Network Working Group M. Handley
`Request for Comments: 2327 V. Jacobson
`Category: Standards Track ISI/LBNL
` April 1998
`
` SDP: Session Description Protocol
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (1998). All Rights Reserved.
`
`Abstract
`
` This document defines the Session Description Protocol, SDP. SDP is
` intended for describing multimedia sessions for the purposes of
` session announcement, session invitation, and other forms of
` multimedia session initiation.
`
` This document is a product of the Multiparty Multimedia Session
` Control (MMUSIC) working group of the Internet Engineering Task
` Force. Comments are solicited and should be addressed to the working
` group’s mailing list at confctrl@isi.edu and/or the authors.
`
`1. Introduction
`
` On the Internet multicast backbone (Mbone), a session directory tool
` is used to advertise multimedia conferences and communicate the
` conference addresses and conference tool-specific information
` necessary for participation. This document defines a session
` description protocol for this purpose, and for general real-time
` multimedia session description purposes. This memo does not describe
` multicast address allocation or the distribution of SDP messages in
` detail. These are described in accompanying memos. SDP is not
` intended for negotiation of media encodings.
`
`Handley & Jacobson Standards Track [Page 1]
`
`AT&T Exhibit 1038
`AT&T v. VoIP, IPR 2017-01382
`Page 1
`
`

`

`
`RFC 2327 SDP April 1998
`
`2. Background
`
` The Mbone is the part of the internet that supports IP multicast, and
` thus permits efficient many-to-many communication. It is used
` extensively for multimedia conferencing. Such conferences usually
` have the property that tight coordination of conference membership is
` not necessary; to receive a conference, a user at an Mbone site only
` has to know the conference’s multicast group address and the UDP
` ports for the conference data streams.
`
` Session directories assist the advertisement of conference sessions
` and communicate the relevant conference setup information to
` prospective participants. SDP is designed to convey such information
` to recipients. SDP is purely a format for session description - it
` does not incorporate a transport protocol, and is intended to use
` different transport protocols as appropriate including the Session
` Announcement Protocol [4], Session Initiation Protocol [11], Real-
` Time Streaming Protocol [12], electronic mail using the MIME
` extensions, and the Hypertext Transport Protocol.
`
` SDP is intended to be general purpose so that it can be used for a
` wider range of network environments and applications than just
` multicast session directories. However, it is not intended to
` support negotiation of session content or media encodings - this is
` viewed as outside the scope of session description.
`
`3. Glossary of Terms
`
` The following terms are used in this document, and have specific
` meaning within the context of this document.
`
` Conference
` A multimedia conference is a set of two or more communicating users
` along with the software they are using to communicate.
`
` Session
` A multimedia session is a set of multimedia senders and receivers
` and the data streams flowing from senders to receivers. A
` multimedia conference is an example of a multimedia session.
`
` Session Advertisement
` See session announcement.
`
` Session Announcement
` A session announcement is a mechanism by which a session
` description is conveyed to users in a proactive fashion, i.e., the
` session description was not explicitly requested by the user.
`
`Handley & Jacobson Standards Track [Page 2]
`
`AT&T Exhibit 1038
`AT&T v. VoIP, IPR 2017-01382
`Page 2
`
`

`

`
`RFC 2327 SDP April 1998
`
` Session Description
` A well defined format for conveying sufficient information to
` discover and participate in a multimedia session.
`
`3.1. Terminology
`
` 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 RFC 2119.
`
`4. SDP Usage
`
`4.1. Multicast Announcements
`
` SDP is a session description protocol for multimedia sessions. A
` common mode of usage is for a client to announce a conference session
` by periodically multicasting an announcement packet to a well known
` multicast address and port using the Session Announcement Protocol
` (SAP).
`
` SAP packets are UDP packets with the following format:
`
` |--------------------|
` | SAP header |
` |--------------------|
` | text payload |
` |//////////
`
` The header is the Session Announcement Protocol header. SAP is
` described in more detail in a companion memo [4]
`
` The text payload is an SDP session description, as described in this
` memo. The text payload should be no greater than 1 Kbyte in length.
` If announced by SAP, only one session announcement is permitted in a
` single packet.
`
`4.2. Email and WWW Announcements
`
` Alternative means of conveying session descriptions include
` electronic mail and the World Wide Web. For both email and WWW
` distribution, the use of the MIME content type "application/sdp"
` should be used. This enables the automatic launching of applications
` for participation in the session from the WWW client or mail reader
` in a standard manner.
`
`Handley & Jacobson Standards Track [Page 3]
`
`AT&T Exhibit 1038
`AT&T v. VoIP, IPR 2017-01382
`Page 3
`
`

