Minutes of the Multiparty Multimedia Session Control (MMUSIC) WG

========================================
========================

Reported by:	Jörg Ott
Notes by:	Colin Perkins

General
-------
Colin Perkins, Jörg Ott

The MMUSIC WG met once at the 59th IETF.  The meeting was chaired by Colin 
Perkins and Jörg Ott.  Some 100 people attended the meeting.

Jörg reviewed the agenda, with no changes being requested.  He also 
provided a brief status update: Several WG documents are with the IESG now, 
some of them waiting to be updated.  No RFCs were published since the last 
IETF.


Internet Media Guides
---------------------
Rod Walsh, Juha-Pekka Luoma, Yuji Nomura
- draft-ietf-mmusic-img-req-03.txt
- 
draft-nomura-mmusic-img-framework-03.txt

Rod Walsh discussed the changes since the last version in the two above WG 
documents.  The requirements document has seen various 
clarifications and formal corrections.  The problem statement was 
augmented to point to the holes existing IETF protocols leave in the 
problem space.  The use cases were reordered, further cases covering 
subscribe/notify requirements were added.  Delivery and description 
requirements were clarified.  For the framework document, the 
descriptions of SUBSCRIBE and NOTIFY operations were improved, the draft was 
aligned with the requirements draft.  Finally, again, formal and 
editorial corrections were made.

Rod then presented the conceivable next steps: the documents are already in 
WGLC, so there are considered pretty much complete.  Within the IMG 
framework, three potential new areas of work have been identified: an IMG 
transfer envelope, a multicast delivery protocol, and a subscribe notify 
mechanisms.  Thoughts on all areas exist as individual drafts, and Rod 
requests they be added to the MMUSIC or appropriate other WG charter (see 
below).  There is quite some interest from other bodies (including 3GPP and 
DVB) so this work should proceed.

In the following, Pekka and Yuji outlined the suggested work items, 
starting from the framework draft and filling in the components needed: The 
transfer envelope is supposed to be an XML definition for a container that 
can carry arbitrary metadata as contents 
(draft-luoma-mmusic-
img-metadata-envelope-00.txt).  This could be done in MMUSIC.  The 
multicast transport protocol should be designed as a specific 
instantiation of the FLUTE protocol spec from the RMT WG, as suggested in 
draft-luoma-mmusic-img-muppet-04.txt.  This work could be in MMUSIC or in 
RMT.  The unicast subscribe/notifiy mechanisms could be based upon the SIP 
event framework, but no draft exists here so far.  This could be done in 
MMUSIC or SIPPING.

The presentation provoked some discussion on whether it would be 
appropriate to think about using the SIP SUBSCRIBE/NOTIFY mechanism, as no 
obvious relation can be seen to other SIP work.  It was noted that this 
work is less about personal presence than about conveying state changes in 
general, and it was requested that clear use cases and requirement be 
drawn up and sent to the SIPPING list for discussion. Furthermore, it was 
remarked that the XML encapsulation format will become much easier if all 
data objects are labelled rather than allowing for generic XML to be 
encapsulated, e.g. for diffs.  Yuji noted that a generic 
encapsulation is necessary.

There were no objections raised against continuing this work.  Colin and 
Jörg were tasked to talk to the ADs and the chairs of the other 
relevant working groups (particularly SIPPING and RMT) to determine where 
which work should go and to initiate re-chartering MMUSIC 
accordingly. 



SDP Security Descriptions for Media Streams

-------------------------------------------
Flemming Andreasen
- draft-ietf-mmusic-sdescriptions-03.txt

Flemming briefly reviewed the overall structure of the draft and the 
changes since the last revision: It consists of a core framework and 
parameter definitions, a specific instantiation of this framework for 
SRTP, procedures on how to operate with, and without, offer/answer 
scheme, and a grammar.  Quite a few changes have been made to the draft 
since -02: following consensus from the last IETF, support for 
multicast and multipoint SRTP sessions was removed, so was the SRC 
parameter. Rules for creating and removing crypto contexts are now more 
explicit. Numerous additions were made to clarify the use with 
offer/answer. Finally, the IANA registry structure was changed.

Flemming pointed out one minor issue with offer/answer: with o/a, an 
initial crypto context is established.  However, subsequent o/a 
exchanges may not just modify codec parameters but also peer addresses (IP 
address and/or port).  In this case, the new entity may not have 
information about the current ROC value.  The solution is to reset the ROC 
value to zero whenever any part of an address changes (at either end).

A question was raised which changes would affect security; this seems to be 
restricted to the case of a transport address or port change at either end.

The group felt the document was ready for WGLC.


