Browse code

tm: readme updated based on latest docbook

Daniel-Constantin Mierla authored on 15/06/2013 17:31:43
Showing 1 changed files
... ...
@@ -1,4 +1,3 @@
1
-
2 1
 TM Module
3 2
 
4 3
 Jiri Kuthan
... ...
@@ -12,7 +11,7 @@ Juha Heinanen
12 11
    Copyright � 2003 FhG FOKUS
13 12
 
14 13
    Copyright � 2008 Juha Heinanen
15
-     _________________________________________________________________
14
+     __________________________________________________________________
16 15
 
17 16
    Table of Contents
18 17
 
... ...
@@ -67,76 +66,77 @@ Juha Heinanen
67 66
               4.42. e2e_cancel_reason (boolean)
68 67
               4.43. remap_503_500 (boolean)
69 68
               4.44. failure_exec_mode (boolean)
69
+              4.45. dns_reuse_rcv_socket (boolean)
70 70
 
71 71
         5. Functions
72 72
 
73
-              5.1. t_relay([host, port]) 
74
-              5.2. t_relay_to_udp([ip, port]) 
75
-              5.3. t_relay_to_tcp([ip, port]) 
76
-              5.4. t_relay_to_tls([ip, port]) 
77
-              5.5. t_relay_to_sctp([ip, port]) 
78
-              5.6. t_on_failure(failure_route) 
79
-              5.7. t_on_branch_failure(branch_failure_route) 
80
-              5.8. t_on_reply(onreply_route) 
81
-              5.9. t_on_branch(branch_route) 
82
-              5.10. t_newtran() 
83
-              5.11. t_reply(code, reason_phrase) 
84
-              5.12. t_lookup_request() 
85
-              5.13. t_retransmit_reply() 
86
-              5.14. t_release() 
87
-              5.15. t_forward_nonack([ip, port]) 
88
-              5.16. t_forward_nonack_udp(ip, port) 
89
-              5.17. t_forward_nonack_tcp(ip, port) 
90
-              5.18. t_forward_nonack_tls(ip, port) 
91
-              5.19. t_forward_nonack_sctp(ip, port) 
92
-              5.20. t_set_fr(fr_inv_timeout [, fr_timeout]) 
93
-              5.21. t_reset_fr() 
94
-              5.22. t_set_max_lifetime(inv_lifetime, noninv_lifetime) 
95
-              5.23. t_reset_max_lifetime() 
96
-              5.24. t_set_retr(retr_t1_interval, retr_t2_interval) 
97
-              5.25. t_reset_retr() 
98
-              5.26. t_set_auto_inv_100(0|1) 
99
-              5.27. t_branch_timeout() 
100
-              5.28. t_branch_replied() 
101
-              5.29. t_any_timeout() 
102
-              5.30. t_any_replied() 
103
-              5.31. t_grep_status("code") 
104
-              5.32. t_is_canceled() 
105
-              5.33. t_is_expired() 
106
-              5.34. t_relay_cancel() 
107
-              5.35. t_lookup_cancel([1]) 
108
-              5.36. t_drop_replies([mode]) 
109
-              5.37. t_save_lumps() 
110
-              5.38. t_load_contacts() 
111
-              5.39. t_next_contacts() 
112
-              5.40. t_next_contact_flow() 
113
-              5.41. t_check_trans() 
114
-              5.42. t_set_disable_6xx(0|1) 
115
-              5.43. t_set_disable_failover(0|1) 
116
-              5.44. t_replicate(params) 
117
-              5.45. t_relay_to(proxy, flags) 
118
-              5.46. t_set_no_e2e_cancel_reason(0|1) 
119
-              5.47. t_is_set(target) 
73
+              5.1. t_relay([host, port])
74
+              5.2. t_relay_to_udp([ip, port])
75
+              5.3. t_relay_to_tcp([ip, port])
76
+              5.4. t_relay_to_tls([ip, port])
77
+              5.5. t_relay_to_sctp([ip, port])
78
+              5.6. t_on_failure(failure_route)
79
+              5.7. t_on_branch_failure(branch_failure_route)
80
+              5.8. t_on_reply(onreply_route)
81
+              5.9. t_on_branch(branch_route)
82
+              5.10. t_newtran()
83
+              5.11. t_reply(code, reason_phrase)
84
+              5.12. t_lookup_request()
85
+              5.13. t_retransmit_reply()
86
+              5.14. t_release()
87
+              5.15. t_forward_nonack([ip, port])
88
+              5.16. t_forward_nonack_udp(ip, port)
89
+              5.17. t_forward_nonack_tcp(ip, port)
90
+              5.18. t_forward_nonack_tls(ip, port)
91
+              5.19. t_forward_nonack_sctp(ip, port)
92
+              5.20. t_set_fr(fr_inv_timeout [, fr_timeout])
93
+              5.21. t_reset_fr()
94
+              5.22. t_set_max_lifetime(inv_lifetime, noninv_lifetime)
95
+              5.23. t_reset_max_lifetime()
96
+              5.24. t_set_retr(retr_t1_interval, retr_t2_interval)
97
+              5.25. t_reset_retr()
98
+              5.26. t_set_auto_inv_100(0|1)
99
+              5.27. t_branch_timeout()
100
+              5.28. t_branch_replied()
101
+              5.29. t_any_timeout()
102
+              5.30. t_any_replied()
103
+              5.31. t_grep_status("code")
104
+              5.32. t_is_canceled()
105
+              5.33. t_is_expired()
106
+              5.34. t_relay_cancel()
107
+              5.35. t_lookup_cancel([1])
108
+              5.36. t_drop_replies([mode])
109
+              5.37. t_save_lumps()
110
+              5.38. t_load_contacts()
111
+              5.39. t_next_contacts()
112
+              5.40. t_next_contact_flow()
113
+              5.41. t_check_trans()
114
+              5.42. t_set_disable_6xx(0|1)
115
+              5.43. t_set_disable_failover(0|1)
116
+              5.44. t_replicate(params)
117
+              5.45. t_relay_to(proxy, flags)
118
+              5.46. t_set_no_e2e_cancel_reason(0|1)
119
+              5.47. t_is_set(target)
120 120
 
121 121
         6. TM Module API
122 122
 
123 123
               6.1. Defines
124 124
               6.2. Functions
125 125
 
126
-                    6.2.1. register_tmcb(cb_type, cb_func) 
127
-                    6.2.2. load_tm(*import_structure) 
128
-                    6.2.3. int t_suspend(struct sip_msg *msg, unsigned
129
-                            int *hash_index, unsigned int *label) 
126
+                    6.2.1. register_tmcb(cb_type, cb_func)
127
+                    6.2.2. load_tm(*import_structure)
128
+                    6.2.3. int t_suspend(struct sip_msg *msg, unsigned int
129
+                            *hash_index, unsigned int *label)
130 130
 
131 131
                     6.2.4. int t_continue(unsigned int hash_index,
132
-                            unsigned int label, struct action *route) 
132
+                            unsigned int label, struct action *route)
133 133
 
134 134
                     6.2.5. int t_cancel_suspend(unsigned int hash_index,
135
-                            unsigned int label) 
135
+                            unsigned int label)
136 136
 
137 137
         7. Event Routes
138 138
 
139
-              7.1. event_route[tm:branch-failure] 
139
+              7.1. event_route[tm:branch-failure]
140 140
 
141 141
    List of Examples
142 142
 
... ...
@@ -173,9 +173,9 @@ Juha Heinanen
173 173
    1.31. Set ruri_matching parameter
174 174
    1.32. Set via1_matching parameter
175 175
    1.33. Set callid_matching parameter
176
-   1.34. Set pass_provisional_replies parameter 
177
-   1.35. Set default_code parameter 
178
-   1.36. Set default_reason parameter 
176
+   1.34. Set pass_provisional_replies parameter
177
+   1.35. Set default_code parameter
178
+   1.36. Set default_reason parameter
179 179
    1.37. Set disable_6xx_block parameter
180 180
    1.38. Set local_ack_mode parameter
181 181
    1.39. Set failure_reply_mode parameter
... ...
@@ -184,47 +184,48 @@ Juha Heinanen
184 184
    1.42. Set e2e_cancel_reason parameter
185 185
    1.43. Set remap_503_500 parameter
186 186
    1.44. Set failure_exec_mode parameter