`

`
`RFC 2327 SDP April 1998
`
` Note that announcements of multicast sessions made only via email or
` the World Wide Web (WWW) do not have the property that the receiver
` of a session announcement can necessarily receive the session because
` the multicast sessions may be restricted in scope, and access to the
` WWW server or reception of email is possible outside this scope. SAP
` announcements do not suffer from this mismatch.
`
`5. Requirements and Recommendations
`
` The purpose of SDP is to convey information about media streams in
` multimedia sessions to allow the recipients of a session description
` to participate in the session. SDP is primarily intended for use in
` an internetwork, although it is sufficiently general that it can
` describe conferences in other network environments.
`
` A multimedia session, for these purposes, is defined as a set of
` media streams that exist for some duration of time. Media streams
` can be many-to-many. The times during which the session is active
` need not be continuous.
`
` Thus far, multicast based sessions on the Internet have differed from
` many other forms of conferencing in that anyone receiving the traffic
` can join the session (unless the session traffic is encrypted). In
` such an environment, SDP serves two primary purposes. It is a means
` to communicate the existence of a session, and is a means to convey
` sufficient information to enable joining and participating in the
` session. In a unicast environment, only the latter purpose is likely
` to be relevant.
`
` Thus SDP includes:
`
` o Session name and purpose
`
` o Time(s) the session is active
`
` o The media comprising the session
`
` o Information to receive those media (addresses, ports, formats and
` so on)
`
` As resources necessary to participate in a session may be limited,
` some additional information may also be desirable:
`
` o Information about the bandwidth to be used by the conference
`
` o Contact information for the person responsible for the session
`
`Handley & Jacobson Standards Track [Page 4]
`
`AT&T Exhibit 1038
`AT&T v. VoIP, IPR 2017-01382
`Page 4
`
`

`

`
`RFC 2327 SDP April 1998
`
` In general, SDP must convey sufficient information to be able to join
` a session (with the possible exception of encryption keys) and to
` announce the resources to be used to non-participants that may need
` to know.
`
`5.1. Media Information
`
` SDP includes:
`
` o The type of media (video, audio, etc)
`
` o The transport protocol (RTP/UDP/IP, H.320, etc)
`
` o The format of the media (H.261 video, MPEG video, etc)
`
` For an IP multicast session, the following are also conveyed:
`
` o Multicast address for media
`
` o Transport Port for media
`
` This address and port are the destination address and destination
` port of the multicast stream, whether being sent, received, or both.
`
` For an IP unicast session, the following are conveyed:
`
` o Remote address for media
`
` o Transport port for contact address
`
` The semantics of this address and port depend on the media and
` transport protocol defined. By default, this is the remote address
` and remote port to which data is sent, and the remote address and
` local port on which to receive data. However, some media may define
` to use these to establish a control channel for the actual media
` flow.
`
`5.2. Timing Information
`
` Sessions may either be bounded or unbounded in time. Whether or not
` they are bounded, they may be only active at specific times.
`
` SDP can convey:
`
` o An arbitrary list of start and stop times bounding the session
`
` o For each bound, repeat times such as "every Wednesday at 10am for
` one hour"
`
`Handley & Jacobson Standards Track [Page 5]
`
`AT&T Exhibit 1038
`AT&T v. VoIP, IPR 2017-01382
`Page 5
`
`

`

`
`RFC 2327 SDP April 1998
`
` This timing information is globally consistent, irrespective of local
` time zone or daylight saving time.
`
`5.3. Private Sessions
`
` It is possible to create both public sessions and private sessions.
` Private sessions will typically be conveyed by encrypting the session
` description to distribute it. The details of how encryption is
` performed are dependent on the mechanism used to convey SDP - see [4]
` for how this is done for session announcements.
`
` If a session announcement is private it is possible to use that
` private announcement to convey encryption keys necessary to decode
` each of the media in a conference, including enough information to
` know which encryption scheme is used for each media.
`
`5.4. Obtaining Further Information about a Session
`
` A session description should convey enough information to decide
` whether or not to participate in a session. SDP may include
` additional pointers in the form of Universal Resources Identifiers
` (URIs) for more information about the session.
`
`5.5. Categorisation
`
` When many session descriptions are being distributed by SAP or any
` other advertisement mechanism, it may be desirable to filter
` announcements that are of interest from those that are not. SDP
` supports a categorisation mechanism for sessions that is capable of
` being automated.
`
`5.6. Internationalization
`
` The SDP specification recommends the use of the ISO 10646 character
` sets in the UTF-8 encoding (RFC 2044) to allow many different
` languages to be represented. However, to assist in compact
` representations, SDP also allows other character sets such as ISO
` 8859-1 to be used when desired. Internationalization only applies to
` free-text fields (session name and background information), and not
` to SDP as a whole.
`
`6. SDP Specification
`
` SDP session descriptions are entirely textual using the ISO 10646
` character set in UTF-8 encoding. SDP field names and attributes names
` use only the US-ASCII subset of UTF-8, but textual fields and
` attribute values may use the full ISO 10646 character set. The
` textual form, as opposed to a binary encoding such as ASN/1 or XDR,
`
`Handley & Jacobson Standards Track [Page 6]
`
`AT&T Exhibit 1038
`AT&T v. VoIP, IPR 2017-01382
`Page 6
`
`

`

`
`RFC 2327 SDP April 1998
`
` was chosen to enhance portability, to enable a variety of transports
` to be used (e.g, session description in a MIME email message) and to
` allow flexible, text-based toolkits (e.g., Tcl/Tk ) to be used to
` generate and to process session descriptions. However, since the
` total bandwidth allocated to all SAP announcements is strictly
` limited, the encoding is deliberately compact. Also, since
` announcements may be transported via very unreliable means (e.g.,
` email) or damaged by an intermediate caching server, the encoding was
` designed with strict order and formatting rules so that most errors
` would result in malformed announcements which could be detected
` easily and discarded. This also allows rapid discarding of encrypted
` announcements for which a receiver does not have the correct key.
`
` An SDP session description consists of a number of lines of text of
` the form <type>=<value> <type> is always exactly one character and is
` case-significant. <value> is a structured text string whose format
` depends on <type>. It also will be case-significant unless a
` specific field defines otherwise. Whitespace is not permitted either
` side of the ‘=’ sign. In general <value> is either a number of fields
` delimited by a single space character or a free format string.
`
` A session description consists of a session-level description
` (details that apply to the whole session and all media streams) and
` optionally several media-level descriptions (details that apply onto
` to a single media stream).
`
` An announcement consists of a session-level section followed by zero
` or more media-level sections. The session-level part starts with a
` ‘v=’ line and continues to the first media-level section. The media
` description starts with an ‘m=’ line and continues to the next media
` description or end of the whole session description. In general,
` session-level values are the default for all media unless overridden
` by an equivalent media-level value.
`
` When SDP is conveyed by SAP, only one session description is allowed
` per packet. When SDP is conveyed by other means, many SDP session
` descriptions may be concatenated together (the ‘v=’ line indicating
` the start of a session description terminates the previous
` description). Some lines in each description are required and some
` are optional but all must appear in exactly the order given here (the
` fixed order greatly enhances error detection and allows for a simple
` parser). Optional items are marked with a ‘*’.
`
`Session description
` v= (protocol version)
` o= (owner/creator and session identifier).
` s= (session name)
` i=* (session information)
`
`Handley & Jacobson Standards Track [Page 7]
`
`AT&T Exhibit 1038
`AT&T v. VoIP, IPR 2017-01382
`Page 7
`
`

`

`
`RFC 2327 SDP April 1998
`
` u=* (URI of description)
` e=* (email address)
` p=* (phone number)
` c=* (connection information - not required if included in all media)
` b=* (bandwidth information)
` One or more time descriptions (see below)
` z=* (time zone adjustments)
` k=* (encryption key)
` a=* (zero or more session attribute lines)
` Zero or more media descriptions (see below)
`
`Time description
` t= (time the session is active)
` r=* (zero or more repeat times)
`
`Media description
` m= (media name and transport address)
` i=* (media title)
` c=* (connection information - optional if included at session-level)
` b=* (bandwidth information)
` k=* (encryption key)
` a=* (zero or more media attribute lines)
`
` The set of ‘type’ letters is deliberately small and not intended to
` be extensible -- SDP parsers must completely ignore any announcement
` that contains a ‘type’ letter that it does not understand. The
` ‘attribute’ mechanism ("a=" described below) is the primary means for
` extending SDP and tailoring it to particular applications or media.
` Some attributes (the ones listed in this document) have a defined
` meaning but others may be added on an application-, media- or
` session-specific basis. A session directory must ignore any
` attribute it doesn’t understand.
`
` The connection (‘c=’) and attribute (‘a=’) information in the
` session-level section applies to all the media of that session unless
` overridden by connection information or an attribute of the same name
` in the media description. For instance, in the example below, each
` media behaves as if it were given a ‘recvonly’ attribute.
`
` An example SDP description is:
`
` v=0
` o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
` s=SDP Seminar
` i=A Seminar on the session description protocol
` u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
` e=mjh@isi.edu (Mark Handley)
` c=IN IP4 224.2.17.12/127
`
`Handley & Jacobson Standards Track [Page 8]
`
`AT&T Exhibit 1038
`AT&T v. VoIP, IPR 2017-01382
`Page 8
`
`

`

`
`RFC 2327 SDP April 1998
`
` t=2873397496 2873404696
` a=recvonly
` m=audio 49170 RTP/AVP 0
` m=video 51372 RTP/AVP 31
` m=application 32416 udp wb
` a=orient:portrait
`
` Text records such as the session name and information are bytes
` strings which may contain any byte with the exceptions of 0x00 (Nul),
` 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The sequence
` CRLF (0x0d0a) is used to end a record, although parsers should be
` tolerant and also accept records terminated with a single newline
` character. By default these byte strings contain ISO-10646
` characters in UTF-8 encoding, but this default may be changed using
` the ‘charset’ attribute.
`
` Protocol Version
`
` v=0
`
` The "v=" field gives the version of the Session Description Protocol.
` There is no minor version number.
`
` Origin
`
` o=<username> <session id> <version> <network type> <address type>
` <address>
`
` The "o=" field gives the originator of the session (their username
` and the address of the user’s host) plus a session id and session
` version number.
`
` <username> is the user’s login on the originating host, or it is "-"
` if the originating host does not support the concept of user ids.
` <username> must not contain spaces. <session id> is a numeric string
` such that the tuple of <username>, <session id>, <network type>,
` <address type> and <address> form a globally unique identifier for
` the session.
`
` The method of <session id> allocation is up to the creating tool, but
` it has been suggested that a Network Time Protocol (NTP) timestamp be
` used to ensure uniqueness [1].
`
` <version> is a version number for this announcement. It is needed
` for proxy announcements to detect which of several announcements for
` the same session is the most recent. Again its usage is up to the
`
`Handley & Jacobson Standards Track [Page 9]
`
`AT&T Exhibit 1038
`AT&T v. VoIP, IPR 2017-01382
`Page 9
`
`

