Re: [SR-Users] KEMI jsdt CommonJS-based module

[Daniel-Constantin Mierla]

Hello,

I just merged the pull request, thanks!

I had some remarks/questions in a comment made on PR, let me post them
here for discussing further:

  * one can load another JS file in the Kamailio KEMI JS file, but this
another JS file has its content following the node.js module specs,
right? It cannot be just any JS code

  * does it allow loading any node.js modules available out there that
do not require the node.js core modules (which are embedded (compiled)
in node.js binary)?

Cheers,
Daniel

On 23.02.22 13:55, Ian Carlson wrote:
>
> Greetings,
>
>  
>
> Thanks for the feedback. Since this was something I requested, I
> thought I'd have a go. I was able to log messages from nested
> require() via JSDT loaded file. I'm barely literate in C, so
> hopefully, I'm doing something helpful and not wasting everyone's
> time. If I happen to be on a good track, I'll try to keep going with a
> bit of guidance.
>
>  
>
> https://github.com/kamailio/kamailio/issues/3037
>
> https://github.com/kamailio/kamailio/pull/3038
>
>  
>
> Cheers,
>
> Ian
>
>  
>
>  
>
> *From:* Daniel-Constantin Mierla 
> *Sent:* Monday, February 21, 2022 4:44 AM
> *To:* Kamailio (SER) - Users Mailing List
> ; Ian Carlson 
> *Subject:* Re: [SR-Users] KEMI jsdt CommonJS-based module
>
>  
>
> Hello,
>
> I didn't notice that require() was not in the duktape 2.x, I will try
> to add support for module-duktape when I get a chance. If someone
> wants to do it, pull requests are welcome -- it does not seem to be
> complex:
>
>   * https://github.com/svaarala/duktape/tree/master/extras/module-duktape
>
> The module-node sounds interesting, but not being familiar with
> node.js, looks it need more work to enable it:
>
>   * https://github.com/svaarala/duktape/tree/master/extras/module-node
>
> Cheers,
> Daniel
>
> On 20.02.22 00:50, Ian Carlson wrote:
>
> Greetings,
>
>  
>
> I’m new to Kamailio and working to add Kamailio to an existing
> Asterisk solution.  I’m attracted to the idea of routing via KEMI
> jsdt since our Asterisk ARI is using nodejs.  Playing with KEMI
> jsdt I was trying to use require() to break up the monolithic
> routing script.  It seems that Kamailio uses Ducktape 2 without
> module-node or module-ducktape, requiring all routing in a single
> file?  I’d appreciate any suggested practices for managing
> Kamailio configurations.
>
>  
>
> Cheers,
>
> Ian
>
>  
>
>  
>
>
>
> __
>
> Kamailio - Users Mailing List - Non Commercial Discussions
>
>   * sr-users@lists.kamailio.org
>
> Important: keep the mailing list in the recipients, do not reply only to 
> the sender!
>
> Edit mailing list options or unsubscribe:
>
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> -- 
> Daniel-Constantin Mierla -- www.asipto.com 
> www.twitter.com/miconda  -- 
> www.linkedin.com/in/miconda 
> Kamailio Advanced Training - Online
>   Feb 21-24, 2022 (America Timezone)
>   * https://www.asipto.com/sw/kamailio-advanced-training-online/

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online
  March 28-31, 2022 (Europe Timezone)
  * https://www.asipto.com/sw/kamailio-advanced-training-online/
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] [sr-dev] Info: SIP resources collection

[Jiri Kuthan]

On 16.02.22 11:16, Daniel-Constantin Mierla wrote:

Hello,

over the 20 years I used various SIP applications, libraries and tools
but after a while I forgot many of them, therefore I tried to collect
many in a list hosted on github at:

   * https://github.com/miconda/sip-resources

Hoping it proves useful for some of you!

Cheers,
Daniel




perfect job, thank you Daniel!

-jiri

__
Kamailio - Users Mailing List - Non Commercial Discussions
 * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
 * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Problem with auth_ephemeral and parse_uri(): bad port in uri

[Daniel-Constantin Mierla]

Hello,

it should be reviewed properly if does not work before removing. The
entire auth_ephemeral is deprecated from specs point of view, as the
ietf draft never made it to rfc, but it is still useful to use at least
for PoC. I don't have access to some old deployments using mode 0 to see
if they were changed meanwhile.

Cheers,
Daniel

On 24.02.22 10:39, Henning Westerholt wrote:
> Hello,
>
> yes, if it is not working and also deprecated, if probably should be removed. 
> You could open an issue for that or create (even better) a pull request.
>
> Cheers,
>
> Henning
>
> -- 
> Henning Westerholt – https://skalatan.de/blog/
> Kamailio services – https://gilawa.com
>
> -Original Message-
> From: sr-users  On Behalf Of Vlasis 
> Chatzistavrou
> Sent: Sunday, February 20, 2022 8:07 PM
> To: mico...@gmail.com; Kamailio (SER) - Users Mailing List 
> 
> Subject: Re: [SR-Users] Problem with auth_ephemeral and parse_uri(): bad port 
> in uri
>
> Hi Daniel,
>
> Just an update, I tested this with username_format set to 1 and set the
> To: and From: headers to be the phone's username (ie without the timestamp). 
> This worked without problems.
>
> However, setting the username_format to 0 (the deprecated option) does not 
> work even with the correct To: and From: headers. Since this option is 
> already deprecated perhaps it could be removed in future versions to avoid 
> confusion?
>
> On 25/1/2022 11:38, Vlasis Chatzistavrou wrote:
>> Thank you Daniel,
>>
>> I will give this a try.
>>
>> On 25/1/2022 11:11, Daniel-Constantin Mierla wrote:
>>> Hello,
>>>
>>> as far as I remember, the format with "user:timestamp" is only for 
>>> authentication username field, respectively the username attribute in 
>>> Proxy-/Authorization header. The subscriber address is still 
>>> user@domain, so that has to be used in From/To headers.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 02.01.22 20:36, Vlasis Chatzistavrou wrote:
 Hello,

 I have a problem with Kamailio 5.4.6 and auth_ephemeral. I have the 
 following in the Kamailio configuration

 loadmodule "auth_ephemeral"
  modparam( "auth_ephemeral", "sha_algorithm", 3 )
  modparam( "auth_ephemeral", "username_format", 0 )
  modparam( "auth_ephemeral", "secret", 1234 )

 as per

 https://kamailio.org/docs/modules/4.1.x/modules/auth_ephemeral.html#
 auth_eph.p.username_format



 and registrations fail. In the logs we see:

 Jan  2 18:21:10 enswitch43 /sbin/kamailio[37501]: DEBUG: {1 545 
 REGISTER rhaqgafd7boteg24jp5db0} sanity [sanity.c:777]:
 check_parse_uris(): looking up From header Jan  2 18:21:10 
 enswitch43 /sbin/kamailio[37501]: DEBUG: {1 545 REGISTER 
 rhaqgafd7boteg24jp5db0} sanity [sanity.c:817]:
 check_parse_uris(): parsing From URI Jan  2 18:21:10 enswitch43 
 /sbin/kamailio[37501]: DEBUG: {1 545 REGISTER 
 rhaqgafd7boteg24jp5db0} 
 [core/parser/parse_uri.c:1296]: parse_uri(): bad port in uri (error 
 at char 5 in state 2) parsed: (17) 
 / (35) Jan  2 18:21:10 
 enswitch43 /sbin/kamailio[37501]: WARNING: {1 545 REGISTER 
 rhaqgafd7boteg24jp5db0} sanity [sanity.c:820]:
 check_parse_uris(): failed to parse From uri


 Apparently Kamailio is confused by the timestamp following the 
 username separated by the : character. The REGISTER message is below:

 REGISTER sip:192.168.2.99 SIP/2.0
 Via: SIP/2.0/WSS 192.0.2.202;branch=z9hG4bK5452321
 Max-Forwards: 70
 To: "3518929" 
 From: "3518929" ;tag=ht76o8b2b6
 Call-ID: phkj9mi2n3s3ju7uu3qq2f
 CSeq: 274 REGISTER
 Contact:
 ;reg-id=1;+sip.instance=">>> n:uuid:ca5e9372-dfa1-459a-b6ba-4398d23bd896>";expires=300

 Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
 Supported: path, gruu, outbound
 User-Agent: Raspberry Phone (SipJS - 0.11.6)
 Content-Length: 0

 and Kamailio parses it as sip:: instead of 
 sip::.

 Is this a bug that should be reported or is there any setting that I 
 am missing?


 __
 Kamailio - Users Mailing List - Non Commercial Discussions
   * sr-users@lists.kamailio.org
 Important: keep the mailing list in the recipients, do not reply 
 only to the sender!
 Edit mailing list options or unsubscribe:
   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * 

