RE: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt- multiplexing to what extent

["Hadriel Kaplan" <HKaplan at acmepacket.com>]

Hey Randell,
Comments inline...

> -----Original Message-----
> From: Randell Jesup [mailto:rjesup at wgate.com]
> Sent: Monday, September 11, 2006 3:15 PM
> To: Gunnar Hellstrom
> Cc: Colin Perkins; AVT WG
> Subject: Re: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-
> 00.txt- multiplexing to what extent
> 
> Another issue that at least should be mentioned is that it can fail if any
> proxy doesn't support a=rtcp: and that proxy changes the RTP port.
> Changing the RTP port is frequently (normally) done by ALGs and SBCs, and
> not all of them support a=rtcp: - and if they do support it, the traffic
> caused by this draft might mess them up.  I will concede that lack of
> a=rtcp support by an SBC, ALG, rtp-relay, etc would also break regular
> RTCP - but these are important issues for this draft and for users of it.

I think this draft handles that: if the answer does not have an a=rtcp
matching the m= udp port, then the offer must fail and the offerer must
retry it without muxing.  So an offer/answer using this draft through an
ALG/FW which did not support rfc3605 would probably fail, with a very high
probability, and re-signal.  It is then just as good/bad as 3605, or the
offerer could just not use a=rtcp at all at that point; i.e., it's no worse
than before.  


> This draft relies on a "tricky" use of a=rtcp as implicit signalling, and
> to in some cases trick implementations that predate this draft into using
> the same port for RTP and RTCP (assuming that they already support a=rtcp,
> which many do not).
> Explicit signalling would restrict it to implementations that know about
> this draft, but would avoid problems with a=rtcp implementation (see above
> about SBCs, etc).

I was going to comment originally that this draft could use explicit
signaling instead of overloading a=rtcp; though I think it's a
graceful/clever reuse of a=rtcp.  But it occurs to me it's just as likely
you hit a FW/SBC that doesn't allow non-conforming PT's in the stream, and
you have as bad a problem.  In that case it would have been better to fail
the offer, as this draft would do.  IOW, damned if you do, damned if you
don't.  

Perhaps what this draft should say is if the answer still used a=rtcp but
with mismatching udp port to the answer's m= line, that the offerer may
consider retrying without muxing AND without using RFC 3605 at all, because
the odds are something in the middle's mucking with SDP and doesn't
understand a=rtcp?

-hadriel



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