187
-   1.45. t_relay usage
188
-   1.46. t_relay_to_udp usage
189
-   1.47. t_on_failure usage
190
-   1.48. t_on_branch_failure usage
191
-   1.49. t_on_reply usage
192
-   1.50. t_on_branch usage
193
-   1.51. t_newtran usage
194
-   1.52. t_reply usage
195
-   1.53. t_lookup_request usage
196
-   1.54. t_retransmit_reply usage
197
-   1.55. t_release usage
198
-   1.56. t_forward_nonack usage
199
-   1.57. t_set_fr usage
200
-   1.58. t_reset_fr usage
201
-   1.59. t_set_max_lifetime usage
202
-   1.60. t_reset_max_lifetime usage
203
-   1.61. t_set_retr usage
204
-   1.62. t_reset_retr usage
205
-   1.63. t_set_auto_inv_100 usage
206
-   1.64. t_branch_timeout usage
207
-   1.65. t_branch_replied usage
208
-   1.66. t_any_timeout usage
209
-   1.67. t_any_replied usage
210
-   1.68. t_grep_status usage
211
-   1.69. t_is_canceled usage
212
-   1.70. t_is_expired usage
213
-   1.71. t_relay_cancel usage
214
-   1.72. t_lookup_cancel usage
215
-   1.73. t_drop_replies() usage
216
-   1.74. t_save_lumps() usage
217
-   1.75. t_load_contacts usage
218
-   1.76. t_next_contacts usage
219
-   1.77. t_next_contact_flow usage
220
-   1.78. t_check_trans usage
221
-   1.79. t_set_disable_6xx usage
222
-   1.80. t_set_disable_failover usage
223
-   1.81. t_replicate usage
187
+   1.45. Set dns_reuse_rcv_socket parameter
188
+   1.46. t_relay usage
189
+   1.47. t_relay_to_udp usage
190
+   1.48. t_on_failure usage
191
+   1.49. t_on_branch_failure usage
192
+   1.50. t_on_reply usage
193
+   1.51. t_on_branch usage
194
+   1.52. t_newtran usage
195
+   1.53. t_reply usage
196
+   1.54. t_lookup_request usage
197
+   1.55. t_retransmit_reply usage
198
+   1.56. t_release usage
199
+   1.57. t_forward_nonack usage
200
+   1.58. t_set_fr usage
201
+   1.59. t_reset_fr usage
202
+   1.60. t_set_max_lifetime usage
203
+   1.61. t_reset_max_lifetime usage
204
+   1.62. t_set_retr usage
205
+   1.63. t_reset_retr usage
206
+   1.64. t_set_auto_inv_100 usage
207
+   1.65. t_branch_timeout usage
208
+   1.66. t_branch_replied usage
209
+   1.67. t_any_timeout usage
210
+   1.68. t_any_replied usage
211
+   1.69. t_grep_status usage
212
+   1.70. t_is_canceled usage
213
+   1.71. t_is_expired usage
214
+   1.72. t_relay_cancel usage
215
+   1.73. t_lookup_cancel usage
216
+   1.74. t_drop_replies() usage
217
+   1.75. t_save_lumps() usage
218
+   1.76. t_load_contacts usage
219
+   1.77. t_next_contacts usage
220
+   1.78. t_next_contact_flow usage
221
+   1.79. t_check_trans usage
222
+   1.80. t_set_disable_6xx usage
223
+   1.81. t_set_disable_failover usage
224 224
    1.82. t_replicate usage
225
-   1.83. t_set_no_e2e_cancel_reason usage
226
-   1.84. t_replicate usage
227
-   1.85. event_route[tm:branch-failure] usage
225
+   1.83. t_replicate usage
226
+   1.84. t_set_no_e2e_cancel_reason usage
227
+   1.85. t_replicate usage
228
+   1.86. event_route[tm:branch-failure] usage
228 229
 
229 230
 Chapter 1. Admin Guide
230 231
 
... ...
@@ -279,178 +280,179 @@ Chapter 1. Admin Guide
279 280
         4.42. e2e_cancel_reason (boolean)
280 281
         4.43. remap_503_500 (boolean)
281 282
         4.44. failure_exec_mode (boolean)
283
+        4.45. dns_reuse_rcv_socket (boolean)
282 284
 
283 285
    5. Functions
284 286
 
285
-        5.1. t_relay([host, port]) 
286
-        5.2. t_relay_to_udp([ip, port]) 
287
-        5.3. t_relay_to_tcp([ip, port]) 
288
-        5.4. t_relay_to_tls([ip, port]) 
289
-        5.5. t_relay_to_sctp([ip, port]) 
290
-        5.6. t_on_failure(failure_route) 
291
-        5.7. t_on_branch_failure(branch_failure_route) 
292
-        5.8. t_on_reply(onreply_route) 
293
-        5.9. t_on_branch(branch_route) 
294
-        5.10. t_newtran() 
295
-        5.11. t_reply(code, reason_phrase) 
296
-        5.12. t_lookup_request() 
297
-        5.13. t_retransmit_reply() 
298
-        5.14. t_release() 
299
-        5.15. t_forward_nonack([ip, port]) 
300
-        5.16. t_forward_nonack_udp(ip, port) 
301
-        5.17. t_forward_nonack_tcp(ip, port) 
302
-        5.18. t_forward_nonack_tls(ip, port) 
303
-        5.19. t_forward_nonack_sctp(ip, port) 
304
-        5.20. t_set_fr(fr_inv_timeout [, fr_timeout]) 
305
-        5.21. t_reset_fr() 
306
-        5.22. t_set_max_lifetime(inv_lifetime, noninv_lifetime) 
307
-        5.23. t_reset_max_lifetime() 
308
-        5.24. t_set_retr(retr_t1_interval, retr_t2_interval) 
309
-        5.25. t_reset_retr() 
310
-        5.26. t_set_auto_inv_100(0|1) 
311
-        5.27. t_branch_timeout() 
312
-        5.28. t_branch_replied() 
313
-        5.29. t_any_timeout() 
314
-        5.30. t_any_replied() 
315
-        5.31. t_grep_status("code") 
316
-        5.32. t_is_canceled() 
317
-        5.33. t_is_expired() 
318
-        5.34. t_relay_cancel() 
319
-        5.35. t_lookup_cancel([1]) 
320
-        5.36. t_drop_replies([mode]) 
321
-        5.37. t_save_lumps() 
322
-        5.38. t_load_contacts() 
323
-        5.39. t_next_contacts() 
324
-        5.40. t_next_contact_flow() 
325
-        5.41. t_check_trans() 
326
-        5.42. t_set_disable_6xx(0|1) 
327
-        5.43. t_set_disable_failover(0|1) 
328
-        5.44. t_replicate(params) 
329
-        5.45. t_relay_to(proxy, flags) 
330
-        5.46. t_set_no_e2e_cancel_reason(0|1) 
331
-        5.47. t_is_set(target) 
287
+        5.1. t_relay([host, port])
288
+        5.2. t_relay_to_udp([ip, port])
289
+        5.3. t_relay_to_tcp([ip, port])
290
+        5.4. t_relay_to_tls([ip, port])
291
+        5.5. t_relay_to_sctp([ip, port])
292
+        5.6. t_on_failure(failure_route)
293
+        5.7. t_on_branch_failure(branch_failure_route)
294
+        5.8. t_on_reply(onreply_route)
295
+        5.9. t_on_branch(branch_route)
296
+        5.10. t_newtran()
297
+        5.11. t_reply(code, reason_phrase)
298
+        5.12. t_lookup_request()
299
+        5.13. t_retransmit_reply()
300
+        5.14. t_release()
301
+        5.15. t_forward_nonack([ip, port])
302
+        5.16. t_forward_nonack_udp(ip, port)
303
+        5.17. t_forward_nonack_tcp(ip, port)
304
+        5.18. t_forward_nonack_tls(ip, port)
305
+        5.19. t_forward_nonack_sctp(ip, port)
306
+        5.20. t_set_fr(fr_inv_timeout [, fr_timeout])
307
+        5.21. t_reset_fr()
308
+        5.22. t_set_max_lifetime(inv_lifetime, noninv_lifetime)
309
+        5.23. t_reset_max_lifetime()
310
+        5.24. t_set_retr(retr_t1_interval, retr_t2_interval)
311
+        5.25. t_reset_retr()
312
+        5.26. t_set_auto_inv_100(0|1)
313
+        5.27. t_branch_timeout()
314
+        5.28. t_branch_replied()
315
+        5.29. t_any_timeout()
316
+        5.30. t_any_replied()
317
+        5.31. t_grep_status("code")
318
+        5.32. t_is_canceled()
319
+        5.33. t_is_expired()
320
+        5.34. t_relay_cancel()
321
+        5.35. t_lookup_cancel([1])
322
+        5.36. t_drop_replies([mode])
323
+        5.37. t_save_lumps()
324
+        5.38. t_load_contacts()
325
+        5.39. t_next_contacts()
326
+        5.40. t_next_contact_flow()
327
+        5.41. t_check_trans()
328
+        5.42. t_set_disable_6xx(0|1)
329
+        5.43. t_set_disable_failover(0|1)
330
+        5.44. t_replicate(params)
331
+        5.45. t_relay_to(proxy, flags)
332
+        5.46. t_set_no_e2e_cancel_reason(0|1)
333
+        5.47. t_is_set(target)
332 334
 
333 335
    6. TM Module API
334 336
 
335 337
         6.1. Defines
336 338
         6.2. Functions
337 339
 
338
-              6.2.1. register_tmcb(cb_type, cb_func) 
339
-              6.2.2. load_tm(*import_structure) 
340
+              6.2.1. register_tmcb(cb_type, cb_func)
341
+              6.2.2. load_tm(*import_structure)
340 342
               6.2.3. int t_suspend(struct sip_msg *msg, unsigned int
341
-                      *hash_index, unsigned int *label) 
343
+                      *hash_index, unsigned int *label)
342 344
 
343 345
               6.2.4. int t_continue(unsigned int hash_index, unsigned int
344
-                      label, struct action *route) 
346
+                      label, struct action *route)
345 347
 
346 348
               6.2.5. int t_cancel_suspend(unsigned int hash_index,
347
-                      unsigned int label) 
349
+                      unsigned int label)
348 350
 
349 351
    7. Event Routes
350 352
 
351
-        7.1. event_route[tm:branch-failure] 
353
+        7.1. event_route[tm:branch-failure]
352 354
 
353 355
 1. Overview
354 356
 
