Re: [MMUSIC] BUNDLE and DATA CHANNEL and SHIM

[Magnus Westerlund <[e-mail]>]

On 2013-04-30 01:03, Martin Thomson wrote:
> On 29 April 2013 12:41, Paul Kyzivat <[e-mail]> wrote:
>> One more thing - a question for all:
>>
>> Do you agree that there is a need to support more than one way to demux RTP,
>> and hence a need to signal what way is to be used?
>>
>> Or do you think we will be able to reach agreement on a single algorithm, so
>> that signaling of the algorithm isn't required?
> 
> There is agreement in avtcore to build two demux schemes.  The need to
> signal the choice of demux scheme has already been made for us.
> 
> Yes, we could define BUNDLE to mean "demux by SSRC (and maybe PT (oh
> and protocol if you've got this DTLS thingy))" and then have a
> SHIMBUNDLE grouping.  That would be actively antisocial.

Can you please clarify why you think this is anti-social?

I would like to point out that BUNDLE and SHIM operates at different
levels. To my understanding BUNDLE is a way of using multiple media
descriptions (m= lines) to describe one RTP session.

SHIM is an explicit layer for transmitting multiple independent RTP
session on the same lower layer transport. Each RTP session will be
described using its own signaling, which could include BUNDLE of
multiple m= lines.

The transmission of DTLS/SCTP over the same UDP flow as an RTP session
is yet another problem of who shares the lower layer transport.

A number of RTP sessions over SHIM will be able to share the lower layer
transport (UDP) with DTLS/SCTP, more from the perspective that it must
be able to share it with DTLS and STUN to make ICE and DTLS-SRTP work
than anything else.

Colin Perkins and I did privately discuss ways of signalling the SHIM
solution in Orlando and put together a strawman. I can share it here to
see what input you have.

1) We would have one m= line to describe the SHIM's transport itself, i.e.
m=application 12345 UDP/SHIM *
a=candidate ...

2) Each RTP session would be described normally with or without bundle.
Although we prefer to avoid BUNDLE, but that would depend on the rest of
discussion on what recommendation for multiple m= lines description of
one RTP session means.

The port numbers on the m= lines would be used as SHIM IDs. They anyway
have to be unique for fallback if BUNDLE is not supported.

3) The media descriptions involved in one SHIM will for clarity be
indicated using a SHIM specific grouping semantics.

4) If SHIM is supported as determined by first round, the media
descriptions can be cleaned up and any unnecessary transport information
can be removed in second round to verify that middleboxes don't
misunderstand that SHIM is being used and that is the only main
transport parameters for the streams put on that SHIM.

This proposal is intentionally not requiring BUNDLE because we want to
enable the fallback from SHIM to Individual sessions over different
transports if SHIM is not supported. If BUNDLE would be included then
then choice of fallback from SHIM might become BUNDLE, which in most
cases is not desired. You are using SHIM because you want different RTP
sessions, not have everything put into one RTP Session.

Sorry if I missed something important in earlier discussions. I am still
catching up on MMUSIC and I haven't managed to read it linearly.

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