[MMUSIC] IETF#80: mmusic notes

[Christer Holmberg <[e-mail]>]

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.