×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Unicast UCM Music On Hold Fails through CUBE ASR

Unanswered Question
Aug 4th, 2013
User Badges:

Just ran through the following scenario and wanted to share the experience.


Setup

Service Provider ----SIP----> ASR CUBE -------SIP----> UCM


We found in a packet capture that UCM advertised music on hold on port 4000, however it choose a random RTP port.  The ASR was receiving the MOH RTP stream on the internal interface but it did no pass the MOH RTP stream along to the service provider apparently because there is a port discrepancy. 


Bug

I believe we were running into the bug listed below.


"CSCud60826 - One-way audio after TDM SIP GW receives sendonly, sendrecv media attr"

and

"CSCtb32219 - ASR1k:CUBE: half duplex path streams (MoH) not established."


Workaround

As a work around we set the "Duplex Streaming Enabled" service parameter in CUCM to "True".  After making this change the UCM stopped using the bogus 4000 port and started advertising the actual port it selected for the MOH.


According to the ASR code release notes this bug is corrected in version 3.10S (03.10.00.S.153-3.S) At the time of this posting that ASR code version has been released for 4 days.  We chose to stick with the "Duplex Streaming" work aound.

http://www.cisco.com/en/US/docs/routers/asr1000/release/notes/asr1k_caveats_310s.html


-Joshua Learn

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Alessandro Bertacco Fri, 09/27/2013 - 03:19
User Badges:

Great Joshua,

  this issue was making me crazy!!!

Works perfect.


Thank you so Much.

Regards


Alessandro

Rejohn Ronald Cuares Wed, 10/02/2013 - 03:26
User Badges:
  • Bronze, 100 points or more

I also encountered this issue on ISRs. Another workaround was disabling IP CEF (not recommended though in a high traffic environment).

Sent from Cisco Technical Support iPhone App

Frederick Nielsen Mon, 12/16/2013 - 15:42
User Badges:
  • Bronze, 100 points or more

Enabling two-way MOH per the above is a workaround of sorts, but does anyone understand why CUCM uses the bogus port 4000 (instead of the actual source port) when setting up a one-way MOH in the 1st place?  We have observed that a number of 3rd-party SIP peers drop the one-way unicast MOH stream because of this and as a consequence (the whole cluster) needs to be enabled for two-way MOH, which is not 100% desirable.


Seems like a lot of issues would be solved by implementing proper support for the one-way call setups here.  There are several defects filed on this, but they all seem to be sev 6.

Actions

This Discussion