355
-   The  TM  module  enables  stateful  processing  of  SIP  transactions.
356
-   Stateful  logic  is costly in terms of memory and CPU. The main use is
357
-   services  that  inherently  need state. For example, transaction-based
358
-   accounting  (module acc) needs to process transaction state as opposed
359
-   to  individual  messages.  Any  kind  of  forking  must be implemented
360
-   transaction  statefully.  By  using  transaction  states you trade CPU
361
-   caused  by retransmission processing for memory. That only makes sense
362
-   if  CPU  consumption  per request is huge. For example, if you want to
363
-   avoid  costly  DNS resolution for every retransmission of a request to
364
-   an unresolvable destination, use stateful mode. Then, only the initial
357
+   The TM module enables stateful processing of SIP transactions. Stateful
358
+   logic is costly in terms of memory and CPU. The main use is services
359
+   that inherently need state. For example, transaction-based accounting
360
+   (module acc) needs to process transaction state as opposed to
361
+   individual messages. Any kind of forking must be implemented
362
+   transaction statefully. By using transaction states you trade CPU
363
+   caused by retransmission processing for memory. That only makes sense
364
+   if CPU consumption per request is huge. For example, if you want to
365
+   avoid costly DNS resolution for every retransmission of a request to an
366
+   unresolvable destination, use stateful mode. Then, only the initial
365 367
    message burdens server by DNS queries, subsequent retransmissions will
366
-   be  dropped  and  will  not  result  in  more processes blocked by DNS
368
+   be dropped and will not result in more processes blocked by DNS
367 369
    resolution. The price is more memory consumption and higher processing
368 370
    latency.
369 371
 
370 372
    From the admin's perspective, these are the major functions : t_relay,
371
-   t_relay_to_udp  and  t_relay_to_tcp.  All  of  them  setup transaction
372
-   state,  absorb  retransmissions  from  upstream,  generate  downstream
373
+   t_relay_to_udp and t_relay_to_tcp. All of them setup transaction state,
374
+   absorb retransmissions from upstream, generate downstream
373 375
    retransmissions and correlate replies to requests. t_relay forwards to
374
-   current  URI (be it original request's URI or a URI changed by some of
375
-   URI-modifying   functions,   such   as  sethost).  t_relay_to_udp  and
376
-   t_relay_to_tcp   forward  to  a  specific  address  over  UDP  or  TCP
376
+   current URI (be it original request's URI or a URI changed by some of
377
+   URI-modifying functions, such as sethost). t_relay_to_udp and
378
+   t_relay_to_tcp forward to a specific address over UDP or TCP
377 379
    respectively.
378 380
 
379
-   In  general,  if TM is used, it copies clones of received SIP messages
380
-   in  shared  memory.  That  costs  memory  and  also CPU time (memcpys,
381
-   lookups,  shmem  locks,  etc.) Note that non-TM functions operate over
382
-   the  received  message  in  private  memory,  that means that any core
383
-   operations  will have no effect on statefully processed messages after
384
-   creating  the  transactional  state. For example, calling record_route
385
-   after  t_relay is pretty useless, as the RR is added to privately held
386
-   message whereas its TM clone is being forwarded.
387
-
388
-   The  TM  module  is quite big and uneasy to program --lots of mutexes,
389
-   shared  memory  access, malloc and free, timers--you really need to be
381
+   In general, if TM is used, it copies clones of received SIP messages in
382
+   shared memory. That costs memory and also CPU time (memcpys, lookups,
383
+   shmem locks, etc.) Note that non-TM functions operate over the received
384
+   message in private memory, that means that any core operations will
385
+   have no effect on statefully processed messages after creating the
386
+   transactional state. For example, calling record_route after t_relay is
387
+   pretty useless, as the RR is added to privately held message whereas
388
+   its TM clone is being forwarded.
389
+
390
+   The TM module is quite big and uneasy to program --lots of mutexes,
391
+   shared memory access, malloc and free, timers--you really need to be
390 392
    careful when you do anything. To simplify TM programming, there is the
391
-   instrument  of callbacks. The callback mechanisms allow programmers to
393
+   instrument of callbacks. The callback mechanisms allow programmers to
392 394
    register their functions to a specific event. See t_hooks.h for a list
393 395
    of possible events.
394 396
 
395
-   Other  things  programmers  may  want  to  know  is  UAC--it is a very
396
-   simplistic  code  which  allows you to generate your own transactions.
397
-   Particularly  useful  for  things like NOTIFYs or IM gateways. The UAC
398
-   takes  care  of  all  the  transaction  machinery: retransmissions, FR
397
+   Other things programmers may want to know is UAC--it is a very
398
+   simplistic code which allows you to generate your own transactions.
399
+   Particularly useful for things like NOTIFYs or IM gateways. The UAC
400
+   takes care of all the transaction machinery: retransmissions, FR
399 401
    timeouts, forking, etc. See t_uac prototype in uac.h for more details.
400
-   If  you want to see the transaction result the code can register for a
402
+   If you want to see the transaction result the code can register for a
401 403
    callback.
402 404
 
403 405
 Note
404 406
 
405
-   Several  Kamailio  TM  module functions are now implemented in the TMX
406
-   module:  "modules_k/tmx".  Check it to see if what you are looking for
407
-   is there.
407
+   Several Kamailio TM module functions are now implemented in the TMX
408
+   module: "modules_k/tmx". Check it to see if what you are looking for is
409
+   there.
408 410
 
409 411
 2. Serial Forking Based on Q Value
410 412
 
411 413
    A single SIP INVITE request may be forked to multiple destinations. We
412
-   call  the set of all such destinations a "destination set". Individual
413
-   elements  within  the destination sets are called branches. The script
414
-   writer  can  add  URIs  to  the destination set from the configuration
415
-   file,  or  they  can  be  loaded from the user location database. Each
416
-   registered contact then becomes one branch in the destination set.
417
-
418
-   The  default behavior of the TM module, if it encounters a SIP message
419
-   with  multiple  branches in the destination set, is to forward the SIP
420
-   message  to  all  the  branches  in  parallel. That means it sends the
421
-   message  to  all  the  branch destinations before it waits for replies
422
-   from  any  of them. This is the default behavior if you call t_relay()
423
-   and similar functions without any other arguments.
414
+   call the set of all such destinations a "destination set". Individual
415
+   elements within the destination sets are called branches. The script
416
+   writer can add URIs to the destination set from the configuration file,
417
+   or they can be loaded from the user location database. Each registered
418
+   contact then becomes one branch in the destination set.
419
+
420
+   The default behavior of the TM module, if it encounters a SIP message
421
+   with multiple branches in the destination set, is to forward the SIP
422
+   message to all the branches in parallel. That means it sends the
423
+   message to all the branch destinations before it waits for replies from
424
+   any of them. This is the default behavior if you call t_relay() and
425
+   similar functions without any other arguments.
424 426
 
425 427
    Another approach of handling multiple branches in a destination set is
426 428
    serial forking. When configured to do serial forking, the server takes
427
-   the  first  branch out of the destination set, forwards the message to
428
-   its  destination  and waits for a reply or timeout. Only after a reply
429
-   has  been  received  or  a  timeout occurred, the server takes another
430
-   destination  from  the  destination  set  and  tries  again,  until it
431
-   receives  a  positive  final  reply  or  until  all  branches from the
432
-   destination set have been tried.
433
-
434
-   Yet  another, more sophisticated, way of handling multiple branches is
429
+   the first branch out of the destination set, forwards the message to
430
+   its destination and waits for a reply or timeout. Only after a reply
431
+   has been received or a timeout occurred, the server takes another
432
+   destination from the destination set and tries again, until it receives
433
+   a positive final reply or until all branches from the destination set
434
+   have been tried.
435
+
436
+   Yet another, more sophisticated, way of handling multiple branches is
435 437
    combined serial/parallel forking, where individual branches within the
436 438
    destination set are assigned priorities. The order in which individual
437
-   branches  are  tried  is  then  determined  by their relative priority
438
-   within  the destination set. Branches can be tried sequentially in the
439
+   branches are tried is then determined by their relative priority within
440
+   the destination set. Branches can be tried sequentially in the
439 441
    descending priority order and all branches that have the same priority
440 442
    can be tried in parallel. Such combined serial/parallel forking can be
441 443
    achieved in the TM module with the help of functions t_load_contacts()
442 444
    and t_next_contacts().
443 445
 
444
-   Every  branch  in  the  destination set is assigned a priority number,
445
-   also known as the "q value". The q value is a floating point number in
446
-   a  range 0 to 1.0. The higher the q value number, the more priority is
446
+   Every branch in the destination set is assigned a priority number, also
447
+   known as the "q value". The q value is a floating point number in a
448
+   range 0 to 1.0. The higher the q value number, the more priority is
447 449
    given to the particular branch in the destination set. Branches with q
448
-   value  1.0  have  maximum  priority, such branches should be always be
450
+   value 1.0 have maximum priority, such branches should be always be
449 451
    tried first in serial forking. Branches with q value 0 have the lowest
450 452
    priority and they should by tried after all other branches with higher
451 453
    priority in the destination set.
452 454
 
453
-   As  an example, consider the following simple configuration file. When
455
+   As an example, consider the following simple configuration file. When
454 456
    the server receives an INVITE, it creates four branches with usernames
455 457
    A through D and then forwards the request using t_relay():
