Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog
Extracted elements (26)
A forking proxy receiving a non-2xx final response does not always immediately forward it upstream; instead it waits to select the 'best' final response. This leaves upstream entities—including the UAC—holding resources for early dialogs that have already been terminated at the UAS, wasting capacity that could be reused for other dialogs. The 199 response code was introduced to close this gap by proactively informing upstream entities of individual early-dialog termination before any final response is sent.
The 199 response is explicitly an optimization, not a reliability mechanism. Because it is normally sent unreliably (and cannot be sent reliably when generated by a proxy), some or all 199 responses may be lost. Applications MUST ensure an acceptable user experience if every 199 response is lost.
The UAS normally should not send a 199 response when forking proxies are present, because proxies are better positioned to detect which early dialogs were terminated by a received non-2xx response. A UAS may deviate from this default if it knows that intermediate proxies lack 199 support, or if its deployment environment mandates sending 199 before non-2xx final responses.
A 199 response does not replace a final response; RFC 3261 rules governing when a final response is sent remain unchanged. A proxy MUST continue to forward requests according to RFC 3261 even if it has knowledge that the early dialog has been terminated.
A forking proxy can detect additional downstream forking by storing the top Via branch parameter value from each response that creates an early dialog. Identical top Via branch values across multiple early dialogs indicate further forking downstream, and a non-2xx response on one such dialog also terminates all others sharing the same top Via branch value.
A 199 response SHOULD NOT contain an SDP offer/answer message body unless required by RFC 3264 rules. If an INVITE contains no SDP offer and the 199 response is the first reliably sent response, the 199 is required to contain an SDP offer; in that case the UAS SHOULD send it unreliably, or include an SDP offer with no 'm=' lines.
A forking proxy-generated 199 response MUST contain a To header field tag identifying the terminated early dialog and MUST insert a Reason header field with the SIP response code that triggered the 199. The proxy MUST NOT insert a '199' option-tag in Supported, Require, or Proxy-Require of the 199 response.
A forking proxy MUST generate and send a 199 response upstream for each terminated early dialog when: it does not intend to forward the triggering non-2xx final response immediately; the UAC indicated '199' support; the UAC has not required reliable provisional responses ('100rel' in Require/Proxy-Require); the proxy has not already forwarded a 199 for that dialog; and no final response has already been sent for any early dialog.
A forking proxy that generates a 199 response SHOULD NOT include a Contact header field or a Record-Route header field in the 199 response.
A forking proxy that supports 199 MUST track early dialogs to know when to generate 199, and MUST track which dialogs have already received forwarded 199 responses to avoid duplicate generation.
A UAC SHOULD NOT insert a '199' option-tag in the Require or Proxy-Require header field of the request, since doing so would cause unnecessary session establishment failures in many cases.
A UAC that is willing to receive 199 responses MUST insert a '199' option-tag in the Supported header field of the initial dialog initiation request.
A UAS SHOULD send a 199 response unreliably, unless the '100rel' option-tag is present in the Require header field of the associated request, since 199 is informational only.
For backward compatibility, the sender of a 199 response MUST be prepared to receive SIP requests and responses on the dialog for which the 199 was sent. A UAC that receives a 199 MUST NOT send any further requests on that dialog except requests acknowledging reliable responses.
If a UAC receives an unreliably sent 199 response for a dialog not yet established (e.g., 199 arrives before the 18x that would create the dialog), it SHALL discard the 199 response. If the 199 was sent reliably on a non-established dialog, the UAC MUST acknowledge it per RFC 3262.
If multiple dialog usages exist within an early dialog and it is not clear which usage the 199 response terminates, SIP entities that keep dialog state SHALL NOT release resources associated with the early dialog upon receiving the 199 response.
If the Require header of an initial dialog initiation request contains a '100rel' option-tag, a proxy MUST NOT generate and send 199 responses associated with that request, because a proxy is not allowed to send 199 responses reliably.
If the Supported header of an initial dialog initiation request does not contain the '199' option-tag, the UAS MUST NOT send a 199 response on any early dialog associated with the request.
It is RECOMMENDED that a UAC not insert a '100rel' option-tag in the Require header field when it also indicates support for 199 responses, because proxies are not allowed to generate and send 199 responses when the UAC has required reliable provisional responses.
Once a UAC has received and accepted a 199 response, it MUST NOT send any media associated with the terminated early dialog, and MUST NOT process any received media associated with that dialog.
When a UAS generates a 199 response it MUST contain a To header field tag parameter (to identify the terminated early dialog) and MUST include a Reason header field with a response code describing why the early dialog was terminated. The UAS MUST NOT insert a '199' option-tag in the Supported, Require, or Proxy-Require field of the 199 response itself.
199 Early Dialog Terminated is a new SIP provisional response code (1xx class) that a forking proxy or UAS sends to indicate to upstream SIP entities that a specific early dialog has been terminated before any final response is forwarded. It carries a To header tag identifying the terminated dialog and a Reason header describing why it was terminated.
A new SIP option-tag '199' is defined for use in the Supported header of initial dialog initiation requests to indicate that the UAC supports and is willing to receive 199 responses. When present in Require or Proxy-Require it mandates that UAS or proxies support the 199 response code (but does not require them to actually send it).
IANA is requested to register SIP option-tag '199' indicating support for the 199 Early Dialog Terminated provisional response code, for use in Supported, Require, or Proxy-Require header fields per RFC 3261.
IANA is requested to register SIP response code 199 with the default reason phrase 'Early Dialog Terminated' per the procedures of RFC 3261.
The 199 response may be attractive for attacks targeting specific early dialogs: a man-in-the-middle could forge a 199 response to cause the UAC and stateful intermediates to prematurely release resources for a dialog, while the UAS remains unaware. SIP security mechanisms such as hop-to-hop TLS are recommended to mitigate or eliminate this risk.