[MMUSIC] IETF #80 (Prague): draft MoM MMUSIC

["Miguel A. Garcia" <[e-mail]>]

The chairs want to share the draft minutes of the MMUSIC meeting that 
took place in Prague. We are still trying to verify a couple of unclear 
sentences. Please review it and send comments and amendments.



Minutes of the Meeting: MMUSIC working group at IETF 80
--------------------------------------------------------------------------------------

The MMUSIC working group of the IETF met at IETF #80 in Prague, Check 
Republic. The WG met on April 1st, 2011 from 9 to 11.30.

The meeting was chaired by Flemming Andreasen and Miguel A. Garcia. 
Christer Holmberg and Paul Kyzivat took notes. Wolfgang Weck acted as a 
jabber scribe.

The chairs presented the agenda. No agenda bashing was needed.

The chairs presented the status of the working group (see slides). On a 
call for volunteers to do a last review of RTSP 2.0, Peiyu Yue indicated 
willingness to review the draft.

The chairs presented the proposed new milestones. On RTSP 2.0, Magnus 
Westerlund indicated that as soon as RTSP 2.0 is submitted for 
publication to the IESG, we can move forward with the related RTSP 
extensions.

On the forthcoming rfc4566bis, Colin Perkins indicated that he has the 
XML source of the current rfc4566bis, included some errata fixing, and he 
will send them to the new editor (Ali Begen).


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

Listed the comments by Paul Kyzivat, and plans to address them. Jonathan 
Lennox suggested the ABNF change for UUI should not use raw bytes in the 
SDP – suggested hex for discriminator byte.Flemming recently sent a bunch 
of comments to the list (not addressed in the presentation). Simo 
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

John Elwell asked if session-level versus media-level issue isn't already 
handled by RFC 5939. Simo clarified that RFC 5939 allows extensions to 
change the default behavior, however the current does not change it – 
Elwell agreed with that.

Charles Eckel 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: Tomas Stach
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
-- Jonathan Lennox commented that an ICE entity should always know 
whether an updated offer is expected.  So the fax machine should know 
this and behave appropriately. John Elwell answered that even in this 
case it doesn’t know how long it might have to wait for it.
Flemming asked for more feedback on ICE in general. Hadriel commented 
that this isn’t really just an ICE problem – it is a general update 
problem. Response: yes, but this makes it worse.

- ISSUE 2: Interaction with 3PCC

Discussion of what is meant by “middlebox”. Conclusion that it does not 
mean arbitrary B2BUA. Rather the concern is boxes that get media. 
Indicated that middle boxes that modify SDP will terminate ICE. Chair 
query if there is an issue for WG to address – not specifically this one, 
but general problems with ICE. A poll reveals that about 15-20 people 
have read the draft. Christer is concerned with the restrictions being 
imposed on the form of the solution. Christer said he felt that if you 
are going to implement ICE then implementing 100rel isn’t that much more. 
Cullen sees many reasons not to require 100rel, etc. Cullen noted that 
while not every product implements ICE, there are many ICE 
implementations available today. Cullen stated that maybe we don’t need 
the extra O/A cycle at all for ICE (some implementations do not do it) – 
the cases where it is required are places where ICE does not work for 
other reasons and is not needed. Cullen is concerned with raising the bar 
for existing implementations. John Elwell noted that there are classes of 
devices where ICE is not widely implemented today, and there are barriers 
to implementing ICE for certain types of applications, and we should 
address those. Elwell agreed that we should not raise the bar for other 
implementations (incl. e.g. RTCWeb).

Conclusions: more discussions are required, including clarification on 
scope of what we are looking at.


Media level ice-options SDP attribute
-------------------------------------
Presenter: 	Marc Petit-Huguenin
Draft: 	draft-petithuguenin-mmusic-ice-attributes-level-00

Marc indicated that this draft has come from implementation experiences. 
J. Lennox questioned whether aggregation works when if you have two m= 
lines, one of which supports ICE and the other does not. John Elwell 
suggested that if SPLICES is the only motivation for this, then perhaps 
we should wait for SPLICES to get further. Marc clarified that this isn’t 
only related to SPLICES. Andrew Allen indicated that 3GPP has already 
specified a SPLICES-like mechanism, so they are likely going to have this 
problem, presumably with ECN, and he is interested in seen the work 
progressing. Paul Kyzivat and Magnus Westerlund indicated that this draft 
is important.

Conclusion:
There was interest in working with the problem defined in the document.


DCCP Encapsulation for NAT Traversal (DCCP-UDP)
-----------------------------------------------
Presenter: 	Colin Perkins
Draft: 	draft-ietf-dccp-udpencap-07

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

Various alternatives presented from floor. Jonathan Lennox said this is 
likely to be used in conjunction with ICE, so could offer ICE candidates 
of both types and let the ice negotiation sort out which one works. 
Cullen thinks it is complicated to have two port numbersbecause many APIs 
etc only support one port number. He says that when doing this, should 
require UDP port and DCCP port to be the same. Flemming supported Cullen 
– do not introduce two ports into SDP for this. Flemming advocated for 
the usa of existing frameworks (CapNeg, ICE). Hadriel said aligning the 
port numbers is not feasible with SBCs, they will change the UDP port but 
not the DCCP port.  Lennox noted that SDP transport protocol field covers 
both transport protocol and higher level profile (e.g. RTP); we are 
looking at pure transport protocol here and hence should use ICE. 
Christer indicated yet a third mechanism: grouping framework. Gonzalo 
indicated that the same issue exists for SCTP, as it is likely to be 
encapsulated in UDP, so we should do the same thing.

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

