👤
Home Man
Search
Today's Posts
Register

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:
Select Section of Man Page:
Select Man Page Repository:

Linux 2.6 - man page for megaco (linux section 3erl)

megaco(3erl)			     Erlang Module Definition			     megaco(3erl)

NAME
       megaco - Main API of the Megaco application

DESCRIPTION
       Interface module for the Megaco application

DATA TYPES
       megaco_mid() = ip4Address() | ip6Address() |
		      domainName() | deviceName() |
		      mtpAddress()
       ip4Address() = #'IP4Address'{}
       ip6Address() = #'IP6Address'{}
       domainName() = #'DomainName'{}
       deviceName() = pathName()
       pathName()   = ia5String(1..64)
       mtpAddress() = octetString(2..4)

       action_request() = #'ActionRequest'{}
       action_reply() = #'ActionReply'{}
       error_desc() = #'ErrorDescriptor'{}
       transaction_reply() = #'TransactionReply'{}
       segment_no() = integer()

       resend_indication() = flag | boolean()

       property_parm() = #'PropertyParm'{}
       property_group() = [property_parm()]
       property_groups() = [property_group()]

       sdp() = sdp_c() | sdp_o() | sdp_s() | sdp_i() | sdp_u() |
	       sdp_e() | sdp_p() | sdp_b() | sdp_z() | sdp_k() |
	       sdp_a() | sdp_a_rtpmap() | sdp_a_ptime() |
	       sdp_t() | sdp_r() | sdp_m()
       sdp_v() = #megaco_sdp_v{} (Protocol version)
       sdp_o() = #megaco_sdp_o{} (Owner/creator and session identifier)
       sdp_s() = #megaco_sdp_s{} (Session name)
       sdp_i() = #megaco_sdp_i{} (Session information)
       sdp_u() = #megaco_sdp_u{} (URI of description)
       sdp_e() = #megaco_sdp_e{} (Email address)
       sdp_p() = #megaco_sdp_p{} (Phone number)
       sdp_c() = #megaco_sdp_c{} (Connection information)
       sdp_b() = #megaco_sdp_b{} (Bandwidth information)
       sdp_k() = #megaco_sdp_k{} (Encryption key)
       sdp_a() = #megaco_sdp_a{} (Session attribute)
       sdp_a_rtpmap() = #megaco_sdp_a_rtpmap{}
       sdp_a_ptime() = #megaco_sdp_a_ptime{}
       sdp_a_quality() = #megaco_sdp_a_quality{}
       sdp_a_fmtp() = #megaco_sdp_a_fmtp{}
       sdp_z() = #megaco_sdp_z{} (Time zone adjustment)
       sdp_t() = #megaco_sdp_t{} (Time the session is active)
       sdp_r() = #megaco_sdp_r{} (Repeat times)
       sdp_m() = #megaco_sdp_m{} (Media name and transport address)
       sdp_property_parm() = sdp() | property_parm()
       sdp_property_group() = [sdp_property_parm()]
       sdp_property_groups() = [sdp_property_group()]

       megaco_timer() = infinity | integer() >= 0 | megaco_incr_timer()
       megaco_incr_timer() = #megaco_incr_timer{}

       The record megaco_incr_timer contains the following fields:

	 wait_for = integer() >= 0 :
	   The actual timer time.

	 factor = integer() >= 0 :
	   The factor when calculating the new timer time ( wait_for ).

	 incr = integer() :
	   The	increment  value when calculating the new timer time ( wait_for ). Note that this
	   value can be negative and that a timer restart can therefor lead to a  wait_for  value
	   of  zero!  It is up to the user to be aware of the consequences of a wait_for value of
	   zero.

	 max_retries = infinity | infinity_restartable | integer() >= 0 :
	   The maximum number of repetitions of the timer.

	   There is a special case for this field. When the  max_retries  has  the  value  infin-
	   ity_restartable  ,  it  means  that	the timer is restartable as long as some external
	   event occurs (e.g. receipt of a pending message for	instance).  But  the  timer  will
	   never  be  restarted  "by  itself",	i.e. when the timer expires (whatever the timeout
	   time), so does the timer. Whenever the timer is restarted, the timeout  time  will  be
	   calculated in the usual way! Also, as mentioned above, beware the consequences of set-
	   ting the value to infinity if incr has been set to an negative value.

