Number Portability Parameters for the "tel" URI
draft-ietf-iptel-tel-np-11

IPTEL Working Group                                               J. Yu 
Internet Draft                                                  NeuStar 
Document: draft-ietf-iptel-tel-np-11.txt                August 28, 2006 
Category: Standards Track                                               
 
 
                    NP Parameters for the "tel" URI 
 
    
Status of this Memo 
    
   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in progress".  
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt.  
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
   This Internet-Draft will expire on February 27, 2007. 
    
    
Copyright Notice 
 
   Copyright (C) The Internet Society (2006).  
    
    
Abstract 
    
   This document defines five parameters in the "tel" Uniform Resource 
   Identifier (URI) to carry the number portability (NP)-related 
   information.  Those parameters can be passed to the next-hop network 
   node after an NP database dip has been performed. 
    
 
 
 
 
 
  
Yu                      Expires February 27, 2007            [Page 1] 


Internet-Draft       NP Parameters for the "tel" URI        August 2006   
                      
 
Table of Contents 
    
   1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   2 
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2 
   3.  Abbreviation . . . . . . . . . . . . . . . . . . . . . . . .   3 
   4.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . .   4 
   5.  Normative Rules  . . . . . . . . . . . . . . . . . . . . . .   5 
     5.1.  Handling "tel" URI with NP Parameter or Parameters . . .   6 
     5.2.  Adding NP Parameter or Parameters to the "tel" URI . . .   8 
       5.2.1. Retrieving NP-related information for a geographical 
              telephone number  . . . . . . . . . . . . . . . . . .   8 
       5.2.2. Retrieving NP-related information for a freephone  
              number  . . . . . . . . . . . . . . . . . . . . . . .   9 
       5.2.3. Adding location information about the caller  . . . .  10 
       5.2.4. Adding NP parameter or parameters due to protocol 
              Conversion  . . . . . . . . . . . . . . . . . . . . .  10 
   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  11 
   7.  Security Considerations  . . . . . . . . . . . . . . . . . .  12 
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  13 
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . .  13 
     9.1.  Normative References . . . . . . . . . . . . . . . . . .  13 
     9.2.  Informative References . . . . . . . . . . . . . . . . .  13 
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  13 
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . .  14 
   Intellectual Property and Copyright Statements . . . . . . . . .  14 
 
1. Conventions 
    
   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 RFC2119 [RFC2119]. 
    
2. Introduction 
    
   Number portability (NP) [RFC3482] allows telephony subscribers to 
   keep their telephone numbers when they change service provider 
   (service provider portability), move to a new location (location 
   portability), or change the subscribed services (service 
   portability).  The telephone numbers can be the geographical 
   telephone numbers, mobile telephone numbers, freephone numbers or 
   other types of non-geographical telephone numbers.  Some mobile 
   telephone numbers are like geographical telephone numbers (e.g., 
   those in the North America) and others are of non-geographical 
   nature but their routing is similar to the routing of geographical 
   telephone numbers so they are not specifically mentioned in this 
   document.  The freephone numbers are also known as the toll free 
   phone numbers.  The called party who is assigned the freephone 
   number pays the call charge when the caller dials the freephone 
   number. 
    
   NP impacts call signaling and routing.  One impact is the need to 
   carry the NP-related information in the "tel" URI [RFC3966] for 
   protocols such as the Session Initiation Protocol (SIP) [RFC3261] 
  
Yu                     Expires  February 27, 2007             [Page 2] 


