Subject: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, May 23, 2013

From: IESG Secretary <[email-masked]>
Date: Thu, 09 May 2013 11:02:36 -0700

Greetings

This is to announce a virtual interim meeting for the MMUSIC Working
Group to take place on Thursday, May 23rd, from 7:00 am - 10:00 am
Pacific Time. The goal of this meeting is to come to a resolution on the
so-called "Plan A" or "Plan B" approach related to SDP signaling needed
by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines
or very few "m=" lines and to what extent is there sub-negotation and
signaling at the SSRC level).

A more detailed agenda and logistics will be sent out separately. For
now, people should take a close look at the following two drafts:

http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt

http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt

You may also want to look at
http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt

Thanks

-- Ari & Flemming (MMUSIC co-chairs)

PS: We are currently also considering having a physical interim meeting
the week of June 24th, likely on the US West Coast. We will await the
outcome of the virtual interim meeting before making a decision on this
but wanted to give people a heads-up for now.

---

From: Ari Keränen <[email-masked]>
Date: Thu, 16 May 2013 23:06:00 +0300

All,

Since it seems that many of the key draft authors of the Plan A vs. Plan 
B discussion are unable to attend the virtual interim at the planned 
time, we have decided to focus at this interim on the open issues in the 
Bundle draft.

For details please read the current Bundle draft:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-03

Also see the latest Bundle threads on the MMUSIC mailing list. Christer 
will provide a more detailed list of issues to discuss.

Thanks,
Ari & Flemming (MMUSIC co-chairs)

On 5/9/13 9:02 PM, IESG Secretary wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Mary Barnes <[email-masked]>
Date: Thu, 16 May 2013 15:31:16 -0500

Are there plans to schedule another virtual interim where the various
plans can be discussed?

On Thu, May 16, 2013 at 3:06 PM, Ari Keränen <[email-masked]> wrote:
> All,
>
> Since it seems that many of the key draft authors of the Plan A vs. Plan B
> discussion are unable to attend the virtual interim at the planned time, we
> have decided to focus at this interim on the open issues in the Bundle
> draft.
>
> Also see the latest Bundle threads on the MMUSIC mailing list. Christer will
> provide a more detailed list of issues to discuss.
>
>
> Thanks,

---

From: Ari Keränen <[email-masked]>
Date: Fri, 17 May 2013 00:31:47 +0300

Hi Mary,

Yes, we are planning another interim for this discussion. Scheduling for 
one has turned out to be quite hard due to various constraints, but 
we're working on it.

Cheers,
Ari

---

From: Mary Barnes <[email-masked]>
Date: Fri, 17 May 2013 08:54:12 -0500

Thanks.  I'm also assuming then that there is no longer a potential
f2f interim meeting in the plans (as was suggested in the announcement
of the May 23rd interim)?

Mary.

On Thu, May 16, 2013 at 4:31 PM, Ari Keränen <[email-masked]> wrote:
> Hi Mary,
>
> Yes, we are planning another interim for this discussion. Scheduling for one
> has turned out to be quite hard due to various constraints, but we're
> working on it.
>
>
> Cheers,
> Ari
>
>
>>> B
>>> will

---

From: Ari Keränen <[email-masked]>
Date: Fri, 17 May 2013 19:36:23 +0300

Whether we can have the f2f is still open too (the proposed date seems 
to collide with the WebRTC expo at Atlanta). We're working on figuring 
out possibilities for both a new virtual and/or f2f.

Cheers,
Ari

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 May 2013 14:11:32 +0000

Hi,

The main technical issues for BUNDLE at the moment are:

1)	How to demux RTP (and other media types, but RTP is the most critical). This is currently discussed within the "Plan A vs Plan B" context on the RTCWEB list.

2)	Where to send media until an O/A exchange with identical port number has taken place. This is currently discussed on the MMUSIC list ("Bundle offer with different ports - where to expect media?").

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ari Keränen
Sent: 16. toukokuuta 2013 23:06
To: [email-masked]
Cc: Flemming Andreasen
Subject: Re: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, May 23, 2013

