Subject: [MMUSIC] BUNDLE: RTP only?

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Feb 2013 19:48:23 +0000

(Sorry for sending this to both RTCWEB and MMUSIC, but it is related to both the need of RTCWEB, and the solution produced by MMUSIC)

Hi,

At the interim, during my BUNDLE presentation, I indicated that we need to make a decision whether the solution (whatever it will be...) shall support bundling of non-RTP media. Not saying it can't be changed, but as currently documented all alternatives only support bundling of RTP media.

There might have been some comments from the mic, but as far as I know there was no decision (if there was, please point me to it).

So, my question is: do we keep the scope to RTP media?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Feb 2013 15:06:01 -0500

> So, my question is: do we keep the scope to RTP media?

*If* there is a goal to share a single 5-tuple between RTP and SCTP then 
we need a solution allows bundling them.

The key to what you can bundle together is not whether it is RTP or not. 
It is whether you can specify the mechanism for demuxing the 5-tuple and 
associated the parts with the appropriate m-line in the bundle.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Feb 2013 20:08:05 +0000

Hi,

> we need a solution allows bundling them.

That's another way of presenting my question, yes :)

> associated the parts with the appropriate m-line in the bundle.

Yes, and the question is whether we need to perform the exercise to look into that, or if we focus on RTP.

Regards,

Christer

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 13 Feb 2013 20:37:42 +0000

I think EKR expressed that he felt it was important for data channel to be included in the multiplexing. 

On Feb 13, 2013, at 12:48 PM, Christer Holmberg <[email-masked]> wrote:

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Randell Jesup <[email-masked]>
Date: Wed, 13 Feb 2013 15:42:31 -0500

> I think EKR expressed that he felt it was important for data channel to be included in the multiplexing.

And I agree(d), strongly.  We want 1 port to minimize NAT issues and 
startup times.

-- 
Randell Jesup
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Feb 2013 13:48:30 -0800

I would phrase this somewhat less strongly: less ports is better than more
ports,
so all things being equal, a multiplexing mechanism that keeps you down to
one port is better than not. That said, if we decide that plan A is dead and
we are going to plan B, I can live with having data on a separate port.

-Ekr

On Wed, Feb 13, 2013 at 12:42 PM, Randell Jesup <[email-masked]>wrote:

>> At the interim, during my BUNDLE presentation, I indicated that we need
>> to make a decision whether the solution (whatever it will be...) shall
>> support bundling of non-RTP media. Not saying it can't be changed, but as
>> currently documented all alternatives only support bundling of RTP media.
>>
>> There might have been some comments from the mic, but as far as I know
>> there was no decision (if there was, please point me to it).
>>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Feb 2013 14:24:00 -0800

A question: 

Since we have a clear way of de-multiplexing RTP and DTLS, is it necessary to entangle that (solved) problem with the A/V mux issue? I realize that SDP has the tendency to "deeply intermingle" just about everything, but at the RTP/DTLS level, we're in much better shape.

Bernard "Do we need to boil the entire ocean, or just a lake or two?" Aboba

On Feb 13, 2013, at 13:49, "Eric Rescorla" <[email-masked]> wrote:

> I would phrase this somewhat less strongly: less ports is better than more ports,
> On Wed, Feb 13, 2013 at 12:42 PM, Randell Jesup <[email-masked]> wrote:
>> And I agree(d), strongly.  We want 1 port to minimize NAT issues and startup times.
>> 
>> 
>>> 
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Feb 2013 22:15:23 -0500

> Yes, and the question is whether we need to perform the exercise to look into that, or if we focus on RTP.

We know how to do the demux between DTLS payloads, ICE, and RTP/SRTP 
payloads. And if we restrict to RTP/SRTP and SCTP over DTLS, then we 
know how to demux RTP and SCTP.

There are various schemes that can be used to demux multiple RTP streams 
and associate them with individual m-lines in the bundle.

