SDPng: first shot at requirements

[Joerg Ott <[e-mail]>]

Folks,

we have started talking about a sucessor to SDP for a while now.
We have received input from a variety of sources and have started
to draw up a small requirements document (at pre-I-D stage) that
hopefully collects most of the input which is attached below.
This document uses terminology and modeling from
draft-ott-mmusic-caps-00.txt submitted as I-D last summer.

We have also compiled a collection of input documents (which is
probably incomplete at the moment).  They can be found at

       http://www.dmn.tzi.org/ietf/mmusic/sdp-ng/

If you have additions to the documentation, please contact me
directly and I will add them to the web page.

We look forward to your comments.

Joerg

----------------------------------------------------------------------

Requirements for SDPng
======================

Dirk Kutscher, Jörg Ott, Carsten Bormann
{dku,jo,cabo}@tzi.uni-bremen.de

4 July 2000


1. Introduction

SDP allows to specify multimedia sessions (i.e. conferences, "session"
as used here is not to be confused with "RTP session"!)  by providing
general information about the session as a whole and specifications
for all the media streams (RTP sessions and others) to be used to
exchange information within the multimedia session.

  Note: Please keep in mind that whenever we use the terms
  "conference" or "interaction" this may as well apply to other types
  of multimedia communication, particularly including
  (RTSP-controlled) media streaming or broadcasting applications.

This separation into a session description and one or more media
descriptions needs to be preserved.

Currently, media descriptions in SDP are used for two purposes:

* to describe session parameters for announcements and invitations
  (the original purpose of SDP)

* to describe the capabilities of a system (and possibly povide a
  choice between a number of alternatives). Note that SDP was not
  designed to facilitate this.

A distincton between these two "sets of semantics" is only made
implictly.

A brief note on terminology (taken from draft-ott-mmusic-caps-00.txt):

* A multimedia session (or conference) consists of one or more
  conference components for multi media interaction.


* A component describes a particular type of interaction (e.g. audio
  conversation, slide presentation) that can be realized by means of
  different applications (possibly using different protocols).

* A configuration is a set of parameters that are required to
  implement a certain variation (realization) of a certain
  component. There are actual and potential configurations.

   - Potential configurations describe possible configurations that
     are supported by an end system

   - An actual configuration is an "instantiation" of one of the
     potential configurations, i.e. a decision how to realize a
     certain component.

  In less abstract words, potential configurations describe what a
  system can do ("capabilities") and actual configurations describe
  how a system is configured to operate at a certain point in time
  (media stream spec).

To decide on a certain actual configuration, a negotiation process
needs to take place between the involved peers

(a) to determine which potential configuration(s) they have in common.

(b) Out of this shared set of common potential configurations the
    peers need to select one or more to be used for information exchange
    (e.g. based upon preferences, external constraints, etc.).

In SAP-based session announcements on the Mbone, for which SDP was
originally developed, the negotiation procedure is non-existent.
Instead, the announcement contains the media stream description sent
out (i.e. the actual configurations) which implicitly describe what a
receiver must understand to participate.

In point-to-point scenarios, the negotiation procedure is typically
carried out implicitly: each party informs the other about what it can
receive and the respective sender chooses from this set a
configuration that it can transmit.

Capability negotiation must not only work for 2-party conferences but
is also required for multi-party conferences. Especially for the
latter case it is required that the process of determining the subset
of allowable potential configurations is deterministic to reduce the
number of required round trips before a session can be established.

In the following, we elaborate on requirements for an SDPng
specification, subdivided into general requirements and requirements
for session descriptions, potential and actual configurations as well
as negotiation rules.

2. General Requirements

A couple of trivial ones first (just for warming up :-)

2.1 Simplicity

    The SDPng syntax shall be simple to parse and the protocol rules
    shall be easy to implement.

2.2 Extensibility

    SDPng shall be extensible in a backward compatible fashion.
    Extensions should be doable without modifying the SDPng
    specification itself.  The spec should preclude two independent
    extensions from clashing with each other (e.g. in the naming of
    attributes).

