aboutsummaryrefslogtreecommitdiffstats
path: root/lib/megaco/include/megaco_sdp.hrl
diff options
context:
space:
mode:
Diffstat (limited to 'lib/megaco/include/megaco_sdp.hrl')
-rw-r--r--lib/megaco/include/megaco_sdp.hrl1471
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.