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

Gunnar Hellstrom <gunnar.hellstrom at omnitor.se> writes:
>Thanks for a good initiative and a good draft.
>It seems to cover part of the need for multiplexing in a good way.
>
>But, I suggest that you in the abstract and early in the text describe to
>what extent you solve the multiplexing problem.
>
>I read it with the initial hope that you proposed a method to multiplex all
>RTP and RTCP streams in e.g. a SIP session onto one UDP port.
>
>I had to read it all through down below the sdp example, before I could
>conclude that the method does not cover the problems that would occur if you
>want to multiplex all media in a session onto the same port.

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.

>In multimedia applications, it is a similar burden to handle all media rtp
>streams through NAT.
>
>By this draft you cover half of the problem - the RTP-RTCP multiplexing
>belonging to one RTP session, but not how to multiplex all RTP sessions with
>its RTCP. Please indicate that early in the draft with wording that not
>forbids solving the other half of the problem.

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

The other option to consider is a more explicit multiplexing as Gunnar is
mentioning (sub-ports if you will) to minimize the number of holes that
need to be punched and tested, especially when ICE is involved.  A protocol
that uses (say) 3 streams in each direction needs 6 incoming ports tested
and punched open.  With a full multiplex layer for RTP, you'd only need 1
port.

In Message-ID: <ybuu098lwq9.fsf at jesup.eng.wgate.com> sent on April 4, 2006
to avt at ietf, Colin, etc, I suggested signalling a multiplex layer at the
connection level.  I quote:


| the canonical way to achieve this to be define a multiplexing
| protocol for datagrams, and specify this as part of a c= line in the
| SDP.  This would change the "port" value from the media line into a "stream
| ID" on the multiplex.  Something like:
| 
| c=IN IP4/PLEX 23.45.67.89 1234
| m=audio 2 RTP/AVP 0
| m=video 4 RTP/AVP 99
| a=rtpmap:99 H999/90000
| 
| That would put audio on multiplex "ports" 2 & 3, and video on 4 & 5.
| All data would be sent to 23.45.67.89 port 1234.
| 
| This is more overhead than if it were designed into RTP - but it can be
| used for any protocol, not just RTP.
| 
| Packet data could be something like:
| [short plex_port]
| [datagram]
| 
| Yes, this causes an MTU size drop, which is an issue for some.  This would
| need to be handled at the sending end.  Perhaps (maybe) you could consider
| optimizing this for the "common" case of "same as last packet", but you
| still need at least a bit, and more likely a byte.  Probably better to
| stick to two.
| 
| There would be no attempt to deal with duplication, ordering, timing or any
| other issue at this layer.  KISS.  That's the job of the application these
| datagrams get fed to.
| 
| If you do need to get fancier, you can add fragmentation, etc, but it gets
| ugly fast, and starts approaching the complexity/overhead of UDP.

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