MOH from branch router throws off AAR calculations.

[don.wood]

Has anyone seen this before?

We have a 30 user location that just went live behind a 384Kb/s Frame-Relay circuit. We are running G729 codec between locations and are using G711 locally. The MOH for the new location is being sourced from the local IOS gateway. When using the Real time monitor, we noticed that every time someone at the remote site places a user on hold, AAR deducts a G711 call from the available bandwidth calculations. The actual MOH stream doesn't go across the WAN (we verified this with traffic monitoring and bandwidth usage).

This throws the whole WAN/PSTN routing out of wack from what we needed (less calls use the WAN and more long distance is incurred). We could adjust the AAR values up to try to compensate, but since we have no way of determining how many calls will be placed on hold at any given time and how many actual calls will traverse the WAN (and consume bandwidth).

Is there some kind of workaround for this? We need the MOH source to be local because it sounds horrible at G729 and G711 streams across the WAN aren't really cost effective.

[palves]

This sounds strange...

BTW. What version of CCM are you using?

If 3.3X Multicast MOH is not suppose to take any bandwidth away from Location based CAC (regardless if the multicast traffic goes over the WAN or not).

[don.wood]

we are 3.34.

Just out of curiosity, why wouldn't the AAR take a MOH (or transcoding or conference) stream into account when calculating available bandwidth. It seems to me that this would be just as damaging as wrongly accounting for a stream that isn't there. The system subtracts the 80Kb/s whenever a user is placed on hold. We currently have it set to 135Kb/s (about 5 G729 calls), with this problem, two instances of MOH confuse the CCM into thinking all 135Kb/s is used up. All calls after these two MOH instances are automatically re-routed over the PSTN.

-Thanks

[Aaron Harrison]

According to the Cisco documentation the idea is that when using MoH multicast you would account for this manually - i.e. adjust what you assign as the bandwidth to leave an additional amount of QoS assured bandwidth to allow the MoH stream to work alongside the calls permitted by locations...

If the CM is assigning 80K per call can you definately verify from the CCM logs that the IP phones are being instructed to open multicast reception and not a seperate stream from the CallManager??

[don.wood]

MOH is being sourced from the local IOS gateway. The MOH file is different music than our central office. When a remote user places me on hold (when dialed in over the PSTN), I hear the "remote" MOH song being played. I can also verify that there is no G711 stream traversing the WAN by looking at the actual real-time bandwidth utilization (SNMP).

-Thanks

[Aaron Harrison]

If there are no config issues (i.e. all devices have the same audio source configured, mcast is enabled on the MRG/MRGL/Server/Source, and the gateway has the ccm-manager music-on-hold command) and you can verify that the devices are receiving MOH on the correct mcast IP then it sounds like some sort of bug - as the other poster mentioned CM even up to version 4.0 does not keep track of multicast MoH streams for locations based CAC purposes.

[jconi]

Hi,

I've exactly the same problem. I noticed this when I didn't receive MOH stream on the remote sites. Then if I increased the location bandwidth, the MOH was OK.

I'm really upset, because this throws off AAR calculation, and I don't find any workaround.

I'm working also on a 3.3(3) version, I will try a new one to check if MOH isn't include in CAC.

bye

jp