What troubles me about it is that the rules for what you can bundle 
together are dependent on the demux strategy. Describing the rules for 
this as part of the specification of the bundling mechanism is going to 
be pretty ugly. I don't see any way to make it clean and elegant.

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 14 Feb 2013 09:24:36 +0100

RTCWEB has a requirement (or rather: it has assumed that there was a 
solution) for signalling over SDP that SCTP/DTLS/UDP is sent over the 
same port pair as SRTP.

If BUNDLE is not going to be that solution, we have to start designing 
another.

On 02/14/2013 04:15 AM, Paul Kyzivat wrote:
>>>> (Sorry for sending this to both RTCWEB and MMUSIC, but it is 
>>>> related to both the need of RTCWEB, and the solution produced by 
>>>> MMUSIC)
>>>>
>>>> Hi,
>>>>
>>>> At the interim, during my BUNDLE presentation, I indicated that we 
>>>> need to make a decision whether the solution (whatever it will 
>>>> be...) shall support bundling of non-RTP media. Not saying it can't 
>>>> be changed, but as currently documented all alternatives only 
>>>> support bundling of RTP media.
>>>>
>>>> There might have been some comments from the mic, but as far as I 
>>>> know there was no decision (if there was, please point me to it).
>>>>
> There are various schemes that can be used to demux multiple RTP 
> streams and associate them with individual m-lines in the bundle.
>
> this as part of the specification of the bundling mechanism is going 
> to be pretty ugly. I don't see any way to make it clean and elegant.
>
>     Thanks,
>     Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Feb 2013 13:14:26 -0500

Harald,

> If BUNDLE is not going to be that solution, we have to start designing

Yes, I know. But nobody has made a proposal that actually encompasses 
that desire. I think we have turned over a rock and found a large can of 
worms.

There is a deep connection here between the mechanisms used to demux 
packets into separate logical "flows" and the SDP notations used to 
describe those flows.

SDP was designed to describe flows that are demuxed by 3-tuple - 
incoming transport type, address, and port. SDP O/A extended that to 
describe symmetric pairs of such flows. Restriction to symmetry of 
send/recv address/port potentially extends that to demux by 5-tuple. But 
we are already on fuzzy ground of SDP expressiveness by that time.

Now we want to extend that expressiveness to further levels and criteria 
for demuxing. The bundle *syntax* lets us describe the things we want to 
demux, but without any explicit indication of what demux algorithm to 
apply. The existing bundle proposal applies some restrictions on what 
can be bundled - presumably to limit it what can be demuxed - but 
doesn't explicitly say how to demux. (There are restrictions on use of 
payload types across m-lines that suggest an expectation that demux is 
to be done based on payload type.) The restrictions it imposes don't 
permit bundling RTP and SCTP.

Unless we want to devolve into a Do What I Mean situation, we need to 
find a way to explicitly say what we mean.

A good start would be to first be *specific* (and exhaustive) about what 
we would like to multiplex (without regard to how we will notate that), 
and how we propose to mux/demux it.

There is info out there on how to mux/demux UDP/TLS/RTP/SAVP and 
DTLS/SCTP over the same DTLS connection. (Though it isn't immediately 
obvious where that is specified.)

Presumably the goal for RTCWEB is to demux distinct MediaStreamTracks 
from a single UDP/TLS/RTP/SAVP session. I doubt we want to do that by 
payload type. Based on discussion last week, this may sometimes be done 
by SSRC, but I think we had cases when multiple SSRCs might map to the 
same track, and the mappings may not always be known in advance. CLUE 
has further needs, where an SSRC may move about from one 
"capture-encoding" to another. (A clue capture-encoding is, I think, 
more or less equivalent to an RTCWEB track.)

So I think we need a serious discussion of mux/demux 
criteria/algorithms. This seems to be a prerequisite to a solution to 
the bundling problem in MMUSIC. But MMUSIC may not be the proper wg for 
this discussion. I don't know which one is.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Feb 2013 10:34:08 -0800

