Internet DRAFT - draft-ietf-mmusic-sdp-capability-negotiation-reqts

draft-ietf-mmusic-sdp-capability-negotiation-reqts



MMUSIC Working Group                                       F. Andreasen 
Internet Draft                                            Cisco Systems 
Expires: September 2007                                   March 4, 2007 
                                    
 
                                      
                        SDP Capability Negotiation: 
                 Requirements and Review of Existing Work 


         draft-ietf-mmusic-sdp-capability-negotiation-reqts-01.txt 


Status of this Memo 

   By submitting this Internet-Draft, each author represents that       
   any applicable patent or other IPR claims of which he or she is       
   aware have been or will be disclosed, and any of which he or she       
   becomes aware will be disclosed, in accordance with Section 6 of       
   BCP 79. 

   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 

   This Internet-Draft will expire on September 4, 2007. 

Copyright Notice 

   Copyright (C) The IETF Trust (2007). 

Abstract 

   The Session Description Protocol (SDP) was intended for describing 
   multimedia sessions for the purposes of session announcement, session 
   invitation, and other forms of multimedia session initiation. SDP was 
 
 
 
Andreasen             Expires September 4, 2007                [Page 1] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

   not intended to provide capability indication or capability 
   negotiation, however over the years, SDP has seen widespread adoption 
   and as a result it has been gradually extended to provide limited 
   support for these. SDP and its current extensions however do not 
   have, for example, the ability to negotiate one or more alternative 
   transport protocols (e.g. RTP profiles) which makes it particularly 
   difficult to deploy new RTP profiles such as secure RTP and RTP with 
   RTCP-based feedback. The purpose of this document is to identify a 
   set of requirements for SDP Capability Negotiation and evaluate 
   existing work in this area. The document does not provide any 
   solutions to SDP Capability Negotiation 

Conventions used in this document 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in [RFC2119]. 

Table of Contents 

    
   1. Introduction...................................................3 
   2. Requirements...................................................5 
   3. Review of Existing Work.......................................10 
      3.1. Grouping of Media Lines..................................10 
      3.2. Session Description Protocol (SDP) Simple Capability 
      Declaration...................................................11 
      3.3. Session Description and Capability Negotiation (SDPng)...12 
      3.4. Multipart/alternative....................................14 
      3.5. Sharing Ports Between "m=" Lines.........................15 
      3.6. Opportunistic Encryption Using a Session Attribute.......16 
      3.7. Best-Effort Secure Real-Time Transport Protocol..........17 
      3.8. Opportunistic Encryption using Probing...................18 
   4. Security Considerations.......................................18 
   5. IANA Considerations...........................................18 
   6. Acknowledgments...............................................18 
   7. Change Log....................................................18 
      7.1. draft-ietf-mmusic-sdp-capability-negotiation-reqts-01.txt18 
      7.2. draft-ietf-mmusic-sdp-capability-negotiation-reqts-00.txt19 
      7.3. draft-andreasen-mmusic-sdp-capability-negotiation-reqts-
      00.txt........................................................19 
   8. References....................................................20 
      8.1. Normative References.....................................20 
      8.2. Informative References...................................20 
   Author's Addresses...............................................22 
   Intellectual Property Statement..................................22 
   Full Copyright Statement.........................................22 
 
 
Andreasen             Expires September 4, 2007                [Page 2] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

   Acknowledgment...................................................23 
    
1. Introduction 

   The Session Description Protocol (SDP) was intended for describing 
   multimedia sessions for the purposes of session announcement, session 
   invitation, and other forms of multimedia session initiation. The SDP 
   contains one or more media stream descriptions with information such 
   as IP-address and port, type of media stream (e.g. audio or video), 
   transport protocol (possibly including profile information, e.g. 
   RTP/AVP or RTP/SAVP), media formats (e.g. codecs), and various other 
   session and media stream parameters that define the session.  

   Simply providing media stream descriptions is sufficient for session 
   announcements for a broadcast application, where the media stream 
   parameters are fixed for all participants. When a participant wants 
   to join the session, he obtains the session announcement and uses the 
   media descriptions provided, e.g., joins a multicast group and 
   receives media packets in the encoding format specified.  If the 
   media stream description is not supported by the participant, he is 
   unable to receive the media.  

   Such restrictions are not generally acceptable to conversational 
   multimedia session invitations, where two or more entities attempt to 
   establish a media session using a set of media stream parameters 
   acceptable to all participants. First of all, each entity must inform 
   the other of its receive address, and secondly, the entities need to 
   agree on the media stream parameters to use for the session, e.g. 
   transport protocols and codecs. We here make a distinction between 
   the capabilities supported by each participant and the parameters 
   that can actually be used for the session. More generally, we can say 
   that we have the following: 

   o  A set of capabilities, or potential configurations of the media 
      stream components, supported by each side.  

   o  A set of actual configurations of the media stream components, 
      which specifies which media stream components to use and with what 
      parameters. 

   o  A negotiation process that takes the set of potential 
      configurations (capabilities) as input and provides the actual 
      configurations as output.  

   SDP by itself was designed to provide only the second of these, i.e., 
   the actual configurations, however over the years, use of SDP has 
   been extended beyond its original scope.  Session negotiation 
 
 
