File: megaco_user.html

package info (click to toggle)
erlang-doc-html 1%3A11.b.2-1
links: PTS
area: main
in suites: etch, etch-m68k
size: 23,284 kB
ctags: 10,724
sloc: erlang: 505; ansic: 323; makefile: 62; perl: 61; sh: 45
file content (752 lines) | stat: -rw-r--r-- 23,389 bytes
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- This document was generated using DocBuilder 3.3.3 -->
<HTML>
<HEAD>
  <TITLE>megaco_user</TITLE>
  <SCRIPT type="text/javascript" src="../../../../doc/erlresolvelinks.js">
</SCRIPT>
  <STYLE TYPE="text/css">
<!--
    .REFBODY     { margin-left: 13mm }
    .REFTYPES    { margin-left: 8mm }
-->
  </STYLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#FF00FF"
      ALINK="#FF0000">
<!-- refpage -->
<CENTER>
<A HREF="http://www.erlang.se">
  <IMG BORDER=0 ALT="[Ericsson AB]" SRC="min_head.gif">
</A>
<H1>megaco_user</H1>
</CENTER>

<H3>MODULE</H3>
<DIV CLASS=REFBODY>
megaco_user
</DIV>

<H3>MODULE SUMMARY</H3>
<DIV CLASS=REFBODY>
 Callback module for users of the Megaco application

</DIV>

<H3>DESCRIPTION</H3>
<DIV CLASS=REFBODY>

<P> This module defines the callback behaviour of Megaco users. A
megaco_user compliant callback module must export the following
functions: 
<P>
<UL>

<LI>
 <A HREF="#connect">handle_connect/2</A><BR>


</LI>


<LI>
 <A HREF="#disconnect">handle_disconnect/3</A><BR>


</LI>


<LI>
 <A HREF="#syntax_error">handle_syntax_error/3</A><BR>


</LI>


<LI>
 <A HREF="#message_error">handle_message_error/3</A><BR>


</LI>


<LI>
 <A HREF="#trans_request">handle_trans_request/3</A><BR>


</LI>


<LI>
 <A HREF="#trans_long_request">handle_trans_long_request/3</A><BR>


</LI>


<LI>
 <A HREF="#trans_reply">handle_trans_reply/4</A><BR>


</LI>


<LI>
 <A HREF="#trans_ack">handle_trans_ack/4</A><BR>


</LI>


<LI>
 <A HREF="#unexpected_trans">handle_unexpected_trans/3</A><BR>


</LI>


<LI>
 <A HREF="#request_abort">handle_trans_request_abort/4</A><BR>


</LI>


</UL>

<P>The semantics of them and their exact signatures are explained
below. There are a couple data types that are common for many
of the functions. These are explained here:
<P>
<DL>

<DT>
<CODE>conn_handle()</CODE>
</DT>

<DD>
        Is the 'megaco_conn_handle' record initially returned by
         megaco:connect/4. It identifies a &#34;virtual&#34; connection and
         may be reused after a reconnect (disconnect + connect).
        <BR>


</DD>

<DT>
<CODE>protocol_version()</CODE>
</DT>

<DD>
        Is the actual protocol version. In most cases the protocol
         version is retreived from the processed message, but there
         are exceptions:<BR>

        <BR>

<UL>

<LI>
         When handle_connect/2 is triggered by an explicit call
         to megaco:connect/4.<BR>

         
</LI>


<LI>
         handle_disconnect/3<BR>

         
</LI>


<LI>
         handle_syntax_error/3<BR>

         
</LI>


</UL>


        In these cases, the ProtocolVersion default
         version is obtained from the static connection
         configuration:<BR>

        
<UL>

<LI>
         megaco:conn_info(ConnHandle, protocol_version).<BR>

         
</LI>


</UL>


</DD>

<DT>
<CODE>error_descr()</CODE>
</DT>

<DD>
        An 'ErrorDescriptor' record.<BR>


</DD>

