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

From: Colin Perkins <[email-masked]>
Date: Wed, 1 Aug 2007 12:08:05 +0100

On 26 Jul 2007, at 19:54, Randell Jesup wrote:
> [email-masked] 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Wed, 01 Aug 2007 22:53:40 -0400

>       when multiplexing RTP and RTCP.  This is done to ensure  robustness

Looks good.

>> "a=rtcp <port>".  I can see an endpoint wanting (or needing) to  include
>> (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.

Aha, sorry, missed that.  The wording seems good.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)