456 458
 route {
... ...
@@ -463,10 +465,10 @@ route {
463 465
   break;
464 466
 }
465 467
 
466
-   With  this  configuration  the server forwards the request to all four
467
-   branches  at  once, performing parallel forking as described above. We
468
+   With this configuration the server forwards the request to all four
469
+   branches at once, performing parallel forking as described above. We
468 470
    did not set the q value for individual branches in this example but we
469
-   can   do   that   by   slightly   modifying  the  arguments  given  to
471
+   can do that by slightly modifying the arguments given to
470 472
    append_branch():
471 473
 route {
472 474
   seturi("sip:a@example.com");
... ...
@@ -478,19 +480,19 @@ route {
478 480
   break;
479 481
 }
480 482
 
481
-   Here  we  assigned  q value 0.5 to branches B and C and q value 1.0 to
483
+   Here we assigned q value 0.5 to branches B and C and q value 1.0 to
482 484
    branch D. We did not specify any q value for branch A and in that case
483
-   it  is assumed that its q value is the lowest from all branches within
484
-   the  destination  set.  If you try to run this example again, you will
485
-   figure  out  that nothing changed, t_relay() still forward the message
486
-   to all branches in parallel.
487
-
488
-   We  now want to implement the combined serial/parallel forking. Branch
489
-   D  should be tried first, because its q value is 1.0. Branches B and C
490
-   should  be  tried  in  parallel,  but  only after D finishes. Branch A
491
-   should  be  tried  after  B  and  C finished, because its q value (the
492
-   default)  is  the  lowest of all. To do that, we need to introduce two
493
-   new functions into our example and two tm module parameters:
485
+   it is assumed that its q value is the lowest from all branches within
486
+   the destination set. If you try to run this example again, you will
487
+   figure out that nothing changed, t_relay() still forward the message to
488
+   all branches in parallel.
489
+
490
+   We now want to implement the combined serial/parallel forking. Branch D
491
+   should be tried first, because its q value is 1.0. Branches B and C
492
+   should be tried in parallel, but only after D finishes. Branch A should
493
+   be tried after B and C finished, because its q value (the default) is
494
+   the lowest of all. To do that, we need to introduce two new functions
495
+   into our example and two tm module parameters:
494 496
 modparam("tm", "contacts_avp", "tm_contacts");
495 497
 modparam("tm", "contact_flows_avp", "tm_contact_flows");
496 498
 
... ...
@@ -507,23 +509,23 @@ route {
507 509
   break;
508 510
 }
509 511
 
510
-   First  of  all,  the tm module parameters are mandatory if the two new
512
+   First of all, the tm module parameters are mandatory if the two new
511 513
    functions are used. Function t_load_contacts() takes all branches from
512 514
    the destination set, sorts them according to their q values and stores
513
-   them  in  the AVP configured in the modparam. The function also clears
514
-   the  destination  set,  which  means  that  it  removes  all  branches
515
+   them in the AVP configured in the modparam. The function also clears
516
+   the destination set, which means that it removes all branches
515 517
    configured before with seturi() and append_branch().
516 518
 
517
-   Function  t_next_contacts()  takes  the  AVP  created  by the previous
518
-   function  and  extract  the branches with highest q values from it. In
519
-   our  example  it  is  branch  D. That branch is then put back into the
520
-   destination  set  and  when  the script finally reaches t_relay(), the
521
-   destination  set  only  contains  branch  D  and  the  request will be
519
+   Function t_next_contacts() takes the AVP created by the previous
520
+   function and extract the branches with highest q values from it. In our
521
+   example it is branch D. That branch is then put back into the
522
+   destination set and when the script finally reaches t_relay(), the
523
+   destination set only contains branch D and the request will be
522 524
    forwarded there.
523 525
 
524
-   We  achieved  the  first  step  of  serial  forking,  but  this is not
525
-   sufficient.  Now  we also need to forward to other branches with lower
526
-   priority  values when branch D finishes. To do that, we need to extend
526
+   We achieved the first step of serial forking, but this is not
527
+   sufficient. Now we also need to forward to other branches with lower
528
+   priority values when branch D finishes. To do that, we need to extend
527 529
    the configuration file again and introduce a failure_route section:
528 530
 modparam("tm", "contacts_avp", "tm_contacts");
529 531
 
... ...
@@ -551,47 +553,47 @@ failure_route["serial"]
551 553
   t_relay();
552 554
 }
553 555
 
554
-   The  failure_route section will be executed when branch D finishes. It
555
-   executes  t_next_contacts() again and this time the function retrieves
556
-   branches  B  and  C from the AVP and adds them to the destination set.
557
-   Here  we  need  to  check  the return value of the function, because a
558
-   negative  value  indicates  that  there were no more branches, in that
559
-   case  the failure_route should just terminate and forward the response
560
-   from branch D upstream.
561
-
562
-   If  t_next_contact()  returns  a  positive value then we have more new
563
-   branches  to try and we need to setup the failure_route again and call
564
-   t_relay().  In  our  example  the  request  will  now  be forwarded to
565
-   branches  B  and  C  in  paralell, because they were both added to the
566
-   destination set by t_next_contacts() at the same time.
567
-
568
-   When  branches  B  and  C  finish, the failure_route block is executed
569
-   again,  this  time  t_next_contacts() puts the final branch A into the
556
+   The failure_route section will be executed when branch D finishes. It
557
+   executes t_next_contacts() again and this time the function retrieves
558
+   branches B and C from the AVP and adds them to the destination set.
559
+   Here we need to check the return value of the function, because a
560
+   negative value indicates that there were no more branches, in that case
561
+   the failure_route should just terminate and forward the response from
562
+   branch D upstream.
563
+
564
+   If t_next_contact() returns a positive value then we have more new
565
+   branches to try and we need to setup the failure_route again and call
566
+   t_relay(). In our example the request will now be forwarded to branches
567
+   B and C in paralell, because they were both added to the destination
568
+   set by t_next_contacts() at the same time.
569
+
570
+   When branches B and C finish, the failure_route block is executed
571
+   again, this time t_next_contacts() puts the final branch A into the
570 572
    destination set and t_relay() forwards the request there.
571 573
 
572
-   And  that's  the  whole  example, we achieved combined serial/parallel
573
-   forking  based  on  the  q value of individual branches. In real-world
574
-   configuration  files  the script writer would need to check the return
575
-   value  of  all functions and restart_fr_on_each_reply. The destination
576
-   set  would  not  be configured directly in the configuration file, but
577
-   can  be  retrieved  from  the  user  location  database.  In that case
578
-   registered  contacts will be stored in the destination set as branches
579
-   and their q values (provided by UAs) will be used.
574
+   And that's the whole example, we achieved combined serial/parallel
575
+   forking based on the q value of individual branches. In real-world
576
+   configuration files the script writer would need to check the return
577
+   value of all functions and restart_fr_on_each_reply. The destination
578
+   set would not be configured directly in the configuration file, but can
579
+   be retrieved from the user location database. In that case registered
580
+   contacts will be stored in the destination set as branches and their q
581
+   values (provided by UAs) will be used.
580 582
 
581 583
 3. Known Issues
582 584
 
583
-     * Possibly,   performance   could   be   improved   by  not  parsing
584
-       non-INVITEs, as they do not be replied with 100, and do not result
585
-       in  ACK/CANCELs,  and other things which take parsing. However, we
586
-       need  to  rethink  whether  we don't need parsed headers later for
587
-       something  else.  Remember, when we now store a request in sh_mem,
588
-       we  can't apply any pkg_mem operations to it any more. (that might
589
-       be redesigned too).
590
-     * Another  performance  improvement  may  be achieved by not parsing
591
-       CSeq   in   replies  until  reply  branch  matches  branch  of  an
592
-       INVITE/CANCEL in transaction table.
585
+     * Possibly, performance could be improved by not parsing non-INVITEs,
586
+       as they do not be replied with 100, and do not result in
587
+       ACK/CANCELs, and other things which take parsing. However, we need
588
+       to rethink whether we don't need parsed headers later for something
589
+       else. Remember, when we now store a request in sh_mem, we can't
590
+       apply any pkg_mem operations to it any more. (that might be
591
+       redesigned too).
592
+     * Another performance improvement may be achieved by not parsing CSeq
593
+       in replies until reply branch matches branch of an INVITE/CANCEL in
594
+       transaction table.
593 595
      * t_replicate should be done more cleanly--Vias, Routes, etc. should