On 13 February 2013 19:15, Paul Kyzivat <[email-masked]> wrote:
> What troubles me about it is that the rules for what you can bundle together
> are dependent on the demux strategy. Describing the rules for this as part
> of the specification of the bundling mechanism is going to be pretty ugly. I
> don't see any way to make it clean and elegant.

I didn't see this as a deal-breaker.  You could think of it as: "if
you can demux these things, then it is valid to multiplex them".
Don't bother saying anything more than that.

As Bernard observes, it's the RTP demux that is hard.  Solve that and
let the rest sort themselves out.  Sure, you might not be able to
demux protocol MEAT and protocol CHEESE, but that's an easy solve -
don't try to multiplex them.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Feb 2013 13:55:28 -0500

> don't try to multiplex them.

I agree we don't need an algorithm to demux anything from anything.

But we do need a specified way to look at the SDP and know what the 
mux/demux algorithm is. The rule for bundling should make that a 
prerequisite for any given bundle.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 14 Feb 2013 14:53:22 -0500 (EST)

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

Do any of the current proposed bundling techniques include both RTP
and SCTP?

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Feb 2013 20:13:37 +0000

Hi Dale,

I see no reason why BUNDLE couldn't be used also for non-RTP. We would need to consider it when we study the study the SDP attribute impact, though, but that exercise we have to do for RTP anyway.

For MMT it is more tricky. As it only uses a single m= line for the whole bundle, we would need to define a new "MMT" proto value for that m= line (currently the draft uses RTP). Then we would need to, inside the m= line, define a way to specify the proto value for each individual media.

Regards,

Christer
________________________________________
From: [email-masked] [[email-masked]] on behalf of Dale R. Worley [[email-masked]]
Sent: Thursday, 14 February 2013 9:53 PM
To: [email-masked]
Subject: Re: [MMUSIC] BUNDLE: RTP only?

Dale

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 14 Feb 2013 13:10:50 -0800

On Feb 14, 2013, at 10:14 AM, Paul Kyzivat <[email-masked]> wrote:
>> 
> 
> Yes, I know. But nobody has made a proposal that actually encompasses that desire. I think we have turned over a rock and found a large can of worms.
> 
> There is a deep connection here between the mechanisms used to demux packets into separate logical "flows" and the SDP notations used to describe those flows.
> 
> SDP was designed to describe flows that are demuxed by 3-tuple - incoming transport type, address, and port. SDP O/A extended that to describe symmetric pairs of such flows. Restriction to symmetry of send/recv address/port potentially extends that to demux by 5-tuple. But we are already on fuzzy ground of SDP expressiveness by that time.
> 
> Now we want to extend that expressiveness to further levels and criteria for demuxing. The bundle *syntax* lets us describe the things we want to demux, but without any explicit indication of what demux algorithm to apply. The existing bundle proposal applies some restrictions on what can be bundled - presumably to limit it what can be demuxed - but doesn't explicitly say how to demux. (There are restrictions on use of payload types across m-lines that suggest an expectation that demux is to be done based on payload type.) The restrictions it imposes don't permit bundling RTP and SCTP.
> 
> Unless we want to devolve into a Do What I Mean situation, we need to find a way to explicitly say what we mean.
> 

Yes, and *only* because RTCWEB turned over the rock *and* continues to insist that SDP be the way for the developers to "explicitly say what we mean" are we here in MMUSIC with a big can of worms and some urgency around coming up with any solution, no matter how ugly.

There are better ways to construct an API with which developers could tell the browser what they want it to do, and then MMUSIC could work on carefully standardizing only what is needed for interworking cases.

Matthew Kaufman

(Sent from my iPhone)

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Feb 2013 13:40:30 -0800

> prerequisite for any given bundle.

That's only necessary if there is a choice of algorithm.  As long as
you know that you are doing protocol DUCK and protocol GOOSE somehow -
and it matters not how, for now - then the DUCK/GOOSE multiplexing
rules apply.

