Section Appendix D. Use of SDP for RTSP Session Descriptions

The Session Description Protocol (SDP, [RFC4566]) may be used to
   describe streams or presentations in RTSP.  This description is
   typically returned in reply to a DESCRIBE request on a URI from a
   server to a client or received via HTTP from a server to a client.
   This appendix describes how an SDP file determines the operation of
   an RTSP session.  Thus, it is worth pointing out that the
   interpretation of the SDP is done in the context of the SDP receiver,
   which is the one being configured.  This is the same as in SAP
   [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where each
   SDP is interpreted in the context of the agent providing it.
   SDP as is provides no mechanism by which a client can distinguish,
   without human guidance, between several media streams to be rendered
   simultaneously and a set of alternatives (e.g., two audio streams
   spoken in different languages).  The SDP extension found in "The
   Session Description Protocol (SDP) Grouping Framework" [RFC5888]
   provides such functionality to some degree.  Appendix D.4 describes
   the usage of SDP media line grouping for RTSP.
D.1.  Definitions
   The terms "session-level", "media-level", and other key/attribute
   names and values used in this appendix are to be used as defined in
   SDP [RFC4566]:
D.1.1.  Control URI
   The "a=control" attribute is used to convey the control URI.  This
   attribute is used both for the session and media descriptions.  If
   used for individual media, it indicates the URI to be used for
   controlling that particular media stream.  If found at the session
   level, the attribute indicates the URI for aggregate control
   (presentation URI).  The session-level URI MUST be different from any
   media-level URI.  The presence of a session-level control attribute
   MUST be interpreted as support for aggregated control.  The control
   attribute MUST be present on the media level unless the presentation
   only contains a single media stream; in which case, the attribute MAY
   be present on the session level only and then also apply to that
   single media stream.
   ABNF for the attribute is defined in Section 20.3.
   Example:
     a=control:rtsp://example.com/foo
   This attribute MAY contain either relative or absolute URIs,
   following the rules and conventions set out in RFC 3986 [RFC3986].
   Implementations MUST look for a base URI in the following order:
   1.  the RTSP Content-Base field;
   2.  the RTSP Content-Location field;
   3.  the RTSP Request-URI.
   If this attribute contains only an asterisk (*), then the URI MUST be
   treated as if it were an empty embedded URI; thus, it will inherit
   the entire base URI.
      Note: RFC 2326 was very unclear on the processing of relative URIs
      and several RTSP 1.0 implementations at the point of publishing
      this document did not perform RFC 3986 processing to determine the
      resulting URI; instead, simple concatenation is common.  To avoid
      this issue completely, it is recommended to use absolute URIs in
      the SDP.
   The URI handling for SDPs from container files needs special
   consideration.  For example, let's assume that a container file has
   the URI: "rtsp://example.com/container.mp4".  Let's further assume
   this URI is the base URI and that there is an absolute media-level
   URI: "rtsp://example.com/container.mp4/trackID=2".  A relative media-
   level URI that resolves in accordance with RFC 3986 [RFC3986] to the
   above given media URI is "container.mp4/trackID=2".  It is usually
   not desirable to need to include or modify the SDP stored within the
   container file with the server local name of the container file.  To
   avoid this, one can modify the base URI used to include a trailing
   slash, e.g., "rtsp://example.com/container.mp4/".  In this case, the
   relative URI for the media will only need to be "trackID=2".
   However, this will also mean that using "*" in the SDP will result in
   the control URI including the trailing slash, i.e.,
   "rtsp://example.com/container.mp4/".
      Note: the usage of TrackID in the above is not a standardized
      form, but one example out of several similar strings such as
      TrackID, Track_ID, StreamID that is used by different server
      vendors to indicate a particular piece of media inside a container
      file.
D.1.2.  Media Streams
   The "m=" field is used to enumerate the streams.  It is expected that
   all the specified streams will be rendered with appropriate
   synchronization.  If the session is over multicast, the port number
   indicated SHOULD be used for reception.  The client MAY try to
   override the destination port, through the Transport header.  The
   servers MAY allow this: the response will indicate whether or not
   this is allowed.  If the session is unicast, the port numbers are the
   ones RECOMMENDED by the server to the client, about which receiver
   ports to use; the client MUST still include its receiver ports in its
   SETUP request.  The client MAY ignore this recommendation.  If the
   server has no preference, it SHOULD set the port number value to
   zero.
   The "m=" lines contain information about which transport protocol,
   profile, and possibly lower-layer are to be used for the media
   stream.  The combination of transport, profile, and lower layer, like
   RTP/AVP/UDP, needs to be defined for how to be used with RTSP.  The
   currently defined combinations are discussed in Appendix C; further
   combinations MAY be specified.
   Example:
     m=audio 0 RTP/AVP 31
D.1.3.  Payload Type(s)
   The payload type or types are specified in the "m=" line.  In case
   the payload type is a static payload type from RFC 3551 [RFC3551], no
   other information may be required.  In case it is a dynamic payload
   type, the media attribute "rtpmap" is used to specify what the media
   is.  The "encoding name" within the "rtpmap" attribute may be one of
   those specified in [RFC4856], a media type registered with IANA
   according to [RFC4855], or an experimental encoding as specified in
   SDP [RFC4566]).  Codec-specific parameters are not specified in this
   field, but rather in the "fmtp" attribute described below.
   The selection of the RTP payload type numbers used may be required to
   consider RTP and RTCP Multiplexing [RFC5761], if that is to be
   supported by the server.
