File 2048-megaco-doc-megaco-conn_info-2-cleanup.patch of Package erlang

Overview Repositories Revisions Requests Users Attributes Meta

File 2048-megaco-doc-megaco-conn_info-2-cleanup.patch of Package erlang (Revision a95c38533dd94a5c195230b3b146d029)

Currently displaying revision a95c38533dd94a5c195230b3b146d029 , Show latest

From 80580033e8a23b38306bb9f7959526e337a20384 Mon Sep 17 00:00:00 2001
From: Micael Karlberg <bmk@erlang.org>
Date: Mon, 8 Jan 2024 10:22:16 +0100
Subject: [PATCH 38/46] [megaco|doc] megaco:conn_info/2 cleanup

OTP-18920
---
 lib/megaco/doc/src/megaco.xml | 484 ----------------------------------
 1 file changed, 484 deletions(-)

diff --git a/lib/megaco/doc/src/megaco.xml b/lib/megaco/doc/src/megaco.xml
index 178db93483..74c5c7b309 100644
--- a/lib/megaco/doc/src/megaco.xml
+++ b/lib/megaco/doc/src/megaco.xml
@@ -2460,490 +2460,6 @@ megaco_incr_timer() = #megaco_incr_timer{}
 Lookup information about an active connection
 Requires that the connection is active.
 
