Network Working Group Ross Finlayson Internet-Draft LIVE.COM Expire in six months 2001.01.24 Category: Informational Describing session directories in SDP 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract A directory containing a set of media sessions - each described using the Session Description Protocol (SDP) [1] - can itself be treated as a media session, with its own SDP description. This document shows how a session directory can be described, using SDP, within one or more other session directories. This increases the flexibility and scalability of the directory system. 3. Introduction SDP [1] is a format for describing the properties of a media session, including its IP address(es), port(s), and media type(s). The SDP descriptions for a set of media sessions can be announced in a "session directory", using a directory management protocol. (One such protocol - commonly used on multicast networks - is the Session Announcement Protocol (SAP) [2].) This document describes how a session directory can itself be treated as a media session, with its own SDP description, and announced within other session directories. This allows session directories to be organized in a hierarchy (or some more general graph). For example, a directory for announcing musical sessions might contain subdirectories representing particular musical genres (e.g., "classical", "rock"), with the actual audio sessions announced within these subdirectories. With this functionality, session directories become more scalable: All of the Internet's global session announcements no longer need to be announced within a single directory, and receivers no longer need to receive and process announcements for all of the Internet's global sessions. 4. Definition As described in the SDP specification [1], a media session is described using a "m=" line of the general form: m= A 'directory' media session is described as follows: m=application SAP SDP The only currently defined is "SAP" - representing the Session Announcement Protocol. (Additional directory management protocols, if any, might be defined by future documents.) Similarly, the only parameter currently defined is "SDP". (To describe SAP sessions containing payloads other than SDP, additional 'format' parameters might be defined by future documents.) Example: The SAP specification [2] defines a default directory for announcing global sessions. Because this particular directory is 'well-known', it does not need to be described using SDP, but if it were, it might look as follows: v=0 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP Default Directory c=IN IP4 224.2.127.254/255 t=0 0 m=application 9875 SAP SDP The SDP definition of a session directory places no 'a priori' restrictions upon its use; it merely defines "application/SAP/SDP" as another possible session media type - just like "audio" or "video". The use of this media type does, however, have implications for SDP receiving tools, SDP proxies, and SDP announcers. These issues are discussed below. 5. Implications for SDP receiving tools A SDP receiving tool (e.g., a "session browser") should always be prepared to ignore any SDP media type(s) that it does not understand. Therefore, legacy tools should not be adversely affected by the presence of 'directory' SDP sessions; they will merely be unable to launch them. A SDP receiving tool may choose to handle 'directory' sessions internally, or it may choose to treat them just like any other media type, and launch a separate tool to receive these sessions. (This tool might simply be another copy of itself.) In any case, the user interface will typically display the contents of each 'directory' session separately - e.g., in a separate window. As with other media types, a SDP receiving tool should allow for the possibility of SDP announcements containing more than one 'directory' session, or containing a mixture of 'directory' sessions and other media types. 6. Implications for SDP proxies A node may act as a proxy (or cache) for SDP announcements within one or more directories - e.g., to translate between SAP and some other directory management protocol, or for firewall traversal. To properly handle 'directory' SDP announcements, such a node should be able to proxy a set of different directories, rather than just a single directory. It is unrealistic to expect a proxy to traverse the entire graph of directory sessions, by automatically opening and listening to every 'directory' session announcement that it sees. This would eventually lead to the proxy listening to every session announcement within every possible directory - something that clearly cannot scale. Instead, a proxy should open and listen directories selectively, driven by demand from its clients. That is, a proxy should open and listen to a 'directory' session only if it knows that there is demand for this directory - and it will need a way to ascertain this demand. Example 1: Suppose that a proxy acts as a proxy/cache between SAP (a pure 'push' protocol) and a separate (unspecified) request-response protocol used by SDP-receiving clients. In this case a SDP-receiving client would use the request-response protocol to request the contents of a directory; the proxy would then respond with that cached contents of that directory. If a client requests a directory that contains one or more 'directory' session announcements, the proxy may choose to open and listen to those subdirectories (if it's not already doing so), in anticipation of the client subsequently requesting one or more of these subdirectories. Example 2: A SDP-aware firewall controller for multicast sessions may use the contents of SDP directories to decide which multicast groups are candidates to be relayed across its firewall [3]. Whenever the controller determines (by some method outside the scope of this document) that one of its internal clients wishes to participate in one of these 'candidate' SDP sessions, it would start relaying the multicast group(s) used by this session. If this session is a 'directory' session, the controller could also start listening to the contents of this subdirectory, adding these contents to its list of relaying candidates. 7. Implications for SDP announcers In general, the SDP announcement for a session is independent of participation in this session. The party or parties that create and advertise the SDP announcement for a session are not necessarily those parties that participate in a session, and the longevity of the SDP announcement can differ from that of the session itself. This is true for any media type, but it is particularly relevant for 'directory' sessions, because a directory will typically contain announcements from several different parties other than the creator of the announcement(s) for the directory itself. It is possible, in principle, for a user to see the announcement for a 'directory' session, begin creating session announcements within this directory, but then see the 'directory' session stop being advertised, rendering the directory invisible to others. To overcome this problem, parties that advertise within directories should also participate in advertising the directory itself. In particular, if a node is advertising one or more sessions within a directory D, and is also aware of directory D being advertised within other directories D', D'' etc., then it should also participate in the advertising of D within each of these other directories. 8. Security Considerations In general, the security issues for 'directory' SDP announcements are the same as those for other media types, but amplified by the fact that - as noted above - the parties that create announcements within "directory" sessions will typically be independent of the party or parties that created the announcement(s) of the 'directory' session itself. In particular, as with any media type, encryption of a session announcement does not imply confidentially of the session itself, nor does it preclude the possibility that an unencrypted version of the session announcement is visible elsewhere. 9. References [1] Handley, M., Jacobson, V., "SDP: Session Description Protocol", RFC 2327, April 1998. [2] Handley, M., Perkins, C., Whelan, E., "Session Announcement Protocol", RFC 2974, February, 2000. [3] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May 1999. 10. Author's Address Ross Finlayson, Live Networks, Inc. (LIVE.COM) email: finlayson@live.com WWW: http://www.live.com/