Description

Kamailio is using the wrong source port when relaying INVITE packets with t_relay(). Another interesting thing is that while doing this, Kamailio reports to Homer via HEPv2 that it sent the packet from port 4242, but a tcpdump on the server shows this to be false so maybe homer was just looking at the R-URI port?
There is a somewhat random element to this, so it is very difficult to reproduce. I will provide the scenario which led to this problem.

Reproduction

This is the code block which is responsible for relaying INVITEs to phone from our PBX servers, it is also the only instance of port 5062 being inserted into a SIP message.

if(is_method("INVITE"))
{
	if(lookup("location", "sip:$rU@location"))
	{
		remove_hf("Contact");
		append_hf("Contact: <sip:$sel(cfg_get.global.publicIP):5062>\r\n"); //A vendor's SIPIS server doesn't work on port 4242, does changing this port break SIP compliance?
		rtpproxy_manage("cow");
		t_relay();
		exit;
	}
}

• Kamailio listens for UDP+TCP on ports 5060,5062, and 4242.
• Phone A registers to tcp:KamailioIP:4242 from tcp:CustomerIP:10042
• Phone B registers to tcp:KamailioIP:4242 from tcp:CustomerIP:11042
• These phones have been re-registering from and to the same ports for a long time without problems with the same REGISTER callID (same transaction so nothing about the connection has changed).
• At this point we have TCP connections tcp:CustomerIP:10042 -> tcp:KamailioIP:4242 and tcp:CustomerIP:11042 -> tcp:KamailioIP:4242
• Kamailio sends INVITEs from tcp:KamailioIP:4242 to the address of the registered phone with a contact header that tells the phones to send responses to tcp:KamailioIP:5062 (as seen in the above code block). This causes a new TCP connection to be made from the customer's router to Kamailio, just for this transaction.
• All is well until phone A sends a response and the customer's router, by pure chance, decides to use port 11042 for the new TCP connection. tcp:CustomerIP:11042 -> tcp:KamailioIP:5062
• From this point on Kamailio begins to route INVITEs, that were meant for phone B, to phone A using this TCP connection tcp:CustomerIP:11042 -> tcp:KamailioIP:5062 (source port 5062!) rather than the connection that phone B is actually registered to tcp:CustomerIP:11042 -> tcp:KamailioIP:4242.
• The customer's router sends packets from this TCP socket to phone A because the connection identified by the Kamailio source port had been created by phone A.
• Kamailio is still routing other types of packets to phone B from port 4242 like NOTIFY in response to a subscription and OPTIONs keep alives, but INVITEs (which are an entirely new SIP transaction) are being sent from the wrong source port.

Possible Solutions Problems

I have the default tcp_accept_aliases=0, so ;alias in a Via header is not a problem. We are also not using force_send_socket.
I've tried to figure out how Kamailio works, and I am wondering if this function might be adding the new TCP connection from phone A to port 5062 as an alias of the already existing TCP connection from phone B to port 4242.
https://github.com/kamailio/kamailio/blob/cb7810c939da9c8f4385b530539487528ac8705d/src/core/tcp_main.c#L1287-L1300

I also found these comments interesting.
https://github.com/kamailio/kamailio/blob/52111974b4571e0562e8e731df80f48dbc504915/src/core/forward.c#L288-L290
https://github.com/kamailio/kamailio/blob/52111974b4571e0562e8e731df80f48dbc504915/src/core/forward.c#L76-L81

Additional Information

• Kamailio Version - output of kamailio -v

version: kamailio 5.0.5 (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 on 04:38:13 Feb  2 2018 with gcc 4.8.5

• Operating System:

Linux dallas-sip1-int 3.10.0-514.16.1.el7.x86_64 #1 SMP Wed Apr 12 15:04:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.