Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Latency when Picking Up a Call

Status
Not open for further replies.

Caballero1

Technical User
Nov 8, 2010
67
US
Hello,
There's latency when a call comes in from another site (two different separate Call Managers, same company, domain, different sites but they do no seem to be directly connected), there's a one to two second delay until the calling person can hear me (us). When placing a call to them, i can hear them and vice versa just fine.
Any insights will be greatly appreciated.
Thanks
 
Are calls going over the PSTN via T-1/POTS or are these calls on the company network?
 
Hello,

Calls use a software trunk via an MPLS, real time protocol, two different sites, both autonomous.

Sorry for delay. Someone was taking care of the issue and have come up with "network issue" rather than the phone systems themseves.

Analysys of the RTP stream shows:
Max jitter = 7.26 ms. Mean jitter = 0.89 ms.

There is no packet loss, however the variance in arrival of voice packets is visible.

Any points what it could be on the network, certainly appreicated.

 
7.26ms of *maximum* jitter is nothing.
Plus it's totally irrelevant to the issue of call setup.

"The variance in arrival of voice packets is visible",
What on earth does this mean?
How does it relate to call setup?

Your jitter buffer is obviously going to be set to something which is a *multiple* of your maximum jitter.
120ms jitter buffer is acceptable, for example.
With a jitter buffer set higher than your maximum jitter, you will get zero packet loss (as you are seeing) and there will be zero "variance in arrival of voice packets".

You need to separate voice-quality-related issues from call-setup-signalling issues and address the latter unless the former is indicated.

 
Plus, don't misuse the term "latency".

"Latency" means something in the context of IP traffic: the delay in arrival of an IP packet between two end points.

It does not correctly apply to the symptom you describe.

It sounds to me like somebody is deliberately trying to obscure the issue in order to point the finger at the network instead of addressing the Call Manager config to find out why call setup in one direction is slow.
 
Since you're using MPLS I would check to make sure that the router QoS matches the service providors QoS configuration. I have ran into an issue in the past where Sprint did not have the QoS policy configured to match what we had configured on our router and this caused a similiar issue.

The great use of life is to spend it for something that outlasts it. ~William James
 
Doubtful.
QoS either works or doesn't work. I can't see QoS being responsible for *no packets* for 2 seconds followed by *all packets* thereafter. Doesn't make sense.
This has to be a call setup issue. "temporary initial one-way voice" would be how you could describe it.
The call manager at your end can find the endpoints, which is why the call is setting up OK. The info it gives both phones must be good because both start communicating OK.
The call manager at the other end can find the endpoints, so you get call setup, BUT, what detail is it giving to your phone about its prospective partner in the call setup? Can you get your phone logging what it's doing at this stage? You might have to take a packet capture at your end to see the sequence of events.
1-2 seconds sounds like some kind of timeout for a lookup of some sort.
Make sure you check both Call Manager logs (especially the remote one) for anything they log at this stage of the call setup.
 
In any case, with max jitter 7ms and zero packet loss, QoS is clearly not in any way relevant to this problem.

All QoS is, is a mechanism for helping small voice packets bypass any congestion that might exist in the switch, in order to maximise voice quality.
The effects of congestion are increased jitter and latency and dropped packets.
The OP's voice network is obviously not suffering from any of the effects of congestion and he has no voice quality issue.
Therefore nothing you do with QoS is going to change the voice quality he achieves at the moment.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top