</DL>

<P>The <CODE>user_args</CODE> configuration parameter which may be used to
extend the argument list of the callback functions. For example,
the handle_connect function takes by default two arguments:
<P>
<UL>

<LI>
handle_connect(Handle, Version)<BR>

</LI>


</UL>

<P>but if the <CODE>user_args</CODE> parameter is set to a longer
list, such as <CODE>[SomePid,SomeTableRef]</CODE>, the callback
function is expected to have these (in this case two) extra
arguments last in the argument list:
<P>
<UL>

<LI>
 handle_connect(Handle, Version, SomePid, SomeTableRef)<BR>


</LI>


</UL>
<A NAME="connect"><!-- Empty --></A>
</DIV>

<H3>EXPORTS</H3>

<P><A NAME="handle_connect/2"><STRONG><CODE>handle_connect(ConnHandle, ProtocolVersion) -&#62; ok | error | {error,ErrorDescr}</CODE></STRONG></A><BR>

<DIV CLASS=REFBODY><P>Types:
  <DIV CLASS=REFTYPES>
<P>
<STRONG><CODE>ConnHandle = conn_handle()</CODE></STRONG><BR>
<STRONG><CODE>ProtocolVersion = protocol_version()</CODE></STRONG><BR>
<STRONG><CODE>ErrorDescr = error_descr()</CODE></STRONG><BR>

  </DIV>
</DIV>

<DIV CLASS=REFBODY>

<P>Invoked when a new connection is established
<P>Connections may either be established by an explicit call to
         megaco:connect/4 or implicitely at the first invokaction of
         megaco:receive_message/3.
<P>Normally a Media Gateway (MG) connects explicitly while a Media
         Gateway Controller (MGC) connects implicitly.
<P>At the Media Gateway Controller (MGC) side it is possible to reject
         a connection request (and send a message error reply to the gateway)
         by returning <CODE>{error, ErrorDescr}</CODE> or simply <CODE>error</CODE> which
         generates an error descriptor with code 402 (unauthorized) and 
         reason &#34;Connection refused by user&#34; (this is also the case for all 
         unknown results, such as exit signals or throw).<A NAME="disconnect"><!-- Empty --></A>
</DIV>

<P><A NAME="handle_disconnect/3"><STRONG><CODE>handle_disconnect(ConnHandle, ProtocolVersion, Reason) -&#62; ok</CODE></STRONG></A><BR>

<DIV CLASS=REFBODY><P>Types:
  <DIV CLASS=REFTYPES>
<P>
<STRONG><CODE>ConnHandle = conn_handle()</CODE></STRONG><BR>
<STRONG><CODE>ProtocolVersion = protocol_version()</CODE></STRONG><BR>
<STRONG><CODE>Reason = term()</CODE></STRONG><BR>

  </DIV>
</DIV>

<DIV CLASS=REFBODY>

<P>Invoked when a connection is teared down
<P>The disconnect may either be made explicitely by a call to
         megaco:disconnect/2 or implicitely when the control process
         of the connection dies.<A NAME="syntax_error"><!-- Empty --></A>
</DIV>

<P><A NAME="handle_syntax_error/3"><STRONG><CODE>handle_syntax_error(ReceiveHandle, ProtocolVersion, DefaultED) -&#62; reply | {reply,ED} | no_reply | {no_reply,ED} </CODE></STRONG></A><BR>

<DIV CLASS=REFBODY><P>Types:
  <DIV CLASS=REFTYPES>
<P>
<STRONG><CODE>ReceiveHandle = receive_handle()</CODE></STRONG><BR>
<STRONG><CODE>receive_handle() = #megaco_receive_handle{}</CODE></STRONG><BR>
<STRONG><CODE>ProtocolVersion = protocol_version()</CODE></STRONG><BR>
<STRONG><CODE>DefaultED = error_descr()</CODE></STRONG><BR>
<STRONG><CODE>ED = error_descr()</CODE></STRONG><BR>

  </DIV>
