I ran into the exact same issue. DNS resolution is just stuck on A records for OPTIONS pings irrespective of DNS options. I can see correct DNS resolution with kamcmd dns.lookup but kamcmd dispatcher.list command does not even list the gateways which have a NAPTR/SRV DNS name.

Dispatching INVITEs also fails because none of the trunks are actually loaded in memory for kamailio to process or for me to be able to set its state manually to active.

Any plans on fixing this behavior?

Cheers, Pat.

________________________________ From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Daniel-Constantin Mierla miconda@gmail.com Sent: Friday, November 16, 2018 8:09 AM To: Kamailio (SER) - Users Mailing List; José Seabra Subject: Re: [SR-Users] Dispatcher with a naptr address as destination

Hello,

I think the A query you see is done by the part related to doing OPTIONS keepalive -- I haven't developed that part, but if I remember correctly I saw something like that in the code. Maybe you can disable keepalive via the mod param and see if the query is still done.

For routing, dispatcher is not doing any DNS query, just sets the R-URI or D-URI and then tm is in charge of resolving the destination address, and there should be from NAPTR down, if no transport or port is specified.

Cheers, Daniel

On 14.11.18 17:25, José Seabra wrote: Hello all, I'm trying to use a naptr address as a dispatcher destination and i'm facing some issues here.

When i configure a naptr address in dispatcher table, like: 1:1:sip:proxy-registrar-ci1.fuze.domain:0:0:'':''

I see kamailio making a dns query of type A, but since that this name doesn't have any A record configured in dns, kamailio didn't get any positive reply from it.

Should't kamailio make dns query by this order?

1. NAPTR 2. SRV 3. A

I noticed also that if the name configured in dispatcher table is resolved successfully with A record from dns, then kamailio tries to make a query to NAPTR and then SRV services for the exactly same name used for query previously done(type A), but only if it gets a positive answer from dns to the A type query.

I'm using kamailio version 5.1.0 with the following dns parameters configured:

####### DNS Parameters ######### dns = no rev_dns = no dns_try_ipv6 = no dns_retr_time = 1 dns_retr_no = 1 dns_cache_del_nonexp = no dns_cache_flags = 1 dns_cache_gc_interval = 120 dns_cache_init = 1 dns_cache_mem = 1000 dns_cache_negative_ttl = 60 dns_try_naptr = yes use_dns_cache = on use_dns_failover = on dns_srv_lb = yes

Is there something wrongly configured here that can make kamailio behaves like that?

Thank you. Regards -- Cumprimentos José Seabra

_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.comhttp://www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.comhttp://www.asipto.com

Am Mittwoch, 28. November 2018, 15:06:03 CET schrieb Patrick Murphy:

I ran into the exact same issue. DNS resolution is just stuck on A records for OPTIONS pings irrespective of DNS options. I can see correct DNS resolution with kamcmd dns.lookup but kamcmd dispatcher.list command does not even list the gateways which have a NAPTR/SRV DNS name.

Dispatching INVITEs also fails because none of the trunks are actually loaded in memory for kamailio to process or for me to be able to set its state manually to active.

Any plans on fixing this behavior?

Hi Patrick,

the best would be probably to file a issue about this behavior on our GitHub tracker. Then it could be analyzed in more details.

Best regards,

Henning

Hello,

a solution for the moment would be to add a new flag to mark the destination for no-keepalive, so it is considered to be active always.

Right now the issue is created by the fact that keepalive is enabled and the implementation needs the IP at start up.

However, for NAPTR/SRV records, there can be a different IP returned for each query, so it might not bring much benefits to do keepalives in such cases. This can be added if someone wants to develop it.

Then, just to refresh, you can do SRV based load balancing without dispatcher, it is done by tm and core automatically.

Cheers, Daniel

On 29.11.18 11:32, Patrick Murphy wrote:

Here you go: https://github.com/kamailio/kamailio/issues/1743

