/
path_admin.xml
333 lines (314 loc) · 9.38 KB
/
path_admin.xml
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
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
<?xml version="1.0" encoding='ISO-8859-1'?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
<!-- Include general documentation entities -->
<!ENTITY % docentities SYSTEM "../../../docbook/entities.xml">
%docentities;
]>
<!-- Module User's Guide -->
<chapter>
<title>&adminguide;</title>
<section>
<title>Overview</title>
<para>
This module is designed to be used at intermediate sip proxies like loadbalancers in front of
registrars and proxies. It provides functions for inserting a Path header including a parameter for
passing forward the received-&uri; of a registration to the next hop. It also provides a mechanism
for evaluating this parameter in subsequent requests and to set the destination &uri; according to it.
</para>
<section>
<title>Path insertion for registrations</title>
<para>
For registrations in a scenario like <quote>[UAC] -> [P1] -> [REG]</quote>,
the "path" module can be used at the intermediate proxy P1 to insert a Path
header into the message before forwarding it to the registrar REG. Two functions
can be used to achieve this:
<itemizedlist>
<listitem>
<para>
<emphasis>add_path(...)</emphasis> adds a Path header in the form of
<quote>Path: <sip:1.2.3.4;lr></quote> to the message using the address
of the outgoing interface. A port is only added if it's not the default
port 5060.
</para>
<para>
If a username is passed to the function, it is also included in the Path
&uri;, like <quote>Path: <sip:username@1.2.3.4;lr></quote>.
</para>
</listitem>
<listitem>
<para>
<emphasis>add_path_received(...)</emphasis> also add a Path header in the
same form as above, but also adds a parameter indicating the received-&uri;
of the message, like
<quote>Path: <sip:1.2.3.4;received=sip:2.3.4.5:1234;lr></quote>. This
is especially useful if the proxy does NAT detection and wants to pass
the NAT'ed address to the registrar.
</para>
<para>
If the function is called with a username, it's included in the Path &uri; too.
</para>
</listitem>
</itemizedlist>
</para>
<para>
</para>
</section>
<section>
<title>Outbound routing to NAT'ed UACs</title>
<para>
If the NAT'ed address of an UAC is passed to the registrar, the registrar routes back
subsequent requests using the Path header of the registration as Route header of the
current request. If the intermediate proxy had inserted a Path header including the
<quote>received</quote> parameter during the registration, this parameter will show up
in the Route header of the new request as well, allowing the intermediate proxy to route
to this address instead of the one propagated in the Route &uri; for tunneling through NAT.
This behaviour can be activated by setting the module parameter <quote>use_received</quote>.
</para>
</section>
</section>
<section>
<title>Dependencies</title>
<section>
<title>&kamailio; Modules</title>
<para>
The following modules must be loaded before this module:
<itemizedlist>
<listitem>
<para>
The "rr" module is needed for outbound routing according to the <quote>received</quote>
parameter.
</para>
</listitem>
<listitem>
<para>
The "outbound" module is needed for outbound routing as per RFC 5626.
</para>
</listitem>
</itemizedlist>
</para>
</section>
<section>
<title>External Libraries or Applications</title>
<para>
The following libraries or applications must be installed before
running &kamailio; with this module loaded:
<itemizedlist>
<listitem>
<para>
<emphasis>None</emphasis>.
</para>
</listitem>
</itemizedlist>
</para>
</section>
</section>
<section>
<title>Parameters</title>
<section>
<title><varname>use_received</varname> (int)</title>
<para>
If set to 1, the <quote>received</quote> parameter of the first Route &uri; is evaluated and
used as destination-&uri; if present.
</para>
<para>
<emphasis>
Default value is 0.
</emphasis>
</para>
<example>
<title>Set <varname>use_received</varname> parameter</title>
<programlisting format="linespecific">
...
modparam("path", "use_received", 1)
...
</programlisting>
</example>
</section>
</section>
<section>
<title>Functions</title>
<section>
<title>
<function moreinfo="none">add_path()</function>
</title>
<para>
This function is used to insert a Path header in the form
<quote>Path: <sip:1.2.3.4;lr></quote>, where <quote>1.2.3.4</quote> is the address
of the outgoing interface.
</para>
<para>
If the <quote>outbound</quote> module was loaded before this module, and outbound is
required for this request, the header will be in the form
<quote>Path: <sip:flowtoken@1.2.3.4;lr;ob></quote>, where <quote>flowtoken</quote>
is the RFC 5626 flow-token that can be used to identify the source and local address and
transport the request was received on, and where <quote>1.2.3.4</quote> is the address of
the outgoing interface.
</para>
<para>
This function can be used from REQUEST_ROUTE.
</para>
<example>
<title><function>add_path</function> usage</title>
<programlisting format="linespecific">
...
if (!add_path()) {
sl_send_reply("503", "Internal Path Error");
...
};
...
</programlisting>
</example>
</section>
<section>
<title>
<function moreinfo="none">add_path(user)</function>
</title>
<para>
This function adds a Path header in the form
<quote>Path: <sip:user@1.2.3.4;lr></quote>.
</para>
<para>Meaning of the parameters is as follows:</para>
<itemizedlist>
<listitem>
<para>
<emphasis>user</emphasis> - The username to be inserted as user part.
SPVE is supported.
</para>
</listitem>
</itemizedlist>
<para>
This function can be used from REQUEST_ROUTE.
</para>
<example>
<title><function>add_path(user)</function> usage</title>
<programlisting format="linespecific">
...
if (!add_path("loadbalancer")) {
sl_send_reply("503", "Internal Path Error");
...
};
...
</programlisting>
</example>
</section>
<section>
<title>
<function moreinfo="none">add_path(user, parameters)</function>
</title>
<para>
This function adds a Path header in the form
<quote>Path: <sip:user@1.2.3.4;lr></quote> and appends the
given <emphasis>parameters</emphasis> as additional URI parameters.
</para>
<para>Meaning of the parameters is as follows:</para>
<itemizedlist>
<listitem>
<para>
<emphasis>user</emphasis> - The username to be inserted as user part.
SPVE is supported.
</para>
</listitem>
<listitem>
<para>
<emphasis>parameters</emphasis> - Additional URI parameters to be
appended to the URI. The semicolon separator is added automatically.
The script writer is responsible for proper URI escaping.
SPVE is supported.
</para>
</listitem>
</itemizedlist>
<para>
This function can be used from REQUEST_ROUTE.
</para>
<example>
<title><function>add_path(user, parameters)</function> usage</title>
<programlisting format="linespecific">
...
if (!add_path("loadbalancer", "ob")) {
sl_send_reply("503", "Internal Path Error");
...
};
...
</programlisting>
</example>
</section>
<section>
<title>
<function moreinfo="none">add_path_received()</function>
</title>
<para>
This function adds a Path header in the form
<quote>Path: <sip:1.2.3.4;received=sip:2.3.4.5:1234;lr></quote>, setting its own
outgoing address as domain-part, and the address the request has been received from as
received-parameter.
</para>
<para>
This function can be used from REQUEST_ROUTE.
</para>
<example>
<title><function>add_path_received()</function> usage</title>
<programlisting format="linespecific">
...
if (!add_path_received()) {
sl_send_reply("503", "Internal Path Error");
...
};
...
</programlisting>
</example>
</section>
<section>
<title>
<function moreinfo="none">add_path_received(user)</function>
</title>
<para>
This function adds a Path header in the form
<quote>Path: <sip:user@1.2.3.4;received=sip:2.3.4.5:1234;lr></quote>, setting
'user' as username part of address, its own
outgoing address as domain-part, and the address the request has been received from as
received-parameter.
</para>
<para>
This function can be used from REQUEST_ROUTE.
</para>
<example>
<title><function>add_path_received(user)</function> usage</title>
<programlisting format="linespecific">
...
if (!add_path_received("inbound")) {
sl_send_reply("503", "Internal Path Error");
...
};
...
</programlisting>
</example>
</section>
<section>
<title>
<function moreinfo="none">add_path_received(user, parameters)</function>
</title>
<para>
This function adds a Path header in the form
<quote>Path: <sip:user@1.2.3.4;received=sip:2.3.4.5:1234;lr></quote>, setting
'user' as username part of address, its own
outgoing address as domain-part, and the address the request has been received from as
received-parameter.
</para>
<para>
This function can be used from REQUEST_ROUTE.
</para>
<example>
<title><function>add_path_received(user, parameters)</function> usage</title>
<programlisting format="linespecific">
...
if (!add_path_received("inbound", "ob")) {
sl_send_reply("503", "Internal Path Error");
...
};
...
</programlisting>
</example>
</section>
</section>
</chapter>