All,

Since it seems that many of the key draft authors of the Plan A vs. Plan B discussion are unable to attend the virtual interim at the planned time, we have decided to focus at this interim on the open issues in the Bundle draft.

Also see the latest Bundle threads on the MMUSIC mailing list. Christer will provide a more detailed list of issues to discuss.

Thanks,

---

From: Ari Keränen <[email-masked]>
Date: Tue, 21 May 2013 17:00:40 +0300

Hi all,

Please find below the dial in information for the virtual interim meeting.

The idea is to focus on open issues in the Bundle draft 
(draft-ietf-mmusic-sdp-bundle-negotiation-03). In particular:

1)	How to demux RTP (and other media types, but RTP is the most 
critical). This is currently discussed within the "Plan A vs Plan B" 
context on the RTCWEB list.

2)	Where to send media until an O/A exchange with identical port number 
has taken place. This is currently discussed on the MMUSIC list ("Bundle 
offer with different ports - where to expect media?").

Regards,

--

Topic: MMUSIC Interim
Date: Thursday, May 23, 2013
Time: 10:00 am, Eastern Daylight Time (New York, GMT-04:00)
Meeting Number: 201 076 029
Password: mmusic

-------------------------------------------------------
To join the meeting online
-------------------------------------------------------
1. Go to 
https://ciscosales.webex.com/ciscosales/j.php?ED=226784177&UID=2458&PW=NYWYxYzE5ZTFk&RT=MiMxMQ%3D%3D
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: mmusic
4. Click "Join".
5. If the meeting includes a teleconference, follow the instructions 
that appear on your screen.

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
To receive a call back, provide your phone number when you join the 
meeting, or call the number below and enter the access code.
Call-in toll-free number (US/Canada): +1-866-432-9903
Call-in toll number (US/Canada): +1-408-525-6800
Global call-in numbers: 
https://ciscosales.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=226784177&tollFree=1
Toll-free dialing restrictions: 
http://www.webex.com/pdf/tollfree_restrictions.pdf

Access code:201 076 029

CCP:+14085256800x201076029#

IMPORTANT NOTICE: This WebEx service includes a feature that allows 
audio and any documents and other materials exchanged or viewed during 
the session to be recorded. By joining this session, you automatically 
consent to such recordings. If you do not consent to the recording, 
discuss your concerns with the meeting host prior to the start of the 
recording or do not join the session. Please note that any such 
recordings may be subject to discovery in the event of litigation.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 21 May 2013 14:22:05 +0000

> 1)	How to demux RTP (and other media types, but RTP is the most critical). This is currently discussed within the "Plan A vs Plan B" context on the RTCWEB list.

If we don't end up with the people in the call that are involved wight he proposals on this, I don't think we will be able to do this. I see it breaking into two different topics 

1a) How to demux SCTP data channel stuff from RTP 

1b) How to demux RTP 

Cullen (and to be clear all my emails on this list are in my individual contributor role)

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 May 2013 13:19:08 -0400

> 1a) How to demux SCTP data channel stuff from RTP

I would cut this slightly differently:

X) relevant ways of classifying packets received on a 5-tuple
Y) relevant ways to use those attributes to associate each packet with
    an m-line in a bundle
Z) how to signal a choice from (Y) in SDP

For X:

There is one layer of classification that distinguishes DTLS from RTP 
from ICE.

Then DTLS can further be classified into the stuff used for DTLS/SRTP 
keying, and DTLS payload packets.

What the DTLS payload packets contain depends on what is layered on top 
of DTLS. The only case we are considering is SCTP. (But we may need to 
make provision for the possibility that something else might be.)

SCTP packets can be demuxed by sctp port. (But there seems no interest 
in this.)

RTP packets can be classified by at least SSRC and PT. We have also been 
discussed using an RTP extension header to provide another 
classification attribute.

For Y:

I guess there is no intent to associate ICE packets with an m-line?

RTP packets can be associated with an m-line based on SSRC *if* an 
a=ssrc line mentioning that SSRC is present in exactly one m-line of the 
bundle.