2.3 Firewall Friendliness
    
    It should be theoretically possible for firewalls (and other
    network infrastructure elements) to process announcements
    etc. that contain SDng content. The concrete procedures have to be
    defined but if possible the processing of the SDPng content should
    be doable without interpretation of the textual descriptions.

    Firewall friendliness should not be harmed when extending the
    SDPng specification later on..

2.4 Security

    SDPng should allow independent security attributes for parts of
    a session description.  In particular, signing and/or encrypting
    parts of a session description should be supported.


2.5 Text encoding

    A concise text representation is desirable.

    A syntax should be used that allows parsing and skipping unknown
    pieces of an SDPng message.

2.6 Mapping (of a Subset) to SDP

    It shall be possible to translate a subset of SDPng into standard
    SDP session description to enable a certain minimal degree of
    interoperability between SDP-based and SDPng-based systems.
    However, as SDPng will provide enhanced functionality compared to
    SDP, a full mapping to SDP is not possible.

    It is unclear at the moment whether syntactic backward
    compatibility to SDP as per RFC 2327 is a must.  Clearly, this is
    desirable but may not need to be achieved at all cost.

    Since several flavors of SDP have been developd (e.g., the MEGACO
    WG uses certain non-SDP enhancements) it needs to be discussed which
    of these flavors need to be considered for some kind of mapping.

3. Session Description Requirements

   For now, we only consider requirements for media (stream)
   desciptions.

3.1 Media Description

    It must be possible to express the following information with SDPng:

3.1.1 Medium Type

      Payload types and format paramters for audio and video are
      well-defined and the basic semantics are clear (as defined in
      RFC1889 and RFC2327).

      Format description for text and whiteboard are currently only
      defined in the context of specific applications, this is
      probably going to change in the future (not an SDPng work item).
     
      Non-standard (in terms of defined as a non-standard payload
      type) codecs and format parameters can be accomplished by using
      dynamic payload type mappings. This is a crucial feature of SDP
      that needs to be preserved for the sake of interopability with
      RTP-applications.
     
      Current SDP only provides a= (a=fmtp) as means to specify codec
      parameters but actually gives little support on how to do this.
      Schemes for expressing more sophisticated parameters
      (e.g. supporting nesting) may be necessary.  Nevertheless, it is
      imperative to keep the overall structure of a codec description
      manageable.

      Note that there is a conflict between the desire to be able to
      use any old SDP and translate it in SDPng and the desire to have
      a more powerful structure in the SDPng data.

3.1.2 Media Stream Packetization

      SDPng need to be able to take care of more sophisticated payload
      descriptions than simple payload type assignment.  Audio/video
      redundancy coding schemes need to be supported as need other
      mechanisms e.g. for FEC (RFC 2733) and media stream repair (RFC
      2354).  Also, layered coding schemes need to be supported.

      Finally, a separation of the media encoding scheme, the
      packetization format, and possible repair schemes (and their
      respective parameters) is required.

3.1.3 Transport
      
      Since session descriptions are not only used to describe
      sessions that use IPv4/RTP for media transport it must be
      possible to specify different transport protocols (and their
      corresponding mandatory parameters).  This means SDPng must
      support different address formats (IPv4, IPv6, E.164, NSAP, ...)
      and different transport protocol stacks (RTP/UDP/IP,
      RTP/AAL5/ATM, ...).
      
      Additionally the requirement for expressing multiple addresses
      per actual configuration (layered coding support) has emerged,

      as well as the requirement for expressing multiple addresses per
      potential configuration (one port per payload type to simplify
      processing at the receiver). (A motivation has been provided by
      draft-camarillo-sip-sdp-00.txt.)
      
      In multi-unicast-scenarios it must be possible to specify more
      than one transport address for a single media stream in an
      actual configuration, i.e. by specifying address lists.

      In "broadcast"- or "lecture"-like sessions source filters might
      be needed that allow receivers to verify the source and apply
      filters in multicast sessions.

