sr-users June 2011

sr-users@lists.kamailio.org

75 participants
115 discussions

HTTP POST
by Matthew Williams 16 Jun '11

16 Jun '11

Hi, I'm working on an application that needs to create an HTTP POST from within Kamailio. The utils module has the http_query function, but that is only for GET. I think I'm looking for something more like the uac module's uac_req_send -- but for http. Any suggestions? Thanks in advance!

2 1

mi_datagram usage example
by Asgaroth 16 Jun '11

16 Jun '11

Hi All, I am trying to send a mi command over the mi_datagram udp socket. I dont seem to be getting a response back from the server. I am certain that it is something I am doing wrong. I have mi_datagram loaded and listening on udp:1.1.1.1:8080. I then try to send the following dispatcher mi command over to the mi_dg interface: echo -ne ":ds_list:\n\n" | nc -w 1 -u 1.1.1.1 8080 I dont see any error in the log file, so it appears that the mi_datagram is processing the request, but I am not getting any response back. The ds_list command works properly if I run it using "kamctl fifo ds_list", or if I go via "sercmd mi_dg ds_list" that works too. Would anyone have an example bash/ksh/perl snippet that would help me on my way to communicating with this mi interface. Any thoughts comments would be greatly appreciated. Thanks

3 3

Kamailio dispatcher
by Evgeniy Spinov 16 Jun '11

16 Jun '11

Hello. I had a Kamailio version of 3.0.3 and during this time configured a failover with simple routine. In short like this: if (ds_next_domain()) { xlog(.....); if (!t_relay()) { xlog(.....); return; } return; } else { t_reply("503"); } Then I've updated to 3.1.3 and was happy enough until I've discovered that my failover is not working anymore. What is observed: - It changes $rd variable, but not changing $du variable, is it ok? - Not any of the nodes receive packet on t_relay after ds_next_domain(). - In route decision section, where t_on_reply() and t_on_failure() are located I have the same t_relay() and it works fine, cause there is no any ds_next_domains(). Is it a bug or I'm doing something wrong? Thanks in advance.

3 11

How to check a bit (1/0) of a pseudo-variable?
by Iñaki Baz Castillo 16 Jun '11

16 Jun '11

Hi, summarizing I have two pseudo-variables: $var(allowed_zones) = 5; $var(id_zone) = 2; The binary representation of 5 (3+2), assuming 8 bits lenght, is: 00000101 so bit 0 = 1, bit 1 = 0, bit 2 = 1 ... Now I just need to know if bit number 2 ($var(id_zone)) of $var(allowed_zones) is 0 or 1. Is there any function like isflagset() but for pseudo-variables? Thanks a lot. -- Iñaki Baz Castillo <ibc(a)aliax.net>

3 6

Re: [SR-Users] Use of mtree module having multiple trees in the same table
by Javier Gallart 16 Jun '11

16 Jun '11

Hello not sure what you want to accomplish, but in case it might help this is how we use the mtree module. Our 3 columns are: partition, prefix, route Partition is just a name that defines a group, this is done inside the script before calling mt_match (via a table lookup for instance). Let's say if a call comes from ip x we assign it to partition 400; if it comes from ip y we assign it to partition 401. Each partition is a different tree. Consider these entries in the tree table: 400,123456,A 401,123456,A 401,1234567,B Let's say both x and y send a call with $rU 1234567; mt_match will return A for ip x, and B for ip y; we use that information for taking further routing decisions. A common situation might be: x has a unique route for a whole country while y has that entry but has more defined routes for more specific area codes inside that country. The column route could also be for instance the setid of a group of gw's for the dispatcher module, etc... Regards Javi > > Message: 3 > > Date: Tue, 14 Jun 2011 14:27:53 +0200 > > From: I?aki Baz Castillo <ibc(a)aliax.net> > > Subject: Re: [SR-Users] Use of mtree module having multiple trees in > > the same table > > To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - > > Users Mailing List" <sr-users(a)lists.sip-router.org> > > Message-ID: <BANLkTim8h563kUy0YT9pTgOSXJ6W4Qf6ww(a)mail.gmail.com> > > Content-Type: text/plain; charset=UTF-8 > > > > 2011/6/13 jose luis millan <doctore96(a)gmail.com>: > > > I wonder if anyone could help me understanding how can I use this > > > module in a scenario where multiple mtrees are defined behind the same > > > database table. > > > > > > I can't guess how to speficy to 'mt_match' the mtree I want to match > > > against, since the 'mtree' module parameter defines a specific memory > > > tree based on a specific table, but not based on a specific 'tname' > > > value. > > > > Indeed we have a table with these colums: > > > > - prefix: string to identify number destination. This is the regex > > column. > > - id_zone: integer, points to other table. This is the value column. > > - scope: integer, can be 0 or 1. > > > > So wee need two instances of mtree: > > 1) those rows with scope 0. > > 2) those rows with scope 1. > > > > Is it possible with current mtree module? or maybe we'd do better by > > creating two views of the table (one for entries with scope 0 and > > another for entries with scope 1)? > > > > Thanks a lot. > > > > -- > > I?aki Baz Castillo > > <ibc(a)aliax.net> > > > > > > > > >

2 1

Re: [SR-Users] sr-users Digest, Vol 73, Issue 40
by Javier Gallart 16 Jun '11

16 Jun '11

Hello not sure what you want to accomplish, but in case it might help this is how we use the mtree module. Our 3 columns are: partition, prefix, route Partition is just a name that defines a group, this is done inside the script before calling mt_match (via a table lookup for instance). Let's say if a call comes from ip x we assign it to partition 400; if it comes from ip y we assign it to partition 401. Each partition is a different tree. Consider these entries in the tree table: 400,123456,A 401,123456,A 401,1234567,B Let's say both x and y send a call with $rU 1234567; mt_match will return A for ip x, and B for ip y; we use that information for taking further routing decisions. A common situation might be: x has a unique route for a whole country while y has that entry but has more defined routes for more specific area codes inside that country. The column route could also be for instance the setid of a group of gw's for the dispatcher module, etc... Regards Javi Message: 3 > Date: Tue, 14 Jun 2011 14:27:53 +0200 > From: I?aki Baz Castillo <ibc(a)aliax.net> > Subject: Re: [SR-Users] Use of mtree module having multiple trees in > the same table > To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - > Users Mailing List" <sr-users(a)lists.sip-router.org> > Message-ID: <BANLkTim8h563kUy0YT9pTgOSXJ6W4Qf6ww(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > 2011/6/13 jose luis millan <doctore96(a)gmail.com>: > > I wonder if anyone could help me understanding how can I use this > > module in a scenario where multiple mtrees are defined behind the same > > database table. > > > > I can't guess how to speficy to 'mt_match' the mtree I want to match > > against, since the 'mtree' module parameter defines a specific memory > > tree based on a specific table, but not based on a specific 'tname' > > value. > > Indeed we have a table with these colums: > > - prefix: string to identify number destination. This is the regex > column. > - id_zone: integer, points to other table. This is the value column. > - scope: integer, can be 0 or 1. > > So wee need two instances of mtree: > 1) those rows with scope 0. > 2) those rows with scope 1. > > Is it possible with current mtree module? or maybe we'd do better by > creating two views of the table (one for entries with scope 0 and > another for entries with scope 1)? > > Thanks a lot. > > -- > I?aki Baz Castillo > <ibc(a)aliax.net> > > > >

1 0

t_relay_to("0x02") alternative with kamailio 3.1
by Herve Couplet 16 Jun '11

16 Jun '11

Hi, I had a setup with an old version where I used the function t_relay_to("0x02"). Following the 3.1 documentation, flag : * 0x02* - do not generate reply on internal error (NOTE: has no effect anymore) I used that function as a workaround with a pbx that stop to register when it receive an error response like 478 Unresolvable destination or 408 request timeout. I did upgrade to 3.1 to have dns srv caching. Do you know how this would be possible with kamailio 3.1. Thanks for your suggestions, hp

4 4

Operations With Variables $var- does it need to load a module
by Omar 15 Jun '11

15 Jun '11

In Kamailio 1.4.3 I have the following scenario: $var(a) = 0 $var(b) = 0 $var(a) = $(tU{s.len}); $var(b) = $var(a) - 5; xlog(" $var(b)"); the result $var(b) is always the same as $var(a) should i check if some specific module is loaded? the debugs does not show any error, and $var(a) and $var(b) are unique. Variables are working, but not the operations with the variables. regards O

3 4

200 OK Retransmission Error
by Jijo 15 Jun '11

15 Jun '11

