Investigate SIP 413 Request Entity Too Large on an IllyVoIP call

If an IllyVoIP-connected phone or PBX reports SIP 413 Request Entity Too Large, begin with the SIP exchange for that attempt. The response means the receiving server rejected a request body that was too large for it to process. It does not identify a universal IllyVoIP size limit or prove which setting caused the oversized request.

This guide is for an administrator who can inspect a short trace from their own phone, PBX or SBC. A web page or API returning HTTP 413 is a different protocol error; do not apply SIP changes to repair an HTTP upload problem.

1. Confirm what actually failed

1. Record the attempt time and timezone, direction, affected IllyVoIP line and the Portal call reference if one exists.
2. Find the response beginning SIP/2.0 413 in the customer-side trace. Match it to the request using its transaction references.
3. Record the request method and the peer that returned the response. Determine whether your PBX received it from the IllyVoIP-facing connection or from another local component.
4. Keep the relevant request, response and nearby transaction together. A screenshot of “413” alone cannot show which message was rejected.

A rejected setup may not produce the same history information as an answered call. Do not manufacture a Portal reference when none is available; use the trace time and owned line to help Support correlate the event.

2. Compare the rejected request with a working attempt

1. Use an existing successful trace from the same setup where available. Keep the comparison narrow: same PBX profile, similar call direction and the configuration versions involved.
2. Compare the request’s body type and size, then inspect whether a recent change added or duplicated body content. Save the unmodified private evidence before redacting it for sharing.
3. Check your PBX or SBC’s own diagnostics and supported configuration documentation. Do not assume that a large list of headers alone proves the particular body-size rejection.
4. If no useful working comparison exists, collect the failed exchange first and ask Support which constraint is implicated before making broad changes.

A useful change log says what changed and when: for example, a new trunk template or an added application feature before the first failures. That is a lead to investigate, not proof of the cause. Avoid deleting security or media settings just to make the message shorter.

3. Make a bounded correction only after identifying the cause

If the customer-side configuration is producing unintended or redundant content, correct that configuration using the PBX vendor’s supported controls. Keep a backup and change one relevant setting at a time. Do not manually edit captured packets and treat their altered size as a production fix.

Changing UDP to TCP or TLS is not, by itself, a fix for a server rejecting the request entity. A temporary rejection may include Retry-After; follow it when present instead of creating a rapid retry loop. A missing header does not justify unlimited repeated calls.

4. Verify the result and preserve a rollback

1. With authorization, make one controlled attempt using the corrected configuration. Normal call charges can apply if it connects.
2. Confirm whether the 413 is gone on the same call path. Then check normal call setup and, if answered, two-way audio. A different error is not full success.
3. Compare the new request with the preserved failure to show what changed.
4. If the change does not address the rejection, restore the known configuration and continue diagnosis instead of stacking unrelated edits.

What to send Support

Provide the line reference, precise time, PBX version, request method, response peer and a short sanitized exchange. Remove authentication material, private contact data and unrelated conversations. Keep SIP transaction references consistent across the redacted messages so they can still be matched. Do not send a full day of traffic or claim a specific maximum message size unless it has been verified for the affected service.

Related guides

• Capture a SIP call trace for IllyVoIP Support with Wireshark
• How to Read and Understand Your VoIP Call Reports (CDR)

Reference

Current instructions and technical reference: RFC 3261: SIP.

Reviewed 12 October 2026 against the current IllyVoIP controls, implementation and applicable references. Available options depend on account permissions and service state.