Hello Olle,

Thanks for the reply!

Den mån 14 aug. 2023 kl 11:24 skrev Olle E. Johansson <oej@edvina.net>:

I had similar problems using dispatcher. Asterisk somehow locked up, so dispatcher moved on before asterisk had sent 100 trying. After the call was up on another instance, the first Asterisk suddenly responded and that caused a lot of issues. I could not repeat it, but it happened now and then.

That sounds a bit like the scenario I am having here.

Maybe this is something that we should find a solution too. I don’t know what can be seen as similarities here, but it seems like
an attempt to complete a transaction that is abandoned before any response then wakes up after Kamailio finds another
server by using DNS or dispatcher (generating internal 408 timeout).

I have a test case so that I can reproduce the scenario 100%. But I am still too new to Kamailio to fully understand all the log output from it.

I am running version 5.5.3 and have not tried to upgrade since I was convinced it was the config that was wrong. Perhaps I should try a later version to see if that makes any difference.

If my recording client returns 100 Trying before the 503 I will just get a new INVITE to the other recording-client in the DNS SRV response as expected. If I then also lower the timeout of the fr_inv_timeout to be lower than the time it takes to get the 503 it will send a CANCEL to the recording client and also respond back to A with a 408 Timeout. It will NOT do the DNS failover to the second recording-client in the DNS SRV response as I expected.

It looks to me that these internally generated 408 are not handled in the same way as the externally generated 503. I also tried to externally generate a 408 (instead of the previously generated 503) in the recording UAS. This resulted in a 408 sent towards A and no DNS failover taking place.

I have tried to read up on how the DNS failover and DNS load balancing is supposed to work but I could not find much to read.

Found this document: https://github.com/kamailio/kamailio/blob/master/doc/tutorials/dns.txt

Quote:

"When its internal DNS cache is enabled, Kamailio can also use DNS failover: if

one destination resolves to multiple addresses Kamailio can try all of them until
it finds one to which it can successfully send the packet or it exhausts all
of them. Kamailio (The tm module to be more precise) uses the DNS failover also
when the destination host doesn't send any reply to a forwarded invite within the
SIP timeout interval (whose value can be configured using the tm fr_timer
parameter).
When SRV based load balancing is enabled Kamailio can even do DNS based load
balancing (see RFC2782 and the dns_srv_lb option below). This is using the
weight value in the DNS SRV record."

" use_dns_failover = on | off - if on and sending a request fails (due to not
being allowed from an onsend_route, send failure, blocklisted destination
or, when using tm, invite timeout), and the destination resolves to
multiple ip addresses and/or multiple SRV records, the send will be
re-tried using the next ip/record. In tm's case a new branch will be
created for each new send attempt.
Default: off."

/Mattis

Food for thought.

/O

On 14 Aug 2023, at 10:03, Ihor Olkhovskyi <igorolhovskiy@gmail.com> wrote:

Hello,

I'm having somewhat looks-alike problem with long responce from endpoints and ended up tracking status of transaction (or dialog) htabled with callerid key.
So, when I'm receiving an "outdated" responce, I'm checking the status of the whole transaction (or dialog) and acting accordingly.

Hopefuly, this idea can point you to solution.

Cheers,
Ihor

Le ven. 11 août 2023 à 22:32, Henning Westerholt <hw@gilawa.com> a écrit :

Hello,

this sounds odd. Are you maybe using a failure route to intercept the 503 and send the INVITE to a new destination?

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

From: Mattis Lind <mattislind@gmail.com>
Sent: Donnerstag, 10. August 2023 15:02
To: sr-users@lists.kamailio.org
Subject: [SR-Users] Kamailio dns-failover / dns-loadbalancing with slow responding client.

Hello!

I am looking into a problem where we have Kamailio forwarding calls to two or more "recording-clients". I will try my best to describe the problem and would appreciate it if someone has an idea what to do. Please feel free to ask if you think I have forgotten to describe something that might be important or something is unclear in what I have written.

We use use_dns_failover=yes and dns_srv_lb=yes so calls get load balancing to the "recording-clients". There is also the t_set_fr(60000,1000) parameter set so that if there is no response within 1 second it would try the next recording-client. The SRV record points to two or more recording clients.

It now happens that the recording-clients sometimes have some kind of temporary problem so it will respond with a 503 after 5 seconds.

What happens is that after the 1 second timeout trying to get the INVITE through to the first recording-client Kamailio will internally generate a 408. This will cause it to failover to another recording-client which happily takes care of the INVITE and responds properly with a 200 OK.

Everything would have been just fine except for the fact that the first recording-client is just slow and finally responds with a 503. This 503 is not relayed backwards since a 200 has already been forwarded back to the caller. But when receiving the 503 Kamailio will initiate a new INVITE which is trying to set up a new call to a recording client. It looks like it is doing a new failover regardless if it already has done a failover for this failed transaction.

I don't want Kamailio to send that last INVITE when receiving the 503. How can I configure Kamailio to disregard the last 503 (except for responding with an ACK) and not initiate a new INVITE?

I have tried a lot of different changes to the configuration but failed to achieve this, unfortunately. Do I need to use the dispatcher module to achieve this?

/Mattis

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:

--
Best regards,
Ihor (Igor)
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe: