IPTEL Working Group                                                J.Yu
Internet Draft                                                  NueStar
Intended status: Standards track                             D. Hancock
Expires: December 9, 2009                                     CableLabs
                                                           F. Andreasen
                                                                  Cisco

                                                          July 10, 2009

                  DAI Parameter for the "tel" URI
                        draft-yu-tel-dai-07


Status of this Memo
   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 December 9, 2009.

Abstract
   This document defines a "dai" parameter for the "tel" Uniform
   Resource Identifier (URI) to support the Dial Around Indicator (DAI).
   The "dai" parameter is associated with the "cic" parameter, defined
   in [RFC4694], and indicates how the carrier identified in the "cic"
   parameter was selected.  This document also expands the use of the
   "cic" parameter to support pre-subscribed and dialed long-distance
   carrier requirements.

Conventions used in this document
   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].



Yu et al               Expires January 10, 2010                [Page 1]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009

Table of Contents

   1. Introduction...................................................2
   2. Abbreviations..................................................3
   3. Formal Syntax..................................................3
   4. Normative Rules................................................4
   5. Examples......................................................14
   6. Security Considerations.......................................15
   7. IANA Considerations...........................................16
   8. References....................................................16
   9. Change History................................................16

1. Introduction

   Before equal access was supported in the United States, only AT&T's
   subscribers could dial "1" to reach AT&T when they made long distance
   calls.  Other long distance carriers' subscribers needed to dial
   extra digits to reach their long distance carriers.  For the fair
   competition, the Federal Communication Commission in the U.S.
   mandated the support for equal access that allowed any long distance
   carrier's subscriber to follow the same dialing plan to reach his/her
   pre-subscribed long distance carrier.  The regulatory bodies in many
   other countries also have mandated equal access.

   To allow a telephony subscriber to use a non-pre-subscribed long
   distance carrier for some of their long distance calls, the U.S. has
   implemented the dialing prefix "10XXX" that was later expanded to
   "101XXXX" in the dialing plan.  The prefix allows the caller to use
   "XXX" or "XXXX" to specify the long distance carrier to handle that
   particular call.  This dialing prefix was also used to identify the
   local toll carrier in the United States when equal access also
   applied to the local toll calls.

   One of the purposes of the DAI is to indicate to the long distance
   carrier that receives a call from the local exchange carrier whether
   the call came from a pre-subscribed customer or not.   Due to
   operator-assisted calls, where the called party or a third party may
   be charged for the call in some cases, the DAI is also used to
   indicate to the receiving long distance carrier if it is the primary
   or alternate preferred long distance carrier of the charged party.

   The long distance carrier information, the Carrier Identification
   Code (CIC), can be carried in the "cic" parameter [RFC4694], a
   parameter of the "tel" Uniform Resource Identifier (URI) [RFC3966].
   The "cic" parameter defined in [RFC4694] identifies the freephone
   service provider that serves the freephone number.  As described in
   [RFC4694], it can also be used to carry the CIC associated with the
   carrier who is to handle a call to a geographic telephone number;
   such usage is leveraged in this document.  When the carrier that is


Yu et al               Expires December 9, 2009                [Page 2]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009
   assigned the CIC receives the call, the "dai" parameter defined in
   this document indicates to that carrier how it was selected.

2. Abbreviations

   ANSI American National Standards Institute
   BNF  Backus-Naur Form
   CIC  Carrier Identification Code (also cic)
   DAI  Dial Around Indicator (also dai)
   FCC  Federal Communications Commission
   ENUM Telephone Number Mapping
   GSTN Global Switched Telephone Network
   GW   Gateway
   IETF Internet Engineering Task Force
   IP   Internet Protocol
   ISUP Integrated Services Digital Network User Part
   SS7  Signaling System number 7
   SW   Switch
   URI  Uniform Resource Identifier

3. Formal Syntax

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) as described in RFC 5234 [RFC5234] and defines the "dai"
   pname and associated pvalues as an instantiation of the "parameter"
   production rule of the "tel" URI defined in [RFC3966].


         dai        = ";dai="  dai_value
         dai-value  = "no-ind"           /
                      "presub"           /
                      "presub-da"        /
                      "presub-daUnkwn"   /
                      "da"               /
                      "CIC-chrgPty"      /
                      "altCIC-chrgPty"   /
                      "verbal-clgPty"    /
                      "verbal-chrgPty"   /
                      "emergency"        /
                      "presubUnkwn-da"   /
                      "operator"         /
                      pvalue

   The "dai" parameter can appear in the "tel" URI at most once.  The
   "dai" parameter MUST NOT be present if the "cic" parameter is not
   present.  When the "cic" parameter is present due to carrier
   selection (whether presubscribed or not), the "dai" parameter MUST be
   present so that its presence in the tel URI can differentiate the
   carrier selection case from the freephone case.  Please see [RFC4694]
   for the syntax specification of the "cic" parameter.


