Subject: [MMUSIC] BUNDLE and DATA CHANNEL

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Apr 2013 14:19:48 +0000

[Was: [MMUSIC] Comment on Payload type restriction in draft-ietf-mmusic-sdp-bundle-negotiation-03]

Hi,

> - the draft doesn't currently talk at all about including the
>   m-line for the SCTP association for data channels in the bundle,
>   but people expect it. There is a special mechanism for demuxing
>   those packets from RTP. But that mechanism is limited to SCTP
>   over DTLS. And it is limited to a single SCTP association in the
>   bundle.

That is for sure text that needs to be added - assuming we have a WG decision that we are going to do it. Or, does someone think we only need to care about RTP (as far as BUNDLE is concerned) at this point?

>ISTM that there must be specification of:
>- the demux mechanisms that are available,
>- how they work,
>- how they do or don't coexist with one another,
>- and how they are signaled in SDP.
>
> The list of available demux mechanisms may need to be extensible.
> And the bundle mechanism should be designed to accommodate that.

Yes. Whenever someone wants to add a new transport to BUNDLE, he/she needs to describe how the multiplexing with other transports is done, i.e. fill out the bullet list above.

BUT, does that mean that we need a signalling mechanism where a BUNDLE client inform which demux mechanisms it supports?

        	Example: a=mux_transports: RTP, DTLS-SCTP

In future, someone may specify how to add MSRP to BUNDLE, and how to mux it with DTLS-SCRTP and RTP:

	Example: a=mux_transports: RTP, DTLS-SCTP, MSRP

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Apr 2013 13:52:06 -0400

> 	Example: a=mux_transports: RTP, DTLS-SCTP, MSRP

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

ISTM that there will need to be a spec (maybe just a small one) for each 
mechanism, that describes how it works and also how it is signaled.
How that is denoted isn't yet apparent to me. Its not even clear to me 
*where* in the SDP it needs to go. *Perhaps* it can be per-m-line, as 
long as there are clear rules for how the rules for different m-lines 
are coordinated in a bundle.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 25 Apr 2013 18:19:57 -0400 (EDT)

> From: Paul Kyzivat <[email-masked]>
> 

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.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Apr 2013 07:44:54 +0000

Hi,

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

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.

It is important to remember that, whatever you multiplex, all media have to use the same IP transport (e.g. UDP).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Apr 2013 11:27:46 -0400

On 4/25/13 6:19 PM, Dale R. Worley wrote:
> multiplexing mechanism.

We *could*. But I suspect it is a sub-optimal mechanism. It doesn't 
scale very well.

It appears that there can be multiple demux mechanisms in use within the 
same bundle. At least, there can be one for distinguishing data channel 
packets from RTP packets. And then some other mechanism for sorting out 
the RTP packets.

And it *may* make sense to use SSRC to demux some RTP, and the new RTP 
extension to sort out some others. (Whether these should coexist is TBD.)

So I suspect that the demux indication should be signaled per-m-line, 
with some rules for when/how the different mechanisms can coexist.

> One endpoint could probe the other to

This seems a good argument for not going this way!

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Apr 2013 12:58:58 -0400

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

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

There may be more than one stream per m-line, but I think we can assume 
that every stream binds to one m-line.

> 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, the lowest layer in the stack for each bundled m-line must be the 
same. There are more constraints than that. What comes to mind is:

- factor the protos of all the m-lines, forming nested groups
   that share some common lower layers.

- for each group that share some common lower layers,
   a demux algorithm is required that allows packets to be
   assigned to the appropriate member of that group.

- the above is applied recursively until packets have been assigned
   to a particular m-line.

For instance, consider the following:

        ...
        c=IN IP4 host.biloxi.com
        a=group:BUNDLE m1 m2 m3 m4
        m=audio 20000 RTP/SAVPF 0
        a=mid:m1
        a=ssrc:12345 cname:[email-masked]
        a=max-send-ssrc:{*:1}
        a=max-recv-ssrc:{*:1}
        ...
        m=video 20000 RTP/SAVPF 96 98
        a=mid:m2
        a=ssrc:5678 cname:[email-masked]
        a=max-send-ssrc:{*:1}
        a=max-recv-ssrc:{*:1}
        ...
        m=video 20000 RTP/SAVPF 96 98
        a=mid:m3
        a=max-send-ssrc:{*:4}
        a=max-recv-ssrc:{*:4}
        ...
        m=application 20000 DTLS/SCTP ...
        a=mid:m4
        ...

We have four bundled m-lines. We have one proto (RTP/SAVPF) in three 
m-lines, and another (DTLS/SCTP) in the other m-line. From a protocol 
layering perspective we have:

    m1      m2      m3      m4
    =====   =====   =====   ====
    SAVPF   SAVPF   SAVPF   SCTP
    RTP     RTP     RTP     DTLS
    UDP     UDP     UDP     UDP
    IP      IP      IP      IP

So, the first demux that must be done is to distinguish RTP from DTLS.
DTLS has been designed to have a field that distinguishes it from 
RTP/RTCP/ICE, so that can perhaps be considered a default demux 
algorithm for that.

Because there is only one SCTP m-line, that is enough to identify those 
packets that should be bound to m4. But we need to use something else to 
sort out the RTP.

In this example, payload type can be used to distinguish audio from 
video. But there may be cases where that isn't possible. If we want to 
allow this mechanism, then perhaps we need some way to signal that it 
should be used. Or *maybe* we could count on it being inferred. Assuming 
that is used, then it is sufficient to identify those packets that 
belong to m1.

Or, because m1 is marked as having at most one ssrc, and the ssrc value 
(1234) is specified, that could be used to bind packets to m1.

Similarly, RTP packets having ssrc=5678 can be bound to m2.

m3 supports multiple unspecified SSRCs. Since there is only one m-line 
that does, all the packets with pt 96 or 98 and with an ssrc other than 
1234 or 5678 can be bound to m3.

I'm undecided if we can count on inferring this decision logic from 
existing signaling options, or if we ought to signal the choices more 
explicitly.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Apr 2013 17:33:30 +0000

Hi,

> per-m-line, and specify the demux algorithm(s) for streams that bind to

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.

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.

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

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

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Apr 2013 16:27:51 -0400

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

> I will reply to the rest of your e-mail later, because I need a little more time to read it :)

OK.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Apr 2013 13:06:05 +0000

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:[email-masked]]
Sent: Friday, April 26, 2013 10:28 PM
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL

On 4/26/13 1:33 PM, Christer Holmberg wrote:
>>>>> (Unless there is only one possibility. And we have already
>>>>> disproved
>>>>> that.)
>>>>
>>>> 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.
>>>
>> per-m-line, and specify the demux algorithm(s) for streams that bind
>> to that m-line.
>

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

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

OK.

        Thanks,
        Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Apr 2013 14:44:18 +0000

Hi,

I need to correct 1).

The IP header Protocol value will of course only indicate UDP, NOT what is on top of that (RTP, SCTP, or something else...).

Regards,

Christer
________________________________________
From: [email-masked] [[email-masked]] on behalf of Christer Holmberg [[email-masked]]
Sent: Monday, 29 April 2013 4:06 PM
To: 'Paul Kyzivat'
Cc: [email-masked]
Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL

Hi,

Regards,

Christer

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

OK.

        Thanks,
        Paul