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.co
m/
Tel    : +1-678-954-0670
Direct : +1-678-954-0671

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

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-bounceslists.digium.com 
> [mailto:asterisk-dev-bounceslists.digium.com] On Behalf
Of 
> Alex Balashov
> Sent: Friday, November 02, 2007 5:41 PM
> To: asterisk-devlists.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.co
m/
> Tel    : +1-678-954-0670
> Direct : +1-678-954-0671
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.c
om--
> 
> 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.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Most systems have an un-answered call timeout/limit. This
makes sure
that calls are not left ringing forever. Also most telcos
enforce a
timeout to prevent people from getting endless free phone
calls.

If you want to do something with a call, other than leave it
ringing,
then answer it first (as you found out). Some 800 call
centers cheat the
phone company by NOT answering the call but starting an auto
attendent or
voice mail system and placing the call in queue WITHOUT
being charged.

There are valid reasons to not answer a call but not be
ringing.
The best example is for changed/disconnected number
messages.
Other reasons not to answer are for call
forwarding/redirections
(where the final leg controls answering).

Also some phones (or systems) won't send DTMF on an
unanswered call.....


Quoting Alex Balashov <abalashovevaristesys.com>:

>
>
> 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.co
m/
> Tel    : +1-678-954-0670
> Direct : +1-678-954-0671
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.c
om--
>
> 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.c
om--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev