08-10-2011 06:11 AM - edited 03-16-2019 06:24 AM
CUCM 6.1.5 with 8 subs, 1 Pub, and MOH server running on TFTP server using fixed source WAV files. 2 phones in the device-pool, when called by PSTN offf-net callers, and put on hold, the caller hears no MOH, only silence. Other phones in the same device-pool hear MOH fine. All services running, detailed debugging enabled, no sign of errors. WHen we change the device-level HOLD source from <none> default, to a source like 2 or 3, then MOH is heard. What would make 1 or 2 phones not play MOH when the system is setup to play the default MOH source, which is associated to the inbound SIP trunks ?
08-12-2011 08:08 AM
Hi,
The MOH for the PSTN caller is taken from the gateway or the gateways device pool not the phone.
Check the gateway has access to the MOH resource
Hope this helps
Alex
08-12-2011 08:47 AM
To add to what Alex said (+5 Alex), the audio source is specified by the device executing the hold event (i.e. phone user presses Hold, Transfer, etc.). The Media Resource Group List (MRGL) assigned to the SIP trunk determines the media resource provider that will stream the audio. MRGL can be assigned directly or via a device pool. A directly assigned MRGL overrides the device pool.
Those are the basics, check them to be sure you are running what you think you are. I suspect you got it covered. Getting to your specific problem. If I follow, when you select an audio source other than default (on the ip phone) the MoH plays out fine, every time. However, when you select the default audio-source, you are not getting MoH. Assuming this is a correct interpretation of what you are seeing then I'd look at the following:
1. Is the default audio-source the stock audio source or did you create/upload a new audio file? If you uploaded a new/custom audio file, you will need to upload that file to every cluster node that is running the IPVMS service (i.e. a MoH server in your Media Resource Group). Media files are streamed from the local disk on individual IPVMS systems.
2. Are you doing multicast? You will want to check the audio source to see if it is enabled for multicast. If this is the case then you will want to make some mods. It depends on what you mean by "inbound SIP trunks". If you are using carrier SIP trunks then multicast MoH is likely not supported (at least in my experience). So, you will want to ensure you are doing unicast MoH. This doesn't mean you have to dismantle your multicast approach. You can still keep the audio source as mcast enabled, you just need to configure a MRGL/MRG for the SIP trunk where the MRG is not mcast enabled.
If, on the other hand, you are running SIP between CUCM and the gateway and T1/E1 PRI to the carrier, you may be able to get mcast to work using the "ccm-manager music-on-hold" IOS command. For SIP, I think this needs to be IOS 12.4(24)T2 or later.
3. Region/Codec. If doing SIP trunks from the carrier you will first want to identify the codec the carrier expects. Sometimes, they only support G.729. Check the codecs allowed for MoH via IPVMS service parameters (I suspect this is fine since some MoH streams work). Check codecs on MoH audio source. Check region/inter-region configurations. This is a good time to stare-and-compare between the "known-good" and "known-bad" configurations.
HTH.
Regards,
Bill
Please remember to rate helpful responses and identify
08-12-2011 09:11 AM
1. The MOH is a custom audio file made by Captive Audience, uploaded to (2) TFTP server nodes. I verified the audio source file ( 711,729) shows up on each TFTP server where the IPVMS service is running for the MOH server.
2. Unicast, since the MOH is assigned to SIP trunks from Verizon, no gateways involved, uses SIP trunking to most sites including this one. SIP over MPLS WAN.
3. Region codec for this site's device-pool uses system default.
I noticed this phone device has no user associated to the device, that shoudl NOT be related to MOH I would think, but I will associate a user anyways, since that is our standard. It has a MOH file source assisgned at the device and line level at this time, and callers now hear MOH, very strange. Only 1 other phone at same site has same problem, my test phone in same site DP hears MOH ok using system default.
Questions:
Does Unicast MOH have a max sessions parameter ?
It is a 7962 with a sidecar with lots of BLF's on it, does that matter ?
08-12-2011 09:18 AM
Yes, there is a max session parameter. Look under service parameters for the IPVMS service. You may need to look at Advanced Parameters.
The 7962 with BLFs shouldn't make a difference.
Back to your regions. You are using default and the default behavior is that inter-region codec is g729. So, if regions are different, you are using g729. Which may or may not be what you want.
HTH.
Regards,
Bill
Please remember to rate helpful responses and identify
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide