[sr-dev] [kamailio/kamailio] t_relay() sending packets from the wrong TCP socket (#1532)

[Jared Hull]

### 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 at 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 or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1532
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20180515/32625352/attachment-0001.html>