RTP packets can be associated with an m-line based on PT *if* that PT is 
present on exactly one m-line of the bundle.

RTP packets can be associated with an m-line based on the extension 
header *if* the value in that header is present in exactly one m-line of 
the bundle.

If none of the above work, then if some combination of the above is 
present in exactly one m-line then that can be used to do the association.

DTLS payload packets can be associated with the collection of m-lines 
with proto of DTLS/* other than DTLS/SRTP.

If all m-lines in the bundle with a proto of DTLS/* but not DTLS/SRTP 
are DTLS/SCTP, then they can be associated with a single m-line based on 
SCTP port *if* there is exactly one m-line bound to that port. (This 
only works if there is a way to associate an SCTP port with a DTLS/SCTP 
m-line.

For Z:

Mostly implicit above: PT in m-lines, a=ssrc present with m-lines.

We will need a new attribute for the new header value if that is to be 
supported.

People didn't want to define a way to specify SCTP port with DTLS/SCTP. 
Without that there can only be one DTLS/SCTP in a bundle. And that is 
probably fine.

As long as there is only one DTLS/* proto other than DTLS/SRTP then all 
DTLS payload packets can go there, so it doesn't really need to be 
specialized for DTLS/SCTP.

Clearly there can't be any UDP or DTLS protos in the bundle, or anything 
other than the above based on UDP.

No additional SDP is needed to say how to classify *if* some combination 
of SSRC, PT, and new header value is unique for each m-line. But we may 
need something else to indicate how to classify any packets that don't 
match. (E.g., an SSRC that is not mentioned in the SDP.)

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Tue, 21 May 2013 17:56:56 -0500

Perhaps I missed it, but I can't seem to find any logistic information
for this meeting.  Is it available?

Thanks,
Mary.

---

From: Mary Barnes <[email-masked]>
Date: Tue, 21 May 2013 18:18:42 -0500

Okay.  I did miss it. For anyone else that might have in the flurry of
email on this list, here's the info:
http://www.ietf.org/mail-archive/web/mmusic/current/msg11102.html

Mary.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 May 2013 07:31:30 +0000

Hi,

I will address Paul's input later, but a general comment.

> If we don't end up with the people in the call that are involved wight he proposals on this, I don't think we will be able to do this. I see it breaking into two different topics 

Well, the question is whether how-to-demux is really dependent on Plan A vs Plan B. In my opinion the demux mechanism should not be dependent. 

No matter whether we choose Plan A or Plan B, at the end of the day a client will end up receiving multiple media on a single 5-tuple, and it needs to know how to demux it.

But, if people think that we CAN NOT move forward with how-to-demux until we have made a decision regarding Plan A vs Plan B, then we should probably remove it from the Thursday agenda.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 May 2013 13:37:22 +0000

Hi,

>> If we don't end up with the people in the call that are involved wight 
>> he proposals on this, I don't think we will be able to do this. I see 
>> it breaking into two different topics
>>
> There is one layer of classification that distinguishes DTLS from RTP from ICE.
>
> Then DTLS can further be classified into the stuff used for DTLS/SRTP keying, and DTLS payload packets.
>
> What the DTLS payload packets contain depends on what is layered on top of DTLS. The only case we are considering is SCTP. (But we may need to make provision for the possibility that something else might be.)
>
> SCTP packets can be demuxed by sctp port. (But there seems no interest in this.)
>
> RTP packets can be classified by at least SSRC and PT. We have also been discussed using an RTP extension header to provide another classification attribute.

> I guess there is no intent to associate ICE packets with an m-line?

In my opinion there is no need to do so, as the ICE packets are for the whole bundled transport.

> RTP packets can be associated with an m-line based on SSRC *if* an a=ssrc line mentioning that SSRC is present in exactly one m-line of the bundle.

Yes.

> RTP packets can be associated with an m-line based on PT *if* that PT is present on exactly one m-line of the bundle.

Yes.

> RTP packets can be associated with an m-line based on the extension header *if* the value in that header is present in exactly one m-line of the bundle.

Yes.

> If none of the above work, then if some combination of the above is present in exactly one m-line then that can be used to do the association.

Yes. 

> DTLS payload packets can be associated with the collection of m-lines with proto of DTLS/* other than DTLS/SRTP.
>
> If all m-lines in the bundle with a proto of DTLS/* but not DTLS/SRTP are DTLS/SCTP, then they can be associated with a single 
> m-line based on SCTP port *if* there is exactly one m-line bound to that port. (This only works if there is a way to associate an SCTP port with a DTLS/SCTP m-line.

The question is really how flexible we really need to make bundle, when it comes to multiplexing different media types. The main usage is RTP, and from an RTCWEB perspective we also want the data channel, but maybe we can restrict ourselves to that in the core BUNDLE spec?

Then, if people later want to add protocol X to BUNDLE, they will have to specify how the multiplexing is done, which types of other protocols can be used in the same bundle group as X.

Also, I wonder whether it would be good to do things in steps. For example, first we should decide on X, Y and Z for RTP. I believe that is most critical, because even without BUNDLE we will have to do that - at least if we move forward with Plan B.

---------------------------

> We will need a new attribute for the new header value if that is to be supported.
>
> Without that there can only be one DTLS/SCTP in a bundle. And that is probably fine.
>
> As long as there is only one DTLS/* proto other than DTLS/SRTP then all DTLS payload packets can go there, so it doesn't really need to be specialized for DTLS/SCTP.
>
> Clearly there can't be any UDP or DTLS protos in the bundle, or anything other than the above based on UDP.
>
> No additional SDP is needed to say how to classify *if* some combination of SSRC, PT, and new header value is unique for 
> each m-line. But we may need something else to indicate how to classify any packets that don't match. (E.g., an SSRC that is not 
> mentioned in the SDP.)

Yes.

Whatever we intend to use SSRC for, we need to be clear on:

1) Can we assume that the SSRC value will always be signaled in SDP?

2) Can we assume that the media actually uses the SSRC value that was changed in SDP (read: if the SSRC value changes, will there be an updated offer with the new SSRC value)?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 May 2013 11:07:50 -0400

> In my opinion there is no need to do so, as the ICE packets are for the whole bundled transport.

Yes, I think it must be that way.

> The question is really how flexible we really need to make bundle, when it comes to multiplexing different media types. The main usage is RTP, and from an RTCWEB perspective we also want the data c…

I agree we can bound what we address here. I just want us to realize 
that what we are addressing is a special case of a potentially more 
general mechanism. So we should be explicit about what we are addressing 
and not addressing.

> Also, I wonder whether it would be good to do things in steps. For example, first we should decide on X, Y and Z for RTP. I believe that is most critical, because even without BUNDLE we will have t…

I guess we could do that.
I just want to ensure that we aren't just choosing *one* of X,Y,Z!
And I think there could (someday, not now) be more - at least Z1, Z2, ...

	Thanks,
	Paul

---

From: Ari Keränen <[email-masked]>
Date: Thu, 23 May 2013 01:01:45 +0300

> But, if people think that we CAN NOT move forward with how-to-demux until we have made a decision regarding Plan A vs Plan B, then we should probably remove it from the Thursday agenda.

I think we should do our best to make progress with this with the people 
we get to the call. What ever we decide or propose as the way forward 
will be taken to the list to confirm anyway.

Meanwhile, it's of course helpful if (especially) people who can not 
join the call express their views on this on the list.

Cheers,
Ari

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 22 May 2013 22:02:50 -0400 (EDT)

> From: Christer Holmberg <[email-masked]>
> Date: Wed, 22 May 2013 13:37:22 +0000
> Accept-Language: en-US
> 

Yes.  ICE packets aren't visible at the interface between the
SDP-driven transport apparatus and the application that handles the
media flows; ICE packets are associated with the setting-up of the
transport associations.  If one transport association carries the
media for multiple m= lines, its ICE packets are clearly not associated
with any single m= line.

Dale