[asterisk-users] Send SIP 100 Trying instead of 183 Session Progress

[Richard Revels]

You're right of course.  I should have dug into this a little deeper  
and checked to see if it is corrected in the current release.  As is  
so often the case, I was working on a real specific problem and once  
the system started doing what I wanted it to I pretty much forgot  
about it.

I won't drag this out but I do want to clarify one point.  This  
scenario occurs when the call originates from the SIP side and is  
destined for a number on the PRI side.  The PRI does the trunk setup  
and then the SIP 183 is sent back to the originator before any further  
call progress occurs on the PRI side.  This results in the SIP  
originator seeing a "ring" and then a "busy" if the called party is  
actually busy.  Not deadly (although the original poster seemed to  
have some equipment that didn't like it) but certainly irritating.

Richard

On Dec 22, 2007, at 2:23 AM, Johansson Olle E wrote:

>
> 21 dec 2007 kl. 22.24 skrev Richard Revels:
>
>> 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
>>
>>>>>>>>>>>>>>>>>>>>>>>>
>> gday guys (n'gals).
>>
>> I have a third party SIP platform which generates outbound calls via
>> asterisk to ISDN (Australia - so thats ETSI ISDN).   This platform
>> doesn't
>> really like inband signalling on outbound calls (ie getting 183's
>> with SDP
>> -- its fine with 180 Ringing etc...)
>>
>> Having had a bit of a silly time with the sip.conf variable
>> progressinband=never,no,yes (arg!) I dug a little deeper into the
>> chan_sip
>> code.
>>
>> It appears on a SIP->Zap call the ISDN channel is opened, and before
>> you can
>> say 'boo' sip_write() in chan_sip is called.... this appears to
>> occurs prior
>> to any ISDN signalling (such as PRI_EVENT_PROCEEDING etc..)
>>
>> sip_write doesn't seem to care at all what progressinband is set to,
>> and if
>> it gets a frame when the SIP channel is not in AST_STATE_UP it
>> generates a
>> 183 with SDP (then sets SIP_PROGRESS_SENT)
>>
>> Does this behaviour seem strange?   I'm not really sure if this is a
>> bug, a
>> 'its just like that' thing, or something strange with our ISDN that  
>> is
>> unusual?
>>
>> In an ideal world (for me anyway... *grin*) I would think that
>> progressinband=never (or even progressinband=no) would mean that 180
>> Ringing, 486 Busy etc would be used and 183 Session Progress with
>> SDP would
>> not...
>
> I don't think progressinband controls early media (audio to caller
> before call setup)
> but how indications should be sent (in audio=inband). If we get early
> media from
> the callee leg of the call, we have to relay it always.
>
> If you get early media signalling in SIP and don't have early media on
> the outbound
> call leg, then there's a bug and you should open a bug in the bug
> tracker so we
> can resolve it. For license reasons, we can't handle patches on the
> mailing list,
> we have to get them through the bug tracker.
>
> I really appreciate your help in resolving this issue, as you clearly
> have a lot of
> insight in the situation. Please open a bug on the bug tracker and
> we'll meet
> you there!
>
> Thanks,
> /Olle
>
> ---
> * Olle E. Johansson - oej at edvina.net
> * Asterisk Training http://edvina.net/training/
> * The Asterisk SIP Masterclass - Stockholm, Sweden, January 2008
> * Register today!
>
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users