594
-       be  removed from a message prior to replicating it (well, does not
596
+       be removed from a message prior to replicating it (well, does not
595 597
        matter any longer so much as there is a new replication module).
596 598
 
597 599
 4. Parameters
... ...
@@ -640,6 +642,7 @@ failure_route["serial"]
640 642
    4.42. e2e_cancel_reason (boolean)
641 643
    4.43. remap_503_500 (boolean)
642 644
    4.44. failure_exec_mode (boolean)
645
+   4.45. dns_reuse_rcv_socket (boolean)
643 646
 
644 647
 4.1. fr_timer (integer)
645 648
 
... ...
@@ -657,10 +660,10 @@ modparam("tm", "fr_timer", 10000)
657 660
 
658 661
 4.2. fr_inv_timer (integer)
659 662
 
660
-   Timer  which  hits  if  no  final  reply for an INVITE arrives after a
663
+   Timer which hits if no final reply for an INVITE arrives after a
661 664
    provisional message was received (in milliseconds).
662 665
 
663
-   Note:  this  timer  can  be  restarted  when a provisional response is
666
+   Note: this timer can be restarted when a provisional response is
664 667
    received. For more details see restart_fr_on_each_reply.
665 668
 
666 669
    Default value is 120000 ms (120 seconds).
... ...
@@ -674,33 +677,33 @@ modparam("tm", "fr_inv_timer", 180000)
674 677
 
675 678
 4.3. max_inv_lifetime (integer)
676 679
 
677
-   Maximum  time  an  INVITE  transaction  is  allowed  to  be active (in
678
-   milliseconds).  After  this  interval  has passed from the transaction
679
-   creation,  the transaction will be either moved into the wait state or
680
-   in  the  final  response  retransmission  state,  irrespective  of the
680
+   Maximum time an INVITE transaction is allowed to be active (in
681
+   milliseconds). After this interval has passed from the transaction
682
+   creation, the transaction will be either moved into the wait state or
683
+   in the final response retransmission state, irrespective of the
681 684
    transaction fr_inv_timer and fr_timer values.
682 685
 
683
-   An   INVITE   transaction   will   be  kept  in  memory  for  maximum:
684
-   max_inv_lifetime+fr_timer(from    the   ack   to   the   final   reply
686
+   An INVITE transaction will be kept in memory for maximum:
687
+   max_inv_lifetime+fr_timer(from the ack to the final reply
685 688
    wait)+wt_timer.
686 689
 
687
-   The  main  difference  between this timer and fr_inv_timer is that the
688
-   fr_inv_timer  is  per  branch, while max_inv_lifetime is per the whole
689
-   transaction.  Even  on  a  per  branch  basis  fr_inv_timer  could  be
690
-   restarted.  For example, by default if restart_fr_on_each_reply is not
691
-   cleared,   the  fr_inv_timer  will  be  restarted  for  each  received
692
-   provisional  reply.  Even  if  restart_fr_on_each_reply is not set the
693
-   fr_inv_timer  will  still be restarted for each increasing reply (e.g.
694
-   180,  181,  182,  ...).  Another  example  when a transaction can live
695
-   substantially  more  then  its fr_inv_timer and where max_inv_lifetime
696
-   will  help  is  when dns failover is used (each failed dns destination
697
-   can introduce a new branch).
698
-
699
-   The  default  value  is  180000  ms (180 seconds - the rfc3261 timer C
690
+   The main difference between this timer and fr_inv_timer is that the
691
+   fr_inv_timer is per branch, while max_inv_lifetime is per the whole
692
+   transaction. Even on a per branch basis fr_inv_timer could be
693
+   restarted. For example, by default if restart_fr_on_each_reply is not
694
+   cleared, the fr_inv_timer will be restarted for each received
695
+   provisional reply. Even if restart_fr_on_each_reply is not set the
696
+   fr_inv_timer will still be restarted for each increasing reply (e.g.
697
+   180, 181, 182, ...). Another example when a transaction can live
698
+   substantially more then its fr_inv_timer and where max_inv_lifetime
699
+   will help is when dns failover is used (each failed dns destination can
700
+   introduce a new branch).
701
+
702
+   The default value is 180000 ms (180 seconds - the rfc3261 timer C
700 703
    value).
701 704
 
702
-   See  also:  max_noninv_lifetime, t_set_max_lifetime() (allows changing
703
-   max_inv_lifetime  on  a  per  transaction basis), t_reset_max_lifetime
705
+   See also: max_noninv_lifetime, t_set_max_lifetime() (allows changing
706
+   max_inv_lifetime on a per transaction basis), t_reset_max_lifetime
704 707
    fr_timer, wt_timer, restart_fr_on_each_reply.
705 708
 
706 709
    Example 1.3. Set max_inv_lifetime parameter
... ...
@@ -710,28 +713,27 @@ modparam("tm", "max_inv_lifetime", 150000)
710 713
 
711 714
 4.4. max_noninv_lifetime (integer)
712 715
 
713
-   Maximum  time  a  non-INVITE  transaction  is allowed to be active (in
714
-   milliseconds).  After  this  interval  has passed from the transaction
715
-   creation,  the transaction will be either moved into the wait state or
716
-   in  the  final  response  retransmission  state,  irrespective  of the
716
+   Maximum time a non-INVITE transaction is allowed to be active (in
717
+   milliseconds). After this interval has passed from the transaction
718
+   creation, the transaction will be either moved into the wait state or
719
+   in the final response retransmission state, irrespective of the
717 720
    transaction fr_timer value. It's the same as max_inv_lifetime, but for
718 721
    non-INVITEs.
719 722
 
720
-   A   non-INVITE  transaction  will  be  kept  in  memory  for  maximum:
723
+   A non-INVITE transaction will be kept in memory for maximum:
721 724
    max_noninv_lifetime+wt_timer.
722 725
 
723
-   The  main  difference  between  this  timer  and  fr_timer is that the
724
-   fr_timer  is  per  branch,  while max_noninv_lifetime is per the whole
726
+   The main difference between this timer and fr_timer is that the
727
+   fr_timer is per branch, while max_noninv_lifetime is per the whole
725 728
    transaction. An example when a transaction can live substantially more
726
-   then  its fr_timer and where max_noninv_lifetime will help is when dns
727
-   failover  is  used  (each  failed  dns destination can introduce a new
729
+   then its fr_timer and where max_noninv_lifetime will help is when dns
730
+   failover is used (each failed dns destination can introduce a new
728 731
    branch).
729 732
 
730
-   The  default  value  is  32000  ms  (32  seconds - the rfc3261 timer F
731
-   value).
733
+   The default value is 32000 ms (32 seconds - the rfc3261 timer F value).
732 734
 
733
-   See  also:  max_inv_lifetime,  t_set_max_lifetime()  (allows  changing
734
-   max_noninv_lifetime  on a per transaction basis), t_reset_max_lifetime
735
+   See also: max_inv_lifetime, t_set_max_lifetime() (allows changing
736
+   max_noninv_lifetime on a per transaction basis), t_reset_max_lifetime
735 737
    fr_timer, wt_timer.
736 738
 
737 739
    Example 1.4. Set max_noninv_lifetime parameter
... ...
@@ -741,11 +743,11 @@ modparam("tm", "max_noninv_lifetime", 30000)
741 743
 
742 744
 4.5. wt_timer (integer)
743 745
 
744
-   Time  for  which  a  transaction  stays  in  memory  to absorb delayed
745
-   messages  after  it completed (in milliseconds); also, when this timer
746
-   hits,  retransmission  of  local  cancels  is  stopped (a puristic but
747
-   complex behavior would be not to enter wait state until local branches
748
-   are finished by a final reply or FR timer--we simplified).
746
+   Time for which a transaction stays in memory to absorb delayed messages
747
+   after it completed (in milliseconds); also, when this timer hits,
748
+   retransmission of local cancels is stopped (a puristic but complex
749
+   behavior would be not to enter wait state until local branches are
750
+   finished by a final reply or FR timer--we simplified).
749 751
 
750 752
    Default value is 5000 ms (5 seconds).
751 753
 
... ...
@@ -756,11 +758,11 @@ modparam("tm", "wt_timer", 1000)
756 758
 
757 759
 4.6. delete_timer (integer)
758 760
 
759
-   Time  after  which  a  to-be-deleted transaction currently ref-ed by a
761
+   Time after which a to-be-deleted transaction currently ref-ed by a
760 762
    process will be tried to be deleted again (in milliseconds).
761 763
 
762
-   Note:  this  parameter is obsolete for ser 2.1 (in 2.1 the transaction
763
-   is deleted the moment it's not referenced anymore).
764
+   Note: this parameter is obsolete for ser 2.1 (in 2.1 the transaction is
765
+   deleted the moment it's not referenced anymore).
764 766
 
765 767
    Default value is 200 milliseconds.
766 768
 
... ...
@@ -782,8 +784,8 @@ modparam("tm", "retr_timer1", 1000)
782 784
 
783 785
 4.8. retr_timer2 (integer)
784 786
 
785
-   Maximum  retransmission  period  (in milliseconds). The retransmission
786
-   interval  starts  with retr_timer1 and increases until it reaches this
787
+   Maximum retransmission period (in milliseconds). The retransmission
788
+   interval starts with retr_timer1 and increases until it reaches this
787 789
    value. After this it stays constant at retr_timer2.
788 790
 
789 791
    Default value is 4000 milliseconds.
... ...
@@ -795,16 +797,15 @@ modparam("tm", "retr_timer2", 2000)
795 797
 
796 798
 4.9. noisy_ctimer (integer)
797 799
 
798
-   If  set,  INVITE  transactions  that  time-out  (FR INV timer) will be
799
-   always  replied.  If it's not set, the transaction has only one branch
800
-   and  no response was ever received on this branch, it will be silently
801
-   dropped  (no  408 reply will be generated) This behavior is overridden
802
-   if  a  request  is  forked,  the  transaction  has  a failure route or
803
-   callback,  or  some  functionality  explicitly  turned  it  on  for  a
804
-   transaction  (like  acc  does to avoid unaccounted transactions due to
805
-   expired  timer).  Turn  this off only if you know the client UACs will
806
-   timeout  and their timeout interval for INVITEs is lower or equal than
807
-   tm's fr_inv_timer.
800
+   If set, INVITE transactions that time-out (FR INV timer) will be always
801
+   replied. If it's not set, the transaction has only one branch and no
802
+   response was ever received on this branch, it will be silently dropped
803
+   (no 408 reply will be generated) This behavior is overridden if a
804
+   request is forked, the transaction has a failure route or callback, or
805
+   some functionality explicitly turned it on for a transaction (like acc
806
+   does to avoid unaccounted transactions due to expired timer). Turn this
807
+   off only if you know the client UACs will timeout and their timeout
808
+   interval for INVITEs is lower or equal than tm's fr_inv_timer.
808 809
 
809 810
    Default value is 1 (on).
810 811
 
... ...
@@ -815,15 +816,15 @@ modparam("tm", "noisy_ctimer", 1)
815 816
 
816 817
 4.10. restart_fr_on_each_reply (integer)
817 818
 
818
-   If  set  (default), the fr_inv_timer for an INVITE transaction will be
819
-   restarted  for  each  provisional  reply  received  (rfc3261  mandated
820
-   behaviour).  If  not  set, the fr_inv_timer will be restarted only for
821
-   the  first  provisional  replies and for increasing replies greater or
822
-   equal 180 (e.g. 180, 181, 182, 185, ...).
819
+   If set (default), the fr_inv_timer for an INVITE transaction will be
820
+   restarted for each provisional reply received (rfc3261 mandated
821
+   behaviour). If not set, the fr_inv_timer will be restarted only for the
822
+   first provisional replies and for increasing replies greater or equal
823
+   180 (e.g. 180, 181, 182, 185, ...).
823 824
 
824
-   Setting  it  to  0 is especially useful when dealing with bad UAs that
825
-   continuously  retransmit 180s, not allowing the transaction to timeout
826
-   (and  thus  making  impossible the implementation of certain services,
825
+   Setting it to 0 is especially useful when dealing with bad UAs that
826
+   continuously retransmit 180s, not allowing the transaction to timeout
827
+   (and thus making impossible the implementation of certain services,
827 828
    like automatic voicemail after x seconds).
828 829
 
829 830
    Default value is 1 (on).
... ...
@@ -839,11 +840,11 @@ modparam("tm", "restart_fr_on_each_reply", 0)
839 840
 
840 841
    If set (default) tm will automatically send and 100 reply to INVITEs.
841 842
 
842
-   Setting  it  to  0 one can be used to enable doing first some tests or
843
-   pre-processing  on  the  INVITE  and  only  if some conditions are met
844
-   manually  send a 100 (using t_reply()). Note however that in this case
845
-   all  the  100s  have  to be sent "by hand". t_set_auto_inv_100() might
846
-   help  to  selectively  turn  off  this  feature only for some specific
843
+   Setting it to 0 one can be used to enable doing first some tests or
844
+   pre-processing on the INVITE and only if some conditions are met
845
+   manually send a 100 (using t_reply()). Note however that in this case
846
+   all the 100s have to be sent "by hand". t_set_auto_inv_100() might help
847
+   to selectively turn off this feature only for some specific
847 848
    transactions.
848 849
 
849 850
    Default value is 1 (on).
... ...
@@ -872,8 +873,8 @@ modparam("tm", "auto_inv_100_reason", "Trying")
872 873
 
873 874
    Unix socket transmission timeout, in milliseconds.
874 875
 
875
-   If  unix sockets are used (e.g.: to communicate with sems) and sending
876
-   a message on a unix socket takes longer then unix_tx_timeout, the send
876
+   If unix sockets are used (e.g.: to communicate with sems) and sending a
877
+   message on a unix socket takes longer then unix_tx_timeout, the send
877 878
    will fail.
878 879
 
879 880
    The default value is 500 milliseconds.
... ...
@@ -885,13 +886,13 @@ modparam("tm", "unix_tx_timeout", 250)
885 886
 
886 887
 4.14. aggregate_challenges (integer)
887 888
 
888
-   If  set (default), the final reply is a 401 or a 407 and more then one
889
-   branch  received  a  401  or  407,  then  all the WWW-Authenticate and
890
-   Proxy-Authenticate  headers  from  all the 401 and 407 replies will be
891
-   aggregated  in  a  new  final  reply.  If only one branch received the
892
-   winning  401 or 407 then this reply will be forwarded (no new one will
893
-   be  built).  If  0  only  the first 401, or if no 401 was received the
894
-   first 407, will be forwarded (no header aggregation).
889
+   If set (default), the final reply is a 401 or a 407 and more then one
890
+   branch received a 401 or 407, then all the WWW-Authenticate and
891
+   Proxy-Authenticate headers from all the 401 and 407 replies will be
892
+   aggregated in a new final reply. If only one branch received the
893
+   winning 401 or 407 then this reply will be forwarded (no new one will
894
+   be built). If 0 only the first 401, or if no 401 was received the first
895
+   407, will be forwarded (no header aggregation).
895 896
 
896 897
    Default value is 1 (required by rfc3261).
897 898
 
... ...
@@ -903,20 +904,20 @@ modparam("tm", "aggregate_challenges", 0)
903 904
 4.15. reparse_invite (integer)
904 905
 
905 906
    If set (default), the CANCEL and negative ACK requests are constructed
906
-   from  the  INVITE  message which was sent out instead of building them
907
-   from  the  received  request.  The  disadvantage  is that the outgoing
908
-   INVITE  has  to  be  partially  re-parsed,  the  advantage is that the
909
-   CANCEL/ACK  is  always RFC 3261-compliant, it always contains the same
910
-   route-set  as the INVITE message. Do not disable the INVITE re-parsing
911
-   for example in the following cases:
912
-
913
-   -  The  INVITE  contains  a  preloaded route-set, and SER forwards the
914
-   message  to  the  next  hop  according  to the Route header. The Route
915
-   header is not removed in the CANCEL without reparse_invite=1.
916
-
917
-   -  SER record-routes, thus an in-dialog INVITE contains a Route header
918
-   which  is  removed  during  loose  routing. If the in-dialog INVITE is
919
-   rejected,  the  negative  ACK  still contains the Route header without
907
+   from the INVITE message which was sent out instead of building them
908
+   from the received request. The disadvantage is that the outgoing INVITE
909
+   has to be partially re-parsed, the advantage is that the CANCEL/ACK is
910
+   always RFC 3261-compliant, it always contains the same route-set as the
911
+   INVITE message. Do not disable the INVITE re-parsing for example in the
912
+   following cases:
913
+
914
+   - The INVITE contains a preloaded route-set, and SER forwards the
915
+   message to the next hop according to the Route header. The Route header
916
+   is not removed in the CANCEL without reparse_invite=1.
917
+
918
+   - SER record-routes, thus an in-dialog INVITE contains a Route header
919
+   which is removed during loose routing. If the in-dialog INVITE is
920
+   rejected, the negative ACK still contains the Route header without
920 921
    reparse_invite=1.
921 922
 
922 923
    Default value is 1.
... ...
@@ -928,13 +929,13 @@ modparam("tm", "reparse_invite", 0)
928 929
 
929 930
 4.16. ac_extra_hdrs (string)
930 931
 
931
-   Header  fields  prefixed  by  this parameter value are included in the
932
-   CANCEL  and negative ACK messages if they were present in the outgoing
932
+   Header fields prefixed by this parameter value are included in the
933
+   CANCEL and negative ACK messages if they were present in the outgoing
933 934
    INVITE.
934 935
 
935
-   Note,  that  the  parameter value effects only those headers which are
936
-   not covered by RFC-3261 (which are neither mandatory nor prohibited in
937
-   CANCEL  and  ACK),  and  the  parameter can be used only together with
936
+   Note, that the parameter value effects only those headers which are not
937
+   covered by RFC-3261 (which are neither mandatory nor prohibited in
938
+   CANCEL and ACK), and the parameter can be used only together with
938 939
    reparse_invite=1.
939 940
 
940 941
    Default value is "".
... ...
@@ -949,10 +950,10 @@ modparam("tm", "ac_extra_hdrs", "myfavoriteheaders-")
949 950
    If set and the blacklist support is enabled, every 503 reply source is
950 951
    added to the blacklist. The initial blacklist timeout (or ttl) depends
951 952
    on the presence of a Retry-After header in the reply and the values of
952
-   the      following      tm      parameters:      blst_503_def_timeout,
953
-   blst_503_min_timeout and blst_503_max_timeout.
953
+   the following tm parameters: blst_503_def_timeout, blst_503_min_timeout
954
+   and blst_503_max_timeout.
954 955
 
955
-   WARNING:blindly   allowing  503  blacklisting  could  be  very  easily
956
+   WARNING:blindly allowing 503 blacklisting could be very easily
956 957
    exploited for DOS attacks in most network setups.
957 958
 
958 959
    The default value is 0 (disabled due to the reasons above).
... ...
@@ -964,12 +965,12 @@ modparam("tm", "blst_503", 1)
964 965
 
965 966
 4.18. blst_503_def_timeout (integer)
966 967
 
967
-   Blacklist  interval  in  seconds  for  a 503 reply with no Retry-After
968
-   header.     See     also     blst_503,     blst_503_min_timeout    and
968
+   Blacklist interval in seconds for a 503 reply with no Retry-After
969
+   header. See also blst_503, blst_503_min_timeout and
969 970
    blst_503_max_timeout.
970 971
 
971
-   The  default  value is 0, which means that if no Retry-After header is
972
-   present,  the 503 reply source will not be blacklisted (rfc conformant
972
+   The default value is 0, which means that if no Retry-After header is
973
+   present, the 503 reply source will not be blacklisted (rfc conformant
973 974
    behaviour).
974 975
 
975 976
    Example 1.18. Set blst_503_def_timeout parameter
... ...
@@ -979,9 +980,9 @@ modparam("tm", "blst_503_def_timeout", 120)
979 980
 
980 981
 4.19. blst_503_min_timeout (integer)
981 982
 
982
-   Minimum  blacklist  interval  in  seconds  for  a  503  reply  with  a
983
-   Retry-After  header.  It  will  be  used  if  the Retry-After value is
984
-   smaller.     See     also     blst_503,    blst_503_def_timeout    and
983
+   Minimum blacklist interval in seconds for a 503 reply with a
984
+   Retry-After header. It will be used if the Retry-After value is
985
+   smaller. See also blst_503, blst_503_def_timeout and
985 986
    blst_503_max_timeout.
986 987
 
987 988
    The default value is 0
... ...
@@ -993,9 +994,9 @@ modparam("tm", "blst_503_min_timeout", 30)
993 994
 
994 995
 4.20. blst_503_max_timeout (integer)
995 996
 
996
-   Maximum  blacklist  interval  in  seconds  for  a  503  reply  with  a
997
-   Retry-After  header.  It  will  be  used  if  the Retry-After value is
998
-   greater.     See     also     blst_503,    blst_503_def_timeout    and
997
+   Maximum blacklist interval in seconds for a 503 reply with a
998
+   Retry-After header. It will be used if the Retry-After value is
999
+   greater. See also blst_503, blst_503_def_timeout and
999 1000
    blst_503_min_timeout.
1000 1001
 
1001 1002
    The default value is 3600
... ...
@@ -1007,19 +1008,19 @@ modparam("tm", "blst_503_max_timeout", 604800)
1007 1008
 
1008 1009
 4.21. blst_methods_add (unsigned integer)
1009 1010
 
1010
-   Bitmap  of  method  types  that  trigger  blacklisting  on transaction
1011
-   timeouts.  (This setting has no effect on blacklisting because of send
1011
+   Bitmap of method types that trigger blacklisting on transaction
1012
+   timeouts. (This setting has no effect on blacklisting because of send
1012 1013
    failures.)
1013 1014
 
1014
-   The  following values are associated to the request methods: INVITE=1,
1015
-   CANCEL=2,  ACK=4  (not  retransmitted,  thus, never times-out), BYE=8,
1016
-   INFO=16,  REGISTER=32,  SUBSCRIBE=64,  NOTIFY=126,  OTHER=256 (all the
1015
+   The following values are associated to the request methods: INVITE=1,
1016
+   CANCEL=2, ACK=4 (not retransmitted, thus, never times-out), BYE=8,
1017
+   INFO=16, REGISTER=32, SUBSCRIBE=64, NOTIFY=126, OTHER=256 (all the
1017 1018
    unknown types). Check parser/msg_parser.h for farther details.
1018 1019
 
1019
-   Change  the  value  carefully, because requests not having provisional
1020
-   response  (everything  but INVITE) can easily cause the next hop to be
1021
-   inserted  into the blacklist by mistake. For exmaple the next hop is a
1022
-   proxy,  it  is alive, but waiting for the response of the UAS, and has
1020
+   Change the value carefully, because requests not having provisional
1021
+   response (everything but INVITE) can easily cause the next hop to be
1022
+   inserted into the blacklist by mistake. For exmaple the next hop is a
1023
+   proxy, it is alive, but waiting for the response of the UAS, and has
1023 1024
    higher fr_timer value.
1024 1025
 
1025 1026
    The default value is 1, only INVITEs trigger blacklisting
... ...
@@ -1032,7 +1033,7 @@ modparam("tm", "blst_methods_add", 33)
1032 1033
 
1033 1034
 4.22. blst_methods_lookup (unsigned integer)
1034 1035
 
1035
-   Bitmap  of  method  types  that  are looked-up in the blacklist before
1036
+   Bitmap of method types that are looked-up in the blacklist before
1036 1037
    statefull forwarding. See also blst_methods_add
1037 1038
 
1038 1039
    The default value is 4294967287, every method type except BYE. (We try
... ...
@@ -1046,34 +1047,34 @@ modparam("tm", "blst_methods_lookup", 1)
1046 1047
 
1047 1048
 4.23. cancel_b_method (integer)
1048 1049
 
1049
-   Method  used when attempting to CANCEL an unreplied transaction branch
1050
-   (a  branch  where  no reply greater the 99 was received). The possible
1050
+   Method used when attempting to CANCEL an unreplied transaction branch
1051
+   (a branch where no reply greater the 99 was received). The possible
1051 1052
    values are 0, 1, and 2.
1052 1053
 
1053
-   0  will  immediately  stop  the request (INVITE) retransmission on the
1054
-   branch  and  it  will  behave as if the branch was immediately replied
1055
-   with a 487 (a fake internal 487 reply). The advantage is the unreplied
1056
-   branches  will be terminated immediately. However it introduces a race
1054
+   0 will immediately stop the request (INVITE) retransmission on the
1055
+   branch and it will behave as if the branch was immediately replied with
1056
+   a 487 (a fake internal 487 reply). The advantage is the unreplied
1057
+   branches will be terminated immediately. However it introduces a race
1057 1058
    risk with a possible slightly delayed 2xx reply. In this case we could
1058
-   have  an UA receiving a 2xx after a 487. Moreover this risk is greatly
1059
-   amplified  by packet loss (e.g. if an 180 is lost the branch will look
1059
+   have an UA receiving a 2xx after a 487. Moreover this risk is greatly
1060
+   amplified by packet loss (e.g. if an 180 is lost the branch will look
1060 1061
    as unreplied and a CANCEL will silently drop the branch, but a 2xx can
1061
-   still  come  at  a later time). This is the behaviour for ser versions
1062
+   still come at a later time). This is the behaviour for ser versions
1062 1063
    older then 2.1.
1063 1064
 
1064
-   1  will  keep  retransmitting  the request on unreplied branches. If a
1065
+   1 will keep retransmitting the request on unreplied branches. If a
1065 1066
    provisional answer is later received a CANCEL will be immediately sent
1066 1067
    back (attempting to quickly trigger a 487). This approach is race free
1067
-   and  avoids  the  2xx  after  487  problem,  but  it's  more  resource
1068
-   intensive:  faced  with a branch towards and UA that doesn't answer, a
1069
-   CANCEL  attempt  will keep the transaction alive for the whole timeout
1070
-   interval (fr_timer).
1068
+   and avoids the 2xx after 487 problem, but it's more resource intensive:
1069
+   faced with a branch towards and UA that doesn't answer, a CANCEL
1070
+   attempt will keep the transaction alive for the whole timeout interval
1071
+   (fr_timer).
1071 1072
 
1072 1073
    2 will send and retransmit CANCEL even on unreplied branches, stopping
1073
-   the  request  retransmissions.  This  has the same advantages as 1 and
1074
-   also  avoids the extra roundtrip in the case of the provisional reply,
1075
-   but  it's not RFC 3261 conforming (the RFC allows sending CANCELs only
1076
-   on pending branches).
1074
+   the request retransmissions. This has the same advantages as 1 and also
1075
+   avoids the extra roundtrip in the case of the provisional reply, but
1076
+   it's not RFC 3261 conforming (the RFC allows sending CANCELs only on
1077
+   pending branches).
1077 1078
 
1078 1079
    The default value is 1.
1079 1080
 
... ...
@@ -1084,23 +1085,23 @@ modparam("tm", "cancel_b_method", 1)
1084 1085
 
1085 1086
 4.24. reparse_on_dns_failover (integer)
1086 1087
 
1087
-   If  set to 1, the SIP message after a DNS failover is constructed from
1088
-   the  outgoing  message buffer of the failed branch instead of from the
1088
+   If set to 1, the SIP message after a DNS failover is constructed from
1089
+   the outgoing message buffer of the failed branch instead of from the
1089 1090
    received request.
1090 1091
 
1091
-   It  must be set if multiple branches are installed, the SIP message is
1092
-   modified  differently  in them, and at least one of them can result in
1092
+   It must be set if multiple branches are installed, the SIP message is
1093
+   modified differently in them, and at least one of them can result in
1093 1094
    DNS failover. If the parameter is not set the per-branch modifications
1094 1095
    are lost after the failover.
1095 1096
 
1096
-   Note:   If   the   parameter   is   set,   branch   route   block  and
1097
+   Note: If the parameter is set, branch route block and
1097 1098
    TMCB_REQUEST_FWDED callback are not called in case of the failover.
1098 1099
 
1099
-   Disadvantage:  only  the via header is replaced in the message buffer,
1100
-   so  the  outgoing socket address is not corrected in any other part of
1101
-   the  message.  It  is  dangerous on multihomed hosts: when the new SIP
1102
-   request  after  the  DNS failover is sent via different interface than
1103
-   the first request, the message can contain incorrect ip address in the
1100
+   Disadvantage: only the via header is replaced in the message buffer, so
1101
+   the outgoing socket address is not corrected in any other part of the
1102
+   message. It is dangerous on multihomed hosts: when the new SIP request
1103
+   after the DNS failover is sent via different interface than the first
1104
+   request, the message can contain incorrect ip address in the
1104 1105
    Record-Route header for instance.
1105 1106
 
1106 1107
    Default value is 1.
... ...
@@ -1112,10 +1113,10 @@ modparam("tm", "reparse_on_dns_failover", 0)
1112 1113
 
1113 1114
 4.25. on_sl_reply (string)
1114 1115
 
1115
-   Sets  reply  route  block,  to which control is passed when a reply is
1116
-   received  that  has  no associated transaction. The reply is passed to
1117
-   the  core  for  stateless  forwarding  after the route block execution
1118
-   unless it returns 0.
1116
+   Sets reply route block, to which control is passed when a reply is
1117
+   received that has no associated transaction. The reply is passed to the
1118
+   core for stateless forwarding after the route block execution unless it
1119
+   returns 0.
1119 1120
 
1120 1121
    Example 1.25. Set on_sl_reply parameter
1121 1122
 ...
... ...
@@ -1129,12 +1130,12 @@ onreply_route["stateless_replies"] {
1129 1130
 
1130 1131
 4.26. contacts_avp (string)
1131 1132
 
1132
-   This  is  the  name of an XAVP that t_load_contacts() function uses to
1133
-   store  contacts  of  the  destination  set  and that t_next_contacts()
1133
+   This is the name of an XAVP that t_load_contacts() function uses to
1134
+   store contacts of the destination set and that t_next_contacts()
1134 1135
    function uses to restore those contacts.
1135 1136
 
1136 1137
    Default value is "NULL" (t_load_contacts()/t_next_contacts() functions
1137
-   are disabled). 
1138
+   are disabled).
1138 1139
 
1139 1140
    Example 1.26. Set contacts_avp parameter
1140 1141
 ...
... ...
@@ -1143,13 +1144,13 @@ modparam("tm", "contacts_avp", "tm_contacts")
1143 1144
 
1144 1145
 4.27. contact_flows_avp (string)
1145 1146
 
1146
-   This  is  the  name of an XAVP that t_next_contacts() function uses to
1147
-   store  contacts  (if any) that it skipped, because they contained same
1148
-   +sip.instance    value    than    some   other   contact,   and   that
1147
+   This is the name of an XAVP that t_next_contacts() function uses to
1148
+   store contacts (if any) that it skipped, because they contained same
1149
+   +sip.instance value than some other contact, and that
1149 1150
    t_next_contact_flows() function uses to restore those contacts.
1150 1151
 
1151
-   Default  value  is  "NULL".  This  parameter  MUST  be set if variable
1152
-   contacts_avp is set. 
1152
+   Default value is "NULL". This parameter MUST be set if variable
1153
+   contacts_avp is set.
1153 1154
 
1154 1155
    Example 1.27. Set contact_flows_avp parameter
1155 1156
 ...
... ...
@@ -1159,29 +1160,29 @@ modparam("tm", "contact_flows_avp", "tm_contact_flows")
1159 1160
 4.28. fr_timer_avp (string)
1160 1161
 
1161 1162
    The value of fr_timer timer can be overriden on per-transaction basis.
1162
-   The  administrator  can  provide  a  value to be used for a particular
1163
-   transaction  in  an  AVP.  This parameter contains the name of the AVP
1164
-   that  will  be  checked. If the AVP exists then its value will be used
1165
-   for the fr_timer timer, effectively overriding the value configured in
1166
-   fr_timer parameter for the current transaction.
1163
+   The administrator can provide a value to be used for a particular
1164
+   transaction in an AVP. This parameter contains the name of the AVP that
1165
+   will be checked. If the AVP exists then its value will be used for the
1166
+   fr_timer timer, effectively overriding the value configured in fr_timer
1167
+   parameter for the current transaction.
1167 1168
 
1168
-   The  value of this parameter is the the name of the AVP to be checked,
1169
+   The value of this parameter is the the name of the AVP to be checked,
1169 1170
    without the $ character or "$avp" prefix.
1170 1171
 
1171 1172
 Note
1172 1173
 
1173
-   The  value  of  the AVP is expected to be expressed in seconds and not
1174
+   The value of the AVP is expected to be expressed in seconds and not
1174 1175
    milliseconds (unlike the rest of the timers).
1175 1176
 
1176
-   This  parameter  is  kept for backwards compatibility (hence its value
1177
-   expressed  in  seconds  instead  of milliseconds and its arcane way of
1178
-   specifying  the avps). The recommended replacement is using t_set_fr()
1177
+   This parameter is kept for backwards compatibility (hence its value
1178
+   expressed in seconds instead of milliseconds and its arcane way of
1179
+   specifying the avps). The recommended replacement is using t_set_fr()
1179 1180
    on a per transaction basis.
1180 1181
 
1181 1182
    See also: t_set_fr(), fr_timer.
1182 1183
 
1183
-   In  Kamailio  compatibility mode (defined by #!KAMAILIO), the value of
1184
-   the  parameter  must  be the name of an AVP in pseudo-variable format:
1184
+   In Kamailio compatibility mode (defined by #!KAMAILIO), the value of
1185
+   the parameter must be the name of an AVP in pseudo-variable format:
1185 1186
    $avp(name). In SER compatibility mode it must by just AVP name.
1186 1187
 
1187 1188
    Example 1.28. Set fr_timer_avp parameter
... ...
@@ -1193,31 +1194,31 @@ modparam("tm", "fr_timer_avp", "$avp(i:708)")
1193 1194
 
1194 1195
 4.29. fr_inv_timer_avp (string)
1195 1196
 
1196
-   The  value  of  fr_inv_timer timer can be overriden on per-transaction
1197
-   basis.  The  administrator  can  provide  a  value  to  be  used for a
1198
-   particular  transaction in an AVP. This parameter contains the name of
1199
-   the  AVP  that  will  be  checked. If the AVP exists, is non-empty and
1200
-   non-zero  then  its  value  will  be  used for the fr_inv_timer timer,
1201
-   effectively  overriding the value configured in fr_inv_timer parameter
1197
+   The value of fr_inv_timer timer can be overriden on per-transaction
1198
+   basis. The administrator can provide a value to be used for a
1199
+   particular transaction in an AVP. This parameter contains the name of
1200
+   the AVP that will be checked. If the AVP exists, is non-empty and
1201
+   non-zero then its value will be used for the fr_inv_timer timer,
1202
+   effectively overriding the value configured in fr_inv_timer parameter
1202 1203
    for the current transaction.
1203 1204
 
1204
-   The  value of this parameter is the the name of the AVP to be checked,
1205
+   The value of this parameter is the the name of the AVP to be checked,
1205 1206
    without the $ character or "$avp" prefix.
1206 1207
 
1207 1208
 Note
1208 1209
 
1209
-   The  value  of  the AVP is expected to be expressed in seconds and not
1210
+   The value of the AVP is expected to be expressed in seconds and not
1210 1211
    milliseconds (unlike the rest of the timers).
1211 1212
 
1212
-   This  parameter  is  kept for backwards compatibility (hence its value
1213
-   expressed  in  seconds  instead  of milliseconds and its arcane way of
1214
-   specifying  the avps). The recommended replacement is using t_set_fr()
1213
+   This parameter is kept for backwards compatibility (hence its value
1214
+   expressed in seconds instead of milliseconds and its arcane way of
1215
+   specifying the avps). The recommended replacement is using t_set_fr()
1215 1216
    on a per transaction basis.
1216 1217
 
1217 1218
    See also: t_set_fr(), fr_inv_timer.
1218 1219
 
1219
-   In  Kamailio  compatibility mode (defined by #!KAMAILIO), the value of
1220
-   the  parameter  must  be the name of an AVP in pseudo-variable format:
1220
+   In Kamailio compatibility mode (defined by #!KAMAILIO), the value of
1221
+   the parameter must be the name of an AVP in pseudo-variable format:
1221 1222
    $avp(name). In SER compatibility mode it must by just AVP name.
1222 1223
 
1223 1224
    Example 1.29. Set fr_inv_timer_avp parameter
... ...
@@ -1229,16 +1230,15 @@ modparam("tm", "fr_inv_timer_avp", "$avp(my_fr_inv_timer)")
1229 1230
 
1230 1231
 4.30. unmatched_cancel (string)
1231 1232
 
1232
-   This  parameter  selects  between forwarding CANCELs that do not match
1233
-   any  transaction  statefully  (0,  default  value), statelessly (1) or
1234
-   dropping   them  (2).  Note  that  the  statefull  forwarding  has  an
1235
-   additional hidden advantage: tm will be able to recognize INVITEs that
1236
-   arrive  after  their CANCEL. Note also that this feature could be used
1237
-   to   try   a  memory  exhaustion  DOS  attack  against  a  proxy  that
1238
-   authenticates  all  requests, by continuously flooding the victim with
1239
-   CANCELs   to   random   destinations   (since  the  CANCEL  cannot  be
1240
-   authenticated,   each   received   bogus  CANCEL  will  create  a  new
1241
-   transaction that will live by default 30s).
1233
+   This parameter selects between forwarding CANCELs that do not match any
1234
+   transaction statefully (0, default value), statelessly (1) or dropping
1235
+   them (2). Note that the statefull forwarding has an additional hidden
1236
+   advantage: tm will be able to recognize INVITEs that arrive after their
1237
+   CANCEL. Note also that this feature could be used to try a memory
1238
+   exhaustion DOS attack against a proxy that authenticates all requests,
1239
+   by continuously flooding the victim with CANCELs to random destinations
1240
+   (since the CANCEL cannot be authenticated, each received bogus CANCEL
1241
+   will create a new transaction that will live by default 30s).
1242 1242
 
1243 1243
    Default value is 0.
1244 1244
 
... ...
@@ -1249,11 +1249,11 @@ modparam("tm", "unmatched_cancel", "2")
1249 1249
 
1250 1250
 4.31. ruri_matching (integer)
1251 1251
 
1252
-   If  set  it will also try to match the request uri when doing pre-3261
1253
-   transaction  matching  (the  via branch parameter does not contain the
1252
+   If set it will also try to match the request uri when doing pre-3261
1253
+   transaction matching (the via branch parameter does not contain the
1254 1254
    3261 cookie).
1255 1255
 
1256
-   The  only  reason to have it not set is for interoperability with old,
1256
+   The only reason to have it not set is for interoperability with old,
1257 1257
    broken implementations.
1258 1258
 
1259 1259
    Default value is 1 (on).
... ...
@@ -1268,11 +1268,11 @@ modparam("tm", "ruri_matching", 1)
1268 1268
 
1269 1269
 4.32. via1_matching (integer)
1270 1270
 
1271
-   If  set  it will also try to match the topmost via when doing pre-3261
1272
-   transaction  matching  (the  via branch parameter does not contain the
1271
+   If set it will also try to match the topmost via when doing pre-3261
1272
+   transaction matching (the via branch parameter does not contain the
1273 1273
    3261 cookie).
1274 1274
 
1275
-   The  only  reason to have it not set is for interoperability with old,
1275
+   The only reason to have it not set