-	<marker id="ci_control_pid"></marker>
- <taglist>
- <tag><c><![CDATA[control_pid]]></c></tag>
- <item>
- The process identifier of the controlling process for a
- connection.
-
- <marker id="ci_send_handle"></marker>
- </item>
-
- <tag><c><![CDATA[send_handle]]></c></tag>
- <item>
- Opaque send handle whose contents is internal for the
- send module. May be any term.
-
- <marker id="ci_local_mid"></marker>
- </item>
-
- <tag><c><![CDATA[local_mid]]></c></tag>
- <item>
- The local mid (of the connection, i.e. the own mid). 
- <c><![CDATA[megaco_mid()]]></c>.
-
- <marker id="ci_remote_mid"></marker>
- </item>
-
- <tag><c><![CDATA[remote_mid]]></c></tag>
- <item>
- The remote mid (of the connection). 
- <c><![CDATA[megaco_mid()]]></c>.
-
- <marker id="ci_receive_handle"></marker>
- </item>
-
- <tag><c><![CDATA[receive_handle]]></c></tag>
- <item>
- Construct a megaco_receive_handle record.
-
- <marker id="ci_trans_id"></marker>
- </item>
-
- <tag><c><![CDATA[trans_id]]></c></tag>
- <item>
- Next transaction id. A positive integer or the atom 
- <c><![CDATA[undefined_serial]]></c> (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). 
-
- <marker id="ci_max_trans_id"></marker>
- </item>
-
- <tag><c><![CDATA[max_trans_id]]></c></tag>
- <item>
- Last trans id. 
- A positive integer or <c><![CDATA[infinity]]></c>, 
- defaults to <c><![CDATA[infinity]]></c>.
-
- <marker id="ci_request_timer"></marker>
- </item>
-
- <tag><c><![CDATA[request_timer]]></c></tag>
- <item>
- Wait for reply. 
- The timer is cancelled when a reply is received. 
- When a pending message is received, the timer is 
- cancelled and the <c><![CDATA[long_request_timer]]></c> 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 
- <c><![CDATA[megaco:call]]></c> will return with <c><![CDATA[{error, timeout}]]></c>
- or the callback function <c><![CDATA[handle_trans_reply]]></c> will be 
- called with <c><![CDATA[UserReply = {error, timeout}]]></c> (if 
- <c><![CDATA[megaco:cast]]></c> was used).
- A Megaco Timer (see explanation above), 
- defaults to #megaco_incr_timer{}.
-
- <marker id="ci_long_request_timer"></marker>
- </item>
-
- <tag><c><![CDATA[long_request_timer]]></c></tag>
- <item>
- 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 
- <c><![CDATA[long_request_timer]]></c> 
- is not "on its final leg", the timer will be 
- restarted, and, if <c><![CDATA[long_request_resend = true]]></c>, the
- request will be re-sent. 
- A Megaco Timer (see explanation above), 
- defaults to <c><![CDATA[60 seconds]]></c>.
-
- <marker id="ci_request_keep_alive_timeout"></marker>
- </item>
-
- <tag><c><![CDATA[request_keep_alive_timeout]]></c></tag>
- <item>
- 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 
- <seeerl marker="megaco#cast">megaco:cast/3</seeerl> function)
- arrives. As long as this timer is running, replies will 
- be delivered via the 
- <seeerl marker="megaco_user#trans_reply">handle_trans_reply/4,5</seeerl> 
- callback function, with their "arrival number" 
- (see <c><![CDATA[UserReply]]></c> of the 
- <seeerl marker="megaco_user#trans_reply">handle_trans_reply/4,5</seeerl> 
- callback function). 
- Replies arriving after the timer has expired, will be 
- delivered using the 
- <seeerl marker="megaco_user#unexpected_trans">handle_unexpected_trans/3,4</seeerl> 
- callback function. 
- The timeout time can have the values: 
- <c><![CDATA[plain | integer() >= 0]]></c>. 
- Defaults to <c><![CDATA[plain]]></c>.
-
- <marker id="ci_long_request_resend"></marker>
- </item>
-
- <tag><c><![CDATA[long_request_resend]]></c></tag>
- <item>
- 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 <c><![CDATA[long_request_timer]]></c> (see above) is also set
- to an incremental timer (<c><![CDATA[#megaco_incr_timer{}]]></c>). 
- A <c><![CDATA[boolean]]></c>, 
- defaults to <c><![CDATA[false]]></c>.
-
- <marker id="ci_reply_timer"></marker>
- </item>
-
- <tag><c><![CDATA[reply_timer]]></c></tag>
- <item>
- 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 <c><![CDATA[#megaco_incr_timer{}]]></c>, 
- 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.
-
- <marker id="ci_call_proxy_gc_timeout"></marker>
- </item>
-
- <tag><c><![CDATA[call_proxy_gc_timeout]]></c></tag>
- <item>
- Timeout time for the call proxy. 
- When a request is sent using the 
- <seeerl marker="megaco#call">call/3</seeerl> 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 
- <seeerl marker="megaco_user#handle_unexpected_trans">handle_unexpected_trans</seeerl> 
- 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).
- <marker id="ci_auto_ack"></marker>
- </item>
-
- <tag><c><![CDATA[auto_ack]]></c></tag>
- <item>
- Automatic send transaction ack when the transaction
- reply has been received (see <c><![CDATA[trans_ack]]></c> below). 
- This is used for three-way-handshake. 
- A <c><![CDATA[boolean]]></c>, defaults to <c><![CDATA[false]]></c>.
-
- <marker id="ci_trans_ack"></marker>
- </item>
-
- <tag><c><![CDATA[trans_ack]]></c></tag>
- <item>
- Shall ack's be accumulated or not. 
- This property is only valid if <c><![CDATA[auto_ack]]></c> is true. 
- If <c><![CDATA[auto_ack]]></c> is true, then if <c><![CDATA[trans_ack]]></c> is
- <c><![CDATA[false]]></c>, ack's will be sent immediately. 
- If <c><![CDATA[trans_ack]]></c> is
- <c><![CDATA[true]]></c>, then ack's will instead be sent to the transaction 
- sender process for accumulation and later sending 
- (see <c><![CDATA[trans_ack_maxcount]]></c>, <c><![CDATA[trans_req_maxcount]]></c>, 
- <c><![CDATA[trans_req_maxsize]]></c>, <c><![CDATA[trans_ack_maxcount]]></c> and 
- <c><![CDATA[trans_timer]]></c>). 
- See also <seeguide marker="megaco_run#transaction_sender">transaction sender</seeguide> for more info. 
- An <c><![CDATA[boolean]]></c>, defaults to <c><![CDATA[false]]></c>.
-
- <marker id="ci_trans_ack_maxcount"></marker>
- </item>
-
- <tag><c><![CDATA[trans_ack_maxcount]]></c></tag>
- <item>
- 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 <seeguide marker="megaco_run#transaction_sender">transaction sender</seeguide> for more info.
- An integer, defaults to 10.
-
- <marker id="ci_trans_req"></marker>
- </item>
-
- <tag><c><![CDATA[trans_req]]></c></tag>
- <item>
- Shall requests be accumulated or not. 
- If <c><![CDATA[trans_req]]></c> is <c><![CDATA[false]]></c>, then request(s)
- will be sent immediately (in its own message). 
- If <c><![CDATA[trans_req]]></c> is true, then request(s) will 
- instead be sent to the transaction sender process for 
- accumulation and later sending 
- (see <c><![CDATA[trans_ack_maxcount]]></c>, <c><![CDATA[trans_req_maxcount]]></c>, 
- <c><![CDATA[trans_req_maxsize]]></c>, <c><![CDATA[trans_ack_maxcount]]></c> and 
- <c><![CDATA[trans_timer]]></c>). 
- See also <seeguide marker="megaco_run#transaction_sender">transaction sender</seeguide> for more info. 
- An <c><![CDATA[boolean]]></c>, defaults to <c><![CDATA[false]]></c>.
-
- <marker id="ci_trans_req_maxcount"></marker>
- </item>
-
- <tag><c><![CDATA[trans_req_maxcount]]></c></tag>
- <item>
- 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 <seeguide marker="megaco_run#transaction_sender">transaction sender</seeguide> for more info. 
- An <c><![CDATA[integer]]></c>, defaults to 10.
-
- <marker id="ci_trans_req_maxsize"></marker>
- </item>
-
- <tag><c><![CDATA[trans_req_maxsize]]></c></tag>
- <item>
- 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 <seeguide marker="megaco_run#transaction_sender">transaction sender</seeguide> for more info. 
- An <c><![CDATA[integer]]></c>, defaults to 2048.
-
- <marker id="ci_trans_timer"></marker>
- </item>
-
- <tag><c><![CDATA[trans_timer]]></c></tag>
- <item>
- 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 <c><![CDATA[auto_ack]]></c> 
- and <c><![CDATA[trans_ack]]></c> is true or if <c><![CDATA[trans_req]]></c> is true, 
- then transaction sender will be started and transactions 
- (which is depending on the values of <c><![CDATA[auto_ack]]></c>, 
- <c><![CDATA[trans_ack]]></c> and <c><![CDATA[trans_req]]></c>) will be accumulated,
- for later sending. 
- See also <seeguide marker="megaco_run#transaction_sender">transaction sender</seeguide> for more info. 
- An <c><![CDATA[integer]]></c>, defaults to 0.
-
- <marker id="ci_pending_timer"></marker>
- </item>
-
- <tag><c><![CDATA[pending_timer]]></c></tag>
- <item>
- 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.
-
- <marker id="ci_sent_pending_limit"></marker>
- </item>
-
- <tag><c><![CDATA[sent_pending_limit]]></c></tag>
- <item>
- 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 <seeerl marker="megaco_user#request_abort">handle_trans_request_abort</seeerl>) 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 <c><![CDATA[infinity]]></c>, 
- defaults to <c><![CDATA[infinity]]></c>.
-
- <marker id="ci_recv_pending_limit"></marker>
- </item>
-
- <tag><c><![CDATA[recv_pending_limit]]></c></tag>
- <item>
- 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 <c><![CDATA[infinity]]></c>, 
- defaults to <c><![CDATA[infinity]]></c>.
-
- <marker id="ci_send_mod"></marker>
- </item>
-
- <tag><c><![CDATA[send_mod]]></c></tag>
- <item>
- 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 <c><![CDATA[atom]]></c>, defaults to <c><![CDATA[megaco_tcp]]></c>.
-
- <marker id="ci_encoding_mod"></marker>
- </item>
-
- <tag><c><![CDATA[encoding_mod]]></c></tag>
- <item>
- 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 <c><![CDATA[atom]]></c>, 
- defaults to <c><![CDATA[megaco_pretty_text_encoder]]></c>.
-
- <marker id="ci_encoding_confi"></marker>
- </item>
-
- <tag><c><![CDATA[encoding_config]]></c></tag>
- <item>
- Encoding module config. 
- A <c><![CDATA[list]]></c>, defaults to [].
-
- <marker id="ci_protocol_version"></marker>
- </item>
-
- <tag><c><![CDATA[protocol_version]]></c></tag>
- <item>
- Actual protocol version. 
- An positive integer, Current default is 1.
- <marker id="ci_strict_version"></marker>
- </item>
- <tag><c><![CDATA[strict_version]]></c></tag>
- <item>
- Strict version control, i.e. when a message is received,
- verify that the version is that which was negotiated. 
- An <c><![CDATA[boolean]]></c>, default is true.
- <marker id="ci_reply_data"></marker>
- </item>
- <tag><c><![CDATA[reply_data]]></c></tag>
- <item>
- Default reply data. 
- Any term, defaults to the atom <c><![CDATA[undefined]]></c>.
-
- <marker id="ci_threaded"></marker>
- </item>
-
- <tag><c><![CDATA[threaded]]></c></tag>
- <item>
- If a received message contains several transaction requests, 
- this option indicates whether the requests should be handled
- sequentially in the same process (<c><![CDATA[false]]></c>), or if each 
- request should be handled by its own process (<c><![CDATA[true]]></c>
- i.e. a separate process is spawned for each request). 
- An <c><![CDATA[boolean]]></c>, defaults to <c><![CDATA[false]]></c>. 
- <marker id="ci_resend_indication"></marker>
- </item>
- <tag><c><![CDATA[resend_indication]]></c></tag>
- <item>
- 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
- <seeerl marker="megaco_transport#send_message">send_message/2</seeerl> 
- function. 
- If true, megaco message re-sends are made using the
- <seeerl marker="megaco_transport#resend_message">resend_message</seeerl> 
- function. The initial message send is still done using the
- <seeerl marker="megaco_transport#send_message">send_message</seeerl> 
- function. 
- The special value flag instead indicates that the 
- function 
- <seeerl marker="megaco_transport#send_message">send_message/3</seeerl> 
- shall be used. 
- A <c>resend_indication()</c>, 
- defaults to <c><![CDATA[false]]></c>.
- <marker id="ci_segment_reply_ind"></marker>
- </item>
-
- <tag><c><![CDATA[segment_reply_ind]]></c></tag>
- <item>
- This option specifies if the user shall be notified of received
- segment replies or not. 
- See 
- <seeerl marker="megaco_user#segment_reply">handle_segment_reply</seeerl> 
- callback function for more information. 
- A <c><![CDATA[boolean]]></c>, 
- defaults to <c><![CDATA[false]]></c>. 
-
- <marker id="ci_segment_recv_timer"></marker>
- </item>
-
- <tag><c><![CDATA[segment_recv_timer]]></c></tag>
- <item>
- This timer is started when the segment indicated by the
- <c><![CDATA[segmentation complete token]]></c> (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 
- <c><![CDATA[segment timeout]]></c> <c><![CDATA[UserReply]]></c> in either the
- <seeerl marker="megaco_user#trans_reply">handle_trans_reply</seeerl> 
- callback function or 
- the return value of the 
- <seeerl marker="megaco#call">call</seeerl> function. 
- A Megaco Timer (see explanation above),
- defaults to <c><![CDATA[10000]]></c>. 
-
- <marker id="ci_segment_send"></marker>
- </item>
-
- <tag><c><![CDATA[segment_send]]></c></tag>
- <item>
- Shall outgoing messages be segmented or not: 
- <taglist>
- <tag><c><![CDATA[none]]></c></tag>
- <item>
- 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).
- </item>
- <tag><c><![CDATA[integer() > 0]]></c></tag>
- <item>
- Outgoing reply messages will be segmented as needed 
- (see <c><![CDATA[max_pdu_size]]></c> below). This value, K, indicate 
- the outstanding window, i.e. how many segments can be 
- outstanding (not acknowledged) at any given time. 
- </item>
- <tag><c><![CDATA[infinity]]></c></tag>
- <item>
- Outgoing reply messages will be segmented as needed 
- (see <c><![CDATA[max_pdu_size]]></c> below). Segment messages 
- are sent all at once (i.e. no acknowledgement awaited 
- before sending the next segment). 
- </item>
- </taglist>
- Defaults to <c><![CDATA[none]]></c>. 
- <marker id="ci_max_pdu_size"></marker>
- </item>
-
- <tag><c><![CDATA[max_pdu_size]]></c></tag>
- <item>
- Max message size. If the encoded message (PDU) exceeds 
- this size, the message should be segmented, and then 
- encoded. 
- A positive integer or <c><![CDATA[infinity]]></c>,
- defaults to <c><![CDATA[infinity]]></c>. 
- </item>
-
-	</taglist>
-
 	Failure: <c>exit</c> if, for instance,
 	<c><anno>ConnHandle</anno></c> refers to a connection
 	that no longer exists.
-- 
2.35.3

Places

File 2048-megaco-doc-megaco-conn_info-2-cleanup.patch of Package erlang (Revision a95c38533dd94a5c195230b3b146d029)

Places