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

[supreeth herle]

Hello Everyone,

I solved this issue. It was totally unrelated to Kamailio. I solved the
issue by having proper DRB settings in eNB.

Thanks and Regards,
Supreeth

On Thu, 27 Feb 2020 at 14:39, supreeth herle <herlesupreeth at gmail.com>
wrote:

> 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/20200303/6038e0d4/attachment.html>