Re: [SR-Users] NAPTR priorities doesn't seem to work properly
One more question here, since I remembered about it -- have you played with dns-based load balancing done by proxy so far? This was new for kamailio in 3.x... Thanks, Daniel On 6/13/11 3:55 PM, Daniel-Constantine Mierla wrote: On Jun 13, 2011, at 2:48 PM, Iñaki Baz Castilloi...@aliax.net wrote: 2011/6/13 Daniel-Constantin Mierlamico...@gmail.com: I saw Andrei jumped in and added case insensitive comparison of naptr flags -- just to conclude this discussion, is it working on now? Hi Daniel, I've tested it right *now* :) Yes, it works. -- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/9 Iñaki Baz Castillo i...@aliax.net: 2011/6/9 Alex Hermann a...@speakup.nl: The way I read rfc2915, there is no failover mechanism. The application pick the first target that it supports and uses that. There is no mention of trying other records afterwards. Matching/finding NAPTR records stops once the first match is completed. All other records are discarded. From section 2: Hi Alex, two comments: 1) What you say does not explain my issue (as in any case TLS or TCP have more priority in my NAPTR's than UDP). In fact, my exact problem is that my Kamailio is not performing NAPTR query. The problem is fixed now, it was an error related to the NAPTR service flag (sip-router expected it to be s case-sensitive, while it should also allow S). 2) About your quoted text, indeed RFC 2915 says that. But that just means that, an application (in this case a SIP client) must take *first* the valid NAPTR record with better order (lowest value). But RFC 2915 is just about NAPTR, it can not mandate that applications or protocols cannot try other NAPTR records as failover mechanism. Any SIP client or proxy implementing NAPTR records does failover to the next NAPTR record in case the first one failed (at least those I've tested). It seems that sip-router behaves exactly as you describe. This it, it performs the NAPTR resolution, chooses the record with best 'order' (for the supported transports) and just uses it (it would do SRV failover and so, but would never try other NAPTR records with less 'order'). However I've seen other SIP stacks also performing failover by taking next NAPTR records. But indeed, RFC 2915 does not mandate it, instead it says MUST NOT. So you are right. Regards. -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
On Wednesday 15 June 2011, Iñaki Baz Castillo wrote: 2011/6/9 Iñaki Baz Castillo i...@aliax.net: 2011/6/9 Alex Hermann a...@speakup.nl: 2) About your quoted text, indeed RFC 2915 says that. But that just means that, an application (in this case a SIP client) must take *first* the valid NAPTR record with better order (lowest value). But RFC 2915 is just about NAPTR, it can not mandate that applications or protocols cannot try other NAPTR records as failover mechanism. Any SIP client or proxy implementing NAPTR records does failover to the next NAPTR record in case the first one failed (at least those I've tested). It seems that sip-router behaves exactly as you describe. This it, it performs the NAPTR resolution, chooses the record with best 'order' (for the supported transports) and just uses it (it would do SRV failover and so, but would never try other NAPTR records with less 'order'). However I've seen other SIP stacks also performing failover by taking next NAPTR records. But indeed, RFC 2915 does not mandate it, instead it says MUST NOT. So you are right. I forgot about a discussion i had about this issue a few years ago with a customer and just remembered the outcome now. (Optional) failover can be provided by different 'Preference' field within the same 'Order'. From rfc 2915/3403 section 2: The important difference between Order and Preference is that once a match is found the client MUST NOT consider records with a different Order but they MAY process records with the same Order but different Preferences. I.e., Preference is used to give weight to rules that are considered the same from an authority standpoint but not from a simple load balancing standpoint. Unfortunately this wasn't possible with Kamailio =1.5. Have you tried 3.x with equal 'Order' but different 'Preference' or just with different 'Order'? -- Greetings, Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/15 Alex Hermann a...@speakup.nl: However I've seen other SIP stacks also performing failover by taking next NAPTR records. But indeed, RFC 2915 does not mandate it, instead it says MUST NOT. So you are right. I forgot about a discussion i had about this issue a few years ago with a customer and just remembered the outcome now. (Optional) failover can be provided by different 'Preference' field within the same 'Order'. From rfc 2915/3403 section 2: The important difference between Order and Preference is that once a match is found the client MUST NOT consider records with a different Order but they MAY process records with the same Order but different Preferences. I.e., Preference is used to give weight to rules that are considered the same from an authority standpoint but not from a simple load balancing standpoint. Yes, 100% right. Unfortunately this wasn't possible with Kamailio =1.5. Have you tried 3.x with equal 'Order' but different 'Preference' or just with different 'Order'? Not yet, but I'll do it and comment here :) -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/15 Iñaki Baz Castillo i...@aliax.net: Unfortunately this wasn't possible with Kamailio =1.5. Have you tried 3.x with equal 'Order' but different 'Preference' or just with different 'Order'? Not yet, but I'll do it and comment here :) Kamailio just takes one of the NAPTR records, even if the first fails and there are more NAPTR records with same order (tested right now). The file doc/dns-txt confirms it: dns_try_naptr = on | off - if on sip-router will first try a NAPTR lookup for destinations that don't have the protocol or port specified and are not simple ip addresses (as described in RFC 3263). This will introduce a slight performance penalty and will probably cause extra DNS lookups. For example a lookup for a non-existing domain will produce one extra query: NAPTR(domain), SRV(_sip._udp.domain) and A/(domain). If the result of a query contains several NAPTR records, sip-router will select among them according to the RFC2915 and sip-router preference towards a specific protocol (see dns_udp_pref, dns_tcp_pref and dns_tls_pref below). For an RFC3263 compliant configuration (choose the remote side preferred protocol if supported), set dns_udp_pref, dns_tcp_pref and dns_tls_pref to the same value (=0), e.g. 0. Default: off -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
Hello, On 6/11/11 9:24 AM, Iñaki Baz Castillo wrote: 2011/6/10 Iñaki Baz Castilloi...@aliax.net: Then if you use a simple config with t_relay(), go to tm module, see where t_relay() is defined, follow a bit the code and set a breakpoint by file and line number at a convenient location (as much as close to dns lookup functions if you can spot them in the code), so you don't do next/next/ too many times. Hi Daniel, I tryed to extract some useful data but got nothing. I've set breakpoints by indicating file:line of tm module as well as resolve.c file. The same using function names as breakpoints, etc. No result at all, I just get stuf about UDP, IO, read and so. Anyhow I've make some other tests and concluded that the issue is very simple: Kamailio performs NAPTR query but completely ignores its result. I've reported the bug in the tracker: http://sip-router.org/tracker/index.php?do=detailstask_id=135 I saw Andrei jumped in and added case insensitive comparison of naptr flags -- just to conclude this discussion, is it working on now? Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/13 Daniel-Constantin Mierla mico...@gmail.com: I saw Andrei jumped in and added case insensitive comparison of naptr flags -- just to conclude this discussion, is it working on now? Hi Daniel, I've tested it right *now* :) Yes, it works. -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
On Jun 13, 2011, at 2:48 PM, Iñaki Baz Castillo i...@aliax.net wrote: 2011/6/13 Daniel-Constantin Mierla mico...@gmail.com: I saw Andrei jumped in and added case insensitive comparison of naptr flags -- just to conclude this discussion, is it working on now? Hi Daniel, I've tested it right *now* :) Yes, it works. Ok, thanks. Cheers, Daniel -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/10 Iñaki Baz Castillo i...@aliax.net: Then if you use a simple config with t_relay(), go to tm module, see where t_relay() is defined, follow a bit the code and set a breakpoint by file and line number at a convenient location (as much as close to dns lookup functions if you can spot them in the code), so you don't do next/next/ too many times. Hi Daniel, I tryed to extract some useful data but got nothing. I've set breakpoints by indicating file:line of tm module as well as resolve.c file. The same using function names as breakpoints, etc. No result at all, I just get stuf about UDP, IO, read and so. Anyhow I've make some other tests and concluded that the issue is very simple: Kamailio performs NAPTR query but completely ignores its result. I've reported the bug in the tracker: http://sip-router.org/tracker/index.php?do=detailstask_id=135 Cheers. -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
My Kamailio 3.1.3 performs NATPR lookups: use_dns_cache = yes dns_try_naptr = yes dns_udp_pref=1 dns_tcp_pref=1 dns_tls_pref=1 dns_sctp_pref=1 dns_use_search_list=no dns_try_ipv6=yes dns_retr_time=1 dns_retr_no=1 regards Klaus Am 09.06.2011 12:44, schrieb Iñaki Baz Castillo: 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_tcp_pref_dns_tls_pref_dns_udp_pref: 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:q...@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. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/10 Klaus Darilion klaus.mailingli...@pernau.at: My Kamailio 3.1.3 performs NATPR lookups: use_dns_cache = yes dns_try_naptr = yes dns_udp_pref=1 dns_tcp_pref=1 dns_tls_pref=1 dns_sctp_pref=1 dns_use_search_list=no dns_try_ipv6=yes dns_retr_time=1 dns_retr_no=1 With your exact configuration, my kamailio 3.2.0-dev5 (debian package) does not perform NAPTR :( -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/10 Iñaki Baz Castillo i...@aliax.net: With your exact configuration, my kamailio 3.2.0-dev5 (debian package) does not perform NAPTR :( Klaus, could you provide me the following information? 1) kamailio -V 2) Is compiled? a deb package? 3) Could you please call sip:anyth...@oversip.net and show me kamailio logs by filtering dns ( grep | dns ) ? Really thanks a lot. -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/10 Klaus Darilion klaus.mailingli...@pernau.at: Kamailio performs NAPTR lookups, but chooses UDP. I do not know why. You are fully right. I've captured DNS traffic and wireshark clearly shows a NAPTR record. And indeed kamailio prefers SIP over UDP with no reason (it should prefer TCP as my kamailio does not speak TLS): $ 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. Maybe kamailio is taking the order field of the NAPTR incorrectly and gives priority with higher values? I will check it ASAP. Thanks a lot Klaus. -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/10 Iñaki Baz Castillo i...@aliax.net: Maybe kamailio is taking the order field of the NAPTR incorrectly and gives priority with higher values? I will check it ASAP. Ok, I've created domain whose NAPTR record just includes a single SIP+D2T entry (just SIP over TCP). My Kamailio (which uses UDP and TCP) indeed performs the NAPTR queries, but it seems it doesn't like the response and ignores it. Then it performs an usual _sip._udp SRP query. My DNS domains and NAPTR/SRV/A records work OK with any other SIP client implementing RFC 3263. -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
On 6/10/11 8:23 PM, Iñaki Baz Castillo wrote: 2011/6/10 Iñaki Baz Castilloi...@aliax.net: Maybe kamailio is taking the order field of the NAPTR incorrectly and gives priority with higher values? I will check it ASAP. Ok, I've created domain whose NAPTR record just includes a single SIP+D2T entry (just SIP over TCP). My Kamailio (which uses UDP and TCP) indeed performs the NAPTR queries, but it seems it doesn't like the response and ignores it. Then it performs an usual _sip._udp SRP query. My DNS domains and NAPTR/SRV/A records work OK with any other SIP client implementing RFC 3263. Could you set children to 1, attach with gdb to the sip worker handling the invite, send the call and execute step by step to see which condition fails? A simple config with t_relay() should make the debugging easier. Thanks, Daniel -- Daniel-Constantin Mierla http://www.asipto.com ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/10 Daniel-Constantin Mierla mico...@gmail.com: Could you set children to 1, attach with gdb to the sip worker handling the invite, send the call and execute step by step to see which condition fails? A simple config with t_relay() should make the debugging easier. Hi Daniel. Which worker should I attach? My kamailio listens in UDP and TCP. I send the request via UDP and it should do NAPTR stuf and choose SIP TCP (best priority). So: Process:: ID=0 PID=26913 Type=attendant Process:: ID=1 PID=26914 Type=udp receiver child=0 sock=192.168.1.16:8080 Process:: ID=2 PID=26915 Type=slow timer Process:: ID=3 PID=26916 Type=timer Process:: ID=4 PID=26917 Type=MI FIFO Process:: ID=5 PID=26918 Type=ctl handler Process:: ID=6 PID=26919 Type=tcp receiver child=0 Process:: ID=7 PID=26920 Type=tcp main process Which process should I attach? udp receiver? I've tryed to attach udp receiver process in gdb, and by pressing next, next, next (running gdb in the kamailio sources directory) I see nothing about dns functions. Could you please give me some indications please? Thanks a lot. -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
Hello, On 6/10/11 11:16 PM, Iñaki Baz Castillo wrote: 2011/6/10 Daniel-Constantin Mierlamico...@gmail.com: Could you set children to 1, attach with gdb to the sip worker handling the invite, send the call and execute step by step to see which condition fails? A simple config with t_relay() should make the debugging easier. Hi Daniel. Which worker should I attach? My kamailio listens in UDP and TCP. I send the request via UDP and it should do NAPTR stuf and choose SIP TCP (best priority). So: Process:: ID=0 PID=26913 Type=attendant Process:: ID=1 PID=26914 Type=udp receiver child=0 sock=192.168.1.16:8080 Process:: ID=2 PID=26915 Type=slow timer Process:: ID=3 PID=26916 Type=timer Process:: ID=4 PID=26917 Type=MI FIFO Process:: ID=5 PID=26918 Type=ctl handler Process:: ID=6 PID=26919 Type=tcp receiver child=0 Process:: ID=7 PID=26920 Type=tcp main process Which process should I attach? udp receiver? I've tryed to attach udp receiver process in gdb, and by pressing next, next, next (running gdb in the kamailio sources directory) I see nothing about dns functions. Could you please give me some indications please? yes, attach to the process that receives the sip request, in this case the udp receiver. Then if you use a simple config with t_relay(), go to tm module, see where t_relay() is defined, follow a bit the code and set a breakpoint by file and line number at a convenient location (as much as close to dns lookup functions if you can spot them in the code), so you don't do next/next/ too many times. Cheers. Daniel ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/10 Daniel-Constantin Mierla dan...@kamailio.org: yes, attach to the process that receives the sip request, in this case the udp receiver. Then if you use a simple config with t_relay(), go to tm module, see where t_relay() is defined, follow a bit the code and set a breakpoint by file and line number at a convenient location (as much as close to dns lookup functions if you can spot them in the code), so you don't do next/next/ too many times. Understood. Let me some time to do it and I'll come back. Thanks. -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/9 Iñaki Baz Castillo i...@aliax.net: So as my domain oversip.net has no entries with same order, preference value doesn't matter. And of course, SIP over TLS should take preference. Also my SRV records are ok (using other SIP clients they choose TLS first): $ host -t srv _sips._tcp.oversip.net. _sips._tcp.oversip.net has SRV record 1 80 9091 sip1.oversip.net. $ host -t a sip1.oversip.net. sip1.oversip.net has address 91.121.79.216 -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/9 Iñaki Baz Castillo i...@aliax.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?? This is the Kamailio's log about DNS resolution for the above request (note that I've restarted kamailio before the request in order to clean any possible DNS cache): DEBUG: core [dns_cache.c:567]: dns_hash_find(oversip.net(11), 35), h=956 DEBUG: core [resolve.c:924]: get_record: skipping 0 NS (p=0x826fdd, end=0x826fdd) DEBUG: core [resolve.c:940]: get_record: parsing 0 ARs (p=0x826fdd, end=0x826fdd) DEBUG: core [dns_cache.c:1777]: dns_get_related(0x7f359f68db50 (oversip.net, 35), 35, *(nil)) (0) DEBUG: core [dns_cache.c:870]: dns_cache_add: adding oversip.net(11) 35 (flags=0) at 956 DEBUG: core [dns_cache.c:567]: dns_hash_find(_sip._udp.oversip.net(21), 33), h=23 DEBUG: core [resolve.c:924]: get_record: skipping 0 NS (p=0x826f0a, end=0x826f0a) DEBUG: core [resolve.c:940]: get_record: parsing 0 ARs (p=0x826f0a, end=0x826f0a) DEBUG: core [dns_cache.c:1777]: dns_get_related(0x7f359f68de08 (_sip._udp.oversip.net, 33), 33, *(nil)) (0) DEBUG: core [dns_cache.c:870]: dns_cache_add: adding _sip._udp.oversip.net(21) 33 (flags=0) at 23 DEBUG: core [dns_cache.c:2362]: dns_srv_get_nxt_rr(0x7f359f68de08, 0, 0, 1367445037): selected 0/1 in grp. 0 (rand_w=0, rr=0x7f359f68de60 p=0 w=0 rsum=0) DEBUG: core [dns_cache.c:567]: dns_hash_find(sip.oversip.net(15), 1), h=400 DEBUG: core [resolve.c:924]: get_record: skipping 0 NS (p=0x826ef1, end=0x826ef1) DEBUG: core [resolve.c:940]: get_record: parsing 0 ARs (p=0x826ef1, end=0x826ef1) DEBUG: core [dns_cache.c:1777]: dns_get_related(0x7f359f68def0 (sip.oversip.net, 1), 1, *(nil)) (0) DEBUG: core [dns_cache.c:870]: dns_cache_add: adding sip.oversip.net(15) 1 (flags=0) at 400 DEBUG: core [dns_cache.c:2982]: dns_a_resovle(sip.oversip.net, 0) returning 0 DEBUG: core [dns_cache.c:3236]: dns_srv_resolve_ip(_sip._udp.oversip.net, 0, 0), ret=0, ip=91.121.79.216 DEBUG: core [dns_cache.c:3358]: dns_sip_resolve(oversip.net, 0, 0), srv0, ret=0 As per these logs I understand that no NAPTR record is taking place, but just SRV for _sip._udp.oversip.net. -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/9 Iñaki Baz Castillo i...@aliax.net: Even if I set a minor value to dns_tls_preference (so higher priority I expect) it still uses UDP. By reading the doc it seems that higher values of dns_xxx_preference take preference (it's the opposite to NAPTR records order). However as I said I'm trying setting the same value for all the transports. -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
Hi Inaki, I kind of lost the conclusion on your replies, is it not working as documented/expected, or still not? Cheers, Daniel On 6/9/11 2:13 PM, Iñaki Baz Castillo wrote: 2011/6/9 Iñaki Baz Castilloi...@aliax.net: Even if I set a minor value to dns_tls_preference (so higher priority I expect) it still uses UDP. By reading the doc it seems that higher values of dns_xxx_preference take preference (it's the opposite to NAPTR records order). However as I said I'm trying setting the same value for all the transports. -- Daniel-Constantin Mierla -- http://www.asipto.com http://linkedin.com/in/miconda -- http://twitter.com/miconda ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/9 Daniel-Constantin Mierla mico...@gmail.com: I kind of lost the conclusion on your replies, is it not working as documented/expected, or still not? Sorry for so many mails. No, it doesn't work as documented or expected. Summarizing: My Kamailio is not performing NAPTR query for a Request URI sip:x...@oversip.net (no transport, no port). It just does SRV query for SIP over UDP. Kamailio info: version: kamailio 3.2.0-dev5 (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 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 04:43:00 Jun 9 2011 with gcc 4.4.3 --- A MESSAGE with RURI sip:q...@oversip.net arrives (no transport param, no port), t_relay() is invoked, and kamailio just performs a SRV query for SIP over UDP (as logs show): --- DEBUG: core [dns_cache.c:567]: dns_hash_find(oversip.net(11), 35), h=956 DEBUG: core [dns_cache.c:1777]: dns_get_related(0x7f98eebec390 (oversip.net, 35), 35, *(nil)) (0) DEBUG: core [dns_cache.c:870]: dns_cache_add: adding oversip.net(11) 35 (flags=0) at 956 DEBUG: core [dns_cache.c:567]: dns_hash_find(_sip._udp.oversip.net(21), 33), h=23 DEBUG: core [dns_cache.c:1777]: dns_get_related(0x7f98eebec648 (_sip._udp.oversip.net, 33), 33, *(nil)) (0) DEBUG: core [dns_cache.c:870]: dns_cache_add: adding _sip._udp.oversip.net(21) 33 (flags=0) at 23 DEBUG: core [dns_cache.c:2362]: dns_srv_get_nxt_rr(0x7f98eebec648, 0, 0, 1616155624): selected 0/1 in grp. 0 (rand_w=0, rr=0x7f98eebec6a0 p=0 w=0 rsum=0) DEBUG: core [dns_cache.c:567]: dns_hash_find(sip.oversip.net(15), 1), h=400 DEBUG: core [dns_cache.c:1777]: dns_get_related(0x7f98eebec730 (sip.oversip.net, 1), 1, *(nil)) (0) DEBUG: core [dns_cache.c:870]: dns_cache_add: adding sip.oversip.net(15) 1 (flags=0) at 400 DEBUG: core [dns_cache.c:2982]: dns_a_resovle(sip.oversip.net, 0) returning 0 DEBUG: core [dns_cache.c:3236]: dns_srv_resolve_ip(_sip._udp.oversip.net, 0, 0), ret=0, ip=91.121.79.216 DEBUG: core [dns_cache.c:3358]: dns_sip_resolve(oversip.net, 0, 0), srv0, ret=0 My DNS related configuration in Kamailio: --- dns_try_ipv6=no dns_retr_time=1 dns_retr_no=2 dns_servers_no=2 dns_srv_lb=yes dns_try_naptr=yes dns_use_search_list=no dns_search_full_match=no use_dns_cache=yes dns_cache_init=yes use_dns_failover=yes dns_tls_preference=1 dns_tcp_preference=1 dns_udp_preference=1 --- According to the doc it should perform NAPTR query (it's compiled with USE_NAPTR as kamailio -V says, and parameter dns_try_naptr has value yes). Could somebody try to send a MESSAGE or INVITE through Kamailio 3.X with RURI sip:whate...@oversip.net? According to NAPTR/SRV records, destinations should be (in order of preference): 1) TLS 91.121.79.216:9091 2) TCP 91.121.79.216:9090 3) UDP 91.121.79.216:9090 -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
On Thursday 09 June 2011 12:44:11 Iñaki Baz Castillo wrote: 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. The way I read rfc2915, there is no failover mechanism. The application pick the first target that it supports and uses that. There is no mention of trying other records afterwards. Matching/finding NAPTR records stops once the first match is completed. All other records are discarded. From section 2: Order A 16-bit unsigned integer specifying the order in which the NAPTR records MUST be processed to ensure the correct ordering of rules. Low numbers are processed before high numbers, and once a NAPTR is found whose rule matches the target, the client MUST NOT consider any NAPTRs with a higher value for order (except as noted below for the Flags field). Note the last sentence. -- Alex Hermann ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/9 Alex Hermann a...@speakup.nl: The way I read rfc2915, there is no failover mechanism. The application pick the first target that it supports and uses that. There is no mention of trying other records afterwards. Matching/finding NAPTR records stops once the first match is completed. All other records are discarded. From section 2: Hi Alex, two comments: 1) What you say does not explain my issue (as in any case TLS or TCP have more priority in my NAPTR's than UDP). In fact, my exact problem is that my Kamailio is not performing NAPTR query. 2) About your quoted text, indeed RFC 2915 says that. But that just means that, an application (in this case a SIP client) must take *first* the valid NAPTR record with better order (lowest value). But RFC 2915 is just about NAPTR, it can not mandate that applications or protocols cannot try other NAPTR records as failover mechanism. Any SIP client or proxy implementing NAPTR records does failover to the next NAPTR record in case the first one failed (at least those I've tested). But anyhow, my main problem is that my Kamailio is not performing NAPTR query :) Cheers. -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] NAPTR priorities doesn't seem to work properly
2011/6/9 Iñaki Baz Castillo i...@aliax.net: According to the doc it should perform NAPTR query (it's compiled with USE_NAPTR as kamailio -V says, and parameter dns_try_naptr has value yes). Could somebody try to send a MESSAGE or INVITE through Kamailio 3.X with RURI sip:whate...@oversip.net? According to NAPTR/SRV records, destinations should be (in order of preference): 1) TLS 91.121.79.216:9091 2) TCP 91.121.79.216:9090 3) UDP 91.121.79.216:9090 I've tested in other Kamailio 3.X boxes, with same configuration for DNS and support for UDP and TCP. In all cases the same, Kamailio is *NOT* performing a NAPTR query. -- Iñaki Baz Castillo i...@aliax.net ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