Andreasen             Expires September 4, 2007                [Page 3] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

   semantics were defined by the offer/answer model in RFC 3264 
   [RFC3264].  It defines how two entities, an offerer and an answerer, 
   exchange session descriptions to negotiate a session. The offerer can 
   include one or more media formats (codecs) per media stream, and the 
   answerer then selects one or more of those offered and returns them 
   in an answer. Both the offer and the answer contain actual 
   configurations - potential configurations are not supported. The 
   answer however may reduce the set of actual configurations from the 
   offer.  The answerer may also include additional media formats in the 
   answer, however those media formats can only be used in the answerers 
   receive direction.  Such additional media formats would be actual 
   configurations as well.  

   Other relevant extensions have been defined. Simple capability 
   declarations, which defines how to provide a simple and limited set 
   of capability descriptions in SDP was defined in RFC 3407.  Grouping 
   of media lines, which defines how media lines in SDP can have other 
   semantics than the traditional "simultaneous media streams" 
   semantics, was defined in RFC 3388, etc.   

   Each of these extensions was designed to solve a specific limitation 
   of SDP.  Since SDP had already been stretched beyond its original 
   intent, a more comprehensive capability declaration and negotiation 
   process was intentionally not defined.  Instead, work on a "next 
   generation" of a protocol to provide session description and 
   capability negotiation was initiated [SDPng].  SDPng however has not 
   gained traction and has remained as work in progress for an extended 
   period of time.  Existing real-time multimedia communication 
   protocols such as SIP, RTSP, Megaco, and MGCP continue to use SDP.  
   SDP and its current extensions however do not address an increasingly 
   important problem: the ability to negotiate one or more alternative 
   transport protocols (e.g., RTP profiles).  This makes it difficult to 
   deploy new RTP profiles such as secure RTP (SRTP) [SRTP], RTP with 
   RTCP-Based Feedback [AVPF], etc.  This particular problem is 
   exacerbated by the fact that RTP profiles are defined independently.  
   When a new profile is defined and N other profiles already exist, 
   there is a potential need for defining N additional profiles, since 
   profiles cannot be combined automatically.  For example, in order to 
   support the plain and secure RTP version of RTP with and without 
   RTCP-based feedback, four separate profiles (and hence profile 
   definitions) are needed: RTP/AVP [RFC3551], RTP/SAVP [SRTP], RTP/AVPF 
   [AVPF], and RTP/SAVPF [SAVPF].  In addition to the pressing profile 
   negotiation problem, other important real-life constraints have been 
   found as well.  

   The purpose of this document is two-fold.  

 
 
Andreasen             Expires September 4, 2007                [Page 4] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

   1. Identify a set of requirements for a SDP capability negotiation 
   mechanism that will enable SDP to provide limited support for 
   indicating potential configurations (capabilities) and negotiate the 
   use of those potential configurations as actual configurations.   

   2. Review relevant existing work in the area of SDP capability 
   negotiation and see how it aligns with the proposed requirements.  

   It should be noted, that it is not the intent to provide requirements 
   for a full-fledged capability indication and negotiation mechanism 
   along the lines of SDPng [SDPng] or ITU-T H.245 [H245]. Rather, the 
   focus is on identifying requirements for addressing a set of well-
   known real-life limitations.  

   The rest of the document is structured as follows. In Section 2, we 
   provide a set of requirements for SDP capability negotiation, and in 
   Section 3, we review relevant existing work in this area, how a 
   solution based on that work might look, and the pros and cons 
   associated with each. An actual solution to the proposed requirements 
   will be provided separately.  

2. Requirements 

   REQ-10: It MUST be possible to indicate and negotiate alternative 
   media formats on a per media stream basis. 

      For example, many implementations support multiple codecs, but 
      only one at a time.  Changes between codecs cannot be done on-
      the-fly, e.g. when receiving a simple RTP payload type change. 

   REQ-20: It MUST be possible to indicate and negotiate alternative 
   attribute values ("a=") on a per media stream basis.  

      For example, T.38 [T38] defines new attributes that may need to 
      be conveyed as part of a capability. Also, alternative SRTP 
      keying mechanisms (e.g. [SDES] and [KMGMT]) may use SDP 
      attributes to negotiate SRTP keying material. 

   REQ-25: It MUST be possible to indicate and negotiate alternative 
   attribute values ("a=") at the session level.    

      For example, [KMGMT] may indicate alternative key management 
      material for MIKEY [MIKEY] at the session level. 

   REQ-30: It MUST be possible to indicate and negotiate alternative 
   media format parameter values ("a=fmtp") per media format on a per 
   media stream basis. 
 
 
