File: api.xml

package info (click to toggle)
kamailio 4.2.0-2
  • links: PTS, VCS
  • area: main
  • in suites: jessie-kfreebsd
  • size: 56,100 kB
  • sloc: ansic: 552,832; xml: 166,484; sh: 8,659; makefile: 7,676; sql: 6,235; perl: 3,487; yacc: 3,428; python: 1,457; cpp: 1,219; php: 1,047; java: 449; pascal: 194; cs: 40; awk: 27
file content (266 lines) | stat: -rw-r--r-- 8,782 bytes parent folder | download | duplicates (4)
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:[&lt;file_name&gt;]\n
 &lt;method&gt;\n
 &lt;sender's uri&gt;\n
 &lt;dst uri&gt;\n
 &lt;CR_separated_headers&gt;\n
 &lt;body&gt;\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 &gt; /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 &gt; /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, &lt;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, &lt;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, &lt;0 - error.</para>
	</section>
    </section>
</section>