No subject

issued to Asterisk with an inactive SDP attribute. Asterisk replies with
inactive SDP and re-INVITES the SIP PSTN channel so the RTP is now going
through Asterisk, music on hold is played to the PSTN channel.

Cisco then re-INVITES with no SPD, Asterisk responds with sendrecv and
Cisco acknowledges with  sendonly SDP attribute, after this Cisco sends
music on hold directly to the SIP PSTN channel. Asterisk repeats the
previous re-INVITE on the PSTN channel and sends music on hold. The result
is that the held party receives two RTP streams, one from Cisco UCM and one
from Asterisk, each playing music on hold.

It is believed that Cisco issues inactive between placing the call on hold
and generating music on hold. This also appears to be performed when the
call is taken off hold. 

It is believed that when Asterisk receives the sendonly it should stop
sending RTP to the held channel. 

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0016313 Responds sendrecv to recvonly SDP, but ...
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-12-07 12:23 lmadsen        Relationship added       related to 0016313  
======================================================================