| Summary: | ASTERISK-15258: Asterisk ignoring sendonly SDP generated from Cisco UCM after generating inactive SDP when a Cisco phone initiates hold | ||||
| Reporter: | James Taylor (jamestaylor) | Labels: | |||
| Date Opened: | 2009-12-02 11:23:30.000-0600 | Date Closed: | 2011-07-26 14:33:31 | ||
| Priority: | Major | Regression? | No | ||
| Status: | Closed/Complete | Components: | Channels/chan_sip/General | ||
| Versions: | Frequency of Occurrence | ||||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) full_cisco_hold2 ( 1) full_cisco_hold2.pdf | |||
| Description: | Cisco Unified Communications Manager 6 was connected to Asterisk via a SIP trunk. A call was made from a Cisco handset and routed to Asterisk via the Cisco SIP trunk. Asterisk answered the call and Dials a PSTN number via the Cisco SIP trunk, which is answered. The call is established and the RTP is re-INVITED. From the Cisco handset the call is placed on hold. A SIP re-INVITE is 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. ****** ADDITIONAL INFORMATION ****** This has also been tested on Asterisk 1.6.1.0 with the following patch applied: https://issues.asterisk.org/file_download.php?file_id=22737&type=bug The same problem is present. Cisco is configured not to use MTPs. Music on hold is enabled. The dial plan configured on Asterisk was: exten => 6120,1,Answer() exten => 6120,n,Wait(3) exten => 6120,n,Dial(SIP/911122223333@siptrunk1) The Cisco sip trunk is configured as follows in sip.conf: [siptrunk1] type=friend context=default host=192.168.10.10 disallow=all allow=ulaw canreinvite=yes qualify=yes call-limit=1000 dtmfmode=rfc2833 6902 is the Cisco phone. 192.168.10.10 is the Cisco UCM version 6 192.168.71.51 is Asterisk 911122223333 is the PSTN number I have attached a PDF file showing the SIP signalling and RTP state. | ||||
| Comments: | By: David Woolley (davidw) 2009-12-03 05:09:40.000-0600 By using a Polycom, rather than the Cisco, one can also demonstrate this, in terms of dialogues, and final RTP configuration, without the complications due to the Cisco sending re-invite with no SDP, and temporarily re-inviting to a=inactive. The big difference is that the Polycom doesn't source MOH, so the result is not, or at least less, obvious to the user. As phones send a=sendonly, without sourcing MOH, the best approach may be to respond a=inactive, rather than a=recvonly. Alternatively one could re-invite the holder back to Asterisk, so that Asterisk had full control of the RTP stream, although I don't know what happens if there is a conflict between upstream RTP and local MOH, in Asterisk itself. By: David Woolley (davidw) 2009-12-08 13:33:39.000-0600 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. By: David Woolley (davidw) 2009-12-09 11:41:27.000-0600 As a short term solution, we may resort to pointing music on hold at an empty directory, which results in Asterisk not sending any RTP. In its simplest form, this completely destroys the music on hold capability, of course. The other risk, in the simple form, is that anything with something like Asterisk's rtptimeout, and without the double MOH problem, might think the connection had failed. By: Leif Madsen (lmadsen) 2011-07-26 14:33:25.948-0500 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks! By: Hernán (hmronline) 2011-10-27 09:39:35.839-0500 I'm having this very same issue with Cisco Call Manager v4.1 and Asterisk 1.8.7.1. Please let me know what information is required to resolve it. Thanks in advance, Hernán.- | ||||