Internet-Draft       NP Parameters for the "tel" URI        August 2006   
                      
 
   and H.323 [H323] after the NP database dip has been performed.  
   Another impact is for a Voice over IP (VoIP) server to use the NP-
   related information in a received "tel" URI to determine routing. 
    
   A routing number is associated with a geographical or mobile 
   telephone number that has been ported out from a donor carrier to 
   another carrier.  A donor carrier is the initial carrier where a 
   geographical telephone number was allocated before ever being 
   ported.  A "non-ported" geographical or mobile telephone number does 
   not have any routing number associated with it because the first N 
   digits of the geographical or mobile telephone number can be used 
   for routing.  A routing number can also be used to indicate the 
   switch or network node that originates a call or service similar to 
   the Jurisdiction Information Parameter in Signaling System Number 7 
   (SS7) Integrated Services Digital Network User Part (ISUP).  The 
   "rn" parameter carries the routing number information.  The "rn-
   context" parameter describes how the "rn" parameter value should be 
   interpreted when the value is not a "global-rn" as is discussed in 
   Section 4. 
     
   The NP database dip indicator is used to inform the downstream 
   servers or switches during call setup that there is no need to 
   perform the NP database dip for a geographical telephone number 
   again.  The "npdi" parameter carries such an indicator. 
    
   A "Carrier Identification Code (CIC)" identifies the current 
   freephone service provider for a freephone number.  This parameter 
   can also be used to carry the pre-subscribed or dialed long distance 
   carrier information; however, that is outside the scope of this 
   document.  The "cic" parameter carries the CIC information.  The 
   "cic-context" parameter describes how the "cic" parameter value 
   should be interpreted when the value is not a "global-cic" as is 
   discussed in Section 4. 
    
3. Abbreviations 
    
   ABNF   Augmented Backus-Naur Form 
   ANSI   American National Standards Institute 
   CIC    Carrier Identification Code (also cic) 
   CIP    Carrier Identification Parameter 
   FCI    Forward Call Indicator 
   GAP    Generic Address Parameter 
   GSTN   Global Switched Telephone Network 
   HTML   HyperText Markup Language 
   IC     Identification Code 
   ISUP   Integrated Services Digital Network User Part 
   JIP    Jurisdiction Information Parameter 
   NP     Number Portability 
   NPDB   Number Portability Database 
   npdi   NP Database Dip Indicator 
   rn     Routing Number 
   PNTI   Ported Number Translation Indicator 
   SIP    Session Initiation Protocol 
  
Yu                     Expires  February 27, 2007             [Page 3] 


Internet-Draft       NP Parameters for the "tel" URI        August 2006   
                      
 
   SS7    Signaling System Number 7 
   URI    Uniform Resource Identifier 
   VoIP   Voice over IP 
 
4. Formal Syntax 
    
   The following syntax specification uses the Augmented Backus-Naur 
   Form (ABNF) as described in RFC-4234 [RFC4234] and defines the five 
   parameters, rn, npdi, cic, rn-context and cic-context, by extending 
   the "parameter" production rule of the "tel" URI defined in 
   [RFC3966]. 
    
   Parameter               =/ rn / cic / npdi  
   rn                      = ";rn=" (global-rn / local-rn) 
   npdi                    = ";npdi"  
   cic                     = ";cic=" (global-cic / local-cic) 
   global-rn               = global-hex-digits 
   local-rn                = 1*hex-phonedigit rn-context 
   rn-context              = ";rn-context=" rn-descriptor  
   rn-descriptor           = domainname / global-hex-digits 
   global-hex-digits       = "+" 1*3(DIGIT) *hex-phonedigit 
   hex-phonedigit          = HEXDIG / visual-separator 
   visual-separator        = "-" / "." / "(" / ")" 
   domainname              = *( domainlabel "." ) toplabel ["."] 
   domainlabel             = alphanum 
                             / alphanum *( alphanum / "-" ) alphanum 
   toplabel                = ALPHA / ALPHA *( alphanum / "-" ) alphanum 
   alphanum                = ALPHA / DIGIT 
   global-cic              = global-hex-digits                                
   local-cic               = 1*hex-phonedigit cic-context 
   cic-context             = ";cic-context=" rn-descriptor  
    
   The "rn", "npdi" or "cic" parameter each can appear in the "tel" URI 
   at most once. 
    
   The first "hex-phonedigit" value in "local-rn" or "local-cic" MUST 
   be a hex-decimal digit. 
    
   For a "global-rn", the routing number information after "+" MUST 
   begin with a valid E.164 [E164] country code.  Hexadecimal digit is 
   allowed after the country code in the "global-rn". 
    
   For a "local-rn", the routing number in the "rn" parameter MUST be 
   interpreted according to the "rn-context".  For example, if a 
   national routing number is in the "rn" parameter, the "rn-context" 
   MUST contain a valid E.164 country code after "+" if it is in the 
   "global-hex-digits" format.  Hexadecimal digit is allowed in the 
   "local-rn". 
    
   For a "global-cic", the CIC information after "+" MUST begin with a 
   valid E.164 country code.   
    
  