The reason I posted here first was that I wanted to rule out any obvious thing I was missing here since there already was a thread open on it.

Cheers, Pat

---

*From:* Henning Westerholt hw@kamailio.org *Sent:* Wednesday, November 28, 2018 9:06 PM *To:* sr-users@lists.kamailio.org *Cc:* Patrick Murphy; José Seabra; miconda@gmail.com *Subject:* Re: [SR-Users] Dispatcher with a naptr address as destination   Am Mittwoch, 28. November 2018, 15:06:03 CET schrieb Patrick Murphy:

...

I ran into the exact same issue. DNS resolution is just stuck on A

records

...

for OPTIONS pings irrespective of DNS options. I can see correct DNS resolution with kamcmd dns.lookup but kamcmd dispatcher.list command

does

...

not even list the gateways which have a NAPTR/SRV DNS name.

Dispatching INVITEs also fails because none of the trunks are actually loaded in memory for kamailio to process or for me to be able to set its state manually to active.

Any plans on fixing this behavior?

Hi Patrick,

the best would be probably to file a issue about this behavior on our GitHub tracker. Then it could be analyzed in more details.

Best regards,

Henning

-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services Kamailio security assessment - https://skalatan.de/de/assessment

I just did it, if you use git, you can pull and have it. Nightly built Debian packages will make it available tomorrow if you use deb.kamailio.org apt repository with nightly builds.

Cheers, Daniel

On 03.12.18 11:37, Patrick Murphy wrote:

Thanks for the fix Daniel,

Any ETA on when this will be backported to 5.2?

*From:* Daniel-Constantin Mierla miconda@gmail.com *Sent:* Thursday, November 29, 2018 10:54 AM *To:* Patrick Murphy; Henning Westerholt; sr-users@lists.kamailio.org *Cc:* José Seabra *Subject:* Re: [SR-Users] Dispatcher with a naptr address as destination

Hello,

a solution for the moment would be to add a new flag to mark the destination for no-keepalive, so it is considered to be active always.

Right now the issue is created by the fact that keepalive is enabled and the implementation needs the IP at start up.

However, for NAPTR/SRV records, there can be a different IP returned for each query, so it might not bring much benefits to do keepalives in such cases. This can be added if someone wants to develop it.

Then, just to refresh, you can do SRV based load balancing without dispatcher, it is done by tm and core automatically.

Cheers, Daniel

On 29.11.18 11:32, Patrick Murphy wrote:

...

Here you go: https://github.com/kamailio/kamailio/issues/1743

The reason I posted here first was that I wanted to rule out any obvious thing I was missing here since there already was a thread open on it.

Cheers, Pat

---

*From:* Henning Westerholt hw@kamailio.org mailto:hw@kamailio.org *Sent:* Wednesday, November 28, 2018 9:06 PM *To:* sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org *Cc:* Patrick Murphy; José Seabra; miconda@gmail.com mailto:miconda@gmail.com *Subject:* Re: [SR-Users] Dispatcher with a naptr address as destination   Am Mittwoch, 28. November 2018, 15:06:03 CET schrieb Patrick Murphy:

...

I ran into the exact same issue. DNS resolution is just stuck on A

records

...

for OPTIONS pings irrespective of DNS options. I can see correct DNS resolution with kamcmd dns.lookup but kamcmd dispatcher.list

command does

...

not even list the gateways which have a NAPTR/SRV DNS name.

Dispatching INVITEs also fails because none of the trunks are actually loaded in memory for kamailio to process or for me to be able to

set its

...

state manually to active.

Any plans on fixing this behavior?

Hi Patrick,

the best would be probably to file a issue about this behavior on our GitHub tracker. Then it could be analyzed in more details.

Best regards,

Henning

-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services Kamailio security assessment - https://skalatan.de/de/assessment

-- Daniel-Constantin Mierla -- www.asipto.com http://www.asipto.com www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com http://www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com http://www.asipto.com