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

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

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?

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

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.

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

Chris

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?

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

Outstanding.

Thanks Chris, you have been very helpful.

I have a much better understanding now.