Andreasen             Expires September 4, 2007                [Page 5] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

      For example, a media format (codec) indicated as an alternative 
      capability may include fmtp parameters.  

   REQ-40: It MUST be possible to indicate and negotiate alternative 
   transport protocols, e.g. different RTP profiles, on a per media 
   stream basis.  

      For example, "RTP/AVP" and "RTP/SAVP" may be alternatives. 

   REQ-50: It MUST be possible to indicate and negotiate alternative 
   transport protocol and media type combinations on a per media stream 
   basis. 

      For example, an entity may support a fax call using either T.38 
      fax relay ("m=image <port> udptl t38") or PCMU ("m=audio <port> 
      RTP/AVP 0").  

   REQ-80: The mechanism MUST be backwards compatible for SIP endpoints; 
   an entity that does not support the mechanism should behave as if the 
   mechanism was not present in the signaling the first place.   

      The above is referred to as "best-case" backwards compatibility. 
      Another form of backwards compatibility could result in an error 
      message indicating the extension is not supported, however this 
      has undesirable side-effects for SIP (heterogeneous error 
      response forking problem - HERFP) and leads to additional 
      signaling. Another form of backwards compatibility would have an 
      entity that does not support the extension behaving differently 
      than it normally would (but not failing), possibly followed by 
      additional signaling to remedy this.  

   REQ-85: The mechanism SHOULD attempt to be as backwards compatible 
   and friendly as reasonably possible for SIP middle-boxes. A SIP 
   middle-box is here defined as a SIP entity between two SIP endpoints 
   in a session, that may or may not have the media associated with the 
   SIP session traverse through it. In either case, the middle box may 
   have a need to understand the details of the media streams for the 
   session.  

      For example, a SIP middle-box may inspect the SDP exchanged to 
      determine what Quality of Service to authorize for the associated 
      media streams. While such middle boxes are not part of the SIP 
      architecture or the Internet per se, they do exist in many real 
      life scenarios, and we have a desire to provide a solution for 
      those. A SIP middle-box such as the above, may be affected by a 
      solution to the requirements provided above. For example, if the 
      SDP exchanged appears to negotiate use of plain RTP, but in 
 
 
Andreasen             Expires September 4, 2007                [Page 6] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

      reality, extensions are being used that result in Secure RTP with 
      an added authentication tag being used, then the middle-box above 
      may authorize less bandwidth than necessary. Similarly, if it 
      tries to process media, unexpected results may occur. This is why 
      such middle-boxes in theory should not pass SDP through them, if 
      said SDP contains one or more attributes they do not understand 
      or support. However, in practice, many SIP middle-boxes 
      nevertheless do in an attempt to be as minimally invasive as 
      possible. The alternative would be for a new extensions to either 
      never make it through such middle-boxes or have SIP methods using 
      them be rejected. The requirement provided here is to try and aid 
      such middle-boxes under the assumption that they will be upgraded 
      to support the extensions that will be defined, and hence the aid 
      provided need not be optimal.  

   REQ-90: The mechanism MUST either be backwards compatible for Megaco 
   and MGCP or it MUST be possible to interwork it with Megaco and MGCP 
   without any additional signaling between the MGC and its peer (e.g. 
   another SIP UA as opposed to a media gateway).  

      For example, if a media gateway controller (MGC) uses SIP to 
      communicate with peers, and the MGC uses Megaco or MGCP to 
      control a media gateway, it must be possible to translate between 
      the mechanism and normal SDP. Avoiding interworking requirements 
      in the MGC is desirable.  

   REQ-100: The mechanism MUST work within the context of the 
   offer/answer model [RFC3264]. Specifically, it MUST be possible to 
   negotiate alternatives within a single offer/answer exchange. 

   REQ-110: The offer/answer model requires the offerer to be able to 
   receive media for any media streams listed as either "recvonly" or 
   "sendrecv" in an offer, as soon as that offer is generated.  The 
   mechanism MUST preserve this capability for all actual configurations 
   included in an offer.  

      Potential configurations do not have such a requirement.  

   REQ-120: The mechanism MUST enable inclusion of potential 
   configurations (alternative capabilities) in the offer - the answer 
   would then indicate which, if any of these potential configurations 
   were accepted. The offerer is not required to process media for a 
   specific potential configuration until the offerer receives an answer 
   showing that potential configuration was accepted. 

      Note that this implies that it may not be possible for the 
      offerer to process early media generated using a potential 
 
 
Andreasen             Expires September 4, 2007                [Page 7] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

      configuration (as opposed to the actual configuration) until the 
      answer has been received.  

   REQ-121: The mechanism SHOULD enable inclusion of potential 
   configurations for each offered media stream in the answer. The 
   offerer may wish to use such potential configurations as input to 
   generating additional offers subsequently.  

   REQ-122: The mechanism SHOULD enable inclusion of additional media 
   streams beyond those offered in the offer or accepted in the answer 
   as latent potential configurations, provided this does not unduly 
   complicate the mechanism. Latent potential configurations cannot be 
   promoted to actual configurations in the current offer/answer 
   exchange.  

      For example, an offerer that offers only audio, but is also able 
      to support video, may want to indicate this.  Similarly, an 
      answerer that receives an offer for audio only, but is able to do 
      video may want to indicate this. Such capabilities are purely 
      information in the current offer/answer exchange - use of them 
      cannot be negotiated until a new offer/exchange is performed.  

   REQ-130: The mechanism MUST work as well as existing offer/answer 
   procedures in the presence of SIP forking. The mechanism MUST NOT 
   introduce any new failure scenarios for SIP forking.  

   REQ-140: The mechanism SHOULD be reasonably efficient in terms of 
   overall message size.  

      This is a relative requirement to evaluate alternative solutions 
      as opposed to an absolute and quantifiable requirement. Use of 
      compression techniques can help reduce the size of text-based 
      messages, however it is still considered important to try and 
      keep the message size reasonably small.  

   REQ-150: It SHOULD be possible to specify valid combinations of media 
   lines. 

      For example, an entity may be able to support audio and video or 
      audio and IM, but not video and IM (or all three). 

   REQ-160: It SHOULD be possible to specify valid combinations of media 
   formats between media streams. 

      For example, there may be constraints on which combinations of 
      audio and video codecs can be supported.  

 
 
Andreasen             Expires September 4, 2007                [Page 8] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

   REQ-170: The mechanism MUST be extensible and allow for new types of 
   capabilities to be specified and used in potential and actual 
   configurations.  

      For example, the mechanism could be extended to negotiate unicast 
      or multicast addresses as alternatives. 

   REQ-300: The mechanism provided MUST be modular inasmuch as it can be 
   divided into a required core set of functionality that all entities 
   MUST support and an optional set of enhancements that entities MAY 
   support. Entities that implement different sets of enhancements MUST 
   be fully interoperable, albeit possibly with reduced functionality in 
   terms of the actual negotiation performed.  

      For example, not all entities may implement support for REQ-150 
      and REQ-160 

   REQ-301: The mechanism MUST provide a way for both the offerer and 
   the answerer to indicate the current version(s) of the mechanism 
   supported as well as the enhancements supported. 

   REQ-302: The mechanism MUST provide a way for the offerer to indicate 
   the version and enhancements that are used by the offerer and must be 
   supported by the answerer (and vice versa), in order to correctly 
   process the SDP capability negotiation in the offer (or answer).  

      Note that this requirement applies to the SDP capability 
      negotiation part of the SDP only - other SDP extensions are 
      unaffected by this.  

   REQ-310: The following requirements are considered enhancements as 
   defined in REQ-300:  

   o  REQ-10 (alternative media formats) 

   o  REQ-30 (alternative fmtp parameters) 

   o  REQ-50 (alternative combinations of transport protocol and media 
      type) 

   o  REQ-122 (additional media streams as latent configurations) 

   o  REQ-150 (valid combinations of media lines) 

   o  REQ-160 (valid combinations of media formats between media 
      streams) 

 
 
Andreasen             Expires September 4, 2007                [Page 9] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

      [Editor's Note: Need to consider layered codecs and how they may 
     impact the requirements] 

   Above, we presented the requirements for the capability negotiation 
   mechanism. Below, we provide a set of features that were considered 
   and then explicitly deemed to be out-of-scope: 

   o  Support for negotiation of unicast and multicast addresses as 
      alternatives. It was suggested as a requirement initially, but 
      subsequent discussion led to its removal.  

   o  Support for negotiation of IPv4 and IPv6 addresses as 
      alternatives. It was suggested as a requirement initially, but 
      subsequent discussion led to its removal.  

   If necessary, it should be possible to define such capabilities in 
   the form of extensions. 

3. Review of Existing Work  

   In this section, we provide an overview of existing relevant work 
   that has either been completed or is work in progress.  For each 
   item, we outline how/if it can be used to address the requirements 
   provided and the pros and cons of doing so.  

3.1. Grouping of Media Lines 

   Grouping of Media Lines is defined in [RFC3388]. RFC 3388 defines a 
   framework that enables two or more media lines to be grouped together 
   for different purposes. Each media line is assigned an identifier and 
   one or more group attributes then references two or more of those 
   identifiers. Associated with each group attribute is a semantics 
   indication. One semantic indication is the Alternative Network 
   Address Types ("ANAT") [RFC4091] which allows for IPv4 and IPv6 
   addresses to be specified as alternatives. The requirements presented 
   above go beyond that, however a new semantic to simply indicate 
   alternative media lines and associated negotiation rules could easily 
   be defined.  

   The main advantages of such an approach would be: 

   o  Mechanism Reuse:  Several semantics have already been defined 
      which increases the likelihood of an implementation supporting the 
      framework.  

   The disadvantages of such an approach would be: 

 
 
Andreasen             Expires September 4, 2007               [Page 10] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

   o  Backwards Compatibility:   The mechanism is not transparently 
      backwards compatible.  If an entity that does not support the 
      mechanism receives it, the entity may incorrectly interpret the 
      SDP as consisting of multiple media streams.  While RFC 3388 
      defines procedures for recognizing and recover from this when 
      using offer/answer, it can still lead to unintended behavior with 
      endpoints that do not support the mechanism.  

        In practice, it is not clear how much of an issue this is, at 
        least for intelligent SIP endpoints. Most current 
        implementations generally accept only one media stream of a 
        given type (e.g. audio). Use of alternatives with different 
        media stream types (e.g. a fax call using "audio" for voice-
        band data or "image" for T.38) makes it less clear though.  
        Also, Media Gateway Controllers and Media Gateways that do not 
        support grouping of media lines have been known to encounter 
        problems.  

   o  Semantics Combination Issues: Multiple semantics may be provided 
      by use of grouping, however they may interact with each other 
      unintentionally. For example, the "FID" semantics defined in RFC 
      3388 forbids grouping of media lines with the same transport 
      address, however that would be needed for alternative 
      capabilities. Thus, using "FID" and alternative capabilities 
      together would require special consideration.  

   o  Some Combinatoric Explosion:  The mechanism is not ideal to 
      indicate alternative capabilities for multiple parameters or media 
      formats within a particular media stream. For example, alternative 
      attribute values and media format parameters for several codecs 
      would lead to combinatoric explosion.  
       
      [Editor's note: In practice, it is not clear this is a huge issue 
      though.]  

   o  Message Size:  Each alternative requires full duplication of all 
      the relevant media stream parameters.  
       
      [Editor's note: In practice, it is not clear this is a huge issue 
      though.]  

3.2. Session Description Protocol (SDP) Simple Capability Declaration 

   SDP Simple Capability Declaration (simcap) is defined in [RFC3407]. 
   It defines a set of SDP attributes that enables capabilities to be 
   described at a session level or on a per media stream basis.  RFC 
   3407 defines capability declaration only - actual negotiation 
 
 
Andreasen             Expires September 4, 2007               [Page 11] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

   procedures taking advantage of such capabilities have not been 
   defined. Such rules however could easily be defined - the negotiation 
   part would extend the offer/answer model to examine alternative 
   configurations (capabilities).  In conjunction with that, attributes 
   to indicate the alternative configurations accepted would likely be 
   needed as well.  
    
   The main advantages of this approach are: 

   o  Satisfies most of the requirements provided above.  In particular, 
      by relying solely on SDP attributes, transparent backwards 
      compatibility is always ensured.  

   The disadvantages of this approach are: 

   o  Offered Capabilities Hidden in Attributes:   An offer may be 
      accepted by the answerer and a media stream established based on 
      SDP parameters contained in SDP attributes not known to 
      intermediaries. Such intermediaries may be back-to-back user 
      agents, or proxies that need to inspect the SDP, e.g., to 
      authorize Quality of Service, add transcoders, etc. 

   o  Maximum of 255 alternative media formats per SDP:     RFC 3407 
      currently allows a maximum of 255 alternative media formats 
      (codecs) per SDP. This may be too restrictive.  

3.3. Session Description and Capability Negotiation (SDPng) 

   The Session Description and Capability Negotiation protocol [SDPng] 
   was intended as a replacement for SDP [SDP].  SDPng includes a full 
   capability indication and negotiation framework that would address 
   the shortcomings of SDP and satisfy the requirements provided above.  
   However, SDPng has not gained traction, in large part due to existing 
   widespread adoption of SDP.  As a consequence, SDPng has remained as 
   work in progress with limited progress for an extended period of 
   time.  

   SDPng consists of two things: an SDPng description, which is an XML 
   document that describes the actual and/or potential configurations as 
   well as an optional negotiation process (an offer/answer compliant 
   process is included as part of SDPng). The SDPng description consists 
   of up to five parts: 

   o  Capabilities:     An optional list of capabilities (potential 
      configurations) to be matched with the other parties' 
      capabilities.  

 
 
Andreasen             Expires September 4, 2007               [Page 12] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

   o  Definitions:      An optional set of definitions of commonly used 
      parameters for later referencing. 

   o  Configurations:   A mandatory description of the conference 
      components, each of which can provide a list of alternative 
      configurations.  

   o  Constraints:      An optional set of constraints of combinations 
      of configurations.  Constraints are not defined as part of the 
      base SDPng specification.  

   o  Session Information:    Optional meta information on the 
      conferences and individual components.  

   SDPng is application-agnostic with the base specification defining a 
   basic XML schema supporting the above.  In order to actually use 
   SDPng, application-specific packages are needed.  Packages define 
   things such as media types, codecs and their configuration 
   parameters, etc.  The base SDPng specification includes a couple of 
   example packages to support audio, video, and RTP.  

   One approach to extending SDP with capability indication and 
   negotiation capabilities could be to adopt the mechanisms defined by 
   SDPng that are necessary to satisfy the requirements provided above.  
   Those areas could then be included within SDP itself, e.g. in the 
   form of one or more SDP attributes ("a=") containing the actual SDPng 
   description. The areas to consider here include: 

   o  Capabilities:  This would be needed to describe alternative media 
      formats and media format parameters. 

   o  Configurations:   This would be needed to define alternative 
      configurations 

   The constraints and session information parts of SDPng would not be 
   used.  

   The main advantages of such an approach would be: 

   o  SDPng was designed and intended to solve the general capability 
      negotiation problems faced by SDP.  A considerable amount of work 
      has already gone into it and it was originally targeted as the 
      long-term direction (replacement for SDP).  

   The disadvantages of such an approach would be: 


 
 
Andreasen             Expires September 4, 2007               [Page 13] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

   o  Duplicate Encoding and Specification Work:   SDPng uses a 
      different coding format than SDP and hence all SDP parameters 
      (incl. codecs and transports) that need to be provided will need 
      to have an equivalent SDPng definition.  There is currently no 
      automatic process for translating all SDP parameters or values 
      into corresponding SDPng parameters or values; many existing SDP 
      parameters and values currently have no corresponding SDPng 
      definition.  

   o  SDPng is Work in Progress: SDPng is currently work in progress but 
      has seen limited interest and progress for a while.  Adoption of a 
      subset of its current definition may end up differing from the 
      final specification.  Also, the current SDPng specification needs 
      further clarification and semantic tightening in a number of areas 
      that would be of relevance to this approach.  

   o  Negotiation of Transport Parameters:   SDPng currently does not 
      support negotiation of transport parameters as individual 
      capabilities.  It is however still possible to negotiate different 
      transport parameters by providing alternative configurations. 

   o  Verbose Encoding and Large Message Size:  SDPng descriptions are 
      XML documents, which are fairly verbose and result in descriptions 
      that are substantially larger than existing SDP.  

3.4. Multipart/alternative 

   In [I-D.jennings-sipping-multipart], the use of multipart/alternative 
   MIME is proposed as a way to support multiple alternative offers.  
   Each alternative offer has an id associated with it by use of a new 
   MIME header field called Content-Answering-CID. The answerer chooses 
   one of the offers and performs normal offer/answer operation on that 
   offer, and then sends back a single answer which includes the 
   Content-Answering-CID value of the offer chosen.  

   The main advantages of this approach are: 

   o  It allows for use of alternative encodings of the offer, e.g. SDP 
      and SDPng, as well as varying levels of confidentiality and 
      integrity by use of S/MIME [RFC3851].  

   Use of multipart/alternative to solve the SDP capability negotiation 
   problems however has several shortcomings: 




 
 
Andreasen             Expires September 4, 2007               [Page 14] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

   o  Backwards Compatibility:   Neither SIP nor RTSP mandate support 
      for Multipart MIME. In the case of SIP, multipart/alternative is 
      generally incompatible with existing SIP proxies, firewalls, 
      Session Border Controllers, and endpoints. 

   o  Heterogeneous Error Response Forking Problem (HERFP): When a SIP 
      proxy forks a request to multiple Contacts, each of which generate 
      a response, the proxy only forwards the "best" of these responses 
      to the request originator.  If one or more of the Contacts do not 
      support multipart/alternative, the request originator may never 
      discover this.  Instead, only a Contact that supports 
      multipart/alternative will be able to generate an answer that 
      reaches the request originator.  

   o  Combinatoric Explosions:   Use of multipart/alternative to convey 
      alternatives on a per media stream basis or even per media format 
      parameter basis quickly leads to combinatoric explosions. 

   o  Message Size:  Each alternative requires full duplication of all 
      the relevant SDP parameters (one complete SDP per alternative).  

   It should be noted, that use of multipart/alternative has been 
   discussed several times before and, in large part due to the problems 
   mentioned above as well as the semantics defined for 
   multipart/alternative [RFC2046], has met with opposition when it 
   comes to addressing the above types of requirements.  

3.5. Sharing Ports Between "m=" Lines 

   SDP [SDP] does not state whether two "m=" lines can share the same 
   transport address or not but rather leaves this explicitly undefined.  
   It has been suggested that alternative capabilities for a media 
   stream could be indicated by including multiple media stream 
   descriptions sharing the same transport address (i.e. using the same 
   port number in the "m=" line and sharing the same IP-address).  

     Such practice was not defined in [RFC2327], however it was 
     suggested in an Internet-Draft version of [SDP].  Following 
     discussion of the potential problems it introduced, it was removed.  

   The main advantages of this approach would be: 






 
 
Andreasen             Expires September 4, 2007               [Page 15] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

   o  May not require any additional extensions to SDP - only additional 
      semantics.  
       
      [Editor's note: It is somewhat unclear how it would work without 
      extensions if we allow for alternative attributes and media format 
      parameters and the offerer needs to always know which ones were 
      accepted] 

   The disadvantages of this approach would be: 

   o  Backwards Compatibility Issues:  Since sharing of transport 
      addresses between multiple streams was never specified as part of 
      SDP, backwards compatibility is likely to be an issue.  Some 
      implementations may support it whereas others may not. The lack of 
      an explicit signaling indication to indicate the desired operation 
      may lead to ungraceful failure scenarios.  Offer/answer semantics 
      would be unclear here as well.  

   o  Some Combinatoric Explosion:  The mechanism is not ideal to 
      indicate alternative capabilities for multiple parameters or media 
      formats within a particular media stream. For example, alternative 
      attribute values and media format parameters for several codecs 
      would lead to combinatoric explosion.  

   o  Message Size:  Each alternative requires full duplication of all 
      the relevant media stream parameters.  
       
      [Editor's note: In practice, it is not clear this is a huge issue 
      though.]  

3.6. Opportunistic Encryption Using a Session Attribute  

   This approach was suggested to address the specific scenario of 
   negotiating either RTP or SRTP. The endpoints signal their desire to 
   do SRTP by listing RTP (RTP/AVP) as the transport protocol in the 
   "m=" line in the offer together with an attribute ("a=") that 
   indicates whether SRTP is supported or not. If the answerer supports 
   SRTP and wants to use it, the answer then includes SRTP (RTP/SAVP) as 
   the transport protocol in the "m=" line.  

   The main advantages of this approach are: 

   o  Compatible with non-SRTP-aware endpoints.  

   The disadvantages of this approach are: 


 
 
Andreasen             Expires September 4, 2007               [Page 16] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

   o  Does not allow the offerer to indicate alternatives other than 
      SRTP (including vanilla RTP as an alternative to SRTP).  

   o  Addresses only a small subset of the requirements provided above.  

3.7. Best-Effort Secure Real-Time Transport Protocol  

   This approach is documented in [BESRTP]. The approach is similar to 
   the one described above, except it does not actually include any 
   explicit signaling indication as to the transport protocols 
   supported. Instead, support for the Secure RTP profile [SRTP] is 
   inferred based on the presence of the crypto attribute defined in 
   [SDES] and/or the key-mgmt attribute defined in [KMGMT]. The draft 
   also proposes the use of separate payload types for codecs being used 
   under different profiles as a way to enable the offerer to process 
   early media packets (especially non-secure ones) prior to receiving 
   an answer (which includes the selected profiles and, in some cases, 
   information about SRTP keying material).  

   The main advantages of this approach are: 

   o  Compatible with non-SRTP-aware endpoints.  

   o  Provides a (separable) solution to disambiguating secure from non-
      secure RTP packets before receiving an answer.  

   The disadvantages of this approach are: 

   o  Defines new semantics above and beyond those defined by RFC 3264, 
      RFC 4567, and RFC 4568 without any explicit signaling in the offer 
      to that effect. This in turn may lead to unintended side-effects. 

         Without explicit signaling indication, it is questionable to 
         infer that presence of e.g. a crypto parameter in the offer 
         indeed indicates that the offer wants to use the mechanism 
         defined by the proposal.  Furthermore, Section 5.1.2 of [SDES] 
         defines generic operation where presence of a crypto attribute 
         without e.g. SRTP as the offered transport protocol could 
         result in the media stream being rejected.  

   o  Does not allow the offerer to indicate alternatives other than the 
      inferred SRTP (including vanilla RTP as an alternative to SRTP). 

   o  Addresses only a small subset of the requirements provided above. 



 
 
Andreasen             Expires September 4, 2007               [Page 17] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

3.8. Opportunistic Encryption using Probing  

   This is another approach suggested to address the specific scenario 
   of negotiating either RTP or SRTP. In this case, the endpoints first 
   establish an RTP session using RTP (RTP/AVP). The endpoints send 
   probe messages, over the media path, to determine if the remote 
   endpoint supports their profile (e.g. RTP/SAVP) and keying technique. 

   The main advantages of this approach are: 

   o  Compatible with non-SRTP-aware endpoints.  

   The disadvantages of this approach are: 

   o  Addresses only a small subset of the requirements provided above. 

4. Security Considerations 

   One of the motivations for SDP capability negotiation is to enable 
   best-effort SRTP negotiation, i.e. an offer/answer exchange offering 
   both a secure and a non-secure version of RTP. The answerer in turn 
   will select one of these. Such a negotiation where the offerer is 
   willing to accept either a secure or insecure RTP profile, and 
   possibly with more or less strong security algorithms as a result of 
   the negotiation opens up for a range of possible security attacks. It 
   is important that any solution for SDP capability negotiation 
   properly addresses such security risks and/or notes any security 
   threats inherent in the proposed solution.  

5. IANA Considerations 

   There are no IANA considerations in this document.  

6. Acknowledgments 

   Thanks to the MMUSIC WG for comments on the requirements in this 
   document. Also, Francois Audet, Paul Jones and Dan Wing provided 
   specific comments on a precursor to this document.  

7. Change Log 

7.1. draft-ietf-mmusic-sdp-capability-negotiation-reqts-01.txt 

   o  Moved REQ-10, REQ-30, and REQ-122 from core to enhancements 



 
 
Andreasen             Expires September 4, 2007               [Page 18] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

   o  Elaborated on note around middle-boxes passing unknown attributes 
      through them, and the potential implication of doing so with 
      respect to this framework.  

7.2. draft-ietf-mmusic-sdp-capability-negotiation-reqts-00.txt 

   Version -00 is based on draft-andreasen-mmusic-sdp-capability-
   negotiation-reqts-00.txt with the following changes: 

   o  Noted that REQ-50 may have interactions with ICE 

   o  Clarified requirements REQ-80, REQ-130. 

   o  Added new requirements REQ-85, REQ-121, REQ-122, REQ-301, and REQ-
      302. 

   o  Reduced requirements REQ-150 and REQ-160 to "SHOULD" strength. 

   o  Minor updates to Section 3.7. and 3.8.  

    

7.3. draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00.txt 

   Version -00 is the initial version. The requirements provided in this 
   initial version were taken from an earlier version of [SDPCapNeg] 
   with additional requirements added (from REQ-150 and up).  

   The ability to indicate capabilities as either mandatory or optional 
   is no longer explicitly out of scope (in order to support modularity 
   and extensibility per the newly added requirements), and neither is 
   the ability to indicate constraints on combinations of 
   configurations.  














 
 
Andreasen             Expires September 4, 2007               [Page 19] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

8. References 

8.1. Normative References 

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
             Requirement Levels", BCP 14, RFC 2119, March 1997. 

   [RFC3264] Rosenberg, J., and H. Schulzrinne, "An Offer/Answer Model 
             with Session Description Protocol (SDP)", RFC 3264, June 
             2002.  

   [RFC3407] F. Andreasen, "Session Description Protocol (SDP) Simple 
             Capability Declaration", RFC 3407, October 2002. 

   [RFC3605] C. Huitema, "Real Time Control Protocol (RTCP) attribute in 
             Session Description Protocol (SDP)", RFC 3605, October 
             2003.  

   [RFC4234] Crocker, D., and P. Overell, "Augmented BNF for Syntax 
             Specifications: ABNF", RFC 4234, October 2005. 

   [SDP]     Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 
             Description Protocol", RFC 4566, July 2006.  

8.2. Informative References 

   [RFC2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail 
             Extensions (MIME) Part Two: Media Types", RFC 2046, 
             November 1996. 

   [RFC2327] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 
             Description Protocol", RFC 2327, April 1998.  

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 
             A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, 
             "SIP: Session Initiation Protocol", RFC 3261, June 2002. 

   [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 
             Schulzrinne, "Grouping of Media Lines in the Session 
             Description Protocol (SDP)", RFC 3388, December 2002. 

   [RFC3551] Schulzrinne, H., and S. Casner, "RTP Profile for Audio and 
             Video Conferences with Minimal Control", RFC 3551, July 
             2003.  



 
 
Andreasen             Expires September 4, 2007               [Page 20] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

   [SRTP]    Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 
             Norrman, "The Secure Real-time Transport Protocol (SRTP)", 
             RFC 3711, March 2004. 

   [RFC3851] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions 
             (S/MIME) Version 3.1 Message Specification", RFC 3851, July 
             2004.  

   [RFC4091] Camarillo, G., and J. Rosenberg, The Alternative Network 
             Address Types (ANAT) Semantics for the Session Description 
             Protocol (SDP) Grouping Framework, RFC 4091, June 2005.  

   [AVPF]    Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 
             "Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF)", 
             Work in Progress, August 2004.  

   [I-D.jennings-sipping-multipart] Wing, D., and C. Jennings, "Session 
             Initiation Protocol (SIP) Offer/Answer with Multipart 
             Alternative", Work in Progress, March 2006. 

   [SAVPF]   Ott, J., and E Carrara, "Extended Secure RTP Profile for 
             RTCP-based Feedback (RTP/SAVPF)", Work in Progress, 
             December 2005.  

   [SDES]    Andreasen, F., Baugher, M., and D. Wing, "Session 
             Description Protocol Security Descriptions for Media 
             Streams", RFC 4568, July 2006.  

   [SDPng]   Kutscher, D., Ott, J., and C. Bormann, "Session Description 
             and Capability Negotiation", Work in Progress, February 
             2005.  

   [BESRTP]  Kaplan, H., and F. Audet, "Session Description Protocol 
             (SDP) Offer/Answer Negotiation for Best-Effort Secure Real-
             Time Transport Protocol, Work in progress, August 2006.  

   [KMGMT]   Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. 
             Carrara, "Key Management Extensions for Session Description 
             Protocol (SDP) and Real Time Streaming Protocol (RTSP)", 
             RFC 4567, July 2006.  

   [SDPCapNeg] Andreasen, F. "SDP Capability Negotiation", work in 
             progress, December 2006. 

   [MIKEY]   J. Arkko, E. Carrara, F. Lindholm, M. Naslund, and K. 
             Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, 
             August 2004.  
 
 
Andreasen             Expires September 4, 2007               [Page 21] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

   [T38]     ITU-T Recommendation T.38, "Procedures for real-time Group 
             3 facsimile communication over IP networks", September 
             2005. 

   [H245]    ITU-T Recommendation H.245, "Control protocol for 
             multimedia communication", May 2006.  

    

Author's Addresses 

   Flemming Andreasen 
   Cisco Systems 
   Edison, NJ 
       
   Email: fandreas@cisco.com 
    

Intellectual Property Statement 

   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights.  Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 

   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 

   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at 
   ietf-ipr@ietf.org. 

Full Copyright Statement 

   Copyright (C) The IETF Trust (2007). 


 
 
Andreasen             Expires September 4, 2007               [Page 22] 

Internet-Draft SDP Capability Negotiation Requirements       March 2007 
    

   This document is subject to the rights, licenses and restrictions 
   contained in BCP 78, and except as set forth therein, the authors 
   retain all their rights. 

   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 

Acknowledgment 

   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 

    





























 
 
Andreasen             Expires September 4, 2007               [Page 23]