Hi All, In an INVITE transaction, no ACK from A party and B party continue retransmission of 200 OK. I have observed that kamailio is not passing the retransmitted 200 OK message from B party to the Application(script) after 3 seconds. Instead kamailio directly sending to A party without passing to the script. I see in the logs that kamailio is cleaning up the transaction after 3 seconds..look for the string "DEBUG: t_lookup_request: no transaction found" before this log it is cleaning up the timer in the log "DEBUG: cleanup_uac_timers: RETR/FR timers reset" What does it mean by that?? How can we make the kamailio to pass the response to the application? Please let me know your comments.. Here is the flow. I cannot send the complete logs which is quite big. so i grep'd using the stirng "tcp_read_req: content-length|get_hdr_field|t_reply_matching|cleanup_uac_timers|RR11" from the complete log.. A kamailo B ----INVITE-->- --------------------INVITE 180 Ringing--<---------------180 Ringing 200 OK-----------<---------------200 OK 0 200 OK-----------<---------------200 OK 500ms 200 OK-----------<---------------200 OK 1s 200 OK-----------<---------------200 OK 2s < From here it is not passing to the application- script> 200 OK-----------<---------------200 OK 4s 200 OK-----------<---------------200 OK 4s 28 102:2011-06-13T19:47:37+01:00 [debug] sipserver: [26177] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [50]; uri=[ sip:5616990102@192.168.243.151:5060] 36 95:2011-06-13T19:47:37+01:00 [debug] sipserver: [26177] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 267 86:2011-06-13T19:47:37+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 0 282 102:2011-06-13T19:47:37+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 284 95:2011-06-13T19:47:37+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 285 89:2011-06-13T19:47:37+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 286 90:2011-06-13T19:47:38+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1018]: DEBUG: t_reply_matching: reply matched (T=0xb0f62e50)! 292 96:2011-06-13T19:47:38+01:00 [info] sipserver: [26269] INFO: <script>: CI=1-8028(a)192.168.243.150 -RR11 - Entry M=INVITE RURI=<null> From= sip:5616990103@192.168.243.150 To=sip:5616990102@192.168.243.151:5060 RD= <null> IP=192.168.243.161 Code:180 Reason=Ringing CT=5616990102 <sip: 5616990102@192.168.243.161:5060;transport=tcp> 331 86:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 346 102:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 348 95:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 349 89:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 350 90:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1018]: DEBUG: t_reply_matching: reply matched (T=0xb0f62e50)! 356 96:2011-06-13T19:47:39+01:00 [info] sipserver: [26269] INFO: <script>: CI=1-8028(a)192.168.243.150 -RR11 - Entry M=INVITE RURI=<null> From= sip:5616990103@192.168.243.150 To=sip:5616990102@192.168.243.151:5060 RD= <null> IP=192.168.243.161 Code:200 Reason=OK CT=5616990102 <sip:5616990102 @192.168.243.161:5060;transport=tcp> 398 89:2011-06-13T19:47:39+01:00 [debug] sipserver: [26269] DEBUG: tm [t_reply.c:1467]: DEBUG: cleanup_uac_timers: RETR/FR timers reset 406 86:2011-06-13T19:47:40+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 421 102:2011-06-13T19:47:40+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 423 95:2011-06-13T19:47:40+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 424 89:2011-06-13T19:47:40+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 425 90:2011-06-13T19:47:40+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1018]: DEBUG: t_reply_matching: reply matched (T=0xb0f62e50)! 431 96:2011-06-13T19:47:40+01:00 [info] sipserver: [26269] INFO: <script>: CI=1-8028(a)192.168.243.150 -RR11 - Entry M=INVITE RURI=<null> From= sip:5616990103@192.168.243.150 To=sip:5616990102@192.168.243.151:5060 RD= <null> IP=192.168.243.161 Code:200 Reason=OK CT=5616990102 <sip:5616990102 @192.168.243.161:5060;transport=tcp> 481 86:2011-06-13T19:47:41+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 496 102:2011-06-13T19:47:41+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 498 95:2011-06-13T19:47:41+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 499 89:2011-06-13T19:47:41+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 500 90:2011-06-13T19:47:41+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1018]: DEBUG: t_reply_matching: reply matched (T=0xb0f62e50)! 506 96:2011-06-13T19:47:41+01:00 [info] sipserver: [26269] INFO: <script>: CI=1-8028(a)192.168.243.150 -RR11 - Entry M=INVITE RURI=<null> From= sip:5616990103@192.168.243.150 To=sip:5616990102@192.168.243.151:5060 RD= <null> IP=192.168.243.161 Code:200 Reason=OK CT=5616990102 <sip:5616990102 @192.168.243.161:5060;transport=tcp> 556 86:2011-06-13T19:47:43+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 571 102:2011-06-13T19:47:43+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 573 95:2011-06-13T19:47:43+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 574 89:2011-06-13T19:47:43+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 575 90:2011-06-13T19:47:43+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1018]: DEBUG: t_reply_matching: reply matched (T=0xb0f62e50)! 581 96:2011-06-13T19:47:43+01:00 [info] sipserver: [26269] INFO: <script>: CI=1-8028(a)192.168.243.150 -RR11 - Entry M=INVITE RURI=<null> From= sip:5616990103@192.168.243.150 To=sip:5616990102@192.168.243.151:5060 RD= <null> IP=192.168.243.161 Code:200 Reason=OK CT=5616990102 <sip:5616990102 @192.168.243.161:5060;transport=tcp> 631 86:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 646 102:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 648 95:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 649 89:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 650 90:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 651 90:2011-06-13T19:47:47+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 693 86:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 708 102:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 710 95:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 711 89:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 712 90:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 713 90:2011-06-13T19:47:51+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 755 86:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 770 102:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 772 95:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 773 89:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 774 90:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 775 90:2011-06-13T19:47:55+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 817 86:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 832 102:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 834 95:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 835 89:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 836 90:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 837 90:2011-06-13T19:47:59+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 879 86:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 894 102:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 896 95:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 897 89:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 898 90:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 899 90:2011-06-13T19:48:03+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 941 86:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 956 102:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 958 95:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 959 89:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 960 90:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 961 90:2011-06-13T19:48:07+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction 1003 86:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: <core> [tcp_read.c:933]: tcp_read_req: content-length= 191 1018 102:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:185]: DEBUG: get_hdr_field: <To> [65]; uri=[ sip:5616990102@192.168.243.151:5060] 1020 95:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: <core> [parser/msg_parser.c:165]: get_hdr_field: cseq <CSeq>: <1> <INVITE> 1021 89:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:967]: DEBUG: t_reply_matching: hash 5084 label 418362480 branch 0 1022 90:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1052]: DEBUG: t_reply_matching: no matching transaction exists 1023 90:2011-06-13T19:48:11+01:00 [debug] sipserver: [26269] DEBUG: tm [t_lookup.c:1055]: DEBUG: t_reply_matching: failure to match a transaction

