Just ran through the following scenario and wanted to share the experience.
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.
I believe we were running into the bug listed below.
"CSCud60826 - One-way audio after TDM SIP GW receives sendonly, sendrecv media attr"
"CSCtb32219 - ASR1k:CUBE: half duplex path streams (MoH) not established."
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.
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.
I'm not able to access my old voice mail messages all of a sudden. The recording says something like 'the message is currently not available'. This has never happened before in all the years I have been using this system. I have t...