Yu                     Expires  February 27, 2007             [Page 4] 


Internet-Draft       NP Parameters for the "tel" URI        August 2006   
                      
 
   For a "local-cic", the CIC value in the "cic" parameter MUST be 
   interpreted according to the "cic-context".  For example, if the 
   national CIC value is in the "cic" parameter, the "cic-context" MUST 
   contain a valid E.164 country code after "+" if it is in the 
   "global-hex-digits" format. 
    
   The inclusion of the visual separator in the "rn" or "cic" is 
   optional. 
 
5. Normative Rules 
    
   There are two distinct uses for the tel URI. In one use, the tel URI 
   appears in a piece of static content. For example, it might appear 
   in a HyperText Markup Language (HTML) page or a presence document. 
   In another use, the tel URI appears in call signaling protocols, 
   such as SIP and H.323, where it is used to guide routing of the call 
   setup messages. The tel URI extensions defined in this document are 
   targeted at call signaling protocols. When a tel URI is placed in 
   static content, the parameters defined here SHOULD NOT be present, 
   and any entity receiving them SHOULD remove them prior to using the 
   tel URI. 
    
   Within the context of signaling protocols, these parameters are 
   meant for usage between call signaling entities, called network 
   nodes, amongst them there is a trust relationship. Since parameters 
   inserted by one network node can impact the routing of a request at 
   a downstream node, processing of these parameters depends on 
   trusting that the upstream element properly followed the rules 
   defined here. A call signaling protocol can verify that an upstream 
   element is part of its circle of trust through hop-by-hop integrity 
   mechanisms. See Section 7, Security Considerations, for more 
   information. If a network node receives a call signaling message 
   from an element it does not trust, it SHOULD ignore the parameters. 
    
   This section discusses how a network node handles a received "tel" 
   URI that contains one or more of the parameters defined in this 
   document or has accessed an NP database for a freephone number or 
   geographical telephone number and needs to add some of the 
   parameters defined in this document to a "tel" URI. 
    
   In countries where there is no freephone number portability or 
   geographical telephone number portability, the call routing can be 
   based on the leading digits of the freephone number or geographical 
   telephone number.  This document does not describe those scenarios. 
    
   Please note that two accesses to the freephone databases are 
   normally done for routing a call to a freephone number.  The first 
   one is done by the originating network that queries a freephone 
   database for the CIC information so that the call can be routed to 
   the serving freephone service provider of the called freephone 
  
Yu                     Expires  February 27, 2007             [Page 5] 


Internet-Draft       NP Parameters for the "tel" URI        August 2006   
                      
 
   number.  When the call reaches the serving freephone provider, the 
   second database access is performed to map the freephone number to a 
   geographical telephone number and/or internal routing information.  
   This document does not address the case where internal routing 
   information is returned. 
    
   The first freephone database contains the CIC information for all 
   the active freephone numbers while the second one usually contains 
   mapping information only for those freephone numbers served by a 
   freephone service provider.  Because the originating carrier may 
   provide freephone service, its freephone database would contain the 
   CIC information for all the active freephone numbers plus the 
   mapping information for those freephone numbers it serves.  This 
   document refers to the two database accesses as "the first freephone 
   database access" and "the second freephone database access". 
    
   When handling the "rn" and "cic" parameters and the phone numbers in 
   the "tel" URI for the purposes such as database access and routing, 
   the visual separators in them are removed before using the 
   information in them. 
    
   When a network node handles a "tel" URI that contains invalid "rn" 
   or "cic" information, it may release the call or drop the invalid 
   parameter and access the appropriate NP database or freephone 
   database to see if it can retrieve a valid routing number for a 
   geographical telephone number or valid CIC for the freephone number. 
    
   When a "tel" URI is received from an untrusted source, a network 
   node MAY redo the NPDB query. 
    
   SIP [RFC 3261] has mechanisms in place to detect routing loops due to 
   URI re-writing, and the new parameters added here work within these 
   established contexts. The npdi parameter in the URI that indicates a 
   NPDB query has already been done can also prevent routing loop.  
   Other protocols considering using these "tel" URI parameters SHOULD 
   ensure that they have mechanisms in place to detect loops when re-
   writing the "tel" URI. 
 
