cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1628
Views
10
Helpful
17
Replies

Multicasting MoH

arrrghhh3
Level 1
Level 1

So I have several problems, but I'd like to start with this seemingly *simple* one. We're running CUCM 7.1.2, and I think multicasting MoH is configured correctly, I even see the MOHMulticastResourceActive value changing in the RTMT Performance section.

The problem is, when I set the multicast stream to be the first priority in CUCM, I hear no hold music. When I set our unicast stream to be first priority, I hear music. So this tells me we're only unicasting. How do I setup multicasting? Is there a good step-by-step guide? Based on conversations with our network administrator, multicasting is enabled on our LAN at the very least. He is not seeing any multicast packets coming out of CUCM, so I'm pretty certain something is mis-configured. Since I thought it was all correct and I was simply hearing silence, I assumed our switches/routers were blocking the traffic, but not according to the admin.

So any help would be greatly appreciated. We have a much larger problem with remote sites, SRST, using the gateways to stream MoH, but I'd like to sort out why we can't even multicast from CUCM to the local network. Thanks!!

17 Replies 17

Brandon Buffin
VIP Alumni
VIP Alumni

Make sure your audio source and MOH server are set for multicast and that you are using G.711.

Here's a good step-by-step guide.

http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00802d1c31.html#wp1099756

Hope this helps.

Brandon

I have seen that guide, it is a very good one. I'm not sure if my version of CUCM is so different or what, but from what I can tell multicast is enabled - but every time I put it at the top, I get dead air when the user is placed on hold. I put the unicast stream back to the top, and it works perfectly - but it is unicasted.

I will go over the codec again. I went over it previously and when I look at the call stats on the phone it says G.711. I also confirmed the settings in CUCM, but there still is something awry. All the docs on CUCM seem severely outdated - there isn't even an entry for 7.x, and I had to go back to 5.x to get any documentation about the configuration of the system! Am I missing something?

In the region section is where I found the codec settings. When I click on our main site, CORP, and I look at it's relationship with the CORP region, G.711 is there.

A lot of the other sites are G.729, but we don't want to multicast to those remote sites so I assume that is OK.

In the MRGL, if I move the multicast source to the top that is when I get dead air. I don't get it, as the performance counter increments for the multicast active sessions for MOH...

That is a good guide, but seems outdated for my particular setup... Are there any docs from Cisco that are updated? Thanks!

If your CUCM config is correct, it sounds like the multicast stream is not making it to the phone. Can you plug the phone into the same switch as CUCM and verify that multicast is enabled on this switch. If multicast MOH works there, you could then start moving the phone downstream until you find the problem.

Brandon

I'll see if they let me plug a phone into that switch... not sure how well that's going to go over. Supposedly all the switches that matter between CUCM and the phones are trunked together. Also, the admin said he did not see any multicast packets leaving CUCM using some NetScout utility. I can confirm on Wireshark that no multicast streams from 239.1.1.1 or CUCM are showing up...

I'll talk to the admin about plugging my phone into the same switch. This should be an interesting conversation...

Well now I feel bad for creating this thread. My admin was mistaken... multicast is disabled here at CORP, and we want to unicast... that makes no sense, but it's not my decision. I hope we're keeping the unicast streams here, or else we're going to have problems...

Maybe I can expand on this since I'm not going to worry about CORP for multicast for the time being - If I want to use SRST gateway routers to serve MoH locally, does CUCM need to be set to multicasting as well? Based on what I'm reading, that's the case...

I still have to do some testing with my remote sites, but my hunch is that we're just unicasting all the MoH stuff here from CORP, which we really don't want. I've been able to verify everything on the routers, but I haven't seen any active calls testing properly with the MoH command. Perhaps I'll call them from a cell phone to test...

So I guess my question would be, to use SRST routers for MoH all the time - what needs to be configured in CUCM... It seems the configuration on the router is important, but I'm not sure how CUCM tells the router to be the MoH server instead of CUCM. Any help on that would be greatly appreciated, thanks!!

Basically, this setup tricks the phone into receiving its MOH from the local router. If you set the max hops to 1 for your audio source, the multicast stream will not be able to traverse the WAN. When the remote phones are told to receive a multicast stream from CUCM, they listen to the IP address/port number configured in CUCM. The local router is also sending out multicast MOH on this IP address port number. So, while the phone thinks it's getting MOH from CUCM, it's actually listening to the multicast stream from the local gateway.

