megaco_sdp.hrl

OTP是开放电信平台的简称

%%   There must be a space or a hyphen ("-") between the country code
%%   and the rest of the phone number.  Spaces and hyphens may be used
%%   to split up a phone field to aid readability if desired. For
%%   example:
%%
%%                 p=[phone] or p=[phone]
%%
%% o Both email addresses and phone numbers can have an optional free
%%   text string associated with them, normally giving the name of the
%%   person who may be contacted.  This should be enclosed in
%%   parenthesis if it is present.  For example:
%%
%%                      e=[e-mail] (Mark Handley)
%%
%%   The alternative RFC822 name quoting convention is also allowed for
%%   both email addresses and phone numbers.  For example,
%%
%%                      e=Mark Handley <[e-mail]>
%%
%%   The free text string should be in the ISO-10646 character set with
%%   UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings
%%   if the appropriate charset session-level attribute is set.
%% 

-record(megaco_sdp_e, {
	  email                                 % string()
	 }
       ).

-record(megaco_sdp_p, {
	  phone_number                          % string()
	 }
       ).




%% ===================================================================
%% 
%% Connection Data
%% 
%% c=<network type> <address type> <connection address>
%%
%% The "c=" field contains connection data.
%%
%% A session announcement must contain one "c=" field in each media
%% description (see below) or a "c=" field at the session-level.  It may
%% contain a session-level "c=" field and one additional "c=" field per
%% media description, in which case the per-media values override the
%% session-level settings for the relevant media.
%%
%% The first sub-field is the network type, which is a text string
%% giving the type of network.  Initially "IN" is defined to have the
%% meaning "Internet".
%%
%% The second sub-field is the address type.  This allows SDP to be used
%% for sessions that are not IP based.  Currently only IP4 is defined.
%%
%% The third sub-field is the connection address.  Optional extra
%% subfields may be added after the connection address depending on the
%% value of the <address type> field.
%%
%% For IP4 addresses, the connection address is defined as follows:
%%
%% o Typically the connection address will be a class-D IP multicast
%%   group address.  If the session is not multicast, then the
%%   connection address contains the fully-qualified domain name or the
%%   unicast IP address of the expected data source or data relay or
%%   data sink as determined by additional attribute fields. It is not
%%   expected that fully-qualified domain names or unicast addresses
%%   will be given in a session description that is communicated by a
%%   multicast announcement, though this is not prohibited.  If a
%%   unicast data stream is to pass through a network address
%%   translator, the use of a fully-qualified domain name rather than an
%%   unicast IP address is RECOMMENDED.  In other cases, the use of an
%%   IP address to specify a particular interface on a multi-homed host
%%   might be required.  Thus this specification leaves the decision as
%%   to which to use up to the individual application, but all
%%   applications MUST be able to cope with receiving both formats.
%% 
%% o Conferences using an IP multicast connection address must also have
%%   a time to live (TTL) value present in addition to the multicast
%%   address.  The TTL and the address together define the scope with
%%   which multicast packets sent in this conference will be sent. TTL
%%   values must be in the range 0-255.
%%
%%   The TTL for the session is appended to the address using a slash as
%%   a separator.  An example is:
%%
%%                         c=IN IP4 224.2.1.1/127
%%
%%   Hierarchical or layered encoding schemes are data streams where the
%%   encoding from a single media source is split into a number of
%%   layers.  The receiver can choose the desired quality (and hence
%%   bandwidth) by only subscribing to a subset of these layers.  Such
%%   layered encodings are normally transmitted in multiple multicast
%%   groups to allow multicast pruning.  This technique keeps unwanted
%%   traffic from sites only requiring certain levels of the hierarchy.
%%   For applications requiring multiple multicast groups, we allow the
%%   following notation to be used for the connection address:
%%
%%          <base multicast address>/<ttl>/<number of addresses>
%%
%%   If the number of addresses is not given it is assumed to be one.
%%   Multicast addresses so assigned are contiguously allocated above
%%   the base address, so that, for example:
%%
%%                        c=IN IP4 224.2.1.1/127/3
%%
%%   would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are
%%   to be used at a ttl of 127.  This is semantically identical to
%%   including multiple "c=" lines in a media description:
%%
%%                         c=IN IP4 224.2.1.1/127
%%                         c=IN IP4 224.2.1.2/127
%%                         c=IN IP4 224.2.1.3/127
%%
%%   Multiple addresses or "c=" lines can only be specified on a per-
%%   media basis, and not for a session-level "c=" field.
%%
%%   It is illegal for the slash notation described above to be used for
%%   IP unicast addresses.
%% 