5.1 Handling "tel" URI with NP Parameter or Parameters 
    
   If the "tel" URI contains the "npdi" parameter, the network node 
   MUST NOT retrieve the NP-related information for geographical 
   telephone numbers even if it is set to do so. 
    
   If the "tel" URI contains the "cic" parameter whose CIC value is 
   different from the one this network node is associated with, this 
   network node MUST NOT retrieve the NP-related information for the 
   geographical telephone number or perform the first freephone 
   database access for the freephone number in the "tel" URI. 
    
   For the "cic" and "rn" parameters and either a freephone number or 
   geographical telephone number, the order of processing is to look 
  
Yu                     Expires  February 27, 2007             [Page 6] 


Internet-Draft       NP Parameters for the "tel" URI        August 2006   
                      
 
   for the "cic" parameter first for call routing.  If the CIC 
   information is not useful or the "cic" parameter does not exist, 
   then the next step is to look for the "rn" parameter.  If the 
   information in the "rn" parameter is not useful or the "rn" 
   parameter does not exist, then the freephone number or geographical 
   telephone number is used. 
    
   If the network node does not know how to route based on the "cic" or 
   "rn" parameter, the local policies MUST decide whether to stop the 
   call processing or continue the call processing by ignoring the 
   invalid/unknown information. 
    
   When looking for the "cic" parameter and that parameter exists in 
   the "tel" URI: 
    
   - The network node MUST ignore the "cic" parameter if the CIC 
     identifies a carrier or service provider associated with that node 
     and look for the "rn" parameter for making the routing decision.  
     It MUST remove the "cic" parameter when it routes the call to the 
     next-hop network node that belongs to another carrier or service 
     provider. 
     
   - The network node MUST invoke special handling process if the "cic" 
     parameter contains a code that requires such a treatment.  For 
     example, a CIC value of "0110" in the response to a freephone DB 
     query in the North America indicates "local, translated 
     geographical telephone number provided".  In this particular 
     example, the "cic" parameter is ignored.  Please note that this 
     particular CIC value of "+1-0110" normally will not appear in the 
     call setup message. It is given as an example to show that such 
     special CIC values may exist.  The exact code values and the 
     handling of them are outside the scope of this document. 
    
   - Otherwise, the network node MUST make the routing decision based 
     on the CIC.  The network node MUST NOT remove the "cic" parameter 
     unless it is handing over the call to the carrier or service 
     provider identified by the CIC and the local policies require it 
     to remove the "cic" parameter.  How the call is actually routed 
     based on the CIC value in the "cic" parameter is outside the scope 
     of this document. 
    
   When looking for the "rn" parameter and that parameter exists in the 
   "tel" URI: 
    
   - If the routing number in the "rn" parameter points to this network 
     node (e.g., the call has reached the intended network node), this 
     network node MUST look for the freephone number or geographical 
     telephone number for making the routing decision.  It MUST remove 
     the "rn" parameter when setting up the call to the next-hop 
     network node regardless if that next-hop network node is in the 
     same or different network. 
    

  
Yu                     Expires  February 27, 2007             [Page 7] 


