[SR-Users] Dynamically change the transport protocol from UDP to TCP to avoid fragmentation

supreeth herle herlesupreeth at gmail.com
Thu Feb 27 14:39:38 CET 2020


Hello Everyone,

I have an IMS setup using Kamailo and is working as expected when the 4G
Core Network and IMS is running in a single VM. However, when running in
two different VMs registration is successful but calling fails. As per the
scripts in kamailio ims example folder for P-CSCF, uac module is used to
generate OPTIONS message to achieve a kind of NATPINGING to UEs.
The ping achieved in this way times out with 408 when IMS and Core Network
is run in different VMs.

I suspect that the increasing packets size could be the issue for UE not
responding to OPTIONS from P-CSCF (I have verified that OPTIONS message
from P-CSCF is reaching the eNB). In this aspect, I would like to switch
the transport protocol to TCP when MTU is greater than 1300 (please guide
me if my thinking of switching to TCP to tackle NAT issue is wrong).

I have explored the following options:

tcp_reuse_port=yes
udp_mtu=1300
udp_mtu_try_proto=TCP

But, when I use these options, any request message which hit 1300 MTU mark
are not sent out at all (in my case it is the NOTIFY request from SCSCF)
and Kamailio has a warning saying that binding to address failed as the
address is already in use.

Following is the small part of the log:

Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19712]: DEBUG:
ims_registrar_scscf [registrar_notify.c:2275]:
notification_event_process(): About to free notification
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
PCSCF MO_reply:
                                                          Destination URI:
<null>
                                                          Request URI:
<null>
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: INFO: rr
[rr_mod.c:515]: pv_get_route_uri_f(): No route header present.
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
Source IP and Port: (10.4.128.21:6060)
                                                          Route-URI:
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
Received IP and Port: (10.4.128.21:5060)
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
Contact header: <sip:scscf.ims.mnc001.mcc001.3gppnetwork.org:6060>
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: ERROR: <script>:
NOTIFY (tel:0198765432100 (172.24.15.30:6060) to tel:0198765432100,
4125089758_4268630712 at 192.168.101.2)
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
Within DLG
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
Within loose route
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
PCSCF MO_indialog:
                                                          Destination URI:
sip:172.24.15.10:5060
                                                          Request URI: sip:
192.168.101.2:5060
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
Source IP and Port: (172.24.15.30:6060)
                                                          Route-URI:
sip:mo at 172.24.15.30;lr=on;ftag=4125089761
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
Received IP and Port: (10.4.128.21:5060)
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: NOTICE: <script>:
Contact header: <sip:scscf.ims.mnc001.mcc001.3gppnetwork.org:6060>
Feb 27 14:31:15 epc-ims /usr/local/sbin/kamailio[19730]: WARNING: <core>
[core/tcp_main.c:1298]: tcp_do_connect(): binding to source address
10.4.128.21:5060 failed: Address already in use [98]


I could be assuming things here about huge packet sizes causing the issue,
if anyone has experienced similar issue in NATed scenario please let me
know some hints or pointer to solve this. Thanks in advance.

Best Regards,
Supreeth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200227/74918df8/attachment.html>


More information about the sr-users mailing list