EXPORTS
       start() -> ok | {error, Reason}

	      Types  Reason = term()

	      Starts the Megaco application

	      Users may either explicitly be registered with megaco:start_user/2 and/or be stati-
	      cally  configured by setting the application environment variable 'users' to a list
	      of {UserMid, Config} tuples. See the function megaco:start_user/2 for details.

       stop() -> ok | {error, Reason}

	      Types  Reason = term()

	      Stops the Megaco application

       start_user(UserMid, Config) -> ok | {error, Reason}

	      Types  UserMid = megaco_mid()
		     Config = [{user_info_item(), user_info_value()}]
		     Reason = term()

	      Initial configuration of a user

	      Requires the megaco application to be started. A user is	either	a  Media  Gateway
	      (MG) or a Media Gateway Controller (MGC). One Erlang node may host many users.

	      A user is identified by its UserMid, which must be a legal Megaco MID.

	      Config  is a list of {Item, Value} tuples. See megaco:user_info/2 about which items
	      and values that are valid.

       stop_user(UserMid) -> ok | {error, Reason}

	      Types  UserMid = megaco_mid()
		     Reason = term()

	      Delete the configuration of a user

	      Requires that the user does not have any active connection.

       user_info(UserMid) -> [{Item, Value}]
       user_info(UserMid, Item) -> Value | exit(Reason)

	      Types  Handle = user_info_handle()
		     UserMid = megaco_mid()
		     Item = user_info_item()
		     Value = user_info_value()
		     Reason = term()

	      Lookup user information

	      The following Item's are valid:

		connections :
		  Lists all active connections for this user. Returns a list of  megaco_conn_han-
		  dle records.

		receive_handle :
		  Construct a megaco_receive_handle record from user config

		trans_id :
		  Current transaction id.

		  A  positive  integer or the atom undefined_serial (in case no messages has been
		  sent).

		min_trans_id :
		  First trans id.

		  A positive integer, defaults to 1.

		max_trans_id :
		  Last trans id.

		  A positive integer or infinity , defaults to infinity .

		request_timer :
		  Wait for reply.

		  The timer is cancelled when a reply is received.

		  When	a  pending  message  is  received,  the  timer	is  cancelled	and   the
		  long_request_timer is started instead (see below). No resends will be performed
		  from this point (since we now  know  that  the  other  side  has  received  the
		  request).

		  When	the  timer  reaches an intermediate expire, the request is resent and the
		  timer is restarted.

		  When the timer reaches the final expire, either the function	megaco:call  will
		  return  with	{error, timeout} or the callback function handle_trans_reply will
		  be called with UserReply = {error, timeout} (if megaco:cast was used).

		  A Megaco Timer (see explanation above), defaults to #megaco_incr_timer{} .

		long_request_timer :
		  Wait for reply after having received a pending message.

		  When the timer reaches an intermediate expire, the timer is restarted.

		  When a pending message is received, and the long_request_timer is not  "on  its
		  final  leg",	the timer will be restarted, and, if long_request_resend = true ,
		  the request will be re-sent.

		  A Megaco Timer (see explanation above), defaults to 60 seconds .

		long_request_resend :
		  This option indicates weather the request should be resent until the	reply  is
		  received, even though a pending message has been received.

		  Normally,  after a pending message has been received, the request is not resent
		  (since a pending message is an indication that the request has been  received).
		  But  since  the reply (to the request) can be lost, this behaviour has its val-
		  ues.

		  It  is  of  course  pointless  to  set  this	 value	 to   true   unless   the
		  long_request_timer   (see  above)  is  also  set  to	an  incremental  timer	(
		  #megaco_incr_timer{} ).

		  A boolean , defaults to false .

		reply_timer :
		  Wait for an ack.

		  When a request is received, some info related to the reply is store  internally
		  (e.g.  the  binary  of  the  reply). This info will live until either an ack is
		  received or this timer expires. For instance, if the same request  is  received
		  again (e.g. a request with the same transaction id), the (stored) reply will be
		  (re-) sent automatically by megaco.

		  If the timer is of type #megaco_incr_timer{} , then for each intermediate  tim-
		  out,	the  reply will be resent (this is valid until the ack is received or the
		  timer expires).

		  A Megaco Timer (see explanation above), defaults to 30000.

		request_keep_alive_timeout :
		  Specifies the timeout time for the request-keep-alive timer.

		  This timer is started when the first reply to an asynchroneous request  (issued
		  using  the  megaco:cast/3  function) arrives. As long as this timer is running,
		  replies will be delivered via  the  handle_trans_reply/4,5  callback	function,
		  with	their "arrival number" (see UserReply of the handle_trans_reply/4,5 call-
		  back function).

		  Replies arriving after the timer has expired, will be delivered using the  han-
		  dle_unexpected_trans/3,4 callback function.

		  The timeout time can have the values: plain | integer() >= 0 .

		  Defaults to plain .

		call_proxy_gc_timeout :
		  Timeout time for the call proxy.

		  When a request is sent using the call/3 function, a proxy process is started to
		  handle all replies. When the reply has been received and delivered to the user,
		  the  proxy  process continue to exist for as long as this option specifies. Any
		  received messages, is passed on to the  user	via  the  handle_unexpected_trans
		  callback function.

		  The  timeout	time is in milliseconds. A value of 0 (zero) means that the proxy
		  process will exit directly after the reply has been delivered.

		  An integer >= 0, defaults to 5000 (= 5 seconds).

		auto_ack :
		  Automatic send transaction ack when the transaction  reply  has  been  received
		  (see trans_ack below).

		  This is used for three-way-handshake .

		  A boolean , defaults to false .

		trans_ack :
		  Shall ack's be accumulated or not.

		  This property is only valid if auto_ack is true.

		  If  auto_ack	is  true, then if trans_ack is false , ack's will be sent immedi-
		  ately. If trans_ack is true , then ack's will instead be sent to  the  transac-
		  tion	sender process for accumulation and later sending (see trans_ack_maxcount
		  , trans_req_maxcount , trans_req_maxsize , trans_ack_maxcount  and  trans_timer
		  ).

		  See also transaction sender for more info.

		  An boolean , defaults to false .

		trans_ack_maxcount :
		  Maximum  number  of  accumulated ack's. At most this many ack's will be accumu-
		  lated by the transaction  sender  (if  started  and  configured  to  accumulate
		  ack's).

		  See also transaction sender for more info.

		  An integer , defaults to 10.

		trans_req :
		  Shall requests be accumulated or not.

		  If  trans_req  is  false , then request(s) will be sent immediately (in its own
		  message).

		  If trans_req is true, then request(s) will instead be sent to  the  transaction
		  sender  process  for	accumulation  and later sending (see trans_ack_maxcount ,
		  trans_req_maxcount , trans_req_maxsize , trans_ack_maxcount and trans_timer ).

		  See also transaction sender for more info.

		  An boolean , defaults to false .

		trans_req_maxcount :
		  Maximum number of accumulated requests. At most  this  many  requests  will  be
		  accumulated  by the transaction sender (if started and configured to accumulate
		  requests).

		  See also transaction sender for more info.

		  An integer , defaults to 10.

		trans_req_maxsize :
		  Maximum size of the accumulated requests. At most this much  requests  will  be
		  accumulated  by the transaction sender (if started and configured to accumulate
		  requests).

		  See also transaction sender for more info.

		  An integer , defaults to 2048.

		trans_timer :
		  Transaction sender timeout time. Has two functions. First, if the value  is  0,
		  then	transactions will not be accumulated (e.g. the transaction sender process
		  will not be started). Second, if the value is greater then 0 and  auto_ack  and
		  trans_ack  are  both true or if trans_req is true, then transaction sender will
		  be started and transactions (which is depending on the  values  of  auto_ack	,
		  trans_ack and trans_req ) will be accumulated, for later sending.

		  See also transaction sender for more info.

		  An integer , defaults to 0.

		pending_timer :
		  Automatically  send pending if the timer expires before a transaction reply has
		  been sent. This timer is also called provisional response timer.

		  A Megaco Timer (see explanation above), defaults to 30000.

		sent_pending_limit :
		  Sent pending limit (see the MGOriginatedPendingLimit and the MGCOriginatedPend-
		  ingLimit of the megaco root package). This parameter specifies how many pending
		  messages that can be sent (for a given received transaction request). When  the
		  limit is exceeded, the transaction is aborted (see handle_trans_request_abort )
		  and an error message is sent to the other side.

		  Note that this has no effect on the actual  sending  of  pending  transactions.
		  This	is either implicit (e.g. when receiving a re-sent transaction request for
		  a request which is being processed) or controlled  by  the  pending_timer,  see
		  above.

		  A positive integer or infinity , defaults to infinity .

		recv_pending_limit :
		  Receive  pending limit (see the MGOriginatedPendingLimit and the MGCOriginated-
		  PendingLimit of the megaco root package). This  parameter  specifies	how  many
		  pending  messages  that  can be received (for a sent transaction request). When
		  the limit is exceeded,  the  transaction  is	considered  lost,  and	an  error
		  returned to the user (through the call-back function handle_trans_reply ).

		  A positive integer or infinity , defaults to infinity .

		send_mod :
		  Send	 callback   module  which  exports  send_message/2.  The  function  Send-
		  Mod:send_message(SendHandle, Binary) is invoked when	the  bytes  needs  to  be
		  transmitted to the remote user.

		  An atom , defaults to megaco_tcp .

		encoding_mod :
		  Encoding  callback  module which exports encode_message/2 and decode_message/2.
		  The  function  EncodingMod:encode_message(EncodingConfig,   MegacoMessage)   is
		  invoked whenever a 'MegacoMessage' record needs to be translated into an Erlang
		  binary.  The	function  EncodingMod:decode_message(EncodingConfig,  Binary)  is
		  invoked whenever an Erlang binary needs to be translated into a 'MegacoMessage'
		  record.

		  An atom , defaults to megaco_pretty_text_encoder .

		encoding_config :
		  Encoding module config.

		  A list , defaults to [] .

		protocol_version :
		  Actual protocol version.

		  An integer , default is 1.

		strict_version :
		  Strict version control, i.e. when a message is received, verify that	the  ver-
		  sion is that which was negotiated.

		  An boolean , default is true.

		reply_data :
		  Default reply data.

		  Any term, defaults to the atom undefined .

		user_mod :
		  Name	of the user callback module. See the the reference manual for megaco_user
		  for more info.

		user_args :
		  List of extra arguments to the user callback functions. See the  the	reference
		  manual for megaco_user for more info.

		threaded :
		  If  a received message contains several transaction requests, this option indi-
		  cates whether the requests should be handled sequentially in the same process (
		  false  ), or if each request should be handled by its own process ( true i.e. a
		  separate process is spawned for each request).

		  An boolean , defaults to false .

		resend_indication :
		  This option indicates weather the transport module should be told if a  message
		  send is a resend or not.

		  If false , megaco messages are sent using the send_message function.

		  If  true  , megaco message re-sends are made using the resend_message function.
		  The initial message send is still done using the send_message function.

		  The special value flag instead indicates that the function send_message/3 shall
		  be used.

		  A resend_indication() , defaults to false .

		segment_reply_ind :
		  This option specifies if the user shall be notified of received segment replies
		  or not.

		  See handle_segment_reply callback function for more information.

		  A boolean , defaults to false .

		segment_recv_timer :
		  This timer is started when the segment indicated by the  segmentation  complete
		  token is received, but all segments has not yet been received.

		  When	the  timer  finally expires, a "megaco segments not received" (459) error
		  message is sent to the other side and the user is notified with a segment time-
		  out  UserReply in either the handle_trans_reply callback function or the return
		  value of the call function.

		  A Megaco Timer (see explanation above), defaults to 10000 .

		segment_send :
		  Shall outgoing messages be segmented or not:

		  none :
		    Do not segment outgoing reply messages. This is  useful  when  either  it  is
		    known  that  messages  are	never to large or that the transport protocol can
		    handle such things on its own (e.g. TCP or SCTP).

		  integer() > 0 :
		    Outgoing reply messages will be segmented as needed (see max_pdu_size below).
		    This value, K, indicate the outstanding window, i.e. how many segments can be
		    outstanding (not acknowledged) at any given time.

		  infinity :
		    Outgoing reply messages will be segmented as needed (see max_pdu_size below).
		    Segment messages are sent all at once (i.e. no acknowledgement awaited before
		    sending the next segment).

		  Defaults to none .

		max_pdu_size :
		  Max message size. If the encoded message (PDU) exceeds this size,  the  message
		  should be segmented, and then encoded.

		  A positive integer or infinity , defaults to infinity .

       update_user_info(UserMid, Item, Value) -> ok | {error, Reason}

	      Types  UserMid = megaco_mid()
		     Item = user_info_item()
		     Value = user_info_value()
		     Reason = term()

	      Update information about a user

	      Requires	that  the  user  is started. See megaco:user_info/2 about which items and
	      values that are valid.

       conn_info(ConnHandle) -> [{Item, Value}]
       conn_info(ConnHandle, Item) -> Value | exit(Reason)

	      Types  ConnHandle = #megaco_conn_handle{}
		     Item = conn_info_item()
		     Value = conn_info_value()
		     Reason = {no_such_connection, ConnHandle} | term()

	      Lookup information about an active connection

	      Requires that the connection is active.

		control_pid :
		  The process identifier of the controlling process for a connection.

		send_handle :
		  Opaque send handle whose contents is internal for the send module. May  be  any
		  term.

		local_mid :
		  The local mid (of the connection, i.e. the own mid). megaco_mid() .

		remote_mid :
		  The remote mid (of the connection). megaco_mid() .

		receive_handle :
		  Construct a megaco_receive_handle record.

		trans_id :
		  Next	transaction  id. A positive integer or the atom undefined_serial (only in
		  case of error).

		  Note that transaction id's are (currently) maintained on a per  user	basis  so
		  there  is no way to be sure that the value returned will actually be used for a
		  transaction sent on this connection (in case a user  has  several  connections,
		  which is not at all unlikely).

		max_trans_id :
		  Last trans id.

		  A positive integer or infinity , defaults to infinity .

		request_timer :
		  Wait for reply.

		  The timer is cancelled when a reply is received.

		  When	 a   pending  message  is  received,  the  timer  is  cancelled  and  the
		  long_request_timer is started instead (see below). No resends will be performed
		  from	this  point  (since  we  now  know  that  the other side has received the
		  request).

		  When the timer reaches an intermediate expire, the request is  resent  and  the
		  timer is restarted.

		  When	the  timer reaches the final expire, either the function megaco:call will
		  return with {error, timeout} or the callback function  handle_trans_reply  will
		  be called with UserReply = {error, timeout} (if megaco:cast was used).

		  A Megaco Timer (see explanation above), defaults to #megaco_incr_timer{}.

		long_request_timer :
		  Wait for reply after having received a pending message.

		  When the timer reaches an intermediate expire, the timer restarted.

		  When	a  pending message is received, and the long_request_timer is not "on its
		  final leg", the timer will be restarted, and, if long_request_resend =  true	,
		  the request will be re-sent.

		  A Megaco Timer (see explanation above), defaults to 60 seconds .

		request_keep_alive_timeout :
		  Specifies the timeout time for the request-keep-alive timer.

		  This	timer is started when the first reply to an asynchroneous request (issued
		  using the megaco:cast/3 function) arrives. As long as this  timer  is  running,
		  replies  will  be  delivered	via the handle_trans_reply/4,5 callback function,
		  with their "arrival number" (see UserReply of the handle_trans_reply/4,5  call-
		  back function).

		  Replies  arriving after the timer has expired, will be delivered using the han-
		  dle_unexpected_trans/3,4 callback function.

		  The timeout time can have the values: plain | integer() >= 0 .

		  Defaults to plain .

		long_request_resend :
		  This option indicates weather the request should be resent until the	reply  is
		  received, even though a pending message has been received.

		  Normally,  after a pending message has been received, the request is not resent
		  (since a pending message is an indication that the request has been  received).
		  But  since  the reply (to the request) can be lost, this behaviour has its val-
		  ues.

		  It  is  of  course  pointless  to  set  this	 value	 to   true   unless   the
		  long_request_timer   (see  above)  is  also  set  to	an  incremental  timer	(
		  #megaco_incr_timer{} ).

		  A boolean , defaults to false .

		reply_timer :
		  Wait for an ack.

		  When a request is received, some info related to the reply is store  internally
		  (e.g.  the  binary  of  the  reply). This info will live until either an ack is
		  received or this timer expires. For instance, if the same request  is  received
		  again (e.g. a request with the same transaction id), the (stored) reply will be
		  (re-) sent automatically by megaco.

		  If the timer is of type #megaco_incr_timer{} , then for each intermediate  tim-
		  out,	the  reply will be resent (this is valid until the ack is received or the
		  timer expires).

		  A Megaco Timer (see explanation above), defaults to 30000.

		call_proxy_gc_timeout :
		  Timeout time for the call proxy.

		  When a request is sent using the call/3 function, a proxy process is started to
		  handle all replies. When the reply has been received and delivered to the user,
		  the proxy process continue to exist for as long as this option  specifies.  Any
		  received  messages,  is  passed  on to the user via the handle_unexpected_trans
		  callback function.

		  The timeout time is in milliseconds. A value of 0 (zero) means that  the  proxy
		  process will exit directly after the reply has been delivered.

		  An integer >= 0, defaults to 5000 (= 5 seconds).

		auto_ack :
		  Automatic  send  transaction	ack  when the transaction reply has been received
		  (see trans_ack below).

		  This is used for three-way-handshake .

		  A boolean , defaults to false .

		trans_ack :
		  Shall ack's be accumulated or not.

		  This property is only valid if auto_ack is true.

		  If auto_ack is true, then if trans_ack is false , ack's will	be  sent  immedi-
		  ately.  If  trans_ack is true , then ack's will instead be sent to the transac-
		  tion sender process for accumulation and later sending (see  trans_ack_maxcount
		  ,  trans_req_maxcount  , trans_req_maxsize , trans_ack_maxcount and trans_timer
		  ).

		  See also transaction sender for more info.

		  An boolean , defaults to false .

		trans_ack_maxcount :
		  Maximum number of accumulated ack's. At most this many ack's	will  be  accumu-
		  lated  by  the  transaction  sender  (if  started  and configured to accumulate
		  ack's).

		  See also transaction sender for more info.

		  An integer, defaults to 10.

		trans_req :
		  Shall requests be accumulated or not.

		  If trans_req is false , then request(s) will be sent immediately  (in  its  own
		  message).

		  If  trans_req  is true, then request(s) will instead be sent to the transaction
		  sender process for accumulation and later  sending  (see  trans_ack_maxcount	,
		  trans_req_maxcount , trans_req_maxsize , trans_ack_maxcount and trans_timer ).

		  See also transaction sender for more info.

		  An boolean , defaults to false .

		trans_req_maxcount :
		  Maximum  number  of  accumulated  requests.  At most this many requests will be
		  accumulated by the transaction sender (if started and configured to  accumulate
		  requests).

		  See also transaction sender for more info.

		  An integer , defaults to 10.

		trans_req_maxsize :
		  Maximum  size  of  the accumulated requests. At most this much requests will be
		  accumulated by the transaction sender (if started and configured to  accumulate
		  requests).

		  See also transaction sender for more info.

		  An integer , defaults to 2048.

		trans_timer :
		  Transaction  sender  timeout time. Has two functions. First, if the value is 0,
		  then transactions will not be accumulated (e.g. the transaction sender  process
		  will	not  be started). Second, if the value is greater then 0 and auto_ack and
		  trans_ack is true or if trans_req is true,  then  transaction  sender  will  be
		  started  and	transactions  (which  is  depending  on  the values of auto_ack ,
		  trans_ack and trans_req ) will be accumulated, for later sending.

		  See also transaction sender for more info.

		  An integer , defaults to 0.

		pending_timer :
		  Automatic send transaction pending if the timer expires  before  a  transaction
		  reply has been sent. This timer is also called provisional response timer.

		  A Megaco Timer (see explanation above), defaults to 30000.

		sent_pending_limit :
		  Sent pending limit (see the MGOriginatedPendingLimit and the MGCOriginatedPend-
		  ingLimit of the megaco root package). This parameter specifies how many pending
		  messages  that can be sent (for a given received transaction request). When the
		  limit is exceeded, the transaction is aborted (see handle_trans_request_abort )
		  and an error message is sent to the other side.

		  Note	that  this  has  no effect on the actual sending of pending transactions.
		  This is either implicit (e.g. when receiving a re-sent transaction request  for
		  a  request  which  is  being processed) or controlled by the pending_timer, see
		  above.

		  A positive integer or infinity , defaults to infinity .

		recv_pending_limit :
		  Receive pending limit (see the MGOriginatedPendingLimit and the  MGCOriginated-
		  PendingLimit	of  the  megaco  root package). This parameter specifies how many
		  pending messages that can be received (for a sent  transaction  request).  When
		  the  limit  is  exceeded,  the  transaction  is  considered  lost, and an error
		  returned to the user (through the call-back function handle_trans_reply ).

		  A positive integer or infinity , defaults to infinity .

		send_mod :
		  Send	callback  module  which  exports  send_message/2.  The	 function   Send-
		  Mod:send_message(SendHandle,	Binary)  is  invoked  when  the bytes needs to be
		  transmitted to the remote user.

		  An atom , defaults to megaco_tcp .

		encoding_mod :
		  Encoding callback module which exports encode_message/2  and	decode_message/2.
		  The	function   EncodingMod:encode_message(EncodingConfig,  MegacoMessage)  is
		  invoked whenever a 'MegacoMessage' record needs to be translated into an Erlang
		  binary.  The	function  EncodingMod:decode_message(EncodingConfig,  Binary)  is
		  invoked whenever an Erlang binary needs to be translated into a 'MegacoMessage'
		  record.

		  An atom , defaults to megaco_pretty_text_encoder .

		encoding_config :
		  Encoding module config.

		  A list , defaults to [].

		protocol_version :
		  Actual protocol version.

		  An positive integer, Current default is 1.

		strict_version :
		  Strict  version  control, i.e. when a message is received, verify that the ver-
		  sion is that which was negotiated.

		  An boolean , default is true.

		reply_data :
		  Default reply data.

		  Any term, defaults to the atom undefined .

		threaded :
		  If a received message contains several transaction requests, this option  indi-
		  cates whether the requests should be handled sequentially in the same process (
		  false ), or if each request should be handled by its own process ( true i.e.	a
		  separate process is spawned for each request).

		  An boolean , defaults to false .

		resend_indication :
		  This	option indicates weather the transport module should be told if a message
		  send is a resend or not.

		  If false , megaco messages are sent using the send_message/2 function.

		  If true , megaco message re-sends are made using the	resend_message	function.
		  The initial message send is still done using the send_message function.

		  The special value flag instead indicates that the function send_message/3 shall
		  be used.

		  A resend_indication() , defaults to false .

		segment_reply_ind :
		  This option specifies if the user shall be notified of received segment replies
		  or not.

		  See handle_segment_reply callback function for more information.

		  A boolean , defaults to false .

		segment_recv_timer :
		  This	timer  is started when the segment indicated by the segmentation complete
		  token (e.g. the last of the segment which makes up the reply) is received,  but
		  all segments has not yet been received.

		  When	the  timer  finally expires, a "megaco segments not received" (459) error
		  message is sent to the other side and the user is notified with a segment time-
		  out  UserReply in either the handle_trans_reply callback function or the return
		  value of the call function.

		  A Megaco Timer (see explanation above), defaults to 10000 .

		segment_send :
		  Shall outgoing messages be segmented or not:

		  none :
		    Do not segment outgoing reply messages. This is  useful  when  either  it  is
		    known  that  messages  are	never to large or that the transport protocol can
		    handle such things on its own (e.g. TCP or SCTP).

		  integer() > 0 :
		    Outgoing reply messages will be segmented as needed (see max_pdu_size below).
		    This value, K, indicate the outstanding window, i.e. how many segments can be
		    outstanding (not acknowledged) at any given time.

		  infinity :
		    Outgoing reply messages will be segmented as needed (see max_pdu_size below).
		    Segment messages are sent all at once (i.e. no acknowledgement awaited before
		    sending the next segment).

		  Defaults to none .

		max_pdu_size :
		  Max message size. If the encoded message (PDU) exceeds this size,  the  message
		  should be segmented, and then encoded.

		  A positive integer or infinity , defaults to infinity .

       update_conn_info(ConnHandle, Item, Value) -> ok | {error, Reason}

	      Types  ConnHandle = #megaco_conn_handle{}
		     Item = conn_info_item()
		     Value = conn_info_value()
		     Reason = term()

	      Update information about an active connection

	      Requires that the connection is activated. See megaco:conn_info/2 about which items
	      and values that are valid.

       system_info() -> [{Item, Value}] | exit(Reason)
       system_info(Item) -> Value | exit(Reason)

	      Types  Item = system_info_item()

	      Lookup system information

	      The following items are valid:

		text_config :
		  The text encoding config.

		connections :
		  Lists all active connections. Returns a list of megaco_conn_handle records.

		users :
		  Lists all active users. Returns a list of megaco_mid()'s.

		n_active_requests :
		  Returns an integer representing the number of requests that has originated from
		  this	 Erlang  node  and  still  are	active	(and  therefore  consumes  system
		  resources).

		n_active_replies :
		  Returns an integer representing the number of replies that has originated  from
		  this	 Erlang  node  and  still  are	active	(and  therefore  consumes  system
		  resources).

		n_active_connections :
		  Returns an integer representing the number of active connections.

       info() -> Info

	      Types  Info = [{Key, Value}]

	      This function produces a list of information about the megaco application. Such  as
	      users and their config, connections and their config, statistics and so on.

	      This  information  can  be  produced  by the functions user_info , conn_info , sys-
	      tem_info and get_stats but this is a simple way to get it all at once.

       connect(ReceiveHandle, RemoteMid, SendHandle, ControlPid) -> {ok,  ConnHandle}  |  {error,
       Reason}
       connect(ReceiveHandle,  RemoteMid,  SendHandle,	ControlPid,  Extra) -> {ok, ConnHandle} |
       {error, Reason}

	      Types  ReceiveHandle = #megaco_receive_handle{}
		     RemoteMid = preliminary_mid | megaco_mid()
		     SendHandle = term()
		     ControlPid = pid()
		     ConnHandle = #megaco_conn_handle{}
		     Reason = connect_reason() | handle_connect_reason() | term()
		     connect_reason() = {no_such_user, LocalMid} |  {already_connected,  ConnHan-
		     dle} | term()
		     handle_connect_error() = {connection_refused, ConnData, ErrorInfo} | term()
		     LocalMid = megaco_mid()
		     ConnData = term()
		     ErrorInfo = term()
		     Extra = term()

	      Establish a "virtual" connection

	      Activates  a  connection	to a remote user. When this is done the connection can be
	      used to send messages (with SendMod:send_message/2). The ControlPid is the  identi-
	      fier of a process that controls the connection. That process will be supervised and
	      if it dies, this will be	detected  and  the  UserMod:handle_disconnect/2  callback
	      function	will be invoked. See the megaco_user module for more info about the call-
	      back arguments. The connection may  also	explicitly  be	deactivated  by  invoking
	      megaco:disconnect/2.

	      The  ControlPid  may  be the identity of a process residing on another Erlang node.
	      This is useful when you want to distribute a user over  several  Erlang  nodes.  In
	      such  a  case one of the nodes has the physical connection. When a user residing on
	      one  of  the  other  nodes  needs  to  send  a  request  (with   megaco:call/3   or
	      megaco:cast/3),  the  message will encoded on the originating Erlang node, and then
	      be forwarded to the node with the physical connection. When the reply  arrives,  it
	      will be forwarded back to the originator. The distributed connection may explicitly
	      be deactivated by a local call to megaco:disconnect/2 or implicitly when the physi-
	      cal  connection  is  deactivated (with megaco:disconnect/2, killing the controlling
	      process, halting the other node, ...).

	      The call of this function will trigger the  callback  function  UserMod:handle_con-
	      nect/2  to  be invoked. See the megaco_user module for more info about the callback
	      arguments.

	      A connection may be established in several ways:

		provisioned MID :
		  The MG may explicitly invoke megaco:connect/4 and use a provisioned MID of  the
		  MGC as the RemoteMid.

		upgrade preliminary MID :
		  The  MG  may explicitly invoke megaco:connect/4 with the atom 'preliminary_mid'
		  as a temporary MID of the MGC, send  an  intial  message,  the  Service  Change
		  Request,  to	the  MGC and then wait for an initial message, the Service Change
		  Reply. When the reply arrives, the Megaco application will pick the MID of  the
		  MGC  from  the  message header and automatically upgrade the connection to be a
		  "normal" connection. By using this method of establishing the  connection,  the
		  callback  function  UserMod:handle_connect/2	to be invoked twice. First with a
		  ConnHandle with the remote_mid-field set to preliminary_mid, and then when  the
		  connection  upgrade  is done with the remote_mid-field set to the actual MID of
		  the MGC.

		automatic :
		  When the MGC receives its first message, the Service Change Request, the Megaco
		  application  will  automatically  establish  the connection by using the MG MID
		  found in the message header as remote mid.

		distributed :
		  When a user (MG/MGC) is distributed over several nodes, it is required that the
		  node hosting the connection already has activated the connection and that it is
		  in the "normal" state. The RemoteMid must be a real Megaco MID and not  a  pre-
		  liminary_mid.

	      An initial megaco_receive_handle record may be obtained with megaco:user_info(User-
	      Mid, receive_handle)

	      The send handle is provided by the preferred  transport  module,	e.g.  megaco_tcp,
	      megaco_udp. Read the documentation about each transport module about the details.

	      The  connect  is	done in two steps: first an internal connection setup and then by
	      calling the user handle_connect callback function. The first step could  result  in
	      an  error with Reason = connect_reason() and the second an error with Reason = han-
	      dle_connect_reason() :

		connect_reason() :
		  An error with this reason is generated by the megaco application itself.

		handle_connect_reason() :
		  An error with this reason is caused by the user handle_connect  callback  func-
		  tion either returning an error or an invalid value.

	      Extra  can  be any term() except the atom ignore_extra . It is passed (back) to the
	      user via the callback function handle_connect/3 .

       disconnect(ConnHandle, DiscoReason) -> ok | {error, ErrReason}

	      Types  ConnHandle = conn_handle()
		     DiscoReason = term()
		     ErrReason = term()

	      Tear down a "virtual" connection

	      Causes the UserMod:handle_disconnect/2 callback function to  be  invoked.  See  the
	      megaco_user module for more info about the callback arguments.

       call(ConnHandle, Actions, Options) -> {ProtocolVersion, UserReply}

	      Types  ConnHandle = conn_handle()
		     Actions = action_reqs() | [action_reqs()]
		     action_reqs() = binary() | [action_request()]
		     Options = [send_option()]
		     send_option()   =	{request_timer,  megaco_timer()}  |  {long_request_timer,
		     megaco_timer()} | {send_handle, term()} |	{protocol_version,  integer()}	|
		     {call_proxy_gc_timeout, call_proxy_gc_timeout()}
		     ProtocolVersion = integer()
		     UserReply = user_reply() | [user_reply()]
		     user_reply() = success() | failure()
		     success() = {ok, result()} | {ok, result(), extra()}
		     result() = message_result() | segment_result()
		     message_result() = action_reps()
		     segment_result() = segments_ok()
		     failure() = {error, reason()} | {error, reason(), extra()}
		     reason()  =  message_reason()  |  segment_reason()  | user_cancel_reason() |
		     send_reason() | other_reason()
		     message_reason() = error_desc()
		     segment_reason() = {segment, segments_ok(), segments_err()} | {segment_time-
		     out, missing_segments(), segments_ok(), segments_err()}
		     segments_ok() = [segment_ok()]
		     segment_ok() = {segment_no(), action_reps()}
		     segments_err() = [segment_err()]
		     segment_err() = {segment_no(), error_desc()}
		     missing_segments() = [segment_no()]
		     user_cancel_reason() = {user_cancel, reason_for_user_cancel()}
		     reason_for_user_cancel() = term()
		     send_reason() = send_cancelled_reason() | send_failed_reason()
		     send_cancelled_reason() = {send_message_cancelled, reason_for_send_cancel()}
		     reason_for_send_cancel() = term()
		     send_failed_reason() = {send_message_failed, reason_for_send_failure()}
		     reason_for_send_failure() = term()
		     other_reason() = {wrong_mid, WrongMid, RightMid, TR} | term()
		     WrongMid = mid()
		     RightMid = mid()
		     TR = transaction_reply()
		     action_reps() = [action_reply()]
		     call_proxy_gc_timeout() = integer() >= 0
		     extra() = term()

	      Sends one or more transaction request(s) and waits for the reply.

	      When  sending one transaction in a message, Actions should be action_reqs() ( User-
	      Reply will then be user_reply() ). When sending several transactions in a  message,
	      Actions  should  be [action_reqs()] ( UserReply will then be [user_reply()] ). Each
	      element of the list is part of one transaction.

	      For some of our codecs (not binary), it is also possible to pre-encode the actions,
	      in which case Actions will be either a binary() or [binary()] .

	      The  function  returns  when  the  reply arrives, when the request timer eventually
	      times out or when the outstanding requests are explicitly cancelled.

	      The default values of the send options are obtained by megaco:conn_info(ConnHandle,
	      Item) . But the send options above, may explicitly be overridden.

	      The ProtocolVersion version is the version actually encoded in the reply message.

	      At success() , the UserReply contains a list of 'ActionReply' records possibly con-
	      taining error indications.

	      A message_error() , indicates that the remote user has  replied  with  an  explicit
	      transactionError.

	      A  user_cancel_error()  , indicates that the request has been canceled by the user.
	      reason_for_user_cancel() is the reason given in the call to the cancel function.

	      A send_error() , indicates that the send function of the megaco transport  callback
	      module  failed  to  send	the  request.  There  are  two	separate cases: send_can-
	      celled_reason() and send_failed_reason() . The first is  the  result  of	the  send
	      function	returning {cancel, Reason} and the second is some other kind of erroneous
	      return value. See the send_message function for more info.

	      An other_error() , indicates some other error such as timeout.

	      For more info about the extra() part of the result, see the note in the user  call-
	      back module documentation.

       cast(ConnHandle, Actions, Options) -> ok | {error, Reason}

	      Types  ConnHandle = conn_handle()
		     Actions = action_reqs() | [action_reqs()]
		     action_reqs() = binary() | [action_request()]
		     Options = [send_option()]
		     send_option() = {request_keep_alive_timeout, request_keep_alive_timeout()} |
		     {request_timer, megaco_timer()}  |  {long_request_timer,  megaco_timer()}	|
		     {send_handle,  term()}  |	{reply_data,  reply_data()}  | {protocol_version,
		     integer()}
		     request_keep_alive_timeout() = plain | integer() >= 0
		     Reason = term()

	      Sends one or more transaction request(s) but does NOT wait for a reply

	      When sending one transaction in a message, Actions should be action_reqs()  .  When
	      sending several transactions in a message, Actions should be [action_reqs()] . Each
	      element of the list is part of one transaction.

	      For some of our codecs (not binary), it is also possible to pre-encode the actions,
	      in which case Actions will be either a binary() or [binary()] .

	      The default values of the send options are obtained by megaco:conn_info(ConnHandle,
	      Item). But the send options above, may explicitly be overridden.

	      The ProtocolVersion version is the version actually encoded in the reply message.

	      The callback  function  UserMod:handle_trans_reply/4  is	invoked  when  the  reply
	      arrives,	when  the  request  timer  eventually  times  out or when the outstanding
	      requests are explicitly cancelled. See the megaco_user module for more  info  about
	      the callback arguments.

	      Given as UserData argument to UserMod:handle_trans_reply/4.

       encode_actions(ConnHandle, Actions, Options) -> {ok, BinOrBins} | {error, Reason}

	      Types  ConnHandle = conn_handle()
		     Actions = action_reqs() | [action_reqs()]
		     action_reqs() = [#'ActionRequest'{}]
		     Options = [send_option()]
		     send_option()   =	{request_timer,  megaco_timer()}  |  {long_request_timer,
		     megaco_timer()} | {send_handle, term()} | {protocol_version, integer()}
		     BinOrBins = binary() | [binary()]
		     Reason = term()

	      Encodes lists of action requests for one or more transaction request(s).

	      When encoding action requests for one transaction, Actions should be  action_reqs()
	      .  When  encoding  action  requests  for	several  transactions,	Actions should be
	      [action_reqs()] . Each element of the list is part of one transaction.

       token_tag2string(Tag) -> Result
       token_tag2string(Tag, EncoderMod) -> Result
       token_tag2string(Tag, EncoderMod, Version) -> Result

	      Types  Tag = atom()
		     EncoderMod = pretty | compact | encoder_module()
		     encoder_module() = megaco_pretty_text_encoder |  megaco_compact_text_encoder
		     | atom()
		     Version = int_version() | atom_version()
		     int_version() = 1 | 2 | 3
		     atom_version() = v1 | v2 | v3 | prev3c | prev3b
		     Result = string() | {error, Reason}
		     Reason = term()

	      Convert a token tag to a string

	      If no encoder module is given, the default is used (which is pretty).

	      If no or an unknown version is given, the best version is used (which is v3).

	      If no match is found for Tag , Result will be the empty string ( [] ).

       cancel(ConnHandle, CancelReason) -> ok | {error, ErrReason}

	      Types  ConnHandle = conn_handle()
		     CancelReason = term()
		     ErrReason = term()

	      Cancel all outstanding messages for this connection

	      This  causes  outstanding  megaco:call/3 requests to return. The callback functions
	      UserMod:handle_reply/4 and UserMod:handle_trans_ack/4 are  also  invoked	where  it
	      applies. See the megaco_user module for more info about the callback arguments.

       process_received_message(ReceiveHandle, ControlPid, SendHandle, BinMsg) -> ok
       process_received_message(ReceiveHandle, ControlPid, SendHandle, BinMsg, Extra) -> ok

	      Types  ReceiveHandle = #megaco_receive_handle{}
		     ControlPid = pid()
		     SendHandle = term()
		     BinMsg = binary()
		     Extra = term()

	      Process a received message

	      This  function  is  intended  to	be  invoked by some transport modules when get an
	      incoming message. Which transport that actually is  used	is  up	to  the  user  to
	      choose.

	      The  message is delivered as an Erlang binary and is decoded by the encoding module
	      stated in the receive handle together with its encoding config (also in the receive
	      handle).	Depending  of the outcome of the decoding various callback functions will
	      be invoked. See megaco_user for more info about the callback arguments.

	      The argument Extra is just an opaque data structure passed  to  the  user  via  the
	      callback functions in the user callback module . Note however that if Extra has the
	      value   extra_undefined	the   argument	 will	be   ignored	(same	 as    if
	      process_received_message/4  had  been called). See the documentation for the behav-
	      iour of the callback module, megaco_user , for more info.

	      Note that all processing is done in the context of the calling process. A transport
	      module  could  call this function via one of the spawn functions (e.g. spawn_opt ).
	      See also receive_message/4,5 .

	      If the message cannot be decoded the following callback function will be invoked:

		* UserMod:handle_syntax_error/3

	      If the decoded message instead of transactions contains a message error,	the  fol-
	      lowing callback function will be invoked:

		* UserMod:handle_message_error/3

	      If the decoded message happens to be received before the connection is established,
	      a new "virtual" connection is established. This is typically the case for the Media
	      Gateway  Controller  (MGC) upon the first Service Change. When this occurs the fol-
	      lowing callback function will be invoked:

		* UserMod:handle_connect/2

	      For each transaction request in the decoded message the following callback function
	      will be invoked:

		* UserMod:handle_trans_request/3

	      For  each  transaction  reply  in  the decoded message the reply is returned to the
	      user. Either the originating function megaco:call/3 will return.	Or  in	case  the
	      originating  function  was  megaco:case/3  the  following callback function will be
	      invoked:

		* UserMod:handle_trans_reply/4

	      When a transaction acknowledgement is received it is possible that user has decided
	      not  to  bother  about the acknowledgement. But in case the return value from User-
	      Mod:handle_trans_request/3 indicates that the acknowledgement is important the fol-
	      lowing callback function will be invoked:

		* UserMod:handle_trans_ack/4

	      See the megaco_user module for more info about the callback arguments.

       receive_message(ReceiveHandle, ControlPid, SendHandle, BinMsg) -> ok
       receive_message(ReceiveHandle, ControlPid, SendHandle, BinMsg, Extra) -> ok

	      Types  ReceiveHandle = #megaco_receive_handle{}
		     ControlPid = pid()
		     SendHandle = term()
		     BinMsg = binary()
		     Extra = term()

	      Process a received message

	      This  is	a callback function intended to be invoked by some transport modules when
	      get an incoming message. Which transport that actually is used is up to the user to
	      choose.

	      In  principle,  this  function  calls the process_received_message/4 function via a
	      spawn to perform the actual processing.

	      For further information see the process_received_message/4 function.

       parse_digit_map(DigitMapBody) -> {ok, ParsedDigitMap} | {error, Reason}

	      Types  DigitMapBody = string()
		     ParsedDigitMap = parsed_digit_map()
		     parsed_digit_map() = term()
		     Reason = term()

	      Parses a digit map body

	      Parses a digit map body, represented as a list of characters, into a list of  state
	      transitions suited to be evaluated by megaco:eval_digit_map/1,2.

       eval_digit_map(DigitMap) -> {ok, MatchResult} | {error, Reason}
       eval_digit_map(DigitMap, Timers) -> {ok, MatchResult} | {error, Reason}

	      Types  DigitMap = #'DigitMapValue'{} | parsed_digit_map()
		     parsed_digit_map() = term()
		     ParsedDigitMap = term()
		     Timers = ignore() | reject()
		     ignore() = ignore | {ignore, digit_map_value()}
		     reject() = reject | {reject, digit_map_value()} | digit_map_value()
		     MatchResult = {Kind, Letters} | {Kind, Letters, Extra}
		     Kind = kind()
		     kind() = full | unambiguous
		     Letters = [letter()]
		     letter() = $0..$9 | $a .. $k
		     Extra = letter()
		     Reason = term()

	      Collect digit map letters according to the digit map.

	      When  evaluating	a  digit  map,	a  state  machine  waits for timeouts and letters
	      reported by megaco:report_digit_event/2. The length of  the  various  timeouts  are
	      defined in the digit_map_value() record.

	      When  a complete sequence of valid events has been received, the result is returned
	      as a list of letters.

	      There are two options for handling syntax errors (that is when an unexpected  event
	      is  received when the digit map evaluator is expecting some other event). The unex-
	      pected events may either be ignored or rejected. The latter means that the  evalua-
	      tion is aborted and an error is returned.

       report_digit_event(DigitMapEvalPid, Events) -> ok | {error, Reason}

	      Types  DigitMapEvalPid = pid()
		     Events = Event | [Event]
		     Event = letter() | pause() | cancel()
		     letter() = $0..$9 | $a .. $k | $A .. $K
		     pause() = one_second() | ten_seconds()
		     one_second() = $s | $S
		     ten_seconds() = $l | $L
		     cancel() = $z | $Z | cancel
		     Reason = term()

	      Send one or more events to the event collector process.

	      Send  one  or  more  events  to a process that is evaluating a digit map, that is a
	      process that is executing megaco:eval_digit_map/1,2.

	      Note that the events $s | $S , l | $L and $z | $Z has nothing to do with the timers
	      using the same characters.

       test_digit_event(DigitMap, Events) -> {ok, Kind, Letters} | {error, Reason}

	      Types  DigitMap = #'DigitMapValue'{} | parsed_digit_map()
		     parsed_digit_map() = term()
		     ParsedDigitMap = term()
		     Timers = ignore() | reject()
		     ignore() = ignore | {ignore, digit_map_value()}
		     reject() = reject | {reject, digit_map_value()} | digit_map_value()
		     DigitMapEvalPid = pid()
		     Events = Event | [Event]
		     Event = letter() | pause() | cancel()
		     Kind = kind()
		     kind() = full | unambiguous
		     Letters = [letter()]
		     letter() = $0..$9 | $a .. $k | $A .. $K
		     pause() = one_second() | ten_seconds()
		     one_second() = $s | $S
		     ten_seconds() = $l | $L
		     cancel () = $z | $Z | cancel
		     Reason = term()

	      Feed digit map collector with events and return the result

	      This function starts the evaluation of a digit map with megaco:eval_digit_map/1 and
	      sends a sequence of events to it megaco:report_digit_event/2 in order  to  simplify
	      testing of digit maps.

       encode_sdp(SDP) -> {ok, PP} | {error, Reason}

	      Types  SDP  =  sdp_property_parm() | sdp_property_group() | sdp_property_groups() |
		     asn1_NOVALUE
		     PP = property_parm() | property_group() | property_groups() | asn1_NOVALUE
		     Reason = term()

	      Encode (generate) an SDP construct.

	      If a property_parm() is found as part of	the  input  (  SDP  )  then  it  is  left
	      unchanged.

	      This function performs the following transformation:

		* sdp() -> property_parm()

		* sdp_property_group() -> property_group()

		* sdp_property_groups() -> property_groups()

       decode_sdp(PP) -> {ok, SDP} | {error, Reason}

	      Types  PP = property_parm() | property_group() | property_groups() | asn1_NOVALUE
		     SDP  =  sdp() | decode_sdp_property_group() | decode_sdp_property_groups() |
		     asn1_NOVALUE
		     decode_sdp() = sdp() | {property_parm(), DecodeError}
		     decode_sdp_property_group() = [decode_sdp()]
		     decode_sdp_property_groups() = [decode_sdp_property_group()]
		     DecodeError = term()
		     Reason = term()

	      Decode (parse) a property parameter construct.

	      When decoding property_group() or property_groups() , those property parameter con-
	      structs  that cannot be decoded (either because of decode error or because they are
	      unknown), will be returned as a two-tuple. The first element of which will  be  the
	      (undecoded) property parameter and the other the actual reason. This means that the
	      caller of this function has to expect not only sdp-records, but also this two-tuple
	      construct.

	      This function performs the following transformation:

		* property_parm() -> sdp()

		* property_group() -> sdp_property_group()

		* property_groups() -> sdp_property_groups()

       get_sdp_record_from_PropertGroup(Type, PG) -> [sdp()]

	      Types  Type = v | c | m | o | a | b | t | r | z | k | s | i | u | e | p
		     PG = sdp_property_group()
		     Reason = term()

	      Retreive all the sdp records of type Type from the property group PG .

       versions1() -> {ok, VersionInfo} | {error, Reason}
       versions2() -> {ok, Info} | {error, Reason}

	      Types  VersionInfo = [version_info()]
		     version_info() = term()
		     Reason = term()

	      Utility functions used to retrieve some system and application info.

	      The  difference  between the two functions is in how they get the modules to check.
	      versions1 uses the app-file and versions2 uses the function application:get_key .

       print_version_info() -> void()
       print_version_info(VersionInfo) -> void()

	      Types  VersionInfo = [version_info()]
		     version_info() = term()

	      Utility function to produce a formated printout of the versions info  generated  by
	      the versions1 and versions2 functions.

	      The  function  print_version_info/0  uses the result of function version1/0 as Ver-
	      sionInfo .

	      Example:

			 {ok, V} = megaco:versions1(), megaco:format_versions(V).

       enable_trace(Level, Destination) -> void()

	      Types  Level = max | min | 0 <= integer() <= 100
		     Destination = File | Port | HandlerSpec | io
		     File = string()
		     Port = integer()
		     HandleSpec = {HandlerFun, Data}
		     HandleFun = fun() (two arguments)
		     Data = term()

	      This function is used to start megaco tracing at a given Level and direct result to
	      the given Destination .

	      It  starts  a tracer server and then sets the proper match spec (according to Level
	      ).

	      In the case when Destination is File , the printable megaco trace  events  will  be
	      printed to the file File using plain io:format/2 .

	      In  the  case  when  Destination	is io , the printable megaco trace events will be
	      printed on stdout using plain io:format/2 .

	      See dbg for further information.

       disable_trace() -> void()

	      This function is used to stop megaco tracing.

       set_trace(Level) -> void()

	      Types  Level = max | min | 0 <= integer() <= 100

	      This function is used to change the megaco trace level.

	      It is assumed that tracing has already been enabled (see enable_trace above).

       get_stats() -> {ok, TotalStats} | {error, Reason}
       get_stats(GlobalCounter) -> {ok, CounterStats} | {error, Reason}
       get_stats(ConnHandle) -> {ok, ConnHandleStats} | {error, Reason}
       get_stats(ConnHandle, Counter) -> {ok, integer()} | {error, Reason}

	      Types  TotalStats = [total_stats()]
		     total_stats() = {conn_handle(), [stats()]} | {global_counter(), integer()}
		     GlobalCounter = global_counter()
		     GlobalCounterStats = integer()
		     ConnHandle = conn_handle()
		     ConnHandleStats = [stats()]
		     stats() = {counter(), integer()}
		     Counter = counter()
		     counter() = medGwyGatewayNumTimerRecovery | medGwyGatewayNumErrors
		     global_counter() = medGwyGatewayNumErrors
		     Reason = term()

	      Retreive the (SNMP) statistic counters maintained by the	megaco	application.  The
	      global  counters	handle	events	that  cannot be attributed to a single connection
	      (e.g. protocol errors that occur before the connection has been properly setup).

       reset_stats() -> void()
       reset_stats(ConnHandle) -> void()

	      Types  ConnHandle = conn_handle()

	      Reset all related (SNMP) statistics counters.

       test_request(ConnHandle,  Version,  EncodingMod,  EncodingConfig,  Actions)  ->	{MegaMsg,
       EncodeRes}

	      Types  ConnHandle = conn_handle()
		     Version = integer()
		     EncodingMod = atom()
		     EncodingConfig = Encoding configuration
		     Actions = A list
		     MegaMsg = #'MegacoMessage'{}
		     EncodeRes = {ok, Bin} | {error, Reason}
		     Bin = binary()
		     Reason = term()

	      Tests if the Actions argument is correctly composed.

	      This  function  is only intended for testing purposes. It's supposed to have a same
	      kind of interface as the call or cast functions (with the additions of  the  Encod-
	      ingMod  and  EncodingConfig  arguments).	It composes a complete megaco message end
	      attempts to encode it. The return value, will be a tuple	of  the  composed  megaco
	      message and the encode result.

       test_reply(ConnHandle,	Version,   EncodingMod,   EncodingConfig,   Reply)  ->	{MegaMsg,
       EncodeRes}

	      Types  ConnHandle = conn_handle()
		     Version = integer()
		     EncodingMod = atom()
		     EncodingConfig = A list
		     Reply = actual_reply()
		     MegaMsg = #'MegacoMessage'{}
		     EncodeRes = {ok, Bin} | {error, Reason}
		     Bin = binary()
		     Reason = term()

	      Tests if the Reply argument is correctly composed.

	      This function is only intended for testing purposes.  It's  supposed  to	test  the
	      actual_reply() return value of the callback functions handle_trans_request and han-
	      dle_trans_long_request functions (with the additions of the EncodingMod and  Encod-
	      ingConfig  arguments). It composes a complete megaco message end attempts to encode
	      it. The return value, will be a tuple of the composed megaco message and the encode
	      result.

Ericsson AB				  megaco 3.15.1 			     megaco(3erl)


All times are GMT -4. The time now is 10:06 PM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
×
UNIX.COM Login
Username:
Password:  
Show Password