</DIV>

<DIV CLASS=REFBODY>

<P>Invoked when a received message had syntax errors
<P>Incoming messages is delivered by megaco:receive_message/4
         and normally decoded successfully. But if the decoding
         failed this function is called in order to decide if the
         originator should get a reply message (reply) or if the reply
         silently should be discarded (no_reply).
<P>Syntax errors are detected locally on this side of the
         protocol and may have many causes, e.g. a malfunctioning
         transport layer, wrong encoder/decoder selected, bad
         configuration of the selected encoder/decoder etc.
<P>The error descriptor defaults to <CODE>DefaultED</CODE>,
         but can be overridden with an alternate one by
         returning <CODE>{reply,ED}</CODE> or <CODE>{no_reply,ED}</CODE>
         instead of <CODE>reply</CODE> and <CODE>no_reply</CODE> respectively.

        
<P>Any other return values (including exit signals or throw) and the
         <CODE>DefaultED</CODE> will be used.
         
<A NAME="message_error"><!-- Empty --></A> 

</DIV>

<P><A NAME="handle_message_error/3"><STRONG><CODE>handle_message_error(ConnHandle, ProtocolVersion, ErrorDescr) -&#62; ok</CODE></STRONG></A><BR>

<DIV CLASS=REFBODY><P>Types:
  <DIV CLASS=REFTYPES>
<P>
<STRONG><CODE>ConnHandle = conn_handle()</CODE></STRONG><BR>
<STRONG><CODE>ProtocolVersion = protocol_version()</CODE></STRONG><BR>
<STRONG><CODE>ErrorDescr = error_descr()</CODE></STRONG><BR>

  </DIV>
</DIV>

<DIV CLASS=REFBODY>

<P>Invoked when a received message just contains an error
         instead of a list of transactions.
<P>Incoming messages is delivered by megaco:receive_message/4
         and successfully decoded. Normally a message contains a list
         of transactions, but it may instead contain an
         ErrorDescriptor on top level of the message.
<P>Message errors are detected remotely on the other side of
         the protocol. And you probably don't want to reply to it,
         but it may indicate that you have outstanding transactions
         that not will get any response (request -&#62; reply; reply -&#62;
         ack).<A NAME="trans_request"><!-- Empty --></A>
</DIV>

<P><A NAME="handle_trans_request/3"><STRONG><CODE>handle_trans_request(ConnHandle, ProtocolVersion, ActionRequests) -&#62; pending() | reply() | ignore_trans_request</CODE></STRONG></A><BR>

<DIV CLASS=REFBODY><P>Types:
  <DIV CLASS=REFTYPES>
