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 asynchronous 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
callback function).
Replies arriving after the timer has expired, will be delivered using the handle_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 values.
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 timout, 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 immediately. If trans_ack
is true
, then ack'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_ack_maxcount
-
Maximum number of accumulated ack's. At most this many ack's will be accumulated 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 MGCOriginatedPendingLimit 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 MGCOriginatedPendingLimit 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 SendMod: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 version 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 indicates 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 timeout
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
.