[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Monday VoIP peering wrap-up stew
Sorry for the jumbled nature of the responses below here - sending
half a dozen replies shotgun-style seems to be a bit overwhelming, so
I've condensed various threads below.
At 5:28 PM -0400 on 5/17/04, Richard Shockey wrote:
At 03:40 PM 5/17/2004, John Todd wrote:
Yes, sure. As an enterprise user, I suspect I'd have lots of
non-E.164 numbers running around in my route tables, just like
enterprise users have RFC1918 address ranges in their IGP's.
BTW ... its useful to point out here that you hint at one of the
most powerful applications for private enum trees which is the
management of intra-entrprise private dial plans.
This is extremely useful for multi-site enterprises trying to
integrate different SIP systems for different vendors. Point each
edge IP-PBX into a single private tree behind the FW as in
e164.ibm.com and the whole dial plan is globally accessible with a
single administrative interface .. the DNS.
Astrisk I'm told can do this now and its a way cool feature.
I've been preaching in the lecture circuit for some time that this.
Asterisk can do this now, and also can do "cascading" ENUM lookups,
so that if one (previously defined) tree fails with a lookup, the
system looks into the next sequential tree for the same ENUM mapping
until it runs out of trees or gets a response.
This is great for intra-enterprise, you are correct, since it's a
well-known system that is fast and easily expanded within an
organization where there is trust and accountability at some or all
points in the resolution root path.
It is hopeless for inter-enterprise, since you have to verify that
nobody has bogus ENUM entries in their tree, or you need to limit the
tree to certain prefixes, or.... ugh. Starts to look a lot like a
route-filter and access-list, yes? Not something I'd really look
forward to implementing in DNS.
At 7:18 PM +0000 on 5/17/04, Paul Vixie wrote:
> Whilst I am in general in favour of alt-enum proposals, it is very
important to remember that there does have to be an element of control
and indentification in any implementation. If I didnt have to provide
some proof when registering a number, it would be all to easy for me
to register your telephone number and point it to us and steal your
client telephone calls!
i agree. and, this is also true of native enum. that's why i proposed
"fax us a copy of your phone bill" as a way to prove block-ownership. if
there is another, more effective way to prove block-ownership, i am
The faxed copy of the phone bill works for a while, but is just as
madness-inducing as the callback scheme. The costs for overhead on
such a plan will be fairly steep. I have worked directly in
environments with LNP (Local Number Portability) that relied on the
same method of verification, and the estimated cost per number
transferred was around $35 in person-time, even after tuning the
process. I am sorry that I can't offer anything better. I thought
about the callback scheme, and that was the best thing I could come
up with as well, since it could be almost completely automated and
the cost after programming would be down in the pennies per minute
for almost all nations.
At 9:41 PM +0000 on 5/17/04, Paul Vixie wrote:
just to reaffirm isc's capabilities in this area, it's my strong belief
that an isc-branded "e164 root" would have high perceived trust... which
is one of the reasons it's important that we only launch it if doing so
is a non-controversial act.
I would feel comfortable with such a root service. In fact, ISC's
name has been brought up before in over-the-pizza discussions on this
The controversy would erupt due to the introduction of 1.e164.arpa
Real Soon Now. What is the migration strategy? What is the life
cycle of the ISC root? In the event that the ISC root is for all
nations (and not just the industry-sluggish American zone) then how
does ISC propose to ward off international lawsuits by nations who
are displeased with VoIP calls circumventing their "e.164 tax" that
they apply to all phone numbers? Has anyone here even mentioned the
USF tax idea being floated quietly by AT&T, etc. on NANP phone
numbers? We had advantages in the IP world - we could see the
minefield being sewn by the enemy a few feet away, and we could
mostly walk unscathed. This minefield has been laid for years, by
professionals - walk carefully.
More interesting would be ISC's involvement in a robust
implementation of a real routing protocol for telephony routes. TRIP
would be a good candidate, but I think everyone is open to hearing
other options if there is some mystery-hate for TRIP. The question
is, as always, "Where does the money come from?"
At 5:22 PM -0400 on 5/17/04, Richard Shockey wrote:
At 04:14 PM 5/17/2004, Kurt Jaeger wrote:
No. It's like mobile fon numbers -- they were different from the
fixed network numbers. So inet phone numbers will be different as
well and some of the numbers on your business card will vanish
sometime in the future.
<sigh> seen that .. been there.. the guys in Austria have been
trying to push adoption of what the ITU called 878-10 or a global
prefix for "Personal Telecommunications Services" within the E.164
plan.. the root is already registered in e164.arpa , it works in
ENUM, but Richard Stastny and company cant get any service
providers to buy into the scheme.
The reason is that SP do have to buy the numbers ..because like any
complicated numbering resource ..like IP numbers it requires an
administration and administrative fees.
I'll disagree that nobody is using it, though I might be the only one
that can argue with you at the moment. :-) I think it remains to be
seen how much that actually costs. My suspicion is that it's a whole
lot less than TLD's, and that the pricing will be reasonable for
SP's. I'm betting on it, in fact, since I'm using those number
ranges for my customer allocations to avoid a whole host of political
and geographic nightmares, some specific to the US and some generic
to any other nation.
The problem I see with +878 is getting traditional telephony
operators to route that country code to gateways, so that calls from
the PSTN can find their way to the VoIP user. There is no single
provider who can offer that gateway service - any phone company,
anywhere can provide a gateway into the +878 "trunk" just by putting
up a $1200 Asterisk box with a PRI connected to their existing TDM
gear. That scares and confuses most telcos to the point of inaction.
Going the other way is easy - most VoIP devices somewhere have an
upstream carrier that can hand off calls into the PSTN.
At 4:00 PM -0400 on 5/17/04, Richard Shockey wrote:
SIP to SIP works very very well even on best efforts networks the
cost of SIP CUA's is dropping like a rock so if anyone wants to call
me they can use my URI's. ..I do think you generally need above 256K
upstream for reasonable performance with G.711 but if you are using
the GIPS codec you can come down several notches and survive 20% or
better packet loss.
Actually, G.711 works quite well with 128kbps or even less (it's
~80kbps bi-directionally, including IP overhead.) G.729 and GSM work
over dialup 56kbps modems, for some value of the word "work" - it's
quite usable, but is not something on which I'd want to have a
business conference call.
If you're looking for good resiliency against packet loss conditions,
I'd suggest checking out the iLBC codec, which has been native in
Asterisk for some time and is now in the newest Grandstream firmware
image. Please pester the vendor of your ChoIce So they Can Overview
the codec for inclusion into their gateways or MTA devices.
As a VoIP carrier, I am confronted with a lack of routing
methodology for transporting and filtering real VoIP routes between
myself and any other entity. My routing protocol is a hodgepodge of
spreadsheets and contracts, from which I craft my static route straw
doll. I'm looking for a practical implementation of something that
allows me to understand monetary cost, route cost (metrics), and
gateway characteristics from anyone who wants to offer me
settlement-free or cost-based interactions. The protocol is the same
for each... but the protocol doesn't really exist yet.
I see a lot of discussion on how great ENUM is, and I agree! I love
ENUM, and I've put my money where my mouth is by using it for my
customers and myself, and I can't wait for the day when all phones
are ENUM-listed, or even better, when all phones have keyboards. But
ENUM is insufficient for routing. Peering involves, but is not
exactly, exchange of routes that are not exact matches and that can
have competing announcements. ENUM involves hierarchies and
political issues, and private ENUM is still insufficient for route
description without turning ENUM into something that looks like...
well... what should otherwise be a routing protocol. Remove the
hierarchy from this equation by removing the concept that there is a
"root" for most of the voice traffic that will flow around the
Internet. There isn't. Just because you have the hammer of ENUM,
don't think that routing is a nail. ENUM deserves a lot of
attention, but not because it's going to be useful to anyone in the
next few years, so let's be a bit more pragmatic about getting routes
and traffic flowing between VoIP islands.
To unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.
An archive is at <http://psg.com/lists/voip-peering/>.