[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-11-2008 17:25 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-11-08 17:25  
---------------------------------------------------------------------- 
First, I'd like to see if we can get a tcpdump/wireshark capture of the
traffic between the CCM and Asterisk and between Asterisk and the SIP phone
for one of these failing calls. A packet capture is much easier to analyze
than a console log :-) The packet capture should be made from an unmodified
Asterisk installation, not one with any patches applied.

Second, a number of us have analyzed the information that is provided here
and concluded that it appears that Asterisk is doing *exactly* what the CCM
is asking;  it asks us to put the call on hold, and we do that. For some
reasons it keeps on asking over and over again (and we keep the call on
hold), and it never puts the call back into normal ('sendrecv', 2-way
audio) mode.

You didn't experience the same symptoms with Asterisk 1.2 because
music-on-hold handling in Asterisk 1.2 was written very differently and in
many cases did not work correctly; you happened to find a case where a
combination of bugs in our MOH handling masked the problems being caused by
CCM. This code was rewritten in Asterisk 1.4, and now you are seeing the
bad effects this behavior causes.

Once we have a packet capture of a complete call (start to finish) we can
be more sure of what we are seeing, but it certainly appears that the CCM
is misbehaving and that Asterisk can't be expected to do anything other
than what it is doing. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-11-08 17:25  kpfleming      Note Added: 0083780                          
======================================================================