<P>
<STRONG><CODE>ConnHandle = conn_handle()</CODE></STRONG><BR>
<STRONG><CODE>ProtocolVersion = protocol_version()</CODE></STRONG><BR>
<STRONG><CODE>ActionRequests = [#'ActionRequest'{}]</CODE></STRONG><BR>
<STRONG><CODE>pending() = {pending, req_data()}</CODE></STRONG><BR>
<STRONG><CODE>req_data() = term()</CODE></STRONG><BR>
<STRONG><CODE>reply() = {ack_action(), actual_reply()} | {ack_action(), actual_reply(), send_options()} </CODE></STRONG><BR>
<STRONG><CODE>ack_action() = discard_ack | {handle_ack, ack_data()} | {handle_pending_ack, ack_data()} | {handle_sloppy_ack, ack_data()}</CODE></STRONG><BR>
<STRONG><CODE>actual_reply() = [#'ActionReply'{}] | error_descr()</CODE></STRONG><BR>
<STRONG><CODE>ack_data() = term()</CODE></STRONG><BR>
<STRONG><CODE>send_options() = [send_option()]</CODE></STRONG><BR>
<STRONG><CODE>send_option() = {reply_timer, megaco_timer()} | {send_handle, term()} | {protocol_version, integer()}</CODE></STRONG><BR>

  </DIV>
</DIV>

<DIV CLASS=REFBODY>

<P>Invoked for each transaction request
<P>Incoming messages is delivered by megaco:receive_message/4
         and successfully decoded. Normally a message contains a list
         of transactions and this function is invoked for each
         TransactionRequest in the message.
<P>This function takes a list of 'ActionRequest' records and
         has three main options:
<P>
<DL>

<DT>
<CODE>Return ignore_trans_request</CODE>
</DT>

<DD>
         Decide that these action requests shall be ignored
         completely.<BR>

         
</DD>

<DT>
<CODE>Return pending()</CODE>
</DT>

<DD>
         Decide that the processing of these action requests
         will take a long time and that the originator should get
         an immediate 'TransactionPending' reply as interim
         response. The actual processing of these action requests
         instead should be delegated to the the
         handle_trans_long_request/3 callback function with the
         req_data() as one of its arguments. <BR>

         
</DD>

<DT>
<CODE>Return reply()</CODE>
</DT>

<DD>
         Process the action requests and either return an
         error_descr() indicating some fatal error or a list of
         action replies (wildcarded or not). <BR>


         If for some reason megaco is unable to deliver the reply,
the reason for this will be passed to the user via a call
to the callback function 
<A HREF="#trans_ack">handle_trans_ack</A>,
unless <CODE>ack_action() = discard_ack</CODE>. <BR>


         The ack_action() is either:
         <BR>

<DL>

<DT>
<CODE>discard_ack</CODE>
</DT>

<DD>
                Meaning that you don't care if the reply is
                 acknowledged or not.<BR>

         
</DD>

<DT>
<CODE>{handle_ack, ack_data()} | {handle_ack, ack_data(), send_options()}</CODE>
</DT>

<DD>
                Meaning that you want an immediate acknowledgement
                 when the other part receives this transaction
                 reply. When the acknowledgement eventually is
                 received, the handle_trans_ack/4 callback function
                 will be invoked with the ack_data() as one of its
                 arguments. ack_data() may be any Erlang term.<BR>

                
</DD>

<DT>
<CODE>{handle_pending_ack, ack_data()} | {handle_pending_ack, ack_data(), send_options()}</CODE>
</DT>

<DD>
                This has the same effect as the above, 
<STRONG>if and only if</STRONG> megaco has sent atleast one 
pending message for this request (during the processing
of the request). If no pending message has been sent, then 
immediate acknowledgement will <STRONG>not</STRONG> be 
requested. <BR>

Note that this only works as specified if the 
<CODE>sent_pending_limit</CODE> config option has been set to 
an integer value. <BR>


</DD>

<DT>
<CODE>{handle_sloppy_ack, ack_data()}| {handle_sloppy_ack, ack_data(), send_options()}</CODE>
</DT>

<DD>
                Meaning that you want an acknowledgement <STRONG>sometime</STRONG>.
When the acknowledgement eventually is received, the 
handle_trans_ack/4 callback function will be invoked with 
the ack_data() as one of its arguments. ack_data() may be 
any Erlang term.<BR>

                
</DD>

</DL>

         
</DD>

</DL>

<P>Any other return values (including exit signals or throw) will 
         result in an error descriptor with code 500 (internal gateway error) 
         and the module name (of the callback module) as reason.
         

<A NAME="trans_long_request"><!-- Empty --></A> 

</DIV>

<P><A NAME="handle_trans_long_request/3"><STRONG><CODE>handle_trans_long_request(ConnHandle, ProtocolVersion, ReqData) -&#62; reply()</CODE></STRONG></A><BR>

<DIV CLASS=REFBODY><P>Types:
  <DIV CLASS=REFTYPES>
<P>
<STRONG><CODE>ConnHandle = conn_handle()</CODE></STRONG><BR>
<STRONG><CODE>ProtocolVersion = protocol_version()</CODE></STRONG><BR>
<STRONG><CODE>ReqData = req_data()</CODE></STRONG><BR>
<STRONG><CODE>req_data() = term()</CODE></STRONG><BR>
<STRONG><CODE>reply() = {ack_action(), actual_reply()} | {ack_action(), actual_reply(), send_options()}</CODE></STRONG><BR>
<STRONG><CODE>ack_action() = discard_ack | {handle_ack, ack_data()} | {handle_sloppy_ack, ack_data()}</CODE></STRONG><BR>
<STRONG><CODE>actual_reply() = [#'ActionReply'{}] | error_descr()</CODE></STRONG><BR>
<STRONG><CODE>ack_data() = term()</CODE></STRONG><BR>
<STRONG><CODE>send_options() = [send_option()]</CODE></STRONG><BR>
<STRONG><CODE>send_option() = {reply_timer, megaco_timer()} | {send_handle, term()} | {protocol_version, integer()}</CODE></STRONG><BR>

  </DIV>
</DIV>

<DIV CLASS=REFBODY>

<P>Optionally invoked for a time consuming transaction request
<P>If this function gets invoked or not is controlled by the
         reply from the preceeding call to handle_trans_request/3.
         The handle_trans_request/3 function may decide to process
         the action requests itself or to delegate the processing to
         this function.
<P>The req_data() argument to this function is the Erlang term
         returned by handle_trans_request/3.
<P>
        
<P>Any other return values (including exit signals or throw) will 
         result in an error descriptor with code 500 (internal gateway error)
         and the module name (of the callback module) as reason.
         
<A NAME="trans_reply"><!-- Empty --></A> 

</DIV>

<P><A NAME="handle_trans_reply/4"><STRONG><CODE>handle_trans_reply(ConnHandle, ProtocolVersion, UserReply, ReplyData) -&#62; ok</CODE></STRONG></A><BR>

<DIV CLASS=REFBODY><P>Types:
  <DIV CLASS=REFTYPES>
<P>
<STRONG><CODE>ConnHandle = conn_handle()</CODE></STRONG><BR>
<STRONG><CODE>ProtocolVersion = protocol_version()</CODE></STRONG><BR>
<STRONG><CODE>UserReply = success() | failure()</CODE></STRONG><BR>
<STRONG><CODE>success() = {ok, [#'ActionReply'{}]}</CODE></STRONG><BR>
<STRONG><CODE>failure() = message_error() | user_cancel_error() | send_error() | other_error()</CODE></STRONG><BR>
<STRONG><CODE>message_error() = {error, error_descr()}</CODE></STRONG><BR>
<STRONG><CODE>user_cancel_error() = {error, user_cancel_reason()}</CODE></STRONG><BR>
<STRONG><CODE>user_cancel_reason() = {user_cancel, reason_for_user_cancel()}</CODE></STRONG><BR>
<STRONG><CODE>reason_for_user_cancel() = term()</CODE></STRONG><BR>
<STRONG><CODE>send_error() = {error, send_reason()}</CODE></STRONG><BR>
<STRONG><CODE>send_reason() = send_cancelled_reason() | send_failed_reason()</CODE></STRONG><BR>
<STRONG><CODE>send_cancelled_reason() = {send_message_cancelled, reason_for_send_cancel()}</CODE></STRONG><BR>
<STRONG><CODE>reason_for_send_cancel() = term()</CODE></STRONG><BR>
<STRONG><CODE>send_failed_reason() = {send_message_failed, reason_for_send_failure()}</CODE></STRONG><BR>
<STRONG><CODE>reason_for_send_failure() = term()</CODE></STRONG><BR>
<STRONG><CODE>other_error() = {error, other_reason()}</CODE></STRONG><BR>
<STRONG><CODE>other_reason() = term()</CODE></STRONG><BR>
<STRONG><CODE>ReplyData = reply_data()</CODE></STRONG><BR>
<STRONG><CODE>reply_data() = term()</CODE></STRONG><BR>

  </DIV>
</DIV>

<DIV CLASS=REFBODY>

<P>Optionally invoked for a transaction reply
<P>The sender of a transaction request has the option of
         deciding, whether the originating Erlang process should
         synchronously wait (megaco:call/3) for a reply or if the
         message should be sent asynchronously (megaco:cast/3) and
         the processing of the reply should be delegated this
         callback function.
<P>The ReplyData defaults to megaco:lookup(ConnHandle,
         reply_data), but may be explicitely overridden by a
         megaco:cast/3 option in order to forward info about the
         calling context of the originating process.
<P>At success(), the UserReply contains a list of 'ActionReply'
         records possibly containing error indications.
<P>A message_error(), indicates that the remote user has
         replied with an explicit transactionError.
<P>A <CODE>user_cancel_error()</CODE>, indicates that the request has been
canceled by the user. <CODE>reason_for_user_cancel()</CODE> is the reason
given in the call to the <A HREF="#cancel">cancel</A>
function. 
<P>A <CODE>send_error()</CODE>, indicates that the send function of the 
megaco transport callback module failed to send the request. 
There are two separate cases: <CODE>send_cancelled_reason()</CODE> and 
<CODE>send_failed_reason()</CODE>. 
The first is the result of the send function returning 
<CODE>{cancel, Reason}</CODE> and the second is some other kind of 
erroneous return value. See the 
<A HREF="megaco_transport.html#send_message">send_message</A>
function for more info. 
<P> An other_error(), indicates some other error such as timeout. <A NAME="trans_ack"><!-- Empty --></A>
</DIV>

<P><A NAME="handle_trans_ack/4"><STRONG><CODE>handle_trans_ack(ConnHandle, ProtocolVersion, AckStatus, AckData) -&#62; ok</CODE></STRONG></A><BR>

<DIV CLASS=REFBODY><P>Types:
  <DIV CLASS=REFTYPES>
<P>
<STRONG><CODE>ConnHandle = conn_handle()</CODE></STRONG><BR>
<STRONG><CODE>ProtocolVersion = protocol_version()</CODE></STRONG><BR>
<STRONG><CODE>AckStatus = ok | user_cancel() | send_error() | other_error()</CODE></STRONG><BR>
<STRONG><CODE>user_cancel() = {error, user_cancel_reason()}</CODE></STRONG><BR>
<STRONG><CODE>user_cancel_reason() = {user_cancel, reason_for_user_cancel()}</CODE></STRONG><BR>
<STRONG><CODE>send_error() = {error, send_reason()}</CODE></STRONG><BR>
<STRONG><CODE>send_reason() = send_cancelled_reason() | send_failed_reason()</CODE></STRONG><BR>
<STRONG><CODE>send_cancelled_reason() = {send_message_cancelled, reason_for_send_cancel()}</CODE></STRONG><BR>
<STRONG><CODE>reason_for_send_cancel() = term()</CODE></STRONG><BR>
<STRONG><CODE>send_failed_reason() = {send_message_failed, reason_for_send_failure()}</CODE></STRONG><BR>
<STRONG><CODE>reason_for_send_failure() = term()</CODE></STRONG><BR>
<STRONG><CODE>other_error() = {error, other_reason()}</CODE></STRONG><BR>
<STRONG><CODE>other_reason() = term()</CODE></STRONG><BR>
<STRONG><CODE>AckData = ack_data()</CODE></STRONG><BR>
<STRONG><CODE>ack_data() = term()</CODE></STRONG><BR>

  </DIV>
</DIV>

<DIV CLASS=REFBODY>

<P>Optionally invoked for a transaction acknowledgement
<P>If this function gets invoked or not, is controlled by the
         reply from the preceeding call to handle_trans_request/3.
         The handle_trans_request/3 function may decide to return
         {handle_ack, ack_data()} or {handle_sloppy_ack, ack_data()} 
meaning that you need an immediate acknowledgement of the 
reply and that this function should be invoked to handle the 
acknowledgement.
<P>The ack_data() argument to this function is the Erlang term
         returned by handle_trans_request/3.
<P>
        
<P>If the AckStatus is ok, it is indicating that this is a
         true acknowledgement of the transaction reply.
<P>If the AckStatus is {error, Reason}, it is an indication that the
         acknowledgement or even the reply (for which this is an 
acknowledgement) was not delivered, but there is no point in
         waiting any longer for it to arrive. This happens when: 
<P>
<DL>

<DT>
<CODE>reply_timer</CODE>
</DT>

<DD>
 The <CODE>reply_timer</CODE> eventually times out.<BR>

         
</DD>

<DT>
reply send failure
</DT>

<DD>
 When megaco failes to send the reply (see 
<A HREF="#trans_reply">handle_trans_reply</A>), 
for whatever reason. <BR>

         
</DD>

<DT>
cancel
</DT>

<DD>
 The user has explicitly cancelled the wait 
(megaco:cancel/2).<BR>

         
</DD>

</DL>
<A NAME="unexpected_trans"><!-- Empty --></A><A NAME="handle_unexpected_trans"><!-- Empty --></A>
</DIV>

<P><A NAME="handle_unexpected_trans/3"><STRONG><CODE>handle_unexpected_trans(ReceiveHandle, ProtocolVersion, Trans) -&#62; ok</CODE></STRONG></A><BR>

<DIV CLASS=REFBODY><P>Types:
  <DIV CLASS=REFTYPES>
<P>
<STRONG><CODE>ReceiveHandle = receive_handle()</CODE></STRONG><BR>
<STRONG><CODE>receive_handle() = #megaco_receive_handle{}</CODE></STRONG><BR>
<STRONG><CODE>ProtocolVersion = protocol_version()</CODE></STRONG><BR>
<STRONG><CODE>Trans = 'TransactionPending' | 'TransactionReply' | 'TransactionResponseAck'</CODE></STRONG><BR>

  </DIV>
</DIV>

<DIV CLASS=REFBODY>

<P>Invoked when a unexpected message is received
<P>If a reply to a request is not received in time, the
         megaco stack removes all info about the request from
         it's tables. If a reply should arrive after this has been
         done the app has no way of knowing where to send this message.
         The message is delivered to the &#34;user&#34; by calling this
         function on the local node (the node which has the link).<A NAME="request_abort"><!-- Empty --></A>
</DIV>

<P><A NAME="handle_trans_request_abort/4"><STRONG><CODE>handle_trans_request_abort(ReceiveHandle, ProtocolVersion, TransNo, Pid) -&#62; ok</CODE></STRONG></A><BR>

<DIV CLASS=REFBODY><P>Types:
  <DIV CLASS=REFTYPES>
<P>
<STRONG><CODE>ReceiveHandle = receive_handle()</CODE></STRONG><BR>
<STRONG><CODE>receive_handle() = #megaco_receive_handle{}</CODE></STRONG><BR>
<STRONG><CODE>ProtocolVersion = protocol_version()</CODE></STRONG><BR>
<STRONG><CODE>TransNo = integer()</CODE></STRONG><BR>
<STRONG><CODE>Pid = undefined | pid()</CODE></STRONG><BR>

  </DIV>
</DIV>

<DIV CLASS=REFBODY>

<P>Invoked when a transaction request has been aborted
<P>This function is invoked if the originating pending limit
         has been exceeded. This usually means that a request has taken 
         abnormally long time to complete.
</DIV>

<H3>AUTHORS</H3>
<DIV CLASS=REFBODY>
Hkan Mattsson - support@erlang.ericsson.se<BR>

</DIV>
<CENTER>
<HR>
<SMALL>megaco 3.5<BR>
Copyright &copy; 1991-2006
<A HREF="http://www.erlang.se">Ericsson AB</A><BR>
</SMALL>
</CENTER>
</BODY>
</HTML>