VoIP and Call Status 3

[DJPlaZma]

I have a multi-part question and I've had no luck finding answers.

We have CM3 with the head end in MI and an ESS in PHX, connected over an MPLS circuit. It's a 1.5Mb circuit w/60% set aside for voice, so we have roughly 900k for voice. Based on 30k per call, that gives us about 30 calls before there is degradation in voice quality. (If someone can check that math I'd appreciate it...I may be missing a factor or two in figuring that out.)

My questions are this:
1) I believe we're trying to put too many calls down that pipe, resulting in very poor sound quality. Is there a way to monitor or pull up historic numbers of the amount of traffic being routed over that MPLS circuit? Sprint's reporting gives me a percentage of utilization, but not solid numbers, as in calls-per-hour.
2) I'm using the 90-day trial of VoIP Monitoring Manger software. Can the call volume be pulled from this application? I appreciate how it gives me jitter, ttl, lost packets, etc, but does the thing do anything less-granular?

I'm trying to make a case for a) increasing the bandwidth on this pipe and b) for splitting the call center (one in MI, one in PHX) in two. I feel that there are too many call center calls being routed between the two locations, leading to a severe degradation in voice quality.

Thanks in Advance for any help!

-Jim

 

[pat1960]

I don't know about an historical measurement, but you can status the network region real time to see how many calls are happening on that region.

 

[Dunstan]

You can also limit the IP network region to a certain total number of calls or total bw usage. If you suspect it is more then the 900k alloted just lock it down at 900 with a PSTN based fail over and see how many calls during peak route pstn versus IP.

 

[mrjedi]

you can also use IGAR to route calls between sites over pstn but using the signalling across the mpls. Try this and reduce the bandwith to 20k which then forces the call over pstn and then increase the limit gradually and see if indeed QoS is the problem. We have a similar scenario and run no voice across the MPLS and it works fine except for the 2-3 second delay in answering the call because of the pstn route

 

[DJPlaZma]

GREAT information! Thanks, guys. I think I have a hold on this now. Getting the router configs helped A LOT and I've made some changes that have been helpful.

 

[whatsanavaya]

i'm not following this thread clearly.

isn't the number of calls limited to the number of trunk members?
ie. if you have an IP trunk between two locations with 30 members, then the max calls is 30?
The amount of bandwidth they use will depend on the codec set used when dialling between the two regions. So if they used G.729 its approx 30kb/s per call as posted above, that 900kb/s, although the quality is still dependant on the WAN link

So how many members do you have on the Link? what coedecs are you using?

 

[DJPlaZma]

I was trying to narrow down how many calls we were trying to send across this MPLS circuit, because the voice quality was extremely poor. With the aid of the posts above, getting copies of the router configs to see that there were miss-matched QoS settings, and correctly setting the percentage alloted for voice calls I was able to clear things up.

Sprint did not, as we were originally informed, have it set up as 60%, but at 35% dedicated for voice. There was also a codec miss-match between IP Network Regions 1 and 2. We are now at 50% set for voice (750k, about 27 calls) using G.729 codec, where previously one region was using G.711. The correct QoS settings have been applied.

Things seem to have cleared up making all these (and more) adjustments. Funny thing, though...Avaya installed this system in conjunction with Sprint working on the network side.

My next step will be to limit the calls between regions by either bandwidth or number of calls to keep this from happening again. Any suggestions on which way to do it?

 

[mrjedi]

Use IGAR and limit the calls by bandwidth or number of calls and all remaining calls get routed over PSTN but the signalling still goes over the MPLS so user still gets name and number display. Excellent feature. My customer loves it.