[182504] in North American Network Operators' Group
Re: SIP trunking providers
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Jul 20 09:04:34 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <1212444734.2959.1437388624829.JavaMail.mhammett@ThunderFuck>
Date: Mon, 20 Jul 2015 06:04:24 -0700
To: Mike Hammett <nanog@ics-il.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
Why not set up a small Asterisk box in a local datacenter and only trunk =
out the non-local calls?
Owen
> On Jul 20, 2015, at 03:36 , Mike Hammett <nanog@ics-il.net> wrote:
>=20
> I want the gateway in Chicago as well.=20
>=20
> I am Chicago based. The end users are Chicago based. Therefore the =
origination would be coming from a Chicago area gateway. Half of the =
calls (inbound would be guaranteed to be local as they'd be coming in =
through a local tandem anyway. Most of the termination traffic would =
again be to local numbers, therefore would again have to be through =
local tandems.=20
>=20
>=20
>=20
>=20
> -----=20
> Mike Hammett=20
> Intelligent Computing Solutions=20
> http://www.ics-il.com=20
>=20
> ----- Original Message -----
>=20
> From: "Nathan Anderson" <nathana@fsr.com>=20
> To: "Mike Hammett" <nanog@ics-il.net>=20
> Cc: nanog@nanog.org=20
> Sent: Monday, July 20, 2015 4:11:37 AM=20
> Subject: RE: SIP trunking providers=20
>=20
> Maybe I'm missing something here, but what does it matter if the RTP =
from your perspective ends in Chicago or not? If it does end in Chicago, =
that only means they are proxying the audio before sending it on to the =
actual media gateway for that call where it finally drops onto the PSTN. =
So all that happens is that the audio latency remains the same (or =
worse, because of the additional, unnecessary proxy) AND that the actual =
media gateway remains hidden from you. You won't be able to actually =
test and see the latency to the MG, and you will be under the (false) =
impression that latency across all calls is equally "good" because you =
are only measuring RTT to a specific and common media proxy. By sending =
the audio directly to an MG closer to the point of exit from IP-land, it =
is taking a more direct route to the callee than you are seemingly =
asking for.=20
>=20
> If you're not talking about adding a proxy to the equation, are you =
expecting to find a provider in Chicago that immediately goes from IP to =
PSTN within Chicago, regardless of the actual destination of the call? =
Circuit-switched TDM is not a no-latency connection. Physics is involved =
here. The farther apart the caller is from the callee, the more latency =
there will be, regardless of the medium. All other things being equal =
(similar network path, etc.), I doubt IP packet switching significantly =
increases the latency over and above TDM call trunking. But I'm not an =
expert, and again, if I'm missing something here, I would love to be =
proven wrong.=20
>=20
> --=20
> Nathan Anderson=20
> First Step Internet, LLC=20
> nathana@fsr.com=20
>=20
> ________________________________________=20
> From: NANOG [nanog-bounces@nanog.org] On Behalf Of Mike Hammett =
[nanog@ics-il.net]=20
> Sent: Sunday, July 19, 2015 1:04 PM=20
> Cc: nanog@nanog.org=20
> Subject: Re: SIP trunking providers=20
>=20
> I too am looking for the Chicago area. Low volume. I'm looking for =
people whose SIP and RTP hit the end of the road in Chicago. Not =
interested in someone whose SIP servers are in LA , but will redirect me =
to the nearest gateway... without telling me where said gateway is.=20
>=20
>=20
>=20
>=20
> -----=20
> Mike Hammett=20
> Intelligent Computing Solutions=20
> http://www.ics-il.com=20
>=20
> ----- Original Message -----=20
>=20
> From: "Rafael Possamai" <rafael@gav.ufsc.br>=20
> To: nanog@nanog.org=20
> Sent: Friday, June 19, 2015 4:40:48 PM=20
> Subject: SIP trunking providers=20
>=20
> Would anyone in the list be able to recommend a SIP trunk provider in =
the=20
> Chicago area? Not a VoIP expert, so just looking for someone with =
previous=20
> experience.=20
>=20
>=20
> Thanks,=20
> Rafael=20
>=20
>=20
