How to avoid splitting SIP messages into multiple segments when traces are enabled

We’ve noticed that when SIP traces are enabled, the SIP messages sent are split into segments at the network level. This is not the case with traces disabled. We also see that the segments are very small and split into semantically meaningful parts. This is causing issues with some SIP providers such as Genesys Cloud - their security mechanism does not accept packets split in more than 4 segments and rejects the traffic. Is there a way to disable this splitting?

What are you talking about exactly? Sounds like you’re stating that the UDP packets go over the MTU and are fragmented. If Genesys can’t handle fragmented packets its their problem, a possible solution is to use TCP for your transport.


I’m referring to SIP traffic over TLS which is using TCP. The fragments are very small, well below the MTU size.

MTU and fragments mean nothing over TCP/TLS, what is the core issue you’re trying to solve because what you’ve outlined isn’t a real issue.


This is what Genesys communicated to us:

I discussed this with our devs and they pointed out that our SIP servers will terminate a TLS session if a message is broken up into more that 4 fragments for security and performance reasons (in the case of the 100 Trying there are 4 TCP fragments but 6 TLS message fragments - if I understand correctly exceeding 4 for either will cause us to close the session). I think the next step for you is to find out why FreeSwitch is doing that excessive fragmentation on those small messages.

That’s a Genesis thing, not an FreeSWITCH thing to fix. What part of the RFC states this is an ok behavior on their part?