3.1.4 QoS
      
      QoS-Parameters for different protocol domains (e.g. traffic
      specification and flow specification or TOS bits for IP QoS)
      need to be specified.  draft-ietf-mmusic-sdp-qos-00.txt has
      provided a proposal for a syntax that can be used with SDP to
      describe network and security preconditions that have to be met
      in order to establish a session.

3.1.5 Other parameters (media-specific)

      Extension mechanisms that allow to describe arbitrary other
      parameters of media codecs and formats are mandatory. It is
      possibly required to distinguish between mandatory and optional
      extension parameters.

      In particular, it must be possible to introduce new (optional)
      parameters for a payload format and have old implementations
      still parse the parameters correctly.

3.1.6 Naming Hierarchy and/or Scoping

      Parameter names should be constructed in a way to that helps to
      avoid clashes and thereby simplify independent development of
      e.g. codec parameter descriptions in different groups.

4. Requirements for Capability Description and Negotiation

4.1 Capability Constraints

    Capability negotiation is used to gain a session description (a
    actual configuration) that is compatible with the different end
    system capabilities and user preferences of the potential
    participants of a conference. 

    A media capability description is the same as a potential
    configuration, as it contains a set of allowable configurations
    for different components that could be used to implement the
    corresponding component. A capability description should allow
    specifying a number of interdependencies among capabilities.
    Traditional SDP only supports alternative capabilities and the
    specification implicitly assumed that all capabilities could be
    combined and basically used at the same time (looking at the pure
    session description, at least).

    Processing power, hardware, link, or other resources may preclude
    the simultaneous use of certain configurations and/or limit the
    number of simultaneous instantiations of one or more
    configurations.  This has led to a need to express in more detail
    constraints on combinations of configurations including the
    following:

    - grouping capabilities (-> capability set);
    - expressing simultenous capability sets;
    - expressing alternative capability sets; and
    - constraining the number of uses of a certain capability (set).

    It needs to be carefully investigated how much more sophistication
    (if any) than simply listing alternatives needs to go into a base
    specification of SDPng (and which extension mechanisms for certain
    applications or for future revisions should be allowed).

    Examples are known where complex capability descriptions are
    available but are simply not used (at least not at the level of
    sophistication that would be possbile).  This strongly calls for
    keeping requirements on capability constraints rather modest
    (KISS).

4.2 Processing Rules
      
    The processing (i.e. collapsing, forwarding etc.) of different
    potential configurations in order to find a compatible subset must
    work without having to know the semantics of the individual
    parameters. This is a key requirement for extensibility.

    Additionally it must be possible to make use of different
    negotiation policies in order to reflect different conference
    types. For example in a lecture-style conference it must be
    ensured that a capability collapsing process does not yield an
    actual configuration that excludes the main source (i.e. the
    lecturer and her end system) from the conference.

    Of course, the negotiation of configurations must not only work in
    peer-to-peer-conference scenarios but also be usable in multi
    party scenarios.

    In order to allow for concise capability specification it will
    probably be required to group descriptions of, say, codecs and to
    establish a kind of hierarchy that allows to attach a certain
    attribute or parameter to a whole group of codecs.

    It might then also be required to have a naming scheme that allows
    to name definitions in order to be able to later reference them in
    subsequent definitions. This is useful in situations where some
    definition extends a previous definition by just one parameter or
    in situations where codecs are combined, for example for
    expressing redundancy or layered codings. Different models of
    re-use are conceivable.

5  Remarks
   
   Explicitely addressing the issue of capability negotiation when
   drafting the new session description language generates new sets of
   requirements, some of which might conflict with other important
   goals, such as simplicity, conciseness and SDP-compatibility.

   However, we think that it's worthwile to sketch a complete and
   powerful solution first and then later develop a migration path
   from today's technology instead of imposing limits at the outset to
   minimize the possibly necessary changes.



----------------------------------------------------------------------