[p2p-hackers] Official IETF behavior recommendationsforNATrelevant to P2P

[David Barrett]

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?

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'm not familiar with IAX2.  Is it a pipe dream, or does it actually stand a
chance of catching on?

-david

PS: I'm leaving this on the list in case anyone else is out there dealing
with P2P VoIP issues.