Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

mgcp gw across wan link

I've got a group of IP phones separated from their Call Mgr (3.3.2) and PRI PSTN gateways (used by both these users and users local to the CM LAN. 6608 ports so there's no H.323 or IOS involved at all) over a T1 dedicated for IP telephony (CBR PVC between an IMA port on 3620 @ remote & T3 @ CM site). It seems to work fine with light usage (< the T1 PVC), but I'm concerned what will happen if the link runs out of capacity (codec = G.711). There are about 50 users so saturation is unlikely, but certainly possible.

Is there anything I can do to protect the link from saturation? There is only voice over the link; data has another path.

New Member

Re: mgcp gw across wan link

There are a couple of things you can look at.

Use locations in callmanager for CAC and you might want to use g.729 to the other IPphones at central site this will cut the banwidth and voice quality will be good so have a look at regions in CM for this .

I wont recomend G.729 remote-site--> PSTN because of tandem encoding issues and this will result in severe degradation of voice qaulity .This is my opinion from my experience.

Though you can test it and see for yourself call some mobile and international numbers see how it goes.

The ratio you have T1 to users 50 is good 33% of remote office could make g. 711 calls unless this is a call centre / telesales or something simillar where phone abuse is regular.

Have a look at this link ..

Cisco Employee

Re: mgcp gw across wan link

There are only a few things we can do to improve QoS on a link:

1) traffic prioritization

2) fragmentation and interleaving

3) compression

With prioritization, there need to be at least 2 traffic types whereby you can prioritize one over the other. With all voice traffic, you only have one traffic class to work with.

Fragmentation and interleaving won't really apply if this is all voice traffic, as they're already small packets

Compression is really your only option in this case. With 12.2(13)T Class-based RTP header compression was introduced and should work on ATM PVCs:

But, if it were my network I wouldn't bother with that and would just go with G.729 for the bandwidth savings.



New Member

Re: mgcp gw across wan link

That's pretty much what I thought. One other wrinkle is that there are really 2 PVCs between this remote office and the centeral: a 1.5Mbps CBR used for voice and a 2Mbps VBR-nRT used for data. At the remote end, these all originate from a 3xT1 IMA port and terminate at the central on a T3 ATM port (central also terminates 2 10Mbps VBR-nRT PVCs to other sites on this same T3 port). I use policy routing on both ends to direct voice traffic based on the remote end's IP address (since IP phones are in their own remote VLAN/subnet). We do not run any IP phone services so I'm assuming that the non-voice traffic to/from the IP phone subnet is negligible.

I guess what I was looking for was some kind of CAC where if the link was full, the call would be rejected, rather than just piling on & degrading everyone with increased latency, discards, and jitter. G.729 would allow me to handle more calls and I'd hit the wall later, but doesn't really solve the problem.

One more thing... I had a bad experience with 12.2.13T with my IMA boards when chasing another problem. TAC eventually told me that 13T & 15T didn't play nicely with IMA (or maybe ATM in general, I disremember). I've never been able to find a bug or caveat in the RNs to substantiate this, but the IMA interfaces would not come up on anything after 11T. Made for an interesting evening a month or so ago.

Cisco Employee

Re: mgcp gw across wan link

Depending on how your dial-peers are set, you can configure "max-calls " to limit the maximum number of simultaneous calls on a dial-peer. This doesn't really help if you have multiple VoIP dial-peers for outbound calls, but can work in a true hub/spoke environment.

You may have to use a Gatekeeper solution to handle CAC and bandwidth management.

Another solution would be to use Cisco's SAA to monitor link quality and disallow calls if some basic service requirements are not met:

I haven't heard of the IMA problem. If you have a TAC case to reference, post the number and I can take a look if I can grab some free time. ;)



New Member

Re: mgcp gw across wan link

Well if your looking for CAC with hub/spoke CM topology which you have then locations is the obvious answer simple as that!!!!

New Member

Re: mgcp gw across wan link

of course. but I'm a little confused. I have hub and spoke centralized call processing. So I define locations for the hub and each spoke. Bandwidth for the spokes seem obvious as the BW of the link connecting the hub with the spoke. What is the BW of the hub location? 0?

What if there is a mesh circuit between two spokes that will actually carry the traffic (that CM wouldn't know about)?

New Member

Re: mgcp gw across wan link

I'm quite sure 0 means infinite if your worried about it put 10000000 in.

You could still use locations to decrement the value even though it a different physical link.As it is a call going from a to b it will decrement the bandwidth.

These are my opinions I'm sure other people other ideas.

2)Then do LLQ and priority que for voice and setup other classes between the mesh sites.

You obviously thought about this before you implemented it didnt you ?

Re: mgcp gw across wan link

For hub and spoke using locations, I always specify the hub location as having 10000000, no chance of running out of bandwidth there.

Also with CM 3.3 you can have AAR working so that if you limit the spoke to say 1.2M, then run G.729, in the Very unlikely event you run out of bandwidth (and don't forget it's not a real physical limit, just an imposed one) the calls can re-direct over the PSTN.

One word of warning about AAr though, it seriously screws up if you have unity (or any other voice mail) at the hub location. because the VM has no idea who the incoming call is for.

Oh and don't worry about G.729 call quality because in your scenario double encoding shouldn't happen, so most users will have absolutely no idea.


CreatePlease login to create content