documenting t_is_expired() function
authorMiklos Tirpak <miklos@iptel.org>
Fri, 16 Jan 2009 09:47:58 +0000 (09:47 +0000)
committerMiklos Tirpak <miklos@iptel.org>
Fri, 16 Jan 2009 09:47:58 +0000 (09:47 +0000)
modules/tm/README
modules/tm/doc/functions.xml

index ecd5b9f..d095d0b 100644 (file)
@@ -74,9 +74,10 @@ Jiri Kuthan
         1.4.23. t_any_replied() 
         1.4.24. t_grep_status("code") 
         1.4.25. t_is_canceled() 
-        1.4.26. t_relay_cancel() 
-        1.4.27. t_drop_replies() 
-        1.4.28. t_save_lumps() 
+        1.4.26. t_is_expired() 
+        1.4.27. t_relay_cancel() 
+        1.4.28. t_drop_replies() 
+        1.4.29. t_save_lumps() 
 
    1.5. TM Module API
 
@@ -1154,7 +1155,21 @@ failure_route[0]{
         }
 }
 
-1.4.26.  t_relay_cancel()
+1.4.26.  t_is_expired()
+
+   Returns true if the current transaction has already been expired, i.e.
+   the max_inv_lifetime/max_noninv_lifetime interval has already elapsed.
+
+   Example 50. t_is_expired usage
+...
+failure_route[0]{
+        if (t_is_expired()){
+                log("transaction expired\n");
+                # There is no point in adding a new branch.
+        }
+}
+
+1.4.27.  t_relay_cancel()
 
    Forwards the CANCEL if the corresponding INVITE transaction exists.
    The function is supposed to be used at the very beginning of the
@@ -1166,7 +1181,7 @@ failure_route[0]{
    CANCELs were successfully sent to the pending branches, true if the
    INVITE was not found, and false in case of any error.
 
-   Example 50. t_relay_cancel usage
+   Example 51. t_relay_cancel usage
 if (method == CANCEL) {
         if (!t_relay_cancel()) {  # implicit drop if relaying was successful,
                                   # nothing to do
@@ -1179,14 +1194,14 @@ if (method == CANCEL) {
         # do the same as for INVITEs
 }
 
-1.4.27.  t_drop_replies()
+1.4.28.  t_drop_replies()
 
    Drops all the previously received replies in failure_route block to
    make sure that none of them is picked up again. Works only if a new
    branch is added to the transaction, or it is explicitly replied in the
    script!
 
-   Example 51. t_drop_replies() usage
+   Example 52. t_drop_replies() usage
 ...
 failure_route[0]{
         if (t_check_status("5[0-9][0-9]")){
@@ -1202,7 +1217,7 @@ failure_route[0]{
         }
 }
 
-1.4.28.  t_save_lumps()
+1.4.29.  t_save_lumps()
 
    Forces the modifications of the processed SIP message to be saved in
    shared memory before t_relay() is called. The new branches which are
@@ -1217,7 +1232,7 @@ failure_route[0]{
    The transaction must be created by t_newtran() before calling
    t_save_lumps().
 
-   Example 52. t_save_lumps() usage
+   Example 53. t_save_lumps() usage
 route {
         ...
         t_newtran();
index 2f54897..d171048 100644 (file)
@@ -841,6 +841,29 @@ failure_route[0]{
        </example>
        </section>
 
+       <section id="t_is_expired">
+       <title>
+           <function>t_is_expired()</function>
+       </title>
+       <para>
+               Returns true if the current transaction has already been expired,
+               i.e. the max_inv_lifetime/max_noninv_lifetime interval has already
+               elapsed.
+       </para>
+       <example>
+           <title><function>t_is_expired</function> usage</title>
+           <programlisting>
+...
+failure_route[0]{ 
+       if (t_is_expired()){
+               log("transaction expired\n");
+               # There is no point in adding a new branch.
+       }
+} 
+           </programlisting>
+       </example>
+       </section>
+
     <section id="t_relay_cancel">
        <title>
            <function>t_relay_cancel()</function>