Multiparty Multimedia Session Control Working Group Minutes

Reported by Colin Perkins

The MMUSIC working group met once at the 55th IETF meeting in Atlanta.  We 
discussed SDP key management and media security descriptions, media 
format independent SDP parameters, SDP bandwidth modifiers, examples of the 
offer/answer model, Internet Media Guides, XML schema for video control and 
the revised RTSP specification.

Agenda Bashing and Status update

The meeting started with an introduction and status report by Joerg Ott.  
The SIMCAP draft has been published as RFC 3407, and the FID draft is in the 
RFC Editor's queue. The comedia, sdp4nat and SDPnew drafts are still with 
the IESG. The draft on reservation flows is completing its working group 
last call, and will be submitted to the IESG for publication as a 
proposed standard immediately after the meeting.

There have been minor changes to the SDP spec, to address comments from the 
list. We are waiting for feedback from our area director before we can 
progress this further. There has been no recent update to the SDPng 
draft, but the authors are working on a new version that will have some 
internal reorganization, will focus on the offer/answer model, and will 
leave multiparty content-independent negotiation for a future 
extension document. 

The SDPng Transition draft 
(draft-ietf-mmusic-sdpng-trans-02.txt) has been revised, and is largely 
complete. Feedback is solicited, we plan to issue a working group last call 
shortly.

The SDP Source Filter draft 
(draft-ietf-mmusic-sdp-srcfilter-02.txt) seems to be complete. Joerg asked if 
a working group last call would be appropriate? There were no 
objections, and a last call will be issued shortly. 

The comedia draft is, in principle, complete but concerns have been 
raised about applicability in the presence of middle-boxes. Joerg Ott 
outlined his understanding of the issues. Jonathan Rosenberg disagreed with 
Joerg's formulation: rather the issue is that there'a a strong coupling 
between session lifetime and connection lifetime, and problems reusing 
connections. This causes too much load and bad congestion state.  
Jonathan suggested updating the comedia spec to address these 
concerns.  Allison Mankin asked if this needs just a relatively small 
change rather than an elaborate extension? Jonathan expected the changes to 
be small.  Joerg Ott noted that we need to understand the muxing and 
binding mechanisms. Jonathan agreed, since right now there are problems due 
to NAT, firewalls, etc. Jonathan said he would produce a concrete 
proposal on what needs to be changed in comedia "within a month", else we 
will go ahead with the existing specification.

Joerg noted that the working group charter is out of date. The chairs will 
work on updated milestones and charter, to be circulated to the list for 
comments. Suggested new work items may include Internet Media Guides and 
Floor Control, but these need to be discussed with the area directors 
before any decision is taken.

MIKEY/Key Management with SDP

Allison Mankin (Transport Area director) and Eric Rescorla (security 
advisor for the transport area) outlined their concerns with the key 
management model for SDP and the MIKEY draft. Eric's concern is the 
binding between MIKEY and SDP, which allows multiple key management 
protocols, such as IKE, S/MIME, etc. There is no protection against 
downgrade attacks during the protocol negotiation. 

Elisabetta Carrara noted that there is a recommendation in the draft to 
choose between appropriate crypto-suites, but this did not satisfy Eric.  
Jonathan Rosenberg said that his understanding is that using MIKEY with SDP 
is not sufficient, the SDP will be protected with S/MIME anyway and hence 
S/MIME provides the protection against downgrade attacks. Eric asked why, if 
you have S/MIME already, do you need MIKEY? Elisabetta noted that we don't 
commit to S/MIME, but Eric countered that, to have reasonable 
security, S/MIME or similar protection is needed in addition to MIKEY. 
Discussion continued for a while with no real resolution.  Allison Mankin 
committed provide a written review of the draft, with detailed comments for 
discussion on the list.

SDP Security Descriptions for Media Streams

Mark Baugher outlined the new draft on SDP Security Descriptions for Media 
Streams 
(draft-baugher-mmusic-sdpmediasec-00.txt). This is an alternative means of 
exchanging keying material, to be used when the SDP message is securely 
delivered. Accordingly it is expected to be complementary to key 
management with MIKEY. 

Mark outlined the limitations of the existing "k=" line, described the 
proposed "a=crypto:" attribute, and outlined use with the 
offer/answer model. Jonathan Rosenberg asked unclear why you'd want to do 
separate security properties on a codec by codec basis since this seems to be 
the cause of a lot of complexity? 

Mark asked if this could become an MMUSIC work item. The chairs agreed that 
the work is a good thing to do, but need to figure out the correct home for 
it. 

SDP attribute for qualifying Media Formats with Generic Parameters

Flemming Andreasen presented 
draft-rajeshkumar-mmusic-gpmd-01.txt, the format independent parameter that 
can apply to existing MIME types. He outlined the background to the 
draft, signalling voice-band data, and noted issues with the current 
draft: it is very open-ended and needs to be more limited in scope; it 
needs to specify interactions with the offer/answer model; and it needs a 
procedure for registration of new gpmd parameters. 

Jonathan Rosenberg recommend that parameter specifications suggest the 
actual interaction with offer/anser. He also suggested that we require new 
parameters to be standards track.

A Transport Independent Bandwidth Modifier for SDP

Magnus Westerlund outlined 
draft-westerlund-mmusic-sdp-bwparam-01.txt, on a new set of SDP 
bandwidth modifiers that signal session bandwidth in a transport 
independent manner. These are intended to solve problems due to NATs and 
protocol translation, that make the existing parameters less than 
useful.