2 2

NAPTR priorities doesn't seem to work properly
by Iñaki Baz Castillo 15 Jun '11

15 Jun '11

Hi, I'm testing Kamailio's NAPTR resolution: version: kamailio 3.2.0-dev4 (x86_64/linux) flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB DNS related configuration: dns_servers_no=2 dns_srv_lb=yes dns_try_naptr=yes dns_use_search_list=no use_dns_cache=yes use_dns_failover=yes dns_tls_preference=1 dns_tcp_preference=1 dns_udp_preference=1 As the doc says it should respect the priorities of the NAPTR records, see http://kamailio.org/dokuwiki/doku.php/core-cookbook:3.1.x#dns_sctp_pref_dns…: "To use the remote site preferences set all dns_*_pref to the same positive value (e.g. dns_udp_pref=1, dns_tcp_pref=1, dns_tls_pref=1, dns_sctp_pref=1)" So my kamailio receives an INVITE for an external domain oversip.net (no transport param neither port in the RURI) and does a t_relay. Request RURI is sip:qwe@oversip.net. According to NAPTR: ~$ host -t naptr oversip.net oversip.net has NAPTR record 5 50 "S" "SIPS+D2T" "" _sips._tcp.oversip.net. oversip.net has NAPTR record 10 50 "S" "SIP+D2T" "" _sip._tcp.oversip.net. oversip.net has NAPTR record 20 50 "S" "SIP+D2U" "" _sip._udp.oversip.net. oversip.net has NAPTR record 40 50 "S" "SIP+D2S" "" _sip._sctp.oversip.net. oversip.net has NAPTR record 50 50 "S" "SIPS+D2S" "" _sips._sctp.oversip.net. So it should try TLS over TCP first, if it fails try TCP and if it fails try UDP. However it just uses UDP, why?? Even if I set a minor value to dns_tls_preference (so higher priority I expect) it still uses UDP. Am I doing something wrong? Thanks a lot. -- Iñaki Baz Castillo <ibc(a)aliax.net>

6 29

← Newer
1
...
5
6
7
8
9
10
11
12
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users June 2011