[asterisk-bugs] [Asterisk 0012110]: CCM sends multiple INVITEs which causes MusicOnHold to execute on a channel

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12110 
====================================================================== 
Reported By:                blitzrage
Assigned To:                kpfleming
====================================================================== 
Project:                    Asterisk
Issue ID:                   12110
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:           1.4.18 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             02-29-2008 16:27 CST
Last Modified:              03-13-2008 08:16 CDT
====================================================================== 
Summary:                    CCM sends multiple INVITEs which causes MusicOnHold
to execute on a channel
Description: 
Found this for a client who is using a CCM gateway and terminating calls to
SIP phones attached to Asterisk.

I've added some traces from the console with history dumped. You'll notice
in the good calls that you get 3 or 4 INVITE,100,200,ACK loops, then the
CCM stops sending the invites, and the call remains setup.

In 1.2.26.2, you'll see that happen, with the Starting Music on
Hold/Stopping Music on Hold each time that loop happens. On 1.2 though, the
music on hold never actually is heard. On 1.4, when the same thing happens,
the music on hold actually is executed and does not stop.

This is preventing him from moving to 1.4.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0011475 Asterisk replies with a 488 to a Re-Inv...
====================================================================== 

---------------------------------------------------------------------- 
 kpfleming - 03-13-08 08:16  
---------------------------------------------------------------------- 
Well, I'm not sure what to tell you. In this trace Asterisk is doing
*exactly* what the CCM is asking it to do. The initial call setup proceeds
normally, then the CCM asks Asterisk to put the call on hold (the media
session is set to 'inactive'). After that, the CCM sends a series of INVITE
requests with no SDP included. The RFCs do not say what should happen when
this occurs.

In older releases of Asterisk, and 1.4 with the patch I supplied, Asterisk
does not change the state of the session, it just replies to the INVITE as
normal. In unpatched Asterisk 1.4, Asterisk takes the session off hold (the
media session returns to 'sendrecv'), which your CCM does not handle well,
it asks Asterisk to put the call back on hold.

This code in Asterisk was put there explicitly to support Cisco Call
Manager by oej when he was at a SIP interoperability event early last year,
so it's really bizarre why your CCM is acting so strangely.

In any case, there are only two things we can do when we receive an INVITE
with no SDP: we can either respond with the session's current state without
changing it, or we can bring the session back from hold. We have now tried
both alternatives with your CCM, and neither of them results in usable
behavior for your system.

I really don't see that there is anything else that Asterisk can do to
help this situation. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-13-08 08:16  kpfleming      Note Added: 0083888                          
======================================================================