Handling Large SIP INVITE Packets in UDP

[pavanputhra]

Description

I am trying to send an INVITE request whose size is around 4000 bytes. However, I receive the following error:

{"level":"debug","caller":"transactionLayer","error":"size of packet larger than MTU","req":"INVITE sip:foo@example.com SIP/2.0","time":"2025-03-12T04:47:50Z","message":"Fail to write request on init"}

size of packet larger than MTU. transaction transport error

I am using the following code to forward the SIP request over UDP:

clTx, err := s.client.TransactionRequest(ctx, req, sipgo.ClientRequestAddVia, sipgo.ClientRequestAddRecordRoute)

Question

Is there a way in the sipgo library handle large SIP messages by automatically fragmenting them when using UDP? If not could this feature be implemented?

Note

I am aware that the SIP RFC recommends switching to TCP when a message exceeds the MTU. However, some proxies like Kamailio implement UDP fragmentation in such situations, which is useful when there is no reliable way to determine whether the User Agent supports TCP.

Thanks!

[emiago]

Hi @pavanputhra . To keep it short, I think this will not happen, but as library is flexible, there could be a way that you could override default transport implementation. Of course if you are willing to go this path, we could consider exposing this.

BTW: It is not recommends. -> https://datatracker.ietf.org/doc/html/rfc3261#section-18.1.1
Kamailio can do automatic switch as well.

[pavanputhra]

Hi @emiago,

I understand that the SIP RFC recommends switching to TCP when the message size exceeds the MTU. However, in some practical scenarios, strictly adhering to the RFC may not be feasible.

For example, if a User Agent (UA) is registered using UDP and is behind a NAT, switching to TCP for larger messages becomes problematic. The NAT router might only have an active mapping for UDP (via rport), meaning there is no established path for TCP communication.

Here’s a diagram to illustrate this situation:

   +--------+            +--------+            +------------------+
   |   UA   | <--UDP-->  |  NAT   | <--UDP-->  |  sipgo Proxy/SIP |
   +--------+            +--------+            +------------------+
                           |   ❌   
                           |   (No TCP Mapping to send INVITE to UA)
                           v   
                     TCP Connection Fails

• The UA registers using UDP, creating a NAT binding for UDP.
• When sending a large SIP message, RFC suggests switching to TCP, but the NAT has no TCP mapping.
• As a result, the TCP connection fails, preventing message delivery.

Given this limitation, it make sense to exposing a way to override the default transport implementation.