Internet-Draft       NP Parameters for the "tel" URI        August 2006   
                      
 
   - If the routing number in the "rn" parameter points to a network 
     this network node is in (e.g., in some countries the routing 
     number gets the call to the serving carrier network where another 
     NP database access is required to locate the serving switch), this 
     network node MUST look for the freephone number or geographical 
     telephone number for making the routing decision.  The network 
     node MAY access the NP database for routing information if it is 
     set to do so.  It MUST remove the "rn" parameter if the next-hop 
     network node belongs to another carrier or service provider. 
    
   - Otherwise, the network node MUST make the routing decision based 
     on the routing number in the "rn" parameter.  How the call is 
     actually routed based on the routing number in the "rn" parameter 
     is outside the scope of this document. 
    
   When the "cic" or "rn" parameter is not used for routing, the 
   network node uses the freephone number or geographical telephone 
   number for making routing decisions.  It may access the NP database 
   if it is set to do so, or it may route the call to a designated 
   network node that will access the NP database, or it may route the 
   call based on the local routing table.  How the call is handled at 
   this stage is outside the scope of this document.  See Section 5.2 
   for rules in adding the parameter or parameters defined in this 
   document to the "tel" URI if the network node is set to access the 
   NP database. 
 
5.2 Adding NP Parameter or Parameters to the "tel" URI 
    
   There are two cases in terms of NP database access.  One is for a 
   geographical telephone number and the other is for a freephone 
   number.  They are discussed in Sections 5.2.1 and 5.2.2 for a "tel" 
   URI that is used for routing. 
    
   Section 5.2.3 discusses a special case where the "rn" parameter is 
   added to a "tel" URI that is associated with the first network node 
   that handles the call request from the caller.  Section 5.3.4 
   discusses the addition of the parameter or parameters defined in 
   this document to the "tel" URI due to protocol conversion. 
    
5.2.1 Retrieving NP-related information for a geographical telephone 
      number 
    
   When a network node accesses an NP database for a geographical 
   telephone number: 
    
   - If the network node retrieves a routing number, it MUST add the 
     "rn" parameter to the "tel" URI to carry the routing number 
     information in the "global-rn" or "local-rn" format.  It MUST also 
     add the "npdi" parameter. 
       
   - If the network node does not retrieve a routing number (e.g., for 
     a non-ported geographical telephone number), it MUST add the 
     "npdi" parameter to the "tel" URI.   
  
Yu                     Expires  February 27, 2007             [Page 8] 


Internet-Draft       NP Parameters for the "tel" URI        August 2006   
                      
 
    
   The network node MUST follow the rules described in Section 5.1 for 
   using the information in the "tel" URI to make the routing decision. 
    
5.2.2 Retrieving NP-related information for a freephone number 
    
   When a network node performs the first or second freephone database 
   access for a freephone number: 
    
   - If the network node retrieves a CIC that identifies a carrier or 
     service provider associated with that network node, or indicates 
     that a geographic number is supplied (e.g., "+1-0110" means 
     "local, translated geographical telephone number provided"), it 
     would have retrieved a geographical telephone number.  The network 
     node MUST NOT add the "cic" parameter and MUST replace the 
     freephone number in the "tel" URI with the retrieved geographical 
     telephone number in either the "global-number" or "local-number" 
     format. 
    
     Some freephone databases may not return the geographical telephone 
     number but internal routing information in a proprietary format 
     (e.g., switch ID and trunk group ID).  That case is outside the 
     scope of this document. 
    
   - If the network node retrieves a CIC that belongs to another 
     freephone service provider, the network node MUST add the "cic" 
     parameter to the "tel" URI that contains the CIC in the "global-
     cic" or "local-cic" format. 
      
     The originating carrier may have business agreements with a 
     freephone service provider to return the geographical telephone 
     number in addition to the CIC.  When a geographical telephone 
     number is returned, the network node MUST replace the freephone 
     number in the "tel" URI with the returned geographical telephone 
     number in either the "global-number" or "local-number" format.   
    
   - If the network node retrieves a geographical telephone number 
     (which is the typical case for the second freephone database 
     access), the network node MUST replace the freephone number in the 
     "tel" URI with the retrieved geographical telephone number in 
     either the "global-number" or "local-number" format. 
    
     When a geographical telephone number is returned in the response, 
     it is possible that the NP-related information for that 
     geographical telephone number could also be returned.  In that 
     case, the network node MUST add the "npdi" parameter and MUST add 
     the "rn" parameter to contain the routing number in either the 
     "global-rn" or "local-rn" format only when the routing number is 
     available. 
    
   The network node MUST follow the rules described in Section 5.1 for 
   using the information in the "tel" URI to make the routing decision. 
    
  
