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 <[email protected]> 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 <[email protected]> > *Sent:* Donnerstag, 10. August 2023 15:02 > *To:* [email protected] > *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 [email protected] > 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 [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
