SIP Header Breakdown Tool

The server is not rejecting the call — it is issuing a challenge. The UAC must extract the WWW-Authenticate header from the 401, compute a digest response using the correct credentials, and resend the request with an Authorization header. If you see a 401 followed immediately by a 403, the credentials are wrong or the realm does not match what the server expects.

Hard rejection. The server understood the request and explicitly denied it. In Direct Routing this almost always means one of three things: the SBC IP is not in the Microsoft allowed list, the SIP trunk credentials failed digest authentication, or the called number is not assigned to a user with a valid Phone System license. Check IP ACLs on the SBC and verify the Teams admin center trunk configuration before touching anything else.

Same mechanism as 401 but issued by a proxy rather than the endpoint. The response will contain a Proxy-Authenticate header. The UAC must resend with Proxy-Authorization. Common in hosted SBC deployments where the carrier SBC sits in front of the Teams infrastructure and issues its own auth challenge before passing traffic upstream.

The endpoint exists but cannot be reached right now. In practice this usually means the device is not registered, the registration has expired, or the SBC cannot reach the Teams infrastructure. Check the REGISTER flow in your SBC logs — if there is no active registration binding, no INVITE will succeed.

Media negotiation failed. The remote device could not find a compatible codec, media type, or transport in the SDP offer. Paste the INVITE into the tool above and look at the codec flags — compare what was offered against what the remote end supports. In Webex Calling deployments this is frequently caused by SRTP/RTP mismatch: one side is sending encrypted media, the other expects plain RTP. Check m=audio transport line for RTP/AVP vs RTP/SAVP.

The server cannot process the request right now. In Direct Routing this appears when the Microsoft SIP proxy cannot be reached, when the SBC has exhausted its licensed session capacity, or when a downstream PSTN gateway is unreachable. Check SBC health dashboards first — session counts, CPU, and memory. If the SBC is healthy, check connectivity to the Microsoft SIP proxy FQDNs on port 5061 from the SBC itself.

Tracks every device the message has passed through. Each proxy adds its own Via entry. The branch parameter must start with z9hG4bK per RFC 3261 — if it does not, the sending device is not RFC-compliant and interop issues are likely. A received= parameter added by the server means NAT was detected between the sending device and the proxy.

From identifies the originator. To identifies the intended recipient. Both carry a tag parameter — the From tag is set by the UAC on the initial request, the To tag is added by the UAS in its response. Together with Call-ID, these three values uniquely identify a dialog. A missing From tag on a request is unusual and may indicate a malformed message from a non-standard device.

Every message in the same call — INVITE, 200 OK, ACK, BYE, re-INVITEs — shares the same Call-ID. This is your primary search key when correlating a call across SBC logs, proxy logs, and Microsoft Call Quality Dashboard. Copy it out of any message and use it to filter logs on every device in the path simultaneously.

Contains a sequence number and the method name. The method in CSeq must match the request method — a mismatch indicates a malformed message. CSeq numbers increment with each new request in a dialog, which lets you reconstruct the order of events from out-of-sequence log entries. A re-INVITE for hold/resume will have a higher CSeq than the original INVITE.

Provides the SIP URI where this device can be reached directly for subsequent requests in the dialog, bypassing the proxy. In NAT environments the Contact address is frequently the device's private IP — if the SBC is not correctly rewriting Contact headers to its public FQDN, in-dialog requests like re-INVITEs and BYEs will fail to route. This is one of the most common SBC misconfiguration patterns.

Port zero on a media line means the stream is being rejected or put on hold. If this appears in an INVITE rather than a re-INVITE, media negotiation has already failed before the call connected.

Connection address of 0.0.0.0 is a hold indicator. Media will not flow until a re-INVITE with a real IP address is sent. Expected during hold/resume sequences — unexpected in an initial INVITE.

Asymmetric media direction. If a=recvonly appears where you expect a=sendrecv, this is the direct cause of one-way audio. Often set incorrectly by hold logic or by misconfigured SBC media handling policies.

Transport protocol mismatch. RTP/AVP is unencrypted. RTP/SAVP is SRTP (encrypted). If one side offers SAVP and the other expects AVP, the result is a 488 and no media. Common in Webex Calling deployments where SRTP is mandatory.

If the INVITE offers G.711 only and the remote device requires G.729 or Opus, there is no intersection and the call fails with 488. Check the a=rtpmap lines in the INVITE SDP against the codec list configured on the receiving device or SBC.

If the SDP connection address is a RFC 1918 private IP and the call crosses a NAT boundary, the remote device will attempt to send RTP to an unreachable address. Call connects (SIP succeeds) but no audio flows. SBC must rewrite the c= line to its public IP.