D.1.4.  Format-Specific Parameters
   Format-specific parameters are conveyed using the "fmtp" media
   attribute.  The syntax of the "fmtp" attribute is specific to the
   encoding(s) to which the attribute refers.  Note that some of the
   format-specific parameters may be specified outside of the "fmtp"
   parameters, for example, like the "ptime" attribute for most audio
   encodings.
D.1.5.  Directionality of Media Stream
   The SDP attributes "a=sendrecv", "a=recvonly", and "a=sendonly"
   provide instructions about the direction the media streams flow
   within a session.  When using RTSP, the SDP can be delivered to a
   client using either RTSP DESCRIBE or a number of RTSP external
   methods, like HTTP, FTP, and email.  Based on this, the SDP applies
   to how the RTSP client will see the complete session.  Thus, media
   streams delivered from the RTSP server to the client would be given
   the "a=recvonly" attribute.
   "a=recvonly" in an SDP provided to the RTSP client indicates that
   media delivery will only occur in the direction from the RTSP server
   to the client.  SDP provided to the RTSP client that lacks any of the
   directionality attributes ("a=recvonly", "a=sendonly", "a=sendrecv")
   would be interpreted as having "a=sendrecv".  At the time of writing,
   there exists no RTSP mode suitable for media traffic in the direction
   from the RTSP client to the server.  Thus, all RTSP SDP SHOULD have
   an "a=recvonly" attribute when using the PLAY mode defined in this
   document.  If future modes are defined for media in the client-to-
   server direction, then usage of "a=sendonly" or "a=sendrecv" may
   become suitable to indicate intended media directions.
D.1.6.  Range of Presentation
   The "a=range" attribute defines the total time range of the stored
   session or an individual media.  Live sessions that are not seekable
   can be indicated as specified below; whereas the length of live
   sessions can be deduced from the "t=" and "r=" SDP parameters.
   The attribute is both a session- and a media-level attribute.  For
   presentations that contain media streams of the same duration, the
   range attribute SHOULD only be used at the session level.  In case of
   different lengths, the range attribute MUST be given at media level
   for all media and SHOULD NOT be given at the session level.  If the
   attribute is present at both media level and session level, the
   media-level values MUST be used.
   Note: usually one will specify the same length for all media, even if
   there isn't media available for the full duration on all media.
   However, that requires that the server accept PLAY requests within
   that range.
   Servers MUST take care to provide RTSP Range (see Section 18.40)
   values that are consistent with what is presented in the SDP for the
   content.  There is no reason for non dynamic content, like media
   clips provided on demand to have inconsistent values.  Inconsistent
   values between the SDP and the actual values for the content handled
   by the server is likely to generate some failure, like 457 "Invalid
   Range", in case the client uses PLAY requests with a Range header.
   In case the content is dynamic in length and it is infeasible to
   provide a correct value in the SDP, the server is recommended to
   describe this as content that is not seekable (see below).  The
   server MAY override that property in the response to a PLAY request
   using the correct values in the Range header.
   The unit is specified first, followed by the value range.  The units
   and their values are as defined in Section 4.4.1, Section 4.4.2, and
   Section 4.4.3 and MAY be extended with further formats.  Any open-
   ended range (start-), i.e., without stop range, is of unspecified
   duration and MUST be considered as content that is not seekable
   unless this property is overridden.  Multiple instances carrying
   different clock formats MAY be included at either session or media
   level.
   ABNF for the attribute is defined in Section 20.3.
   Examples:
     a=range:npt=0-34.4368
     a=range:clock=19971113T211503Z-19971113T220300Z
     Non-seekable stream of unknown duration:
     a=range:npt=0-
D.1.7.  Time of Availability
   The "t=" field defines when the SDP is valid.  For on-demand content,
   the server SHOULD indicate a stop time value for which it guarantees
   the description to be valid and a start time that is equal to or
   before the time at which the DESCRIBE request was received.  It MAY
   also indicate start and stop times of 0, meaning that the session is
   always available.
   For sessions that are of live type, i.e., specific start time,
   unknown stop time, likely not seekable, the "t=" and "r=" field
   SHOULD be used to indicate the start time of the event.  The stop
   time SHOULD be given so that the live event will have ended at that
   time, while still not being unnecessary far into the future.
D.1.8.  Connection Information
   In SDP used with RTSP, the "c=" field contains the destination
   address for the media stream.  If a multicast address is specified,
   the client SHOULD use this address in any SETUP request as
   destination address, including any additional parameters, such as
   TTL.  For on-demand unicast streams and some multicast streams, the
   destination address MAY be specified by the client via the SETUP
   request, thus overriding any specified address.  To identify streams
   without a fixed destination address, where the client is required to
   specify a destination address, the "c=" field SHOULD be set to a null
   value.  For addresses of type "IP4", this value MUST be "0.0.0.0";
   and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" (can also be
   written as "::"), i.e., the unspecified address according to RFC 4291
   [RFC4291].
