30 Oct
2020
30 Oct
'20
12:09 a.m.
### Description
I notice a test failure when validating Kamailio 5.4.x, and after looking at the SIP
traces, Kamailio is does not forwarding the first ACK.
However, it does it after receiving a 200 OK re-transmission .
```
192.0.2.12:5062 192.0.2.24:5060
──────────┬───────── ──────────┬─────────
│ │
│ │
│ │ 200 coco (SDP
│ │ <<<────────────────
200 coco (SDP) │
<───────────────────────────────────────────── │
ACK │
─────────────────────────────────────────────> │
ACK │
───────────────────────────────────────────>>> │
│ │ 200 coco (SDP
│ │ <<<────────────────
200 coco (SDP) │
<───────────────────────────────────────────── │
│ │
ACK │
─────────────────────────────────────────────> │
│ │ ACK
│ │ ──────────────────>
```
### Troubleshooting
I did proceed by isolation and ended up concluding that this commit was triggering this
behavior.
Simply, reverting this commit is fixing the problem.
```
commit 28049aafc8dd06c160ce5e7b8d5e4fc728441b0c
Author: Semen Darienko <semen.darienko(a)wildix.com>
Date: Sun May 3 12:26:45 2020 +0200
core: dns - use all NAPTR records
- enable using of all NAPTR records instead of the first one ordered by
priority
- GH #2290
```
I did not look at the code modification and/or anything config specific yet, I will try to
find some time to debug.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539
30 Oct
30 Oct
9:20 a.m.
Thanks for the report, are you testing 5.4.2? Do you have NAPTR records configured in your
setup? Did not noticed something in this regards on my setups.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#issuecomment-719402258
11:45 a.m.
Hi Henning,
I was testing 5.4.2 but I ended up going back as far a May 3.
While trying to reproduce I just noticed that now I see 300-400ms to relay the ACK. (not
enough to trigger a re-transmission anymore)
- First INVITE and BYE are relayed in 1ms.
- When I rollback the commit the ACK is also relayed in 1ms.
- The same problem is found on another gitlab runner test box and the delay seems to be
worst.
- No NAPTR resolution should be needed since the RURI is an IP.
```
2020/10/30 03:02:48.442251 192.0.2.23:5060 -> 192.0.2.24:5060
ACK sip:192.0.2.2:5060 SIP/2.0
Record-Route: <sip:192.0.2.23;lr>
Via: SIP/2.0/UDP 192.0.2.23:5060;branch=z9hG4bKa37.abcde5432ec8393b4ab82cf54fa2d04a.0
Via: SIP/2.0/UDP
192.0.2.7:5777;received=192.0.2.7;rport=5777;branch=z9hG4bKPj0bd8b830-4a10-467a-9984-3a8dceb15141
Max-Forwards: 69
From: sip:4468246@fakecustomer.xyz;tag=5f1e815a-3786-499a-ba48-6b1dfde0544d
To: sip:+11234567890@proxy1;tag=778aaba7-ab0e-4a60-9596-65d28d86a43e
Call-ID: a7319394-6352-4465-b673-d49ea8de8190
CSeq: 10636 ACK
Route: <sip:192.0.2.24;lr>
Content-Length: 0
```
It seems it is reproducible as it is always adding a significant delay, sometimes
triggering a 200 OK re-transmission.
Not sure if it may be more complicated to reproduce due to config params.
I will not be able to debug to confirm more into details until next Wednesday.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#issuecomment-719480125
2 Nov
2 Nov
4:16 p.m.
Interesting, have not seen this in my sngrep observations. Looking forward to get more
details.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#issuecomment-720533758
4 Nov
4 Nov
6:18 p.m.
One example with +50ms, I need to figure out why there is not a fluctuating delay it seems
like we are doing more resolution.
```
2020-11-04T17:15:46.613616287Z 1(175) INFO: <script>:
[MAIN][ACK][301bf833-a402-4f89-9d10-f3f3bd7822fb] from[4468246] to[+11234567890]
ruri[sip:192.0.2.2:5060]
2020-11-04T17:15:46.613918650Z 1(175) INFO: <core> [core/dns_cache.c:3296]:
dns_naptr_sip_resolve(): do naptr: dns_get_entry: 192.0.2.2
2020-11-04T17:15:46.660225641Z 1(175) INFO: <core> [core/dns_cache.c:3338]:
dns_naptr_sip_resolve(): do naptr: not found: 192.0.2.2
2020-11-04T17:15:46.660247791Z 1(175) INFO: <core> [core/dns_cache.c:3340]:
dns_naptr_sip_resolve(): do naptr: not found dns_srv_resolve: 192.0.2.2
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#issuecomment-721863651
6:25 p.m.
Are you still observing the error when NAPTR is disabled (its disabled by default)
dns_try_naptr = no
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#issuecomment-721867611
6:37 p.m.
Indeed I have it enabled, `dns_try_naptr = yes`
Will not execute this code, I just double checked since you asked.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#issuecomment-721873895
6:38 p.m.
it seems like something bypassing the cache.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#issuecomment-721874238
6:44 p.m.
Ok, have a look to the DNS queries its actually does on network level.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#issuecomment-721877509
6:56 p.m.
let me try to identify why there is an excessive delay when getting it out of the cache
(probably another resolution) and see how this can be avoided.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#issuecomment-721883511
7:01 p.m.
or if this is in fact the expected behavior, confirm it was not working as expected
before.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#issuecomment-721885663
7:07 p.m.
Closed #2539.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#event-3958852442
7:08 p.m.
Reopened #2539.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#event-3958852729
7:38 p.m.
found it, we disabled the check
```
/* check if it's an ip address */
if ( ((tmp_ip=str2ip(name))!=0)
|| ((tmp_ip=str2ip6(name))!=0)
```
and always do an
```
if ((e=dns_get_entry(name, T_NAPTR))==0)
```
I will propose an MR
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#issuecomment-721903827
7:43 p.m.
If you are referring to src/core/dns_cache.c - this code is from 2006.
I has not been changed in the 28049aafc8dd06c16 commit referred above.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#issuecomment-721906352
7:48 p.m.
I did mention the commit in question, I can now confirm reading the code that Kamailio is
doing DNS NAPTR resolution
on IP addresses, this was not intended but the desired improvement.
```
commit 28049aafc8dd06c160ce5e7b8d5e4fc728441b0c
Author: Semen Darienko <semen.darienko(a)wildix.com>
Date: Sun May 3 12:26:45 2020 +0200
core: dns - use all NAPTR records
- enable using of all NAPTR records instead of the first one ordered by
priority
- GH #2290
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#issuecomment-721908901
7:58 p.m.
We mean different things probably. But thank you, lets just look at your proposed merge
request. :-)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#issuecomment-721913752
5 Nov
5 Nov
4:17 p.m.
New subject: [kamailio/kamailio] NAPTR resolution on IP addresses in kamailio 5.4.x (#2539)
fix merged into master and cherry-picked in 5.4, thank to Semen for the review.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#issuecomment-722442880
5:14 p.m.
New subject: [kamailio/kamailio] NAPTR resolution on IP addresses in kamailio 5.4.x (#2539)
Closed #2539.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2539#event-3963210364
1275
days inactive
1282
days old
18 comments
2 participants
participants (2)
-
Henning Westerholt -
Julien Chavanton