Yu                     Expires  February 27, 2007             [Page 9] 


Internet-Draft       NP Parameters for the "tel" URI        August 2006   
                      
 
5.2.3 Adding location information about the caller 
    
   In SS7 ISUP, the JIP identifies the switch that originates the call 
   and the information in it may be used by the serving carrier to 
   determine the call charge to the caller or by the involved carriers 
   to determine the settlement amount between them. 
    
   A network node that is the first to handle the call request from the 
   caller MAY include the "rn" parameter to the "tel" URI associated 
   with the caller, if one exists.  For example, if the network node is 
   a Global Switched Telephone Network (GSTN) gateway that receives an 
   ISUP message that contains the JIP, the correct location information 
   in the JIP can be placed in the "rn" parameter of the "tel" URI that 
   is associated with the caller. 
    
   Please note that the information in the "rn" parameter may not be 
   authenticated; therefore, the use of the information by the 
   recipient of the "tel" URI for anything related to charging is done 
   at its own risk. 
    
5.2.4 Adding NP parameter or parameters due to protocol conversion 
    
   A GSTN gateway needs to convert between SS7 ISUP and the VoIP 
   protocol such as SIP or H.323.  This type of network node MUST map 
   between the corresponding ISUP parameters and the parameters defined 
   in this document associated with the "tel" URI for routing and MAY 
   map between the corresponding ISUP parameters and the parameters 
   defined in this document that are in the "tel" URI associated with 
   the caller. 
    
   Since ISUP support for NP depends on the individual country, the 
   following discussion applies to a situation when a network node is 
   to map between the NP information in the American National Standards 
   Institute (ANSI) ISUP and the NP-related parameters in the "tel" 
   URI.   
    
   For a ported geographical telephone number, the network node MUST 
   convert the routing number in the ISUP Called Party Number parameter 
   to a routing number in either the "global-rn" or "local-rn" format 
   and carry it in the "rn" parameter for a "tel" URI that is used for 
   routing.  The network node MUST convert the phone number that is 
   marked as the "ported number" in the ISUP Generic Address Parameter 
   (GAP) to a phone number in either the "global-number" or "local-
   number" format [RFC3966] and put it in the global-number-digits or 
   local-number-digits (see [RFC3966]) part of the "tel" URI that is 
   used for routing.  
    
   For a non-ported geographical telephone number, the network node 
   MUST convert the phone number in the ISUP Called Party Number 
   parameter to a phone number in either the "global-number" or "local-
   number" format and put it in the global-number-digits or local-
   number-digits (see [RFC3966]) part of the "tel" URI that is used for 
   routing.  The "rn" parameter MUST NOT appear in the "tel" URI unless 
  
Yu                     Expires  February 27, 2007             [Page 10] 


Internet-Draft       NP Parameters for the "tel" URI        August 2006   
                      
 
   the local policies require the network node to include it.  It is 
   outside the scope of this document how to include the "rn" parameter 
   if the local policies require the network node to do so.  
    
   The network node MUST include the "npdi" parameter in the "tel" URI 
   that is used for routing when the Ported Number Translation 
   Indicator (PNTI) bit in the Forward Call Indicator (FCI) parameter 
   is set to "1".  
    
   The network node MUST include the "cic" parameter in either the 
   "global-cic" or "local-cic" format in the "tel" URI that is used for 
   routing when the ISUP Carrier Identification Parameter (CIP) is 
   present.   
    
   The network node MAY include the "rn" parameter in the "tel" URI 
   associated with the caller information when the ISUP JIP is present. 
   This may be subject to the network node's local policy and/or the 
   signaling protocol that carries the "tel" URI. 
    
   Mapping NP-related parameters in a "tel" URI to the NP-related 
   information in the ISUP message depends on the national ISUP 
   implementation and is outside the scope of this document. 
    
