| Previous | Next |
| RTC_E_STATUS_CLIENT_NOT_FOUND | RTC_E_STATUS_CLIENT_NOT_ACCEPTABLE |
RTC_E_STATUS_CLIENT_METHOD_NOT_ALLOWED
What the RTC value marks: RTC_E_STATUS_CLIENT_METHOD_NOT_ALLOWED
When RTC returns this result, the relevant contract is a peer, proxy, registrar, or gateway returning a specific SIP response to the RTC transaction, and it says that the target resource recognizes SIP but does not allow the requested method.
This result carries 0x80EF0195 in the RTC SIP-status facility carrying status 405; store the result value at the first RTC callback or method boundary, before retry logic replaces it with a broader timeout or connection message.
Start the result investigation by having the trace capture the Allow header, target URI, method, and resource state; for this HRESULT, do not skip the distinction that Method Not Allowed concerns this resource; 501 means the server does not implement the method at all.
Protocol and object boundary
| RTC area | SIP final response boundary |
|---|---|
| Objects to correlate | SIP request method, client transaction, response status, dialog identifiers and method-specific headers |
| Condition to prove | the target resource recognizes SIP but does not allow the requested method |
| Safe corrective direction | select an allowed method or feature path and do not retry the prohibited method unchanged |
The API and protocol context for this HRESULT is not optional: The facility code preserves the SIP status number; diagnosis should start with the method and responding hop rather than treating every value as a local COM failure; the related this result control-flow rule is that Some responses invite a modified request or authenticated retry, while others are terminal for the current target or even global for the addressed user.
Evidence that separates the cause
Build the incident record before automatic recovery runs; the result record must identify one client/profile/session generation and the exact signaling, presence, or media transition in progress.
- Code-specific proof for this HRESULT: capture the Allow header, target URI, method, and resource state.
- Identity and target for this HRESULT: request method and Request-URI.
- State at production for this HRESULT: responding Via hop.
- Timing and ordering for this HRESULT: Call-ID/CSeq/tags.
Sanitize the result evidence before storage: secrets and user content should disappear, while framing, domains, sizes, hashes, timing, and object-state changes remain available for reproduction.
Related RTC results
Use the following contrast when classifying this result: 501 indicates implementation-wide lack of support rather than resource-specific policy; for this HRESULT, similar subsystem names do not imply identical recovery.
RTC_E_STATUS_CLIENT_CONFLICT | the legacy RTC peer reported a conflict with current resource or transaction state |
|---|---|
RTC_E_STATUS_CLIENT_TEMPORARILY_NOT_AVAILABLE | the addressed user or endpoint is temporarily unavailable at all currently known contacts |
RTC_E_STATUS_CLIENT_BAD_EXTENSION | the server requires removal of a SIP extension it does not understand |
Telemetry for this HRESULT should retain these distinctions even when several outcomes share HRESULT severity.
A safe diagnostic sequence
- Locate the earliest it producer and verify that no wrapper replaced a more specific lower-layer value.
- map that producer to the active RTC object and to one SIP, SDP, PINT, presence, media, or profile transition.
- collect enough evidence to capture the Allow header, target URI, method, and resource state.
- test the competing explanation explicitly, because Method Not Allowed concerns this resource; 501 means the server does not implement the method at all.
- perform the narrow correction — select an allowed method or feature path and do not retry the prohibited method unchanged — and validate both protocol completion and object cleanup.
Use RTC event state to interpret the protocol trace for this HRESULT, and use the trace to verify what left or reached the host; for this HRESULT, this two-sided correlation identifies the producing layer.
How to handle the result
The corrective direction for this HRESULT is to select an allowed method or feature path and do not retry the prohibited method unchanged; for this HRESULT, cancellation, cleanup, and retry should remain with the component that owns the failed transition.
Do not turn it into an immediate unconditional retry; for this HRESULT, first determine whether the peer could have accepted the prior request and whether RTC still owns a live transaction.
Example for this HRESULT: A presence resource allows SUBSCRIBE but rejects an attempted MESSAGE method and lists supported methods.
Actions that do not address this condition
- An investigation should not do not retry every 4xx or 5xx response with the identical request.
- also do not show a reason phrase as trusted server identity or authorization evidence.
- Do not translate it into a broad “connection failed” label before preserving the RTC symbol and producing phase.
Verification after a fix
A regression test for this HRESULT should reproduce “the target resource recognizes SIP but does not allow the requested method” with the smallest profile, message, session, presence, media, or PINT fixture; for this HRESULT, assert 0x80EF0195, 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 response semantics — definitions relevant when reproducing it.
Looking for a different code? Search another status or error code.