SDP Security Preconditions
--------------------------
Flemming Andreasen
- 
draft-andreasen-mmusic-securityprecondition-01.txt

Flemming briefly introduced the problem to be addressed: during an 
offer/answer exchange, the offerer and answerer exchange security 
parameters.  When the answered has picked a scheme (possibly one out of 
several offered) and the respective parameters, it can start sending media 
right away.  The first packets of the secured media stream may reach the 
offerer before the answer, so that the offerer does not know which 
security description to use.  RFC 3312 provides a solution by means of 
introducing preconditions which was suggested for this problem at the last 
IETF.  In the meantime, no concerns were raised and no issues found so that 
this work is believed to be useful and also ready.

It was tentatively agreed to adopt this as a WG item, pending charter 
discussion.


SDP Connectivity Preconditions
------------------------------
Flemming Andreasen
- 
draft-andreasen-mmusic-connectivityprecondition-00.txt

Flemming introduced the problem to be addressed: various 
circumstances (e.g. deployment of NATs, firewalls, etc.) may interfere with 
packet transmission and may prevent media streams from flowing in either or 
both directions, even though call signaling setup succeeds.  The 
proposed approach is to re-use the precondition mechanism defined in RFC 
3312 with a new precondition tag to indicate that a call shouldn't 
proceed until connectivity has been verified.  To test whether media 
stream connectivity (which is only defined for RTP) is available, a 
mechanism such as STUN or the proposed new RTP NOOP payload format can be 
used (the draft doesn't mandate any particular connectivity check).

Significant discussion arose concerning the relationship between this work 
and ICE (the latter being used to ensure that there is 
connectivity).  Commenters found that the term "connectivity" needs a more 
precise definition in the draft to be able to take a binary decision of 
whether or not a connectivity precondition is satisfied. A further issue was 
raised in conjunction with SIP forking, as the initiator of a call may 
receive packets from multiple destinations and may be unable to tell which 
branch satisfied the precondition. Flemming believes the approach is 
workable and took up the task to explain this in more detail in a 
revised version.

The chairs noted that there is clearly interest in the draft, but 
chartering this as an MMUSIC work item again requires a charter 
discussion first. 


Interactive Connectivity Establishment (ICE)

--------------------------------------------
Jonathan Rosenberg
- draft-ietf-mmusic-ice-01.txt

Jonathan presented three issues and proposed solutions regarding the 
current ICE draft.

Issue 1 is may occur with a port restricted flow if the called entity does 
not respond soon enough, e.g. with a 200 OK in the case of SIP (refer to the 
slides for details of the message flow).  In this case, a STUN timeout may 
occur at the callee because the caller does not receive the 200 OK and 
start sending STUN packets itself (thereby creating the necessary 
binding in its local NAT) so that media connectivity is not 
established.  This is a race condition between the STUN timeout and the 
answer from the callee.

Jonathan has two solution proposals: solution 1 is to mandate an 
immediate answer, this can be achieved in SIP e.g. with a 183 
conveying the necessary addressing information back to the caller, and to 
increase the STUN timeout.  Solution 2 is to mandate a second ICE cycle to 
re-check  STUN-allocated addresses; this solution increases the 
signaling overhead associated with session setup (not the setup delay!) but 
eliminates the race condition in all cases.  Jonathan proposed solution 1 as 
the appropriate solution.

A comment was made that a connectivity precondition may solve this issue 
which Jonathan argues against.  A suggestion was made to avoid a second 
cycle with solution two, based upon the priority order of the 
connection type.  Jonathan feels that basing this decision on the NAT type 
determination is too risky, since it is difficult to determine the type of 
NAT that is present.  A question was raised whether or not this use of 183 
would interfere with "early media" via 183; this will be checked.  It was 
also proposed to extend the timeout until the "200 Ok" in solution 1, and 
there was some brief discussion of the implications of this. 

No consensus was reached on issue 1.  Jonathan will send mail to the list 
summarizing the issue and soliciting feedback.

Issue 2 is on how to prioritize addressing information in ICE.  So far, the 
intention is to minimize relaying and to prefer IPv6.  There are, 
however, are other conceivable criteria, e.g. to maximize the number of 
hops across security networks, minimize path latency, minimize number of 
router hops, etc.  The issue is (a) whether one of these criteria needs to be 
chosen and, if so, (b) which one.  Jonathan argues that this is in 
essence a policy decision and ICE does not depend on any policy.  It works as 
long as at least one uable address exists.  Nevertheless, there may be many 
parties involved with different policies and preferences. With the work of 
SIP/SIPPING on session policies (e.g. allowing service providers to 
assert policies on media streams), the ICE address preference appears 
simply as another policy. 

Jonathan proposes to not fix address preferences but rather clarify, in the 
ICE spec, that there are different axes of optimizations and, document the 
existing algorithm.  Other specs shall be allowed to define 
(informationally) other algorithms.  A reference session policy should be 
described as a non-normative approach for finding out other policies. This 
proposal was found reasonable.

Issue 3 addresses the interaction between ICE and RTP NOOP (a 
presentation on RTP NOOP was given).  The NOOP format appears to have some 
commonalities with STUN: sent to RTP port, requests an immediate (RTCP) 
response, and checks for connectivity and QoS between endpoints. The same 
(except for QoS checks) can be said for STUN used by ICE. Jonathan 
briefly described the differences: NOOP uses RTP and hence is cleaner for 
RTP sessions; but ICE works for other protocols, too.  NOOP uses RTCP for 
responses which are sent to different port and hence may not work 
through many NATs.  ICE (STUN) also provides address allocation and uses 
username/password for validation while NOOP would require SRTP. 

The obvious options, given this commonality, are to either use only NOOP, to 
use only STUN, or to use both.  There was a lot of discussion, trying to 
understand and clarify the differences between the drafts, with no clear 
conclusion.  It is plain that clarification of use cases, and of the 
relationship and overlap between the various drafts, is needed.



RTSP Update
-----------
Magnus Westerlund
- draft-ietf-mmusic-rfc2326bis-06.txt
- draft-ietf-mmusic-rtsp-nat-02.txt
- draft-zeng-mmusic-map-ice-rtsp-00.txt

Magnus presented the current status of the RTSP core spec (see slides for 
the details).  The spec has been progressing well.  Out of the 
currently logged 40 bugs almost all are solved, with only six 
unresolved ones.  The spec underwent major changes and 
restructuring: the use of RTP was rewritten, the syntax is now compiled in a 
single chapter, and a proposal on timing RTSP messages was included.  The 
numerous minor updates are listed in the slides.

Magnus discussed the open issues and their current status 
(elaborated on in detail on the slides).  There was some discussion of 
options for authentication to prevent session hijacking, including the 
possibility to mandate use of RTSP over TLS, as an alternative to 
cryptographically random session IDs. It was also noted that we need to 
understand the use cases for destination redirection, to determine how big an 
open issue this is.

Finally, Magnus presented those resolved issues that did not yet make it 
into the spec: RTSP proxies, use cases for RTSP, and the use of 
implicit redirects.

Everyone is encouraged to review the revised spec in detail and 
comment!  The editors will edit in the remaining issues.  The 
teleconferences held for discussing and resolving issues shall be 
resumed.  The goal is to finish the RTSP core spec in 2004.

Next, Magnus reported on the interactions between RTSP and NATs.  As per the 
discussion during IETF-58, a requirement section was added and the usage of 
ICE is now in a separate draft, and solution proposals (regarding 
protocol changing mechanisms) were removed.

The remaining open issues include to clarify the recommendations on 
working with ALGs, with specific recommendation to be provided for 
firewalls ALGs (which are different from NAT ALGs).  An appropriate 
protocol modifying solution needs to be chosen.  Various high-level 
proposals exist for the latter including using ICE (for a proposal exists 
which is briefly presented), embedding STUN in an RTSP server, and using 
symmetric RTP.  Interested parties are requested to write drafts; these 
should be evaluated afterwards and a single solution should be 
selected.


Temporal References within URIs
-------------------------------
Conrad Parker
- 
draft-pfeiffer-temporal-fragments-02.txt

Conrad Parker motivated the work by the need to define links to time 
points and regions within a real-time media resource (e.g. a movie) so that 
pieces of interest can be referred to directly.  The draft on 
rfc2396bis defines "?query" and "#fragment" to enable referring to a 
subpart of a resource.  This is integrated with HTTP and other download in a 
straightforward fashion: the server interprets the URI with the 
additional parameters and returns only the selected piece of the 
resource. 

Conrad notes that in RFC 2326 the handling of query identifiers and 
fragments is undefined.  He suggests specific interpretations of queries and 
fragments for handlng by the server and the client, respectively. He 
raises various issues, particularly how the mechanism can be kept 
extensible. It was noted that, while there is a clear use case for 
fragment requests, it is less obvious why queries are useful. Some 
clarification was requested.

Other short discussion suggests that -- rather than defining 
individual specific extensions for RTSP URIs and extending those every now 
and then -- it may be more appropriate if a generic header inclusion 
mechanism is defined, as for SIP.

				 - * -