The R13B03 release.OTP_R13B03

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.