archives.Minutes of the MMUSIC WG Meeting at the 57th IETF

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


Reported by Joerg Ott and Colin Perkins
Notes taken by Colin Perkins


The MMUSIC WG met once at the 57th IETF.  The meeting was chaired by Colin 
Perkins and Joerg Ott.  It was attended by some 90 participants.


Status Update
-------------


Joerg Ott reported on the status of the working and the general 
progress since the 56th IETF in San Francisco:


- The new charter was finally approved.


- RFC 3524 was published on SDP extensions for reservation flows.


- Two documents are with the RFC editor: SDP extensions for NAT 
traversal and SDPng transition.


- Two documents are with the IESG, and comments have been received:


   - draft-rajeshkumar-mmusic-gpmd-03.txt was felt to overlap with work on 
capability negotiation carried out elsewhere; it was noted that this 
probably applies to most of SDP except that SDP was first. The chairs and 
authors will work with the IESG to sort this out.
   - draft-ietf-mmusic-sdp-new-13.txt received many comments which were 
discussed in a separate slot (see below).


- Two documents are under AD review:
   - 
draft-ietf-mmusic-sdp-srcfilter-05.txt
   - draft-ietf-mmusic-sdp-comedia-05.txt


- draft-ietf-mmusic-sdp-bwparam-04.txt is completing WGLC on 28 Jul 2003.


- The SDP extensions for key management 
(draft-ietf-mmusic-kmgmt-ext-07.txt) have been waiting for the MIKEY work to 
complete which seems to progress.  A further revision is expected 
shortly after the IETF.


- The SDP implementation draft 
draft-ietf-mmusic-sdp-implem-00.txt has not been revised yet, but Tom 
Taylor is working on it.  He is trying to incorporate further 
implementation experience from inside his company as well as from the 
SIPit events.


Two potential new work items have been discussed for MMUSIC:


- Real-time fax 
(draft-ietf-sipping-realtimefax-01.txt) from the SIPPING WG is to 
provide implementers with guidelines on how to use registered SDP 
attributes for ITU-T T.38.  This document actually contains two logical 
parts: the use of offer/answer mechanics (which belongs to MMUSIC) and a 
discussion of SIP-specific signaling (which belongs to SIPPING).  It is 
suggested to investigate splitting the document to deal with each one in the 
respective WG.  But it was pointed out that this document merely 
contains examples only and hence should be done as a whole in just one WG.  
To be resolved.


- Interactive connectivity establishment (ICE) also from the SIPPING WG 
(draft-rosenberg-sipping-ice-01.txt).  This is discussed later on the 
agenda.


Revised SDP 
(draft-ietf-mmusic-sdp-new-13.txt)

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


Colin Perkins reported on the changes incorporated in the latest 
revision of SDP: It was attempted to clarify when the k= attribute may be 
used.  Further clarifications include: RTP may be used with 
non-consecutive port numbers and a=charset is only allowed as a session 
level attribute.  Also, unregistered X- attributes and media format are 
deprecated.  Finally, IANA considerations and references were updated.


Colin further reported on issues raised on revision -13 on the mailing 
list, as well as from the IESG review.


- An ABNF inconsistency was found: a comment in the ABNF for 
"token-char" allowed for a larger set of characters than the actual 
definition.  One could either (1) change the comment to match the actual 
grammar (and thus reduce the set of allowed characters) or (2) modify the 
grammar to match the comment.  The group agreed to go with option (1), 
pending a check against the use of SDP in RFC 3108. Tom Taylor 
volunteered to find this out.


- The use of b= with layered coding should be clarified as follows:
When using the CT modifier with RTP, if several RTP sessions are part of the 
conference, the conference total refers to total bandwidth of all RTP 
sessions.  This was accepted in principle but it was also pointed out that a 
bandwidth specification per layer would be helpful.  Further 
discussion is needed on the mailing list.


- Again with layered coding, it should be clarified which ports are 
associated with an m= line.  The clarification proposal was accepted.


- The k= is underspecified.  The most straightforward way would be to 
deprecate the use of this field altogether.  Opinions from 
implementers are sought.  It was reported that MS Messenger uses this 
field; the details are unknown at this moment though.  As there are 
implementation out there, just deprecating this field won't work. 

  Therefore, further work needs to go into the specification of using k=.  In 
particular, when k= shall be used, a secure channel must be available and 
endpoints need to be sure that no third party can eavesdrop on the key.  
These issues, however, need to be specified by those using SDP rather than 
SDP itself. 

  The k= field currently supports an algorithm indicator, but it should 
also specify a key type.  This may be implied by the URI or the media 
protocol used.  For more complex scenarios, e.g. when more than one key is 
needed, either the sdescriptions work 
(draft-ietf-mmusic-sdescriptions-01.txt) or the key management 
(draft-ietf-mmusic-kmgmt-ext-07.txt) work should be used. 

  It was proposed that the security considerations section should change 
