### 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 or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1532_______________________________________________
Kamailio (SER) - Development Mailing List
[email protected]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