Where the multiplexed things appear on multiple m= lines, seeing the
protocol labels should suffice.  As Christer notes, the same applies
if you go with the one m= line for all, you still need a way to say
that you want to do SCTP over DTLS somewhere, presumably using the
same sort of label you would use for multiple m= lines.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 14 Feb 2013 13:56:12 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Thursday, February 14, 2013 10:14 AM
> To: [email-masked]

http://tools.ietf.org/html/rfc5764 explains how to demux RTP (and SRTP),
DTLS, and STUN:

                   +----------------+
                   | 127 < B < 192 -+--> forward to RTP
                   |                |
       packet -->  |  19 < B < 64  -+--> forward to DTLS
                   |                |
                   |       B < 2   -+--> forward to STUN
                   +----------------+

To that, I believe we want to consider SCTP-over-UDP, which I believe
was going to be protected with DTLS.  So, that looks like this, where
DTLS demuxes and processes DTLS handshakes itself and decrypts encrypted
payloads and sends them to SCTP.

            +----------------+
            | 127 < B < 192 -+--> forward to RTP     
            |                |                      /SCTP
packet -->  |  19 < B < 64  -+--> forward to DTLS -<
            |                |                      \DTLS handshake
            |       B < 2   -+--> forward to STUN
            +----------------+

-d

> has further needs, where an SSRC may move about from one "capture-
> encoding" to another. (A clue capture-encoding is, I think, more or less
> equivalent to an RTCWEB track.)
> 
> >>>>> be...) shall support bundling of non-RTP media. Not saying it
> >>>>> can't be changed, but as currently documented all alternatives
> >>>>> only support bundling of RTP media.
> >>>>>
> >>>> *If* there is a goal to share a single 5-tuple between RTP and SCTP
> >>>> then we need a solution allows bundling them.
> >>>
> >>>> It is whether you can specify the mechanism for demuxing the
> >>>> 5-tuple and associated the parts with the appropriate m-line in the
> >>>> bundle.
> >>>
> >> together are dependent on the demux strategy. Describing the rules
> >> for this as part of the specification of the bundling mechanism is
> >> going to be pretty ugly. I don't see any way to make it clean and
> elegant.
> >>
> >>     Thanks,
> >>     Paul
> >>

---

From: John Leslie <[email-masked]>
Date: Thu, 14 Feb 2013 17:25:05 -0500

>>> solution) for signalling over SDP that SCTP/DTLS/UDP is sent over the

   (This sentence confuses me, but that's not the point...)

>>> If BUNDLE is not going to be that solution, we have to start designing

   Harald posted to MMUSIC and not RTCWEB. I'm not sure I agree that
MMUSIC has to start designing that...

>> that desire. I think we have turned over a rock and found a large can
>> of worms.

   In my career, I have encountered many cans of worms. I take them as a
signal that my assumptions may have been faulty.

>> packets into separate logical "flows" and the SDP notations used to

   (Thus, trying to change either threatens to reveal worms...)

>> send/recv address/port potentially extends that to demux by 5-tuple.
>> But we are already on fuzzy ground of SDP expressiveness by that time.

   Is it possibly time to stop digging?

>> Now we want to extend that expressiveness to further levels and
>> criteria for demuxing. The bundle *syntax* lets us describe the
>> things we want to demux, but without any explicit indication of
>> what demux algorithm to apply.

   Am I imagining it, or is the ground starting to shake?

>> The existing bundle proposal applies some restrictions on what can
>> be bundled - presumably to limit it what can be demuxed - but
>> doesn't explicitly say how to demux. (There are restrictions on
>> use of payload types across m-lines that suggest an expectation
>> that demux is to be done based on payload type.) The restrictions
>> it imposes don't permit bundling RTP and SCTP.

   ISTM that the existing "bundle" isn't a good way to relate RTP
and SCTP...

>> Unless we want to devolve into a Do What I Mean situation,

   PLEASE NO!!!