Yu et al               Expires December 9, 2009                [Page 3]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009

   Below are the descriptions of the values of the "dai" parameter.

   "no-ind": indicates that it is not known how the carrier identified
   in the CIC was selected.

   "presub": indicates that the CIC contains the caller's presubscribed
   carrier; the caller did not dial a Carrier Identification Code.

   "presub-da": indicates that the CIC contains the caller's dialed
   Carrier Identification Code; the selected carrier is the caller's
   presubscribed carrier.

   "presub-daUnkwn": indicates that the CIC contains the caller's
   presubscribed carrier; no information is provided on whether or not
   the caller dialed a Carrier Identification Code.

   "da": indicates that the CIC contains the caller's dialed carrier-
   identification-code; the selected carrier is not the caller's
   presubscribed carrier.

   "CIC-chrgPty": indicates that the CIC contains the preferred carrier
   of the charged party.

   "altCIC-chrgPty": indicates that the CIC contains the alternate
   carrier of the charged party.

   "verbal-clgPty": indicates that the CIC contains the carrier
   delivered verbally by the calling party.

   "verbal-chrgPty": indicates that the CIC contains the carrier
   delivered verbally by the charged party.

   "emergency": indicates that the CIC is selected for emergency call
   handling.

   "presubUnkwn-da": indicates that the CIC contains the caller's dialed
   carrier-identification-code;  no information is provided on whether
   or not the selected carrier is the caller's presubscribed carrier.

   "operator": indicates that the CIC contains a carrier selected by a
   network operator.

4. Normative Rules

   This section discusses how a network node adds the "dai" parameter to
   the "tel" URI or handles a received "tel" URI that contains the "dai"
   parameter.  Since the "dai" parameter goes with the "cic" parameter,
   the latter is included in some of the discussions below.  The phone



Yu et al               Expires December 9, 2009                [Page 4]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009
   numbers of the caller and called party are geographic numbers in the
   discussions.

   When the call signaling message contains a "tel" URI that carries the
   "cic" parameter, ENUM [RFC3761] could map the phone number in the
   "tel" URI to other URI(s) such as SIP URI [RFC3261].  In that case,
   the mapped URI instead of the parameters in the "tel" URI MAY be used
   to route the call.  In this document it is assumed that ENUM is not
   involved.

4.1. Network Model

   The network model in Figure 1 is used to help describe the rules for
   sending and receiving the "dai" parameter. The discussion below
   focuses on the handling of the "tel" URI in the signaling messages.
   It is assumed that the signaling message will contain the "cic" and
   "dai" parameters after it leaves "Network Node A" for a call
   originated by the user or after it leaves "GSTN GW" when the call
   comes from the GSTN (Global Switched Telephone Network).

                +-------------------------------+
                |                               |
           +---------+     +---------+     +---------+      +---------+
           | Network |     | Network |     | Network |      |  User   |
           | Node C  |-----| Node B  |-----| Node A  |------| Device  |
           +---------+     +---------+     +---------+      +---------+
                |               |               |
                |               |               |
                |               |          +---------+      +---------+
                |               +----------|  GSTN   |      |  GSTN   |
                +--------------------------|   GW    |------|   SW    |
                                           +---------+      +---------+


                          Figure 1.  Network Model

   "User Device" generates the signaling message requesting a call
   setup.

   "Network Node A" represents those network nodes that receive the call
   request and can analyze the type of call (e.g., local toll, long
   distance or international based on the calling party number/address
   and called party number) and determine or identify the carrier that
   is to handle the call.  The latter can be based on the information
   from the caller (e.g., "101XXXX"), the presubscribed carrier
   information in the service profile of the caller, or via the
   involvement of an operator that interacts with the calling party,
   called party (e.g., for collect call) or a third party (e.g., when
   the call is charged to a third party) for an operator-assisted call.
   If configured by the network operator, Node A can apply a preferred


