/
README
796 lines (589 loc) · 24.7 KB
/
README
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
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
rr Module
Jan Janak
FhG FOKUS
Bogdan-Andrei Iancu
Voice Sistem SRL
Carsten Bock
ng-voice.com
Edited by
Jan Janak
Bogdan-Andrei Iancu
Copyright © 2003 FhG FOKUS
Copyright © 2005 Voice Sistem SRL
Copyright © 2011 Carsten Bock, carsten@ng-voice.com
__________________________________________________________________
Table of Contents
1. Admin Guide
1. Overview
2. Dialog support
3. Dependencies
3.1. Kamailio Modules
3.2. External Libraries or Applications
4. Parameters
4.1. enable_full_lr (integer)
4.2. append_fromtag (integer)
4.3. enable_double_rr (integer)
4.4. add_username (integer)
4.5. enable_socket_mismatch_warning (integer)
4.6. custom_user_avp (avp string)
4.7. force_send_socket (int)
4.8. ignore_sips (int)
4.9. sockname_mode (int)
5. Functions
5.1. loose_route()
5.2. record_route([sparams])
5.3. remove_record_route()
5.4. record_route_preset(string [,string2])
5.5. record_route_advertised_address(address)
5.6. add_rr_param(param)
5.7. check_route_param(re)
5.8. is_direction(dir)
5.9. rr_next_hop_route()
6. Exported Pseudo Variables
6.1. $route_uri
2. Developer Guide
1. Available Functions
1.1. record_route(string)
1.2. record_route_advertised_address(string)
1.3. add_rr_param( msg, param)
1.4. check_route_param( msg, re)
1.5. is_direction( msg, dir)
1.6. get_route_param( msg, name, val)
1.7. register_rrcb( callback, param)
2. Examples
List of Examples
1.1. Dialog support in RR module
1.2. Set enable_full_lr parameter
1.3. Set append_fromtag parameter
1.4. Set enable_double_rr parameter
1.5. Set enable_double_rr to 2 to always have two explicit RR headers
1.6. Set add_username parameter
1.7. enable_socket_mismatch_warning usage
1.8. custom_user_avp usage
1.9. Set force_send_socket parameter
1.10. Set ignore_sips parameter
1.11. Set sockname_mode parameter
1.12. loose_route usage
1.13. record_route usage
1.14. remove_record_route usage
1.15. record_route_preset usage
1.16. record_route_advertised_address usage
1.17. add_rr_param usage
1.18. check_route_param usage
1.19. is_direction usage
1.20. rr_next_hop_route usage
1.21. $route_uri
2.1. record_route usage
2.2. record_route_advertised_address usage
2.3. Loading RR module's API from another module
Chapter 1. Admin Guide
Table of Contents
1. Overview
2. Dialog support
3. Dependencies
3.1. Kamailio Modules
3.2. External Libraries or Applications
4. Parameters
4.1. enable_full_lr (integer)
4.2. append_fromtag (integer)
4.3. enable_double_rr (integer)
4.4. add_username (integer)
4.5. enable_socket_mismatch_warning (integer)
4.6. custom_user_avp (avp string)
4.7. force_send_socket (int)
4.8. ignore_sips (int)
4.9. sockname_mode (int)
5. Functions
5.1. loose_route()
5.2. record_route([sparams])
5.3. remove_record_route()
5.4. record_route_preset(string [,string2])
5.5. record_route_advertised_address(address)
5.6. add_rr_param(param)
5.7. check_route_param(re)
5.8. is_direction(dir)
5.9. rr_next_hop_route()
6. Exported Pseudo Variables
6.1. $route_uri
1. Overview
The module contains record routing logic
2. Dialog support
Kamailio is basically only a transaction stateful proxy, without any
dialog support build in. There are many features/services which
actually requires a dialog awareness, like storing the information in
the dialog creation stage, information which will be used during the
whole dialog existence.
The most urging example is NAT traversal, in dealing with the within
the dialog INVITEs (re-INVITEs). When processing the initial INVITE,
the proxy detects if the caller or callee is behind some NAT and fixes
the signalling and media parts - since not all the detection mechanism
are available for within the dialog requests (like usrloc), to be able
to fix correspondingly the sequential requests, the proxy must remember
that the original request was NAT processed. There are many other cases
where dialog awareness fixes or helps.
The solution is to store additional dialog-related information in the
routing set (Record-Route/Route headers), headers which show up in all
sequential requests. So any information added to the Record-Route
header will be found (with no direction dependencies) in Route header
(corresponding to the proxy address).
As storage container, the parameters of the Record-Route / Route header
will be used - Record-Route parameters mirroring are reinforced by RFC
3261 (see 12.1.1 UAS behavior).
For this purpose, the modules offers the following functions:
* add_rr_param() - see ???
* check_route_param() - see ???
Example 1.1. Dialog support in RR module
...
UAC Kamailio PROXY UAS
---- INVITE ------> record_route() ----- INVITE ---->
add_rr_param(";foo=true")
--- reINVITE -----> loose_route() ---- reINVITE --->
check_route_param(";foo=true")
<-- reINVITE ------ loose_route() <--- reINVITE ----
check_route_param(";foo=true")
<------ BYE ------- loose_route() <----- BYE -------
check_route_param(";foo=true")
...
3. Dependencies
3.1. Kamailio Modules
3.2. External Libraries or Applications
3.1. Kamailio Modules
The following modules must be loaded before this module:
* (optional) The "outbound" module is needed for outbound routing as
per RFC 5626.
3.2. External Libraries or Applications
The following libraries or applications must be installed before
running Kamailio with this module loaded:
* None.
4. Parameters
4.1. enable_full_lr (integer)
4.2. append_fromtag (integer)
4.3. enable_double_rr (integer)
4.4. add_username (integer)
4.5. enable_socket_mismatch_warning (integer)
4.6. custom_user_avp (avp string)
4.7. force_send_socket (int)
4.8. ignore_sips (int)
4.9. sockname_mode (int)
4.1. enable_full_lr (integer)
If set to 1 then “;lr=on” instead of just “;lr” will be used. This is
to overcome problems with broken UAs which strip “;lr” parameter when
generating Route header fields from Record-Route (“;lr=on” seems to
help).
Default value is 0 (no).
Example 1.2. Set enable_full_lr parameter
...
modparam("rr", "enable_full_lr", 1)
...
4.2. append_fromtag (integer)
If turned on, request's from-tag is appended to record-route; that's
useful for understanding whether subsequent requests (such as BYE) come
from caller (route's from-tag==BYE's from-tag) or callee (route's
from-tag==BYE's to-tag)
Default value is 1 (yes).
Example 1.3. Set append_fromtag parameter
...
modparam("rr", "append_fromtag", 0)
...
4.3. enable_double_rr (integer)
There are some situations when the server needs to insert two
Record-Route header fields instead of one. For example when using two
disconnected networks or doing cross-protocol forwarding from UDP->TCP.
This parameter enables inserting of 2 Record-Routes. The server will
later remove both of them.
Double record-routing does not occur when outbound is used for a
request.
Default value is 1 (yes).
Example 1.4. Set enable_double_rr parameter
...
modparam("rr", "enable_double_rr", 0)
...
Some useragents (e. g. Linphone) incorrectly use UDP transport for
subsequent requests in dialog, despite being configured to use another
SIP transport protocol. This can be worked around by setting
Record-Route header with explicit transport attribute. But
enable_double_rr enabled in default mode omits transport attribute from
being added to header if it detects that both sender and receiver use
same protocol (e. g. TCP or TLS), and this results in UDP being used by
such broken clients. Set enable_double_rr to value 2 to always have two
RR headers with transport attributes explicitly set.
Example 1.5. Set enable_double_rr to 2 to always have two explicit RR
headers
...
modparam("rr", "enable_double_rr", 2)
...
4.4. add_username (integer)
If set to a non 0 value (which means yes), the username part will be
also added in the Record-Route URI.
This option cannot be set when the “outbound” module is loaded before
this module as outbound uses the username part of Record-Route URIs to
store flow-tokens.
Default value is 0 (no).
Example 1.6. Set add_username parameter
...
modparam("rr", "add_username", 1)
...
4.5. enable_socket_mismatch_warning (integer)
When a preset record-route header is forced in Kamailio config and the
host from the record-route header is not the same as the host server, a
warning will be printed out in the logs. The
'enable_socket_mismatch_warning' parameter enables or disables the
warning. When Kamailio is behind a NATed firewall, we don't want this
warning to be printed for every bridged call.
Default value is 1 (yes).
Example 1.7. enable_socket_mismatch_warning usage
...
modparam("rr", "enable_socket_mismatch_warning", 0)
...
4.6. custom_user_avp (avp string)
When enable_username is enabled, a call to record_route will add the
username of the RequestURI to the Record-Route URI. This parameter
allows you to setup an AVP with which you can customise the username to
be added in the Record-Route URI.
Default value: if not set, the std add_username behaviour is used -
i.e. Request URI username.
Example 1.8. custom_user_avp usage
...
modparam("rr", "custom_user_avp", "$avp(RR_CUSTOMER_USER_AVP)")
#usage in cfg file
$avp(RR_CUSTOM_USER_AVP)="mo";
record_route();
...
4.7. force_send_socket (int)
If set to 1, local socket is forced even for single Record-Route,
otherwise is done on double Record-Route (should that be enabled).
When use of “outbound” is enabled, the socket is not forced.
Default value is 0.
Example 1.9. Set force_send_socket parameter
...
modparam("rr", "force_send_socket", 1)
...
4.8. ignore_sips (int)
If set to 1, the Record-Route header are build with 'sip' schema
always, ignoring the presence of 'sips' schema in request URI.
Default value is 0 (use 'sips' if present in R-URI).
Example 1.10. Set ignore_sips parameter
...
modparam("rr", "ignore_sips", 1)
...
4.9. sockname_mode (int)
If set to 1, the Record-Route URI is built to contain socket name in
'sn' parameter.
Default value is 0.
Example 1.11. Set sockname_mode parameter
...
modparam("rr", "sockname_mode", 1)
...
5. Functions
5.1. loose_route()
5.2. record_route([sparams])
5.3. remove_record_route()
5.4. record_route_preset(string [,string2])
5.5. record_route_advertised_address(address)
5.6. add_rr_param(param)
5.7. check_route_param(re)
5.8. is_direction(dir)
5.9. rr_next_hop_route()
5.1. loose_route()
The function performs routing of SIP requests which contain a route
set. The name is a little bit confusing, as this function also routes
requests which are in the “strict router” format.
This function is usually used to route in-dialog requests (like ACK,
BYE, reINVITE). Nevertheless also out-of-dialog requests can have a
“pre-loaded route set” and my be routed with loose_route. It also takes
care of translating between strict-routers and loose-router.
The loose_route function analyzes the Route: headers in the requests.
If there is no Route: header, the function returns FALSE and routing
should be done with normal lookup functions. If a Route: header is
found, the function returns 1 and behaves as described in section 16.12
of RFC 3261. There is only one exception: If the request is
out-of-dialog (no to-tag) and there is only one Route: header
indicating the local proxy, then the Route: header is removed and the
function returns FALSE.
When the “outbound” module was loaded before this module and the Route:
header contains a username part this function will attempt to use the
username part as a flow-token for routing. If route calculation based
on flow-token succeeds, function returns TRUE even if there is only one
Route: header indicating the local proxy.
Make sure your loose_routing function can't be used by attackers to
bypass proxy authorization.
The loose_routing topic is very complex. See the RFC3261 for more
details (grep for “route set” is a good starting point in this
comprehensive RFC).
Return codes:
* 1 - route calculation has been successful
* 2 - route calculation based on flow-token has been successful
* -1 - route calculation has been unsuccessful
* -2 - outbound flow-token shows evidence of tampering
* -3 - next hop is taken from a preloaded route set
This function can be used from REQUEST_ROUTE.
Example 1.12. loose_route usage
...
loose_route();
...
5.2. record_route([sparams])
The function adds a new Record-Route header field. The header field
will be inserted in the message before any other Record-Route header
fields.
If any string is passed as parameter, it will be appended as URI
parameter to the Record-Route header. The string must follow the
“;name=value” scheme and it may contain pseudo-variables.
When the “outbound” module was loaded before this module this function
will determine whether outbound is required for the request and
generate and add a flow-token as the username part of the
Record-Route-URI.
Note: if append From-tag is enabled and the function is used for
requests within dialog, it must be executed after loose_route() in
order to detect properly the direction.
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE and
FAILURE_ROUTE.
Example 1.13. record_route usage
...
record_route();
...
5.3. remove_record_route()
The function removes the internal lumps added by record_route()
functions.
Can be used to revert adding Record-Route header(s).
This function can be used from REQUEST_ROUTE and FAILURE_ROUTE.
Example 1.14. remove_record_route usage
...
remove_record_route();
...
5.4. record_route_preset(string [,string2])
This function will put the string into Record-Route, don't use unless
you know what you are doing.
Meaning of the parameters is as follows:
* string - String to be inserted into the first header field; it may
contain pseudo-variables.
* string2 - String to be inserted into the second header field; it
may contain pseudo-variables.
Note: If 'string2' is present, then the 'string' param is pointing to
the outbound interface and the 'string2' param is pointing to the
inbound interface.
When the “outbound” module was loaded before this module this function
will determine whether outbound is required for the request and
generate and add a flow-token as the username part of the
Record-Route-URI.
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE and
FAILURE_ROUTE.
Example 1.15. record_route_preset usage
...
record_route_preset("1.2.3.4:5090");
...
5.5. record_route_advertised_address(address)
The function adds a new Record-Route header field using the address
given. The header field will be inserted in the message before any
other Record-Route header fields.
When the “outbound” module was loaded before this module this function
will determine whether outbound is required for the request and
generate and add a flow-token as the username part of the
Record-Route-URI.
Meaning of the parameter is as follows:
* address - Advertised address to use in the header; it may contain
pseudo-variables.
If double record-routing is enabled two Record-Route headers will be
inserted with the same given address with different transports if the
transport changes.
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE and
FAILURE_ROUTE.
Example 1.16. record_route_advertised_address usage
...
record_route_advertised_address("1.2.3.4:5080");
...
5.6. add_rr_param(param)
Adds a parameter to the Record-Route URI (param must be in
“;name=value” format. The function may be called also before or after
the record_route() or record_route_advertised_address() calls (see ???
or ???)).
Meaning of the parameters is as follows:
* param - String containing the URI parameter to be added. It must
follow the “;name=value” scheme; it may contain pseudo-variables.
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE and
FAILURE_ROUTE.
Example 1.17. add_rr_param usage
...
add_rr_param(";nat=yes");
...
5.7. check_route_param(re)
The function checks if the URI parameters of the local Route header
(corresponding to the local server) matches the given regular
expression. It must be call after loose_route() (see ???).
Meaning of the parameters is as follows:
* re - regular expression to check against the Route URI parameters.
This function can be used from REQUEST_ROUTE.
Example 1.18. check_route_param usage
...
if (check_route_param("nat=yes")) {
setflag(6);
}
...
5.8. is_direction(dir)
The function checks the flow direction of in-dialog requests. This
function uses the “ftag” parameter from the Route header, therefore the
append_fromtag (see ??? module parameter must be enabled. Also this
must be called only after loose_route() (see ???).
The function returns true if the “dir” is the same with the request's
flow direction.
The “downstream” direction means that the request is in the same
direction as the initial request that created the dialog.
Meaning of the parameters is as follows:
* dir - string containing the direction to be checked. It may be
“upstream” (from callee to caller) or “downstream” (caller to
callee).
This function can be used from REQUEST_ROUTE.
Example 1.19. is_direction usage
...
if (is_direction("downstream")) {
xdbg("in-dialog request from caller to callee (downstream) ($rm)\n");
} else {
xdbg("in-dialog request from callee to caller (upstream) ($rm)\n");
}
...
5.9. rr_next_hop_route()
The function returns 1 (true) if there is a Route header for the next
hop address. It has to be used after loose_route(), when the local
Route headers are processed.
This function can be used from ANY_ROUTE.
Example 1.20. rr_next_hop_route usage
...
if(loose_route) {
if(rr_next_hop_route()) {
# next hop address is from Route header
}
}
...
6. Exported Pseudo Variables
6.1. $route_uri
6.1. $route_uri
Returns the URI of the top route-header.
Example 1.21. $route_uri
...
xdbg("Route-URI is: $route_uri\n");
...
Chapter 2. Developer Guide
Table of Contents
1. Available Functions
1.1. record_route(string)
1.2. record_route_advertised_address(string)
1.3. add_rr_param( msg, param)
1.4. check_route_param( msg, re)
1.5. is_direction( msg, dir)
1.6. get_route_param( msg, name, val)
1.7. register_rrcb( callback, param)
2. Examples
The RR module provides an internal API to be used by other Kamailio
modules. The API offers support for SIP dialog based functionalities -
for more about the dialog support offered by RR module, see Section 2,
“Dialog support”.
For internal(non-script) usage, the RR module offers to other module
the possibility to register callback functions to be executed each time
a local Route header is processed. The callback function will receive
as parameter the register parameter and the Route header parameter
string.
1. Available Functions
1.1. record_route(string)
1.2. record_route_advertised_address(string)
1.3. add_rr_param( msg, param)
1.4. check_route_param( msg, re)
1.5. is_direction( msg, dir)
1.6. get_route_param( msg, name, val)
1.7. register_rrcb( callback, param)
1.1. record_route(string)
The function adds a new Record-Route header field. The header field
will be inserted in the message before any other Record-Route header
fields.
If any string is passed as parameter, it will be appended as URI
parameter to the Record-Route header. The string must follow the
“;name=value” scheme and it may contain pseudo-variables.
This function can be used from REQUEST_ROUTE, BRANCH_ROUTE and
FAILURE_ROUTE.
Example 2.1. record_route usage
...
record_route();
...
1.2. record_route_advertised_address(string)
This function will add the string into a new Record-Route header field.
Don't use unless you know what you are doing. The header field will be
inserted in the message before any other Record-Route header fields.
Meaning of the parameters is as follows:
* string - String to be inserted into the header field.
Calls to add_rr_param() will add parameters to the Record-Route header.
Note: A second Record-Route will be inserted if the transport used on
the inbound and outbound interfaces changes.
Example 2.2. record_route_advertised_address usage
...
record_route_advertised_address("1.2.3.4:5090");
...
1.3. add_rr_param( msg, param)
Adds a parameter to the requests's Record-Route URI (param must be in
“;name=value” format).
The function returns 0 on success. Otherwise, -1 is returned.
Meaning of the parameters is as follows:
* struct sip_msg* msg - request that will has the parameter “param”
added to its Record-Route header.
* str* param - parameter to be added to the Record-Route header - it
must be in “;name=value” format.
1.4. check_route_param( msg, re)
The function checks for the request “msg” if the URI parameters of the
local Route header (corresponding to the local server) matches the
given regular expression “re”. It must be call after the loose_route
was done.
The function returns 0 on success. Otherwise, -1 is returned.
Meaning of the parameters is as follows:
* struct sip_msg* msg - request that will has the Route header
parameters checked.
* regex_t* param - compiled regular expression to be checked against
the Route header parameters.
1.5. is_direction( msg, dir)
The function checks the flow direction of the request “msg”. As for
checking it's used the “ftag” Route header parameter, the
append_fromtag (see ??? module parameter must be enables. Also this
must be call only after the loose_route is done.
The function returns 0 if the “dir” is the same with the request's flow
direction. Otherwise, -1 is returned.
Meaning of the parameters is as follows:
* struct sip_msg* msg - request that will have the direction checked.
* int dir - direction to be checked against. It may be
“RR_FLOW_UPSTREAM” or “RR_FLOW_DOWNSTREAM”.
1.6. get_route_param( msg, name, val)
The function search in to the “msg”'s Route header parameters the
parameter called “name” and returns its value into “val”. It must be
call only after the loose_route is done.
The function returns 0 if parameter was found (even if it has no
value). Otherwise, -1 is returned.
Meaning of the parameters is as follows:
* struct sip_msg* msg - request that will have the Route header
parameter searched.
* str *name - contains the Route header parameter to be searched.
* str *val - returns the value of the searched Route header parameter
if found. It might be empty string if the parameter had no value.
1.7. register_rrcb( callback, param)
The function register a new callback (along with its parameter). The
callback will be called when a loose route will be performed for the
local address.
The function returns 0 on success. Otherwise, -1 is returned.
Meaning of the parameters is as follows:
* rr_cb_t callback - callback function to be registered.
* void *param - parameter to be passed to the callback function.
2. Examples
Example 2.3. Loading RR module's API from another module
...
#include "../rr/api.h"
...
struct rr_binds my_rrb;
...
...
/* load the RR API */
if (load_rr_api( &my_rrb )!=0) {
LM_ERR("can't load RR API\n");
goto error;
}
...
...
/* register a RR callback */
if (my_rrb.register_rrcb(my_callback,0))!=0) {
LM_ERR("can't register RR callback\n");
goto error;
}
...