No subject
Sun Jul 19 19:54:31 CDT 2009
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 ...
======================================================================
----------------------------------------------------------------------
(0114941) davidw (reporter) - 2009-12-08 13:33
https://issues.asterisk.org/view.php?id=16373#c114941
----------------------------------------------------------------------
The workaround of responding a=inactive doesn't work here, because it
requires clairvoyance. Unfortunately the Cisco sends an SDP-less invite,
so Asterisk gets to make the first offer, and cannot know that the reply
will be sendonly.
Now thinking about re-inviting back to Asterisk, as the problem doesn't
happen when canreinvite=no, so Asterisk must be throwing away the upstream
MOH, rather than mixing it with its own.
One worry is about re-invite loops. It should be OK if the hold status is
not changed by the upstream system.
Issue History
Date Modified Username Field Change
======================================================================
2009-12-08 13:33 davidw Note Added: 0114941
======================================================================
More information about the asterisk-bugs
mailing list