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

[Raj Jain]

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