MOH issue with pstn

[Austin3:16]

I have strange issue using MOH, it hear silent with PSTN, eveything good only with internal call but when a call came from the pstn and one of the users put the call on hold it hear silent and sometimes it works randomly.

[Nithin Eluvathingal]

Do you have the MRGl applied on the gateway/Trunk ? 

[Austin3:16]

On the sip trunk in cucm or on the cube ?

[TechLvr]

@Austin3:16 It is possible that your MOH is currently set to use only one codec, either g711, or g729. 
You can configure it to use both codecs. To do that, follow the steps below.  

In CUCM, navigate to System > Service Parameters
Select a CUCM node from the dropdown list.
Then select "Cisco IP Voice Media Stream App (Active)"
Under "MOH Supported Codecs", while holding ctrl on your keyboard, select g711ulaw, g711mlaw, g729
Once all 3 codecs are highlighted blue, click save. 

Go back to the first dropdown list at the top of the page and repeat the same steps for each CUCM node that has an ""Cisco IP Voice Media Stream App (Active)" option. You don't have to worry about the CUCM nodes that shows "Cisco IP Voice Media Stream App (Inactive)". 

If the above changes does not fix the issue, then follow Nithin's suggestion because then it could be related to a mismatched ptime or something. You can assign MRGL to the SIP trunk in CUCM (pointing to your CUBE).

[Austin3:16]

Hello @TechLvr everything you talked about is configured on the cisco unifiee communication manager  but when i collect the log from the cube i see that the cucm send a sdp inactive with a = inactive

[TechLvr]

That’s normal. CUCM and CUBE send a=inactive in the re-Invite messages to signal that the call is on hold, so they pause the audio traffic. 

Can you share your SIP logs here? 

[Austin3:16]

@TechLvr here is th log 

[TechLvr]

The issue is that the CUBE receives re-invites from CUCM, but does not send re-invites to the carrier. This means MOH is delivered to the CUBE and stops there. The carrier side is not aware of the MOH and continues to send RTP traffic. This is a CUBE config issue. I think your config is missing the “mid-call signaling passthru” command. Can you share your CUBE config? 

[Austin3:16]

@TechLvr here is the config.

[Roger Kallberg]

A couple of things to note. You have not turned on the Cube functionality in your SBC. You do so under voice service voip by the command mode border-element. Second thing you do not seem to have an inbound dial peer for calls coming from CM, I’d recommend you to create that. Third instead of having multiple dial peers towards your service provider for different destinations I would recommend you to use an e164 dial plan map so that you can collapse these into one. Fourth, for your dial peers towards CM you can collapse these into one as well if you use a server group. Lastly I would recommend you to use information in the VIA header to match inbound dial peers, this applies to both from CM and your service provider.

For additional information on this please see this great document. In Depth Explanation of Cisco IOS and IOS-XE Call Routing 

[TechLvr]

After reviewing your logs/CUBE configs, I believe the issue is that your SIP trunk, from CUCM to the CUBE, does not have access to any MOH to play.
Or the region relationship between your MOH server and SIP trunk (CUCM to CUBE) is not set to 64kbps.

This is why CUCM never sends a re-invite(sendonly) after the initial re-invite(inactive).

Though your CUBE config is NOT consistent with best/standard practices, it has the right configurations to handle calls/MOH.

To troubleshoot the MOH issue, follow steps below.
1. In CUCM, go to Device > Trunk. Find and click open the SIP Trunk in question.
Under "Media Resource Group List", make sure you select a group. It should not be set to "None."
If it was set to "None" but you selected a media resource group, then reset the trunk and test MOH again.

2. If the issue persists, in CUCM, go to Media Resources > Media Resource Group List. Click open the Media Resource Group List that's assigned to the SIP Trunk.
Write down the name of the media resource group. Next, go to Media Resources > Media Resource Group. Click on the approperiate group name.
Under "Selected Media Resources" make sure a MOH server is selected. If not, select an MOH server from the list of available MOH servers and click save.
Then go back to the SIP Trunk and reset the SIP Trunk if a new MOH server was added.
Test MOH again.

3. If the issue is not resolved, check the region relationship between MOH Server and the SIP Trunk.
Go to Media Resources > Music On Hold Server. Find the MOH server in quesition and see what device pool assigned to.
Open the device pool of the MOH server, and note the name of the "Region" it is associated with.
Also, open the device pool of the SIP trunk, and note the name of the "Region" is assiated with.
Go to System > Region Information > Region. Find and click on the "Region" assinged to MOH server device pool.
Then under "Regions" sections, click to highlght the SIP Trunk "Region"
Finally, set the "Maximum Audio Bit Rate" to 64kbps and click save.
Test MOH again.

Steps above should resolve the issue, but if not, then restart the "Cisco IP voice Media Streaming App" service. The last potential issue, that I can think of, is a bad custom MOH file.

[Roger Kallberg]

Great write-up @TechLvr (+5). One comment, under step 2 there would be no no reset the SIP trunk when adding a resource to a MRG.

[Austin3:16]

@TechLvr i just want to add an informations to you about this log when someone transfer the call i cannot hear the moh from external exactly like when someone put the call on hold the same thing happend. 

[Roger Kallberg]

When a call is transferred it is set on hold, it would be what is known as a network hold.