megaco_sdp.hrl

OTP是开放电信平台的简称

%%   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 multiple languages
%%   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 1766 language tag
%%   in US-ASCII. 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 attribute, is
%%   only defined for video media, and 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 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 attribute, and 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 doesn't 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.
%%
%%   It is a media attribute, and is not dependent on charset.
%% 

-record(megaco_sdp_a, {
	  attribute,                            % string()
	  value                                 % undefined | string()
	 }
       ).

-record(megaco_sdp_a_rtpmap, {
          payload_type,                         % integer()
          encoding_name,                        % string()
          clock_rate,                           % integer()
          encoding_parms = []                   % [ string() ]
         }
       ).
                
-record(megaco_sdp_a_ptime, {
          packet_time                           % integer()
         }
       ).

-record(megaco_sdp_a_quality, {
          quality                               % integer()
         }
       ).

-record(megaco_sdp_a_fmtp, {
          format,                               % string()
          param                                 % string()
         }
       ).




%% ===================================================================
%% 
%% Media Announcements
%% 
%% m=<media> <port> <transport> <fmt list>
%%
%% 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 also has several sub-fields:
%%
%% o The first sub-field is the media type.  Currently defined media are
%%   "audio", "video", "application", "data" and "control", though this
%%   list may be extended as new communication modalities emerge (e.g.,
%%   telepresense).  The difference between "application" and "data" is
%%   that the former is a media flow such as whiteboard information, and
%%   the latter is bulk-data transfer such as multicasting of program
%%   executables which will not typically be displayed to the user.
%%   "control" is used to specify an additional conference control
%%   channel for the session.
%%
%% o The second sub-field is the transport port to which the media
%%   stream will be 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 third sub-field.  Other
%%   ports used by the media application (such as the RTCP port, see
%%   [2]) should be derived algorithmically from the base media port.
%%
%%   Note: For transports based on UDP, the value should be in the range
%%   1024 to 65535 inclusive.  For RTP compliance it should be an even
%%   number.
%%
%%   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> <transport> <fmt list>
%%
%%   In such a case, the ports used depend on the transport protocol.
%%   For RTP, only the even ports are used for data and the
%%   corresponding one-higher odd port is used for RTCP.  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).
%%
%%   It is illegal for both multiple addresses to be specified in the
%%   "c=" field and for multiple ports to be specified in the "m=" field
%%   in the same session description.
%% 
%% o The third sub-field is the transport protocol.  The transport
%%   protocol values are dependent on the address-type field in the "c="
%%   fields.  Thus a "c=" field of IP4 defines that the transport
%%   protocol runs over IP4.  For IP4, it is normally expected that most
%%   media traffic will be carried as RTP over UDP.  The following
%%   transport protocols are preliminarily defined, but may be extended
%%   through registration of new protocols with IANA:
%%
%%   - RTP/AVP - the IETF's Realtime Transport Protocol using the
%%     Audio/Video profile carried over UDP.
%%
%%   - udp - User Datagram Protocol
%%
%%   If an application uses a single combined proprietary media format
%%   and transport protocol over UDP, then simply specifying the
%%   transport protocol as udp and using the format field to distinguish
%%   the combined protocol is recommended.  If a transport protocol is
%%   used over UDP to carry several distinct media types that need to be
%%   distinguished by a session directory, then specifying the transport
%%   protocol and media format separately is necessary. RTP is an
%%   example of a transport-protocol that carries multiple payload
%%   formats that must be distinguished by the session directory for it
%%   to know how to start appropriate tools, relays, mixers or
%%   recorders.
%%
%%   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 PCM audio and
%%   RTP PCM audio.  In addition, relays and monitoring tools that are
%%   transport-protocol-specific but format-independent are possible.
%%
%%   For RTP media streams operating under the RTP Audio/Video Profile
%%   [3], the protocol field is "RTP/AVP".  Should other RTP profiles be
%%   defined in the future, their profiles will be specified in the same
%%   way.  For example, the protocol field "RTP/XYZ" would specify RTP
%%   operating under a profile whose short name is "XYZ".
%% 
%% o The fourth and subsequent sub-fields are media formats.  For audio
%%   and video, these will normally be a media payload type as defined
%%   in the RTP Audio/Video Profile.
%%
%%   When a list of payload formats is given, this implies that all of
%%   these formats may be used in the session, but the first of these
%%   formats is the default format for the session.
%%
%%   For media whose transport protocol is not RTP or UDP the format
%%   field is protocol specific.  Such formats should be defined in an
%%   additional specification document.
%%
%%   For media whose transport protocol is RTP, SDP can be used to
%%   provide a dynamic binding of media encoding to RTP payload type.
%%   The encoding names in the RTP AV Profile do not specify unique
%%   audio encodings (in terms of clock rate and number of audio
%%   channels), and so they are not used directly in SDP format fields.
%%   Instead, the payload type number should be used to specify the
%%   format for static payload types and the payload type number along
%%   with additional encoding information should be used for dynamically
%%   allocated payload types.
%%
%%   An example of a static payload type is u-law PCM coded single
%%   channel audio sampled at 8KHz.  This is completely defined in the
%%   RTP Audio/Video profile as payload type 0, so the media field for
%%   such a stream sent to UDP port 49232 is:
%%
%%                         m=video 49232 RTP/AVP 0
%%
%%   An example of a dynamic payload type is 16 bit linear encoded
%%   stereo audio sampled at 16KHz.  If we wish to use dynamic RTP/AVP
%%   payload type 98 for such a stream, additional information is
%%   required to decode it:
%%
%%                        m=video 49232 RTP/AVP 98
%%                        a=rtpmap:98 L16/16000/2
%%
%%   The general form of an rtpmap attribute is:
%%
%%   a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
%%   parameters>]
%%
%%   For audio streams, <encoding parameters> may specify the number of
%%   audio channels.  This parameter may be omitted if the number of
%%   channels is one provided no additional parameters are needed.  For
%%   video streams, no encoding parameters are currently specified.
%%
%%   Additional parameters may be defined in the future, but
%%   codecspecific parameters should not be added.  Parameters added to
%%   an rtpmap attribute should only be those required for a session
%%   directory to make the choice of appropriate media too to
%%   participate in a session.  Codec-specific parameters should be
%%   added in other attributes.
%%
%%   Up to one rtpmap attribute can be defined for each media format
%%   specified. Thus we might have:
%%
%%                     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.
%%
%%   Experimental encoding formats can also be specified using rtpmap.
%%   RTP formats that are not registered as standard format names must
%%   be preceded by "X-".  Thus a new experimental redundant audio
%%   stream called GSMLPC using dynamic payload type 99 could be
%%   specified as:
%%
%%                        m=video 49232 RTP/AVP 99
%%                        a=rtpmap:99 X-GSMLPC/8000
%%
%%   Such an experimental encoding requires that any site wishing to
%%   receive the media stream has relevant configured state in its
%%   session directory to know which tools are appropriate.
%%
%%   Note that 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 below.
%%
%% o Formats for non-RTP media should be registered as MIME content
%%   types as described in Appendix B.  For example, the LBL whiteboard
%%   application might be registered as MIME content-type application/wb
%%   with encoding considerations specifying that it operates over UDP,
%%   with no appropriate file format.  In SDP this would then be
%%   expressed using a combination of the "media" field and the "fmt"
%%   field, as follows:
%%
%%                       m=application 32416 udp wb
%% 

%% 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() ]
         }).

          
-endif.