Interface module for the Megaco application
start() -> ok | {error, Reason}
Reason = term()
Starts the Megaco application
Users may either explicitly be registered with megaco:start_user/2 and/or be statically 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}
stop
Reason = term()
Stops the Megaco application
start_user(UserMid, Config) -> ok | {error, Reason}
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}
UserMid = megaco_mid()
Reason = term()
user_info(UserMid, Item) -> Value | exit(Reason)
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
receive_handle
min_trans_id
max_trans_id
request_timer
long_request_timer
auto_ack
pending_timer
reply_timer
send_mod
encoding_mod
encoding_config
protocol_version
reply_data
user_mod
user_args
A Timer may be:
infinity
Integer
IncrTimer
update_user_info(UserMid, Item, Value) -> ok | {error, Reason}
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 | exit(Reason)
ConnHandle = #megaco_conn_handle{}
Item = conn_info_item()
Value = conn_info_value()
Reason = term()
Lookup information about an active connection
Requires that the connection is active.
control_pid
send_handle
receive_handle
min_trans_id
max_trans_id
request_timer
long_request_timer
auto_ack
pending_timer
reply_timer
send_mod
encoding_mod
encoding_config
protocol_version
reply_data
A Timer may be:
infinity
Integer
IncrTimer
update_conn_info(ConnHandle, Item, Value) -> ok | {error, Reason}
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)
Lookup system information
The following items are valid:
scanner
connections
users
n_active_requests
n_active_replies
n_active_connections
connect(ReceiveHandle, RemoteMid, SendHandle, ControlPid) -> {ok, ConnHandle} | {error, Reason}
ReceiveHandle = #megaco_receive_handle{}
RemoteMid = preliminary_mid | megaco_mid()
SendHandle = term()
ControlPid = pid()
ConnHandle = #megaco_conn_handle{}
Reason = 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 identifier 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 callback 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 explicitely be deactivated by a local call to megaco:disconnect/2 or implicitely when the physical 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_connect/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
upgrade preliminary MID
automatic
distributed
An initial megaco_receive_handle record may be obtained with megaco:user_info(UserMid, 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.
disconnect(ConnHandle, DiscoReason) -> ok | {error, ErrReason}
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, ActionRequests, Options) -> {ProtocolVersion, UserReply}
ConnHandle = conn_handle()
ActionRequests = [#'ActionRequest'{}]
Options = [send_option()]
send_option() = {request_timer, timer()} | {long_request_timer, timer()} | {send_handle, term()}
UserReply = success() | failure()
success() = {ok, [#'ActionReply'{}]}
failure() = message_error() | other_error()
message_error() = {error, error_descr()}
other_error() = {error, term()}
Sends a transaction request and waits for a reply
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 containing error indications.
A message_error(), indicates that the remote user has replied with an explicit transactionError.
An other_error(), indicates some other error such as timeout or {user_cancel, ReasonForCancel}.
cast(ConnHandle, ActionRequests, Options) -> ok | {error, Reason}
ConnHandle = conn_handle()
ActionRequests = [#'ActionRequest'{}]
Options = [send_option()]
send_option() = {request_timer, timer()} | {long_request_timer, timer()} | {send_handle, term()} | {reply_data, reply_data()}
UserReply = success() | failure()
success() = {ok, [#'ActionReply'{}]}
failure() = message_error() | other_error()
message_error() = {error, error_descr()}
other_error() = {error, term()}
Reason = term()
Sends a transaction request but does NOT wait for a reply
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.
cancel(ConnHandle, CancelReason) -> ok | {error, ErrReason}
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
ReceiveHandle = #megaco_receive_handle{}
ControlPid = pid()
SendHandle = term()
BinMsg = binary()
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.
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
.
If the message cannot be decoded the following callback function will be invoked:
If the decoded message instead of transactions contains a message error, the following callback function will be invoked:
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 following callback function will be invoked:
For each transaction request in the decoded message the following callback function will be invoked:
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:
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 UserMod:handle_trans_request/3 indicates that the acknowledgement is important the following callback function will be invoked:
See the megaco_user module for more info about the callback arguments.
receive_message(ReceiveHandle, ControlPid, SendHandle, BinMsg) -> ok
ReceiveHandle = #megaco_receive_handle{}
ControlPid = pid()
SendHandle = term()
BinMsg = binary()
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}
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, Letters} | {error, Reason}
eval_digit_map(DigitMap, Timers) -> {ok, Letters} | {error, Reason}
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()
Letters = [letter()]
letter() = $0..$9 | $a .. $k
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 unexpected events may either be ignored or rejected. The latter means that the evaluation is aborted and an error is returned.
report_digit_event(DigitMapEvalPid, Events) -> ok | {error, Reason}
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
test_digit_event(DigitMap, Events) -> {ok, Letters} | {error, Reason}
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()
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.