Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-and-rtcp-mux-06.txt

[Colin Perkins <csp at csperkins.org>]

On 26 Jul 2007, at 19:54, Randell Jesup wrote:
> Internet-Drafts at ietf.org writes:
> > Title		: Multiplexing RTP Data and Control Packets on a Single Port
> > Filename	: draft-ietf-avt-rtp-and-rtcp-mux-06.txt
>
> >      Note: since all RTCP packets MUST be sent as compound packets
> >      beginning with an SR or an RR packet ([1] Section 6.1), one  
> > might
> >      wonder why RTP payload types other than 72 and 73 are prohibited
> >      when multiplexing RTP and RTCP.  This is done to ensure  
> > robustness
> >      against broken nodes which send non-compliant RTCP packets,  
> > which
> >      might otherwise be confused with multiplexed RTP packets.
>
> This should mention that relaxing that restriction is under  
> consideration,
> (I forget the exact draft name) and that by including the PT  
> restrictions
> in this draft we avoid a potential conflict with the other draft  
> (i.e. it
> may not be only "broken nodes").  I also would remove the word  
> "broken",
> it's misleading.  They are non-compliant with 3261 (until that  
> draft is
> approved).

I'll submit a -07, changing this to:

      Note: since all RTCP packets MUST be sent as compound packets
      beginning with an SR or an RR packet ([1] Section 6.1), one might
      wonder why RTP payload types other than 72 and 73 are prohibited
      when multiplexing RTP and RTCP.  This is done to ensure  
robustness
      against nodes which send non-compound RTCP packets, which might
      otherwise be confused with multiplexed RTP packets.  At the time
      of this writing, there is a proposal to allow non-compound RTCP
      packets in some circumstances [17], so this robustness may become
      more important in future.

and adding the appropriate reference.

> >   When the Session Description Protocol (SDP) [8] is used to  
> > negotiate
> >   RTP sessions following the offer/answer model [9], the "a=rtcp-mux"
> >   attribute (see Section 8) indicates the desire to multiplex RTP and
> >   RTCP onto a single port.
>
> We should also discuss interaction with offering both "a=rtcp-mux" and
> "a=rtcp <port>".  I can see an endpoint wanting (or needing) to  
> include
> both.  The answer selects between rtcp-mux and "normal" rtcp handling
> (including a=rtcp, though there's no direct way to know if the  
> answerer
> supports it).

This is discussed in section 5.1.1 of the draft. Please suggest text  
if the current wording is not sufficient.

Thanks,
--
Colin Perkins
http://csperkins.org/



_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt