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

Sun Nov 4 14:08:35 CST 2007

> 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.

That sounds like a good idea John. I don't see any harm in doing this. In
fact, if it helps we could also put some additional text in the reason
phrase in such keep-alive 1XXs. An example would be "183 Session Progress
Refresh". That way, somebody looking at the SIP messaging alone would also
get a hint about this. 

Raj

> 
> 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
> 
> 
> _______________________________________________
> --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