Yu et al               Expires December 9, 2009                [Page 5]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009
   CIC for all calls where carrier selection is needed.   Note that
   although Figure 1 shows Node A as a single entity, its
   responsibilities can be shared amongst multiple Node As such that the
   Node A that is connected to or communicates with the user device is
   separate from the Node A that determines or identifies the carrier to
   handle the call.

   "Network Node B" represents those network nodes that are not
   associated with the carrier identified in the "cic" parameter and
   need to route the signaling message that contains the "cic" and "dai"
   parameters towards the carrier identified in the "cic" parameter.

   "Network Node C" represents those network nodes that receive the
   signaling message from "Network Node B" and belongs to the carrier
   identified in the "cic" parameter.

   "GSTN GW" stands for "Global Switched Telephone Network (GSTN)
   Gateway (GW)".  It interfaces between the Internet Protocol (IP)
   domain and the GSTN domain for signaling protocols and the user
   traffic.  The GSTN includes the wireline network, wireless network
   and other circuit-switched networks.  Signaling traffic and user
   traffic could be handled by separate network nodes.   In this
   document, both types of traffic are handled by "GSTN GW" to simplify
   the discussion.

   "GSTN Switch (SW)" is a circuit switch in the GSTN that is connected
   with the GSTN GW.

   "User Device", "Network Node A", "Network Node B" and "Network Node
   C" are in the IP domain.  "Network Node A", "Network Node B" and
   "Network Node C" can route the calls to the GSTN via the GSTN GW.

   The rules for various scenarios are described below.

4.2. Adding the "dai" Parameter to the "tel" URI

   This section discusses those cases where "Network Node A" receives a
   call request containing a "tel URI" from "User Device" and may need
   to add the "dai" parameter to the "tel" URI.  If the "cic" Parameter
   is included in the received "tel URI" but the "dai" Parameter is not
   included, and "Network Node A" does not know how the carrier is
   selected or does not want to reveal how the carrier is selected
   (based on local policy), "Network Node A" MUST include the "dai"
   Parameter and set it to "no-ind".

   DAI information has potential billing impacts, and it is therefore
   important that it is trustworthy. "Network Node A" may have a trust
   relationship with "User Device" whereby it trusts the information
   provided by "User Device". In such cases, "Network Node A" may use
   the DAI information provided by "User Device". In all other cases,


Yu et al               Expires December 9, 2009                [Page 6]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009
   "Network Node A" MUST remove any DAI information provided by "User
   Device" before further processing. Furthermore, the signaling message
   including the "tel URI" SHOULD be hop-by-hop integrity-protected,
   e.g. by the use of TLS in the case of SIP. If it is not, the
   parameters provided cannot be trusted.

4.2.1. CIC Information Provided in Call Signaling from "User Device"

   When an originating user dials the carrier prefix digits to select a
   carrier at call setup time, "User Device" MUST signal the CIC
   information to "Network Node A". "User Device" can provide the CIC
   information via call signaling in one of two ways.

   1. Include the "cic" parameter in the "tel" URI to carry the selected
      CIC.  It is outside the scope of this document as to how "User
      Device" adds the "cic" parameter to the "tel" URI.

   2. Include the selected CIC information in the dialed string (e.g.,
      "101XXXX" followed by a national number).  [RFC4967] specifies one
      way to deliver the dialed string in the SIP protocol [RFC3261].
      How the dialed string is carried in the signaling message to
      "Network Node A", and how "Network Node A" identifies the CIC
      information and the called phone number from the received dialed
      string is outside the scope of this document. "Network Node A"
      MUST convert the received dial string to a valid "tel" URI
      containing a "cic" parameter (by means outside the scope of this
      document), and continue processing as if the "tel" URI had been
      received from the "User Device".

   When receiving a call request that contains the "tel" URI "cic"
   parameter but not the "dai" parameter (or on converting a received
   dialed string to a "tel" URI containing a "cic" parameter), and an
   operator is not involved in call handling, "Network Node A" MUST
   follow the rules described below.  The cases where an operator is
   involved in determining/selecting a carrier to handle the call are
   addressed in 4.2.3 and 4.2.4 below.

   o  If the call is to be handled by the carrier "Network Node A" is
      associated with (that is, the carrier network is the network
      within which Node A resides), "Network Node A" MUST remove the
      "cic" parameter in the "tel" URI, and MUST NOT include the "dai"
      parameter if it needs to forward the signaling message to another
      network node.