`

`
`RFC 2327 SDP April 1998
`
` creating tool, so long as <version> is increased when a modification
` is made to the session data. Again, it is recommended (but not
` mandatory) that an NTP timestamp is used.
`
` <network type> is a text string giving the type of network.
` Initially "IN" is defined to have the meaning "Internet". <address
` type> is a text string giving the type of the address that follows.
` Initially "IP4" and "IP6" are defined. <address> is the globally
` unique address of the machine from which the session was created.
` For an address type of IP4, this is either the fully-qualified domain
` name of the machine, or the dotted-decimal representation of the IP
` version 4 address of the machine. For an address type of IP6, this
` is either the fully-qualified domain name of the machine, or the
` compressed textual representation of the IP version 6 address of the
` machine. For both IP4 and IP6, the fully-qualified domain name is
` the form that SHOULD be given unless this is unavailable, in which
` case the globally unique address may be substituted. A local IP
` address MUST NOT be used in any context where the SDP description
` might leave the scope in which the address is meaningful.
`
` In general, the "o=" field serves as a globally unique identifier for
` this version of this session description, and the subfields excepting
` the version taken together identify the session irrespective of any
` modifications.
`
` Session Name
`
` s=<session name>
`
` The "s=" field is the session name. There must be one and only one
` "s=" field per session description, and it must contain ISO 10646
` characters (but see also the ‘charset’ attribute below).
`
` Session and Media Information
`
` i=<session description>
`
` The "i=" field is information about the session. There may be at
` most one session-level "i=" field per session description, and at
` most one "i=" field per media. Although it may be omitted, this is
` discouraged for session announcements, and user interfaces for
` composing sessions should require text to be entered. If it is
` present it must contain ISO 10646 characters (but see also the
` ‘charset’ attribute below).
`
` A single "i=" field can also be used for each media definition. In
` media definitions, "i=" fields are primarily intended for labeling
` media streams. As such, they are most likely to be useful when a
`
`Handley & Jacobson Standards Track [Page 10]
`
`AT&T Exhibit 1038
`AT&T v. VoIP, IPR 2017-01382
`Page 10
`
`

