One document matched: draft-schwartz-sipping-nsr-code-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3966 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3966.xml">
<!ENTITY I-D.draft-ietf-speermint-terminology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-speermint-terminology-16.xml">
<!ENTITY I-D.draft-schwartz-sip-e164-ownership SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-schwartz-sip-e164-ownership-01.xml">
<!ENTITY I-D.draft-ietf-sipping-dialogusage SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sipping-dialogusage-06.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="std" docName="draft-schwartz-sipping-nsr-code-00" ipr="full3978">
  <front>
    <title abbrev="No Service To This Number Reject Code">No Service To This Number Reject Code</title>

	<author initials="D.S" surname="Schwartz" fullname="David Schwartz">
			<organization>XConnect Global Networks</organization>
				<address>
					<postal>
						<street>Malcha Technology Park</street>
						<street>Building # 1</street>
						<city>Jerusalem</city><code>90961</code>
						<country>Israel</country>
					</postal>
					<phone>+972 2 621 8002</phone>
					<email>dschwartz@xconnect.net</email>
					<uri>www.xconnect.net</uri>
			   </address>
		</author>

    <date year="2008" />

    <abstract>
      <t>The Session Initiation Protocol (SIP) allows for users to make
   calls using telephone numbers embedded in either "sip" [RFC3261] or "tel" 
   [RFC3966] URIs. Either way, the telephone number (TN) itself is not restricted 
   and can represent an entity in the public telephone network, an entity in a 
   private telephone network or an entity on the Internet.  This TN
   resolution ambiguity highlights the difference between the LUF and LRF 
   functions defined in [I-D.draft-ietf-speermint-terminology] and underscores the need 
   for more precise SIP error rejection codes. SIP has no way to indicate to 
   the calling UAC that the reason for call rejection is due to the fact that 
   this number does not exist in the requested domain or realm but it does 
   exist in the public telephone network for instance. Such an indication 
   is useful to allow the call to be retried at a different context (i.e. 
   the public PSTN in this case) with possibly better results.  This 
   specification defines a new SIP response code for this purpose.</t> 
    </abstract>
   
   <note title="Terminology">
      <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 <xref
      target="RFC2119"></xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>The Session Initiation Protocol (SIP) <xref target="RFC3261"></xref> 
	  facilitates outgoing calls by having the caller compose a request message 
	  using a request uri containing an address of record (AOR) of the form 
	  sip:username@domain or tel:username, and sending the request to a server 
	  (UAS, proxy acting on UASs behalf or redirect server) responsible for the
	  request's domain or some other pre-determined domain (e.g. outgoing proxy
	  or server providing LUF [I-D.draft-ietf-speermint-terminology].  
	  There is no real restriction on the value that the username part 
	  of the request URI can take, and in reality, in most cases today this value 
	  contains a telephone number (TN) representing either an entity in the public 
	  telephone network, an entity in a private telephone network or an entity 
	  on the Internet.</t>
	  
	  <t>On the receiving side, the UAS/redirect server must either resolve the 
	  AOR (TN in this case) and forward/redirect appropriately or reject the 
	  call outright.  The AOR may not contain a domain "responsible" for 
	  this TN (i.e. in the case of a "tel" URI) or even if it does, the domain 
	  may simply refer to the recieving UAS/redirect realm and not necessarily 
	  the "owner" network of this TN (see [I-D.draft-schwartz-sip-e164-ownership] 
	  for discussion of 
	  TN ownership).  It is therefore quite possible that the UAS/redirect server 
	  will not be able to resolve the TN to an authoritative URI.  In this case
	  the call will have to be rejected and an appropriate error response
	  code returned upstream to the caller. The point to realize, however, is that
	  the semantics of this rejection are differnt than the typical 404 "Not Found"
	  error code.  Since non TN AORs are tied to a domain, the "Not Found" is 
	  final as the UAS/redirect server bound to this domain is the ultimate
	  authority on the matter.  There is no point in retrying the call at
	  a different domain as it will get forwarded back to authoritative domain
	  that has already rejected the call.  In the TN case, however, the semantics
	  merely imply that the current domain cannot resolve the call, BUT that 
	  the call should be tried again elsewhere as a different domain may yield 
	  a positive result.</t>
	  
	  <t>SIP does not provide a response code that allows for this 
	  differentiation.  The closest response code is 404 "Not Found", and 
	  while it is possible to include a reason phrase with this response, this
	  approach is not useful for automata. An indication that can be understood 
	  by an automaton would allow for programmatic handling, including automatic 
	  retries and proper classification of error in dynamic LCR environments.</t>
	  
	  <t>To remedy this, this specification defines the 4XX (No Service To This 
	  Number) response code.</t>  
    </section>

    <section title="UAS Behavior">
      <t>A server (generally acting on behalf of the called party, though this
	  need not be the case) MAY generate a 4XX "No Service To This Number" 
	  response when it receives a request for a TN that is not serviced by
	  the domain for which the server is responsible.  The reasons for lack of 
	  service may be any one of the following two cases:
	  
	  <list>
          <t>The requested TN does not exist in the realm that this server is
		     responsible for and no forwarding rules are defined</t>
          <t>The requested TN does exist however it is not routable (e.g. part
		     of an allocated number block that is not assigned to any user)</t>
      </list>
	  
	  It is important to note that rejections due to policy affecting the caller
	  are out of scope and should use error codes such as 402 "Payment Required" 
	  or 403 "Prohibited". Similarly, rejection due to policy affecting network 
	  usage (e.g. call gapping or throttling) should be dealt with using a 
	  503 "Service Unavailable".</t>
   </section>

    <section title="UAC Behavior">
      <t>A UAC receiving a 4XX (No Service To This Number) MUST NOT retry the
	  request to the same server and SHOULD fail over to alternate servers if 
	  these are available to try to complete the call.</t>
	  
	  <t>Receipt of a 4XX response to a mid-dialog request SHOULD NOT cause
	  the dialog to terminate, and SHOULD NOT cause the specific usage of
	  that dialog to terminate [I-D.draft-ietf-sipping-dialogusage]</t>
	  
	  <t>A UAC that does not understand or care about the specific semantics
	  of the 4XX response will treat it as a 400 response.</t>
   </section>

    <section title="Requirements">
	  <t>
		The following issues should be addressed when considering this new 
		error response code:
	  </t>
	  <t>
		<list style="hanging">
		  <t>
			Req 1: It MUST be possible to differentiate between the case where 
			a resource is not found at its authoritative domain and the case 
			where it is not found by some other domain.
		  </t>
		  <t>
		    Req 2: Specifically, it MUST be possible differentiate between the 
			case when a domian knows a resource does not exist (here or anywhere) and 
			the case where all that is knows by the domain is that it can not say
			authoritatively whether or not the resource exists anywhere else.
		  </t>
		  <t>
		    Req 3: It MUST be possible for a UAS to return a different SIP error 
			message depending on the above differentiation.
		  </t>
		  <t>
		    Req 4: A definative rejection error response code MUST not be 
			retargetted by the UAC.
		  </t>
		  <t>
		    Req 5: An uncertain rejection error response code MAY be 
			retargetted by the UAC.
		  </t>
		</list>
	  </t>
	</section>

    <section title="IANA Considerations">
      <t>This section registers a new SIP response code according to the
	  procedures of RFC 3261.</t>
	  
	  <t>RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the RFC
	  number of this specification]]</t>
    </section>

    <section anchor="security_considerations" title="Security Considerations">
      <t>   The fact that a request was rejected because it was targeted at a
	  resource that is not available at a particular UAS does in fact
	  reveal sensitive information about the called party - the actual
	  numberspace served by this UAS.  This information may or may not be
	  sensitive.  If it is, a UAS SHOULD reject the request with a 404 instead.</t>
    </section>

    <section title="Acknowledgements">
      <t>This draft was motivated by trials at XConnect Global Networks where
	  rejection of TN requests by participating operators led to reduced
	  ASRs and consequential automatic removal from operator LCR tables even
	  in cases where the rejection by XConnect was due to TN being a PSTN endpoint
	  (non-IP) and not server error or other termination failure problem justifying 
	  the reduced ASR.</t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      &rfc3261;

      &rfc3966;

      &rfc2119;

    </references>

    <references title="Informational References">
	  &I-D.draft-ietf-speermint-terminology;
	  
	  &I-D.draft-schwartz-sip-e164-ownership;
	  
	  &I-D.draft-ietf-sipping-dialogusage;
	  
    </references>
  </back>
</rfc>