[p2p-hackers] Is P2P SIP Poised to Out-Hype Skype? (Voxilla)

[Enzo Michelangeli]

----- Original Message ----- 
From: "David Barrett" <dbarrett at quinthar.com>
To: <p2p-hackers at zgp.org>
Sent: Monday, August 22, 2005 5:23 PM
Subject: Re: [p2p-hackers] Is P2P SIP Poised to Out-Hype Skype? (Voxilla)

[...]
> After all, current telephones have virtually no security, but are widely
> popular with literally billions of users.  I'd rather the IETF focus on
> the billions of mainstream users (simplifying the use of federated SIP
> servers based on DNS records, just like email), who have rather uniform
> and simple needs, than get caught up worrying too much about the diverse
> and complex needs of the hard-core fringe.

Actually, as I said, this is possible right now with ENUM.

[...]
> For example, you rightly pointed out the difficulty of getting SIP to
> work in NAT'd environments.  I'd prefer the IETF:
>
> - Put more weight behind its BEHAVE recommedations, as well as
> - Totally rethink/simplify/unify the STUN/TURN/ICE standards (possibly
> just create a SIP 2 standard that iterates on the whole protocol suite
> into one integrated, stramlined whole),

Such an alternative is already here, now: it's called IAX...

> Before addressing the nonexistent need for a new P2P SIP standard.  The
> IETF can't do everything, so I want it to focus on what brings the
> greatest joy to the greatest number.
>
> Anyway, with all that said, you mentioned NAPTR isn't widely deployed.
> I don't know much about it, but I do know SIP was envisioned to use it
> for looking up the proxy that manages a given SIP address (just like
> looking up the email server for an email address).

NAPTR is a type of Resource Records mainly used by the ENUM number-to-URI
service (and also by similar private numbering systems). You may get the
necessary background e.g. at
http://enum.nic.at/documents/Diverse/Background_to_NAPTR.html .

If popular User Agents just bothered to support it, it could be used
immediately: the existing DNS infrastructure is all is needed. To get a
taste of it, just try this: use dig (or host, or any other DNS client
tool) to resolve "*.0.9.9.9.2.8.8.e164.org", i.e. the number "8829990*"
reversed and used as subdomain of e164.org, you get:

----------------- 8< -----------------
$ dig '*.0.9.9.9.2.8.8.e164.org' NAPTR

; <<>> DiG 8.3 <<>> *.0.9.9.9.2.8.8.e164.org NAPTR
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 0
;; QUERY SECTION:
;;      *.0.9.9.9.2.8.8.e164.org, type = NAPTR, class = IN

;; ANSWER SECTION:
*.0.9.9.9.2.8.8.e164.org.  10M IN NAPTR  100 10 "u" "E2U+HTTP" \
     "!.*!HTTP://www.freeworlddialup.com!" .
*.0.9.9.9.2.8.8.e164.org.  10M IN NAPTR  100 10 "u" "E2U+SIP"  \
     "!^\\+8829990(.*)$!sip:\\1 at fwd.pulver.com!" .

;; AUTHORITY SECTION:
e164.org.               1D IN NS        ns1.e164.org.
e164.org.               1D IN NS        ns2.e164.org.
e164.org.               1D IN NS        ns3.bcwireless.net.
e164.org.               1D IN NS        apollo.bcwireless.net.
e164.org.               1D IN NS        mutual.bcwireless.net.
e164.org.               1D IN NS        alberta.bcwireless.net.
e164.org.               1D IN NS        alberta-2.bcwireless.net.

;; Total query time: 476 msec
;; FROM: em.no-ip.com to SERVER: default -- 192.168.0.1
;; WHEN: Mon Aug 22 18:39:52 2005
;; MSG SIZE  sent: 42  rcvd: 329
----------------- 8< ----------------- 

The line containing "E2U+SIP" (folded in the listing for better
visibility) contains in its last parameter an expression that, apart from
minor differences in the backlash quoting syntax, is a 'sed' expression to
convert numbers starting by "+8829990..." into their equivalent SIP URI's.
For instance, after massaging the expression in a sed-friendly way let's
apply it to +8829990123456 through the sed editor:

$ echo '+8829990123456' | sed 's!^\+8829990\(.*\)$!sip:\1 at fwd.pulver.com!'
sip:123456 at fwd.pulver.com

Voila! this tells you that the number expressed in E.164 format as
"+8829990123456" can be reached with SIP as user "123456" through the
proxy fwd.pulver.com . (There are also "iax2:" URI's, "h323:" URI's and,
for POTS lines on the PSTN, "tel:" URI's. And you can also register
"http:" or "mailto:" URI's, if you like to associate a telephone number to
non-telephonic resources.

So how does the "e164.org" domain name come into the picture?  Well, when
the ENUM standard was agreed upon, the idea was that all the telcos, who
"own" the E.164 telephone number address space, would have registered
their numbers under e164.arpa . That registry, however, is a kind of
"big boys club": forget about your applications being accepted if you are
not a big telco affiliated to the ITU. So the good folks of www.e164.org
decided to set up a free alternative ENUM registry that everybody is
welcome to join. Of course, the resolvers will have to be configured to
search not only for DNS records under e164.arpa, but also under e164.org
(and any other similar registry). Collisions are not a problem, as long as
the applications understand that more than one URI, even with the same
protocol, may be returned for a given number.

>  What can be done to
> accelerate its spread, or compensate for its absence?

The real reason behind the scarce deployment is that providers, as I said
in my previous message, are jealous custodians of their customers, and
just hate the idea of them being reachable and capable of placing calls
without their intervention. Think about it: once a user has a reasonably
intelligent SIP phone or ATA, and can publish the relative URI through
ENUM, what keeps him or her tied to his/her provider? Read the interesting
article at http://www.vonmag.com/issue/2005/jul/features/enum.htm ,
particularly this part:

[...]
"We're also attempting to figure out a way to modify the current ENUM as
it's defined, to include something that called 'Carrier ENUM' or
'infrastructure ENUM'," says McGarry. "ENUM was originally envisioned as a
consumer service. I, Tom McGarry, can register my phone number with the
ENUM registry and I can point those records to my SIP server on my PC in
my basement that's connected to my DSL line. Therefore, I could be my own
VoIP service provider. That's basically the concept. Typically, things
that come out of the IETF have a 'grass roots' aspect to them. But
carriers such as SBC, Verizon, AT&T and MCI have a need to provision ENUM
information to facilitate the routing of VoIP calls, when they finally
roll out VoIP. These carriers are trying to set up ENUM in such a way so
that there's a space within ENUM where they control the records. Today,
the consumer controls the records. It has always been expected that the
majority of the ENUM records would be controlled by carriers as agents of
the consumer."
"But carriers want more control over the situation," says McGarry. "They
want to control access to the records, because they don't want their
network node addresses available on the public Internet. So they've been
working on a way they can modify ENUM to include something called Carrier
ENUM, which gives the carriers-the companies that were assigned telephone
numbers by the number administrator-some greater control over the records
in this section of ENUM. They're still in the middle of trying to figure
out how to get that done."
[...]

So, it seems to me the right thing to do is what e164.org did: create
unofficial registries not subject to the carriers'policies and schemes,
and therefore the ITU's authority.

Or, even better, take the plunge and devise P2P replacements of DNS and
other centralized protocols...

Cheers --

Enzo