[asterisk-dev] UAC leg cancel on early media / MoH.

[Alex Balashov]

Ah, thank you!

This was in 1.2.24.  Do you suppose this behaviour differs in 1.4.x?

On Fri, 2 Nov 2007, Raj Jain wrote:

> Quoting from section 13.3.1.1 of RFC 3261:
>
>   If the UAS desires an extended period of time to answer the INVITE,
>   it will need to ask for an "extension" in order to prevent proxies
>   from canceling the transaction.  A proxy has the option of canceling
>   a transaction when there is a gap of 3 minutes between responses in a
>   transaction.  To prevent cancellation, the UAS MUST send a non-100
>   provisional response at every minute, to handle the possibility of
>   lost provisional responses.
>
> From your description it seems that Asterisk is not repeating the 183 every
> minute. Therefore it's a bug in Asterisk.
>
> - Raj
>
>
>> -----Original Message-----
>> From: asterisk-dev-bounces at lists.digium.com
>> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of
>> Alex Balashov
>> Sent: Friday, November 02, 2007 5:41 PM
>> To: asterisk-dev at lists.digium.com
>> Subject: [asterisk-dev] UAC leg cancel on early media / MoH.
>>
>>
>>
>> Hi folks,
>>
>> I ran into a problem where SIP calls were being dumped
>> straight into a queue without being Answer()'d.  Music on
>> hold from the queue was being generated via 183 Session in
>> Progress + SDP, i.e. early media / in-band ringback.
>>
>> After about 3 minutes of this, all SIP UACs I tested with
>> would CANCEL the leg, resulting in the caller being dropped
>> out of the queue.  This happened with a Cisco 7960 (SIP
>> image), Polycom 501, and tne X-lite softphone.
>>
>> Anyway, I fixed the problem by simply furnishing an Answer()
>> in the dial plan, of course, but I was curious as to why SIP
>> UACs react this way.  I could not find any explanation for
>> this in reviewing the various SIP T-timers in the RFC, or the
>> various RFCs and drafts dealing with early media.
>>
>> In other words, I see no reason why the calling SIP agent
>> should terminate the call after 3 minutes since the 183 + SDP
>> have elapsed.  What gives?
>>
>> Thanks,
>>
>> --
>> Alex Balashov
>> Evariste Systems
>> Web    : http://www.evaristesys.com/
>> Tel    : +1-678-954-0670
>> Direct : +1-678-954-0671
>>
>> _______________________________________________
>> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>

--
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : +1-678-954-0670
Direct : +1-678-954-0671