Re: [AVTCORE] Comments on draft-lennox-rtcweb-rtp-media-type-mux-00

[Harald Alvestrand <[e-mail]>]

(RTCWEB deleted from CC list, as per request)

On 11/07/2011 11:17 AM, Magnus Westerlund wrote:
> Hi,
>
> (as individual)
>
> I have reviewed draft-lennox-rtcweb-rtp-media-type-mux-00 and have some
> comments.
>
> I think this document is most appropriately discussed in AVTCORE as it
> concerns RTP details. Therefore both lists are cc:ed and reply-to set to
> AVTCORE WG mailing list. So if you are on RTCWEB and would like to
> follow this discussion, please follow the AVTCORE mailing list also
> ([e-mail]).
>
> 1. I think the biggest issue with multiple media type in a single RTP
> session isn't discussed. I think it is very important that this issue is
> brought up as it has to do with the applicability of this solution.
>
> To start the discussion on this issue I think a quote from section 4.3
> of draft-westerlund-avtcore-transport-multiplexing-01 is appropriate:
>
>     Many transition scenarios use an RTP translator as a gateway between
>     a single RTP session containing multiple media types multiplexed
>     together, and several separate RTP sessions each using a single media
>     type.  In this scenario, it is possible that a legacy device that
>     uses one RTP session for each media type will use the same SSRC in
>     each session.  When translating these into a single RTP session, it
>     will be necessary to rewrite one of the SSRCs, so that each stream
>     has a unique SSRC.  This SSRC translation process is straight-forward
>     for RTP packets, but is very complex for RTCP packets.  It also
>     hinders innovation, since such a gateway will not be able to
>     translate new RTCP extensions that it is unaware of, even if they are
>     supported by devices on both sides of the gateway.
>
> The issue is that in any case where you have a desire to mix end-points
> supporting this and where some don't you create a situation where you
> will either get malfunctioning translators or translators that likely
> are a barrier for deploying new RTP/RTCP extensions.
Magnus,

why would such a gateway want to offer the BUNDLE extension in its SDP 
negotiation?
(I'm assuming support for draft-holmberg-mmusic-sdp-bundle-negotiation 
as the way to negotiate multiple media types in a single session here.)

An assumption in the deployment of extensions is that one is able to 
negotiate their non-use where some participant does not support the 
feature. I find your arguments compelling if (and only if) I accept the 
premises that:

1) Gateways between RTCWEB deployments and non-RTCWEB deployments will 
want to relay RTP sessions rather than terminate them (something which I 
do not believe, but that's another debate)

2) Gateways between RTCWEB deployments and non-RTCWEB deployments can't 
negotiatiate non-support for the BUNDLE extension with the RTCWEB deployment

Given that I believe 2) is false, I don't agree with your conclusion.

Some details below.
> Even in WebRTC contexts the case combing the single session and multiple
> sessions are likely to occur. One case is media plane gateways to legacy
> that will negotiate the multiplexing between the WebRTC end-point and
> the gateway and then attempt to perform basic splitting to two RTP
> sessions on the legacy side based on the payload formats. Another
> scenario is the centralized conferences where the RTP mixer or
> translator can negotiate individual behavior to each end-point. Thus one
> might start out fine with all being single session compliant. Then
> someone joins who is not and the result is that one is in a situation
> that either requires renegotiation (including NAT traversal) for the
> already connected end-points or to do a translator. I am certain that
> translator is going to be the approach rather than interrupting the
> ongoing media streams.
The 3 viable approaches I see for gateways are:

- The gateway refuses to negotiate BUNDLE with anyone
- The gateway terminates RTP sessions
- The gateway refuses to establish non-BUNDLE sessions at all

In neither of these 3 scenarios do I see the issue you posit.