-record(megaco_sdp_c, {
          network_type = in,                    % in | string()
          address_type = ip4,                   % ip4 | ip6 | string()
          connection_addr                       % string() | #conn_addr{}
         }).

%% Only if address type = ip4
-record(megaco_sdp_c_conn_addr, {
	  base,                                 % string()
	  ttl,                                  % integer()
	  num_of                                % undefined | integer()
	 }).



%% ===================================================================
%% 
%% Bandwidth
%%
%% b=<modifier>:<bandwidth-value>
%%
%% o This specifies the proposed bandwidth to be used by the session or
%%   media, and is optional.
%%
%% o <bandwidth-value> is in kilobits per second
%%
%% o <modifier> is a single alphanumeric word giving the meaning of the
%%   bandwidth figure.
%%
%% o Two modifiers are initially defined:
%%
%% CT Conference Total: An implicit maximum bandwidth is associated with
%%   each TTL on the Mbone or within a particular multicast
%%   administrative scope region (the Mbone bandwidth vs. TTL limits are
%%   given in the MBone FAQ). If the bandwidth of a session or media in
%%   a session is different from the bandwidth implicit from the scope,
%%   a `b=CT:...' line should be supplied for the session giving the
%%   proposed upper limit to the bandwidth used. The primary purpose of
%%   this is to give an approximate idea as to whether two or more
%%   conferences can co-exist simultaneously.
%%
%% AS Application-Specific Maximum: The bandwidth is interpreted to be
%%   application-specific, i.e., will be the application's concept of
%%   maximum bandwidth.  Normally this will coincide with what is set on
%%   the application's "maximum bandwidth" control if applicable.
%%
%%   Note that CT gives a total bandwidth figure for all the media at
%%   all sites.  AS gives a bandwidth figure for a single media at a
%%   single site, although there may be many sites sending
%%   simultaneously.
%%
%% o Extension Mechanism: Tool writers can define experimental bandwidth
%%   modifiers by prefixing their modifier with "X-". For example:
%%
%%                               b=X-YZ:128
%%
%%   SDP parsers should ignore bandwidth fields with unknown modifiers.
%%   Modifiers should be alpha-numeric and, although no length limit is
%%   given, they are recommended to be short.
%% 

-record(megaco_sdp_b, {
          modifier,                             % string()
          bandwidth                             % integer()
         }).




%% ===================================================================
%% 
%% Times, Repeat Times and Time Zones
%%
%% t=<start time>  <stop time>
%% r=<repeat interval> <active duration> <list of offsets from start-time>
%% z=<adjustment time> <offset> <adjustment time> <offset> ....
%%
%% o "t=" fields specify the start and stop times for a conference
%%   session.  Multiple "t=" fields may be used if a session is active
%%   at multiple irregularly spaced times; each additional "t=" field
%%   specifies an additional period of time for which the session will
%%   be active.  If the session is active at regular times, an "r="
%%   field (see below) should be used in addition to and following a
%%   "t=" field - in which case the "t=" field specifies the start and
%%   stop times of the repeat sequence.
%%
%% o The first and second sub-fields give the start and stop times for
%%   the conference respectively.  These values are the decimal
%%   representation of Network Time Protocol (NTP) time values in
%%   seconds [1].  To convert these values to UNIX time, subtract
%%   decimal 2208988800.
%%
%% o If the stop-time is set to zero, then the session is not bounded,
%%   though it will not become active until after the start-time.  If
%%   the start-time is also zero, the session is regarded as
%%   permanent.
%%
%%   User interfaces should 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 which state precisely
%%   when the session will be active.  In general, permanent sessions
%%   should not be created for any session expected to have a duration
%%   of less than 2 months, and should be discouraged for sessions
%%   expected to have a duration of less than 6 months.
%%
%% o "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:
%%
%%                         t=3034423619 3042462419
%%                          r=604800 3600 0 90000
%%
%%   To make announcements 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 - minutes (3600 seconds)
%%                       m - minutes (60 seconds)
%%       s - seconds (allowed for completeness but not recommended)
%%
%%   Thus, the above announcement could also have been written:
%%
%%                             r=7d 1h 0 25h
%%
%%   Monthly and yearly repeats cannot currently be directly specified
%%   with a single SDP repeat time - instead separate "t" fields
%%   should be used to explicitly list the session times.
%% 
%%   To schedule a repeated session which spans a change from
%%   daylight- saving time to standard time or vice-versa, it is
%%   necessary to specify offsets from the base repeat times. This is
%%   required because different time zones change time at different
%%   times of day, different countries change to or from daylight 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