[asterisk-dev] UAC leg cancel on early media / MoH.
Raj Jain
rj2807 at gmail.com
Mon Nov 5 13:16:38 CST 2007
This issue and further discussion on it is now being tracked at:
http://bugs.digium.com/view.php?id=11157
Raj
> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com
> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of John Todd
> Sent: Saturday, November 03, 2007 7:32 PM
> To: Asterisk Developers Mailing List
> Subject: Re: [asterisk-dev] UAC leg cancel on early media / MoH.
>
> 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
>
>
> _______________________________________________
> --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
More information about the asterisk-dev
mailing list