`

`
`RFC 2327 SDP April 1998
`
` single session has more than one distinct media stream of the same
` media type. An example would be two different whiteboards, one for
` slides and one for feedback and questions.
`
` URI
`
` u=<URI>
`
` o A URI is a Universal Resource Identifier as used by WWW clients
`
` o The URI should be a pointer to additional information about the
` conference
`
` o This field is optional, but if it is present it should be specified
` before the first media field
`
` o No more than one URI field is allowed per session description
`
` Email Address and Phone Number
`
` e=<email address>
` p=<phone number>
`
` o These specify contact information for the person responsible for
` the conference. This is not necessarily the same person that
` created the conference announcement.
`
` o Either an email field or a phone field must be specified.
` Additional email and phone fields are allowed.
`
` o If these are present, they should be specified before the first
` media field.
`
` o More than one email or phone field can be given for a session
` description.
`
` o Phone numbers should be given in the conventional international
`
` format - preceded by a "+ and the international country code.
` There must be a space or a hyphen ("-") between the country code
` and the rest of the phone number. Spaces and hyphens may be used
` to split up a phone field to aid readability if desired. For
` example:
`
` p=+44-171-380-7777 or p=+1 617 253 6011
`
`Handley & Jacobson Standards Track [Page 11]
`
`AT&T Exhibit 1038
`AT&T v. VoIP, IPR 2017-01382
`Page 11
`
`

`

