Media delay / re-invite issue with unsupported VoIP provider

[mit]

Hi,

We have been running 3CX for a couple of months now with great success with the exception of one issue. This is a delay in the media transmission when media is routing via the 3cx server. This delay is around 300ms in our setup which is enough to make conversation awkward.

We have tried to bypass the 3CX server for the media, and this certainly fixes the issue with delay, but we then get an issue with transfers. When we try a transfer out to the VoIP provider we get a 481 "call transaction does not exist" back. We believe this to be because while the call id on the re-invite matches, our VoIP provider is rejecting the call because the contact info or some other field does not match (we are not certain of this though).

So this leads me to a couple of questions for the group:

1) has anyone experieced similar issues with media delay when routing media through the 3CX server or is this likely to be a configuration issue ?

2) any thoughts on how to make transfers work when bypassing the 3CX server for media (everything else seems to work fine, just transfers that are an issue) ?

A few more details:

> 3CX is running on VMWare ESX Enterprise 3.5
> Network latency between phone and 3CX is <1ms
> Network latency between 3CX and VoIP provider is 2ms
> Phones are running dynamic jitter buffers min of 0ms max 100ms normal 20ms
> VoIP provider is running Nextone SBC's version 4.0
> media delay (when looping a call in and out of a phone on the 3CX via the VoIP provider, but not routing media) is about 50ms
> in the same setup above, but routing the media via the 3CX, about 150ms gets added per leg of the call, therefore total delay of about 350ms is apparent.

Any thoughts much appreicated.

 

[mit]

It is not that the media stream passes through the 3CX server twice before reaching the PSTN, it is simply that one set of delay is incurred on the media stream from the A party to the B party, and then further delay is incurred on the return media stream from the B party to the A party. This means that the delay between the A party finishing speaking and then hearing the B party's response is the combination of both these delays, which is the round trip media delay.

An exmaple call flow is as follows:
A Party > IP Handset > 3CX Server > SBC > VoIP Provider > PSTN Gateway > PSTN > B Party
return speech path follows the same route in reverse, albeit via a different SBC

 

[pjr]

In our case it is certainly noticeable. Firstly the 100ms delay (in reality, in our case I think it is a bit longer than this) is incurred on each pass through the 3CX server, so on a conversation this adds a total additional delay of 200ms between parties speaking. Obviously any latency outside our network is additional and any jitter buffers at either end can add this, so in a typical example calling a number from the UK to the UK we might experience a media round trip delay of about 300ms.

This probably makes what would normally sound like a local call in the UK have an equivalent delay to calling between the UK and West Coast US or thereabouts (and when calling from the UK to the US it is accordingly worse). In our situation, having moved all users over one weekend from traditional TDM based PBX to a fully IP solution we have had comments from almost all users mainly related to awkwardness in conversation, where one party inadvertantly talks over the other.

I think the ITU reckons that the maximum acceptible end to end delay is 150ms, so on a call from the phone on my desk to another number in the same city my delay can be approaching this limit.

What I guess is quite frustrating is that this delay is not necessary, there is no need for me to transocde this audio stream on the 3CX server, it can remain as IP until it hits the PSTN, where the transcoding can be performed by a device capable of doing so without significant delay.

Hi Mit,

We have installed a few 3CX systems and use an unsupported VoIP provider (Gamma Telecom). We seem to have no problems with calls made from phones local to the PBX (ie phones on the same LAN as the PBX), but are experiencing intermittent delays on calls made by phones that are connected to the PBX via VPN. This doesnt occur on every call - but happens more often than not. Was the delay you experienced consistent on every call?

The phones that are connected via VPN have their own dedicated ADSL connections which show 20ms responses from the remote phone LAN to the 3CX server LAN.

What overhead did you find that the the internal media server adds to all calls made via SIP Providers?

Thanks

Paul

 

[mit]

Hi Paul,

Our problem is a consistent delay on every call. We do not use VPN in our setup so it is not a direct comparison. We found that when the calls traversed the media server it added probably 100-150ms of consistent delay to the calls. I guess you should be able to tell from the media server logs whether the media server is being invoked when you have your calls coming through on VPN.

Incidently, if you are using your VoIP provider for a call from a phone local to the PABX, do you know if you call is using the media server or if the media is direct in that situation (i.e. are reinvites working correctly).

One other item I picked up while investigating this issue is that somewhere in the advanced settings on the PABX you can set what networks are considered local. If the media server is being involved in the calls from you VPN connected phones, it might be worth taking a look at this setting.