Module: sip-router Branch: master Commit: 87d5961121ade01714ac9717caa9691f6b6a9e9c URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=87d59611...
Author: Daniel-Constantin Mierla miconda@gmail.com Committer: Daniel-Constantin Mierla miconda@gmail.com Date: Sun May 3 15:39:05 2009 +0200
tmx: doc updated
---
modules_k/tmx/README | 183 ++++++++++++++++++++++++++++----------- modules_k/tmx/doc/tmx_admin.xml | 41 +++++++++ 2 files changed, 175 insertions(+), 49 deletions(-)
diff --git a/modules_k/tmx/README b/modules_k/tmx/README index 8342571..83d6e37 100644 --- a/modules_k/tmx/README +++ b/modules_k/tmx/README @@ -18,57 +18,125 @@ Daniel-Constantin Mierla
1. Admin Guide
- 1.1. Overview - 1.2. Dependencies - - 1.2.1. Kamailio Modules - 1.2.2. External Libraries or Applications - - 1.3. Exported pseudo-variables - 1.4. Exported MI Functions - - 1.4.1. t_uac_dlg - 1.4.2. t_uac_cancel - 1.4.3. t_hash - 1.4.4. t_reply - - 1.5. Exported statistics - - 1.5.1. received_replies - 1.5.2. relayed_replies - 1.5.3. local_replies - 1.5.4. UAS_transactions - 1.5.5. UAC_transactions - 1.5.6. 2xx_transactions - 1.5.7. 3xx_transactions - 1.5.8. 4xx_transactions - 1.5.9. 5xx_transactions - 1.5.10. 6xx_transactions - 1.5.11. inuse_transactions + 1. Overview + 2. Dependencies + + 2.1. Kamailio Modules + 2.2. External Libraries or Applications + + 3. Exported Functions + + 3.1. t_cancel_branches(which) + + 4. Exported pseudo-variables + 5. Exported MI Functions + + 5.1. t_uac_dlg + 5.2. t_uac_cancel + 5.3. t_hash + 5.4. t_reply + + 6. Exported statistics + + 6.1. received_replies + 6.2. relayed_replies + 6.3. local_replies + 6.4. UAS_transactions + 6.5. UAC_transactions + 6.6. 2xx_transactions + 6.7. 3xx_transactions + 6.8. 4xx_transactions + 6.9. 5xx_transactions + 6.10. 6xx_transactions + 6.11. inuse_transactions + + List of Examples + + 1.1. t_cancel_branches usage
Chapter 1. Admin Guide
-1.1. Overview + Table of Contents + + 1. Overview + 2. Dependencies + + 2.1. Kamailio Modules + 2.2. External Libraries or Applications + + 3. Exported Functions + + 3.1. t_cancel_branches(which) + + 4. Exported pseudo-variables + 5. Exported MI Functions + + 5.1. t_uac_dlg + 5.2. t_uac_cancel + 5.3. t_hash + 5.4. t_reply + + 6. Exported statistics + + 6.1. received_replies + 6.2. relayed_replies + 6.3. local_replies + 6.4. UAS_transactions + 6.5. UAC_transactions + 6.6. 2xx_transactions + 6.7. 3xx_transactions + 6.8. 4xx_transactions + 6.9. 5xx_transactions + 6.10. 6xx_transactions + 6.11. inuse_transactions + +1. Overview
This module collects extensions from Kamailio TM module.
Kamailio TM (Transaction Management) module documentation is available at: http://www.kamailio.org/docs/modules/1.5.x/tm.html
-1.2. Dependencies +2. Dependencies
-1.2.1. Kamailio Modules + 2.1. Kamailio Modules + 2.2. External Libraries or Applications + +2.1. Kamailio Modules
The following modules must be loaded before this module: * tm - transaction management.
-1.2.2. External Libraries or Applications +2.2. External Libraries or Applications
The following libraries or applications must be installed before running Kamailio with this module loaded: * None.
-1.3. Exported pseudo-variables +3. Exported Functions + + 3.1. t_cancel_branches(which) + +3.1. t_cancel_branches(which) + + Cancel branches of an active SIP transaction. The function can be + called for a SIP reply that will identify the current branch. + + Parameter can be:. + * all - cancel all branches. + * others - cancel all branches but the current one. + * this - cancel current branch. + + This function can be used in ONREPLY_ROUTE. + + Example 1.1. t_cancel_branches usage +... +if (t_cancel_branches("all")) { + xlog("cancelled all branches\n"); +} +... + +4. Exported pseudo-variables
* $T_branch_idx * $T_reply_code @@ -78,9 +146,14 @@ Chapter 1. Admin Guide Exported pseudo-variables are documented at http://www.kamailio.org/dokuwiki/.
-1.4. Exported MI Functions +5. Exported MI Functions + + 5.1. t_uac_dlg + 5.2. t_uac_cancel + 5.3. t_hash + 5.4. t_reply
-1.4.1. t_uac_dlg +5.1. t_uac_dlg
Generates and sends a local SIP request.
@@ -95,7 +168,7 @@ Chapter 1. Admin Guide * body - (optional, may not be present) request body (if present, requires the "Content-Type" and "Content-length" headers)
-1.4.2. t_uac_cancel +5.2. t_uac_cancel
Generates and sends a CANCEL for an existing local SIP request.
@@ -103,14 +176,14 @@ Chapter 1. Admin Guide * callid - callid of the INVITE request to be cancelled. * cseq - cseq of the INVITE request to be cancelled.
-1.4.3. t_hash +5.3. t_hash
Gets information about the load of TM internal hash table.
Parameters: * none
-1.4.4. t_reply +5.4. t_reply
Generates and sends a reply for an existing inbound SIP transaction.
@@ -124,51 +197,63 @@ Chapter 1. Admin Guide * body - (optional, may not be present) reply body (if present, requires the "Content-Type" and "Content-length" headers)
-1.5. Exported statistics +6. Exported statistics + + 6.1. received_replies + 6.2. relayed_replies + 6.3. local_replies + 6.4. UAS_transactions + 6.5. UAC_transactions + 6.6. 2xx_transactions + 6.7. 3xx_transactions + 6.8. 4xx_transactions + 6.9. 5xx_transactions + 6.10. 6xx_transactions + 6.11. inuse_transactions
Exported statistics are listed in the next sections. All statistics except "inuse_transactions" can be reset.
-1.5.1. received_replies +6.1. received_replies
Total number of total replies received by TM module.
-1.5.2. relayed_replies +6.2. relayed_replies
Total number of replies received and relayed by TM module.
-1.5.3. local_replies +6.3. local_replies
Total number of replies local generated by TM module.
-1.5.4. UAS_transactions +6.4. UAS_transactions
Total number of transactions created by received requests.
-1.5.5. UAC_transactions +6.5. UAC_transactions
Total number of transactions created by local generated requests.
-1.5.6. 2xx_transactions +6.6. 2xx_transactions
Total number of transactions completed with 2xx replies.
-1.5.7. 3xx_transactions +6.7. 3xx_transactions
Total number of transactions completed with 3xx replies.
-1.5.8. 4xx_transactions +6.8. 4xx_transactions
Total number of transactions completed with 4xx replies.
-1.5.9. 5xx_transactions +6.9. 5xx_transactions
Total number of transactions completed with 5xx replies.
-1.5.10. 6xx_transactions +6.10. 6xx_transactions
Total number of transactions completed with 6xx replies.
-1.5.11. inuse_transactions +6.11. inuse_transactions
Number of transactions existing in memory at current time. diff --git a/modules_k/tmx/doc/tmx_admin.xml b/modules_k/tmx/doc/tmx_admin.xml index 9b0eb85..760125c 100644 --- a/modules_k/tmx/doc/tmx_admin.xml +++ b/modules_k/tmx/doc/tmx_admin.xml @@ -57,6 +57,47 @@ </section>
<section> + <title>Exported Functions</title> + <section> + <title> + <function moreinfo="none">t_cancel_branches(which)</function> + </title> + <para> + Cancel branches of an active SIP transaction. The function can be + called for a SIP reply that will identify the current branch. + </para> + <para> + Parameter can be:. + </para> + <itemizedlist> + <listitem><para> + <emphasis>all</emphasis> - cancel all branches. + </para></listitem> + <listitem><para> + <emphasis>others</emphasis> - cancel all branches but + the current one. + </para></listitem> + <listitem><para> + <emphasis>this</emphasis> - cancel current branch. + </para></listitem> + </itemizedlist> + <para> + This function can be used in ONREPLY_ROUTE. + </para> + <example> + <title><function>t_cancel_branches</function> usage</title> + <programlisting format="linespecific"> +... +if (t_cancel_branches("all")) { + xlog("cancelled all branches\n"); +} +... +</programlisting> + </example> + </section> + </section> + + <section> <title>Exported pseudo-variables</title> <itemizedlist> <listitem><para>
daniel,
what should be done with t_load_contacts()/t_next_contacts()? should they go to module_k/tmx or modules/tm? jan proposed to include them in modules/tm, but i'm not sure what the current status is.
as we have discussed before, i don't consider the current implementation of those functions a good one. the reason is the branch structure, which should be extended with information about status of branches (used/unused). it does not make sense to keep that in a separate avp.
also, in order to make things more simple to understand, i would also like to get rid of distinction of request uri and appended branches like was done in opensips.
perhaps these are already taken care of in sip-router?
-- juha
Juha,
On 03-05 16:48, Juha Heinanen wrote:
daniel,
what should be done with t_load_contacts()/t_next_contacts()? should they go to module_k/tmx or modules/tm? jan proposed to include them in modules/tm, but i'm not sure what the current status is.
I am almost done integrating your functions (from kamailio svn) into the tm module. I got interrupted by some other work, but I should have it ready tomorrow or on wednesday.
as we have discussed before, i don't consider the current implementation of those functions a good one. the reason is the branch structure, which should be extended with information about status of branches (used/unused). it does not make sense to keep that in a separate avp.
Do you mean the information which is currently stored in transactions within the tm module?
also, in order to make things more simple to understand, i would also like to get rid of distinction of request uri and appended branches like was done in opensips.
perhaps these are already taken care of in sip-router?
I don't recall any such change, so probably not.
Jan.
Jan Janak writes:
as we have discussed before, i don't consider the current implementation of those functions a good one. the reason is the branch structure, which should be extended with information about status of branches (used/unused). it does not make sense to keep that in a separate avp.
Do you mean the information which is currently stored in transactions within the tm module?
jan,
this has been discussed a few times on the lists. here is one link:
http://www.mail-archive.com/devel@openser.org/msg08849.html
-- juha
Hello,
I haven't worked on those functions -- it was in my plan if Jan haven't started, but I just saw he did some.
I tried to add in tmx module some extensions that might not be that used, trying to keep tm slimmer rather than getting it a fat pig. Anyone that wants to add to tmx, just feel free. Some of the current things in tmx may get in tm, as I am looking at tmx being the container for applications/functions on top tm.
Cheers, Daniel
On 05/03/2009 03:48 PM, Juha Heinanen wrote:
daniel,
what should be done with t_load_contacts()/t_next_contacts()? should they go to module_k/tmx or modules/tm? jan proposed to include them in modules/tm, but i'm not sure what the current status is.
as we have discussed before, i don't consider the current implementation of those functions a good one. the reason is the branch structure, which should be extended with information about status of branches (used/unused). it does not make sense to keep that in a separate avp.
also, in order to make things more simple to understand, i would also like to get rid of distinction of request uri and appended branches like was done in opensips.
perhaps these are already taken care of in sip-router?
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Juha,
On 03-05 16:48, Juha Heinanen wrote:
daniel,
what should be done with t_load_contacts()/t_next_contacts()? should they go to module_k/tmx or modules/tm? jan proposed to include them in modules/tm, but i'm not sure what the current status is.
Your serial forking functions are now in the repository. I did some adjustments, because some internals of the tm module in sip-router are slightly different than in kamailio. For example we use a different mechanism to configure timer values.
I only verified that the tm module loads after the changes, if you have a simple script that can be used to test the function then, please, send it to me (or try to test them).
Jan.
Jan Janak writes:
Your serial forking functions are now in the repository. I did some adjustments, because some internals of the tm module in sip-router are slightly different than in kamailio. For example we use a different mechanism to configure timer values.
thanks for your effort.
I only verified that the tm module loads after the changes, if you have a simple script that can be used to test the function then, please, send it to me (or try to test them).
i don't have a standalone script, but i did my own testing by registering a few twinkle users with different q values and then after lookup i call t_load_contacts and then t_next_contacts first time in route block and following times in failure route block.
i can test myself once i get that far (getting sr build and running my cfg file).
-- juha
-
Daniel-Constantin Mierla -
Jan Janak -
jh＠tutpro.com