[Home]

Summary:ASTERISK-18758: CLONE - Asterisk ignoring sendonly SDP generated from Cisco UCM after generating inactive SDP when a Cisco phone initiates hold
Reporter:Hernán (hmronline)Labels:cisco hold sdp
Date Opened:2011-10-27 09:42:36Date Closed:2011-11-21 14:08:59.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:1.8.7.1 Frequency of
Occurrence
Related
Issues:
is a clone ofASTERISK-15258 Asterisk ignoring sendonly SDP generated from Cisco UCM after generating inactive SDP when a Cisco phone initiates hold
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: Hernán (hmronline) 2011-10-27 09:46:15.548-0500

This is a clone of ASTERISK-15258
I'm having this very same issue with Asterisk 1.8.7.1.
Please let me know what information is needed to resolve it.

Thanks in advance,
Hernán.-

By: Leif Madsen (lmadsen) 2011-10-31 13:44:54.656-0500

Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. You may find it helpful to read the Asterisk Issue Guidelines http://www.asterisk.org/developers/bug-guidelines. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need:

1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).

This likely includes output from the console with debug level logging, a SIP trace (if this is SIP related), and configuration information such as dialplan (e.g. extensions.conf) and channel configuration (e.g. sip.conf). Thanks!



By: Leif Madsen (lmadsen) 2011-11-21 14:08:53.334-0600

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines