One document matched: draft-schwartz-sipping-nsr-code-01.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-01" 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>This specification discusses a SIP response error code ambiguity that may 
   exist due to sematic differences between SIP [RFC3261] and TEL [RFC3966]
   URIs.</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. SIP URIs will often contain alphanumeric 
	  usernames while TEL URIs will always contain telephone number (TN) usernames
	  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.  In the case of a request containing a SIP URI, the UAS 
	  acting on behalf of the target domain can "authoritatively" reject a call 
	  with a 404 when the username is not found. For example, a registrar server 
	  acting on behalf of "example.com" can authoritatively reject a call with
	  a request line containing the URI sip:alice@example.com if no user with the 
	  name "alice" exists at "example.com". The implication of the 404 in this
	  case vis-a-vis the UAC is that no further action should be taken as this
	  would be futile since no user named alice exists at this target.  A request 
	  containing a TEL URI, on the other hand, that is rejected with a similar 
	  error code may indeed find success if failover routing is undertaken by the 
	  UAC.</t>
	  
	  <t>As such either clearer more precise definitions are required for the
	  existing error codes or an additional response code is necessary to 
	  disambiguate the cases described above. This specification chooses the 
	  latter and defines the 4XX (No Service To This Number) response code for
	  this purpose.</t>  
    </section>
	
    <section title="SIP error response code classes">
      <t>When examining SIP error response codes, the following classes or
	  types of scenarios exist:
	  
	  <list>
          <t>Something is wrong with request; either malformed or not acceptable
		  at this particular server: e.g. 400, 405, 413, 414, 415, 416, 420, etc.</t>
		  
		  <t>Nothing is wrong with request but receiving user refuses to accept the
		  call: e.g. 480, 486, 488, 6XX, etc.</t>
		  
          <t>There is some network or other issue that preventing this call from 
		  getting to its destination: e.g. 5XX </t>

          <t>There is some permission based reason to reject the call: e.g. 401,
		  402, 403, 407, etc.</t>

          <t>Message formatting is OK but resource identified in request line URI
		  is not found at this target and no retargeting information is available:
		  e.g. 404, 410, etc.</t>
      </list></t>
   </section>

    <section title="Not found error response code">
      <t>There are a few use cases where this class of error may occur and 
	  the goal of this document is to highlight the problamatic ones. In these
	  cases we need to either re-define clearly the meaning of the
	  response codes or define a new response code to address the case/s that 
	  are not currently addressed. 
	  
	  <list>
          <t>"Authoritative rejection" - as in the case of sip:alice@example.com and 
		  no such user (Alice) exists at example.com. Similarly, this can be the 
		  case of a number in an allocated NPA-NXX block that is not currently 
		  assigned to any user. Implications to UAC are: "stop trying to reach 
		  this user - she doesn't exist". The current definition of 404 should
		  suffice for this case.</t>
		  
		  <t>"Authoritative rejection with possible recourse - server assisted" as
		  in the case where a number has been ported out of a range and the server
		  will return a 3XX indicating the possible (possible but not definite since
		  the requested resource may have already been ported out of recipient network 
		  as well) new target for this call. Implications to UAC in this case are: "I 
		  can't help you - go there - he may be able to help you". The current definition
		  of 3XX responses should suffice for this case.</t>
		  
		  <t>"Non-Authoritative rejection" - server is not carrier of record for the 
		  requested resource and has no access to data store (e.g. central database used
		  for number portability data) to populate a 3XX response. Implications to 
		  UAC are: "Don't stop trying to reach this user - he MAY or MAY NOT exist
		  - try looking elsewhere if you can." Need to find a suitable error code
		  for this case or define a new one.</t>

		  <t>"Proxy of Authoritative rejection" - Request has been retargeted through
		  this server to a downstream server that has authoritatively rejected the call
		  with a 404. While this information is authoritative, since it was retargeted
		  and possibly modified (the request URI that is) in the process, the UAC
		  must be made aware of this fact to decide if he wishes to try alternate
		  routing. Can probably use the Warning header which includes the retargeted
		  URI.</t>
      </list></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 not serviced 
	  by the domain for which the server is responsible and no retargeting
	  information is available.</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 domain 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 definitive rejection error response code MUST not be 
			retargeted by the UAC.
		  </t>
		  <t>
		    Req 5: An uncertain rejection error response code MAY be 
			retargeted 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
	  number space 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>