Hi Rajneesh, David,
we had a very similar issue in production, but in our case it was related
to large query replies from RTPengine.
The problem was really caused by the size of the UDP packets. Once the NG
reply became too large and exceeded what could safely pass through the
network path, especially around jumbo/IP frame limits and fragmentation,
the packet simply did not arrive reliably at Kamailio.
We switched the Kamailio RTPengine control channel from UDP to WebSocket,
and this solved the issue for us.
Kamailio can use RTPengine over WS as a WebSocket client. A minimal example
is:
modparam("rtpengine", "rtpengine_sock", "ws://127.0.0.1:9091")
In our production setup we use DB-based RTPengine node configuration with
multiple RTPengine instances, but the important part is that the node URI
uses the ws:// scheme instead of udp:.
On the RTPengine side, the corresponding WS NG listener needs to be enabled.
We currently use this setup in production on several clusters at Daktela,
and it works well for us.
So I would not expect tcp: to work directly in rtpengine_sock, but WS/WSS
is a practical alternative when UDP NG replies become too large or
unreliable.
Regards,
Michal Hajek
so 9. 5. 2026 v 9:09 odesílatel Sergey Safarov via sr-users <
[email protected]> napsal:
> No I do not have used was transport on prod servers.
> Currently on servers used udp6.
>
>
> On Sat, May 9, 2026, 7:36 AM Rajneesh Soni <[email protected]> wrote:
>
>> Hi Sergey,
>>
>> Do you have experience running the "WS" transport in production?
>>
>> I found a few mailing list threads mentioning issues with hung WebSocket
>> connections, and that UDP is generally the recommended transport. I wanted
>> to understand how reliable WS has been in real deployments.
>>
>> Regards
>> Rajneesh
>>
>>
>>
>> On Sat, May 9, 2026 at 9:39 AM Sergey Safarov via sr-users <
>> [email protected]> wrote:
>>
>>> Here is list supported transports
>>>
>>> https://github.com/kamailio/kamailio/blob/master/src/modules/rtpengine/rtpengine.c#L1331-L1343
>>>
>>> For your work case "ws" transport.
>>>
>>> On Sat, May 9, 2026 at 4:20 AM David Escartin Almudevar via sr-users <
>>> [email protected]> wrote:
>>>
>>>> Hi,
>>>>
>>>> We are investigating intermittent RTPengine NG control timeouts in a
>>>> production setup and we would like to know if there is any supported way in
>>>> Kamailio 6.0 to use TCP for the NG control channel towards RTPengine.
>>>>
>>>> Environment:
>>>>
>>>> * Kamailio 6.0.x
>>>> * RTPengine 12.5.1.x
>>>> * NG control currently over UDP (`udp:IP:7772`)
>>>>
>>>> Problem observed:
>>>> Under real traffic load we occasionally see:
>>>>
>>>> ```text
>>>> ERROR: rtpengine [rtpengine.c:4042]: send_rtpp_command():
>>>> timeout waiting reply for command "offer" from RTPEngine <udp:
>>>> 192.168.9.70:7772>
>>>>
>>>> ERROR: rtpengine [rtpengine.c:4042]: send_rtpp_command():
>>>> timeout waiting reply for command "delete" from RTPEngine <udp:
>>>> 192.168.9.70:7772>
>>>> ```
>>>>
>>>> We also observed:
>>>>
>>>> * Large NG replies from RTPengine (~7-9 KB UDP payloads)
>>>> * IP fragmentation on the NG control traffic
>>>> * `UdpRcvbufErrors` and `IpReasmFails` counters increasing on the
>>>> Kamailio host
>>>> * `Recv-Q` accumulating bytes on the UDP sockets between Kamailio and
>>>> RTPengine
>>>>
>>>> We suspect the issue is related to fragmented UDP NG messages under
>>>> load.
>>>>
>>>> We tried enabling TCP NG listener on RTPengine:
>>>>
>>>> ```
>>>> --listen-tcp-ng=IP:PORT
>>>> ```
>>>>
>>>> and configuring Kamailio with:
>>>>
>>>> ```
>>>> modparam("rtpengine", "rtpengine_sock", "tcp:44.228.222.190:22222")
>>>> ```
>>>>
>>>> but Kamailio logs:
>>>>
>>>> ```
>>>> Sep 12 08:01:03 ip-10-100-10-19
>>>> /usr/local/kamailio/sbin/kamailio[4602]: WARNING: rtpengine
>>>> [rtpengine.c:1002]: add_rtpengine_socks(): Node address must start with
>>>> 'udp:' or 'udp6:' or 'unix:'. Ignore 'tcp:44.228.222.190:22222'.
>>>> ```
>>>>
>>>> Questions:
>>>>
>>>> 1. Is TCP transport for RTPengine NG control supported in any Kamailio
>>>> 6.0 version? In that case, how can it be configured?
>>>> 2. Are there any recommended practices for large NG replies under high
>>>> load?
>>>>
>>>> Any guidance or experience would be appreciated.
>>>>
>>>> Thanks a lot and regards
>>>> david escartin
>>>> __________________________________________________________
>>>> Kamailio - Users Mailing List - Non Commercial Discussions --
>>>> [email protected]
>>>> To unsubscribe send an email to [email protected]
>>>> Important: keep the mailing list in the recipients, do not reply only
>>>> to the sender!
>>>>
>>> __________________________________________________________
>>> Kamailio - Users Mailing List - Non Commercial Discussions --
>>> [email protected]
>>> To unsubscribe send an email to [email protected]
>>> Important: keep the mailing list in the recipients, do not reply only to
>>> the sender!
>>>
>> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions --
> [email protected]
> To unsubscribe send an email to [email protected]
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
>
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
[email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
