One document matched: draft-ietf-sipcore-199-03.xml

<?xml version="1.0" encoding="iso-8859-1"?>
<!-- comment -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[]>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="trust200902" category="std" docName="draft-ietf-sipcore-199-03.txt" obsoletes="" updates="3262" submissionType="IETF" xml:lang="en">
  <front>
    <title abbrev="199">
		Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog
	</title>
    <author initials="C.H." surname="Holmberg" fullname="Christer Holmberg">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>Hirsalantie 11</street>
          <code>02420</code>
          <city>Jorvas</city>
          <country>Finland</country>
        </postal>
        <email>christer.holmberg@ericsson.com</email>
      </address>
    </author>
    <date year="2010" />
    <area>Transport</area>
    <workgroup>SIPCORE Working Group</workgroup>
    <keyword>SIP</keyword>
    <keyword>199</keyword>
    <keyword>Response code</keyword>
    <keyword>Early dialog</keyword>
    <keyword>Forking</keyword>
    <keyword>Provisional response</keyword>
	<keyword>RFC 3262</keyword>	
    <abstract>
		<t>
			This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, 
			that a SIP forking proxy and a User Agent Server (UAS) can use to indicate towards upstream SIP entities (including the
			User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP
			entities. In addition, this specification updates section 4 of RFC 3262.
		</t>	
    </abstract>
  </front>
  <middle>
    <section title="Introduction" toc="default">
		<t>
			As defined in RFC 3261 <xref target="RFC3261" pageno="false" format="default" />, a Session Initiation 
			Protocol (SIP) early dialog is created when a non-100 provisional response is sent to the initial dialog 
			initiation request (e.g. INVITE, outside an existing dialog). The dialog is considered to be in early state 
			until a final response is sent.
		</t>		
		<t>
			When a proxy receives an initial dialog initiation request, it can forward the request towards multiple remote 
			destinations. When the proxy does that, it performs forking <xref target="RFC3261" pageno="false" format="default" />.
		</t>
		<t>
			When a forking proxy receives a non-100 provisional response, or a 2xx final response, it forwards
			the response upstream towards the sender of the associated request. After a forking proxy has forwarded
			a 2xx final response, it normally generates and sends CANCEL requests downstream towards all remote 
			destinations where it previously forked the request associated with the 2xx final response and from which 
			it has yet not received a final response. The CANCEL requests are sent in order to terminate any outstanding
			early dialogs associated with the request. 
		</t>
		<t>
			Upstream SIP entities might receive multiple 2xx final responses. When a SIP entity receives the first 
			2xx final response, and it does not intend to accept any subsequent 2xx final response, it will automatically 
			terminate any other outstanding early dialog associated with the request. If the SIP entity receives a subsequent
			2xx final response, it will normally generate and send an ACK request, followed with a BYE request, using the 
			dialog identifier retrieved from the 2xx final response.
		</t>		
		<t>
			NOTE: A User Agent Client (UAC) can use the Request-Disposition header field <xref target="RFC3841" pageno="false" 
			format="default" /> to request that proxies do not generate and send CANCEL requests downstream once they 
			have received the first 2xx final response.
		</t>
		<t>
			When a forking proxy receives a non-2xx final response, it does not always immediately forward the response
			upstream towards the sender of the associated request. Instead, the proxy "stores" the response and waits for
			subsequent final responses from other remote destinations where the associated request was forked. At some point the proxy
			uses a specified mechanism to determine the "best" final response code, and forwards a final response using that response
			code upstream towards the sender of the associated request. When an upstream SIP entity receives the non-2xx final response
			it will release resources associated with the session. The UAC will terminate, or retry, the session setup.
		</t>				
		<t>
			Since the forking proxy does not always immediately forward non-2xx final responses, upstream SIP entities 
			(including the UAC that initiated the request) are not immediately informed that an early dialog has been terminated,
			and will therefor maintain resources associated with the early dialog reserved until a final response is sent by the
			proxy, even if the early dialog has already been terminated. A SIP entity could use the resources for other things, 
			e.g. to accept subsequent early dialogs that it otherwise would reject.
		</t>
		<t>
			This specification defines a new SIP response code, 199 Early Dialog Terminated. A forking proxy can send a 199 
			provisional response to inform upstream SIP entities that an early dialog has been terminated. A UAS can send a 199 
			response code, prior to sending a non-2xx final response, for the same purpose. SIP entities that receive the 199 response 
			can use it to release resources associated with the terminated early dialog. In addition, SIP entities might also use 
			the 199 provisional response to make policy related decisions related to early dialogs.
		</t>			
		<t>
			This specification updates RFC 3262 <xref target="RFC3841" pageno="false" format="default" />, by mandating a UAC to 
			be prepared to receive unreliably sent provisional responses even if it has required provisional responses to be sent 
			reliably.	
		</t>
    </section>
		
    <section title="Terminology" toc="default">
		<t>
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
			"MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 
			<xref target="RFC2119" pageno="false" format="default"/>.
		</t>
	</section>

	<section title="Applicability and Limitation" anchor="sec-app" toc="default">
		<t>
			The 199 response code is an optimization, and it only optimizes how quickly receipients might be informed about 
			terminated early dialogs. The achieved optimization is limited. Since the response is normally not sent reliably by an UAS, 
			and can not be sent reliably when generated and sent by a proxy, it is possible that some or all of the 199 responses get 
			lost before they reach the receipients. In such cases, recipients will behave the same as if the 199 response code 
			were not used at all. 
		</t>	
		<t>						
			One example for which a UA could use the 199 response, is that when it receives a 199 response it releases resources associated 
			with the terminated early dialog. It could also use the 199 response to make policy related decisions related to early 
			dialogs. For example, if a UAC is playing media associated with an early dialog, and the it receives a 199 response indicating 
			the early dialog has been terminated, it could start playing media associated with a different early dialog.
		</t> 
		<t>	
			Applications designers utilizing the 199 response code MUST ensure that the application's user experience is 
			acceptable if all 199 responses are lost, and not delivered to the receipients.
		</t>
	</section>
	
    <section title="User Agent Client behavior" anchor="sec-client" toc="default">			
		<t>
			When a UAC sends an initial request, and if it is willing to receive 199 responses, it MUST insert the
			"199" option-tag in the Supported header field. The option-tag indicates that the UAC supports 199
			responses. The UAC SHOULD NOT insert the "199" option-tag in the Require or the Proxy-Require 
			header fields, since in many cases it would result in unnecessary session establishment failures.
		</t>
		<t>
			When a UAC receives a 199 response it might release resources associated with the terminated early 
			dialog. It might also use the 199 response to make policy related decisions related to 
			early dialogs.
		</t>
		<t>
			NOTE: The 199 response indicates that the early dialog has been terminated, so there is no need
			for the UAC to send a BYE request in order to terminate the early dialog when it receives the 199 response.
		</t>
		<t>
			NOTE: The 199 response does not affect other early dialogs associated with the session establishment. For 
			those the normal SIP rules, regarding transaction timeout etc, still apply.
		</t>
		<t>
			Once the UAC has received and accepted the 199 provisional response, it MUST NOT send or process any 
			media associated with the early dialog that was terminated.
		</t>
		<t>
			If multiple usages <xref target="RFC5057" pageno="false" format="default" /> are used within an early dialog,
			and it is not clear which dialog usage the 199 response terminates, SIP entities that keep dialog state SHALL NOT
			release resources associated with the early dialog when they receive the 199 response.
		</t>
		<t>
			If a SIP entity receives an unreliable 199 response on a dialog which has not previously been established 
			(this can happen if a 199 response reaches the client before the 18x response that would establish the early 
			dialog) it SHALL discard the 199 responses. If a SIP entity receives a reliable 199 response on a dialog which 
			has not previously been created the UAC MUST acknowledge the 199 response, as described in RFC 3262.
		</t>
		<t>
			If the UAC has received a 199 response for all early dialogs, and no early dialog associatd session establisment 
			remains, the UAC maintains the "Procedding" state <xref target="RFC3261" pageno="false" format="default" /> and
		    waits for possible subsequent early dialogs to be established, and eventually for a final response to be received.
		</t>
    </section>
	
    <section title="User Agent Server behavior" anchor="sec-server" toc="default">
		<t>
			If a UAS receives an initial request that contains an "199" option-tag, it SHOULD NOT send a 199 response 
			on an early dialog on which it intends to send a final response, unless it e.g. has been configured to do so 
			due to lack of 199 support by forking proxies or other intermediate SIP entities.
		</t>
		<t>
			NOTE: If the UAS has created multiple early dialogs (the UAS is acting similar to a forking proxy), it 
			does not always intend to send a final response for all of those dialogs.
		</t>
		<t>
			When a UAS generates a 199 response, the response MUST contain a To header field tag parameter, in order 
			to identify the early dialog that has been terminated. The UAS MUST also insert a Reason header field 
			<xref target="RFC3326" pageno="false" format="default" /> that contains a response code which describes 
			the reason why the early dialog was terminated.
		</t>
		<t>
			If the UAS intends to send 199 responses, and if it supports the procedures defined in RFC 3840
			<xref target="RFC3840" pageno="false" format="default" />, it MAY during the registration 
			procedure use the sip.extensions feature tag <xref target="RFC3840" pageno="false"
			format="default" /> to indicate support of the 199 response code.
		</t>
		<t>
			A 199 response SHOULD NOT contain an SDP offer/answer message body, unless required by the
			rules in RFC 3264 <xref target="RFC3264" pageno="false" format="default" />.
		</t>
		<t>
			According to RFC 3264, if the INVITE request does not contain an SDP offer, and the 199 response is the 
			first reliably sent response, the 199 response is required to contain an SDP offer. In this case the 
			UAS SHOULD send the 199 response unreliably, or include an SDP offer with no m- lines in the reliable 
			199 response.
		</t>
		<t>
			Since the provisional response is only used for information purpose, the UAS SHOULD send it unreliably, 
			unless the "100rel" option-tag <xref target="RFC3262" pageno="false" format="default" /> is present in 
			the Require header field of the associated request.
		</t>
		<t>
			Once the UAS has sent a 199 response, it MUST NOT send or process any media associated with the terminated 
			early dialog.
		</t>
    </section>
	
    <section title="Proxy behavior" anchor="sec-proxy" toc="default">
		<t>
			When a proxy receives a 199 response, it MUST process the response as any other non-100 provisional
			responses. The proxy will forward the response upstream towards the sender of the associated request.
			The proxy MAY release resources it has reserved associated with the early dialog that is terminated. 
			If a proxy receives a 199 response out of dialog, it processes it as other non-100 provisional
			responses received out of dialog.
		</t>
		<t>
			When a forking proxy receives a non-2xx final response that it recognizes as terminating one or more 
			early dialogs, it MUST generate and send a 199 response upstream for each of the terminated early 
			dialogs that satisfy each of the following conditions:
		</t>
		<t>
			- the forking proxy does not intend to forward the final response immediately (in accordance with rules
			for a forking proxy)
		</t>
		<t> 
			- the UAC has indicated support (using the "199" option-tag) for the 199 response code
		</t>
		<t>
			- the forking proxy has not already received and forwarded a 199 response for the early dialog
		</t>
		<t>
			- the forking proxy has not already sent a final response for any of the early dialogs
		</t>
		<t>
			As a consequence, once a final response to the INVITE has been issued by
			the proxy, no further 199 responses associated with the INVITE request will be
			generated or forwarded by the proxy.
		</t>
		<t>
			When the forking proxy forks the initial request, it generates a unique Via header branch parameter value
			for each forked leg. The proxy can determine whether additional forking has occurred downstream of the
			proxy by storing the top Via branch value from each response which creates an early dialog. If the
			same top Via branch value is received for multiple early dialogs, the proxy knows that additional forking
			has occurred downstream of the proxy. A non-2xx final response received for a specific early dialog also
			terminates all other early dialog for which the same top Via branch value was received in the responses
			which created those early dialogs.
		</t>
		<t>
			Based on implementation policy, the forking proxy MAY wait before sending the 199 response, e.g. if it
			expects to receive a 2xx final response on another dialog shortly after it received the non-2xx final
			response which triggered the 199 response.
		</t>
		<t>
			When a forking proxy generates a 199 response, the response MUST contain a To header field tag parameter, that
			identifies the terminated early dialog. The proxy MUST also insert a Reason header field that contains the 
			SIP response code of the response that triggered the 199 response. The SIP response code in the Reason 
			header field informs the receiver of the 199 response about the SIP response code that was used by the UAS to 
			terminate the early dialog, and the receiver might use that information for triggering different types of 
			actions and procedures.
		</t>		
		<t>
			A forking proxy that supports generating of 199 responses MUST keep track of early dialogs, in order to
			determine whether to generate a 199 response when the proxy receives a non-2xx final response. In addition,
			the proxy MUST keep track on which early dialogs it has received and forwarded 199 responses, in order to
			not generate additional 199 responses for those early dialogs.
		</t>
		<t>
			If a forking proxy receives a reliably sent 199 response for a dialog, for which it has previously
			generated and sent a 199 response, it MUST forward the 199 response. If the proxy recieves an unreliably 
			sent 199 response, for which it has previously generated and sent a 199 response,it MAY forward the 
			response, or it MAY discard it.
		</t>
		<t>
			When a forking proxy generates and sends a 199 response, it MUST NOT send the response reliably.
		</t>
		<t>
			When a forking proxy generates and sends a 199 response, the response SHOULD NOT contain a Contact 
			header field or a Record-Route header field <xref target="RFC3261" pageno="false" format="default" />.
		</t>
    </section>
	
    <section title="Backward compatibility" anchor="sec-backward" toc="default">
		<t>
			Since all SIP entities involved in a session setup do not necessarily support the specific meaning of 
			the 199 Early Dialog Terminated provisional response, the sender of the response MUST be prepared to 
			receive SIP requests and responses associated with the dialog for which the 199 response was sent 
			(a proxy can receive SIP messages from either direction). If such request is received by a UA, it 
			MUST act in the same way as if it had received the request after sending the final non-2xx response 
			to the INVITE request, as specified in RFC 3261. A UAC that receives a 199 response for an early 
			dialog MUST NOT send any further requests on that dialog, except for requests which acknowledge 
			reliable responses. A proxy MUST forward requests according to RFC 3261, even if the proxy has 
			knowledge that the early dialog has been terminated.
		</t>
		<t>
			A 199 response does not "replace" a final response. RFC 3261 specifies when a final response is 
			sent.
		</t>
    </section>	
    
	<section title="Usage with SDP offer/answer" toc="default">
		<t>
			A 199 response SHOULD NOT contain an SDP offer/answer <xref target="RFC3264" pageno="false" format="default" /> 
			message body, unless required by the rules in RFC 3264.
		</t>
		<t>
			If an INVITE request does not contain an SDP offer, and the 199 response is the first reliably 
			sent response, the 199 response is required to contain an SDP offer. In this case the UAS SHOULD 
			send the 199 response unreliable, or include an SDP offer with no m- lines in a reliable 199 response.
		</t>
    </section>	
    
	<section title="Usage with 100rel" toc="default">
		<t>
			Since the provisional response is only used for information purpose, the UAS SHOULD send it unreliably, 
			unless the "100rel" option-tag <xref target="RFC3262" pageno="false" format="default" /> is present in 
			the Require header field of the associated request.      
		</t>
		<t>
			NOTE: Implementors need to ensure that a 199 response that is sent unreliably, even if the associated
			INVITE request contained a Require header filed with an "100rel" option-tag, does not trigger errors or
			rejection of the 199 response.		
		</t>
		<t>
			When a forking proxy generates and sends a 199 response, it MUST NOT send the response reliably.
		</t>
		<t>
			NOTE: If the forking proxy would generate a reliable 199 response, it would have to terminate
			the associated PRACK <xref target="RFC3262" pageno="false" format="default" /> request.
		</t>
    </section>
		
	<section title="Normative update of RFC 3262" toc="default">
		<section title="General" toc="default">
			<t>
				The paragraph in this section is added to section 4 of RFC 3262.
			</t>
		</section>
		<section title="RFC3262: 4. UAC Behavior" anchor="sec-update-4" toc="default">>
			<t>
				The UAC MUST support reception of all provisional responses, sent reliably or unreliably; use 
				of the option tag value "100rel" in a Require header field does not change this requirement.
			</t>
		</section>
	</section>
		
    <section title="Message Flow Examples" toc="default">
		<section title="Example with a forking proxy which generates 199" toc="default">
			<t>
				The figure shows an example, where a proxy (P1) forks an INVITE received from UAC. The forked 
				INVITE reaches UAS_2, UAS_3 and UAS_4, which send 18x provisional responses in order to establish 
				early dialogs between themselves and the UAC. UAS_2 and UAS_3 reject the INVITE by sending a 4xx 
				error response each. When P1 receives the 4xx responses it immediately sends 199 responses towards 
				the UAC, to indicate that the early dialogs for which it received the 4xx responses have been 
				terminated. The early dialog leg is shown in parenthesis.
			</t>
			<figure title="Example call flow" anchor="fig-ex1" suppress-title="false" align="left" alt="" width="" height="">
			<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[ 
 UAC           P1               UAS_2   UAS_3   UAS_4
  |             |                 |       |       |       
  |-- INVITE -->|                 |       |       |
  |             |--- INVITE (2) ->|       |       |
  |             |--- INVITE (3) --------->|       |
  |             |--- INVITE (4) ----------------->|
  |             |<-- 18x (2) -----|       |       |
  |<- 18x (2) --|                 |       |       |
  |             |<-- 18x (3) -------------|       |
  |<- 18x (3) --|                 |       |       |
  |             |<-- 18x (4) ---------------------|
  |<- 18x (4) --|                 |       |       |
  |             |<-- 4xx (2) -----|       |       |
  |             |--- ACK (2) ---->|       |       |
  |<- 199 (2) --|                 |       |       |
  |             |<-- 4xx (3) -------------|       |
  |             |--- ACK (3) ------------>|       |
  |<- 199 (3) --|                 |       |       |
  |             |<-- 200 (4) ---------------------|
  |<- 200 (4) --|                 |       |       |
  |-- ACK (4) ->|                 |       |       |
  |             |--- ACK (4) -------------------->|
  |             |                 |       |       |

]]></artwork>
			</figure>
		</section>
		<section title="Example with a forking proxy which receives 200 OK" toc="default">
			<t>
				The figure shows an example, where a proxy (P1) forks an INVITE request received from UAC. 
				The forked request reaches UAS_2, UAS_3 and UAS_4, that all send 18x provisional responses in 
				order to establish early dialogs between themselves and the UAC. Later UAS_4 accepts the 
				session and sends a 200 OK final response. When P1 receives the 200 OK responses it immediately 
				forwards it towards the UAC. P1 does not send 199 responses for the early dialogs from UAS_2 
				and UAS_3, since P1 has yet not received any final responses on those early dialogs (even if P1 
				sends CANCEL requests to UAS_2 and UAS_3 P1 may still receive 200 OK final response from UAS_2 or
				UAS_3, that P1 would have to forward towards the UAC. The early dialog leg is shown in parenthesis.
			</t>
        <figure title="Example call flow" anchor="fig-ex2" suppress-title="false" align="left" alt="" width="" height="">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[ 
 UAC           P1               UAS_2   UAS_3   UAS_4
  |             |                 |       |       |
  |-- INVITE -->|                 |       |       |
  |             |--- INVITE (2) ->|       |       |
  |             |--- INVITE (3) --------->|       |
  |             |--- INVITE (4) ----------------->|
  |             |<-- 18x (2) -----|       |       |
  |<- 18x (2) --|                 |       |       |
  |             |<-- 18x (3) -------------|       |
  |<- 18x (3) --|                 |       |       |
  |             |<-- 18x (4) ---------------------|
  |<- 18x (4) --|                 |       |       |
  |             |<-- 200 (4) ---------------------|
  |<- 200 (4) --|                 |       |       |
  |-- ACK (4) ->|                 |       |       |
  |             |--- ACK (4) -------------------->|
  |             |                 |       |       |

]]></artwork>
        </figure>
		</section>
		<section title="Example with two forking proxies, of which one generates 199" toc="default">
			<t>
				The figure shows an example, where a proxy (P1) forks an INVITE request received from UAC. One 
				of the forked requests reaches UAS_2. The other requests reach another proxy (P2), that forks the 
				request to UAS_3 and UAS_4. UAS_3 and UAS_4 send 18x provisional responses in order to establish 
				early dialogs between themselves and UAC. Later UAS_3 and UAS_4 reject the INVITE request by sending 
				a 4xx error response each. P2 does not support the 199 response code, and forwards a single 4xx 
				response. P1 supports the 199 response code, and when it receives the 4xx response from P2, it also 
				manages to associate the early dialogs from both both UAS_3 and UAS_4 with the response. Therefor 
				it generates and sends two 199 responses to indiccate that the early dialogs from UAS_3 and UAS_4 
				have been terminated. The early dialog leg is shown in parenthesis.
			</t>
        <figure title="Example call flow" anchor="fig-ex3" suppress-title="false" align="left" alt="" width="" height="">
          <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[ 
 UAC           P1              P2               UAS_2   UAS_3   UAS_4
  |             |               |                 |       |       |        
  |-- INVITE -->|               |                 |       |       |
  |             |-- INVITE (2) ------------------>|       |       |
  |             |-- INVITE ---->|                 |       |       |
  |             |               |--- INVITE (3) --------->|       |
  |             |               |--- INVITE (4) ----------------->|
  |             |               |<-- 18x (3) -------------|       |
  |             |<- 18x (3) ----|                 |       |       |
  |<- 18x (3) --|               |                 |       |       |
  |             |               |<-- 18x (4) ---------------------|
  |             |<- 18x (4) ----|                 |       |       |
  |<- 18x (4) --|               |                 |       |       |
  |             |               |<-- 4xx (3) -------------|       |
  |             |               |--- ACK (3) ------------>|       |
  |             |               |<-- 4xx (4) ---------------------|
  |             |               |--- ACK (4) -------------------->|
  |             |<- 4xx (3) ----|                 |       |       |
  |             |-- ACK (3) --->|                 |       |       |
  |<- 199 (3) --|               |                 |       |       |
  |<- 199 (4) --|               |                 |       |       |
  |             |<- 200 (2) ----------------------|       |       |
  |<- 200 (2) --|               |                 |       |       |
  |-- ACK (2) ->|               |                 |       |       |
  |             |-- ACK (2) --------------------->|       |       |
  |             |               |                 |       |       |

]]></artwork>
        </figure>
		</section>
    </section>
	
    <section title="Security Considerations" anchor="sec-security" toc="default">
      <t>
		General security issues related to SIP responses are described in
		<xref target="RFC3261" pageno="false" format="default" />. Due to the nature of 
		the 199 response, it may be attractive to use it for launching attacks in order 
		to terminate specific early dialogs (other early dialogs will not be affected). 
		In addition, if a man-in-the-middle sends a 199 response to the UAC, which terminates 
		a specific dialog, it can take a while until the UAS finds out that the 
		UAC, and possbile stateful intermediates, have terminated the dialog.
		SIP security mechanisms (e.g. hop-to-hop TLS) can be used to minimize, 
		or eliminate, the risk for such attacks.	     
    </t>
    </section>
	
    <section title="IANA Considerations" toc="default">
		<t>
			This section registers a new SIP response code and a new option-tag, according to the
			procedures of RFC 3261, and updates section 4 of RFC 3262.
		</t>
		<section title="IANA Registration of the 199 response code" toc="default">
			<t>
				This section registers a new SIP response code, 199. The
				required information for this registration, as specified in RFC 3261,
				is:
			</t>
        <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[ 
    RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the 
	RFC number of this specification]]

    Response Code Number: 199 

    Default Reason Phrase: Early Dialog Terminated
]]></artwork>
		</section>
		<section title="IANA Registration of the 199 option-tag" toc="default">
			<t>
				This section registers a new SIP option-tag, 199. The
				required information for this registration, as specified in RFC 3261,
				is:
			</t>
        <artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height=""><![CDATA[ 
    Name: 199

    Description: This option-tag is for indicating support of the 199 
         Early Dialog Terminated provisional response code. When present 
         in a Supported header, it indicates that the UA supports the
         response code. When present in a Require header in a request, 
         it indicates that the UAS MUST support the sending of the
         response code. 
]]></artwork>
		</section>
		<section title="RFC 3262 Update" toc="default">
			<t>
				This document updates section 4 of RFC 3262.
			</t>
		</section>
    </section>
	
    <section title="Acknowledgements" anchor="sec-acks" toc="default">
		<t>
			Thanks to Paul Kyzivat, Dale Worley, Gilad Shaham, Francois Audet, Attila Sipos, Robert Sparks, 
			Brett Tate, Ian Elz, Hadriel Kaplan, Timothy Dwight, Dean Willis, Serhad Doken, John Elwell, 
			Gonzalo Camarillo, Adam Roach, Bob Penfield, Tom Taylor, Ya Ching Tan, Keith Drage,  
			Hans Erik van Elburg and Cullen Jennings for their feedback and suggestions.
		</t>
    </section>
	
	<section title="Change Log">
		<t>[RFC EDITOR NOTE: Please remove this section when publishing]</t>	
		<t>
			Changes from draft-ietf-sipcore-199-02
			<list style="symbols">
				<t>Usage example section rewritten and clarified</t>
				<t>Requirement has been removed</t>							
				<t>SIP has been added to document title</t>
				<t>Acronyms expanded in the abstract and throughout the document</t>
				<t>Editorial fixes throughout the document</t>
				<t>Indication added that document is aimed for standards track</t>
				<t>Some references made informative</t>				
				<t>Additional text added regarding the usage of the Reason header</t>
				<t>SBC latching text has been removed</t>
				<t>Usage of Require/Proxy-Require header removed</t>
				<t>Additional text added regarding sending SDP offer in 199</t>
				<t>Note added, which clarifies that 199 does not affect other early dialogs</t>
				<t>References added to Security Considerations</t>
				<t>Clarification of local ringing tone</t>		
				<t>Clarification that media must not be sent or processed after 199</t>
				<t>Text regarding sending media on terminated dialogs added to security section</t>
				<t>Change: UAS must send 199 reliably in case of Require:100rel</t>
				<t>Change: Section 4 of RFC 3262 updated</t>
        	</list>
		</t>			
	</section>	
	
  </middle>
  <back>
    <references title="Normative References">
		<?rfc include="reference.RFC.2119"?>
		<?rfc include="reference.RFC.3261"?>
		<?rfc include="reference.RFC.3262"?>
		<?rfc include="reference.RFC.3264"?>
		<?rfc include="reference.RFC.3326"?>      
		<?rfc include="reference.RFC.3840"?>
    </references>
    <references title="Informational References">
		<?rfc include="reference.RFC.3841"?>
		<?rfc include="reference.RFC.5057"?>
		<reference anchor="3GPP.24.182">
			<front>
  				<title>
					IP Multimedia Subsystem (IMS) Customized Alerting Tones (CAT); Protocol specification
				</title> 
				<author>
					<organization>
						3GPP
					</organization> 
				</author>
  			</front>
 	 		<seriesInfo name="3GPP TS" value="24.182" /> 
  			<format type="HTML" target="http://www.3gpp.org/ftp/Specs/html-info/24182.htm" /> 
  		</reference>
		<reference anchor="3GPP.24.628">
			<front>
  				<title>
					Common Basic Communication procedures using IP Multimedia (IM)Core Network (CN) subsystem; Protocol specification
				</title> 
				<author>
					<organization>
						3GPP
					</organization> 
				</author>
  			</front>
 	 		<seriesInfo name="3GPP TS" value="24.628" /> 
  			<format type="HTML" target="http://www.3gpp.org/ftp/Specs/html-info/24628.htm" /> 
  		</reference>
    </references>
  </back>
</rfc>