`
`RFC 2327 SDP April 1998
`
` o Both email addresses and phone numbers can have an optional free
` text string associated with them, normally giving the name of the
` person who may be contacted. This should be enclosed in
` parenthesis if it is present. For example:
`
` e=mjh@isi.edu (Mark Handley)
`
` The alternative RFC822 name quoting convention is also allowed for
` both email addresses and phone numbers. For example,
`
` e=Mark Handley <mjh@isi.edu>
`
` The free text string should be in the ISO-10646 character set with
` UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings
` if the appropriate charset session-level attribute is set.
`
` Connection Data
`
` c=<network type> <address type> <connection address>
`
` The "c=" field contains connection data.
`
` A session announcement must contain one "c=" field in each media
` description (see below) or a "c=" field at the session-level. It may
` contain a session-level "c=" field and one additional "c=" field per
` media description, in which case the per-media values override the
` session-level settings for the relevant media.
`
` The first sub-field is the network type, which is a text string
` giving the type of network. Initially "IN" is defined to have the
` meaning "Internet".
`
` The second sub-field is the address type. This allows SDP to be used
` for sessions that are not IP based. Currently only IP4 is defined.
`
` The third sub-field is the connection address. Optional extra
` subfields may be added after the connection address depending on the
` value of the <address type> field.
`
` For IP4 addresses, the connection address is defined as follows:
`
` o Typically the connection address will be a class-D IP multicast
`
` group address. If the session is not multicast, then the
` connection address contains the fully-qualified domain name or the
` unicast IP address of the expected data source or data relay or
` data sink as determined by additional attribute fields. It is not
` expected that fully-qualified domain names or unicast addresses
`
`Handley & Jacobson Standards Track [Page 12]
`
`AT&T Exhibit 1038
`AT&T v. VoIP, IPR 2017-01382
`Page 12
`
`

`

