<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">You are probably running into the problem described below. Below that is a link to the original document with the code patch. I put it on a PRI box we use inhouse and it took care of the 183 before a busy for me. However, this is a box we use inhouse. I've never put it on anything in production. Your mileage may vary<div><br class="webkit-block-placeholder"></div><div>>>>>>>>>>>>>>>>>>>>>>></div><div><div>gday guys (n'gals).</div><div><br class="webkit-block-placeholder"></div><div>I have a third party SIP platform which generates outbound calls via</div><div>asterisk to ISDN (Australia - so thats ETSI ISDN). This platform doesn't</div><div>really like inband signalling on outbound calls (ie getting 183's with SDP</div><div>-- its fine with 180 Ringing etc...)</div><div><br class="webkit-block-placeholder"></div><div>Having had a bit of a silly time with the sip.conf variable</div><div>progressinband=never,no,yes (arg!) I dug a little deeper into the chan_sip</div><div>code.</div><div><br class="webkit-block-placeholder"></div><div>It appears on a SIP->Zap call the ISDN channel is opened, and before you can</div><div>say 'boo' sip_write() in chan_sip is called.... this appears to occurs prior</div><div>to any ISDN signalling (such as PRI_EVENT_PROCEEDING etc..)</div><div><br class="webkit-block-placeholder"></div><div>sip_write doesn't seem to care at all what progressinband is set to, and if</div><div>it gets a frame when the SIP channel is not in AST_STATE_UP it generates a</div><div>183 with SDP (then sets SIP_PROGRESS_SENT)</div><div><br class="webkit-block-placeholder"></div><div>Does this behaviour seem strange? I'm not really sure if this is a bug, a</div><div>'its just like that' thing, or something strange with our ISDN that is</div><div>unusual?</div><div><br class="webkit-block-placeholder"></div><div>In an ideal world (for me anyway... *grin*) I would think that</div><div>progressinband=never (or even progressinband=no) would mean that 180</div><div>Ringing, 486 Busy etc would be used and 183 Session Progress with SDP would</div><div>not...</div><div><br class="webkit-block-placeholder"></div><div>I have done some basic testing and if I patch as follows...</div></div><div>>>>>>>>>>>>>>>>>>>>>></div><div><br class="webkit-block-placeholder"></div><div>url to patch document:</div><div><a href="http://lists.digium.com/pipermail/asterisk-dev/2006-May.txt.gz">From ds at seiros.ru Mon May 1 04:41:40 2006 From: ds at seiros.ru ...</a></div><div><br class="webkit-block-placeholder"></div><div>Richard</div><div><br class="webkit-block-placeholder"></div><div><br><div><div>On Dec 21, 2007, at 9:57 AM, Remi Quezada wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi,<br><br>I have a Asterisk that connects to the PSTN via a PRI. After Asterisk<br>sends the setup message it immediately sends a 183 Session Progress. Is<br>there a way I can change it so that it sends a 100 Trying instead? <br>Because I am having some issues with a equipment where it does not play<br>a busy tone as a result of sending a 183 Session Progress then the 486 Busy.<br><br>Thanks<br><br>Remi<br><br>_______________________________________________<br>--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com">http://www.api-digital.com</a>--<br><br>asterisk-users mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></blockquote></div><br></div></body></html>