SIP works for small messages but a large UDP request fails

Prove that message size is the differentiator

Capture one failing transaction and a closely matched successful control with the same source, destination, address family, route, account and method where possible. Preserve timestamp, Call-ID, branch, CSeq, selected transport, complete byte length before IP fragmentation, first response or timeout and the device that produced the final result.

A larger INVITE can contain more SDP, identity, routing or feature headers, but size correlation is not proof of fragmentation. First determine whether the sender rejected the message, selected another transport, emitted UDP fragments, received an ICMP signal, reached the next hop or timed out after an intermediary silently dropped it.

Apply the SIP request-size transport rule at the sender

RFC 3261 says that a request within 200 bytes of the path MTU, or larger than 1300 bytes when the path MTU is unknown, must use a congestion-controlled transport such as TCP. It also requires a SIP server that listens for UDP on an address and port to listen for TCP there because a message may need TCP when it is too large.

Record the actual request size, known path MTU, selected URI and DNS result, transport parameter, loaded endpoint or proxy policy, available local transport and remote listener. The rule concerns requests. A large UDP response follows the transaction's Via and transport path and cannot be repaired by assuming the receiver will start a different transaction over TCP.

Follow every fragment and the effective path MTU

RFC 8085 explains that loss of one fragment loses the entire reassembled packet and that some NATs and firewalls drop fragments. Capture on both sides of each suspected boundary when authorized: sender interface, before and after VPN or tunnel encapsulation, firewall or SBC edge and receiver interface. Record IP version, packet identifier, fragment offset, more-fragments state, total length and whether reassembly completed.

Keep interface MTU, discovered path MTU and effective payload after VLAN, VPN or other encapsulation separate. A successful ping at one size or a generic interface MTU does not prove that a fragmented SIP datagram traversed the same path. Do not enable broad fragment acceptance until the drop owner and security policy are known.

Verify the selected Asterisk PJSIP transport

Asterisk documents UDP, TCP and TLS transport objects and notes that an endpoint without an explicit transport can use the first compatible configured transport. Its transport-selection guide says a large message can switch from UDP to TCP when the system option permits it, and that sending fails if a TCP transport is absent or the remote side does not listen on TCP.

Preserve the running Asterisk version, loaded system setting, endpoint or registration transport, target URI, DNS result, existing connection and exact send warning. A configured TCP object, an open local listener and a remote TCP service are separate states. TLS adds hostname, trust and policy checks; it is not a transparent synonym for TCP.

Correct the demonstrated boundary and retest both directions

Correct only the proven owner: sender transport selection, provider-supported URI or proxy profile, missing local TCP or TLS transport, remote listener, path MTU, tunnel overhead, fragment handling or an intermediary limit. Apply Asterisk transport changes through the supported configuration owner and restart boundary when required. Do not shorten SDP, strip identity headers, disable certificate validation or relax firewall policy merely to make one request smaller.

Repeat the failing transaction, the small control, an inbound case where required and a normal established call. Confirm the chosen transport, complete request and response, dialog establishment, both media directions and hangup. No endpoint, path, fragment, transport, availability, compatibility or call was tested for this guide.

Use the SIP MESSAGE-specific size boundary

For Asterisk out-of-dialog text, continue with the MessageSend diagnostic. RFC 3428 applies a 1300-byte request limit unless its explicit safe-path exception is established; measure the complete request, not only the body.