Last Modified: 2004-09-29
|Done||Conduct WG Last Call for SAP Internet-Draft|
|Done||Submit a revised Internet Multimedia Conferencing Architecture I-D.|
|Done||Submit a revised SIP I-D.|
|Done||Submit SDP to the IESG for consideration as a Proposed Standard.|
|Done||Submit SAP Internet-Draft to IESG for publication as an Experimental Protocol.|
|Done||Conduct WG Last Call for RTSP Internet-Draft.|
|Done||Submit Internet-Draft on Internet Multimedia Conferencing Architecture.|
|Done||Submit RTSP to IESG for consideration as a Proposed Standard.|
|Done||Conduct WG Last Call for SIP Internet-Draft.|
|Done||Submit SIP Internet-Draft to IESG for consideration as a Proposed Standard.|
|Done||Conduct WG Last Call for SAP Security Internet-Draft.|
|Done||Conduct second WG Last Call for SAP.|
|Done||Submit SAP Internet-Draft to IESG for consideration as a Proposed Standard.|
|Done||Submit SAP Security Internet-Draft to IESG for consideration as a Proposed Standard.|
|Done||Submit IPv6 Extensions to SDP for Proposed Standard|
|Done||Submit SIP's offer/answer use of SDP for Proposed Standard|
|Done||Submit SDP4NAT for Proposed Standard (Informational?)|
|Done||Submit SDP source filter extensions for Proposed Standard|
|Done||Submit draft on SDPng motivations, comparisons with current SDP capabilities. Request charter review on SDPng work from IAB and IESG.|
|Done||Submit SDP security extension for Proposed Standard|
|Done||Submit IMG requirements and framework for Informational|
|Aug 04||Submit revised SDP spec for Proposed (or Draft) Standard|
|Done||Submit SDP Offer/Answer examples for Informational|
|Aug 04||Review work on IMGs and update charter accordingly|
|Done||Submit SDP connection-oriented media draft for Proposed Standard|
|Nov 04||Submit SDPng transition scenarios for Informational|
|Nov 04||Submit SDPng base specification for Experimental|
|Nov 04||Submit ICE draft for Proposed Standard|
|Feb 05||Submit revised RTSP spec for Proposed or Draft Standard (as appropriate)|
|May 05||Submit RTSP NAT considerations draft|
|Jul 05||Consider update of SDP specification for draft standard|
|Dec 05||Submit updated SDP Offer/Answer examples draft for Informational|
|RFC2326||PS||Real Time Streaming Protocol (RTSP)|
|RFC2327||PS||SDP: Session Description Protocol|
|RFC2543||PS||SIP: Session Initiation Protocol|
|RFC2974||E||Session Announcement Protocol|
|RFC3108||PS||Conventions for the use of the Session Description Protocol (SDP)for ATM Bearer Connections|
|RFC3259||I||A Message Bus for Local Coordiantion|
|RFC3264||PS||An Offer/Answer Model with SDP|
|RFC3266||PS||Support for IPv6 in SDP|
|RFC3388||PS||Grouping of media lines in Session Description Protocol SDP|
|RFC3524||PS||Mapping of Media Streams to Resource Reservation Flows|
|RFC3605||Standard||RTCP attribute in SDP|
|RFC3890||Standard||A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)|
Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes
61st IETF meeting, Washington DC, November 2004
Reported by Colin Perkins
The MMUSIC working group met once at the 61st IETF in Washington DC. The meeting was attended by some 80 participants. Subjects under discussion included application sharing, ICE, Internet Media Guides, SDP and various SDP extensions (for media loopback, BFCP, labels and connection establishment, security and connectivity preconditions).
Introduction and Status Update
The meeting started with an introduction and status update from the chairs. The working group has had one RFC published since the last meeting (RFC 3890 on the Session Bandwidth Modifier) and has several drafts are under IESG review: the IMG requirements and framework, SDP source filter extensions and SDP connection oriented media extensions. The draft on Alternative Network Address Types Semantics (ANAT) for the SDP Grouping Framework has been updated in response to IESG comments and is back under review. The SDP key management and security descriptions drafts are being updated in response to review comments from the IESG.
Several drafts have been discussed on the mailing list, but are not on the agenda for the meeting. Remote camera control will be discussed in AVT (draft-even-avt-h224-00.txt). RTSP (draft-ietf-mmusic-rfc2326bis-08.txt) and the ANNOUNCE extension (draft-ietf-mmusic-rtsp-announce-00.txt) are in progress, but delayed due to lack of review and editing manpower -- help was solicited. The main connection-oriented media specification (draft-ietf-mmusic-sdp-comedia-09.txt) is under IESG review, the TLS extension to comedia (draft-ietf-mmusic-comedia-tls-02.txt) is under development. Symmetric RTP (draft-wing-mmusic-symmetric-rtprtcp-01.txt) is clearly useful, but the chairs suggested it would be better suited to the AVT working group. The draft on tight membership support in SDP (draft-ekim-mmusic-sdp-membership-01.txt) conflicts with work in XCON, and should be discussed there.
The Internet Media Guide (IMG) requirements and framework are complete and under review by the IESG. We have a milestone to revise our charter to accomodate future work in this area. Work to be considered includes: IMG ANNOUNCE via FLUTE, IMG QUERY/RESOLVE via HTTP, IMG SUBSCRIBE/NOTIFY via SIP, and possibly IMG MIME types and URI/URL formats. The chairs, area director, and parties interested in IMGs will work to develop new milestones are charter text to cover this work, and bring it back to the working group for review.
ICE: A Methodology for NAT Traversal
Jonathan Rosenberg presented ICE (draft-ietf-mmusic-ice-03.txt) outlining the changes since the previous version and discussing open issues. Major changes include:
- In the ABNF, rename the "alt" attribute to "candidate" to avoid a conflict with 3GPP specs, remove the remnents of "derived-from", and change the "username" attribute to "user-frag" to more closely reflect its semantics.
- The ICE XML schema has been updated to support both IPv4 and IPv6 (the implementation of ICE using ANAT supports this already, this change brings the schema in line with reality).
- Added implementation hints on masking allocation latency.
- Updated discussion of use of TURN as an address allocation protocol, making it "SHOULD" strength rather than "MUST" strength, to reflect concerns expressed previously. Added text to explain why TURN is a good thing to implement for address allocation. Noted that other allocation protocol can be used.
- Clarified that username and password are different for each transport address.
- Discussed the misrouting scenario raised by Pete Cordell, where STUN keep-alives can be sent to a third party that isn't expecting them. This is a fundamental issue with the non-uniqueness of IP addresses across NAT-realms, not something that can be solved in ICE.
- Removed mid-session checks. STUN now runs until a media packet is received, then you revert to sending only media packets (and using media-specific means, rather than STUN, as a keep-alive). Enforces a clear separation between the STUN server and the media tool. Added a section on application-layer keep-alives.
- Add discussion on how to choose a default address.
- Now use one local transport address for each usable address. This gives a one-to-one mapping between the local address/port pair and the address that goes in SDP, simplifying the protocol and fixing some bugs, but at the cost of opening more sockets.
- Rewrote the description of re-invite handling. Cullen Jennings noted an issue with this, since reverting to an old address can fail if the NAT binding for that address has timed out. There may be a need to redo the negotiation with a new username and password.
- TURN has been promoted to a normative reference, however Cullen Jennings is worried that TURN is late and a normative reference may delay ICE. It was agreed to revert this to a reference to "some media relay protocol" using TURN as an example of a protocol with the required properties, to avoid this potential delay. Considerable discussion ensued, covering a number of these issues.
- Made RTCP information optional in SDP, since many devices don't implement RTCP. Magnus Westerlund suggested it is necessary to set the RTCP bandwidth parameter to zero, in addition to avoiding the ICE check, to inform the other end-point that RTCP isn't used. Jonathan agreed that setting the RTCP bandwidth to zero would be a good thing, but that implementations didn't do it. Rohan Mahy noted that we can say "if you don't do RTCP, you MUST do this with the signalling". After much discussion, the consensus seemed to be to make inclusion of the RTCP address/port optional, but mandate that implementations MUST include a "b=" field of zero if RTCP is not used.
- Rewrote the security and IANA considerations, and made a number of editorial fixes.
There are a number of open issues relating to mid-session checks, use of STUN vs. STUN-over-RTP, forcing symmetry, and local-to-derived mapping.
Mid-session STUN checks serve the purpose of keeping alive NAT bindings, detecting interface and NAT failures, and probing for bandwidth. If they are included, we need to specify frequency of transmission, a definition of failure and protection against flapping. There are two choices for a mid-session keepalive: STUN based and application based. STUN based mid- session checks have the advantage of being codec/transport independent, but require applications to demultiplex STUN and media data, make it hard to specify timers and only provide a partial failure detection/recovery solution. Application based mid-session checks provide a clean handoff between STUN and the media, separating problems and limiting the scope of ICE, and move timers and failure detection to the application.
Jonathan proposed to keep with the solution in the current, with STUN being used for the initial keepalive check, and application specific solutions being used after the initial check. He noted that his slide saying "Recommentation: keep stun keepalives" is wrong. Joerg Ott and Dave Oran agreed with Jonathan.
The next open issue was the use of STUN vs. STUN-over-RTP for initial connectivity checks (i.e. the 1st RTP packet's payload data is a STUN packet). The disadvantages of using STUN over RTP are that it's ugly, the request/response nature of STUN isn't well matched with RTP semantics, the RTP timestamp would jump since the STUN packets aren't really media, it doesn't work with SRTP, and it makes ICE specific to RTP. The only advantage is that is avoids a STUN/RTP demultiplex -- although that comes at the cost of embedding STUN into RTP. Dave Oran agreed with all these, provided this is done for RTCP. For RTCP, the issues are not as bad since RTCP APP packets can be used. Magnus Westerlund noted that there are other protocols and making ICE RTP specific is a mistake. The consensus of the room was that STUN-over-RTP is a mistake, especially since we now have a clean handoff between STUN and the media.
Regarding forced symmetry, the problem is that the current algorithm can result in you sending on a different port than that on which you receive media. This doesn't work if one is depending on application-level keep alives. The suggested fix is MUST send on the port on which you last received a valid RTP packet. Magnus Westerlund noted that there's a potential for flapping, but Jonathan countered that the protocol will settle to a stable state, and there are further rules to ensure one SHOULD use the highest priority address on which you got a STUN request.
Regarding local to derived mapping, previous versions of the draft allowed a single socket to be used for it's local address, and as a source of STUN and TURN requests used to determine derived addresses. This caused confusion with username-to-address mapping for the STUN and TURN requests, made it hard to determine when to stop the STUN server, and made it difficult to assess which address was used. The latest version of the draft uses distinct ports for the local address, and to run STUN and TURN to derive addresses. This avoids all the multiplexing issues, but at the expense of additional local port usage. Jonathan is worried about the port footprint, and is considering going back to the multiplexing solution (one local address for each derived address), and defining appropriate timeouts for each protocol. Rohan Mahy noted that the folks that have port issues will likely be those who have problem multiplexing, so this may not solve the problem. Dan Wing suggested that the problem is that we're lacking a message to say "STUN packet received" so why not create a stun message to say exactly that? Jonathan considered that, but thought that while it helps you turn off the STUN listener, it doesn't solve the demultiplexing issues. Cullen Jennings asked why we can't do both? The choice of one-to-one or many-to-one mappings between local and derived addresses is a local implementation choice, and which doesn't affect remote clients. Why not document the issue, and let the implementor choose? Jonathan agreed that this is a good way forward.
Magnus Westerlund noted that ICE could generate a lot of packets, and may cause congestion. It may be better to have some initial delay and to send messages in priority order. Jonathan agreed that this could reduce the amount of data sent, but increased the post-dial delay (which is a hard requirment for some applications). Joerg Ott noted that it's unlikely there are many addresses, so this may not be such a problem: maybe just add a warning note? Jonathan agreed that a discussion of the issue would be appropriate.
Magnus also worried about switching media between different addresses; we should highlight the potential congestion control issue when changing connection addresses.
Jonathan committed to revising draft immediately after the meeting, to aim for working group last call before Christmas.
Internet Media Guides
Yuji Nomura discussed Internet Media Guides. The IMG requirements and framework are with the IESG for review, so it is now time to identify the specific protocol components that need to be developed. The main items are an IMG transfer envelope, a multicast delivery method, and a subscribe/notify delivery method.
The groundwork for the unicast subscribe/notify mechanism is defined in draft-nomura-mmusic-img-notify-00.txt. Yuji noted that using HTTP doesn't meet the requirements, so the working assumption is that SIP events will be used for subscribe/notify, and there is a need to define an event package for IMG. Multicast delivery will be via FLUTE: an intial draft defining this has previously been submitted, and will be updated shortly.
In addition to the transport protocols, and envelope is needed for the data. An initial proposal (draft-walsh-mmusic-img-envelope-01.txt) exists for this and provide a common minimal set of information to manage transfer of IMG data, independent of the transport protocol. The working assumption here is to use an XML format.
Open issues include the need to define an IMG URI (e.g. img://...) and naming IMG data for encapsulation ("application/envelope+xml"?). It will also be necessary to define versioning and delta descriptions for the IMG data, to support partial transmission.
Henning Schulzrinne asked if the IMG URI is intended to identify the content or the transport, and wondered how it should be used? There was some confusion on this point, and it isn't clear how to translate from the URI to the retrieval mechanism. Clarifiation is needed.
Henning Schulzrinne discussed draft-schulzrinne-mmusic-sharing-00.txt on requirements for application sharing. This is speculative new work, and it's not clear if it belongs in MMUSIC. Our conferencing architecture is deficient in support for shared applications, and Henning has considered how this can be resolved without reinventing T.120. The presentation and draft outline the problem space and the requirements.
Rohan Mahy expressed concern that the scope being addressed here is significantly larger than he had imagined. We may want to solve the problem for named categories of application, splitting the problem space rather than "trying to boil the ocean". Dave Oran, Jonathan Rosenberg and Roni Even and also expressed similar concern regarding the scope of the work, compatibility with other systems, the form of the data to be shared, etc. Henning noted that he's raising possible requirements, not suggesting that we'll solve them all immediately. Steve Casner noted that we already have limited RTP payload formats for pointers and text events, which may feed into this work.
Joerg Ott concluded by noted that this is an intersting problem, and noted that while the negotiation of application sharing sessions is clearly in scope for MMUSIC, the application sharing protocol itself isn't. There doesn't seem to be a natural home for this work in the IETF, although we can think about it here for now.
Colin Perkins outlined the changes to draft-ietf-mmusic-sdp-new-21.txt since the last meeting (see slides for details). There are open issues regarding support for internationalized DNS, layered coding, direction attributes and the placement of the spec in context. Internationalized DNS names did not exist when the original SDP was written, so the draft doesn't indicate how they should be represented. Advice was solicited from the working group and Bernie Hoeneisen gave the suggestion that internationalized DNS names should be conveyed in the ASCII Compatible Encoding (ACE) form defined in RFC 3490, rather than in UTF-8 or some other encoding. This requires no changes to SDP, other than to note that this form should be used.
Regarding layered coding, the issues are that allocation of consecutive multicast addresses is problematic, and that the "a=rtcp:" attribute is not fully specified for layered encoding. Colin suggested that, since this part of the spec is not widely implemented, it should be left as-is for now, and updated if layered multicast transport becomes popular. No comments were received.
There was a suggestion that interactions between the direction attributes ("a=recvonly", etc.) and the offer/answer spec should be documented, and offer/answer referenced. More generally, is there need to include more context on how SDP is used with, for example, SIP? Jonathan Rosenberg and Keith Drage suggested that these interactions are defined in other drafts, so there's no need to add anything to the SDP spec.
SDP Extension for Media Loopback
Kaynam Hedayat discussed draft-hedayat-media-loopback-01.txt. The goal of this draft is to enable SIP endpoint to initiate calls with media loopback. It introduces two SDP media attributes, giving the type and mode of the loopback and is based on the offer/answer model.
Colin Perkins and Dave Oran were uncomfortable with the requirement that endpoints MUST support RTCP-XR, and suggested that support for RTCP-XR be OPTIONAL. The loopback attribute is more general than voice over IP applications, so there is no way a particular subset of RTCP-XR support can be mandated.
Magnus Westerlund expressed concern that the security aspects of this new attribute haven't been fully considered, and that it may introduce potential packet bombing attacks. This issue needs to be documented.
The consensus of the room was that this a good idea, and should be adopted as an MMUSIC work item.
SDP Extension for BFCP
Gonzalo Camarillo presented (draft-camarillo-mmusic-sdp-bfcp-00.txt) on the SDP extensions needed to support the XCON binary floor control protocol. BFCP is defined under the "application/bfcp" media type and runs over TCP. It fits into SDP as a transport protocol with connection establishment is handled by the comedia framework. The "k=" line can be used to convey the shared secret needed by BFCP, and attributes are defined to convey the confid and userid. Mapping between floor IDs and streams can be done using the SDP label attribute. There is an open issue regarding the need for a nonce attribute, which will be discussed in XCON.
The consensus of the room was to accept this as an MMUSIC work item.
SDP Label Attribute
Gonzalo Camarillo presented (draft-ietf-mmusic-sdp-media-label-00.txt) on the SDP label attribute. The main issue at the last meeting was why label media streams, rather than referring to the n'th media stream. It has been clarified that this is so static documents can be created that refer to specific media streams within future SDP files, without having to revise those static documents if the type or order of the media in those future sessions changes.
The authors asked for the draft to go to working group last call. Colin Perkins raised an issue that the label is defined as "any octet string" but needs to be restricted to octet strings that can be represented in SDP (i.e. printable ASCII). The working group last call will be issued after the meeting, with this comment being fixed as an editorial clarification after the last call.
SDP Connection Establishment Precondition
Gonzalo Camarillo presented (draft-ietf-mmusic-connection-precon-00.txt) on SDP connection establishment preconditions, briefly noting that the SIP working group is performing an expert review of the draft.
SDP Security Precondition
Flemming Andreasen gave an overview of the SDP security precondition draft (draft-andreasen-mmusic-securityprecondition-02.txt). The problem that it solves is when an offer includes several security descriptions from which the answerer picks one and sends secure media. The media can start to arrive before the answer, but cannot be be decoded since the offerer doesn't know which security parameters were chosen. Hence a new precondition is defined to delay completion of the call until all parties have agred on the security parameters.
Changes in this version are to clarify the definition of "send" and "recv" security preconditions, add more detail in the example flow, and add security considerations. This is needed by SIP, and there are no known open issues.
Colin Perkins asked that an example be included using the kgmnt-ext form of SDP signalling, in addition to the sdescriptions examples, but otherwise agreed that the draft was in good shape. The authors were requested to make this change, and submit the draft as a working group draft, then a working group last call could start.
SDP Connectivity Precondition
Flemming Andreasen also presented the SDP connectivity preconditions (draft-andreasen-mmusic-connectivityprecondition-01.txt). This draft defines a precondition to ensure there is media stream connectivity between offerer and answerer prior to proceeding with session establishement. It doesn't mandate a particular mechanism to verify connectivity.
Changes in this version are to clarify the definition of "send" and "recv" preconditions, add more detail in the example flow, and add security considerations. Open issues include adding an explanation of the relationship between this and ICE, and explaining how it will interact with SIP forking.
Colin Perkins asked that this draft be clearer on the difference between it and the connection precondition, in particular to be careful about the precondition names (i.e. "con" vs. "conn"). Paul Kyzivat noted that we have many preconditions, and worried about use cases and feature interaction. It may be appropriate to consider documenting possible interactions? Henning Schulzrinne raised a general concern that the precondition framework may be covered by IPR?
It was agreed that this draft should become an MMUSIC work item.
-- + --