D.1.9.  Message Body Tag
   The optional "a=mtag" attribute identifies a version of the session
   description.  It is opaque to the client.  SETUP requests may include
   this identifier in the If-Match field (see Section 18.24) to allow
   session establishment only if this attribute value still corresponds
   to that of the current description.  The attribute value is opaque
   and may contain any character allowed within SDP attribute values.
   ABNF for the attribute is defined in Section 20.3.
   Example:
     a=mtag:"158bb3e7c7fd62ce67f12b533f06b83a"
      One could argue that the "o=" field provides identical
      functionality.  However, it does so in a manner that would put
      constraints on servers that need to support multiple session
      description types other than SDP for the same piece of media
      content.
D.2.  Aggregate Control Not Available
   If a presentation does not support aggregate control, no session-
   level "a=control" attribute is specified.  For an SDP with multiple
   media sections specified, each section will have its own control URI
   specified via the "a=control" attribute.
   Example:
   v=0
   o=- 2890844256 2890842807 IN IP4 192.0.2.56
   s=I came from a web page
   e=adm@example.com
   c=IN IP4 0.0.0.0
   t=0 0
   m=video 8002 RTP/AVP 31
   a=control:rtsp://audio.example.com/movie.aud
   m=audio 8004 RTP/AVP 3
   a=control:rtsp://video.example.com/movie.vid
   Note that the position of the control URI in the description implies
   that the client establishes separate RTSP control sessions to the
   servers audio.example.com and video.example.com.
   It is recommended that an SDP file contain the complete media-
   initialization information even if it is delivered to the media
   client through non-RTSP means.  This is necessary as there is no
   mechanism to indicate that the client should request more detailed
   media stream information via DESCRIBE.
D.3.  Aggregate Control Available
   In this scenario, the server has multiple streams that can be
   controlled as a whole.  In this case, there are both a media-level
   "a=control" attribute, which is used to specify the stream URIs, and
   a session-level "a=control" attribute, which is used as the Request-
   URI for aggregate control.  If the media-level URI is relative, it is
   resolved to absolute URIs according to Appendix D.1.1 above.
   Example:
   C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0
         CSeq: 1
         User-Agent: PhonyClient/1.2
   M->C: RTSP/2.0 200 OK
         CSeq: 1
         Date: Wed, 23 Jan 2013 15:36:52 +0000
         Expires: Wed, 23 Jan 2013 16:36:52 +0000
         Content-Type: application/sdp
         Content-Base: rtsp://example.com/movie/
         Content-Length: 227
         v=0
         o=- 2890844256 2890842807 IN IP4 192.0.2.211
         s=I contain
         i=<more info>
         e=adm@example.com
         c=IN IP4 0.0.0.0
         a=control:*
         t=0 0
         m=video 8002 RTP/AVP 31
         a=control:trackID=1
         m=audio 8004 RTP/AVP 3
         a=control:trackID=2
   In this example, the client is recommended to establish a single RTSP
   session to the server, and it uses the URIs rtsp://example.com/movie/
   trackID=1 and rtsp://example.com/movie/trackID=2 to set up the video
   and audio streams, respectively.  The URI rtsp://example.com/movie/,
   which is resolved from the "*", controls the whole presentation
   (movie).
   A client is not required to issue SETUP requests for all streams
   within an aggregate object.  Servers should allow the client to ask
   for only a subset of the streams.
D.4.  Grouping of Media Lines in SDP
   For some types of media, it is desirable to express a relationship
   between various media components, for instance, for lip
   synchronization or Scalable Video Codec (SVC) [RFC5583].  This
   relationship is expressed on the SDP level by grouping of media
   lines, as described in [RFC5888], and can be exposed to RTSP.
   For RTSP, it is mainly important to know how to handle grouped media
   received by means of SDP, i.e., if the media are under aggregate
   control (see Appendix D.3) or if aggregate control is not available
   (see Appendix D.2).
   It is RECOMMENDED that grouped media are handled by aggregate
   control, to give the client the ability to control either the whole
   presentation or single media.
D.5.  RTSP External SDP Delivery
   There are some considerations that need to be made when the session
   description is delivered to the client outside of RTSP, for example
   via HTTP or email.
   First of all, the SDP needs to contain absolute URIs, since relative
   will, in most cases, not work as the delivery will not correctly
   forward the base URI.
   The writing of the SDP session availability information, i.e., "t="
   and "r=", needs to be carefully considered.  When the SDP is fetched
   by the DESCRIBE method, the probability that it is valid is very
   high.  However, the same is much less certain for SDPs distributed
   using other methods.  Therefore, the publisher of the SDP should take
   care to follow the recommendations about availability in the SDP
   specification [RFC4566] in Section 4.2.