Re: [MMUSIC] BUNDLE and DATA CHANNEL

[Christer Holmberg <[e-mail]>]

Hi,

I think we can separate this into 3 questions:

1) How is a receiver able to demux transport flows associated with different "transport flow usages" (here I consider RTP one usage, the data channel another, etc).

Now, the general first step is of course to separate based on the IP header Protocol value.

But, of course, if you have multiple flows with the same usage (e.g. multiple RTP flows), that it is not enough.

Also, if you have SCTP on top of UDP (as in our case for the data channel), you need to go up on the SCTP level in order to figure out what it is used for.


2) How is a receiver able to associated a transport flow with its associated SDP m- line.

This becomes an issue when multiple m- lines are associated with the same transport flow usage, e.g. when you have multiple m- lines for RTP.


3) How is a receiver able to, within an m- line, identify a media flow.

This becomes an issue e.g. when multiple RTP flows are associated with a single m- line. But, as I said before, this is not a BUNDLE specific problem.


Regarding 2) and 3), the most common solutions that have been discussed are usage of PAYLOAD and/or SSRC. As we know, people have expressed concern about using PAYLOAD, due to the limited number of PT values available.

Regards,

Christer








-----Original Message-----
From: Paul Kyzivat [mailto:[e-mail]]
Sent: Friday, April 26, 2013 10:28 PM
To: Christer Holmberg
Cc: [e-mail]
Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL

On 4/26/13 1:33 PM, Christer Holmberg wrote:
>
> Hi,
>
>>>>> Yes - we need a way to signal the demux mechanism to be used.
>>>>> (Unless there is only one possibility. And we have already
>>>>> disproved
>>>>> that.)
>>>>
>>>> We could use different group "semantics" values to indicate the
>>>> multiplexing mechanism.  One endpoint could probe the other to
>>>> discover which mechanisms it supplies by offering a collection of bundles containing no constituents, one for each mechanism.  The answer will show which mechanisms the answerer supports.
>>>
>>> My idea was the endpoint simply lists the media description proto values that it is capable of multiplexing for a given 5-tuple:
>>>
>>>        Example: a=muxcap: RTP/AVP, SCTP/DTLS
>>>
>>> ...or something like that.
>>
>> That is sufficient *if* there is a single mux/demux algorithm per proto.
>>
>> But I don't think that is true. I think we will need to signal this
>> per-m-line, and specify the demux algorithm(s) for streams that bind
>> to that m-line.
>
> I don't it matters if there are multiple algorithms - the important thing is that the endpoint is able to mux/demux the specific proto using A algorithm.
>
> Otherwise, we can have different values, one for each algorithm. Note that in my example I used to SDP proto values, but we could use whatever.

My point is that both sides need to *agree* on what mechanism is used to mux/demux the streams - in order to associate each received packet with the correct m-line.

So simply declaring "I can mux RTP/SAVP and DTLS/SCTP" is not sufficient without saying *how* it will be done. (Except in cases where there is a mutual understanding that there is only one way, or a default way.)

> HOWEVER, before we go into the details, I would like to know whether people generally think we need a mechanism which allows to list the protos an endpoint is able to mux/demux.
>
>>> Of course, an endpoint needs to be able to multiplex all media that it inserts in a bundle group. But, it may not always insert m- lines for everything it is able to multiplex, so I think an explicit indication would be good.
>>
>> There may be more than one stream per m-line, but I think we can assume that every stream binds to one m-line.
>
> I am not sure I understand what you mean by "binds to one m-line".
>
> However, keep in mind there can be multiple streams per m- line
> already today (at least for RTP), so it's not something BUNDLE
> specific :)

My point is that the *goal* of this exercise is to be able to associate each incoming packet with exactly one of the bundled m-lines.
So there must be an unambiguous mapping that does that - "binds" each packet to the m-line it belongs with.

>>> It is important to remember that, whatever you multiplex, all media have to use the same IP transport (e.g. UDP).
>>
>> Unfortunately SDP has a pretty confusing idea of "transport".
>> The proto field identifies a whole stack of protocol layers.
>
> Yes, and therefor, when we say "must use the same protocol", we need
> to make it clear that we refer to the Protocol value in the IP header
> - not the proto value in the SDP media description :)
>
> I will reply to the rest of your e-mail later, because I need a little
> more time to read it :)

OK.

        Thanks,
        Paul