[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:
[snip]
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.

[snip]

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
educable.

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 very topic.

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: 
[snip]
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. (http://www.ilbcfreeware.org/)



(summary)

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.

JT

--
To unsubscribe send a message to voip-peering-request@psg.com with
the word 'unsubscribe' in a single line as the message text body.
An archive is at <http://psg.com/lists/voip-peering/>.