6. Examples 
    
   A. A "tel" URI, tel:+1-800-123-4567, contains a freephone number "+1-
     800-123-4567".  Assume that this freephone number is served by a 
     freephone service provider with a CIC "+1-6789".  After retrieving 
     the NP-related information, the "tel" URI would be set to 
    
        tel:+1-800-123-4567;cic=+1-6789 
    
   B. A "tel" URI, tel:+1-800-123-4567;cic=+1-6789, is handled by a 
     network node in the serving freephone service provider's network.  
     Assume that the freephone number is mapped to a geographical 
     telephone number "+1-202-533-1234".  After retrieving the NP-
     related information, the "tel" URI would be set to 
    
        tel:+1-202-533-1234 
 
   C. A "tel" URI, tel:+1-202-533-1234, contains a geographical 
     telephone number "+1-202-533-1234".  Assume that this geographical 
     telephone number is ported and is associated with a routing number 
     "1-202-544-0000".  After retrieving the NP-related information, 
     the "tel" URI would be set to 
    
        tel:+1-202-533-1234;npdi;rn=+1-202-544-0000 
    
   D. A "tel" URI, tel:+1-202-533-6789, contains a geographical 
     telephone number "+1-202-533-6789".  Assume that this geographical 
     telephone number is not ported.  After accessing the NP database, 
     the "tel" URI would be set to 
  
  
Yu                     Expires  February 27, 2007             [Page 11] 


