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

[Randell Jesup <rjesup at wgate.com>]

"Hadriel Kaplan" <HKaplan at acmepacket.com> writes:
>> 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.

That could still confuse an existing app.  And the offer doesn't "fail",
the offer has been accepted; you're talking about re-INVITEing/UPDATEing
the offer after it's been accepted but with values that won't work
correctly.  This could cause problems until the call is re-established
without that.  And it may be more delayed if this means another pass of ICE
(this time for more ports).

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

The reason I say it wouldn't fail is:
Offer:
  m=audio 1234 ....
  a=rtcp:1234

Munged offer:
  m=audio 5678 ....
  a=rtcp:1234

Answer (200 OK):
  m=audio 9876 ...
The answerer assumes that rtp goes to 5678 and rtcp goes to 1234.
The offerer will need to re-INVITE (and perhaps re-STUN/ICE/TURN/etc).
And RTCP will be lost for a while at call startup (at minimum).

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

non-conforming PT's?  Perhaps you mean attributes.  I'm more willing to
deal with that sort of failure, and I think it will generally have less
effect on the call setup (it will fail before getting to the dest, and
in theory the caller could then retry).  But a gateway that rejects invites
with attributes it doesn't understand is quickly going to be a problem for
EVERY protocol and draft, unless we hide every addition and extension in 
the few attributes it passes through.  

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

You could (though include the no "a=rtcp" case there too).  But I think
overall there are too many bandaids here.  I'd recommend at least moving
away from the attempt to overload a=rtcp; there's too much chance of
breaking some ALG/SBC/UA that understands 3605 but not this (plus the
issues above).  It's cute, but I think the potential pain isn't worth it.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com


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