Steve Casner noted that biggest open issue is whether we really need to 
make the change at all? Magnus noted that the bandwidth can increase by 25% 
with IPv6, compared with the value currently signalled, a compelling 
argument for the new parameters. Steve disagreed, noting that the RTCP 
bandwidth doesn't have to be that accurate, and that this level of 
inaccuracy is unlikely to be problematic. He also said that a stronger 
point is bandwidth allocaton for links, where it seems likely that for 
tightly controlled channels, header compression will be used, so the 
difference between v6 and v4 goes away. 

SDP Offer Answer Examples

Alan Johnston outlined 
draft-johnston-mmusic-offer-answer-examples-00.txt, giving a series of 
examples and scenarios for the use of offer/answer.  The group 
expressed interest. Joerg Ott asked that the draft be expanded to give some 
pointers to why the examples are correct.

A Framework for Internet Program Guides

Yuji Nomura discussed 
draft-nomura-mmusic-pguide-framework-00.txt, a new framework for 
Internet Program Guides that has evolved out of the drafts that were 
discussed in Yokohama. There are a number of open issues: can this become a 
charter item of MMUSIC? Revision of requirements? Choice of protocol for 
announcements? Appropriate description format? 

There was much discussion of the naming of the work, with many people 
disliking the term "Internet Program Guide". It was decided to call the 
work "Internet Media Guides" from now on.

Joerg Ott noted that many description formats could be used, and that we 
would not want to restrict ourselves to a single format. Similarly, we 
would not want to define a new format within MMUSIC, but instead use the 
existing solutions.  

Henning Schulzrinne asked that we take a step back to see what we learnt 
from SAP. Other things have happened in the space of event 
notification, and SAP hasn't been a clear success because of the service 
model, etc.  We want to revisit, and see what we've learnt.

The chairs noted that this work is not within the MMUSIC charter. They will 
work with the area director, to determine if MMUSIC is appropriate for this 
work, or if it should occur elsewhere.

XML Schema for Media Control

Orit Levin outlined 
draft-levin-mmusic-xml-media-control-00.txt, an XML schema for media 
control. Orit noted that several alternative approaches have been 
discussed previously (CODEC specific RTP/RTCP primitives, RTCP feedback as 
for loss recovery, SDP extensions) but rejected for various reasons. They 
therefore propose the use of an XML scheme conveyed using a reliable 
protocol. The primitive commands are "picture fast update", "GOB fast 
update", "MB fast update" and a "picture freeze" command. This is 
encapsulated in the SIP INFO method, and next steps are to define the 
encapsulation.

Steve Casner noted that he is sure an XML schema can be defined for this 
purpose. A more critical question might be how it is transported, and if the 
result will work. Rohan Mahey noted "if I could go back in time and undo 
INFO, so it didn't exist, I'd be very happy". He noted the issue is that 
this is media oriented, and should be sent with the media. Asked if some 
form of RTCP based approach might be more appropriate?

Henning Schulzrinne expressed concern about re-inventing SOAP on the sly. 
Besides asking whether this belongs in SIP or not, we don't need yet 
another RPC protocol. If it is an RPC mechanism we should ask how we can 
make exisitng RPC solutions work in this context? He also asked if there is a 
need for a traditionally reliable mechanism, and how it relates to other 
work on, for example, floor control?

Nermeen Ishmail noted that there is a real problem of using SIP, since if 
you lose the control path, you lose the media. This leads towards using 
RTCP, but there is an interoperability problem with that since H.323 
systems convey this information in the control path. Accordingly, we 
should steer away from RTCP, and use a media control protocol. There was 
concern that this would not work either, due to the latency of the 
control channel.

Jonathan Rosenberg noted that this might be a perfect candidate for a SOAP 
protocol, signalled in SDP? Henning agreed that SOAP works today, but 
there is a need for a way of associating SOAP connections with a media 
stream, in SDP. Orit asked where should we do SOAP work, since it is 
unclear if MMUSIC is the appropriate forum? The answer seems to depend on 
the form of the final solution.

RTSP Update

Magnus Westerlund outlined recent changes to the revised RTSP draft 
(draft-ietf-mmusic-rfc2236bis-02.txt) and gave a pointer to the bug 
tracker at http://rtspspec.sourceforge.net/. He asked for the group to 
review the updated specification, and noted that teleconferences to 
discuss changes will resume shortly. He also outlined major open issues.

This first open issue is redirect: shall the server be allowed to close a 
session as soon as the clients ACKs the REDIRECT? And what should be done 
with the 3xx codes? 

Magnus noted that the authors are lacking experience with RECORD. It seems 
that the spec needs significant clarifixation on how to use it, and that 
there are many open issues. Input was requested from someone who has 
implemented RECORD, otherwise the authors proposed to remove it from the 
base specification (leaving it as an extension document). Steve Casner said 
he was pretty sure that IP/TV used RECORD, and that this may provide 
implementation experience? Rob Lanphier explained that we need people to 
document what they're doing with RECORD, not just to list 
implementations. Henning Schulzrinne asked if the issues with RECORD might be 
somewhat similar to WEBDAV style protocols, and if experience in that 
field may be helpful? 

Other open issues exist with Appendix C, the Accept-Ranges header, the Via 
header, Negative Scale, TLS support, RTSP over UDP, etc. A bar BOF was 
scheduled for later in the week to discuss these, and discussion will 
continue via the mailing list and teleconferences.