`
`RFC 2327 SDP April 1998
`
` will be given in a session description that is communicated by a
` multicast announcement, though this is not prohibited. If a
` unicast data stream is to pass through a network address
` translator, the use of a fully-qualified domain name rather than an
` unicast IP address is RECOMMENDED. In other cases, the use of an
` IP address to specify a particular interface on a multi-homed host
` might be required. Thus this specification leaves the decision as
` to which to use up to the individual application, but all
` applications MUST be able to cope with receiving both formats.
`
` o Conferences using an IP multicast connection address must also have
` a time to live (TTL) value present in addition to the multicast
` address. The TTL and the address together define the scope with
` which multicast packets sent in this conference will be sent. TTL
` values must be in the range 0-255.
`
` The TTL for the session is appended to the address using a slash as
` a separator. An example is:
`
` c=IN IP4 224.2.1.1/127
`
` Hierarchical or layered encoding schemes are data streams where the
` encoding from a single media source is split into a number of
` layers. The receiver can choose the desired quality (and hence
` bandwidth) by only subscribing to a subset of these layers. Such
` layered encodings are normally transmitted in multiple multicast
` groups to allow multicast pruning. This technique keeps unwanted
` traffic from sites only requiring certain levels of the hierarchy.
` For applications requiring multiple multicast groups, we allow the
` following notation to be used for the connection address:
`
` <base multicast address>/<ttl>/<number of addresses>
`
` If the number of addresses is not given it is assumed to be one.
` Multicast addresses so assigned are contiguously allocated above
` the base address, so that, for example:
`
` c=IN IP4 224.2.1.1/127/3
`
` would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are
` to be used at a ttl of 127. This is semantically identical to
` including multiple "c=" lines in a media description:
`
` c=IN IP4 224.2.1.1/127
` c=IN IP4 224.2.1.2/127
` c=IN IP4 224.2.1.3/127
`
`Handley & Jacobson Standards Track [Page 13]
`
`AT&T Exhibit 1038
`AT&T v. VoIP, IPR 2017-01382
`Page 13
`
`

`

`
`RFC 2327 SDP April 1998
`
` Multiple addresses or "c=" lines can only be specified on a per-
` media basis, and not for a session-level "c=" field.
`
` It is illegal for the slash notation described above to be used for
` IP unicast addresses.
`
` Bandwidth
`
` b=<modifier>:<bandwidth-value>
`
` o This specifies the proposed bandwidth to be used by the session or
` media, and is optional.
`
` o <bandwidth-value> is in kilobits per second
`
` o <modifier> is a single alphanumeric word giving the meaning of the
` bandwidth figure.
`
` o Two modifiers are initially defined:
`
` CT Conference Total: An implicit maximum bandwidth is associated with
` each TTL on the Mbone or within a particular multicast
` administrative scope region (the Mbone bandwidth vs. TTL limits are
` given in the MBone FAQ). If the bandwidth of a session or media in
` a session is different from the bandwidth implicit from the scope,
` a ‘b=CT:...’ line should be supplied for the session giving the
` proposed upper limit to the bandwidth used. The primary purpose of
` this is to give an approximate idea as to whether two or more
` conferences can co-exist simultaneously.
`
` AS Application-Specific Maximum: The bandwidth is interpreted to be
` application-specific, i.e., will be the application’s concept of
` maximum bandwidth. Normally this will coincide with what is set on
` the application’s "maximum bandwidth" control if applicable.
`
` Note that CT gives a total bandwidth figure for all the media at
` all sites. AS gives a bandwidth figure for a single media at a
` single site, although there may be many sites sending
` simultaneously.
`
` o Extension Mechanism: Tool writers can define experimental bandwidth
` modifiers by prefixing their modifier with "X-". For example:
`
` b=X-YZ:128
`
` SDP parsers should ignore bandwidth fields with unknown modifiers.
` Modifiers should be alpha-numeric and, although no length limit is
` given, they are recommended to be short.
`
`Handley & Jacobson Standards Track [Page 14]
`
`AT&T Exhibit 1038
`AT&T v. VoIP, IPR 2017-01382
`Page 14
`
`

`

`
`RFC 2327 SDP April 1998
`
` Times, Repeat Times and Time Zones
`
` t=<start time> <stop time>
`
` o "t=" fields specify the start and stop times for a conference
` session. Multiple "t=" fields may be used if a session is active
` at multiple irregularly spaced times; each additional "t=" field
` specifies an additional period of time for which the session will
` be active. If the session is active at regular times, an "r="
` field (see below) should be used in addition to and following a
` "t=" field - in which case the "t=" field specifies the start and
` stop times of the repeat sequence.
`
` o The first and second sub-fields give the start and stop times for
` the conference respectively. These values are the decimal
` representation of Network Time Protocol (NTP) time values in
` seconds [1]. To convert these values to UNIX time, subtract
` decimal 2208988800.
`
` o If the stop-time is set to zero, then the session is not bounded,
` though it will not become active until after the start-time. If
` the start-time is also zero, the session is regarded as permanent.
`
` User interfaces should st