### Description
<!-- Explain what you did, what you expected to happen, and what actually happened. -->
We are running Kamailio in front of a backend farm, REGISTERs go directly to the backend. After registration, the backend sends out OPTIONS requests periodically. This worked with 5.8.2. Now when running a 5.8.3 server (taken from your apt repository), I get the following errors in the log:
``` Sep 04 14:41:36 sipproxy /usr/sbin/kamailio[124]: ERROR: tm [ut.h:235]: uri2dst2(): bad_uri: [sip:[[2001:16e0:affe:affe:24a2:55a2:15bf:23d1]]:59580;transport=tls] Sep 04 14:41:36 sipproxy /usr/sbin/kamailio[124]: ERROR: tm [t_fwd.c:1764]: t_forward_nonack(): failure to add branches ```
There are extra square brackets in the URI. I compared the REGISTERs from old and new Kamailio to the backend, and also the OPTIONS packets sent by the backend, the are identical except for the obvious differences.
### Troubleshooting
#### Reproduction
<!-- If the issue can be reproduced, describe how it can be done. -->
* Have a Kamailio with nathelper enabled. * Do something like this for nat detection: ``` def ksr_route_natdetect(self, msg): KSR.force_rport() # Checks if request goes to backend or not if not msg.is_internal_message(): KSR.setbflag(FLB_NATB) KSR.setflag(FLT_NATS) if KSR.textops.is_present_hf("Contact") > 0: if KSR.nathelper.set_contact_alias() < 0: msg.log("Error in aliasing contact") KSR.sl.sl_send_reply(400,"Bad request") return False else: if msg.is_request(): KSR.nathelper.handle_ruri_alias() return 1 ```
* register a phone to the backend (e.g. an Asterisk server) * send an OPTIONS packet from the backend to the registered device.
#### SIP
The REGISTER from Kamailio to the backend looks like this:
``` REGISTER sip:domain;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 100.74.11.1:5063;branch=z9hG4bK6c3e.2cedb59e7724d263255c1996d9d2d4fa.0;i=6 Via: SIP/2.0/TLS [2001:16e0:affe:affe:24a2:55a2:15bf:23d1]:61391;received=2001:16e0:affe:affe:24a2:55a2:15bf:23d1;rport=61391;branch=z9hG4bKPjAB7F905A-A6A2-491D-A456-89C8FD4C5183;alias Max-Forwards: 69 From: sip:dZmIQyb70tzt2J9@sdammone;tag=AAA80708-4968-4B49-95B8-7DBCEFCC5E62 To: sip:dZmIQyb70tzt2J9@sdammone Call-ID: 4922AA11-F4BA-49D0-AE64-EECF49735684 CSeq: 44208 REGISTER User-Agent: foobar Supported: outbound, path Contact: sip:dZmIQyb70tzt2J9@[2001:16e0:affe:affe:24a2:55a2:15bf:23d1]:61391;transport=TLS;p-xs=6eb17056fba34ce6bc7d458a1a7a80ba;ob;alias=[2001:16e0:affe:affe:24a2:55a2:15bf:23d1]~61391~3;reg-id=1;+sip.instance="urn:uuid:00000000-0000-0000-0000-00000c73bfc6" Expires: 300 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Content-Length: 0 Path: sip:100.74.11.1:5063;transport=tcp;lr;xep=true ```
The OPTIONS packet from backend to the client looks like this:
``` OPTIONS sip:dZmIQyb70tzt2J9@[2001:16e0:affe:affe:24a2:55a2:15bf:23d1]:61391;transport=TLS;p-xs=6eb17056fba34ce6bc7d458a1a7a80ba;ob;alias=[2001:16e0:affe:affe:24a2:55a2:15bf:23d1]~61391~3 SIP/2.0 Via: SIP/2.0/TCP 100.74.130.66:5060;rport;branch=z9hG4bKPj3e558221-2506-4a2b-9daa-ff7e73d05e8c;alias From: sip:dZmIQyb70tzt2J9@sdammone;tag=18c9809a-4775-4c35-8e88-5c5a7bdcf1fe To: sip:dZmIQyb70tzt2J9@[2001:16e0:affe:affe:24a2:55a2:15bf:23d1];p-xs=6eb17056fba34ce6bc7d458a1a7a80ba;ob;alias=[2001:16e0:affe:affe:24a2:55a2:15bf:23d1]~61391~3 Contact: sip:dZmIQyb70tzt2J9@100.74.130.66:5060;transport=TCP Call-ID: 2e1efbd3-9366-4542-b909-83429266b6ef CSeq: 2989 OPTIONS Supported: path Route: sip:100.74.11.1:5063;transport=tcp;lr;xep=true Max-Forwards: 70 User-Agent: barfoo Content-Length: 0 ```
#### Log Messages
``` Sep 04 14:41:36 sipproxy /usr/sbin/kamailio[124]: ERROR: tm [ut.h:235]: uri2dst2(): bad_uri: [sip:[[2001:16e0:affe:affe:24a2:55a2:15bf:23d1]]:59580;transport=tls] Sep 04 14:41:36 sipproxy /usr/sbin/kamailio[124]: ERROR: tm [t_fwd.c:1764]: t_forward_nonack(): failure to add branches ```
### Possible Solutions
Downgrading to 5.8.2 again works.
I suppose, the problem comes from this commit by @vingarzan: https://github.com/kamailio/kamailio/commit/52ab6f3dcf5ad8d967be8bdecaa64ef3...
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
``` version: kamailio 5.8.3 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 11.4.0 ```
* **Operating System**:
<!-- Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...; Kernel details (output of `lsb_release -a` and `uname -a`) -->
``` Ubuntu Jammy ```
Want's IPv6 supposed to get rid of NAT, so nathelper shouldn't be needed anymore :-) ?!?
I pushed a fix for it, backported to 5.8 as well.
As an alternative fix with 5.8.3, you can replace set_contact_alias() with add_contact_alias() which should add the alias only if different than the contact address, which in this case is the same.
I definitely contributed to this :nauseated_face: ...
Seems that the function that I am using (`add_contact_alias()` with 3 parameters) never added `[` and `]` around IPv6 addresses. I took it as quite OK, and the rule, since the alias encoding uses `~` as separator between IP and port, so there was no need to surround the IPv6 address. In `handle_ruri_alias()` then I patched it to add them for a valid Request-URI result and that was my "fix". Without it, when using it with IPv6, the Request-URI was invalid.
Yet what I didn't observe was that other functions (`add_contact_alias()` without parameters and `set_contact_alias()`) always did include the square brackets around the IPv6 in the saved contact alias. So with my extra addition, using the alias there is a doubling of the square brackets. In hindsight making all the alias creating code consistent would've been a better fix, but I simply didn't realize it probably was fine in all other cases, but in mine. Sorry...
Thanks for the workaround, just tested it and it works. Why are there two functions doing essentially the same anyways?
The result is the same in terms of the SIP message sent out, but internally there are different approaches. If you need other modules like presence and dialog to know about the alias parameter in the Contact URI, then set_contact_alias() has to be used. add_contact_alias() is only about header content update. Docs mention it a bit. Also, the later adds it only if different than contact uri.
Closed #3968 as completed.
Thanks for the clarification.
-
Daniel-Constantin Mierla -
Dragos Vingarzan
-
Sebastian Damm