[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                   Ross Finlayson
Internet-Draft                                          LIVE.COM
Expire in six months                                    2001.01.24
Category: Informational

             Describing session directories in SDP

                     <draft-ietf-mmusic-sdp-directory-type-02.txt>

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=<media> <port> <transport> <fmt list>

A 'directory' media session is described as follows:
        m=application <port> SAP SDP

The only <transport> currently defined is "SAP" - representing the
Session Announcement Protocol.  (Additional directory management
protocols, if any, might be defined by future documents.)

Similarly, the only <fmt list> 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/


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/