Yu et al               Expires December 9, 2009                [Page 7]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009
   o  If "Network Node A" selects a carrier for the call (e.g., because
      local policy does not allow the caller to specify a carrier), and
      the selected carrier is different than the caller's pre-subscribed
      carrier, or the caller does not have a pre-subscribed carrier,
      then "Network Node A" MUST update the received "cic" parameter to
      identify the selected carrier.  In addition, "Network Node A" MUST
      add a "dai" parameter containing the value "operator" to the "tel"
      URI.

   o  If the "User Device" specified carrier is the same as the caller's
      pre-subscribed carrier and "Network Node A" knows that the CIC
      information is provided by "User Device", and "Network Node A"
      chooses (based on local policy) to reveal that the presubscribed
      carrier was selected by the user, then "Network Node A" MUST set
      the "dai" parameter to "presub-da" and include the parameter in
      the "tel" URI.

   o  If "Network Node A" is not sure whether the CIC information is
      provided by "User Device" (e.g., a proxy server between "User
      Device" and "Network Node A" is involved), and the specified
      carrier is the same as the caller's pre-subscribed carrier, then
      "Network Node A" MUST set the "cic" parameter to contain the
      caller's pre-subscribed carrier's CIC and include the parameter,
      if not yet present, in the "tel" URI. "Network Node A" MUST set
      the "dai" parameter to "presub-daUnkwn" and include the parameter
      in the "tel" URI.

   o  If the "User Device" specified carrier is different from the
      caller's pre-subscribed carrier, "Network Node A" MUST set the
      "cic" parameter to contain the "User Device" specified carrier and
      include the parameter, if not yet present, in the "tel" URI.
      "Network Node A" MUST set the "dai" parameter to "da" and include
      the parameter in the "tel" URI.

   o  If the "User Device" specifies a carrier and "Network Node A"
      cannot determine if the selected carrier is the caller's
      presubscribed carrier, or "Network Node A" chooses (based on local
      policy) not to reveal whether the selected carrier is the
      presubscribed carrier, or there is no presubscribed carrier
      assigned to the caller, then "Network Node A" MUST set the "cic"
      parameter to contain the "User Device" specified carrier and
      include the parameter, if not yet present, in the "tel" URI.
      "Network Node A" MUST set the "dai" parameter to "presubUnkwn-da"
      and include the parameter in the "tel" URI.


4.2.2. CIC Information Not Provided in Call Signaling From "User
Device"




Yu et al               Expires December 9, 2009                [Page 8]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009
   In this scenario, "User Device" did not provide any CIC information
   in call signaling and an operator is not involved in call handling.
   "Network Node A" MUST follow the rules described below.  The cases
   where an operator is involved in determining/selecting a carrier to
   handle the call are addressed in 4.2.3 and 4.2.4 below.

   o  If the call is to be handled by the carrier "Network Node A" is
      associated with, "Network Node A" MUST NOT include the "cic" and
      "dai" parameters in the "tel" URI if it needs to forward the
      signaling message to another network node.

   o  If "Network Node A" selects a carrier that is different from the
      caller's pre-subscribed carrier to handle the call, it MUST set
      the "cic" parameter to contain the CIC it selects and include the
      parameter in the "tel" URI.  "Network Node A" MUST include the
      "dai" parameter in the "tel" URI and set it to "operator".

   o  If the caller has a pre-subscribed carrier that can handle the
      call, "Network Node A" MUST set the "cic" parameter to contain the
      caller's pre-subscribed carrier's CIC and include the parameter in
      the "tel" URI.  "Network Node A" MUST set the "dai" parameter to
      "presub" and include the parameter in the "tel" URI.


4.2.3. Operator-assisted Call Handling, Caller Pays for the Call

   When an operator is involved in handling the call request from the
   caller, "Network Node A" may or may not have the CIC information
   available from the signaling message.  If the caller is to pay for
   the call, the operator may interact with the caller to determine the
   carrier to handle the call when applicable.  If the CIC information
   is available from call signaling and the operator also interacts with
   the caller to get the CIC information, the CIC provided by the
   operator MUST be used.  How the caller indicates an operator-assisted
   call and passes the CIC information in call signaling is outside the
   scope of this document.

   "Network Node A" through the assistance of an operator MUST follow
   the rules described below.

   o  If the call is to be handled by the carrier "Network Node A" is
      associated with, "Network Node A" MUST remove the "cic" parameter,
      if present in the "tel" URI, and MUST NOT include the "dai"
      parameter if it needs to forward the signaling message to another
      network node.







Yu et al               Expires December 9, 2009                [Page 9]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009
   o  If "Network Node A" selects a carrier other than the caller's pre-
      subscribed carrier or the one specified by "User Device" or
      indicated by the caller during the interaction with the operator
      to handle the call, "Network Node A" MUST set the "cic" parameter
      to contain the CIC it selects and include the parameter, if not
      yet present, in the "tel" URI.  "Network Node A" MUST include the
      "dai" parameter in the "tel" URI and set it to "operator".

   o  If the carrier specified by "User Device" in call signaling or by
      the caller via the interaction with the operator or selected by
      "Network Node A" is the same as the caller's pre-subscribed
      carrier, "Network Node A" MUST set the "cic" parameter to contain
      the caller's pre-subscribed carrier's CIC and include the
      parameter, if not yet present, in the "tel" URI.  "Network Node A"
      MUST set the "dai" parameter to "presub-da" and include the
      parameter in the "tel" URI.

   o  If "Network Node A" is not sure whether the CIC information is
      provided by "User Device" or the operator did not indicate if the
      CIC information came from the caller, it MUST set the "dai"
      parameter to "presub-daUnkwn" in the process described above.

   o  If the carrier specified by "User Device" in call signaling is
      different from the caller's pre-subscribed carrier, and that
      carrier is being used, "Network Node A" MUST set the "cic"
      parameter to contain the CIC of the selected carrier and include
      the parameter, if not yet present, in the "tel" URI.  "Network
      Node A" MUST set the "dai" parameter to "da" and include the
      parameter in the "tel" URI.

   o  If the operator receives verbal instructions from the caller to
      use a specific carrier and it is not known if that carrier is the
      caller's presubscribed carrier, "Network Node A" MUST set the
      "cic" parameter to contain the CIC of the specified carrier and
      include the parameter, if not yet present, in the "tel" URI.
      "Network Node A" MUST set the "dai" parameter to "verbal-clgPty"
      and include the parameter in the "tel" URI.


4.2.4. Operator-assisted Call Handling, Caller Does Not Pay for the
Call

   There are cases where the call is charged to the called party or a
   third party.   How the caller indicates an operator-assisted call and
   passes the CIC information in call signaling is outside the scope of
   this document. The caller will indicate to the operator that either
   the called party or a third party is to pay for the call.   The
   operator then checks with the charged party if he/she agrees to pay
   for the call and may verbally get the CIC information from the
   charged party or retrieve the primary and alternate preferred carrier


Yu et al               Expires December 9, 2009               [Page 10]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009
   information from some databases.  It is assumed that the "tel" URI in
   the call signaling from "User Device" does not contain the "cic"
   parameter and/or "dai" parameter: They MUST be ignored if they are
   present.

   "Network Node A" through the assistance of an operator MUST follow
   the rules described below.

   o  If the call is to be handled by the carrier "Network Node A" is
      associated with, "Network Node A" MUST remove the "cic" parameter,
      if present, and MUST NOT include the "dai" parameter in the "tel"
      URI.

   o  If "Network Node A" selects the carrier to handle the call, it
      MUST set the "cic" parameter to contain the CIC it selects and
      include the parameter in the "tel" URI.  "Network Node A" MUST
      include the "dai" parameter in the "tel" URI and set it to
      "operator".

   o  If the charged party's primary preferred carrier is used for the
      call handling, "Network Node A" MUST set the "cic" parameter to
      contain that carrier's CIC and include the parameter in the "tel"
      URI.  "Network Node A" MUST set the "dai" parameter to "CIC-
      chrgPty" and include the parameter in the "tel" URI.  How "Network
      Node A" knows that the selected carrier is the charged party's
      primary preferred carrier is outside the scope of this document.

   o  If the charged party's alternate preferred carrier is used for the
      call handling, "Network Node A" MUST set the "cic" parameter to
      contain that carrier's CIC and include the parameter in the "tel"
      URI.  "Network Node A" MUST set the "dai" parameter to "altCIC-
      chrgPty" and include the parameter in the "tel" URI.  How "Network
      Node A" knows that the selected carrier is the charged party's
      alternate preferred carrier is outside the scope of this document.

   o  If the operator receives verbal instructions from the charged
      party to use a specific carrier and it is not known if that
      carrier is the charged party's primary or alternate preferred
      carrier, "Network Node A" MUST set the "cic" parameter to contain
      the CIC of the specified carrier and include the parameter in the
      "tel" URI.  "Network Node A" MUST set the "dai" parameter to
      "verbal-chrgPty" and include the parameter in the "tel" URI.

   o  If the caller contacts an operator for an emergency situation and
      a carrier that "Network Node A" is not associated with needs to
      handle the call, "Network Node A" MUST set the "cic" parameter to
      the CIC of that carrier and include the parameter in the "tel"
      URI.  "Network Node A" MUST set the "dai" parameter to "emergency"
      and include the parameter in the "tel" URI.



Yu et al               Expires December 9, 2009               [Page 11]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009
4.2.5. Call Signaling Received From the GSTN SW by GSTN GW

   The GSTN GW may receive the Signaling System number 7 (SS7)
   Integrated Services Digital Network User Part (ISUP) signaling
   message from the GSTN SW that contains the CIC information.  For
   example, American National Standards Institute (ANSI) ISUP carries
   the CIC information in the "Carrier Selection Information" parameter.
   There is a one-to-one mapping between the ANSI ISUP "Carrier
   Selection Information" parameter and the "dai" parameter.

4.2.6. CIC and DAI Information is Provided in Call Signaling From
"User Device"

   This section describes the cases where the network operator
   configures the "User Device" to provide the user-dialed or pre-
   subscribed CIC, and the corresponding DAI information, to "Network
   Node A".  The mechanism to configure the "User Device" is outside the
   scope of this document.

   When the "User Device" is configured to provide the CIC and DAI
   information to "Network Node A", it MUST insert the "tel" URI "cic"
   and "dai" parameters in the call signaling toward "Network Node A" as
   follows:

   o  If the caller-dialed carrier is the same as the caller's pre-
      subscribed carrier, and the "User Device" inserts the "dai"
      parameter in call signaling, the "User Device" MUST set the "dai"
      parameter to "presub-da" and include the parameter in the "tel"
      URI.

   o  If the caller-dialed carrier is different from the caller's pre-
      subscribed carrier, and the "User Device" inserts the "dai"
      parameter in call signaling, the "User Device" MUST set the "dai"
      parameter to "da" and include the parameter in the "tel" URI.

   o  If the caller dials a carrier, and the "User Device" inserts the
      "dai" parameter in call signaling, and "User Device" cannot
      determine if the selected carrier is the caller's presubscribed
      carrier, then "User Device" MUST set the "dai" parameter to
      "presubUnkwn-da" and include the parameter in the "tel" URI.

   o  If the caller does not dial a carrier, and the "User Device"
      inserts the caller's pre-subscribed carrier information and the
      "dai" parameter in call signaling, then "User Device" MUST set the
      "dai" parameter to "presub" and include the parameter in the "tel"
      URI.

   When receiving a call request containing the "tel" URI "cic" and
   "dai" parameters from a "User Device" which is configured to send
   these parameters, and an operator is not involved in call handling,


Yu et al               Expires December 9, 2009               [Page 12]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009
   "Network Node A" MUST NOT alter "cic" and "dai" parameters in the
   "tel" URI.  The cases where an operator is involved in
   determining/selecting a carrier to handle the call are addressed in
   4.2.3 and 4.2.4.


4.3. Handling the "tel" URI With the "cic", or "cic" and "dai"

   This section discusses how "Network Node A", "Network Node B",
   "Network Node C" or "GSTN GW" handles the signaling messages that
   contain the "dai" and "cic" parameters in the "tel" URI. Scenarios
   that do not involve the "dai" parameter in the "tel" URI are outside
   the scope of this document.

   DAI information has potential billing impacts, and it is therefore
   important that it is trustworthy. It is assumed that all of the
   Network Nodes have a trust relationship with each other whereby they
   trust the DAI information provided. In all other cases, the Network
   Node MUST remove any DAI information provided before further
   processing. Furthermore, the signaling message including the "tel
   URI" SHOULD be hop-by-hop integrity-protected, e.g. by the use of TLS
   in the case of SIP. If it is not, the parameters provided cannot be
   trusted.

4.3.1. Network Node A

   After "Network Node A" has added the "dai" parameter and/or "cic"
   parameter to the "tel" URI and is ready to route the call, it MUST
   route the call based on the rules described in [RFC4694] to "Network
   Node B", "Network Node C" or "GSTN GW".  "Network Node A" MAY record
   the "dai" value in the call detail record. If the carrier that
   Network A is associated with is the one to handle the call, Network
   Node A MUST remove the "cic" and/or "dai" if they are present before
   routing the call.

4.3.2. Network Node B

   Since "Network Node B" is not associated with the carrier identified
   by the CIC in the "cic" parameter, it MUST route the call based on
   the "cic" parameter as stated in [RFC4694] to another "Network Node
   B", "Network Node C" or "GSTN GW".  "Network Node B" MAY record the
   "dai" value in the call detail record.

4.3.3. Network Node C

   Since "Network Node C" is associated with the carrier identified by
   the CIC in the "cic" parameter, it MUST remove the "cic" parameter
   and the "dai" parameter, if present, before it determines how to
   handle the call.   "Network Node C" MAY record the "dai" value in the



Yu et al               Expires December 9, 2009               [Page 13]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009
   call detail record.   How "Network Node C" continues the call
   routing/handling is outside the scope of this document.

4.3.4. GSTN GW

   If "GSTN GW" determines that the call is to be routed from the IP
   domain to "GSTN SW", and SS7 ISUP is used in the GSTN, then the "GSTN
   GW" MUST map the "dai" parameter to the corresponding ISUP parameter.
   Note that when interworking with ANSI ISUP, the "dai" parameter is
   mapped to the ISUP "Carrier Selection Information" parameter.  There
   is a one-to-one mapping between the ANSI ISUP "Carrier Selection
   Information" parameter and the "dai" parameter.

   When "GSTN GW" receives a signaling message from "GSTN SW" that
   contains the carrier selection information, it MUST set the "dai"
   parameter based on the received carrier selection information.  The
   mapping between the "dai" parameter and ISUP is outside the scope of
   this document.  "GSTN GW" MUST route the call based on the "cic"
   parameter as stated in [RFC4694] to "Network Node A", "Network Node
   B" or "Network Node C".  "GSTN GW" MAY record the "dai" value in the
   call detail record.

4.3.5. User Device

   "User Device" is not expected to receive signaling messages that
   contain the "dai" and/or "cic" parameters.  If the received signaling
   messages contain the "tel" URI with the "dai" and/or "cic"
   parameters, "User device" SHALL ignore the parameter(s).


5. Examples

   1. A caller whose pre-subscribed carrier has a CIC of "+1-6789" makes
      an outbound call with the following "tel" URI:

         tel:+1-202-533-1234

     "Network Node A" adds the "dai" and "cic" parameters to the "tel"
     URI as shown follows:

         tel:+1-202-533-1234;cic=+1-6789;dai=presub

   2. A caller whose pre-subscribed carrier has a CIC of "+1-6789" makes
      an outbound call to +1-202-533-1234 and specifies to use the CIC
      of "+1-2345" in call signaling with the following "tel" URI:

         tel:+1-202-533-1234;cic=+1-2345





Yu et al               Expires December 9, 2009               [Page 14]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009
     "Network Node A" recognizes that the caller has selected a non-
     presubscribed carrier to handle the call.  "Network Node A" adds
     the "dai" parameter to the "tel" URI as shown follows:

         tel:+1-202-533-1234;cic=+1-2345;dai=da

   3. A caller makes a collect call to +1-202-533-1234 through an
      operator.  The operator at "Network Node A" interacts with the
      called party and gets a verbal approval to use the CIC of "+1-
      3456".  "Network Node A" adds the "dai" and "cic" parameters to
      the "tel" URI as follows:

         tel:+1-202-533-1234;cic=+1-3456;dai=verbal-chrgPty


6. Security Considerations

   In addition to those security implications discussed in [RFC3966],
   there may be new security implications associated with the "dai"
   parameter depending on the carrier who uses the information.

   Changing the content of the "dai" parameter may cause a call to be
   rejected by or cause some problems (e.g., collecting call charge) to
   the carrier who handles the call.  For example, changing from
   "presub" to "da" may cause the call to be rejected if the carrier
   that is to handle the call only handles calls from its pre-subscribed
   subscribers.  Changing "da" to "presub" may cause a call that would
   be rejected to be processed by a carrier who later finds out it
   cannot collect the call charge from the caller or has to pay more
   than the call charge to collect the call charge from the caller via a
   third party (e.g., local exchange carrier).

   DAI information has potential billing impacts, and it is therefore
   important that it is trustworthy. "Network Node A" may have a trust
   relationship with "User Device" whereby it trusts the information
   provided by "User Device". In such cases, "Network Node A" may use
   the DAI information provided by "User Device". In all other cases,
   "Network Node A" MUST remove any DAI information provided by "User
   Device" before further processing.

   It is assumed that all of the Network Nodes have a trust relationship
   with each other whereby they trust the DAI information provided. In
   all other cases, the Network Node MUST remove any DAI information
   provided before further processing.

   It is RECOMMENDED that protocols carrying the "tel" URI provide hop
   by hop integrity protection for the signaling messages including the
   URI and its associated parameters.  This allows detection of any
   unauthorized changes to the contents of the "tel" URI. If integrity
   protection is not used, the parameters provided cannot be trusted.


Yu et al               Expires December 9, 2009               [Page 15]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009

   Please note that the information in the "dai" parameter may not be
   authenticated; therefore, the use of the information by the recipient
   of the "tel" URI is done at its own risk.

7. IANA Considerations

   The "dai" parameter defined in this document needs to be registered
   with IANA as a new parameter for the "tel" URI [RFC3966].

   1. Parameter name - dai
      Applicability - used to indicate how a carrier was chosen for
      handling a call
      Mandatory or optional - optional
      Restrictions on syntax - see Section 5
      Reference to a specification - defined in this document

8. References

8.1. Normative References

   [RFC2119] S. Bradner, RFC 2119, "Key words for use in RFCs to
   Indicate Requirement Levels", March 1997.


   [RFC3966] H. Schulzrinne, RFC 3966, "The tel URI for Telephone
   Numbers", December 2004.

   [RFC5234] D. Crocker and P. Overell, RFC 5234, "Augmented BNF for
   Syntax Specifications: ABNF", January 2008.

   [RFC4694] J. Yu, RFC 4694, "NP Parameters for the "tel" URI", October
   2006.

8.2. Informative References

   [RFC3261] J. Rosenberg, et al., RFC 3261, "SIP: Session Initiation
   Protocol", June 2002.

   [RFC3761] P. Faltstrom and M. Mealling, RFC 3761, "The E.164 to
   Uniform Resource Identifiers (URI) - Dynamic Delegation Discovery
   System (DDDS) Application (ENUM)", April 2004.

   [RFC4967] B. Rosen,RFC 4967, "Dial String Parameter for the Session
   Initiation Protocol Uniform Resource Identifier ", July 2007.

9. Change History
   (Note to editor - please remove this section in final version.)




Yu et al               Expires December 9, 2009               [Page 16]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009
9.1. Changes from version 01->02

   - Section 3: clarified descriptions of "dai" parameter values
   - Section 4.2.5, plus various other places: removed text that said
     the "dai" parameter was not included in certain cases, since we
     now use "no-ind" these cases.
   - Section 4.3,
        o Item A: added text specifying that if Node-A is the carrier
          then it removes "cic"
        o Item D: added procedures for inbound calls from GSTN

9.2. Changes from version 02->03

   - Section 4.2 is updated to indicate that the "User Device" may
     insert the "dai" parameter.
   - Section 4.2.6 is added to include procedures when the "User
     Device" inserts the "dai" parameter.

9.3. Changes from version 03->04

   - Added note to Section 4.2 (and similar note to other sections)
     describing the billing implications DAI, and the trust issues
     related to the network accepting it from the "User Device".

9.4. Changes from version 04->05

   - Clarified semantics of certain "dai" values in Section 3.


9.5. Changes from version 05->06

   - Clarified semantics of "presubUnkwn-da" in Section 3.
   - Section 4.2.1, 4th bullet, clarified that the "presub-daUnkwn" case
   applies when the received carrier matches the presubscribed carrier.
   Also added text to make 4th bullet stand-alone, instead of referring
   to previous bullet.
   - Fixed typos.

9.6. Changes from version 06->07
   Section 4.2.1
   - Updated point 2 to make result of the dialed-string case the same
   as receiving tel URI containing a "cic" parameter. Updated and
   simplified the following bullets to take advantage of this change,
   since they could be written assuming "cic" parameter was always
   present.
   - Updated 2nd bullet to add case where caller does not have a pre-
   subscribed carrier
   - Updated 3rd bullet to clarify that "presub-da" is driven by local
   policy setting to reveal that the presubscribed carrier was selected
   by the user


Yu et al               Expires December 9, 2009               [Page 17]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009
   - Updated 6th bullet to clarify that network-node-A sets the "DAI"
   parm to "presubUnkwn-da" based on local policy, or because there is
   no presubscribed carrier.


Acknowledgments

   The authors would like to thank Martin Dolly and Penn Pfautz for
   their assistances in providing the relevant information on the DAI.

Authors' Addresses

   James Yu
   NeuStar, Inc.
   46000 Center Oak Plaza
   Sterling, VA 20166
   U.S.A.
   Phone: +1-571-434-5572
   Email: james.yu@neustar.biz

   David Hancock
   CableLabs
   858 Coal Creek Circle
   Louisville, CO 80027-9750
   U.S.A.
   Phone: +1-303-661-3381
   Email: d.hancock@cablelabs.com

   Flemming Andreasen
   Cisco Systems, Inc.
   499 Thornall Street, 8th Floor
   Edison, NJ 08837
   U.S.A.
   Email: fandreas@cisco.com

Copyright Statement

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your
   rights and restrictions with respect to this document.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow


Yu et al               Expires December 9, 2009               [Page 18]


Internet-Draft        DAI Parameter for the "tel" URI       January 2009
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Acknowledgment

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








































Yu et al               Expires December 9, 2009               [Page 19]