MOH configuration question

[wilson_1234_2]

We have three servers confdigures as MOH servers, one has mulitcast enabled, the other two do not.

Our branches have voice gateways, and all phones in remote branches are in the same MRGL, (configured in each device pool).

The MRGL holds a MRG that has two servers in it, the first server is unicast, the other is multicast, but the "Use Multi-cast Audio (if at least one multi-cast MOH resource is available"

This would mean I am not using mulicast at all if this is not checked correct?

Does the Selected Media Resource go in priority, top down?

If I am using unicast, is the MOH sent as an RTP stream to the on hold party?

[Chris Deren]

Whatever MRG is listed first is the one that will be used first until no resources are available.

Resources listed in the same MRG are load balanced.

In order to have multicast working you need the multicast checkbox checked.

If you are using unicast then yes you are streaming it across WAN.

Chris

[wilson_1234_2]

Thanks Chris, when you say streaming, you mean RTP?

[Chris Deren]

Correct.

Keep in mind that MOH sounds terrible over G729, so if you are going to stream it across WAN as g711 you will need to allocate enough bandwidth. This is where multicast comes in handy and at the remote location you can utilize the local GW and "fake" phones to think they are connecting to multicast IP address of the server, but instead they use local GW, you don't need to worry about bandwidth as all traffic stays local to the remote site.

Chris

[wilson_1234_2]

Thanks again.

Please forgive my basic questions. I am having difficulty visualizing how the multicast would work for the branches.

If streaming across the wan, a single g711 call would be approx 64K correct? Not a big deal for one call, unless you are talking about several people being on hold at any one time and consuming 64K per hold session.

If so, then multicasting to all of the phones would be more efficient. Is that what you are talking about?

I am not sure I understad this:

"at the remote location you can utilize the local GW and "fake" phones to think they are connecting to multicast IP address of the server, but instead they use local GW"

Are the multicast "instructions" sent from multicast server to the branch gateway and the gateway mutlicasts to numerous on hold phones?

[Chris Deren]

If streaming across the wan, a single g711 call would be approx 64K  correct? Not a big deal for one call, unless you are talking about  several people being on hold at any one time and consuming 64K per hold  session.

>>G711 call is 64K payload, plus leyer 2 overhead, so about 87K for example over MPLS. This is for each call, so if you put 5 calls on hold concurrently multiply it by 5.

If so, then multicasting to all of the phones would be more efficient. Is that what you are talking about?

>> Correct

"at the remote location you can utilize the local GW and "fake"  phones to think they are connecting to multicast IP address of the  server, but instead they use local GW"

Are  the multicast "instructions" sent from multicast server to the branch  gateway and the gateway mutlicasts to numerous on hold phones?

>> You configure MOH on the local GW under SRST configuration to be used by the phones at the location even during normal condition, the SRST configuration references the same Multicast IP address and port assigned to the MOH Server used by the phones, and set mutlicast hops to be low, i.e. 1 or 2, this way the phones' think they are connecting to the server multicast IP address, but in fact they are connecting to local GW. G711 is used and no calls traverse WAN. You do however need to upload the MOH source file to the local GW and maintain it there, so if you need to change it you need to change it there as well.

HTH,

Chris

[wilson_1234_2]

Ok Chris, I am getting there.

Earlier I mentioned that the two servers configured under the MRGL that the branches use, did not have the check box "Use Multicast Audio" checked.

Since the check box is not checked, could the branches still multicast locally using their local wav file?

We do have SRST configured on the branch routers, but I was unsure if the branches used their local wav file all the time, or only when SRST mode. We recently changed out infrastructure and I am not sure how the MOH is working.

We recently had someone change MOH and the wav file on the servers, but not on the gateways, when they tested the branch, they got the correct MOH.

[Chris Deren]

Hmm, good qestion, I guess I never did it this way as it's just a checkbox so why not check it?

Chris

[wilson_1234_2]

I appreciate your answers Chris, (I am just trying to sort this all out how it is working).

But I am not sure it is even an issue any longer because of the infrastructure change that was made.

Originally each branch had a PRI and all off net calls in and out used their local PRI. In that case the MOH either streamed or multicasted locally to the person on hold.

Now, all calls are in/out via a SIP trunk in the hub site, so any outside caller getting MOH for anyone would be getting it from the MOH server sitting in the same switch as the SIP gateway, so none of that traffic traverses the WAN.

I guess the only time it would be is if someone internally put someone in one of the branches on hold, then I guess it would stream across because we do not have the primary server selected as a multicast source.

Does that sound like it could be correct?

[Chris Deren]

Yes, this makes a huge difference, and you are right on.  Besides SIP trunk providers do not support Multicast MOH, so unicast is required.

Chris

[wilson_1234_2]

Outstanding.

Thanks Chris, you have been very helpful.

I have a much better understanding now.

[davebowen]

Keep in mind these facts when configuring MOH.

Priority follows these rules for MOH.

Line

Device

Common Device Config

CCM Server Parameters

If a remote router should provide MOH service during fallback you will need to have the file TFTP'ed to the flash.

Them change the ccm fallback to moh filename of the moh file.

Hope this helps.