Salvatore addressed comments by Paul Kyzivat that didn't go to the list. 
Only plan to use one media stream per connection. Propose to always use 
stream 0. Jonathan Lennox says there are similar issues in “multi-path 
RTP” in AVTCORE. Should align efforts. Hadriel asks if there is a use 
case for this – why use SCTP for media? He says it is a huge amount of 
work to extend ICE to do multiple connectivity checks and have more than 
one being used. He points out that SCTP doesn’t go through NATs at all 
right now. Cullen asks what is advantage of this compared to TCP if you 
can only use one stream. Cullen furthermore noted that anything that will 
get to multi-stream support will greatly complicate ICE. Magnus 
Westerlund indicated that SCTP solves framing and the head of line 
blocking. Gonzalo Camarillo had heard of use cases for setting up SCTP 
streams via SDP, and then do signaling on top of them.

Conclusion:
- Further discussions are needed in order to clarify the scope of the 
proposed work (including whether NAT and/or UDP is in scope or not).


Grouping of Adjacent Media in the SDP
-------------------------------------
Presenter:	Cullen Jennings
Draft:	draft-jennings-mmusic-adjacent-grouping-03

Cullen highlighted differences from CLUE WG cases, that the mechanism is 
purely declarative, and that the draft should not talk about 
telepresence. Christer says it is not negotiation – it is declaration, 
and so he thinks it should not be SDP. Someone suggested the word 
“declarative”. Brian Rosen agreed it is a different problem, but clue has 
a similar issue – what goes on left, middle, right. So he suggests we 
want to end up with some common mechanisms. He asked if we could hold off 
a little bit. Steve Bosco is also concerned with overlap. Cullen is 
concerned that timeframes are incompatible. Peter Musgrave doesn’t want 
to couple it to CLUE and noted he likes it.

Magnus had some technical issues, but Cullen is not concerned about 
technical details – just if this is work we want to do. Charles thought 
CLUE WG might be able to use this. Hadriel, after some historical 
grumbling, agreed this should go and not block waiting for CLUE.

Allyn sees difference – thinks clue will not be able to use SDP for its 
comparable function. But she disagreed with Cullen’s description of CLUE.

Conclusion: continue list discussion. Updated draft needs to clarify 
relationship (or lack of) with CLUE.


SDP 'trafficclass' Attribute
----------------------------
Presenter:	James Polk
Draft:	draft-polk-mmusic-traffic-class-for-sdp-01

This work has been hummed in TSVWG but not yet an official WG. James asks 
for cooperative work between the areas on this. James thinks transport 
needs to be involved – either chairs working together or ADs working 
together. Indicated that the meaning of different attribute values needs 
to be defined.

Lots of discussion over definitions of these labels, e.g.
- Should not have more labels than clear use cases
- Some labels are not always clear-cut, leaving the implementer with 
ambiguity. Need more clarity on this.
- Confusion on hierarchical aspect – not clear the categories are really 
hierarchical
Christer suggests a framework where other groups define specific 
trafficclass values. It is indicated that there needs to be e.g. some 
global registry (e.g., IANA), where values are defined, so that everyone 
has the same understanding on what the value means.

Conclusion:
- Continue list discussion.
- Chairs to investigate cooperation with transport.


SDP attribute to signal parallax
--------------------------------------
Presenter: 	Bert Greevenbosch
Draft: draft-greevenbosch-mmusic-parallax-attribute-00

Jonathan Lennox commented that there is nothing in SDP that indicates the 
different streams are overlapped on display. Steve Bosco concerned that 
units are pixels but without info about the resolution of the displays.

Conclusion: continue list discussion


Signal 3D format
-----------------------
Presenter: 	Bert Greevenbosch
Draft: draft-greevenbosch-mmusic-signal-3d-format-00

Comment on 3d format that three types are mentioned but there is a 4th 
type of note that is not mentioned. Why? Thomas Schierl questions on the 
AVC codec, whether it fits here. Roni Even is concerned about having 
different ways of conveying this info – whether this should be handled by 
the codec, vs. multiple RDP requiring multiple codecs, etc. Andrew Allen 
asked if this could use Cullen’s grid stuff to describe arrangement of 
streams.

Conclusion: continue list discussion.


Temporal Interleaving Attribute SDP
---------------------------------------------
Presenter: Ali Begen
Draft:draft-begen-mmusic-temporal-interleaving-01

Colin Perkins questioned terminology – ‘interleaving’ vs. ‘delay’. 
Agreement that ‘delay’ is more precise.

Conclusion: continue list discussion.


Redundancy Grouping Semantics in SDP
-------------------------------------------------
Presenter: Ali Begen
Draft:draft-begen-mmusic-redundancy-grouping-00

Comment from Colin that the redundancy impacts RTCP statistics, and 
generally breaks RTCP – should be brought to one of the AVT groups.

Conclusion: continue list discussion.








Cheers,

          Flemming and Miguel

-- 
Miguel A. Garcia
[phone]
Ericsson Spain