Hope this helps.

Brandon

I think that answered my question... I'll do some poking around and see what's wrong, as we're not getting any MoH now at our branches.

Does this mean that CUCM must be setup to multicast, or does that matter? Can we unicast here to CORP, and multicast at all the branches from the branch routers? Just setup the remote sites to mutlicast and CORP to unicast?

You can use unicast at one location and multicast at another. However, the phones at the branch will to be setup to use multicast. CUCM will need to be configured to send multicast to these phones even though it actually will not. The phones need to know from CUCM that they are supposed to be listening to a multicast stream.

Brandon

That does make sense. I'm not sure what's wrong, but I'm not getting any MoH at remote locations. The unicast streams here @ CORP work fine tho.

I see a stream being created on the branch routers, but the line looks like it's using G.729, which I assume is incorrect - "239.1.1.3, 16384, 0/0, 28064, g729r8" - that list goes Multicast Address, Port, Packets in/out, Call ID and codec... Not sure what's wrong, but it's not workin as I have it configured. I think the CUCM stuff is correct, I'm going to review the SRST gateway config.

After reviewing the config doc you sent me, I can't figure out what is wrong... I do know that when I run that "show ccm-manager music-on-hold" and there's a PSTN call on hold, I see the stream being created, but there's no "incoming interface" listed, and the codec isn't G.711. But based on my region setup (which is the only thing I could find that would effect codec) I s/b using G.711 at that branch. As far as the incoming interface being empty, I'm not sure what I'm missing there. I reviewed http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_guide09186a00802d1c31.html#wp1046789 as it suggested, and I'm not sure where I am going wrong...

Im having a similar issue here. I have MOH only for PSTN calls in 4.x. So we create DPs for the voice gateways that had the MOH servers, streams, etc.

Upgraded to 7.1 and cant get it to work. If the IP phone puts to call on hold, they get beep beep beep tone on hold. They should get the stream specified in the Common Device Profile applied to the gateway PRI! I have played around with every setting to figure it out.

The Common Device profile, has an the Streams specified.

The Gateway has a media resource group List specified.

This MRGL has MOH and xcoders in MRGs.

The xcoders MRG does *not* have the check mark box for "Use Multicast for MOH Audio (If at least one multicast MOH resource is available)"

Im not sure this would make a difference.

Since the upgrade, we have tried everything to get this to work. I have a TAC case open, but I need to have it reassigned or escalated.

Also, all my codecs in parameters are set to all codecs...

Im combing through the regions next....

Is the MoH server configured? Is that added to the MRGs and MRGLs? I may be missing what your particular setup is, but you didn't mention that at all. I don't know how it's configured in 4.x, we've always been on the linux version.

I know the specs for the audio file are very strict, and I think the windows version of cucm would convert the files while the linux version will not - or perhaps will convert less? I may be barking up the wrong tree again.

CUCM is streaming to PSTN or IP callers with unicast for our setup just fine, I'm having an issue where our branch SRST routers won't stream. I originally thought our setup was supposed to multicast from CUCM, but evidently that's not the case.

I think in your scenario, you want the audio stream off the SRST router. If that is the case you should have something like this configured:

call-manager-fallback

max-conferences 12 gain -6

ip source-address 10.25.254.2 port 2000

max-ephones 42

max-dn 84

moh music.wav

multicast moh 239.1.1.1 port 16392 route 10.25.254.2 10.1.1.1

The 10.1.1.1 is the loop back IP address on the gateway.

When the Multicast session broadcasts out for a request on the router, the router will intercept it and push it the loopback interface and then play the wav file specified. That will keep the audio at the branch not stream it from the CUCMs centralized.

We think there is a bug in 7.1.2. My scenario is not SRST MOH (which is a pain I agree to setup). This is simply utilizing the new Common Device Prole and applying it the router. The router has MOH server access.... just it will not grab the file for whatever reason.

!

Ah. Yea, your issue is probably well above my head. And that exact bracket (pretty much) is what we have in our routers. I can see the multicast stream being created, but the codec it's using isn't g.711, the packets never increase, and the incoming interface is blank. It always goes to 239.1.1.3, so I assume that's why the codec is g.729, but I thought it had to be g.711. Hopefully my TAC case will yield something useful. I hope yours does as well!