5

We're a Canadian business on the east coast and will soon be opening up a new call centre in Australia. This new call centre will be handling our graveyard shift and will be overlapping with the current call centre. As such, I'd need to be able to (SIP) forward calls from our North American Asterisk PBX to Australia.

I'm thinking this may be a problem as it'd require 2+ trans-atlantic trips and would therefore cause a pretty hefty latency on all such calls.

Does anyone have any experience with this ? Or alternative implementations to suggest ?

:: Edit :: Would having a local Australian SIP trunk to provide local numbers cause additional issues ?

6
  • I have minimal voip experience, but why would it require 2+ trips? I'd imagine the call would just be forwarded to the Australian call center and be done.
    – MDMoore313
    Mar 28, 2013 at 19:19
  • 6
    You can't outrun the speed of light. Mar 28, 2013 at 19:19
  • Things to consider: Are people in Australia going to be calling you? Doesn't anyone work the graveyard shift in Canada? Mar 28, 2013 at 20:25
  • We'll have on-call senior support in Canada, but they won't be fielding queue calls. Mar 28, 2013 at 20:43
  • And yes, we will be receiving calls from Australia. We've got a pretty large customer base there, and a few smaller ones throughout Europe ( UK mostly ). Mar 28, 2013 at 20:43

2 Answers 2

4

I don't have any personal experience with this, beyond being the user of such a system (I don't manage the voice system at work). What I do know is that it's possible, because we do it. Though we do NYC<->LON/AMS and not US<->AU. I suggest you invest in a decent link between the site, with guaranteed bandwith and latency. As Michael says, you can't outrun the speed of light. Fortunately that's fairly irrelevant, as light travels quite fast compared to human speech, even for such distances. You just want to make sure you know you're not going too slow.

(btw, I'd really suggest you go trans-pacific, not trans-atlantic :))

4
  • Haha, true you can't outrun the speed of light, however you're adding an increasing amount of routers and switches in the mix which'll invariably lead to latency, unless I'm very much mistaken. Mar 28, 2013 at 20:14
  • As for the roundtrips .. that's entirely my bad .. a detail I'd omitted. If we were to have local numbers in Australia provided to us as a SIP trunk, the call travel would most likely be Customer > Australian SIP trunk > North American PBX > Australian Phone ... one trip up to the PBX, and then another down to the Phone. Mar 28, 2013 at 20:15
  • Oh, and thanks for the NYC<>LON bit .. that's certainly good to know ! Mar 28, 2013 at 20:17
  • Asterisk is only a directory/connection service. The VOIP calls go direct customer-gateway-call centre. AUS customers to AUS gateway, AUS call centre won't see trans-Pacific Latency. Canadian customers to Canadian gateway, VOIP trunk, AUS call-centre will. Gateway Latency is always significant. TransPacific latency adds to this, but it doesn't multiply-it doesn't affect the Gateway latency. To reduce Gateway/Trunk latency, don't use a cheap gateway, don't use a cheap network provider -- different providers have different trans-pacific latency.
    – user165568
    Mar 30, 2013 at 7:48
0

Have you tried some simple tests to determine what the latency is between the 2 locations? If you haven't got anything there right now you could try using speedtest.net (a bit brutal but it will give you an idea) and choosing an ISP in the right city. Obviously whatever ISP you end up with may vary.

From http://www.voip-info.org/wiki/view/QoS -

Callers usually notice roundtrip voice delays of 250ms or more. ITU-T G.114 recommends a maximum of a 150 ms one-way latency. Since this includes the entire voice path, part of which may be on the public Internet, your own network should have transit latencies of considerably less than 150 ms.

(emphasis mine)

I can only give my personal experience which is largely limited to UK <> US East coast, in that I have never known any issues and that's over a VPN with no special concern at all for the SIP traffic.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .