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

[Magnus Westerlund <[e-mail]>]

Harald,

Inline

On 2011-11-07 11:37, Harald Alvestrand wrote:

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

I will follow up one below. But regarding 2) that is not the reason. 
Even if one can negotiate that the one bundles multiple media types in a 
single RTP session, there is going to be gateways/conference nodes that 
are going to turn on this feature anyway.

The reason for that behavior is that they will think this issue is a 
non-issue. Short term thinking rather than long term implications. They 
will like to avoid the small but existing risk of establishing more NAT 
pinholes. Also, to be certain that this not occurs, you either have zero 
possibility to use the non bundled session to a central node, or you 
configure your central node to never use bundling to avoid this. I think 
more than one developer will look at this and ignore the issue. Because 
if you don't think it through it do look simple on the surface. You 
simply translate the SSRCs if you end up in a collision.

When it comes to using a common session. I agree that for media mixing 
central nodes (RTP mixer), the RTP session is anyway almost individual 
between each end-point and end-point. The only information you forward 
between the legs are the CSRC CNAMEs to ensure the possibility to bind 
the information to the right sources.

But, when looking at the cheapest central node solution, the transport 
relay (transport translator) the common RTP session becomes interesting 
as it limits the central nodes processing to bascially a packet 
forwarder. This gives you on the order of 1000 times higher capacity in 
the number of streams the central node can handle compared to one that 
performs media operations given the same general purpose hardware. Thus 
having a common RTP session and not having to change anything within the 
packets, not even having to perform decryption and encryption cycles in 
the relay is a big bonus.


> 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.
>
>
Agreed, these do avoid the issue of having to translate. From my 
perspective, they should be documented and considered if they will be 
followed.

Raising this issue had two goals.

1) Ensure that the issue and the implications on what one need to do is 
clearly documented in the draft.

2) Raise discussion if those are acceptable

So I hope the authors at least will agree to perform 1). Regarding the 
outcome of 2) that is very much open.

When it comes to 2) I think we need to take into account the 
alternative. Is any of the evaluated alternatives in 
https://datatracker.ietf.org/doc/draft-westerlund-avtcore-transport-multiplexing/ 
actually less problematic?

And I think it is important we do consider what happens when WebRTC is 
successful. I fear the desire to interoperate will kill of the RTP 
session completely as a useful tool. Instead all RTP users will end up 
with a single RTP session and we have to re-invent mechanisms for 
separation when the short-coming of not having an layer of multiplexing 
for media stream purposes.

I know that the window for this is closing, but I think we should at 
least have some reconsideration if the direction proposed in Quebec 
really was the most appropriate.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------