diff options
Diffstat (limited to 'lib/megaco/include/megaco_sdp.hrl')
| -rw-r--r-- | lib/megaco/include/megaco_sdp.hrl | 1471 |
1 files changed, 1471 insertions, 0 deletions
diff --git a/lib/megaco/include/megaco_sdp.hrl b/lib/megaco/include/megaco_sdp.hrl new file mode 100644 index 0000000000..e6d9f92edd --- /dev/null +++ b/lib/megaco/include/megaco_sdp.hrl @@ -0,0 +1,1471 @@ +%% ``The contents of this file are subject to the Erlang Public License, +%% Version 1.1, (the "License"); you may not use this file except in +%% compliance with the License. You should have received a copy of the +%% Erlang Public License along with this software. If not, it can be +%% retrieved via the world wide web at http://www.erlang.org/. +%% +%% Software distributed under the License is distributed on an "AS IS" +%% basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See +%% the License for the specific language governing rights and limitations +%% under the License. +%% +%% The Initial Developer of the Original Code is Ericsson Utvecklings AB. +%% Portions created by Ericsson are Copyright 1999, Ericsson Utvecklings +%% AB. All Rights Reserved.'' +%% +%% $Id$ +%% +%%---------------------------------------------------------------------- +%% Purpose: +%%---------------------------------------------------------------------- +%% +%% +%% Explanaition of the fields in the SDP body +%% (See RFC 4566 for the complete decription) +%% +%% Session descriptions +%% +%% v protocol version +%% o owner/creator and session identifier +%% s session name (optional) +%% i session information (optional) +%% u URI of description (optional) +%% e email address (optional) +%% p phone number (optional) +%% c connection information (optional) +%% b bandwidth information (optional) +%% One or more time descriptions ("t=" and "r=" lines; see below) +%% z time zone adjustment (optional) +%% k encryption key (optional) +%% a zero or more session attribute lines (optional) +%% Zero or more media descriptions +%% +%% Time descriptions +%% +%% t time the session is active +%% r zero or more repeat times (optional) +%% +%% Media descriptions, if present +%% +%% m media name and transport address +%% i media title (optional) +%% c connection information - optional if included at session-level +%% b bandwidth information (optional) +%% k encryption key (optional) +%% a zero or more media attribute lines (optional) +%% +%% +%% An example SDP description is: +%% +%% v=0 +%% o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 +%% s=SDP Seminar +%% i=A Seminar on the session description protocol +%% u=http://www.example.com/seminars/sdp.pdf +%% [email protected] (Jane Doe) +%% c=IN IP4 224.2.17.12/127 +%% t=2873397496 2873404696 +%% a=recvonly +%% m=audio 49170 RTP/AVP 0 +%% m=video 51372 RTP/AVP 99 +%% a=rtpmap:99 h263-1998/90000 +%% +%% +%%---------------------------------------------------------------------- + +-ifndef(megaco_sdp_). +-define(megaco_sdp_, true). + + +%% =================================================================== +%% +%% Protocol Version ("v=") +%% +%% v=0 +%% +%% The "v=" field gives the version of the Session Description +%% Protocol. This memo defines version 0. There is no minor version +%% number +%% + +-record(megaco_sdp_v, { + version % integer() + } + ). + + + + +%% =================================================================== +%% +%% Origin ("o=") +%% +%% o=<username> <sess-id> <sess-version> <nettype> <addrtype> +%% <unicast-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. The <username> MUST NOT contain spaces. +%% +%% <sess-id> is a numeric string such that the tuple of <username>, +%% <sess-id>, <nettype>, <addrtype> and <unicast-address> form 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) +%% timestamp be used to ensure uniqueness [13]. +%% +%% <sess-version> is a version number for this announcement. 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> 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 (see Section 8 +%% of RFC 4566). +%% +%% <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 (see Section 8 +%% of RFC 4566). +%% +%% <unicast-address> is the 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 (for example, a local address MUST NOT be included +%% in an application-level referral that might leave the scope). +%% +%% 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. +%% +%% For privacy reasons, it is sometimes desirable to obfuscate the +%% username and IP address of the session originator. If this is a +%% concern, an arbitrary <username> and private <unicast-address> MAY be +%% chosen to populate the "o=" field, provided that these are selected +%% in a manner that does not affect the global uniqueness of the field. +%% +%% + +-record(megaco_sdp_o, { + user_name, % <username> string() + session_id, % <sess-id> integer() + version, % <sess-version> integer() + network_type = in, % <nettype> in | string() + address_type = ip4, % <addrtype> ip4 | ip6 | string() + address % <unicast-address> string() + } + ). + + +%% =================================================================== +%% +%% Session Name ("s=") +%% +%% s=<session name> +%% +%% 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 (but see also +%% the "a=charset" attribute). If a session has no meaningful name, +%% the value "s= " SHOULD be used (i.e., a single space as the session +%% name). +%% + +-record(megaco_sdp_s, { + name % string() + } + ). + + + + +%% =================================================================== +%% +%% Session and Media Information ("i=") +%% +%% i=<session description> +%% +%% 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. +%% + +-record(megaco_sdp_i, { + session_descriptor % string() + } + ). + + + + +%% =================================================================== +%% +%% URI ("u=") +%% +%% u=<URI> +%% +%% A URI is a Uniform Resource Identifier as used by WWW clients [7]. +%% 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. +%% + +-record(megaco_sdp_u, { + uri % string() + } + ). + + + + +%% =================================================================== +%% +%% Email Address and Phone Number ("e=" and "p=") +%% +%% e=<email address> +%% p=<phone number> +%% +%% 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: +%% +%% [email protected] (Jane Doe) +%% +%% The alternative RFC 2822 [29] name quoting convention is also +%% allowed for both email addresses and phone numbers. For example: +%% +%% e=Jane Doe <[email protected]> +%% +%% 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 session-level "a=charset" attribute is set. +%% + +-record(megaco_sdp_e, { + email % string() + } + ). + +-record(megaco_sdp_p, { + phone_number % string() + } + ). + + + + +%% =================================================================== +%% +%% Connection Data ("c=") +%% +%% c=<nettype> <addrtype> <connection-address> +%% +%% 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. +%% +%% The first sub-field ("<nettype>") is the network type, which 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 (see Section 8 of RFC 4566). +%% +%% The second sub-field ("<addrtype>") is the address type. This +%% allows SDP to be used for sessions that are not IP based. This +%% memo only defines IP4 and IP6, but other values MAY be registered +%% in the future (see Section 8 of RFC 4566). +%% +%% The third sub-field ("<connection-address>") is the connection +%% address. OPTIONAL sub-fields MAY be added after the connection +%% address depending on the value of the <addrtype> field. +%% +%% When the <addrtype> is IP4 and IP6, the connection address is +%% defined as follows: +%% +%% o If the session is multicast, the connection address will be an +%% IP multicast group address. If the session is not multicast, +%% then the connection address contains 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 unicast addresses will be given in a session description +%% that is communicated by a multicast announcement, though this +%% is not prohibited. +%% +%% o Sessions using an IPv4 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. Although the +%% TTL MUST be specified, its use to scope multicast traffic is +%% deprecated; applications SHOULD use an administratively scoped +%% address instead. +%% +%% The TTL for the session is appended to the address using a slash +%% as a separator. An example is: +%% +%% c=IN IP4 224.2.36.42/127 +%% +%% IPv6 multicast does not use TTL scoping, and hence the TTL value +%% MUST NOT be present for IPv6 multicast. It is expected that IPv6 +%% scoped addresses will be used to limit the scope of conferences. +%% +%% 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 +%% +%% Similarly, an IPv6 example would be: +%% +%% c=IN IP6 FF15::101/3 +%% +%% which is semantically equivalent to: +%% +%% c=IN IP6 FF15::101 +%% c=IN IP6 FF15::102 +%% c=IN IP6 FF15::103 +%% +%% (remembering that the TTL field is not present in IPv6 multicast). +%% +%% Multiple addresses or "c=" lines MAY be specified on a per-media +%% basis only if they provide multicast addresses for different layers +%% in a hierarchical or layered encoding scheme. They MUST NOT be +%% specified for a session-level "c=" field. +%% +%% The slash notation for multiple addresses described above MUST NOT +%% be used for IP unicast addresses. +%% + +-record(megaco_sdp_c, { + network_type = in, % <nettype> in | string() + address_type = ip4, % <addrtype> ip4 | ip6 | string() + connection_addr % <connection-address> string() | conn_addr() + }). + +%% Only if address type = ip4 +%% conn_addr() -> #megaco_sdp_c_conn_addr{} +-record(megaco_sdp_c_conn_addr, { + base, % <base multicast address> string() + ttl, % <ttl> integer() + num_of % <number of addresses> undefined | integer() + }). + + + +%% =================================================================== +%% +%% Bandwidth ("b=") +%% +%% b=<bwtype>:<bandwidth> +%% +%% 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. Two values are +%% defined in this specification, but other values MAY be registered +%% in the future (see Section 8 of RFC 4566 and [21], [25]): +%% +%% CT 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 "conference +%% total" bandwidth). The primary purpose of this is to give an +%% approximate idea as to whether two or more sessions can coexist +%% simultaneously. When using the CT modifier with RTP, if +%% several RTP sessions are part of the conference, the conference +%% total refers to total bandwidth of all RTP sessions. +%% +%% AS The bandwidth is interpreted to be application specific (it +%% 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. For +%% RTP-based applications, AS gives the RTP "session bandwidth" +%% as defined in Section 6.2 of [19]. +%% +%% 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. +%% +%% A prefix "X-" is defined for <bwtype> names. This is intended +%% for experimental purposes only. For example: +%% +%% b=X-YZ:128 +%% +%% Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers +%% SHOULD be registered with IANA in the standard namespace. SDP +%% parsers MUST ignore bandwidth fields with unknown modifiers. +%% Modifiers MUST be alphanumeric and, although no length limit is +%% given, it is recommended that they be short. +%% +%% The <bandwidth> is interpreted as kilobits per second by default. +%% The definition of a new <bwtype> modifier MAY specify that the +%% bandwidth is to be interpreted in some alternative unit (the "CT" +%% and "AS" modifiers defined in this memo use the default units). +%% + +%% bwtype() -> ct | as | string() +-record(megaco_sdp_b, { + bwtype, % bwtype() + bandwidth % integer() + }). + + + + +%% =================================================================== +%% +%% Times ("t=") +%% +%% t=<start time> <stop time> +%% +%% 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=" line +%% specifies an additional period of time for which the session will +%% be active. If the session is active at regular times, an "r=" +%% line (see below) 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. +%% +%% The first and second sub-fields give the start and stop times, +%% respectively, for the session. These values are the decimal +%% representation of Network Time Protocol (NTP) time values in +%% seconds since 1900 [13]. To convert these values to UNIX time, +%% subtract decimal 2208988800. +%% +%% NTP timestamps are elsewhere represented by 64-bit values, which +%% wrap sometime in the year 2036. Since SDP uses an arbitrary length +%% decimal representation, this should not cause an issue (SDP +%% timestamps MUST continue counting seconds since 1900, NTP will use +%% the value modulo the 64-bit limit). +%% +%% 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 strongly discourage the creation of +%% unbounded and permanent sessions as they give no information about +%% when the session is actually going to terminate, and so make +%% scheduling difficult. +%% +%% The general assumption may be made, when displaying unbounded +%% sessions that have not timed out to the user, that an unbounded +%% session will only be active until half an hour from the current +%% time or the session start time, whichever is the later. If +%% behaviour other than this is required, an end-time SHOULD be given +%% and modified as appropriate when new information becomes available +%% about when the session should really end. +%% +%% Permanent sessions may be shown to the user as never being active +%% unless there are associated repeat times that state precisely when +%% the session will be active. +%% + +-record(megaco_sdp_t, { + start, % integer() + stop % integer() + }). + + + +%% =================================================================== +%% +%% Repeat Times ("r=") +%% +%% r=<repeat interval> <active duration> <offsets from start-time> +%% +%% "r=" fields specify repeat times for a session. For example, if a +%% session is active at 10am on Monday and 11am on Tuesday for one +%% hour each week for three months, then the <start-time> in the +%% corresponding "t=" field would be the NTP representation of 10am +%% on the first Monday, the <repeat interval> would be 1 week, the +%% <active duration> would be 1 hour, and the offsets would be zero +%% and 25 hours. The corresponding "t=" field stop time would be +%% the NTP representation of the end of the last session three months +%% later. By default, all fields are in seconds, so the "r=" and +%% "t=" fields might be the following: +%% +%% t=3034423619 3042462419 +%% r=604800 3600 0 90000 +%% +%% To make description more compact, times may also be given in units +%% of days, hours, or minutes. The syntax for these is a number +%% immediately followed by a single case-sensitive character. +%% Fractional units are not allowed -- a smaller unit should be used +%% instead. The following unit specification characters are allowed: +%% +%% d - days (86400 seconds) +%% h - hours (3600 seconds) +%% m - minutes (60 seconds) +%% s - seconds (allowed for completeness) +%% +%% Thus, the above session announcement could also have been written: +%% +%% r=7d 1h 0 25h +%% +%% Monthly and yearly repeats cannot be directly specified with a +%% single SDP repeat time; instead, separate "t=" fields should be +%% used to explicitly list the session times. +%% + +-record(megaco_sdp_r, { + repeat_interval, % string() + active_duration, % string() + list_of_offsets % [ string() ] + } + ). + + + +%% =================================================================== +%% +%% Time Zones ("z=") +%% +%% z=<adjustment time> <offset> <adjustment time> <offset> .... +%% +%% To schedule a repeated session that spans a change from daylight +%% saving time to standard time or vice versa, it is necessary to +%% specify offsets from the base time. This is required because +%% different time zones change time at different times of day, +%% different countries change to or from daylight saving time on +%% different dates, and some countries do not have daylight saving +%% time at all. +%% +%% Thus, in order to schedule a session that is at the same time +%% winter and summer, it must be possible to specify unambiguously by +%% whose time zone a session is scheduled. To simplify this task for +%% receivers, we allow the sender to specify the NTP time that a time +%% zone adjustment happens and the offset from the time when the +%% session was first scheduled. The "z=" field allows the sender to +%% specify a list of these adjustment times and offsets from the base +%% time. +%% +%% An example might be the following: +%% +%% z=2882844526 -1h 2898848070 0 +%% +%% This specifies that at time 2882844526, the time base by which the +%% session's repeat times are calculated is shifted back by 1 hour, +%% and that at time 2898848070, the session's original time base is +%% restored. Adjustments are always relative to the specified start +%% time -- they are not cumulative. Adjustments apply to all "t=" +%% and "r=" lines in a session description. +%% +%% If a session is likely to last several years, it is expected that +%% the session announcement will be modified periodically rather than +%% transmit several years' worth of adjustments in one session +%% announcement. +%% + +%% adjustment() -> #megaco_sdp_z_adjustement{} +-record(megaco_sdp_z, { + list_of_adjustments % [ adjustment() ] + } + ). + +-record(megaco_sdp_z_adjustement, { + time, % string() + offset % string() + } + ). + + + + +%% =================================================================== +%% +%% Encryption Keys ("k=") +%% +%% k=<method> +%% k=<method>:<encryption key> +%% +%% 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. Work +%% is in progress to define new key exchange mechanisms for use with +%% SDP [27] [28], and it is expected that new applications will use +%% those mechanisms. A key field is permitted before the first media +%% entry (in which case it applies to all media in the session), or +%% for each media entry as required. The format of keys and their +%% usage are outside the scope of this document, and the key field +%% provides no way to indicate the encryption algorithm to be used, +%% key type, or other information about the key: this is assumed to +%% be provided by the higher-level protocol using SDP. If there is +%% a need to convey this information within SDP, the extensions +%% mentioned previously SHOULD be used. Many security protocols +%% require two keys: one for confidentiality, another for integrity. +%% This specification does not support transfer of two keys. +%% +%% The method indicates the mechanism to be used to obtain a usable +%% key by external means, or from the encoded encryption key given. +%% The following methods are defined: +%% +%% k=clear:<encryption key> +%% +%% The encryption key is included untransformed in this key +%% field. This method MUST NOT be used unless it can be +%% guaranteed that the SDP is conveyed over a secure channel. +%% The encryption key is interpreted as text according to the +%% charset attribute; use the "k=base64:" method to convey +%% characters that are otherwise prohibited in SDP. +%% +%% k=base64:<encoded encryption key> +%% +%% The encryption key is included in this key field but has +%% been base64 encoded [12] because it includes characters +%% that are prohibited in SDP. This method MUST NOT be used +%% unless it can be guaranteed that the SDP is conveyed over +%% a secure channel. +%% +%% k=uri:<URI to obtain key> +%% +%% A Uniform Resource Identifier is included in the key field. +%% The URI refers to the data containing the key, and may +%% require additional authentication before the key can be +%% returned. When a request is made to the given URI, the +%% reply should specify the encoding for the key. The URI is +%% often an Secure Socket Layer/Transport Layer Security +%% (SSL/TLS)-protected HTTP URI ("https:"), although this is +%% not required. +%% +%% k=prompt +%% +%% No key is included in this SDP description, but the session +%% or media stream referred to by this key field is encrypted. +%% The user should be prompted for the key when attempting to +%% join the session, and this user-supplied key should then be +%% used to decrypt the media streams. The use of +%% user-specified keys is NOT RECOMMENDED, since such keys tend +%% to have weak security properties. +%% +%% The key field MUST NOT be used unless it can be guaranteed that +%% the SDP is conveyed over a secure and trusted channel. An example +%% of such a channel might be SDP embedded inside an S/MIME message +%% or a TLS-protected HTTP session. It is important to ensure that +%% the secure channel is with the party that is authorised to join the +%% session, not an intermediary: if a caching proxy server is used, it +%% is important to ensure that the proxy is either trusted or unable +%% to access the SDP. +%% + +%% method() -> clear | base64 | uri | prompt +-record(megaco_sdp_k, { + method, % method() | string() + encryption_key % undefined | string() + } + ). + + +%% =================================================================== +%% +%% Attributes ("a=") +%% +%% a=<attribute> +%% a=<attribute>:<value> +%% +%% Attributes are the primary means for extending SDP. Attributes +%% may be defined to be used as "session-level" attributes, +%% "media-level" attributes, or both. +%% +%% A media description may have any number of attributes ("a=" +%% fields) that are media specific. These are referred to as +%% "media-level" attributes and add information about the media +%% stream. Attribute fields can also be added before the first +%% media field; these "session-level" attributes convey additional +%% information that applies to the conference as a whole rather than +%% to individual media. +%% +%% Attribute fields may be of two forms: +%% +%% o A property attribute is simply of the form "a=<flag>". These +%% are binary attributes, and the presence of the attribute +%% conveys that the attribute is a property of the session. An +%% example might be "a=recvonly". +%% +%% o A value attribute is of the form "a=<attribute>:<value>". For +%% example, a whiteboard could have the value attribute "a=orient: +%% landscape" +%% +%% Attribute interpretation depends on the media tool being invoked. +%% Thus receivers of session descriptions should be configurable in +%% their interpretation of session descriptions in general and of +%% attributes in particular. +%% +%% Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8. +%% +%% Attribute values are octet strings, and MAY use any octet value +%% except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, +%% attribute values are to be interpreted as in ISO-10646 character +%% set with UTF-8 encoding. Unlike other text fields, attribute +%% values are NOT normally affected by the "charset" attribute as +%% this would make comparisons against known values problematic. +%% However, when an attribute is defined, it can be defined to be +%% charset dependent, in which case its value should be interpreted +%% in the session charset rather than in ISO-10646. +%% +%% Attributes MUST be registered with IANA (see Section 8 of RFC +%% 4566). If an attribute is received that is not understood, it +%% MUST be ignored by the receiver. +%% +%% SDP Attributes +%% +%% The following attributes are defined. Since application writers +%% may add new attributes as they are required, this list is not +%% exhaustive. Registration procedures for new attributes are defined +%% in Section 8.2.4 of RFC 4566. +%% +%% a=cat:<category> +%% +%% This attribute gives the dot-separated hierarchical category +%% of the session. This is to enable a receiver to filter +%% unwanted sessions by category. There is no central registry +%% of categories. It is a session-level attribute, and it is +%% not dependent on charset. +%% +%% a=keywds:<keywords> +%% +%% Like the cat attribute, this is to assist identifying wanted +%% sessions at the receiver. This allows a receiver to select +%% interesting session based on keywords describing the purpose +%% of the session; there is no central registry of keywords. It +%% is a session-level attribute. It is a charset-dependent +%% attribute, meaning that its value should be interpreted in the +%% charset specified for the session description if one is +%% specified, or by default in ISO 10646/UTF-8. +%% +%% a=tool:<name and version of tool> +%% +%% This gives the name and version number of the tool used to +%% create the session description. It is a session-level +%% attribute, and it is not dependent on charset. +%% +%% a=ptime:<packet time> +%% +%% This gives the length of time in milliseconds represented by +%% the media in a packet. This is probably only meaningful for +%% audio data, but may be used with other media types if it +%% makes sense. It should not be necessary to know ptime to +%% decode RTP or vat audio, and it is intended as a +%% recommendation for the encoding/packetisation of audio. It +%% is a media-level attribute, and it is not dependent on charset. +%% +%% a=maxptime:<maximum packet time> +%% +%% This gives the maximum amount of media that can be encapsulated +%% in each packet, expressed as time in milliseconds. The time +%% SHALL be calculated as the sum of the time the media present in +%% the packet represents. For frame-based codecs, the time SHOULD +%% be an integer multiple of the frame size. This attribute is +%% probably only meaningful for audio data, but may be used with +%% other media types if it makes sense. It is a media-level +%% attribute, and it is not dependent on charset. Note that this +%% attribute was introduced after RFC 2327, and non-updated +%% implementations will ignore this attribute. +%% +%% a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding +%% parameters>] +%% +%% This attribute maps from an RTP payload type number (as used in +%% an "m=" line) to an encoding name denoting the payload format +%% to be used. It also provides information on the clock rate and +%% encoding parameters. It is a media-level attribute that is not +%% dependent on charset. +%% +%% Although an RTP profile may make static assignments of payload +%% type numbers to payload formats, it is more common for that +%% assignment to be done dynamically using "a=rtpmap:" attributes. +%% As an example of a static payload type, consider u-law PCM +%% coded single-channel audio sampled at 8 kHz. This is +%% completely defined in the RTP Audio/Video profile as payload +%% type 0, so there is no need for an "a=rtpmap:" attribute, and +%% the media for such a stream sent to UDP port 49232 can be +%% specified as: +%% +%% m=audio 49232 RTP/AVP 0 +%% +%% An example of a dynamic payload type is 16-bit linear encoded +%% stereo audio sampled at 16 kHz. If we wish to use the dynamic +%% RTP/AVP payload type 98 for this stream, additional +%% information is required to decode it: +%% +%% m=audio 49232 RTP/AVP 98 +%% a=rtpmap:98 L16/16000/2 +%% +%% Up to one rtpmap attribute can be defined for each media +%% format specified. Thus, we might have the following: +%% +%% m=audio 49230 RTP/AVP 96 97 98 +%% a=rtpmap:96 L8/8000 +%% a=rtpmap:97 L16/8000 +%% a=rtpmap:98 L16/11025/2 +%% +%% RTP profiles that specify the use of dynamic payload types +%% MUST define the set of valid encoding names and/or a means to +%% register encoding names if that profile is to be used with +%% SDP. The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes +%% for encoding names, under the top-level media type denoted in +%% the "m=" line. In the example above, the media types are +%% "audio/l8" and "audio/l16". +%% +%% For audio streams, <encoding parameters> indicates the number +%% of audio channels. This parameter is OPTIONAL and may be +%% omitted if the number of channels is one, provided that no +%% additional parameters are needed. +%% +%% For video streams, no encoding parameters are currently +%% specified. +%% +%% Additional encoding parameters MAY be defined in the future, +%% but codec-specific parameters SHOULD NOT be added. +%% Parameters added to an "a=rtpmap:" attribute SHOULD only be +%% those required for a session directory to make the choice of +%% appropriate media to participate in a session. Codec-specific +%% parameters should be added in other attributes (for example, +%% "a=fmtp:"). +%% +%% Note: RTP audio formats typically do not include information +%% about the number of samples per packet. If a non-default (as +%% defined in the RTP Audio/Video Profile) packetisation is +%% required, the "ptime" attribute is used as given above. +%% +%% a=recvonly +%% +%% This specifies that the tools should be started in +%% receive-only mode where applicable. It can be either a +%% session- or media-level attribute, and it is not dependent +%% on charset. Note that recvonly applies to the media only, +%% not to any associated control protocol (e.g., an RTP-based +%% system in recvonly mode SHOULD still send RTCP packets). +%% +%% a=sendrecv +%% +%% This specifies that the tools should be started in send and +%% receive mode. This is necessary for interactive conferences +%% with tools that default to receive-only mode. It can be +%% either a session or media-level attribute, and it is not +%% dependent on charset. +%% +%% If none of the attributes "sendonly", "recvonly", "inactive", +%% and "sendrecv" is present, "sendrecv" SHOULD be assumed as +%% the default for sessions that are not of the conference type +%% "broadcast" or "H332" (see below). +%% +%% a=sendonly +%% +%% This specifies that the tools should be started in send-only +%% mode. An example may be where a different unicast address is +%% to be used for a traffic destination than for a traffic +%% source. In such a case, two media descriptions may be used, +%% one sendonly and one recvonly. It can be either a session- +%% or media-level attribute, but would normally only be used as +%% a media attribute. It is not dependent on charset. Note +%% that sendonly applies only to the media, and any associated +%% control protocol (e.g., RTCP) SHOULD still be received and +%% processed as normal. +%% +%% a=inactive +%% +%% This specifies that the tools should be started in inactive +%% mode. This is necessary for interactive conferences where +%% users can put other users on hold. No media is sent over an +%% inactive media stream. Note that an RTP-based system SHOULD +%% still send RTCP, even if started inactive. It can be either +%% a session or media-level attribute, and it is not dependent +%% on charset. +%% +%% a=orient:<orientation> +%% +%% Normally this is only used for a whiteboard or presentation +%% tool. It specifies the orientation of a the workspace on +%% the screen. It is a media-level attribute. Permitted +%% values are "portrait", "landscape", and "seascape" +%% (upside-down landscape). It is not dependent on charset. +%% +%% a=type:<conference type> +%% +%% This specifies the type of the conference. Suggested +%% values are "broadcast", "meeting", "moderated", "test", and +%% "H332". "recvonly" should be the default for +%% "type:broadcast" sessions, "type:meeting" should imply +%% "sendrecv", and "type:moderated" should indicate the use of +%% a floor control tool and that the media tools are started +%% so as to mute new sites joining the conference. +%% +%% Specifying the attribute "type:H332" indicates that this +%% loosely coupled session is part of an H.332 session as +%% defined in the ITU H.332 specification [26]. Media tools +%% should be started "recvonly". +%% +%% Specifying the attribute "type:test" is suggested as a hint +%% that, unless explicitly requested otherwise, receivers can +%% safely avoid displaying this session description to users. +%% +%% The type attribute is a session-level attribute, and it is +%% not dependent on charset. +%% +%% a=charset:<character set> +%% +%% This specifies the character set to be used to display the +%% session name and information data. By default, the +%% ISO-10646 character set in UTF-8 encoding is used. If a +%% more compact representation is required, other character +%% sets may be used. For example, the ISO 8859-1 is specified +%% with the following SDP attribute: +%% +%% a=charset:ISO-8859-1 +%% +%% This is a session-level attribute and is not dependent on +%% charset. The charset specified MUST be one of those +%% registered with IANA, such as ISO-8859-1. The character +%% set identifier is a US-ASCII string and MUST be compared +%% against the IANA identifiers using a case-insensitive +%% comparison. If the identifier is not recognised or not +%% supported, all strings that are affected by it SHOULD be +%% regarded as octet strings. +%% +%% Note that a character set specified MUST still prohibit +%% the use of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). +%% Character sets requiring the use of these characters MUST +%% define a quoting mechanism that prevents these bytes from +%% appearing within text fields. +%% +%% a=sdplang:<language tag> +%% +%% This can be a session-level attribute or a media-level +%% attribute. As a session-level attribute, it specifies the +%% language for the session description. As a media-level +%% attribute, it specifies the language for any media-level +%% SDP information field associated with that media. Multiple +%% sdplang attributes can be provided either at session or +%% media level if multiple languages in the session description +%% or media use multiple languages, in which case the order of +%% the attributes indicates the order of importance of the +%% various languages in the session or media from most important +%% to least important. +%% +%% In general, sending session descriptions consisting of +%% multiple languages is discouraged. Instead, multiple +%% descriptions SHOULD be sent describing the session, one in +%% each language. However, this is not possible with all +%% transport mechanisms, and so multiple sdplang attributes +%% are allowed although NOT RECOMMENDED. +%% +%% The "sdplang" attribute value must be a single RFC 3066 +%% language tag in US-ASCII [9]. It is not dependent on the +%% charset attribute. An "sdplang" attribute SHOULD be +%% specified when a session is of sufficient scope to cross +%% geographic boundaries where the language of recipients +%% cannot be assumed, or where the session is in a different +%% language from the locally assumed norm. +%% +%% a=lang:<language tag> +%% +%% This can be a session-level attribute or a media-level +%% attribute. As a session-level attribute, it specifies the +%% default language for the session being described. As a +%% media-level attribute, it specifies the language for that +%% media, overriding any session-level language specified. +%% Multiple lang attributes can be provided either at session +%% or media level if the session description or media use +%% multiple languages, in which case the order of the +%% attributes indicates the order of importance of the various +%% languages in the session or media from most important to +%% least important. +%% +%% The "lang" attribute value must be a single RFC 3066 +%% language tag in US-ASCII [9]. It is not dependent on the +%% charset attribute. A "lang" attribute SHOULD be specified +%% when a session is of sufficient scope to cross geographic +%% boundaries where the language of recipients cannot be +%% assumed, or where the session is in a different language +%% from the locally assumed norm. +%% +%% a=framerate:<frame rate> +%% +%% This gives the maximum video frame rate in frames/sec. +%% It is intended as a recommendation for the encoding of +%% video data. Decimal representations of fractional values +%% using the notation "<integer>.<fraction>" are allowed. It +%% is a media-level attribute, defined only for video media, +%% and it is not dependent on charset. +%% +%% a=quality:<quality> +%% +%% This gives a suggestion for the quality of the encoding +%% as an integer value. The intention of the quality +%% attribute for video is to specify a non-default trade-off +%% between frame-rate and still-image quality. For video, +%% the value is in the range 0 to 10, with the following +%% suggested meaning: +%% +%% 10 - the best still-image quality the compression +%% scheme can give. +%% 5 - the default behaviour given no quality suggestion. +%% 0 - the worst still-image quality the codec designer +%% thinks is still usable. +%% +%% It is a media-level attribute, and it is not dependent on +%% charset. +%% +%% a=fmtp:<format> <format specific parameters> +%% +%% This attribute allows parameters that are specific to a +%% particular format to be conveyed in a way that SDP does +%% not have to understand them. The format must be one of +%% the formats specified for the media. Format-specific +%% parameters may be any set of parameters required to be +%% conveyed by SDP and given unchanged to the media tool that +%% will use this format. At most one instance of this +%% attribute is allowed for each format. +%% +%% It is a media-level attribute, and it is not dependent on +%% charset. +%% + + +%% a=<attribute> +%% a=<attribute>:<value> +-record(megaco_sdp_a, { + attribute, % string() + value % undefined | string() + } + ). + +%% a=cat:<category> +-record(megaco_sdp_a_cat, { + category % string() + } + ). + +%% a=keywds:<keywords> +-record(megaco_sdp_a_keywds, { + keywords % string() + } + ). + +%% a=tool:<name and version of tool> +-record(megaco_sdp_a_tool, { + name_and_version % string() + } + ). + +%% a=ptime:<packet time> +-record(megaco_sdp_a_ptime, { + packet_time % integer() + } + ). + +%% a=maxptime:<maximum packet time> +-record(megaco_sdp_a_maxptime, { + maximum_packet_time % integer() + } + ). + +%% a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>] +-record(megaco_sdp_a_rtpmap, { + payload_type, % <payload type> integer() + encoding_name, % <encoding name> string() + clock_rate, % <clock rate> integer() + encoding_parms = [] % <encoding parameters> [ string() ] + } + ). + +%% a=orient:<orientation> +%% orientation() -> portrait | landscape | seascape +-record(megaco_sdp_a_orient, { + orientation % orientation() + } + ). + + +%% a=type:<conference type> +-record(megaco_sdp_a_type, { + conf_type % string() + } + ). + + +%% a=charset:<character set> +-record(megaco_sdp_a_charset, { + char_set % string() + } + ). + + +%% a=sdplang:<language tag> +-record(megaco_sdp_a_sdplang, { + tag % string() + } + ). + + +%% a=lang:<language tag> +-record(megaco_sdp_a_lang, { + tag % string() + } + ). + + +%% a=framerate:<frame rate> +-record(megaco_sdp_a_framerate, { + frame_rate % string() + } + ). + + +%% a=quality:<quality> +-record(megaco_sdp_a_quality, { + quality % integer() + } + ). + + +%% a=fmtp:<format> <format specific parameters> +-record(megaco_sdp_a_fmtp, { + format, % string() + param % string() + } + ). + + + + +%% =================================================================== +%% +%% Media Announcements ("m=") +%% +%% m=<media> <port> <proto> <fmt> ... +%% +%% A session description may contain a number of media descriptions. +%% 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. A media field has several sub-fields: +%% +%% <media> is the media type. Currently defined media are "audio", +%% "video", "text", "application", and "message", although this +%% list may be extended in the future (see Section 8 of RFC 4566). +%% +%% <port> is the 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 RTP Control Protocol (RTCP) port [19]) MAY be derived +%% algorithmically from the base media port or MAY be specified in +%% a separate attribute (for example, "a=rtcp:" as defined in +%% [22]). +%% +%% If non-contiguous ports are used or if they don't follow the +%% parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:" +%% attribute MUST be used. Applications that are requested to send +%% media to a <port> that is odd and where the "a=rtcp:" is present +%% MUST NOT subtract 1 from the RTP port: that is, they MUST send +%% the RTP to the port indicated in <port> and send the RTCP to the +%% port indicated in the "a=rtcp" attribute. +%% +%% For applications where hierarchically encoded streams are being +%% sent to a unicast address, it may be necessary to specify +%% multiple transport ports. This is done using a similar notation +%% to that used for IP multicast addresses in the "c=" field: +%% +%% m=<media> <port>/<number of ports> <proto> <fmt> ... +%% +%% In such a case, the ports used depend on the transport protocol. +%% For RTP, the default is that only the even-numbered ports are +%% used for data with the corresponding one-higher odd ports used +%% for the RTCP belonging to the RTP session, and the +%% <number of ports> denoting the number of RTP sessions. For +%% example: +%% +%% m=video 49170/2 RTP/AVP 31 +%% +%% would specify that ports 49170 and 49171 form one RTP/RTCP pair +%% and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is +%% the transport protocol and 31 is the format (see below). If +%% non-contiguous ports are required, they must be signalled using +%% a separate attribute (for example, "a=rtcp:" as defined in +%% [22]). +%% +%% If multiple addresses are specified in the "c=" field and +%% multiple ports are specified in the "m=" field, a one-to-one +%% mapping from port to the corresponding address is implied. For +%% example: +%% +%% c=IN IP4 224.2.1.1/127/2 +%% m=video 49170/2 RTP/AVP 31 +%% +%% would imply that address 224.2.1.1 is used with ports 49170 +%% and 49171, and address 224.2.1.2 is used with ports 49172 and +%% 49173. +%% +%% The semantics of multiple "m=" lines using the same transport +%% address are undefined. This implies that, unlike limited past +%% practice, there is no implicit grouping defined by such means +%% and an explicit grouping framework (for example, [18]) should +%% instead be used to express the intended semantics. +%% +%% <proto> is the transport protocol. The meaning of the transport +%% protocol is dependent on the address type field in the +%% relevant "c=" field. Thus a "c=" field of IP4 indicates that +%% the transport protocol runs over IP4. The following transport +%% protocols are defined, but may be extended through +%% registration of new protocols with IANA (see Section 8 of RFC +%% 4566): +%% +%% * udp: denotes an unspecified protocol running over UDP. +%% +%% * RTP/AVP: denotes RTP [19] used under the RTP Profile for +%% Audio and Video Conferences with Minimal Control [20] +%% running over UDP. +%% +%% * RTP/SAVP: denotes the Secure Real-time Transport Protocol +%% [23] running over UDP. +%% +%% The main reason to specify the transport protocol in addition +%% to the media format is that the same standard media formats +%% may be carried over different transport protocols even when +%% the network protocol is the same -- a historical example is +%% vat Pulse Code Modulation (PCM) audio and RTP PCM audio; +%% another might be TCP/RTP PCM audio. In addition, relays and +%% monitoring tools that are transport-protocol-specific but +%% format-independent are possible. +%% +%% <fmt> is a media format description. The fourth and any +%% subsequent sub-fields describe the format of the media. The +%% interpretation of the media format depends on the value of +%% the <proto> sub-field. +%% +%% If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt> +%% sub-fields contain RTP payload type numbers. When a list of +%% payload type numbers is given, this implies that all of these +%% payload formats MAY be used in the session, but the first of +%% these formats SHOULD be used as the default format for the +%% session. For dynamic payload type assignments the "a=rtpmap:" +%% attribute (see Section 6 of RFC 4566) SHOULD be used to map +%% from an RTP payload type number to a media encoding name that +%% identifies the payload format. The "a=fmtp:" attribute MAY +%% be used to specify format parameters (see Section 6 of RFC +%% 4566). +%% +%% If the <proto> sub-field is "udp" the <fmt> sub-fields MUST +%% reference a media type describing the format under the +%% "audio", "video", "text", "application", or "message" +%% top-level media types. The media type registration SHOULD +%% define the packet format for use with UDP transport. +%% +%% For media using other transport protocols, the <fmt> field is +%% protocol specific. Rules for interpretation of the <fmt> sub- +%% field MUST be defined when registering new protocols (see +%% Section 8.2.2 of RFC 4566). +%% + +%% ma_media() -> audio | video | application | data | control +-record(megaco_sdp_m, { + media, % ma_media() | string() + port, % integer() + num_ports, % undefined | integer() + transport, % string() + fmt_list = [] % [ string() ] + }). + + + + +%% =================================================================== +%% +%% References +%% +%% Normative References +%% +%% [1] Mockapetris, P., "Domain names - concepts and facilities", STD +%% 13, RFC 1034, November 1987. +%% +%% [2] Mockapetris, P., "Domain names - implementation and +%% specification", STD 13, RFC 1035, November 1987. +%% +%% [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement +%% Levels", BCP 14, RFC 2119, March 1997. +%% +%% [4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax +%% Specifications: ABNF", RFC 4234, October 2005. +%% +%% [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD +%% 63, RFC 3629, November 2003. +%% +%% [6] Handley, M. and V. Jacobson, "SDP: Session Description +%% Protocol", RFC 2327, April 1998. +%% +%% [7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform +%% Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, +%% January 2005. +%% +%% [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA +%% Considerations Section in RFCs", BCP 26, RFC 2434, October +%% 1998. +%% +%% [9] Alvestrand, H., "Tags for the Identification of Languages", BCP +%% 47, RFC 3066, January 2001. +%% +%% [10] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6 in +%% Session Description Protocol (SDP)", RFC 3266, June 2002. +%% +%% [11] Faltstrom, P., Hoffman, P., and A. Costello, +%% "Internationalizing Domain Names in Applications (IDNA)", RFC +%% 3490, March 2003. +%% +%% [12] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", +%% RFC 3548, July 2003. +%% +%% +%% Informative References +%% +%% [13] Mills, D., "Network Time Protocol (Version 3) Specification, +%% Implementation", RFC 1305, March 1992. +%% +%% [14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement +%% Protocol", RFC 2974, October 2000. +%% +%% [15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., +%% Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: +%% Session Initiation Protocol", RFC 3261, June 2002. +%% +%% [16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming +%% Protocol (RTSP)", RFC 2326, April 1998. +%% +%% [17] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with +%% Session Description Protocol (SDP)", RFC 3264, June 2002. +%% +%% [18] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, +%% "Grouping of Media Lines in the Session Description Protocol +%% (SDP)", RFC 3388, December 2002. +%% +%% [19] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, +%% "RTP: A Transport Protocol for Real-Time Applications", STD 64, +%% RFC 3550, July 2003. +%% +%% [20] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video +%% Conferences with Minimal Control", STD 65, RFC 3551, July 2003. +%% +%% [21] Casner, S., "Session Description Protocol (SDP) Bandwidth +%% Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, +%% July 2003. +%% +%% [22] Huitema, C., "Real Time Control Protocol (RTCP) attribute in +%% Session Description Protocol (SDP)", RFC 3605, October 2003. +%% +%% [23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. +%% Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC +%% 3711, March 2004. +%% +%% [24] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating +%% User Agent Capabilities in the Session Initiation Protocol +%% (SIP)", RFC 3840, August 2004. +%% +%% [25] Westerlund, M., "A Transport Independent Bandwidth Modifier for +%% the Session Description Protocol (SDP)", RFC 3890, September +%% 2004. +%% +%% [26] International Telecommunication Union, "H.323 extended for +%% loosely coupled conferences", ITU Recommendation H.332, +%% September 1998. +%% +%% [27] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. +%% Norrman, "Key Management Extensions for Session Description +%% Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC +%% 4567, July 2006. +%% +%% [28] Andreasen, F., Baugher, M., and D. Wing, "Session Description +%% Protocol (SDP) Security Descriptions for Media Streams", RFC +%% 4568, July 2006. +%% +%% [29] Resnick, P., "Internet Message Format", RFC 2822, April 2001. +%% +%% [30] Hinden, R. and S. Deering, "IP Version 6 Addressing +%% Architecture", RFC 2373, July 1998. +%% +%% [31] Freed, N. and J. Klensin, "Media Type Specifications and +%% Registration Procedures", BCP 13, RFC 4288, December 2005. +%% + + +-endif. |