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

[John Todd]

Sounds like a bug that cries out for a patch... :-)

I'm 100% behind sending out early media the correct way, and 
requiring an "Answer" in front of all applications before a call is 
actually classified as "answered".  However, right now it's very easy 
to mistakenly send audio to a channel without Answering it.

I would suggest this, if you create a patch: the first 183 and 
subsequent early media should be transmitted without any warning or 
error messages.  However, after one minute (the first re-transmit of 
the 183) then a message (debug? warning?) should be thrown saying 
something like "183 Early Media refresh on SIP/1239-blahblahblah: Is 
this intentionally not Answered yet?" so that inadvertent neglect of 
calling an app_answer can be discovered by those who forget it.  A 
full minute of early media is typically longer than "normal", so I 
think the messages on refresh wouldn't be burdensome on the logfiles.

JT


At 7:07 PM -0400 2007/11/2, Raj Jain wrote:
>
>I'm not sure how this broke in 1.4. I just don't see any calls to start a
>one minute timer at places where we generate 183 (or any other non-100
>provisional responses for that matter) in chan_sip.c in 1.4.
>
>- 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 6:42 PM
>>  To: Asterisk Developers Mailing List
>>  Subject: Re: [asterisk-dev] UAC leg cancel on early media / MoH.
>>
>>
>>  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
>>
>>  _______________________________________________
>>  --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