|
|
|
|
|
|
ABNF Grammar for SDP
-- Session Description Protocol (RFC 4566)
|
This page documents the ABNF (Augmented Backus-Naur Form) definitions for SDP
text messages, defined in [RFC4566].
|
|
|
|
|
|
|
|
|
|
An SDP session description consists of a number of lines of text of the form:
<type>=<value>,
where:
| - <type> |
must be exactly one case-significant character, and
|
| - <value> |
is structured text whose format depends on
<type>.
|
Note:
For each element,
the '<type>=' is
shown in comment, with optional items marked with a '*'.
|
|
|
|
|
|
|
|
|
|
Here is an example of a session description with SDP:
|
|
|
|
|
|
|
|
|
|
The "v=" field gives the version of the Session Description Protocol. RFC4566 defines version 0.
There is no minor version number.
|
|
|
|
|
|
|
|
|
|
The "o=" field gives the originator of the session (his/her username and the address of the user's host)
plus a session identifier and version number.
|
|
|
|
| username | = |
non-ws-string
; <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.
; The <username> MUST NOT contain spaces.
|
| sess-id | = |
1*DIGIT
; <sess-id> is a numeric string such that the tuple of
; <username>, <sess-id>, <nettype>, <addrtype>, and <unicast-address>
; forms a globally unique identifier for the session.
; The method of <sess-id> allocation is up to the creating tool, but it has been
; suggested that a Network Time Protocol (NTP) format timestamp be
; used to ensure uniqueness [RFC1305].
|
| sess-version | = |
1*DIGIT
; <sess-version> is a version number for this session description. Its
; usage is up to the creating tool, so long as <sess-version> is
; increased when a modification is made to the session data. Again,
; it is RECOMMENDED that an NTP format timestamp is used.
|
| nettype | = |
token
; <nettype> is a text string giving the type of network. Initially
; "IN" is defined to have the meaning "Internet", but other values
; MAY be registered in the future.
|
| addrtype | = |
token
; <addrtype> is a text string giving the type of the address that
; follows. Initially "IP4" and "IP6" are defined, but other values
; MAY be registered in the future.
|
| unicast-address | |
; Address of the machine from which the session was created.
; The FQDN (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.
|
|
|
|
|
|
|
|
The "s" field is the textual session name. There MUST be one and
only one "s=" field per session description. The "s=" field MUST NOT
be empty and SHOULD contain ISO 10646 characters. If a session has no meaningful name, the
value "s= " SHOULD be used (i.e., a single space as the session
name).
|
|
| session-name-field | = |
%x73 "=" |
; s=
|
| |
text
CRLF
|
|
|
|
|
|
|
|
The "i=" field provides textual information about the session. There
MUST be at most one session-level "i=" field per session description,
and at most one "i=" field per media. If the "a=charset" attribute
is present, it specifies the character set used in the "i=" field.
If the "a=charset" attribute is not present, the "i=" field MUST
contain ISO 10646 characters in UTF-8 encoding.
A single "i=" field MAY also be used for each media definition. In
media definitions, "i=" fields are primarily intended for labelling
media streams. As such, they are most likely to be useful when a
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.
The "i=" field is intended to provide a free-form human-readable
description of the session or the purpose of a media stream. It is
not suitable for parsing by automata.
|
|
| information-field | = |
[%x69 "=" |
; i=
|
| |
text
CRLF]
|
|
|
|
|
|
|
|
A URI is a Uniform Resource Identifier as used by WWW clients
[RFC3986].
The URI should be a pointer to additional information about the
session. This field is OPTIONAL, but if it is present it MUST be
specified before the first media field. No more than one URI field
is allowed per session description.
|
|
|
|
|
|
|
|
|
|
The "e=" and "p=" lines specify contact information for the person
responsible for the conference. This is not necessarily the same
person that created the conference announcement.
Inclusion of an email address or phone number is OPTIONAL. Note that
the previous version of SDP specified that either an email field or a
phone field MUST be specified, but this was widely ignored. The
change brings the specification into line with common usage.
If an email address or phone number is present, it MUST be specified
before the first media field. More than one email or phone field can
be given for a session description.
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 MUST be enclosed in parentheses if it is
present. For example:
e=j.doe@example.com (Jane Doe)
The alternative
[RFC2822]
name quoting convention is also allowed
for both email addresses and phone numbers. For example:
e=Jane Doe <j.doe@example.com>
|
|
| email-fields | = |
*(%x65 "=" |
; e=
|
| |
email-address
CRLF)
|
|
| email-address | = |
address-and-comment
/ dispname-and-address
/ addrspec
|
| address-and-comment | = |
addrspec
1*SP
"("
1*email-safe
")"
|
| dispname-and-address | = |
1*email-safe
1*SP
"<"
addrspec
">"
|
| addrspec | = |
dot-atom
"@"
domain
; defined in RFC2822 (Internet Message Format)
|
|
|
|
|
|
|
|
The "e=" and "p=" lines specify contact information for the person
responsible for the conference. This is not necessarily the same
person that created the conference announcement.
Inclusion of an email address or phone number is OPTIONAL. Note that
the previous version of SDP specified that either an email field or a
phone field MUST be specified, but this was widely ignored. The
change brings the specification into line with common usage.
If an email address or phone number is present, it MUST be specified
before the first media field. More than one email or phone field can
be given for a session description.
Phone numbers SHOULD be given in the form of an international public
telecommunication number (see ITU-T Recommendation E.164) preceded by
a "+". Spaces and hyphens may be used to split up a phone field to
aid readability if desired. For example:
p=+1 617 555-6011
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 MUST be enclosed in parentheses if it is
present. For example:
e=j.doe@example.com (Jane Doe)
The alternative
[RFC2822]
name quoting convention is also allowed
for both email addresses and phone numbers. For example:
e=Jane Doe <j.doe@example.com>
|
|
| phone-fields | = |
*(%x70 "=" |
; p=
|
| |
phone-number
CRLF)
|
|
| phone-number | = |
phone
*SP
"("
1*email-safe
")"
/ 1*email-safe
"<"
phone
">"
/ phone
|
| phone | = |
["+"]
DIGIT
1*( SP
/ "-"
/ DIGIT )
|
|
|
|
|
|
|
|
The "c=" field contains connection data.
A session description MUST contain either at least one "c=" field in
each media description or a single "c=" field at the session level.
It MAY contain a single session-level "c=" field and additional "c="
field(s) per media description, in which case the per-media values
override the session-level settings for the respective media.
|
|
| connection-field | = |
[%x63 "=" |
; c=
|
| |
nettype SP
addrtype SP
connection-address
CRLF]
|
|
| nettype | = |
token
; Type of Network: "IN" is defined to have the meaning "Internet"
|
| addrtype | = |
token
; Type of the address that follows": IP4" or "IP6"
|
| connection-address | = |
multicast-address
/ unicast-address
|
|
|
|
|
|
|
|
This OPTIONAL field denotes the proposed bandwidth to be used by the
session or media. The <bwtype> is an alphanumeric modifier giving
the meaning of the <bandwidth> figure.
|
|
| bandwidth-fields | = |
*(%x62 "=" |
; b=
|
| |
bwtype
":"
bandwidth
CRLF)
|
|
| bwtype | = |
token
; alphanumeric modifier giving the meaning of the bandwidth figure:
|
| | |
| ; |
"CT" |
Conference Total |
[RFC4566] |
| ; |
"AS" |
Application Specific |
[RFC4566] |
| ; |
"RS" |
RTCP for Senders |
[RFC3556] |
| ; |
"RR" |
RTCP for Receivers |
[RFC3556] |
| ; |
"TIAS" |
Transport Independent
Application Specific |
[RFC3890] |
|
| bandwidth | = |
1*DIGIT
; By default: interpreted as kilobits per second
|
|
|
|
|
|
|
|
The "t=" lines specify the start and stop times for a session.
Multiple "t=" lines MAY be used if a session is active at multiple
irregularly spaced times; each additional "t=" lines specifies an
additional period of time for which the session will be active. If
the session is active at regular times, an "r=" line
should be used in addition to, and following, a "t=" line - in which
case the "t=" line specifies the start and stop times of the repeat
sequence.
|
|
| time-fields | = |
1*( %x74 "=" |
; t=
|
| |
start-time SP
stop-time
*( CRLF
repeat-fields )
CRLF)
[zone-adjustments CRLF]
|
|
| start-time | = |
time
/ "0"
|
| stop-time | = |
time
/ "0"
|
| time | = |
POS-DIGIT 9*DIGIT
; Decimal representation of NTP time in seconds since 1900.
; The representation of NTP time is an unbounded length field
; containing at least 10 digits. Unlike the 64-bit representation
; used elsewhere, time in SDP does not wrap in the year 2036.
|
| repeat-fields | = |
%x72 "="
repeat-interval SP
typed-time
1*(SP typed-time)
|
| repeat-interval | = |
POS-DIGIT *DIGIT [fixed-len-time-unit]
|
| typed-time | = |
1*DIGIT [fixed-len-time-unit]
|
| fixed-len-time-unit | = |
"d"
/ "h"
/ "m"
/ "s"
|
| zone-adjustments | = |
%x7a "="
time
SP ["-"]
typed-time
*(SP time
SP ["-"]
typed-time)
|
|
|
|
|
|
|
|
If transported over a secure and trusted channel, the Session
Description Protocol MAY be used to convey encryption keys. A simple
mechanism for key exchange is provided by the key field ("k="),
although this is primarily supported for compatibility with older
implementations and its use is NOT RECOMMENDED.
New key exchange mechanisms for use with SDP have been defined in
[RFC4567] and
[RFC4568],
and
it is expected that new applications will use those mechanisms.
|
|
| key-field | = |
[%x6b "="
key-type
CRLF]
|
| key-type | = |
"prompt"
/ "clear:" text
/ "base64:"
base64
/ "uri:"
uri
|
| base64 | = |
*base64-unit
[base64-pad]
|
| base64-unit | = |
4base64-char
|
| base64-pad | = |
2base64-char
"=="
/ 3base64-pad
"="
|
| base64-char | = |
ALPHA / DIGIT / "+"
/ "/"
|
|
|
|
|
|
|
|
Attributes are the primary means for extending SDP. Attributes may
be defined to be used as "session-level" attributes, "media-level"
attributes, or both.
|
|
| attribute-fields | = |
*(%x61 "="
attribute
CRLF)
|
| attribute | = |
(att-field
":"
att-value)
/ att-field
|
| att-field | = |
token
|
| att-value | = |
byte-string
|
|
; both session and media level:
;
|
| ; | a=recvonly |
[RFC4566] |
| ; | a=sendrecv |
[RFC4566] |
| ; | a=sendonly |
[RFC4566] |
| ; | a=inactive | RFC3108, RFC4566 (and used in RFC3264) |
| ; | a=sdplang:<language tag> |
[RFC4566] |
| ; | a=lang:<language tag> |
[RFC4566] |
| ; | a=maxprate:<packet-rate> |
[RFC3890] |
| ; | a=setup:<role> |
[RFC4145] |
| ; | a=connection:<conn-value> |
[RFC4145] |
| ; | a=key-mgmt:<prtcl-id> <keymgmt-data> |
[RFC4567] |
| ; | a=source-filter:<filter-mode> <filter-spec> |
[RFC4570] |
| ; | a=fingerprint:<hash-func> <fingerprint> |
[RFC4572] |
|
;
; session level:
;
|
| ; | a=cat:<category> |
[RFC4566] |
| ; | a=keywds:<keywords> |
[RFC4566] |
| ; | a=tool:<name and version of tool> |
[RFC4566] |
| ; | a=type:<conference type> |
[RFC4566] |
| ; | a=charset:<character set> |
[RFC4566] |
| ; | a=group:LS <identification-tags> |
[RFC3388] |
| ; | a=group:FID <identification-tags> |
[RFC3388] |
| ; | a=group:FEC <identification-tags> |
[RFC4756] |
|
;
; media level:
;
|
| ; | a=ptime:<packet time> |
[RFC4566] |
| ; | a=rtpmap:<payload type>
<encoding name>/<clock rate>
<encoding parameters> |
[RFC4566] |
| ; | a=orient:<orientation> |
[RFC4566] |
| ; | a=framerate:<frame rate> |
[RFC4566] |
| ; | a=quality:<quality> |
[RFC4566] |
| ; | a=fmtp:<format>
<format specific parameters> |
[RFC4566] |
| ; | a=maxptime:<maximum packet time> | RFC3267, RFC4566 |
| ; | a=curr:<precondition-type>
<status-type> <direction-tag> |
[RFC3312] |
| ; | a=des:<precondition-type>
<strength-tag> <status-type> <direction-tag> |
[RFC3312] |
| ; | a=conf:<precondition-type>
<status-type> <direction-tag> |
[RFC3312] |
| ; | a=mid:<identification-tags> |
[RFC3388] |
| ; | a=rtcp:<port> |
[RFC3605] |
| ; | a=crypto:<tag> <crypto-suite> <key-params> [<session-param>] |
[RFC4568] |
| ; | a=label:<pointer> |
[RFC4574] |
| ; | a=floorctrl:<role> |
[RFC4583] |
| ; | a=confid:<conference-id> |
[RFC4583] |
| ; | a=floorid:<token> |
[RFC4583] |
| ; | a=content:<mediacnt-tag> |
[RFC4796] |
| |
|
|
|
|
The ABNF rules for the attributes defined in [RFC3312]
(Integration of Resource Management and SIP) are as follows:
|
|
| current-status | = |
"a=curr:"
precondition-type
SP status-type
SP direction-tag CRLF
|
| desired-status | = |
"a=des:"
precondition-type
SP strength-tag
SP status-type
SP direction-tag CRLF
|
| confirm-status | = |
"a=conf:"
precondition-type
SP status-type
SP direction-tag CRLF
|
| precondition-type | = |
"qos" / token
|
| strength-tag | = |
("mandatory"
/ "optional"
/ "none"
/ "failure"
/ "unknown")
|
| status-type | = |
("e2e"
/ "local"
/ "remote")
|
| direction-tag | = |
("none"
/ "send"
/ "recv"
/ "sendrecv")
|
|
|
|
The ABNF rules for the attributes defined in [RFC3388]
(Grouping of Media Lines in the SDP) are as follows:
|
|
| mid-attribute | = |
"a=mid:"
identification-tag CRLF
|
| identification-tag | = |
token
|
| group-attribute | = |
"a=group:"
semantics
*(SP identification-tag) CRLF
|
| semantics | = |
"LS"
/ "FID"
/ "SRF"
/ "ANAT"
/ "FEC"
; LS: Lip Synchronization
; FID: Flow Identification
; SRF: Single Reservation flow [RFC3524]
; ANAT: Alternative Network Address Types [RFC4091]
; FEC: Forward Error Correction [RFC4756]
|
|
|
|
The ABNF rule for the attribute defined in [RFC3605]
(RTCP attribute in SDP) is as follows:
|
|
|
|
|
|
The ABNF rules for the attribute defined in [RFC3890]
(a Transport Independent Bandwidth Modifier
for the SDP) are as follows:
|
|
| max-p-rate-def | = |
"a=maxprate:"
packet-rate CRLF
|
| packet-rate | = |
1*DIGIT ["." 1*DIGIT]
|
|
|
|
|
|
The ABNF rules for the attributes defined in [RFC4145]
(TCP-Based Media Transport in the SDP) are as follows:
|
|
| setup-attr | = |
"a=setup:"
role CRLF
|
| role | = |
"active"
/ "passive"
/ "actpass"
/ "holdconn"
|
| connection-attr | = |
"a=connection:"
conn-value CRLF
|
| conn-value | = |
"new"
/ "existing"
|
|
|
|
|
|
The ABNF rules for the attributes defined in [RFC4567]
(Key Management Extensions for SDP and RTSP) are as follows:
|
|
| key-mgmt-attribute | = |
key-mgmt-att-field
":"
key-mgmt-att-value
|
| key-mgmt-att-field | = |
"key-mgmt"
|
| key-mgmt-att-value | = |
0*1SP prtcl-id
SP keymgmt-data
|
| prtcl-id | = |
KMPID
|
| KMPID | = |
1*(ALPHA / DIGIT)
|
| keymgmt-data | = |
base64
|
|
|
|
|
|
The ABNF rules for the attributes defined in [RFC4568]
(SDP Security Descriptions for Media Streams) are as follows:
Generic "Crypto" Attribute Grammar:
|
|
| crypto-attr | = |
"a=crypto:"
tag
1*WSP crypto-suite
1*WSP key-params
*(1*WSP session-param)
CRLF
|
| tag | = |
1*9DIGIT
|
| crypto-suite | = |
1*(ALPHA / DIGIT / "_")
|
| key-params | = |
key-param
*(";"
key-param)
|
| key-param | = |
key-method
":"
key-info
|
| key-method | = |
"inline"
/ key-method-ext
|
| key-method-ext | = |
1*(ALPHA / DIGIT / "_")
|
| key-info | = |
1*(%x21-3A / %x3C-7E)
; visible (printing) chars except semi-colon
|
| session-param | = |
1*(VCHAR)
; visible (printing) chars
|
|
SRTP "Crypto" Attribute Grammar:
|
|
| crypto-suite | = |
srtp-crypto-suite
|
| key-method | = |
srtp-key-method
|
| key-info | = |
srtp-key-info
|
| session-param | = |
srtp-session-param
|
| srtp-crypto-suite | = |
"AES_CM_128_HMAC_SHA1_32" /
"F8_128_HMAC_SHA1_32" /
"AES_CM_128_HMAC_SHA1_80" /
srtp-crypto-suite-ext
|
| srtp-key-method | = |
"inline"
|
| srtp-key-info | = |
key-salt
["|"
lifetime]
["|"
mki]
|
| srtp-session-param | = |
kdr /
"UNENCRYPTED_SRTP" /
"UNENCRYPTED_SRTCP" /
"UNAUTHENTICATED_SRTP" /
fec-order /
fec-key /
wsh /
srtp-session-extension
|
| kdr | = |
"KDR=" 1*2(DIGIT)
; range 0..24, power of two
|
| fec-order | = |
"FEC_ORDER="
fec-type
|
| fec-type | = |
"FEC_SRTP=" /
"SRTP_FEC="
|
| fec-key | = |
"FEC_KEY="
key-params
|
| wsh | = |
"WSH=" 2*DIGIT
; minimum value is 64
|
| base64 | = |
ALPHA / DIGIT /
"+"
/ "/"
/ "="
|
| srtp-crypto-suite-ext | = |
1*(ALPHA / DIGIT /
"_")
|
| srtp-session-extension | = |
["-"] 1*(VCHAR)
; first character must not be dash ("-")
|
|
|
|
|
|
The ABNF rules for the attributes defined in [RFC4570]
(SDP Source Filters) are as follows:
|
|
| source-filter | = |
"source-filter"
":" SP
filter-mode SP
filter-spec
|
| filter-mode | = |
"excl" /
"incl"
|
| filter-spec | = |
nettype
SP address-types
SP dest-address
SP src-list
|
| address-types | = |
"*" /
addrtype
; "*" for all address types (both IP4 and IP6), but only
; when <dest-address> and <src-list> reference FQDNs.
|
| dest-address | = |
"*" /
basic-multicast-address /
unicast-address
; "*" applies to all connection-address values.
|
| src-list | = |
*(unicast-address SP)
unicast-address
; one or more unicast source addresses (in
; standard IPv4 or IPv6 ASCII-notation form) or FQDNs.
|
| basic-multicast-address | = |
basic-IP4-multicast /
basic-IP6-multicast /
FQDN /
extn-addr
; i.e., the same as multicast-address
; defined in [RFC4566], except that the
; /<ttl> and /<number of addresses>
; fields are not included.
|
| basic-IP4-multicast | = |
m1
3( "."
decimal-uchar )
|
| basic-IP6-multicast | = |
hexpart
|
|
|
|
|
|
The ABNF rules for the attributes defined in [RFC4572]
(Comedia over TLS in SDP) are as follows:
|
|
| fingerprint-attribute | = |
"fingerprint"
":"
hash-func SP
fingerprint
|
| hash-func | = |
"sha-1" /
"sha-224" /
"sha-256" /
"sha-384" /
"sha-512" /
"md5" /
"md2" / token
|
| fingerprint | = |
2UHEX
*(":"
2UHEX)
|
| UHEX | = |
DIGIT / %x41-46
|
|
|
|
|
|
The ABNF rules for the attributes defined in [RFC4574]
(The SDP Label Attribute) are as follows:
|
|
| label-attribute | = |
"a=label:"
pointer
|
| pointer | = |
token
|
| token | = |
1*(token-char)
|
| token-char | = |
%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / %x41-5A / %x5E-7E
|
|
|
|
|
|
|
|
The ABNF rules for the attributes defined in [RFC4583]
(SDP Format for BFCP Streams) are as follows:
|
|
| floor-control-attribute | = |
"a=floorctrl:"
role
*(SP role)
|
| role | = |
"c-only"
/ "s-only"
/ "c-s"
|
| confid-attribute | = |
"a=confid:"
conference-id
|
| conference-id | = |
token
|
| userid-attribute | = |
"a=userid:"
user-id
|
| conference-id | = |
token
|
|
|
|
|
|
|
|
The ABNF rules for the attributes defined in [RFC4796]
(The SDP Content Attribute) are as follows:
|
|
| content-attribute | = |
"a=content:"
mediacnt-tag
|
| mediacnt-tag | = |
mediacnt
*(","
mediacnt)
|
| mediacnt | = |
"slides"
/ "speaker"
/ "sl"
/ "main"
/ "alt"
/ mediacnt-ext
|
| mediacnt-ext | = |
token
|
|
|
|
|
|
|
|
Each media description starts with an "m=" field, and is terminated
by either the next "m=" field or by the end of the session
description.
|
|
| media-descriptions | = |
|
| media-field | = |
%x6d "="
media SP
port
["/" integer] SP
proto
1*(SP
fmt)
CRLF
|
| media | = |
token
; Media Type:
|
| | |
|
| port | = |
1*DIGIT
; Transport Port to which the media stream is sent:
; The meaning of the transport port depends on the network being
; used as specified in the relevant "c=" field, and on the transport
; protocol defined in the <proto> sub-field of the media field.
; Other ports used by the media application (such as the RTCP port)
; may be derived algorithmically from the base media port or
; may be specified in a separate attribute (for example "a=rtcp:").
|
| proto | = |
token
*("/" token)
; Transport Protocol:
|
| | |
|
| fmt | = |
token
; Media Formats:
; If the Transport Protocol is "RTP/AVP" or "RTP/SAVP" the <fmt>
; sub-fields contain RTP payload type numbers, for example:
; - for Audio: 0: PCMU, 4: G723, 8: PCMA, 18: G729
; - for Video: 31: H261, 32: MPV
; If the Transport Protocol is "udp" the <fmt> sub-fields
; must reference a MIME type
|
|
|
|
|
|
|
The following Table reports the final set of static payload type assignments
provided in Tables 4 and 5 of [RFC 3551] (RTP Profile for Audio and Video Conferences with Minimal
Control).
RFC 3551 establishes the policy that no additional static
payload types will be assigned beyond the ones defined in this
RFC. Establishing this policy
encourages the implementation and deployment of the dynamic payload
type mechanisms.
Mechanisms for defining dynamic payload type bindings have been
specified in the SDP (rtpmap) and in other
protocols such as ITU-T Recommendation H.323/H.245.
|
|
|
|
|
|
Payload
Type |
Encoding
Name |
Media
Type |
Clock
Rate (Hz) |
Channels
(audio) |
| |
| 0 |
PCMU |
A |
8,000 |
1 |
PCMU denotes PCM (pulse code modulation) with mu-law scaling; it is specified in ITU-T G.711. Audio
data is encoded as eight bits per sample, after logarithmic scaling.
| |
| 1 |
reserved |
A |
|
|
This payload type was assigned to
"1016" in RFC1890 but was removed
because two interoperable implementations were not found.
| |
| 2 |
reserved |
A |
|
|
This payload type was assigned to "G721" in RFC1890 but its use is now deprecated.
| |
| 3 |
GSM |
A |
8,000 |
1 |
GSM (Global System for Mobile Communications) denotes the European GSM 06.10 standard
for full-rate speech transcoding, ETS 300 961, which is based on
RPE/LTP (residual pulse excitation/long term prediction) coding.
Blocks of 160 audio samples are compressed into 33 octets, for an
effective data rate of 13,200 b/s.
| |
| 4 |
G723 |
A |
8,000 |
1 |
G723 is specified in ITU Recommendation G.723.1, "Dual-rate speech
coder for multimedia communications transmitting at 5.3 and 6.3
kbit/s".
| |
| 5 |
DVI4 |
A |
8,000 |
1 |
DVI4 uses an adaptive delta pulse code modulation (ADPCM) encoding
scheme that was specified by the Interactive Multimedia Association
(IMA) as the "IMA ADPCM wave type". However, the encoding defined
in RFC 3551 as DVI4 differs in three respects from the IMA specification.
| |
| 6 |
DVI4 |
A |
16,000 |
1 |
| |
| 7 |
LPC |
A |
8,000 |
1 |
LPC designates an experimental linear predictive encoding contributed
by Ron Frederick, which is based on an implementation written by Ron
Zuckerman posted to the Usenet group comp.dsp on June 26, 1992. The
codec generates 14 octets for every frame. The framesize is set to
20 ms, resulting in a bit rate of 5,600 b/s.
| |
| 8 |
PCMA |
A |
8,000 |
1 |
PCMU denotes PCM (pulse code modulation) with A-law scaling; it is specified in ITU-T G.711. Audio
data is encoded as eight bits per sample, after logarithmic scaling.
| |
| 9 |
G722 |
A |
8,000 |
1 |
G722 is specified in ITU-T Recommendation G.722, "7 kHz audio-coding
within 64 kbit/s". Even though the actual sampling rate for G.722 audio is 16,000 Hz,
the RTP clock rate for the G722 payload format is 8,000 Hz because
that value was erroneously assigned in RFC1890 and must remain
unchanged for backward compatibility.
| |
| 10 |
L16 |
A |
44,100 |
2 |
L16 denotes uncompressed audio data samples, using 16-bit signed
representation with 65,535 equally divided steps between minimum and
maximum signal level, ranging from -32,768 to 32,767. The value is
represented in two's complement notation and transmitted in network
byte order (most significant byte first).
| |
| 11 |
L16 |
A |
44,100 |
1 |
| |
| 12 |
QCELP |
A |
8,000 |
1 |
The Electronic Industries Association (EIA) & Telecommunications
Industry Association (TIA) standard IS-733, "TR45: High Rate Speech
Service Option for Wideband Spread Spectrum Communications Systems",
defines the QCELP audio compression algorithm for use in wireless
CDMA applications. The QCELP CODEC compresses each 20 milliseconds
of 8,000 Hz, 16-bit sampled input speech into one of four different
size output frames: Rate 1 (266 bits), Rate 1/2 (124 bits), Rate 1/4
(54 bits) or Rate 1/8 (20 bits). For typical speech patterns, this
results in an average output of 6.8 kb/s for normal mode and 4.7 kb/s
for reduced rate mode. The packetization of the QCELP audio codec is
described in RFC 2658.
| |
| 13 |
CN |
A |
8,000 |
1 |
The comfort noise (CN) payload type is
primarily for use with audio codecs that do not support comfort noise
as part of the codec itself such as ITU-T Recommendations G.711,
G.726, G.727, G.728, and G.722. The payload format is specified in
RFC 3389.
| |
| 14 |
MPA |
A |
90,000 |
1 |
MPA denotes MPEG-1 or MPEG-2 audio encapsulated as elementary
streams. The encoding is defined in ISO standards ISO/IEC 11172-3
and 13818-3. The encapsulation is specified in RFC 2250.
| |
| 15 |
G728 |
A |
8,000 |
1 |
G728 is specified in ITU-T Recommendation G.728, "Coding of speech at
16 kbit/s using low-delay code excited linear prediction".
| |
| 16 |
DVI4 |
A |
11,025 |
1 |
DVI4 uses an adaptive delta pulse code modulation (ADPCM) encoding
scheme that was specified by the Interactive Multimedia Association
(IMA) as the "IMA ADPCM wave type". However, the encoding defined
in RFC 3651 as DVI4 differs from the IMA specification.
| |
| 17 |
DVI4 |
A |
22,050 |
1 |
| |
| 18 |
G729 |
A |
8,000 |
1 |
G729 is specified in ITU-T Recommendation G.729, "Coding of speech at
8 kbit/s using conjugate structure-algebraic code excited linear
prediction (CS-ACELP)".
| |
| 19 |
reserved |
A |
|
|
Payload type 19 is marked "reserved"
because some draft versions of RFC 3651 assigned that
number to an earlier version of the comfort noise payload format.
| |
| 20 |
unassigned |
A |
|
|
| |
| 21 |
unassigned |
A |
|
|
| |
| 22 |
unassigned |
A |
|
|
| |
| 23 |
unassigned |
A |
|
|
| |
| 24 |
unassigned |
V |
|
|
| |
| 25 |
CelB |
V |
90,000 |
|
The CELL-B encoding is a proprietary encoding proposed by Sun
Microsystems. The byte stream format is described in RFC 2029.
| |
| 26 |
JPEG |
V |
90,000 |
|
The encoding is specified in ISO Standards 10918-1 and 10918-2. The
RTP payload format is as specified in RFC 2435.
| |
| 27 |
unassigned |
V |
|
|
| |
| 28 |
nv |
V |
90,000 |
|
The encoding is implemented in the program 'nv', version 4, developed
at Xerox PARC by Ron Frederick.
| |
| 29 |
unassigned |
V |
|
|
| |
| 30 |
unassigned |
V |
|
|
| |
| 31 |
H261 |
V |
90,000 |
|
The encoding is specified in ITU-T Recommendation H.261, "Video codec
for audiovisual services at p x 64 kbit/s". The packetization and
RTP-specific properties are described in RFC 2032.
| |
| 32 |
MPV |
V |
90,000 |
|
MPV designates the use of MPEG-1 and MPEG-2 video encoding elementary
streams as specified in ISO Standards ISO/IEC 11172 and 13818-2,
respectively. The RTP payload format is as specified in RFC 2250, Section 3.
| |
| 33 |
MP2T |
AV |
90,000 |
|
MP2T designates the use of MPEG-2 transport streams, for either audio
or video. The RTP payload format is described in RFC 2250,
Section 2.
| |
| 34 |
H263 |
V |
90,000 |
|
The encoding is specified in the 1996 version of ITU-T Recommendation
H.263, "Video coding for low bit rate communication". The
packetization and RTP-specific properties are described in RFC 2190.
The H263-1998 payload format is RECOMMENDED over this one for
use by new implementations.
| |
| 35-71 |
unassigned |
? |
|
|
| |
| 72-76 |
reserved |
|
|
|
Reserved for RTCP conflict avoidance
| |
| 77-95 |
unassigned |
? |
|
|
| |
| 96-127 |
dynamic |
? |
|
|
RTP A/V profile reserves payload type numbers in the range 96-127
exclusively for dynamic assignment. Applications SHOULD first use
values in this range for dynamic payload types. Those applications
which need to define more than 32 dynamic payload types MAY bind
codes below 96, in which case it is RECOMMENDED that unassigned
payload type numbers be used first. However, the statically assigned
payload types are default bindings and MAY be dynamically bound to
new encodings if needed. Redefining payload types below 96 may cause
incorrect operation if an attempt is made to join a session without
obtaining session description information that defines the dynamic
payload types.
| |
|
|
|
|
|
|
Here are the generic sub-rules related to addressing defined in
RFC 4566,
from the core rules and generic sub-rules:
|
|
| unicast-address | = |
IP4-address
/ IP6-address
/ FQDN
/ extn-addr
|
| multicast-address | = |
IP4-multicast
/ IP6-multicast
/ FQDN
/ extn-addr
|
| IP4-address | = |
b1
3( "." decimal-uchar )
|
| b1 | = |
decimal-uchar
; less than "224"
|
| IP6-address | = |
hexpart
[ ":"
IP4-address ]
|
| hexpart | = |
hexseq
/ hexseq
"::"
[ hexseq ]
/ "::"
[ hexseq ]
|
| hexseq | = |
hex4
*( ":"
hex4)
|
| hex4 | = |
1*4HEXDIG
|
| IP4-multicast | = |
m1
3( "." decimal-uchar )
"/"
ttl
[ "/" integer ]
; IPv4 multicast addresses may be in the
; range 224.0.0.0 to 239.255.255.255
|
| m1 | = |
("22"
("4"
/ "5"
/ "6"
/ "7"
/ "8"
/ "9"))
/ ("23" DIGIT )
|
| ttl | = |
(POS-DIGIT *2DIGIT) / "0"
|
| IP6-multicast | = |
hexpart
[ "/" integer ]
; IPv6 address starting with FF
|
| FQDN | = |
4*(alpha-numeric / "-"
/ ".")
; fully qualified domain name as specified in RFC1035
; (Domain names - implementation and specification) and updates
|
| extn-addr | = |
non-ws-string
; Generic for other address families
|
|
|
|
|
|
Here are the generic sub-rules defined in
RFC 4566, from the ABNF core rules:
|
|
| alpha-numeric | = |
ALPHA
/ DIGIT
|
| POS-DIGIT | = |
%x31-39
; 1-9
|
| decimal-uchar | = |
DIGIT
/ POS-DIGIT DIGIT
/ ("1"
2*(DIGIT))
/ ("2"
("0"
/ "1"
/ "2"
/ "3"
/ "4")
DIGIT)
/ ("2"
"5"
("0"
/ "1"
/ "2"
/ "3"
/ "4"
/ "5"))
|
| text | = |
byte-string
; default is to interpret this as UTF8 text.
; ISO 8859-1 requires "a=charset:ISO-8859-1" session-level attribute to be used
|
| byte-string | = |
1*( %x01-09 / %x0B-0C / %x0E-FF )
; any byte except NUL, CR or LF
|
| non-ws-string | = |
1*( VCHAR / %x80-FF )
; string of visible characters
|
| token | = |
1*(token-char)
|
| token-char | = |
%x21 / %x23-27 / %x2A-2B /
%x2D-2E / %x30-39 / %x41-5A / %x5E-7E
|
| email-safe | = |
%x01-09 / %x0B-0C / %x0E-27 / %x2A-3B / %x3D / %x3F-FF
; any byte except NUL, CR, LF, or the quoting characters ()<>
|
| integer | = |
POS-DIGIT
*DIGIT
|
|
|
|
