What does HRESULT 0x80EE001B (RTC_E_SIP_UDP_SIZE_EXCEEDED) mean?

Status / error code:		Category:

Constant name:
Source:		Operating System:
Description: The sip message size is greater than the UDP message size allowed

Previous	Next
RTC_E_SIP_REQUEST_DESTINATION_ADDR_NOT_PRESENT	RTC_E_SIP_SSL_TUNNEL_FAILED

RTC_E_SIP_UDP_SIZE_EXCEEDED

Protocol boundary: `RTC_E_SIP_UDP_SIZE_EXCEEDED`

In the RTC Client API, this result separates one failure or completion path from its neighbors because it denotes the serialized SIP datagram exceeds the size accepted by the RTC UDP transport path.

At the HRESULT layer, this result appears as 0x80EE001B in the RTC interface facility 0xEE; for this HRESULT, preserving the facility and symbol prevents it from being grouped incorrectly with unrelated networking or media errors.

A defensible diagnosis of this result requires you to measure encoded request size and identify large headers, authorization data, routes, or SDP; in the case, the error is about one UDP message; it does not imply the peer rejected the SIP method.

Protocol and object boundary

RTC area	`SIP` message and `SDP` negotiation boundary
Objects to correlate	`SIP` start-line and headers, message body framing, `SDP` session and media sections, offer/answer generation
Condition to prove	the serialized `SIP` datagram exceeds the size accepted by the RTC `UDP` transport path
Safe corrective direction	use a profile-supported connection-oriented transport or reduce optional message size without deleting required data

Two RTC rules frame this result: first, SIP transaction state and media negotiation are separate: a syntactically valid SIP request can still contain absent or unacceptable SDP; second, for this HRESULT, An SDP update must be checked against the previous offer/answer state, not merely parsed as a standalone text document.

How to prove the condition

Start from 0x80EE001B and it, then find the method/event pair that first exposed it.
check whether the failure was local before transmission, produced during RTC state validation, or mapped from a remote response.
the proof step is to measure encoded request size and identify large headers, authorization data, routes, or SDP.
keep the analysis at the right boundary: the error is about one UDP message; it does not imply the peer rejected the SIP method.
after you use a profile-supported connection-oriented transport or reduce optional message size without deleting required data, repeat the smallest reproducer rather than restarting the entire application environment.

A SIP capture without RTC callback state cannot show which local object accepted or rejected the transition; for this HRESULT, an HRESULT-only log has the opposite weakness: it cannot show whether the result was generated before transmission or mapped from the peer.

Nearby failure modes

It is tied to the condition “the serialized SIP datagram exceeds the size accepted by the RTC UDP transport path”; preserve that producing boundary before choosing recovery; for this HRESULT, the neighboring results below require different control-flow decisions.

`RTC_E_SIP_NEED_MORE_DATA`	the receive buffer contains only part of a complete SIP message
`RTC_E_SDP_NO_MEDIA`	the SDP contains no enabled media description usable for the requested RTC session
`RTC_E_SDP_UPDATE_FAILED`	a new SDP description is incompatible with the prior negotiated offer/answer state

Facility equality is not semantic equality; route each contrasted value through its own recovery branch.

Minimum incident record

The evidence set for this HRESULT should begin at the first failing or completing RTC boundary; for this HRESULT, reconnect and teardown events are secondary unless they caused the original result.

Code-specific proof for this HRESULT: measure encoded request size and identify large headers, authorization data, routes, or SDP.
Owning object for this HRESULT: start-line plus header names.
Wire evidence for this HRESULT: Content-Type and Content-Length.
Lifecycle generation for this HRESULT: SDP o= version and c= address.

When recording it, redact credentials, full telephone numbers, private contact lists, and message bodies; for this HRESULT, retain permitted URI domains, header names, byte counts, hashes, transaction identifiers, timestamps, and state transitions.

Correct application response

Resolve it at its producing layer: use a profile-supported connection-oriented transport or reduce optional message size without deleting required data; after it, a separate UI or watchdog retry must wait until that layer reports a final state.

Distinguish local rejection from an operation that may already have reached the server; for this HRESULT, use transaction identifiers and final events before replaying any non-idempotent action.

Example for this HRESULT: A large SDP plus authentication and routing headers no longer fits the RTC UDP limit.

Actions that do not address this condition

An investigation should not do not log credentials or an unredacted SDP body from production calls.
also do not repair malformed signaling by silently deleting unknown headers or media sections.
A wrapper handling it should retain the original HRESULT instead of replacing it with an undifferentiated call failure.

Verification after a fix

A regression test for this HRESULT should reproduce “the serialized SIP datagram exceeds the size accepted by the RTC UDP transport path” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EE001B, the responsible method/event, and the object state after the result; then, for this HRESULT, change only the decisive precondition and verify that the corrected run leaves no stale transaction or RTC object.

Technical references

Microsoft RTC return constants — authoritative context for the boundary.
SIP message and transaction rules — definitions relevant when reproducing it.
SDP syntax — API or protocol rules used to interpret it.
SDP offer/answer — authoritative context for the boundary.

Looking for a different code? Search another status or error code.