Subject: [MMUSIC] IETF#80: mmusic notes

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Apr 2011 14:00:21 +0200

Hi,

Below are my notes from the mmusic session.

Regards,

Christer

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

General
-------

- Request for RTSP 2.0 reviwers. 
-- Peiyu Yue indicated willingness.

- Milestones
-- Indication that as soon as RTSP 2.0 is done we can move forward the related RTSP extensions.

SDP Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The PSTN
----------------------------------------------------------------------------------------------------

Presenter: 	Simo Veikkolainen
Draft:	draft-ietf-mmusic-sdp-cs-06

- The presenter proposed to fix the open issues, submit a new version of that the draft, and then be able to initiate WGLC by June.

Title and Bandwidth Capabilities Negotiation in the Session Description
-----------------------------------------------------------------------

Presenter:	Simo Veikkolainen
Draft:	draft-mmusic-sdp-icap-bcap-01

- It was questioned about the need and use-cases for the bandwidth capability attribute. A use-case needs to be added to the draft.

ICE Updated Offer Problematic
-----------------------------

Presenter:	???
Draft:	draft-elwell-mmusic-ice-updated-offer-00

- The issues described in the draft, and mechanism proposals on how to solve those, were presented.

- ISSUE 1: UPDATE race conditions
-- Comment that an ICE entity should always know whether a updated offer is expected. 
-- In case an UPDATE would always be sent, it was questioned how long the remote peer should wait for that UPDATE.

- ISSUE 2: Interaction with 3PCC

- Conclusions
-- Clarification on what types of middle boxes are considered. Indicated that middle boxes that modify SDP will terminte ICE.
-- It was indictated that we should not raise the bar for implementing ICE, e.g. by mandating the support of additional features (e.g. 100rel and preconditions).

Media level ice-options SDP attribute
-------------------------------------

Presenter: 	Marc Petit-Huguenin
Draft: 	draft-petithuguenin-mmusic-ice-attributes-level-00

- There was interest in working with the problem defined in the problem.

DCCP Encapsulation for NAT Traversal (DCCP-UDP)
-----------------------------------------------

Presenter: 	Colen Perkins
Draft: 	draft-ietf-dccp-udpencap-07

- The main issue is how to signal the support of the feature in SDP.
-- Alt 1: Attribute with port number
-- Alt 2: New m= protoc type

- Comment that the usage of different port number will make things complicated, e.g. because many APIs etc only support one port number.
- Different mechanisms were proposed: ICE, SDP CapNeg, SDP grouping framework.
- Indicated that a similar issue exists for SCTP, and that we should aim to come up with a generic solution that can be used also for that.

SCTP-Based Media Transport in the SDP
-------------------------------------

Presenter:	Salvatore Loreto
Draft:	draft-loreto-mmusic-sctp-sdp-07

- Indication that some of the AVT groups are also working on a similar multihoming problem, so it might be a good idea to have a look at what that work.
- Question whether there is a need for this, as there would be much work. Is someone going to send media over SCTP?
- Question what the advantage of sending media over SCTP is, if you can only use one stream.
- Further discussions are needed in order to clarify the scope of the proposed work.

Grouping of Adjacent Media in the SDP
-------------------------------------

Presenter:	Cullen Jennings
Draft:	draft-jennings-mmusic-adjacent-grouping-03

- Indicated that the use-case is different from CLUE, and that draft should not talk about telepresence.
- Indicated that the use-case is not SDP offer/answer, but more a one-way description.
- Indicated that something similar might be needed for CLUE, but that this is only a subset of what is needed for CLUE.

SDP 'trafficclass' Attribute
----------------------------

Presenter:	James Polk
Draft:	draft-polk-mmusic-traffic-class-for-sdp-01

- Indicated that the meaning of different attribute values need to be defined.
- Indicated that the WG could work on a framework, but that specific trafficclass values should be defined by others, working on specific areas.
- Indicated that there needs to e.g. some global registry, where values are defined, so that everyone have the same understanding on what the value means.

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 01 Apr 2011 07:33:41 -0500

>Below are my notes from the mmusic session.

comments on the set of observations regarding the following ID...

>SDP 'trafficclass' Attribute

agreed

>- Indicated that the WG could work on a framework, but that specific 
>trafficclass values should be defined by others, working on specific areas.

This was a late comment during the preso, and no one else really 
reacted to it. I believe there is a basic framework within this 
existing ID (i.e., the -01 version) about the structure of how the 
strings fit together to form a traffic classification label, but no 
consensus has been reached on that yet (obviously). I agreed during 
the preso that I don't want to overstep or overlap existing 
definitions that may exist -  but I'm not sure that's exact what's 
written above. I also don't know if too many of these strings are 
defined anywhere at this time - or are defined in a way we want to 
use them (which may mean we have to switch to a string for a specific 
meaning we want). I'm open to be proven wrong.

>- Indicated that there needs to e.g. some global registry, where 
>values are defined, so that everyone have the same understanding on 
>what the value means.

agreed - but I hope this "global registry" is IANA, because that's 
all I talked about in today's preso. No one talked about anything 
other than IANA today.

Another thing to consider is that we will have several layers looking 
at this same registry (i.e., applications and network layer folks) 
each from their own point of view.

James

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Apr 2011 14:46:13 +0200

Hi James,

>This was a late comment during the preso, and no one else 
>really reacted to it. I believe there is a basic framework 
>within this existing ID (i.e., the -01 version) about the 
>structure of how the strings fit together to form a traffic 
>classification label, but no consensus has been reached on 
>that yet (obviously). I agreed during the preso that I don't 
>want to overstep or overlap existing definitions that may 
>exist -  but I'm not sure that's exact what's written above. 
>I also don't know if too many of these strings are defined 
>anywhere at this time - or are defined in a way we want to 
>use them (which may mean we have to switch to a string for a 
>specific meaning we want). I'm open to be proven wrong.

My intention was not to indicate that the WG has agreed on this, but simply trying to reflect comments (this particular comment was given by myself :) that were given during the session.

>>- Indicated that there needs to e.g. some global registry, 
>>where values are defined, so that everyone have the same understanding on 
>>what the value means.
> 
>agreed - but I hope this "global registry" is IANA, because 
>that's all I talked about in today's preso. No one talked 
>about anything other than IANA today.

Sure. I agree that IANA would be the most obvious.

Regards,

Christer