"SHOULD NOT deliver the user into an interactive multimedia 
session..." to "MUST NOT...".  It was found that this is an issue of user 
authorization (e.g. the user may be able to pre-authorize the 
automatic joining of certain interactive sessions) and needs to be dealt 
with by the protocols using SDP. 



- The suggestion to define a "IN" value for private address spaces was 
rejected because systems 1) cannot tell whether they are in a private 
address space (relative to their peers) and 2) this change would be not 
backward compatible.


- It will be clarified that UTF-8 normalization is not needed because 
comparisons are not done on fields with UTF-8.


- Proposal on a=inactive: it was agreed not to change the SDP spec here 
(this is an issue for users of SDP, which may establish conventions for 
use, not for SDP itself).


- Wording should be added that u= and k= may include URIs that may be 
dereferenced in some (but not all) cases.  Also, it should be noted a k= URI 
may typically be an http or https URI.  Both suggested wording 
additions were accepted.


Colin will fold the comments and the discussion into the document and 
produce a new revision out within a couple of weeks.



SDP Security Descriptions 
(draft-ietf-mmusic-sdescriptions-01.txt)

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


Dan Wing briefly reviewed the document and the changes from the 
previous revision: a new syntax is proposed for the a=crypto attribute and 
the offer/answer part is revised which may need further review. For the 
next steps, Colin noted that an IANA considerations section is needed, 
including a discussion of the registration procedures. Furthermore, 
reviewers for finishing the document were sought: Tom Taylor, Magnus 
Westerlund, and Martin Euchner volunteered. 



Offer/Answer Examples 
(draft-johnston-mmusic-offer-answer-examples-01.txt)

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


Alan Johnston presented the changes to the document: in particular, an 
example for asymmetric use of a codec has been added. This is to be 
achieved using two distinct m= lines with the same port number, one 
indicating "sendonly", the other "recvonly". The proposed behavior caused 
some discussion: it was felt that the mechanism was 
underspecified and that (therefore) m= lines with the same port would be a 
bad idea. Yet, the right approach to achieve the desired behavior seemed 
unclear. Gonzalo Camarillo pointed out that the RFC3388 provided a 
similar example, but with an explicit grouping (which is not present in 
this draft). The applicability of RFC3388 to this problem was 
discussed further. Orit Levin pointed out that the intention clearly is to 
use RFC 3388 but the question is what happens to the endpoints that don't 
support RFC 3388. Gonzalo argued that this is already defined in RFC 3388. 
The chairs stated that they would like to see the asymmetric codec 
behavior with two m= line properly specified in a document. The present 
offer/answer examples draft is meant to be illustrative; the example 
should be kept in place (with added grouping) but the normative text for 
this behavior needs to be someplace else. Flemming Andreasen suggested to 
specify part of this practice in the revised SDP. 


SDPng Update (draft-ietf-mmusic-sdpng-06.txt)

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


Dirk Kutscher presented the latest progress on SDPng, addressing the open 
issues from draft -06 (a new revision still needs to be submitted).  The 
SDPng structure has been enhanced to decouple capability negotiation for 
potential configurations from actual configuration (and the 
respective session parameters).  While the capability model has been kept, 
the syntax has been revised to exclusively rely on XML mechanisms 
(rather than embedding own syntax conventions for attributes) -- which is 
less efficient but much cleaner.  Dirk presented the new syntax using 
several examples and also showed a formal schema definition.  A further 
refinement from draft -06 is to remove the concept of libraries and use 
inline definitions instead -- so that SDPng documents would be 
self-contained. There was little discussion.  Steve Casner asked whether 
this work was getting enough traction and questioned whether people were 
really preparing for a transition.  Joerg Ott argued that people are 
desparately holding onto SDP (which is perceived easier with one small 
extension at a time) -- but that examples show that this getting more 
complicated so that SDP is likely to have only a finite lifetime.  So it 
would be nice to get broader review from the community on a 
replacements for SDP. 


RTP DoS Attacks 
(draft-rosenberg-mmusic-rtp-denialofservice-00.txt)
Interactive Connectivity Establishment 
(draft-rosenberg-sipping-ice-01.txt)

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


Jonathan Rosenberg introduced the RTP DoS problem: An attacker may easily 
direct the RTP stream(s) from an unsuspecting source to any target by 
providing the target's IP address in the SDP.  This works for SIP and RTSP -- 
with RTSP providing limited protection by allowing unicast RTP streams only 
to the address of the originator (but NATs make it worse as anyone behind 
the same NAT can easily be attacked). As authentication mechanisms can at 
most help identify the attacker (which may be very weak though), some kind of 
handshake mechanism is needed so that sources do not start sending media 
streams unless they know that the right receiver is actually waiting for it: a 
request/response mechanism using the RTP ports is needed.  This is ICE (see 
below) which has been chosen as a solution for SIP.  However, ICE has 
broader applicability and may be appropriate for RTSP, too -- which needs to 
be determined by the group.  Jonathan reviewed the properties of the ICE 
approach and briefly walked through the basic ICE algorithm.  With ICE 
being signaling protocol independent, MMUSIC is asked to take ICE up as a WG 
item.


