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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of Alex > >> Balashov > >> Sent: Friday, November 02, 2007 5:41 PM > >> To: asterisk-dev@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
