[SR-Users] NAPTR priorities doesn't seem to work properly
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. -- 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] Meaning of empty body in NOTIFY
Hello, the notify is sent to inform about the state of the subscription, which is active in this case. If it would the first subscription to that user and force_active will not be set, then should be subscription state pending, iirc. The empty body does not change anything to the phone information about the watched presentity, which was known to be offline. Cheers, Daniel On 6/8/11 10:06 PM, Eugen Dedu wrote: No idea? On 05/06/11 22:31, Eugen Dedu wrote: Hi, ekiga.net registrar uses kamailio 1.5.3 (yes, a bit old...) and for users who are not registered an empty NOTIFY body is returned when asked by a SUBSCRIBE. What does this mean from SIP standard point of view, and from kamailio point of view (are they identical?) I see in RFC3265/3.1.6.2: If the resource has no meaningful state at the time that the SUBSCRIBE message is processed, this NOTIFY message MAY contain an empty or neutral body but is difficult for me to interpret what it means. Example: I ask the presence for a user xyz who registered and quit application long time ago: SUBSCRIBE sip:x...@ekiga.net SIP/2.0 CSeq: 1 SUBSCRIBE Via: SIP/2.0/UDP 82.238.108.175:5060;branch=z9hG4bKdabe824f-1a8e-e011-9efc-0024d693d8e8;rport User-Agent: Ekiga/3.3.1 From: sip:eugen.d...@ekiga.net;tag=424f-1a8e-e011-9efc-0024d693d8e8 Call-ID: f602824f-1a8e-e011-9efc-0024d693d8e8@snoopy Supported: eventlist To: sip:x...@ekiga.net Accept: application/pidf+xml Accept: multipart/related Accept: application/rlmi+xml Contact: sip:eugen.dedu@82.238.108.175:5060 Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK Expires: 300 Event: presence Content-Length: 0 Max-Forwards: 70 I receive the following answer: NOTIFY sip:eugen.dedu@82.238.108.175:5060 SIP/2.0 CSeq: 1 NOTIFY Via: SIP/2.0/UDP 86.64.162.35;branch=z9hG4bK2a99.b8a72c47.0 User-Agent: Kamailio (1.5.3-notls (i386/linux)) From: sip:x...@ekiga.net;tag=f85b0bd16aaafa8479586ac9f88b3198-10a0 Call-ID: f602824f-1a8e-e011-9efc-0024d693d8e8@snoopy To: sip:eugen.d...@ekiga.net;tag=424f-1a8e-e011-9efc-0024d693d8e8 Contact: sip:86.64.162.35:5060 Subscription-State: active;expires=370 Event: presence Content-Length: 0 Max-Forwards: 70 To resume: What does SIP standard say about this NOTIFY with empty body? Does this mean that the user xyz is offline? Or does this mean that user's status has not changed? In fact, the NOTIFY with empty body (as shown above) is the first one sent by kamailio, so there is no previous state of that user, hence unchanged status has no meaning. Thank you, ___ 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 -- 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/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
[SR-Users] New developer: Peter Dunkley
Hello, just to let everyone to know that starting with today Peter got developer access to GIT repository. He sent many patches in the past months to fix issues or add new features to presence modules (e.g., OMA extensions to embedded XCAP server) -- some are pending to be committed and expect more to come, as he is continuing to work with this part of SIP server. The user id is 'pd'. 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
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
[SR-Users] Functions for DNS
I'm looking to build a set of contacts with q values based on SRV records for serial/parallel forking. I want enum_query (loading the contact set with a q value based on the order,preference of the NAPTR record) but the ruri is not an e.164 number, and SRV records are used instead. Think in terms of find all peer proxies based on SRV lookup, and sort them for use with t_load_contacts()/t_next_contacts(). So far I haven't found any api that exposes the DNS lookups in sip-router. Before rolling something custom with Lua, am I missing something that's already documented? Or are there plans to make such a module? Sure don't want to re-invent the wheel. tia ___ 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
