[AVT] RE: [Ietf-behave] RTP in draft-ietf-behave-nat-00

["Francois Audet" <[e-mail]>]

Dan is correct.

We are not looking at implementations that don't support RTCP. This is not
what we were trying to address.

We were looking at applications that, upon receiving an 
instruction to send RTP to an odd address would interpret the RFC 3550 
wording to say that it should send it to the the even address that is 
one lower than the one advertized (which would break protocols such
as SIP/SDP).

> -----Original Message-----
> From: Dan Wing [mailto:[e-mail]] 
> Sent: Monday, November 08, 2004 14:36
> To: Stephen Casner; Audet, Francois [SC100:9T51:EXCH]; 
> [e-mail]
> Cc: AVT WG; [e-mail]
> Subject: RE: [Ietf-behave] RTP in draft-ietf-behave-nat-00
> 
> 
> Stephen, 
> 
> Thanks for reviewing the document.
> 
> To your first point,
> I believe we resolved this, in a positive way, on the list; 
> -00 doesn't yet reflect those changes.  We decided to require 
> NATs to preserve even and odd port numbers when they create 
> their UDP bindings, as this provides the best 
> interoperability for RTP applications that don't/can't 
> provide explicit signaling of their RTCP port.
> 
> To your second, a reference to RFC3605 will be added to the 
> 'application behavior' document, which will describe how 
> applications should behave. The current BEHAVE document just 
> describes how NATs should behave.
> 
> -d
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf 
> Of Stephen 
> > Casner
> > Sent: Monday, November 08, 2004 1:56 PM
> > To: [e-mail]; [e-mail]
> > Cc: AVT WG; [e-mail]
> > Subject: [Ietf-behave] RTP in draft-ietf-behave-nat-00
> > 
> > 
> > draft-ietf-behave-nat-00 contains the following statement:
> > 
> >    There is some very unfortunate
> >    wording in RFC 3550 section 11, which can cause some problematic
> >    behavior in RTP clients.  The wording could be 
> interpreted as saying
> >    that if a client receives an odd port for sending RTP, it SHOULD
> >    change it to the next lower even number.  This would 
> obviously result
> >    in the loss of RTP/UDP.
> > 
> > The actual text in RFC3550 is:
> > 
> >    For applications that take a single port number as a 
> parameter and
> >    derive the RTP and RTCP port pair from that number, if 
> an odd number
> >    is supplied then the application SHOULD replace that 
> number with the
> >    next lower (even) number to use as the base of the port 
> pair.  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.
> > 
> > The key here is that when a session description specifies only one 
> > port number to convey the RTP+RTCP port pair, then the recipient of 
> > that description needs to know how to determine the second 
> port number 
> > from the first.  It is critical that the sender and receiver (or 
> > receivers plural for multicast) do this the same way.  Since the 
> > convention is to use an even port for RTP and an odd port for RTCP, 
> > the spec says that when the given port number is odd, the 
> RTP SHOULD 
> > be the next lower (even) number, and the odd number SHOULD 
> be the RTCP 
> > port.
> > 
> > However, because of requirements imposed by NATs and other 
> > considerations, the second sentence in the above quote from RFC3550 
> > was added.  All the applications need to do is explicitly state the 
> > two port numbers, and then there is no restriction on the even/odd 
> > condition of the RTP port number.
> > 
> > If your concern is that applications that do not implement 
> RTCP will 
> > only have one number to specify, then I have four responses:
> > 
> >   - If the application uses SDP to specify the session and 
> gives only
> >     one address, this still implies that RTCP will be sent, so the
> >     RTCP port needs to be inferred from the single port 
> that is given.
> >     In this case, I claim it makes sense for the stated rules to
> >     apply.
> > 
> >   - If you need to be able to use an odd RTP port number in sessions
> >     specified with SDP, then specify another port for RTCP but don't
> >     use it.  I believe it would be acceptable for that other port
> >     number to be zero.
> > 
> >   - If the application will specify its session some other way, and
> >     intends to specify only a single port with the implicatin that
> >     RTCP will not be sent, then the specification of that session
> >     description method can specify that the SHOULD above be
> >     overridden.
> > 
> >   - Designing out RTCP is bad.
> > 
> > 
> > draft-ietf-behave-nat-00 also contains the following statement:
> > 
> >    NATs that use an "IP address pooling" behavior of "arbitrary" can
> >    cause issues for applications that use multiple ports 
> from the same
> >    endpoint but have no way to negotiate IP addresses individually
> >    (e.g., RTP and RTCP ports).
> > 
> > RFC 3605, "Real Time Control Protocol (RTCP) attribute in Session 
> > Description Protocol (SDP)" specifies a means to negotiate an 
> > alternate IP address for RTCP as well as a port number.
> > 
> >                                                         -- Steve 
> > _______________________________________________
> > Ietf-behave mailing list
> > [e-mail] 
> > https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
> 

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt