MoH Issue

[frazier24]

Hi,

My client has an issue with their MoH. I have verified all the proper directories and paths for MoH services are correct, however, when I select an Audio Source, the calling party still hears the default Hold Tone. I thought it may have been a corrupt wav. file, so I inserted a new one, selected it, and still the calling party gets the same tone. I've tried this ten different ways with ten different phones and ten different called/calling parties.. still, the same tone. Can you help?

Thanks

[dugrant]

Have you setup Media Resource Group Lists and assigned them to the devices?

[mowour]

Lee,

The key is in ensuring that the party that is supposed to hear the MOH has access to a MOH resource. The default configuration puts all media resources, including MOH resources in the Default Media Resource Group List. The optimal configuration, as Dustin mentions, is to put the media resources in Media Resource Groups and to put those in Media Resource Group Lists. The MRGLs can then be assigned to the devices either at the Device Pool level, or at the Device level (on the phone configution page). What does your current configuration look like?

So your checklist should be:

1. Is there a MOH server registered in the cluster?

2. Do the phone devices have access to the MOH resource?

3. If the phones are using a codec other than the default codec (g.711), are all codecs selected in the Supported MOH Codecs section of the Cisco IP Voice Media Streaming App Service Parameters configuration page?

If you're certain the configuration is right, try restarting the IP Voice Media Streaming Application service.

Regards.

[frazier24]

Thanks for responding.

There are two MoH servers registered.. they are both my CCMs.

How do I verify if the phone have access? I have created the MRG/MRLs, as well as device pools, and assigned the Phones to the pools. So in essense, the phones should have correct access.

Nope.. using g.711 all the way...

[mowour]

Lee,

Did you try restarting the IP Voice Media Streaming Application service?

Here's one other thing to check that has bitten me before. Go into the MOH Server configuration page of each of your MOH servers. Verify that MOH_Server_A is actually registered to CallManager Server_A, not CallManager Server_B. Also verify that MOH_Server_B is registered with CallManager Server_B. If they are not, configure their respective Device Pools with CallManager Groups that forces them to do so.

With a valid configuration, turn on detailed CCM traces and locate the section right after the Hold softkey is pressed when simulating the problem. Do you see any Media Resource Manager errors? Do you see any errors at all? If you can locate this section of the traces, feel free to post them here.

regards

[frazier24]

Hi.. thanks for the info. Yes, it looks like I have one of my MoH servers registered incorrectly. Seems that MoH_Server_B is registered with CCM_A.

Now, I am not following your suggestion on how to fix this. My Device Pool for Corp does have CCM_A as the highest via its CCM Group. I do not have another Device Pool. Which means that CCM_A will always be at the top when it comes to having the MoH_Server_B register.

So.. should I just remove MoH_Server_B all together? If so, how can I do this when its an actual CCM server?

Thanks again

[mowour]

Hi Lee,

Possible workarounds.

1. Configure a new Callmanager Group with CCM_B as the highest Callmanager. Create a new Device Pool and assign it the newly created Callmanager group. Assign CCM_B to this Device Pool. Reset the MOH server. This will have each MOH server register with the CCM it is on.

2. Create a new MRG and assign MOH_Server_B to it. Remove that server from the existing MRGs so that it is only assigned to the new MRG. Do nothing else. This takes it out of the existing groups including the default group, and puts it in a group that is not being used by any device. So no device should have access to this resource. Now when the Media Resource manager requests that a MOH server be allocated, only MOH_Server_A will be available.

Bottom line, in my opinion, is this is a CCM defect. Media resources are advertised as being able to be shared within a cluster.

Good luck.

Michael.

[frazier24]

Sounds good.. and it looks like my clients CCM boxes are trying to do this very thing.

I'll config this thing via your recommendations. Actually, I've already got new MRG/MRLs, so all I need is to setup a new Pool and CCM Grp.

I'll chat with you later and tell you how it went.

Regards,

Lee

[frazier24]

I got it to work via your suggestions.. However, I have two Phones that are setup the same, but they both get two seperate MoH Audio Sources. I have two avail, but it is sort of wierd why one phone takes a different source then the other. Is this a CCM thing to which it'll choose at random?

Thanks again.

Lee

[mowour]

Thanks for the update, Lee.

Can you please clarify the current issue? The way I understand it, when Phone_A is put on hold, Phone_A hears MOH Audio_Source_1, but when Phone_B is put on hold, Phone_B hears MOH Audio_Source_2. Is this the issue?

If the above is true, then note the following:

The MOH Audio Source ID heard by the held party depends on what is configured on the phone that puts the call on hold (holding party).

So it sounds like you put Phone_A on hold from Phone_C and put Phone_B on hold from Phone_D. Test again by putting Phone_A on hold from Phone_C and then also putting Phone_B on hold from Phone_C. They should hear the same thing.

The difference in configuration is between Phone_C and Phone_D.

Regards,

Michael.

[mowour · Accepted solution]

Different scenario.

If there are only two phones involved in the test:

Phone_A hears MOH Audio_Source_1 when put on hold by Phone_B

Phone_B hears MOH Audio_Source_2 when put on hold by Phone_A

The MOH Audio Source ID heard by the held party depends on what is configured on the phone that puts the call on hold (holding party).

The MOH Audio Source ID that is used can be configured either on the Line level, Phone level, or on the Device Pool level. Check all three places.

Regards.

[frazier24]

Thanks.. that is what I had figured. We got it all to work, although it gets sort of confusing since the orig configs were all messed up.

Lee