Re: [SR-Users] ?= kamailio : how to xlog the value of "myself"=?utf-8?q? ?

[Olle E. Johansson]

Hello!

“myself” is a function that has one or several domains in it configured in your 
configuration. What you normally want to log is the domain that matches myself, 
with could be $rD if you are checking the domain of the request URI.

/O
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Problem with auth_ephemeral and parse_uri(): bad port in uri

[Henning Westerholt]

Hello,

yes, if it is not working and also deprecated, if probably should be removed. 
You could open an issue for that or create (even better) a pull request.

Cheers,

Henning

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

-Original Message-
From: sr-users  On Behalf Of Vlasis 
Chatzistavrou
Sent: Sunday, February 20, 2022 8:07 PM
To: mico...@gmail.com; Kamailio (SER) - Users Mailing List 

Subject: Re: [SR-Users] Problem with auth_ephemeral and parse_uri(): bad port 
in uri

Hi Daniel,

Just an update, I tested this with username_format set to 1 and set the
To: and From: headers to be the phone's username (ie without the timestamp). 
This worked without problems.

However, setting the username_format to 0 (the deprecated option) does not work 
even with the correct To: and From: headers. Since this option is already 
deprecated perhaps it could be removed in future versions to avoid confusion?

On 25/1/2022 11:38, Vlasis Chatzistavrou wrote:
> Thank you Daniel,
>
> I will give this a try.
>
> On 25/1/2022 11:11, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> as far as I remember, the format with "user:timestamp" is only for 
>> authentication username field, respectively the username attribute in 
>> Proxy-/Authorization header. The subscriber address is still 
>> user@domain, so that has to be used in From/To headers.
>>
>> Cheers,
>> Daniel
>>
>> On 02.01.22 20:36, Vlasis Chatzistavrou wrote:
>>> Hello,
>>>
>>> I have a problem with Kamailio 5.4.6 and auth_ephemeral. I have the 
>>> following in the Kamailio configuration
>>>
>>> loadmodule "auth_ephemeral"
>>>  modparam( "auth_ephemeral", "sha_algorithm", 3 )
>>>  modparam( "auth_ephemeral", "username_format", 0 )
>>>  modparam( "auth_ephemeral", "secret", 1234 )
>>>
>>> as per
>>>
>>> https://kamailio.org/docs/modules/4.1.x/modules/auth_ephemeral.html#
>>> auth_eph.p.username_format
>>>
>>>
>>>
>>> and registrations fail. In the logs we see:
>>>
>>> Jan  2 18:21:10 enswitch43 /sbin/kamailio[37501]: DEBUG: {1 545 
>>> REGISTER rhaqgafd7boteg24jp5db0} sanity [sanity.c:777]:
>>> check_parse_uris(): looking up From header Jan  2 18:21:10 
>>> enswitch43 /sbin/kamailio[37501]: DEBUG: {1 545 REGISTER 
>>> rhaqgafd7boteg24jp5db0} sanity [sanity.c:817]:
>>> check_parse_uris(): parsing From URI Jan  2 18:21:10 enswitch43 
>>> /sbin/kamailio[37501]: DEBUG: {1 545 REGISTER 
>>> rhaqgafd7boteg24jp5db0} 
>>> [core/parser/parse_uri.c:1296]: parse_uri(): bad port in uri (error 
>>> at char 5 in state 2) parsed: (17) 
>>> / (35) Jan  2 18:21:10 
>>> enswitch43 /sbin/kamailio[37501]: WARNING: {1 545 REGISTER 
>>> rhaqgafd7boteg24jp5db0} sanity [sanity.c:820]:
>>> check_parse_uris(): failed to parse From uri
>>>
>>>
>>> Apparently Kamailio is confused by the timestamp following the 
>>> username separated by the : character. The REGISTER message is below:
>>>
>>> REGISTER sip:192.168.2.99 SIP/2.0
>>> Via: SIP/2.0/WSS 192.0.2.202;branch=z9hG4bK5452321
>>> Max-Forwards: 70
>>> To: "3518929" 
>>> From: "3518929" ;tag=ht76o8b2b6
>>> Call-ID: phkj9mi2n3s3ju7uu3qq2f
>>> CSeq: 274 REGISTER
>>> Contact:
>>> ;reg-id=1;+sip.instance=">> n:uuid:ca5e9372-dfa1-459a-b6ba-4398d23bd896>";expires=300
>>>
>>> Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
>>> Supported: path, gruu, outbound
>>> User-Agent: Raspberry Phone (SipJS - 0.11.6)
>>> Content-Length: 0
>>>
>>> and Kamailio parses it as sip:: instead of 
>>> sip::.
>>>
>>> Is this a bug that should be reported or is there any setting that I 
>>> am missing?
>>>
>>>
>>> __
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>   * sr-users@lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply 
>>> only to the sender!
>>> Edit mailing list options or unsubscribe:
>>>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dispatcher.reload

[Daniel-Constantin Mierla]

Hello,

you can use the rpc command hash to see what destination is selected.
The hash id value does not change, for a user/uri is always the same
value. Then the 'hashid % number_of_destination' (modulo operation) is
used to pick up the destination from a dispatcher group.

If after the reload is the same number of destination is the group, the
destination at the same index in the group is used. If the number of
destinations in the group is different, then a redistribution can happen.

Cheers,
Daniel

On 24.02.22 09:32, David Villasmil wrote:
> Hello and thanks for your reply, all.
> Actually I WANT that behavior :) switching users to other boxes.
>
> Thanks!
>
> On Thu, 24 Feb 2022 at 07:45, Paolo Visintin
>  wrote:
>
> Hello David, 
> In my experience yes, the hash policy will be reset after reload
> but you can use htable to cache results and avoid this behavior.
>
> Regards
>
> Paolo
>
>
> Il giorno mer 23 feb 2022 alle 23:38 David Villasmil
>  ha scritto:
>
> Hello guys,
>
> We're dispatching with hash over user, if i
> execute |dispatcher.reload|
> 
> 
> does the dispatcher list gets calculated? i.e. user A is
> always dispatched to box3, if i reload, is the hash
> recalculated and will probably be dispatched differently?
>
>
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not
> reply only to the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> -- 
>   
>
>
> Paolo Visintin
>
> *evoseed s.r.l.*
>
>   
>  
>    * *phone:  +39 346 09 86 641
>  mail:  paolo.visin...@evoseed.io
>   site:  evoseed.io 
> address:  Via Lucrezio 13, Trieste Italy
> 
> 
>
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply
> only to the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> -- 
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online
  March 28-31, 2022 (Europe Timezone)
  * https://www.asipto.com/sw/kamailio-advanced-training-online/
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dispatcher.reload

[David Villasmil]

Hello and thanks for your reply, all.
Actually I WANT that behavior :) switching users to other boxes.

Thanks!

On Thu, 24 Feb 2022 at 07:45, Paolo Visintin 
wrote:

> Hello David,
> In my experience yes, the hash policy will be reset after reload but you
> can use htable to cache results and avoid this behavior.
>
> Regards
>
> Paolo
>
>
> Il giorno mer 23 feb 2022 alle 23:38 David Villasmil <
> david.villasmil.w...@gmail.com> ha scritto:
>
>> Hello guys,
>>
>> We're dispatching with hash over user, if i execute dispatcher.reload
>> 
>> does the dispatcher list gets calculated? i.e. user A is always
>> dispatched to box3, if i reload, is the hash recalculated and will probably
>> be dispatched differently?
>>
>>
>> Regards,
>>
>> David Villasmil
>> email: david.villasmil.w...@gmail.com
>> phone: +34669448337
>>
> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>   * sr-users@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> --
> Paolo Visintin
>
> *evoseed s.r.l.*
>
>   phone:  +39 346 09 86 641
>  mail:  paolo.visin...@evoseed.io
>   site:  evoseed.io
> address:  Via Lucrezio 13, Trieste Italy
> 
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- 
Regards,

David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] ACK and DNS failover

[Henning Westerholt]

Hello,

as Daniel pointed out:

> If the ACK is not received, the target is supposed to retransmit the 200ok, 
> to force retransmission of the ACK

So the ACK is not supposed to be retransmitted, only the 200OK from the UAS 
side.

The ACK is handled from the UAC side, and it needs send at least one ACK for 
every 200 OK that it receives. Have a look e.g. here :

