Hello,

We have a strange problem and would like to know if someone have seen this before.  On incoming calls from PSTN Lync server reports a very high average round trip time.  This affect 99% of incoming calls.  This is the only metric that is out of whack.  All others are good.  Our service provider is supplying us with SIP service, by the means of Edgemarc 5300LF2 session border controller (Edgewater Networks).

 

Looking at the media quality summary report we see under PSTN Calls (Non-Bypass): Gateway Leg Round trip (ms) column marked red.  Drilling down on the individual calls the Mediation Server-Gateway Leg Information section, the Media Line (Main Audio) subsection, Audio Stream (Callee -> Caller) subsection, the Avg. round trip: metric is marked as either red or yellow.  And that is the case for most of the incoming calls.  Users do complain about poor call quality, but it is not as bad as report would have you believe. 

 

Ping times from front-end server to the gateway are < 1 ms.  SBC and Font-End servers are on the same subnet, same LAN, same switch.  LAN and WAN ports on SBC running on full duplex at 100Mbps.  Provider checked round trip time through their MPLS network and reports < 30 ms from SBCs WAN port to the SIP service endpoint.  Traffic capture with wireshark shows no issues in regards to bandwidth utilization.  Other SIP (non-Lync) customers have no issues with this SBC and this service. 

 

Internal calling and over-the-Internet calling works great.  Where to look next? 

Hi,

Average amount of (in milliseconds) required for a real-time transport protocol (RTP) packet to travel to another endpoint and then back. Round-trip times of 100 milliseconds or less are considered of acceptable quality.

High round-trip values can be caused by international call routing, a routing misconfiguration, or an overloaded media server. High round-trip times result in difficulties with two-way, real-time audio conversations.

So please double check the international call routing, routing configuration and if there is any overload for media server.

Best Regards,

Eason Huang

The media servers are not overloaded.  We have about 100 users on 2 media servers, both giving 1-2% CPU utilization.  Plus we have no issues on internal call.  So I think this is not the issue. 

The calls we are working with are US calls, not the International calls - so this does not apply either.

In regards to call routing, and I am assuming you are talking about the Media Server to Gateway communication everything here is very straight forward.  2 media server for redundancy, single gateway for outbound calls.

Did you ever get anywhere with this?  We are seeing the same issue between our mediation server  and an AudioCodes Mediant 2600 using a Windstream SIP.  We are only making US national calls and our mediation servers are not overloaded.  Also, times on our IntelePeer SIP or using Windstream analog lines on a AudioCodes Mediant 1000 all look great.  Perhaps a provider issue?

No, not yet.  I have a case open with Microsoft and provider for a month now - no actual solution/answer offered.  I am suspecting the provider.  After looking at the packet capture between Media Servers and SBC I am inclined to believe that SIP service as delivered is not 100% RFC 3550 compliant.  Some information is missing in Sender Reports, most notably the CNAME field.  As I worked with provider on other SIP issues I learned about their network and the way they conduct business.  Provider supplied SBC as configured performs no mediation of its own - it just passes along all the traffic.  Essentially it is acting like a firewall between my network and provider's network.  I also was able to deduce from other tickets with this provider that if the phone number belongs to some other provider, and they have a SIP interface with that provider, they do not mediate - they just pass along the traffic.  In this case mediation is performed by a 2d or 3d party - whoever is closest to the phone number in question.  Armed with this logic one can see that 500 ms on a long distance call might actually be an accurate number.  I can call my desk phone from my cell phone and I will observer the 500 ms delay.

Will post more when I learn more.

Just curious if you ever heard anything more on this issue?

No, Microsoft closed the ticket and issued a full refund.  They don't know either.  Provider is mum on the issue.  Microsoft pointed out that they are not Lync certified.  Well, this is the one we've got geographically speaking.