>> we need to find a way to explicitly say what we mean.

   Again, Paul posted to MMUSIC and not RTCWEB. Again, I'm not sure
I agree that MMUSIC needs to design that.

> Yes, and *only* because RTCWEB turned over the rock *and* continues
> to insist that SDP be the way for the developers to "explicitly say
> what we mean" are we here in MMUSIC with a big can of worms and some
> urgency around coming up with any solution, no matter how ugly.
> 
> There are better ways to construct an API with which developers
> could tell the browser what they want it to do, and then MMUSIC
> could work on carefully standardizing only what is needed for
> interworking cases.

   Perhaps MMUSIC needs to learn how to say "No" to RTCWEB...

   In an ideal world, MMUSIC would have already designed what RTCWEB
wants. But revisiting basic principles tends to be dangerous and
lead to delays. RTCWEB has good folks who could design a way to do
what they want without needing MMUSIC to revisit its basic design.

   IMHO... YMMV...

--
John Leslie <[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 Feb 2013 14:45:50 -0800

I had always assumed that bundle/fumble, etc. (I.e., anything under Cullen's
Plan A) would potentially mux all m-lines together. I assumed that Plan B
(multiple flows per m-line) would not.

-Ekr

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Feb 2013 17:51:33 -0500

> I see no reason why BUNDLE couldn't be used also for non-RTP. We would need to consider it when we study the study the SDP attribute impact, though, but that exercise we have to do for RTP anyway.

Again this is all to do with how you do the demux.
E.g. if you bundled multiple m-lines with a UDP proto then it isn't 
clear how you could demux them.

	Thanks,
	Paul

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 14 Feb 2013 14:52:20 -0800

Ekr said: 

"I had always assumed that bundle/fumble, etc. (I.e., anything under
Cullen's

(multiple flows per m-line) would not.'

[BA] Plan B multiplexes multiple SSRCs of the same media type (single m
line)  on the same transport address.   Plan A additionally allows for
multiplexing of different media types (multiple m lines).  So I don't see
them as really competing (e.g. it's possible to want to multiplex multiple
SSRCs from multiple media types on the same transport address).

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Feb 2013 18:13:20 -0500

> and it matters not how, for now - then the DUCK/GOOSE multiplexing

If DUCK and GOOSE are identified in the SDP, and its not necessary to 
have any other context than that SDP to discover the DUCK/GOOSE 
multiplexing rules, then I agree with you.

(I realize that RTCWEB has another channel that can be used for 
anything. But depending on that to resolve this would render it 
inapplicable environments like SIP where the SDP is the only likely 
place to convey that information. I gather you are not suggesting going 
that way.)

> same sort of label you would use for multiple m= lines.

The protocol labels should suffice *if* there is some sort of standard 
or registry that provides a mapping from "bundled protos" to 
"multiplexing rules".

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Feb 2013 18:21:45 -0500

> http://tools.ietf.org/html/rfc5764 explains how to demux RTP (and SRTP),

Thanks for the reference.

That still leaves unspecified how to demux the RTP relative to the 
bundled RTP m-lines.

ISTM we are going to need a draft that discusses this. I don't know what 
WG that belongs in.

	Thanks,
	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 14 Feb 2013 15:30:23 -0800

On Thu, Feb 14, 2013 at 2:52 PM, Bernard Aboba <[email-masked]>wrote:

> Ekr said: ****
>
> ** **
>
> “I had always assumed that bundle/fumble, etc. (I.e., anything under
> Cullen's****
>
> Plan A) would potentially mux all m-lines together. I assumed that Plan B*
> ***
>
> (multiple flows per m-line) would not.’****
>
> ** **
>
> multiplexing of different media types (multiple m lines).  So I don’t see
> them as really competing (e.g. it’s possible to want to multiplex multiple

My sense from what I heard at the interim meeting was that both plan
A and plan B would have sufficient levels of multiplexing that people
would be willing to forego the other. (though of course the more
the better). Perhaps I misunderstood.

-Ekr

> **

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Feb 2013 18:31:31 -0500

On 2/14/13 5:52 PM, Bernard Aboba wrote:
> (multiple flows per m-line) would not.’
>
> multiplexing of different media types (multiple m lines).  So I don’t
> see them as really competing (e.g. it’s possible to want to multiplex
> multiple SSRCs from multiple media types on the same transport address).

IIUC, Plan A expects a single "flow" (track) per m-line, and uses stuff 
in the SDP to identify exactly which track it is. So it requires demux 
of each "flow" to a particular m-line. I'm not sure how that was 
expected to work.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Feb 2013 19:25:11 -0500

> There are better ways to construct an API with which developers could tell the browser what they want it to do, and then MMUSIC could work on carefully standardizing only what is needed for interwo…

I realize that for RTCWEB the browser is always in the middle,
but this is really about telling the other endpoint what you want to do,
since these media streams are e2e.

If this isn't done in SDP then it won't be available to SIP endpoints.

	Thanks,
	Paul

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 14 Feb 2013 16:55:37 -0800

> since these media streams are e2e.

Browser to browser e2e streams can be signaled through whatever means the developer of the end to end application comes up with...

> If this isn't done in SDP then it won't be available to SIP endpoints.

Right. But maybe not every possible combination is needed when working with SIP endpoints, and maybe, just maybe, the artificial urgency created by RTCWEB's need to have this fully specified yesterday wouldn't be putting us at serious risk of a bad solution to what is likely much more complicated than anyone has yet imagined.

Matthew Kaufman

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Feb 2013 07:35:28 +0000

Hi,

> E.g. if you bundled multiple m-lines with a UDP proto then it isn't clear how you could demux them.

Sure. If it is not possible to demux a protocol, then you obviously can't do it.

But, the scope of BUNDLE is not really to solve those kind of problems. The scope is to define how the demuxing, when it can be done, is negotiated on a signaling level, and what restrictions etc there are associated with that..

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Feb 2013 11:10:24 -0500

> But, the scope of BUNDLE is not really to solve those kind of problems. The scope is to define how the demuxing, when it can be done, is negotiated on a signaling level, and what restrictions etc t…

No, BUNDLE doesn't need to solve the problem. But it does require that 
there be a solution to the problem. And IMO it requires that the 
mux/demux mechanism be determinable from the SDP.

ISTM that a *start* is to ensure that bundle combinations we care about 
have mux/demux algorithms documented someplace that can be referenced. 
Then we reference those in the bundle draft, or create a registry and 
reference that from the bundle draft.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Feb 2013 11:18:25 -0500

> Browser to browser e2e streams can be signaled through whatever means the developer of the end to end application comes up with...

What about browser to non-browser app?

E.g. CLUE in a browser to clue in a server.

> Right. But maybe not every possible combination is needed when working with SIP endpoints, and maybe, just maybe, the artificial urgency created by RTCWEB's need to have this fully specified yester…

There will be at least *some* combinations that are needed when working 
with SIP endpoints. Maybe we at least figure out a solution that works 
for those.

	Thanks,
	Paul

---

From: Richard Barnes <[email-masked]>
Date: Fri, 15 Feb 2013 12:50:55 -0500

On Friday, February 15, 2013, Christer Holmberg wrote:

> Hi,
>
> >> I see no reason why BUNDLE couldn't be used also for non-RTP. We would
> need to consider it when we study the study the SDP attribute impact,
> though, but that exercise we have to do for RTP anyway.
> >
> But, the scope of BUNDLE is not really to solve those kind of problems.
> The scope is to define how the demuxing, when it can be done, is negotiated
> on a signaling level, and what restrictions etc there are associated with
> that..
>
> Regards,
>
> Christer
>
>
This seems right to me.  The SDP just needs to allow the offeror to declare
"I am going to send packets of types DUCK and GOOSE and AVOCADO over this
channel." The mux part is trivial.

The offerer shouldn't offer a combination he can't demux. The answerer
shouldn't accept a combination he can't demux.  In other words, this is a
local matter, like codec support.

That's not to say that demux recommendations shouldn't be written -- they
should -- but the SDP does not need to account for demux algorithms.

Just my $.02,
--Richard

>
>
>
> > For MMT it is more tricky. As it only uses a single m= line for the
> whole bundle, we would need to define a new "MMT" proto value for that m=
> line (currently the draft uses RTP). Then we would need to, inside the m=
> line, define a way to specify the proto value for each individual media.
> >
> > Regards,
> >
> > Christer
> > From: [email-masked] <javascript:;> [[email-masked]<javascript:;>]
> on behalf of
> > Dale R. Worley [[email-masked] <javascript:;>]
> > To: [email-masked] <javascript:;>
> >> From: Paul Kyzivat <[email-masked] <javascript:;>>
> >>
> > [email-masked] <javascript:;>
> > [email-masked] <javascript:;>
> [email-masked] <javascript:;>
> [email-masked] <javascript:;>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Feb 2013 13:52:49 -0500

On 2/15/13 12:50 PM, Richard Barnes wrote:
>      >> I see no reason why BUNDLE couldn't be used also for non-RTP. We
>     would need to consider it when we study the study the SDP attribute
>     impact, though, but that exercise we have to do for RTP anyway.
>      >
>     But, the scope of BUNDLE is not really to solve those kind of
>     problems. The scope is to define how the demuxing, when it can be
>     done, is negotiated on a signaling level, and what restrictions etc
>     there are associated with that..
>
>     Regards,
>
>     Christer
>
>
> This seems right to me.  The SDP just needs to allow the offeror
> to declare "I am going to send packets of types DUCK and GOOSE and
> AVOCADO over this channel." The mux part is trivial.
>
> shouldn't accept a combination he can't demux.  In other words, this is
> a local matter, like codec support.

This doesn't work unless the offerer and the answerer *agree* on the 
mux/demux algorithm.

E.g. It would be bad if the offerer uses a unique payload type for each 
"flow"/track and switches among SSRCs within it, while the answerer 
demuxes into flows/tracks based on SSRC.

> That's not to say that demux recommendations shouldn't be written --
> they should -- but the SDP does not need to account for demux algorithms.

You used an analogy to codec support. SDP doesn't define particular 
codecs, but it does provide the mechanism for the offerer and answerer 
to agree on which codecs will be used.

The same would be true here *if* the SDP allowed the mux/demux algorithm 
to be declared or negotiated.

	Thanks,
	Paul

> Just my $.02,
> --Richard
>
>
>
>
>      > For MMT it is more tricky. As it only uses a single m= line for
>     the whole bundle, we would need to define a new "MMT" proto value
>     for that m= line (currently the draft uses RTP). Then we would need
>     to, inside the m= line, define a way to specify the proto value for
>     each individual media.
>      >
>      > Regards,
>      >
>      > Christer
>      > From: [email-masked] <javascript:;>
>     [[email-masked] <javascript:;>] on behalf of

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 15 Feb 2013 17:23:12 -0500 (EST)

> From: Harald Alvestrand <[email-masked]>
> 

More exactly, RTCWEB has an assumption that there is a strategy for
sending SCTP/DTLS/UDP over the same port as SRTP, and that we will
figure out how to signal it.  (It appears that sending RTP and RTCP
(or SRTP and SRTP) over the same port is already solved.)

The question is whether this is a *requirement*, and if so, to put it
in the requirements document -- I don't see it in
draft-ietf-rtcweb-use-cases-and-requirements-10.

However what I do see in that draft is:

   F29             The browser MUST be able to send streams and
                   data to a peer in the presence of NATs that
                   block UDP traffic.

and we seem to be assuming that the carrier protocol for multiplexing
is UDP...

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 15 Feb 2013 17:22:30 -0500 (EST)

The problem is divisible into two parts.  One part is just clarifying
what needs to be supported.  The second, harder part is specifying all
the mechanisms.

When multiplexing, we have to establish:

1. What is the nature of the constituent data streams that can be
   multiplexed?

2. What method is used to multiplex the constituents?  Does there need
   to be an encapsulation protocol?

3. What method is used to demultiplex the incoming PDUs of the
   multiplexed data?

4. What carrier protocol is used to carry the multiplexed data?

5. How will we signal whatever information is needed to control the
   demultiplexing process?  (This is affected by any need to
   interoperate with existing systems.)

6. Where in the stack of protocols do we apply encryption, and what is
   its nature?

Items 1 and 3 are the ones that are most constrained by the
requirements of the situation.

As far as I can tell from what I've seen, the nature of the
constituent data streams is:

- the RTP or SRTP traffic arising from zero or more SDP media
  descriptions (Here we assume that it is important when
  demultiplexing RTP that it is important to identify the correct
  constituent media description for each incoming RTP packet; that RTP
  cannot be interpreted except in the context of the correct media
  description.)

- the corresponding RTCP or Secure RTCP traffic (assuming we want to
  have RTP/RTCP multiplexing)

- the data carried over a single SCTP connection (which includes a
  number of SCTP streams), or possibly more than one SCTP connection
  if that is to be supported (It is not clear if the multiplexing
  process has access to the data in the individual SCTP streams, or
  whether the constituent data stream is the packets generated by
  SCTP's multiplexing process, or whether it must handle the packets
  generated by DTLS encrypting the SCTP packets.)

The carrier protocol seems to be assumed to be UDP supplemented by the
STUN and ICE traffic needed to support a UDP association with the
far-end.  However there may be value in using SCTP-over-DTLS-over-UDP
as the carrier protocol.

In regard to encryption, it would be more efficient to apply
encryption only to the multiplexed data.  That suggests that the
constituent data is unencrypted: RTP instead of SRTP, SCTP instead of
DTLS/SCTP.

There tends to be an assumption that the demultiplexing process is
trivial, that all incoming PDUs can be identified and routed to their
correct destinations without any additional encapsulation
information.  We might be lucky enough that that is true, but it is
not the common case.

Dale

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 16 Feb 2013 23:56:52 +0000

Sort of - I think the right question is can SCTP over DTLS over UDP demux from SRTP over UDP and from STUN over UDP and the answer to that is yes.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 16 Feb 2013 16:07:28 -0800

Dale,

I had assumed that the layering diagram looked as follows:

     SCTP
     DTLS    SRT(C)P       STUN
               UDP

This means that the demux problem becomes something like

- If packet is STUN, forward to ICE stack.
- If packet is SRT(C)P:
  + Primary demux on payload type
  + Secondary demux on SSRC
- If packet is DTLS
  + Demux SCTP associations by port number
    . SCTP streams are demuxed by stream ID

1. The first level of demux is described in RFC 5764 S 5.1.2.
2. The SRT(C)P demux appears to be specified in:
   http://tools.ietf.org/html/draft-ietf-avtcore-multi-media-rtp-session-01
3. SCTP over DTLS encapsulation (and the elevant muxing) appears to
   be specified in:
   http://tools.ietf.org/id/draft-tuexen-tsvwg-sctp-dtls-encaps-01.txt
   and since the port is part of SCTP, this seems straightforward
   if we wish to allow it.

Obviously, one could, as you suggest, tunnel everything over SCTP,
but this seems like it would be less efficient in terms of bandwidth
(since you would add a bunch of headers to the RTP) and would also
be less compatible with existing SRTP endpoints.

Best,
-Ekr

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 18 Feb 2013 10:05:39 -0500 (EST)

> From: Eric Rescorla <[email-masked]>
> 

And though you don't state it explicitily, no additional framing info
on the second step.

But it seems to me that it's inefficient in that encryption is done
separately for every input stream.  Or is datagram encryption a lot
more clever than I think it is?

Dale