3. SDP Definitions

3.1. Profile Definition

The AV profiles defined in RFC 3551 [2], RFC 4585 [3], and RFC 3711 [4] are referred to as "AVP", "AVPF", and "SAVP", respectively, in the context of, e.g., the Session Description Protocol (SDP) [3]. The combined profile specified in this document is referred to as "SAVPF".

3.2. Attribute Definitions

SDP attributes for negotiating SAVP sessions are defined in RFC 4567 [7] and RFC 4568 [8]. Those attributes MAY also be used with SAVPF. The rules defined in [7] and [8] apply.

SDP attributes for negotiating AVPF sessions are defined in RFC 4585 [3]. Those attributes MAY also be used with SAVPF. The rules defined in [3] apply.

3.3. Profile Negotiation

Session descriptions for RTP sessions may be conveyed using protocols dedicated for multimedia communications such as the SDP offer/answer model (RFC 3264, [9]) used with the Session Initiation Protocol (SIP) [15], the Real Time Streaming Protocol (RTSP) [10], or the Session Announcement Protocol (SAP) [11], but may also be distributed using email, NetNews, web pages, etc.

The offer/answer model allows the resulting session parameters to be negotiated using the SDP attributes defined in RFC 4567 [7] and RFC 4568 [8]. In the following subsection, the negotiation process is described in terms of the offer/answer model.

Afterwards, the cases that do not use the offer/answer model are addressed: RTSP-specific negotiation support is provided by RFC 4567 [7] as discussed in Section 3.3.2, and support for SAP announcements (with no negotiation at all) is addressed in Section 3.3.3.

3.3.1. Offer/Answer-Based Negotiation of Session Descriptions

Negotiations (e.g., of RTP profiles, codecs, transport addresses, etc.) are carried out on a per-media session basis (e.g., per m= line in SDP). If negotiating one media session fails, others MAY still succeed.

Different RTP profiles MAY be used in different media sessions. For negotiation of a media description, the four profiles AVP, AVPF, SAVP, and SAVPF are mutually exclusive. Note, however, that SAVP and SAVPF entities MAY be mixed in a single RTP session (see Section 4). Also, the offer/answer mechanism MAY be used to offer alternatives for the same media session and allow the answerer to choose one of the profiles.

Provided that a mechanism for offering alternative security profiles becomes available (as is presently under development [14]), an offerer that is capable of supporting more than one of these profiles for a certain media session SHOULD always offer all alternatives acceptable in a certain situation. The alternatives SHOULD be listed in order of preference and the offerer SHOULD prefer secure profiles over non-secure ones. The offer SHOULD NOT include both a secure alternative (SAVP and SAVPF) and an insecure alternative (e.g., AVP and AVPF) in the same offer as this may enable bidding down and other attacks. Therefore, if both secure and non-secure RTP profiles are offered (e.g., for best-effort SRTP [14]), the negotiation signaling MUST be protected appropriately to avoid such attacks.

If an offer contains multiple alternative profiles, the answerer SHOULD prefer a secure profile (if supported) over non-secure ones. Among the secure or insecure profiles, the answerer SHOULD select the first acceptable alternative to respect the preference of the offerer.

If a media description in an offer uses SAVPF and the answerer does not support SAVPF, the media session MUST be rejected.

If a media description in an offer does not use SAVPF but the answerer wants to use SAVPF, the answerer MUST reject the media session. The answerer MAY provide a counter-offer with a media description indicating SAVPF in a subsequently initiated offer/answer exchange.

3.3.2. RTSP-Based Negotiation of Session Descriptions

RTSP [10] does not support the offer/answer model. However, RTSP supports exchanging media session parameters (including profile and address information) by means of the Transport header. SDP-based key management as defined in RFC 4567 [7] adds an RTSP header (KeyMgmt) to support conveying a key management protocol (including keying material).

The RTSP Transport header MAY be used to determine the profile for the media session. Conceptually, the rules defined in Section 3.3.1 apply accordingly. Detailed operation is as follows: An SDP description (e.g., retrieved from the RTSP server by means of DESCRIBE) contains the description of the media streams of the particular RTSP resource.

