[p2p-hackers] Official IETF behaviorrecommendationsforNATrelevant to P2P

[Enzo Michelangeli]

----- Original Message ----- 
From: "David Barrett" <dbarrett at quinthar.com>
To: "'Peer-to-peer development.'" <p2p-hackers at zgp.org>
Sent: Friday, May 20, 2005 1:40 PM
Subject: RE: [p2p-hackers] Official IETF
behaviorrecommendationsforNATrelevant to P2P

> Enzo -- Perhaps you can help with solving a lingering problem of mine.
> As you correctly point out, the RTP spec says:
>
> >    [...] For
> >    applications in which the RTP and RTCP destination port numbers are
> >    specified via explicit, separate parameters (using a signaling
> >    protocol or other means), the application MAY disregard the
> >    restrictions that the port numbers be even/odd and consecutive
> >    although the use of an even/odd port pair is still encouraged.
>
> However, RTP isn't the place where ports are communicated -- SDP is that
> place.  Unfortunately, SDP defines a media description as (from
> RFC2327):
>
>      m=<media> <port> <transport> <fmt list>
>
> There's only room for one port in that, and it's presumed to be the RTP
> port, with the RTCP port implied to be one above.  This is backed up by
> the line:
>
>   Other ports used by the media application (such as the RTCP port, see
>   [2]) should be derived algorithmically from the base media port.
>
> This is actually an obstacle I've heretofore been unable to resolve; how
> can you communicate a separate RTCP port while remaining standards
> compliant?

RFC3605 describes an extension to SDP to add an RTCP attribute:

   rtcp-attribute =  "a=rtcp:" port  [nettype space addrtype space
                         connection-address] CRLF

I'm not sure how widely this is deployed, but the RFC is flagged
"Standards Track". And
http://www.simpleweb.org/ietf/internetdrafts/complete/draft-wing-mmusic-symmetric-rtprtcp-01.txt
suggests (or suggested, as it's expired) to practice "symmetric RTCP" just
as it's done for RTP.

> As for rport, symmetric RTP, STUN, TURN, ICE, etc, all these do help.
> But it's just so much damn work; there's a hundred pages of specs
> there to be compliant with.

I know, it's a bloody nightmare, and there is no guarantee that your peers
ever make the same set of assumptions. Shouldn't a "session initiation
protocol" lead to determine precisely that? :-)

> I'm not familiar with IAX2.  Is it a pipe dream, or does it actually
> stand a chance of catching on?

It's real (although still poorly documented: but the work in progress at
http://www.cornfed.com/iax.pdf is promising). At present it is supported
by a number of commercial
(http://www.voip-info.org/wiki-VOIP+Service+Providers+B2B) and free
(www.iaxtel.org, http://www.freeworlddialup.com/content/view/full/1501 )
providers, and also by some hardware manufacturers (see e.g.
http://www.iareaphone.com/Hardware.htm ) and a few softphones: the best of
the latter (but, alas, closed source) being IMO Firefly:
http://www.virbiage.com/firefly/download/ , version "for third party
networks".

The IAX2 reference implementation (libiax2) is embedded in Asterisk, an
excellent (and GPL'd) software PBX (www.asterisk.org ,
http://www.voip-info.org/wiki-Asterisk ) that runs on Linux, *BSD and
MacOS X, and even on reflashed Linksys WRT54GS routers: see e.g.
http://openwrt.org/forum/viewtopic.php?id=1419 . See also the library at
http://iaxclient.sourceforge.net/ .

The great thing of IAX2 for NAT purposes is that it always uses _one_
UDP port for both signalling and media, and it's intrinsecally symmetric.
Apart from that, it's noticeably more efficient than RTP in trunking
applications. On the weak side, sending media together with signalling
makes it impossible for the server (the proxy / registrar with SIP) to
disengage from the media stream while continuing to monitor the call for
billing purposes. So, the carriers (which _hate_ the idea of being forced
to switch to a "flat rate" model, being addicted to the "minutes" they
love to bill as they did when they were younger ;-) ) are generally
unenthusiastic toward IAX2 and like to diss it as "toy protocol".

<SOAPBOX> This, in my opinion, will eventually be resolved by the market
realities: NOBODY is going to pay carriers on metered basis for ANY purely
Internet-based service (i.e. excluding, e.g., PSTN termination), for the
simple reason that on the Internet the application layer is out of the
carrier's reach; also, users prefer flat rates for ease of budgeting, and
apart from that, the complications inherent in a per-minute billing system
should make a flat-fee model attractive also for a provider. Some smart
people who in the past worked for carriers, like David Isenberg (of "The
rise of the Stupid Network" fame: http://www.isen.com/stupid.html), and
the exceptionally bright Andy Odlyzko (e.g., in
http://www.dtc.umn.edu/~odlyzko/doc/pricing.architecture.pdf ), did grasp
this point early on, but the dinosaurs who ran the LD business were in
strict self-preservation mode. </SOAPBOX>

So, it's not surprising if, today, Isenberg looks favourably at IAX2...
See e.g. his article at
http://www.vonmag.com/issue/2004/julaug/columns/isenberg.htm . Now, if
only the IETF and the big vendors who call the shots and sell to the
carriers came to their senses...

Enzo