GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4694

Network Working Group J. Yu Request for Comments: 4694 NeuStar Category: Standards Track October 2006

          Number Portability Parameters for the "tel" URI

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

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.

Table of Contents

 1. Introduction ....................................................2
 2. Conventions .....................................................3
 3. Abbreviations ...................................................3
 4. Formal Syntax ...................................................3
 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 ........................................13
 8. Acknowledgements ...............................................13
 9. IANA Considerations ............................................13

Yu Standards Track [Page 1] RFC 4694 NP Parameters for the "tel" URI October 2006

 10. References ....................................................14
    10.1. Normative References .....................................14
    10.2. Informative References ...................................14

1. 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 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 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" Uniform Resource
 Identifier (URI) [RFC3966] for protocols such as the Session
 Initiation Protocol (SIP) [RFC3261] 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.

Yu Standards Track [Page 2] RFC 4694 NP Parameters for the "tel" URI October 2006

 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.

2. 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 RFC 2119 [RFC2119].

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
 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].

Yu Standards Track [Page 3] RFC 4694 NP Parameters for the "tel" URI October 2006

 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.
 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.

Yu Standards Track [Page 4] RFC 4694 NP Parameters for the "tel" URI October 2006

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,
 among which 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 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.

Yu Standards Track [Page 5] RFC 4694 NP Parameters for the "tel" URI October 2006

 The first freephone database contains the CIC information for all the
 active freephone numbers, whereas 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 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 whether 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 [RFC3261] 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 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

Yu Standards Track [Page 6] RFC 4694 NP Parameters for the "tel" URI October 2006

 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:
  1. 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.
  1. 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 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.
  1. 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:
  1. 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 Standards Track [Page 7] RFC 4694 NP Parameters for the "tel" URI October 2006

  1. 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.
  1. 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.2.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:
  1. 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.

Yu Standards Track [Page 8] RFC 4694 NP Parameters for the "tel" URI October 2006

  1. 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.
 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:
  1. 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.
  1. 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.
  1. 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

Yu Standards Track [Page 9] RFC 4694 NP Parameters for the "tel" URI October 2006

   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.

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

Yu Standards Track [Page 10] RFC 4694 NP Parameters for the "tel" URI October 2006

 (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 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

Yu Standards Track [Page 11] RFC 4694 NP Parameters for the "tel" URI October 2006

 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
       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 will not 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".

Yu Standards Track [Page 12] RFC 4694 NP Parameters for the "tel" URI October 2006

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 among which there is mutual
 trust.  If a node receives a call signaling request from an upstream
 node that it does not trust, it SHOULD remove these parameters.  This
 will generally cause it to redo any DB queries.
 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 Session Initiation Protocol Secure (SIPS) URI
 mechanism.

8. Acknowledgements

 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.

9. 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.

Yu Standards Track [Page 13] RFC 4694 NP Parameters for the "tel" URI October 2006

10. References

10.1. Normative References

 [E164]    ITU-T Recommendation E.164, "The international public
           telecommunication numbering plan," May 1997.
 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
           3966, December 2004.
 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", RFC 4234, October 2005.

10.2. Informative References

 [H323]    ITU-T Recommendation H.323, "Packet-Based Multimedia
           Communications Systems," November 2000.
 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
           A., Peterson, J., Sparks, R., Handley, M., and E. Schooler,
           "SIP: Session Initiation Protocol", RFC 3261, June 2002.
 [RFC3482] Foster, M., McGarry, T., and J. Yu, "Number Portability in
           the Global Switched Telephone Network (GSTN): An Overview",
           RFC 3482, February 2003.
 [TELREG]  Jennings, C. and V. Gurbani, "The Internet Assigned Numbers
           Authority (IANA) tel Uniform Resource Identifier (URI)
           Parameter Registry", Work in Progress, May 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

Yu Standards Track [Page 14] RFC 4694 NP Parameters for the "tel" URI October 2006

Full 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.

Intellectual Property

 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.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Yu Standards Track [Page 15]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4694.txt · Last modified: 2006/10/26 20:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki