Problem with IPv6, TLS and advertise param

[joelsdc]

Description

We want to be able to handle reINVITEs over TLS so calls can reconnect when they switch networks (for example from wifi to mobile data).

We have the following config in kamailio.cfg:

listen=tls:1.1.1.1:443 advertise sbc01.domain.com:443
listen=tls:[AAAA:BBBB:CCCC:DDDD:EEEE:FFFF:GGGG:HHHH]:443 advertise sbc01.domain.com:443
listen=udp:1.1.1.1:5060

In order to not break TLS validation (certs) we set the advertise to the FQDN so all headers are set with the FQDN and not the IP address, also notice no [] in the FQDN part of advertise IPv6 line. We do this, because we found that without the advertise, all headers have the IP address, which is also OK, but if the TCP connection breaks and the client reconnects, it will send the connection to the top request-route header, if it's an IP, the TLS validation will beak because the cn= doesn't match, having the FQDN there, the cn= will match and the request will continue.

Example scenario:

• IPv4 call:

Our public domain is sip.domain.com that has SRV records pointing to sbc01.domain.com and sbc02.domain.com. For this example let's stick to sbc01.domain.com.

Kamailio: 1.1.1.1 / sbc01.domain.com
Media server: 2.2.2.2

Client <---TLS 443---> Kamailio <---UDP 5060---> Media server

Example call:

Let's focus on the INVITE that Kamailio sends to the media server (the blue INVITE in the screenshot)

The headers look like this:

INVITE sip:test@2.2.2.2:5060 SIP/2.0
Record-Route: <sip:1.1.1.1;r2=on;lr=on;ftag=eTdR161Ub;did=916.2391;nat=yes>
Record-Route: <sip:sbc01.domain.com:443;transport=tls;r2=on;lr=on;ftag=eTdR161Ub;did=916.2391;nat=yes>
...

Which is correct, if the client has to send a reINVITE, it will do a DNS request to sbc01.domain.com and depending if it has AAAA and A records, and what the client's current transport is (ipv6/ipv4) it will select and use what it needs.

..Now let's say the same scenario, but origin transport is IPv6 this time..

• IPv6 call:

Same scenario as above, same invite, this time the headers look like this:

INVITE sip:test@2.2.2.2:5060 SIP/2.0
Record-Route: <sip:1.1.1.1;r2=on;lr=on;ftag=iMwhZbnTA;did=fda.2803>
Record-Route: <sip:[sbc01.domain.com]:443;transport=tls;r2=on;lr=on;ftag=iMwhZbnTA;did=fda.2803>

(notice the FQDN surrounded by [])

Reproduction

Add the advertise option on a listen= param with transport tls and using an IPv6.

Observe the format of the headers the record_route() function adds to the request.

Possible Solutions

When setting a FQDN instead of an IP address (v4/v6) in the advertise option; never enclose it with [] ? It's a suggestion, maybe what I'm saying is completely nuts.

Additional Information

• Kamailio Version - output of kamailio -v

# kamailio -v
version: kamailio 5.1.4 (x86_64/linux)
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, 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_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, 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 6.3.0

• Operating System:

OS: Debian stretch 9.4

Kernel: Linux kamailio 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux

[joelsdc]

Hi,

I was testing using Linphone SIP library and this is what their logs say:

2018-07-03 16:40:59 [INFO] LinphoneCallStack.void linphone_log_handler():91 - [org.antlr.runtime.MismatchedTokenException]  reason [1876:1: hexpart : ( hexseq | hexseq COLON COLON ( hexseq )? | COLON COLON ( hexseq )? );]
2018-07-03 16:40:59 [INFO] LinphoneCallStack.void linphone_log_handler():91 - [org.antlr.runtime.MismatchedTokenException]  reason [1876:1: hexpart : ( hexseq | hexseq COLON COLON ( hexseq )? | COLON COLON ( hexseq )? );]
2018-07-03 16:40:59 [INFO] LinphoneCallStack.void linphone_log_handler():91 - header_record_route parser error for [Record-Route:<sip:[sbc01.domain.com]:443;transport=tls;r2=on;lr=on;ftag=dBhXLGB0R;did=e36.6871>]

Hope it helps.

[miconda]

Try with master or using the patch referenced above, if still an issue, reopen.

[joelsdc]

Cherry-piked this commit into v5.1.4 and so far I can confirm it's working.

I have deployed the fix to prod, I'll report back in a new ticket if something fails.