[asterisk-bugs] [Asterisk 0013034]: 183 response although progressinband=never
Asterisk Bug Tracker
noreply at bugs.digium.com
Fri Feb 20 02:35:32 CST 2009
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=13034
======================================================================
Reported By: klaus3000
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 13034
Category: Channels/chan_sip/Interoperability
Reproducibility: always
Severity: minor
Priority: normal
Status: feedback
Asterisk Version: 1.4.21
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2008-07-09 07:03 CDT
Last Modified: 2009-02-20 02:35 CST
======================================================================
Summary: 183 response although progressinband=never
Description:
Hi!
Scenario with Asterisk 1.4.21.1:
SIP Client ----> chan_sip:Dial(zap):chan_zap ---> ISDN
very simple dialplan:
[fromklaus]
exten => _1X.,1,NoOp(1... SIP: Outgoing Call: Asterisk->HiCom)
exten => _1X.,n,Dial(Zap/g1/${EXTEN:1})
Immediately after sending the SETUP message, Asterisk responds with 183
Session Progress. Thus, the SIP client is waiting for inband audio, but
there is no inband audio available. progressinband=never
sip.conf:
[klaus]
type=peer
username=klaus
host=dynamic
context=fromklaus
canreinvite=no
progressinband=never
actually I tried all progressinband settings without any difference
======================================================================
----------------------------------------------------------------------
(0100431) oej (manager) - 2009-02-20 02:35
http://bugs.digium.com/view.php?id=13034#c100431
----------------------------------------------------------------------
After a lot of discussion, I've decided to create a branch called
"no-premature-183" with an option to disable this behaviour in chan_sip. We
won't send any frames until we actually have proceeding or alerting from
the other end. I don't know why chan_sip does that, but doesn't like
breaking it.
This could also be an option in zaptel/dahdi so that no frames are sent
INTO your pbx, but that's for someone else to patch and it would propably
be a better solution. My world is chan_sip :-)
We still want to figure out WHY this happens, what kind of frames
equipment send.
See
http://lists.digium.com/pipermail/asterisk-commits/2009-February/031041.html
Issue History
Date Modified Username Field Change
======================================================================
2009-02-20 02:35 oej Note Added: 0100431
======================================================================
More information about the asterisk-bugs
mailing list