1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266
|
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<section id="tm.api" xmlns:xi="http://www.w3.org/2001/XInclude">
<sectioninfo>
</sectioninfo>
<title>TM Module API</title>
<para>
There are applications which would like to generate SIP transactions
without too big involvement in SIP stack, transaction management,
etc. An example of such an application is sending instant messages from
a website. To address needs of such apps, SIP-router accepts requests for
new transactions via the management interface. If you want to enable this
feature, start the management interface server by configuring the proper
modules.
</para>
<para>
An application can easily launch a new transaction by writing a
transaction request to this interface. The request must follow very
simple format, which for the basic FIFO interface is
</para>
<programlisting>
:t_uac_from:[<file_name>]\n
<method>\n
<sender's uri>\n
<dst uri>\n
<CR_separated_headers>\n
<body>\n
.\n
\n
</programlisting>
<para>
(Filename is to where a report will be dumped. ser assumes /tmp as
file's directory.)
</para>
<para>
Note the request write must be atomic, otherwise it might get
intermixed with writes from other writers. You can easily use it via
Unix command-line tools, see the following example:
</para>
<screen>
[jiri@bat jiri]$ cat > /tmp/ser_fifo
:t_uac_from:xxx
MESSAGE
sip:sender@iptel.org
sip:mrx@iptel.org
header:value
foo:bar
bznk:hjhjk
p_header: p_value
body body body
yet body
end of body
.
</screen>
<para>
or cat test/transaction.fifo > /tmp/ser_fifo
</para>
<section id="defines">
<title>Defines</title>
<itemizedlist>
<listitem>
<para>
ACK_TAG enables stricter matching of acknowledgments
including to-tags. Without it, to-tags are ignored. It is
disabled by default for two reasons:
</para>
<itemizedlist>
<listitem>
<para>
It eliminates an unlikely race condition in which
transaction's to-tag is being rewritten by a 200 OK
whereas an ACK is being looked up by to-tag.
</para>
</listitem>
</itemizedlist>
<itemizedlist>
<listitem>
<para>
It makes UACs happy who set wrong to-tags.
</para>
</listitem>
</itemizedlist>
<para>
It should not make a difference, as there may be only one
negative reply sent upstream and 200/ACKs are not matched
as they constitute another transaction. It will make no
difference at all when the new magic cookie matching is
enabled anyway.
</para>
</listitem>
<listitem>
<para>
CANCEL_TAG similarly enables strict matching of CANCELs
including to-tags--act of mercy to UACs, who screw up
the to-tags (however, it still depends on how forgiving
the downstream UAS is). Like with ACK_TAG, all this
complex transactions matching goes with <ulink
url="http://www.ietf.org/rfc/rfc3261.txt">RFC3261</ulink>'s
magic cookie away anyway.
</para>
</listitem>
</itemizedlist>
</section>
<section>
<title>Functions</title>
<section>
<title>
<function>register_tmcb(cb_type, cb_func)</function>
</title>
<para>
For programmatic use only--register a function to be called
back on an event. See t_hooks.h for more details.
</para>
<para>Meaning of the parameters is as follows:</para>
<itemizedlist>
<listitem>
<para><emphasis>cb_type</emphasis> - Callback type.
</para>
</listitem>
<listitem>
<para><emphasis>cb_func</emphasis> - Callback function.
</para>
</listitem>
</itemizedlist>
</section>
<section id="load_tm">
<title>
<function>load_tm(*import_structure)</function>
</title>
<para>
For programmatic use only--import exported <acronym>TM</acronym> functions.
See the acc module for an example of use.
</para>
<para>Meaning of the parameters is as follows:</para>
<itemizedlist>
<listitem>
<para><emphasis>import_structure</emphasis> - Pointer to the import structure.
</para>
</listitem>
</itemizedlist>
</section>
<section id="t_suspend">
<title>
<function>int t_suspend(struct sip_msg *msg,
unsigned int *hash_index, unsigned int *label)</function>
</title>
<para>
For programmatic use only.
This function together with t_continue() can be used to
implement asynchronous actions: t_suspend() saves the transaction,
returns its identifiers, and t_continue() continues the
SIP request/response processing. (The request/response processing does not continue
from the same point in the script, a separate route block defined
by the parameter of t_continue() is executed instead. The reply lock
is held during the route block execution.)
FR timer is ticking while the transaction is suspended, and the
transaction's failure route is executed if t_continue() is not
called in time.
</para>
<para>
Missing: message lumps are saved by t_suspend() and are not updated by
the subsequent t_relay(). This means that the modifications made
between them are lost.
</para>
<para>Meaning of the parameters is as follows:</para>
<itemizedlist>
<listitem>
<para><emphasis>msg</emphasis> - SIP message pointer.
</para>
</listitem>
<listitem>
<para><emphasis>hash_index</emphasis> - transaction identifier.
</para>
</listitem>
<listitem>
<para><emphasis>label</emphasis> - transaction identifier.
</para>
</listitem>
</itemizedlist>
<para>Return value: 0 - success, <0 - error.</para>
<para>
Usage: Allocate a memory block for storing the transaction identifiers
(hash_index and label), and for storing also any variable related to
the async query. Before calling t_suspend(), register for the following
callbacks, and pass the pointer to the allocated shared memory as
a parameter: TMCB_ON_FAILURE, TMCB_DESTROY, and TMCB_E2ECANCEL_IN
(in case of INVITE transaction). The async operation can be
cancelled, if it is still pending, when TMCB_ON_FAILURE or
TMCB_E2ECANCEL_IN is called. TMCB_DESTROY is suitable to free
the shared memory allocated for the async and SIP transaction identifiers.
Once the async query result is available call t_continue(), see below.
The SIP transaction must exist before calling t_suspend(), and the module
function calling t_suspend() should return 0 to make sure that the script
processing does not continue.
</para>
</section>
<section id="t_continue">
<title>
<function>int t_continue(unsigned int hash_index, unsigned int label,
struct action *route)</function>
</title>
<para>
For programmatic use only.
This function is the pair of t_suspend(), and is supposed
to be called when the asynchronous query result is available.
The function executes a route block with the saved SIP message.
It is possible to add more branches to the transaction, or send
a reply from the route block.
</para>
<para>Meaning of the parameters is as follows:</para>
<itemizedlist>
<listitem>
<para><emphasis>hash_index</emphasis> - transaction identifier.
</para>
</listitem>
<listitem>
<para><emphasis>label</emphasis> - transaction identifier.
</para>
</listitem>
<listitem>
<para><emphasis>route</emphasis> - route block to execute.
</para>
</listitem>
</itemizedlist>
<para>Return value: 0 - success, <0 - error.</para>
</section>
<section id="t_cancel_suspend">
<title>
<function>int t_cancel_suspend(unsigned int hash_index, unsigned int label)</function>
</title>
<para>
For programmatic use only.
This function is for revoking t_suspend() from the
same process as it was executed before. t_cancel_suspend() can be
used when something fails after t_suspend() has already been executed
and it turns out that the transcation should not have been
suspended. The function cancels the FR timer of the transacation.
</para>
<para>
The message lumps are saved by t_suspend() which cannot be restored.
</para>
<para>Meaning of the parameters is as follows:</para>
<itemizedlist>
<listitem>
<para><emphasis>hash_index</emphasis> - transaction identifier.
</para>
</listitem>
<listitem>
<para><emphasis>label</emphasis> - transaction identifier.
</para>
</listitem>
</itemizedlist>
<para>Return value: 0 - success, <0 - error.</para>
</section>
</section>
</section>
|