ICE is felt to introduce quite some complexity for RTSP endpoints. If, 
however, NAT traversal (which is an RTSP issue on its own, see below) and 
security can be addressed by the same mechanism, it may be worth the 
effort.  It is noted that even if we go for the ICE mechanism for RTSP 
right now, this does not solve the problem as long as old RTSP servers are 
still out there.


Regarding the ICE proposal as a WG item Magnus Westerlund argued that if it 
is accepted, one should split the draft into several parts: the SIP use, the 
ICE mechanism, the use with offer/answer, etc. There was consensus in the 
group to accept ICE as new WG item, and to fully document the RTP DoS 
issues as an informational document.



RTSP Update 
(draft-ietf-mmusic-rc2326bis-04.txt

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


Magnus Westerlund reported on the progress of the RTSP revision, 
achieved by having a new co-editor joining the team, many 
teleconference calls, and also quite some list discussion.  He 
presented a number of changes from draft -03 (see the slides).  With this, 
most known open issues are resolved, with only a few ones remaining (see 
slides).  But many resolutions still need to be folded into an updated 
revision of the draft.  When this is done, a second phase of editing on the 
spec is needed: examples need to be fixed, the spec's consistency needs to be 
checked as needs it overall readability, and, potential new open issues 
need to be solved.  With all this, the revised RTSP spec will not meet the 
October deadline as currently documented in the MMUSIC charter.  Magnus 
suggests another six months would be appropriate to finalize the work.



RTSP and NAT 
(draft-ietf-mmusic-rtsp-nat-01.txt)

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


Magnus Westerlund introduced the revised draft on RTSP and NATs, the 
purpose of which is to describe how to traverse NATs and firewalls with 
RTSP.  It documents several possible NAT traversal approaches and gives 
recommendations regarding RTSP for firewalls.  Approaches requiring only 
modifications on the client side STUN, TURN, and RTP/RTSP tunneled in 
RTSP.  Application-Layer Gateways (ALGs) for RTSP will not require any 
modifications -- but are generally discouraged. Magnus further 
discussed open issues, particurlarly the goals for RTSP for NATs (i.e. what 
type of scenarios should be achievable) as well as possible solutions 
(symmetric RTP, STUN, ICE, DCCP).


On the ALGs: The group generally agreed that ALGs are a bad thing and 
should not be considered further (except for documentation purposes and to 
communicate this clearly to outside the IETF -- and fast, as people start 
deploying these).


On the document's purpose: Commenters state that, currently, the draft does 
not give conclusive resolution of what to do as an implementer, it is 
merely an inventory.  It is proposed to pick some solution and write it up, 
e.g. in the RTSP spec.  Magnus wants to resolve the structure of the 
document and then settle on a solution: one for the server and one or more 
for the client side.  Jonathan Rosenberg and Tom Marshal argue over the 
number of client-side solutions to be documented: Jonathan wants only one 
while Tom prefers to have multiple feasible solutions document.  In case 
multiple ones are documented, Jonathan wants exactly one "MUST 
implement" solution to ensure interoperability.


There was some further discussion on technical aspects of possible 
solutions, but no real conclusions were reached.



Internet Media Guides (IMG)
---------------------------

draft-nomura-mmusic-img-requirements-01.txt

draft-nomura-mmusic-img-framework-01.txt


After a brief introduction by Joerg Ott, Rod Walsh presented the 
progress on the IMG requirements document (which will be 
re-submitted as WG draft by end of August). He briefly reviewed the 
general topology and IMG distribution aspects and then went through the 
requirement categories identified in the draft: IMG description 
requirements and IMG transport requirements. The former primarily 
address IMG envelopes for existing meta-data formats, the latter their 
distribution in unicast and multicast, pull and push style scenarios. For 
multicast push, SAPv2 is probably inadequate, so a successor is sought, 
e.g. ALC from the RMT WG. It is pointed that additions to ALC need to be 
specified separately; while Rod wants to use the RMT proposal FLUTE, 
Lorenzo argues that this may not be 100% appropriate here; Lorenzo also 
points out that possible tasks in the RMT WG need to happen quickly as the 
group is trying to wrap up. For unicasting, client-initiated actions could 
use HTTP while notifications from the server could use SIP mechanims. 

Rod discusses on the scalability requirements IMG transport and 
presents a conceptual overview showing the different pieces of an IMG 
framework and outlines the achieved flexibility. He also addresses data 
relationships and particularly security considerations as taken into 
account in the requirements draft. 

Rod finally discusses the way ahead: the requirements draft is pretty 
close to finalization; the remaining efforts are mainly editorial and 
consolidation. The aim is to go for WGLC soon. He also points to the 
existing framework draft that will be revised by the end of August.