[VoiceOps] The big ENUM question (Was: VPFs)

[Mark R Lindsey]

At IPTComm a couple of years ago, Jonathan Rosenberg stood up and said  
the big problem was the walled gardens that are telcos and ITSPs. We  
carriers just aren't passing traffic via VoIP. Even Cisco customers  
aren't passing traffic within their own company; you'd have a BTS over  
here and a BTS over there, owned by the same Cable MSO, passing  
traffic via ISUP.

Continuing this conversation about VPFs: what would it take for you to  
start routing calls across the Internet using lookups like ENUM?

1. A big task would be advertising our routes. We'd have to pull our  
user's numbers out of our boxes -- Asterisk, BroadWorks, MetaSwitch,  
Taqua, Sonus, Nortel, Cisco, etc., and advertise those numbers  
somehow. I'm sure tools to extract the list of local numbers from each  
of these systems would be pretty easy. Raise your hand if you're  
excited about advertising all of your user's telephone numbers to make  
the telemarketing and SPIT easier.

2. We'd need to agree on some way to ensure that these routes  
advertised were authoritative. E.g., how would YOU know that I'm  
really authorized to advertise +1-229-316-0013? If you dip to SS7,  
that goes to my CLEC-partner-of-the-week.

3. Then we'd need to agree on some way to do the lookup. ENUM seems  
like a nice option -- if the basic delegation mechanism made sense. It  
makes sense if we have large blocks of numbers, like NPANXXs, and  
there are no number ports. But since we all have number ports, the  
large blocks will be punctuated by many, many individual references to  
the ITSP that ported in the number. So the ability to delegate  
subdomains using ENUM doesn't bring much value, to my mind.  So  
whether we use ENUM or a normal SIP redirect server probably doesn't  
make a lot of difference.

4. We'd also need to make peace on the whole transport thing. As Brian  
Sneddon just said, the commodity Internet remains acceptable for a lot  
of purposes. There's risk in betting on that, of course.

5. And then we'd have to figure out how to bill each other, if we're  
going to do billing. But is billing each other for 100 kbps audio  
streams worthwhile anyway?

6. Of course, we also want to be sure we're allowing calls only from  
the right people. A few years ago, many of us setup our SBCs to allow  
calls from the public Internet, but that's much less common now. Oh,  
we'll accept any ol' screechy call that comes from our known peer, and  
pay him to do it.

And once we figure out all of these challenges -- which are really  
quite moderate -- we've got to convince ourselves that the effort is  
worth the reward: we get to bypass the big carriers for some calls,  
and get to use fancy codecs like G.722 and video.

The technical challenges are really quite moderate. The VPF people are  
trying to solve it but only within their club. Why pay them when we  
can do it ourselves?




On Aug 5, 2009, at 11:29 AM, Brian Sneddon wrote:

> I've looked at Stealth's VPF a little before, but I also don't see  
> them as too compelling yet.  The voip carriers we use are well  
> connected on the commodity Internet and latency remains within  
> acceptable levels with those carriers.  The last time I checked VPFs  
> didn't take care of the most complex issues such as being able to  
> interop or negotiating rates, so paying a premium for a VPF doesn't  
> yet benefit us enough.
>
> Brian
>
> ----- "David Hiers" <David_Hiers at adp.com> wrote:
>
>> Hi,
>> Does anyone use a voice peering fabric?
>>
>> I look at 'em from time to time, but just don't see them as a
>> compelling option yet.
>>
>>
>> Thanks,
>>
>>
>>
>> David Hiers
>>
>> CCIE (R/S, V), CISSP
>> ADP Dealer Services
>> 2525 SW 1st Ave.
>> Suite 300W
>> Portland, OR 97201
>> o: 503-205-4467
>> f: 503-402-3277
>>
>>
>>
>> This message and any attachments are intended only for the use of the
>> addressee and may contain information that is privileged and
>> confidential. If the reader of the message is not the intended
>> recipient or an authorized representative of the intended recipient,
>> you are hereby notified that any dissemination of this communication
>> is strictly prohibited. If you have received this communication in
>> error, please notify us immediately by e-mail and delete the message
>> and any attachments from your system.
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops


Mark R Lindsey lindsey at e-c-group.com http://e-c-group.com/~lindsey  
+12293160013