MMUSIC Meeting Minutes ====================== Prepared by Tom Taylor and Joerg Ott. Many thanks to Tom Taylor for taking extensive notes. MMUSIC met on Thursday afternoon and was chaired by Joerg Ott. 1. Agenda bashing ================= The proposed agenda was accepted. 2. Status Report (Joerg Ott) ============================ The revised charter is coming. The mailing list is moving to mmusic@tzi.org. The mailing list management uses majordomo. Participants will have to subscribe explicitly -- there will be no automatic transfer from the confctrl list. For some time to come, mails sent to mmusic@tzi.org will be automatically forwarded to confctrl@isi.edu. 3. SAPv2 (Colin Perkins) ======================== (draft-ietf-mmusic-sap-v2-06.txt) Status: Colin had thought SAPv2 was ready for Last Call after Washington, but the WG Last Call brought out lots of issues. One issue remains open. The following changes were made: * The timer reconsideration algorithm was changed to match the one used for RTCP. * The timeout field was removed (was used only for encrypted SAP). As it now stands, a receiver either understands the payload or the announcer sends an explicit delete, or the receiver times out the announcement because it has not heard of it for some time. * A number of editorial changes were made to the spec, including cleaning up the terminology used in the document. * All authorization schemes are now optional. The open issue: how is authentication done? In the past, it was by means of authenticated transport. The suggestion now is to use an authenticated payload instead. Colin pointed out that SAP is independent of the payload, so it is possible to authenticate the sender independently of any announcements. Mark Handley saw this as a key point: SAP is meant for use with proxies who don't necessarily understand the content. Finally, it is not just the payload but also the SAP operation (announce vs. delete) that needs authentication. The meeting agreed that both payload authentication and transport authentication are useful (and may be used alone or in combination). It was agreed to issue a new WG Last Call immediately after the IETF. 4. The SAP Server Access Issue ============================== SAP is really a server-to-server protocol. A SAP server access protocol is also needed. Amongst other things, this would allow a client to iniate an announcement and to receive selected announcements. Some people use HTTP for this purpose, others LDAP. It would be nice to have current practice documented. Colin noted that SAP gives the same scope to announcements and to data, where HTTP does not. There is a server location problem and a server communications problem. The latter can be solved in various ways once the location problem has been solved. A volunteer is requested to compile a current practice document. 5. The Directory SAP Media Type (Ross Finlayson) ================================================ (draft-ietf-mmusic-sdp-directory-type-00.txt) The SAP directory has a group address and port; hence it can be treated like any other media session. In particular, it can be advertised using SDP. Currently the draft specifies one transport: "SAP". Others such as "LDAP" are possible. "Directory" is not a top-level MIME type. Other possibilities don't seem to be quite right. Aside from this, the issues are generally the same as for other media types: * lifetime * announcers within the directory session depend on continued advertisement of the directory - announcers can participate in the advertisement of the directory - have to be careful about extension of lifetime - not a problem: announcer propagates the life of the directory - single announcer may be simpler. There are implications for SDP proxies (between SAP and some other directory management protocol or firewall). It is unscalable for the proxy to traverse the entire graph of directory sessions. The proxy should open and read only the useful directories. The question was raised: where is this work leading? It would seem to be material for an Experimental RFC, but the future of SAP itself is in question. Is it worth working on enhancements to SAP? Comments suggested that the work could be valuable, and could be useful even without SAP. The consensus was that the WG should accept the work item, with a view to producing an Experimental RFC. 6. Expressing Source Filters In SDP (Dave Thaler) ================================================= Source filters are needed for single-source sessions in 232/8. They are also needed for other Include-mode sessions. The authors presented two possible alternatives that would allow applications to express source filters in SDP: (A) a new addrtype (B) a new attribute name A reminder on the latter: the SDP specification mandates to ignore an attribute if it is not understood. Also note that c= and a= lines cannot be intermixed. Source filters are supposed to work for include mode, i.e. explicitly listing the allowed sources, as well as for exclude mode, i.e. listing those source from which data shall not be received. Is is noted that option (A) is not backward compatible and won't work in the exlude mode. Option (B) is backward compatible as legacy implementations that do not understand the new attribute will not cause problems. The authors propose option (B) to be pursued and presented a number of examples for using the new attributes "a=excl:" and "a=incl:". There is a question whether the filter should be a session-level attribute. To process the attribute, it is necessary to copy information out of the c= line and apply the filter. If the receiver ignores the information, it will try to join the group normally; this may not matter. Jonathan Rosenberg saw an application to source authentication in SIP. Ross Finlayson suggested that it would be much neater to put all of the information on the c= line, since it all relates to transport. The counter-argument was that, since it is not mandatory for the feature to work, the attribute approach is better. Steve Casner saw the filter as a media-specific attribute, so the suggestion was that both representations may be needed. The list will be asked to determine whether one way of representing the information will be chosen or both allowed. A new question: can there be domain names, or must all the entries be addresses? For IN IP4, only addresses are allowed. Can address types (IP4, IP6) be mixed? Such mixing is part of the a= proposal. How to handle multiple groups with the same filter? * group range? * multiple c= lines? * would wildcard be OK for the address part? Steve pointed out that the star notation could be used, even with a single c= line. SAP is limited to 1 kilobyte payload, which translates to around 15 IPv6 or 39 IPv4 addresses without compression. There was a suggestion: remove the limit from the specification. It was noted from the audience that no implementations are known which enforce the limit. A single-source session should have a=recvonly, but one cannot assume the reverse. The above points need to be written up. Mark Handley qualified this, saying that it should be written up outside of the SDP specification, since it is attribute-based. To add it to the SDP specification would cause the latter to recycle to Proposed status. Allison Mankin suggested that point needs discussion. 7. Specifying ATM Connections In SDP (Tom Taylor) ================================================= (draft-rajeshkumar-mmusic-sdp-atm-01.txt) In the absence of the author, Tom Taylor (taylor@nortelnetworks.com) presented the syntax for ATM connections proposed in the document. These are meant to be used specifically for narrowband telephony running over ATM AAL1 and AAL2 connections. The issues dealt with are bearer identification, specification of payloads over ATM (reusing the RTP codes), and specification of ATM QOS parameters. The main changes to SDP include specification of the "ATM" nettype and new ATM addrtypes on the c= line, m= lines modified to take account of ATM transport and ATM-based profiles, and a number of new attributes to carry bearer correlators, negotiate codec selection, and transmit various ATM-related parameters. The "$" wildcard notation is introduced on the m= line to designate portions of bearer identifiers to be selected by the recipient of the session description. Mark Handley judged the principle of SDP extension for non-IP transport to be acceptable. The c= syntax looked OK. The attributes need a consistent naming convention or they will get out of hand. There was a suggestion that the authors could learn from the RTSP experience. Alison undertook to consult with the Transport Area Directorate on whether the MEGACO or the MMUSIC WG should be prime for completing the document. Joerg Ott summed up by saying that such work should meet these criteria: * conformance to the rules of SDP syntax * no duplication of effort -- look for more general solutions where possible. The meeting expressed no opposition to allowing the work to proceed. 8. Codec Capabilities Attribute For SDP ======================================= (draft-beser-mmusic-capabilities-00.txt) An SDP media announcement has multiple interpretations: it could be an expression of capabilities, or it could be a definitive selection of parameters. One consequence of this ambiguity is that it is unclear how much payload bandwidth to reserve. This quantity is needed to use RSVP reservation. The proposal is to add an a=cap: attribute to indicate capabilities as opposed to selections. The list of payload types within the attribute would be ordered from most to least preferred. The one comment was that resource reservation and capability exchange are two different operations. 9. Caching In RTSP/RTP Servers (Mark Green) =========================================== The topic is one of dynamic replication of content to bring it nearer to users. Mark presented a list of issues to be considered when caching RTSP/RTP: * transfer loss * transform loss * cache coherency * AAA * copy protection. Transfer loss makes it difficult to create a perfect copy. This is a bigger problem with UDP transport than with HTTP, but with UDP it is easier to maintain cache coherency. There are a couple of approaches. With the packet recorder approach, loss is a problem. This is an RTP issue. The file transfer approach uses RTSP/TCP. Transfer is more reliable, but the cache needs to know the file formats. One possibility is RTSP/TCP to tyransfer RTP, with an additional metachannel to carry retransmissions. Copy protection is a concern with the possibility of rogue caches making illegal copies. Comments: Rogue caches are not an RTSP issue. The metachannel would have a special format which would depend on the data and file format being transferred. The author agreed that this was so, but hopes that a reasonably general set of classes of transfer can be defined. Further discussion is invited on the list. 10. RTSP Extensions: Additional Transports and Performance Enhancements (Sean Sheedy) ========================================================== (draft-sheedy-mmusic-rtsp-ext-00.txt) The proposed extensions are based on existing implementations at Oracle and nCube. These support a commercial broadcast environment featuring high bit rates, simple endpoints, high QOS, MPEG-2 encoding, and low latencies in the order of 250 ms. The server topology includes bridging servers along the path of transmission. The authors found it necessary to define new transports, so transport extensions are proposed, along with new profiles beyond AVP. Addreess extensions were required to make addressing unique, since DOCSIS does not allow an easy mapping between the client IP address and the optical server. Several optimizations were added for faster operation. Setup and tear-down are critical: setup should happen within 1 s, play and rewind within 200 ms. The optimizations included: * the possibility of changing the URI within PLAY, to allow reuse of transport * wildcarded URIs to represent the currently active presentation, although these have limitations because of the potential ambiguity they introduce * bandwidth reservation * two options for over-riding queued PLAY commands: Play-Now, and No-Flush. The optimizations introduced several issues. For example, how can the client tell when the end of the stream has been reached? The proposed solution is to provide a server callback: the server sends a request to the client when state transitions occur. The authors are sharing this information with an invitation to work on standardizing the suggested extensions. The question was raised: what does "extension" mean? Joerg stated that all extensions to a protocol must be backward compatible. He also asked the authors to coordinate with the MEGACO work on ATM addressing to arrive at a single general purpose extension.