The RTSP client MUST select exactly one of the profiles per media stream it wants to receive. It MUST do so in the SETUP request. The RTSP client MUST indicate the chosen RTP profile by indicating the profile and the full server transport address (IP address and port number) in the Transport header included in the SETUP request. The RTSP server's response to the client's SETUP message MUST confirm this profile selection or refuse the SETUP request (the latter of which it should not do after offering the profiles in the first place).

Note: To change any of the profiles in use, the client needs to tear down this media stream (and possibly the whole RTSP session) using the TEARDOWN method and re-establish it using SETUP. This may change as soon as media updating (similar to a SIP UPDATE or re-INVITE) becomes specified.

When using the SDP key management [7], the KeyMgmt header MUST be included in the appropriate RTSP messages if a secure profile is chosen. If different secure profiles are offered in the SDP description (e.g., SAVP and SAVPF) and different keying material is provided for these, after choosing one profile in the SETUP message, only the KeyMgmt header for the chosen one MUST be provided. The rules for matching KeyMgmt headers to media streams according to RFC 4567 [7] apply.

3.3.3. Announcing Session Descriptions

Protocols that do not allow negotiating session descriptions interactively (e.g., SAP [11], descriptions posted on a web page or sent by mail) pose the responsibility for adequate access to the media sessions on the initiator of a session.

The initiator SHOULD provide alternative session descriptions for multiple RTP profiles as far as acceptable to the application and the purpose of the session. If security is desired, SAVP may be offered as alternative to SAVPF -- but AVP or AVPF sessions SHOULD NOT be announced unless other security means not relying on SRTP are employed.

The SDP attributes defined in RFC 4567 [7] and RFC 4568 [8] may also be used for the security parameter distribution of announced session descriptions.

The security scheme description defined in RFC 4568 [8] requires a secure communications channel to prevent third parties from eavesdropping on the keying parameters and manipulation. Therefore, SAP security (as defined in RFC 2974 [11]), S/MIME [12], HTTPS [13], or other suitable mechanisms SHOULD be used for distributing or accessing these session descriptions.

3.3.4. Describing Alternative Session Profiles

SAVP and SAVPF entities MAY be mixed in the same RTP session (see also Section 4) and so MAY AVP and AVPF entities. Other combinations -- i.e., between secure and insecure profiles -- in the same RTP session are incompatible and MUST NOT be used together.

If negotiation between the involved peers is possible (as with the offer/answer model per Section 3.3.1 or RTSP per Section 3.3.2), alternative (secure and non-secure) profiles MAY be specified by one entity (e.g., the offerer) and a choice of one profile MUST be made by the other. If no such negotiation is possible (e.g., with SAP as per Section 3.3.3), incompatible profiles MUST NOT be specified as alternatives.

The negotiation of alternative profiles is for further study.

RTP profiles MAY be mixed arbitrarily across different RTP sessions.

3.4. Examples

This section includes examples for the use of SDP to negotiate the use of secure and non-secure profiles. Depending on what keying mechanism is being used and how it parameterized, the SDP messages typically require integrity protection and, for some mechanisms, will also need confidentiality protection. For example, one could say integrity protection is required for the a=fingerprint of Datagram Transport Layer Security - Secure Real-time Transport Protocol (DTLS-SRTP) [16], and confidentiality is required for RFC 4568 [8] (Security Descriptions) a=crypto.

Example 1: The following session description indicates a secure session made up from audio and dual tone multi-frequency (DTMF) for point-to-point communication in which the DTMF stream uses Generic NACKs. The key management protocol indicated is MIKEY. This session description (the offer) could be contained in a SIP INVITE or 200 OK message to indicate that its sender is capable of and willing to receive feedback for the DTMF stream it transmits. The corresponding answer may be carried in a 200 OK or an ACK. The parameters for the security protocol are negotiated as described by the SDP extensions defined in RFC 4567 [7].

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...