Internet-Draft       NP Parameters for the "tel" URI        August 2006   
                      
 
        tel:+1-202-533-6789;npdi 
 
   E. A "tel" URI, tel:+1-202-533-1234;npdi;rn=+1-202-000-0000, contains 
     an invalid routing number (e.g., no routing information on "+1-
     202-000-0000"), the network node may drop the "rn" parameter and 
     access the NP database again. 
 
   F. A "tel" URI, tel:+1-800-123-456, contains a freephone number "+1-
     800-123-456" that is one digit short.  When accessing the 
     freephone database, there won't be any "cic" information for this 
     freephone number.  The call would be released. 
         
   G. A "tel" URI, tel:+1-800-123-4567;cic=+1-56789, is handled by a 
     network node in an originating or a transit network.  The "cic" 
     information is invalid.  The network node may drop the "cic" 
     parameter and access the freephone database again.  If the same 
     wrong CIC information is received, the network node would release 
     the call because it does not know how to route the call with an 
     invalid CIC.  If valid information is received, the network node 
     will use the received CIC in the "cic" and route the call based on 
     the "cic". 
 
7. Security Considerations 
 
   In addition to those security implications discussed in the revised 
   "tel" URI [RFC3966], there are new security implications associated 
   with the parameters defined in this document. 
    
   If the value of the "rn" or "cic" in the "tel" URI is changed 
   illegally when the signaling message carrying the "tel" URI is en 
   route to the destination entity, the signaling message or call may 
   be routed to the wrong network or network node causing the call 
   setup to be rejected. 
    
   If the "npdi" is illegally inserted into the "tel" URI when the 
   signaling message carrying the "tel" URI is en route to the 
   destination entity, the call may be routed to the wrong network or 
   network node causing the call setup to be rejected.  It is less a 
   problem if the "npdi" is illegally removed.  An additional NPDB 
   query may be performed to retrieve the routing number information 
   and have the "npdi" included again. 
    
   If the "rn" in the "tel" URI that is associated with the caller is 
   illegally changed or inserted, the call charge based on that "rn" 
   would be incorrect. 
    
   Because of these considerations, these tel URI extensions are only 
   applicable within a set of network nodes amongst them there is 
   mutual trust. If a node receives a call signaling request from an 
   upstream node it does not trust, it SHOULD remove these parameters. 
   This will generally cause it to redo any DB queries. 
    
  
Yu                     Expires  February 27, 2007             [Page 12] 


Internet-Draft       NP Parameters for the "tel" URI        August 2006   
                      
 
   To verify that an upstream neighbor is trusted, and to prevent man-
   in-the-middle attacks whereby an attacker inserts or modifies these 
   parameters, call signaling protocols carrying these parameters 
   SHOULD provide hop-by-hop message integrity. In the case of SIP, 
   this is accomplished with the SIPS URI mechanism. 
    
8. IANA Considerations 
    
   This document defines five parameters for the "tel" URI.  Further 
   information on a registry for those parameters is covered in 
   [TELREG].  This document requires no IANA actions. 
    
9. References 
    
9.1 Normative References 
    
   [E164]    ITU-T Recommendation E.164, "The international public 
             telecommunication numbering plan," May 1997. 
    
   [RFC2119] S. Bradner, RFC2119, "Key words for use in RFCs to 
             Indicate Requirement Levels," March 1997. 
    
   [RFC3966] H. Schulzrinne, RFC3966, "The tel URI for Telephone 
             Numbers," December 2004. 
    
   [RFC4234] D. Crocker and P. Overell, RFC4234, "Augmented BNF for 
             Syntax Specifications: ABNF," October 2005. 
    
9.2 Informative References 
    
   [H323]    ITU-T Recommendation H.323, "Packet-Based Multimedia 
             Communications Systems," November 2000. 
    
   [RFC3261] J. Rosenberg, et al., RFC3261, "SIP: Session Initiation 
             Protocol," June 2002.  
    
   [RFC3482] M. Foster, T. McGarry and J. Yu, RFC3482, "Number 
             Portability in the GSTN: An Overview," February 2003. 
    
   [TELREG]  C. Jennings and V. Gurbani, "The Internet Assigned Number 
             Authority (IANA) tel Uniform Resource Identifier (URI) 
             Parameter Registry", draft-ietf-iptel-tel-reg-02.txt (work 
             in progress), May 2006. 
    
10. Acknowledgments 
    
   The author would like to thank Penn Pfautz, Jon Peterson, Jonathan 
   Rosenberg, Henning Schulzrinne, Antti Vaha-Sipila, Flemming 
   Andreasen and Mike Hammer for their discussions and comments. 
 
 
 
  
Yu                     Expires  February 27, 2007             [Page 13] 


Internet-Draft       NP Parameters for the "tel" URI        August 2006   
                      
 
Author's Address 
    
   James Yu 
   NeuStar, Inc. 
   46000 Center Oak Plaza 
   Sterling, VA 20166 
   U.S.A. 
   Phone: +1-571-434-5572 
   Email: james.yu@neustar.biz 
 
Intellectual Property Statement 
 
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology described 
   in this document or the extent to which any license under such 
   rights might or might not be available; nor does it represent that 
   it has made any independent effort to identify any such rights.  
   Information on the procedures with respect to rights in RFC 
   documents can be found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use 
   of such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at  
   ietf-ipr@ietf.org. 
 
Disclaimer of Validity 
 
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology described 
   in this document or the extent to which any license under such 
   rights might or might not be available; nor does it represent that 
   it has made any independent effort to identify any such rights.  
   Information on the procedures with respect to rights in RFC 
   documents can be found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 

  
Yu                     Expires  February 27, 2007             [Page 14] 


Internet-Draft       NP Parameters for the "tel" URI        August 2006   
                      
 
   attempt made to obtain a general license or permission for the use 
   of such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org. 
 
Copyright Statement 
 
   Copyright (C) The Internet Society (2006).  This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights. 
 
   This document and the information contained herein are provided on 
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
 
Acknowledgment 
 
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 
 
 

  
Yu                     Expires  February 27, 2007             [Page 15]