https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-December/020969.html

But there are of course differences regarding implementation in user agents.

Cheers,

Henning

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

From: sr-users  On Behalf Of Julien 
Klingenmeyer
Sent: Wednesday, February 23, 2022 5:34 PM
To: mico...@gmail.com; Kamailio (SER) - Users Mailing List 

Subject: Re: [SR-Users] ACK and DNS failover

Thanks, Daniel, for this complete explanation.

It is clear now why ACKs are not being processed by the DNS failover feature.
Actually, I expect the primary node to be restored quickly. So considering this 
it is OK if there is ACK retransmission to this primary node only, until it 
comes up again.

But from what I could see, Kamailio A does not receive multiple ACK (because of 
retransmission) all the time, although multiple 200 OK are generated by the 
peer.
When Kamailio A receives multiple ACK retransmission, it does relay them to 
Kamailio B1 each time: great!
But some previous hops (not Kamailio ones) can send to it one unique ACK 
although the multiple 200 OK => is it something RFC-compliant? Could it be due 
to a TLS connection between these previous hops and Kamailio A?
I wonder if some previous hops do not relay the retransmission packets because 
they know that the initial ACK was already correctly forwarded thanks to the 
TLS connection. So maybe this is why they only relay the initial ACK and this 
does not trigger ACK retransmission.
If so, would it be possible in the routing script to do a “manual” ACK 
retransmission (in a failure_route or something) when I detect a broken TLS 
connection?
In the logs I do see a failure:
ERROR:  [core/tcp_main.c:4457]: handle_tcpconn_ev(): connect 
:5061 failed
Could I catch it to trigger a retransmission of the ACK request ?

Thanks

Julien

De : Daniel-Constantin Mierla mailto:mico...@gmail.com>>
Répondre à : "mico...@gmail.com" 
mailto:mico...@gmail.com>>
Date : mercredi 23 février 2022 à 10:50
À : "Kamailio (SER) - Users Mailing List" 
mailto:sr-users@lists.kamailio.org>>, Julien 
Klingenmeyer 
mailto:julien.klingenme...@ovhcloud.com>>
Objet : Re: [SR-Users] ACK and DNS failover


Hello,

well, the ACK is a request without a response, practically it is a stateless 
request, no sip transaction can be created for it because there is no response 
to wait for it. That's by design from SIP specs.

In other words, it is no way to know if the target received or not the ACK. If 
the ACK is not received, the target is supposed to retransmit the 200ok, to 
force retransmission of the ACK.

In the case of tcp/tls, one can leverage transport layer to know that it could 
not be transmitted, but for udp is no way, and even more, in sip transport 
layer is decoupled from sip singling layer (ie., same connection can carry 
traffic for many users, many transactions, etc...). Also, for tcp/tls, with 
asynchronous sending, the feedback of not able to send is not immediate. But 
can be coded somehow, it's about open source after all ...

Moreover, ACK does not belong to INVITE transaction and can have a different 
path than the INVITE, being a matter of record-route headers.

So lack (or limitations) of DNS failover for ACK comes from the above.

You can either consider this a corner case, if the target servers are supposed 
to run always and in case of one becoming unavailable for long time, the dns is 
updated accordingly, or, if you know that ACK has to be sent to the address 
where 200ok came from, then you can store that in htable and use it for sending 
out the ACK (but again, this may not be the case always according to the specs, 
but can be in your deployment).

Cheers,
Daniel
On 23.02.22 15:59, Julien Klingenmeyer wrote:
Hello,

I use DNS failover feature for routing some calls, and I wonder about its 
limitations.
I noticed that INVITE and ReINVITE requests are correctly routed based on SRV 
priority/weight in case of failure, but ACK requests do not use them.

Let’s say I have Kamailio A relaying requests to a pool of Kamailios B1 and B2 
in TLS.
DNS records are the below ones.

kamailiob.net.60 NAPTR 20   100  S SIPS+D2T 
_sips._tcp.kamailiob.net.
_sips._tcp.kamailiob.net.   60 SRV 110   5061   kamailiob-1.net.
_sips._tcp.kamailiob.net.   60 SRV 210   5061   kamailiob-2.net.

If B1 is down, I expect requests being relayed to B2 (because of priority 2 in 
the SRV record).

1.   For initial INVITEs: R-URI is sip:kamailiob.net

1.   If B1 is down, the request