Unicast UCM Music On Hold Fails through CUBE ASR

Joshua Learn · ‎08-04-2013

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

Alessandro Bertacco · ‎09-27-2013

Great Joshua,

this issue was making me crazy!!!

Works perfect.

Thank you so Much.

Regards

Alessandro

Rejohn Cuares · ‎10-02-2013

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

Please rate replies and mark question as "answered" if applicable.

Fred Nielsen (ePlus) · ‎12-16-2013

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.