Subject: [AVT] comments on draft-ietf-avt-rtp-and-rtcp-mux-01.txt

From: "Even, Roni" <[email-masked]>
Date: Mon, 6 Nov 2006 01:18:27 +0200

Hi,

I would first like to say that the conflict with FIR and NACK as defined
in RFC2032 is not a problem. In the updated version in RFC4587 we took
those messages out since they were not in use.

I am a bit unclear about the relationship between SDP signaling in
section 5.1.1 and ICE. The section says that if the answer does not
contain a=rtcp the offer should use the port pair rules. But that will
not work for NAT traversal. The next paragraph raises the same question,
how will the answerer offer RTCP candidates for the session.

In section 5.1.3 you describe how to work with ICE when the both sides
support RTP and RTP multiplexing but what will happen in the case when
the answerer does not support multiplexing and would like to fall back
to non-multiplexed mode.

Roni Even

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

---

From: Randell Jesup <[email-masked]>
Date: Sun, 05 Nov 2006 23:04:43 -0500

>those messages out since they were not in use.

The conflict is with the AVPF NACK.  There's no FIR in RFC 4585, but there
is PLI (roughly equivalent).  The payload values in question that could
conflict are RTPFB (205) and PSFB (206).

-- 
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)

---

From: Colin Perkins <[email-masked]>
Date: Sun, 5 Nov 2006 20:44:25 -0800

> conflict are RTPFB (205) and PSFB (206).

I'm not sure I understand the concern about either. It's easy to  
avoid conflicts with all current and previously assigned RTCP packet  
types, and doing so doesn't cut down the RTP payload type space  
significantly.

Colin