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: [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: [email protected] >> >> 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