Example 2: This example shows the same feedback parameters as example 1 but uses the secure descriptions syntax [8]. Note that the key part of the a=crypto attribute is not protected against eavesdropping and thus the session description needs to be exchanged over a secure communication channel.

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack
a=crypto:AES_CM_128_HMAC_SHA1_32
  inline:d/16/14/NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj/2^20/1
  :32

Example 3: This example is replicated from example 1 above, but shows the interaction between the offerer and the answerer in an offer/answer exchange, again using MIKEY to negotiate the keying material:

Offer:

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.example.com
a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack

Answer:

v=0
o=alice 3203093521 3203093521 IN IP4 host.another.example.com
s=Media with feedback
t=0 0
c=IN IP4 host.another.example.com
a=key-mgmt:mikey ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD...
m=audio 53012 RTP/SAVPF 0 96
a=rtpmap:0 PCMU/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=rtcp-fb:96 nack

Example 4: This example shows the exchange for video streaming controlled via RTSP. A client acquires a media description from a server using DESCRIBE and obtains a static SDP description without any keying parameters, but the media description shows that both secure and non-secure media sessions using (S)AVPF are available. A mechanism that allows explicit identification of these alternatives (i.e., secure and non-secure sessions) in the session description is presently being defined [14]. The client then issues a SETUP request and indicates its choice by including the respective profile in the Transport parameter. Furthermore, the client includes a KeyMgmt header to convey its security parameters, which is matched by a corresponding KeyMgmt header from the server in the response. Only a single media session is chosen so that the aggregate RTSP URI is sufficient for identification.

RTSP DESCRIBE request-response pair (optional):

DESCRIBE rtsp://movies.example.org/example RTSP/2.0
CSeq: 314
Accept: application/sdp

200 OK
CSeq: 314
Date: 25 Nov 2005 22:09:35 GMT
Content-Type: application/sdp
Content-Length: 316

v=0
o=alice 3203093520 3203093520 IN IP4 movies.example.com
s=Media with feedback
t=0 0
c=IN IP4 0.0.0.0
m=video 49170 RTP/SAVPF 96
a=rtpmap:96 H263-2000/90000
a=rtcp-fb:96 nack
m=video 49172 RTP/AVPF 96
a=rtpmap:96 H263-2000/90000
a=rtcp-fb:96 nack

RTSP SETUP request-response pair

SETUP rtsp://movies.example.org/example RTSP/2.0
CSeq: 315
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
         data="uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnD..."

200 OK
CSeq: 315
Date: 25 Nov 2005 22:09:36 GMT
Session: 4711
Transport: RTP/SAVPF;unicast;dest_addr=":53012"/":53013";
           src_addr="192.0.2.15:60000"/"192.0.2.15:60001"
KeyMgmt: prot=mikey;url="rtsp://movies.example.org/example";
         data="ushdgfdhgfuiweyfhjsgdkj2837do7eWsnDSJD..."
Accept-Ranges: NPT, SMPTE

Example 5: The following session description indicates a multicast audio/video session (using PCMU for audio and either H.261 or H.263+) with the video source accepting Generic NACKs for both codecs and Reference Picture Selection for H.263. The parameters for the security protocol are negotiated as described by the SDP extensions defined in RFC 4567 [7], used at the session level. Such a description may have been conveyed using the Session Announcement Protocol (SAP).

v=0
o=alice 3203093520 3203093520 IN IP4 host.example.com
s=Multicast video with feedback
t=3203130148 3203137348
a=key-mgmt:mikey uiSDF9sdhs7494ghsd/dhsoKkdOokdo7eWsnDSJD...
m=audio 49170 RTP/SAVP 0
c=IN IP4 224.2.1.183
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/SAVPF 98 99
c=IN IP4 224.2.1.184
a=rtpmap:98 H263-1998/90000
a=rtpmap:99 H261/90000
a=rtcp-fb:* nack
a=rtcp-fb:98 nack rpsi