One document matched: draft-yu-tel-dai-00.txt
IPTEL Working Group J. Yu
Internet Draft NeuStar
Document: draft-yu-tel-dai-00.txt D. Hancock
Category: Standards Track Cable Labs
F. Andreasen
Cisco
October 9, 2006
DAI Parameter 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 April 8, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
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
and indicates how the carrier identified in the "cic" parameter is
chosen to handle the call.
Yu, et al. Expires April 8, 2007 [Page 1]
Internet-Draft DAI Parameter for the "tel" URI October 2006
Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Abbreviation . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 3
5. Normative Rules . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Adding the "dai" Parameter to the "tel" URI . . . . . . . 5
5.2. Handling the "tel" URI with the "cic", or "cic" and "dai" 10
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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
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.
Yu, et al. Expires April 8, 2007 [Page 2]
Internet-Draft DAI Parameter for the "tel" URI October 2006
The long distance carrier information, the Carrier Identification
Code (CIC), can be carried in the "cic" parameter [TELNP], a
parameter of the "tel" Uniform Resource Identifier (URI) [RFC3761].
The "cic" parameter defined in [TELNP] identifies the freephone
service provider that serves the freephone number. As described in
[TELNP], 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
assigned the CIC receives the call, the "dai" parameter defined in
this document indicates to that carrier how it was chosen to handle
the call.
3. 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
4. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) as described in RFC 4234 [RFC4234] and defines the "dai"
parameter by extending the "parameter" production rule of the "tel"
URI defined in [RFC3966].
Parameter =/ dai
dai = ";dai="
"presub" /
"presub-da" /
"presub-daUnkwn" /
"no-presub" /
"CIC-chrgPty" /
"altCIC-chrgPty" /
"verbal-clgPty" /
"verbal-chrgPty" /
"emergency"
The "dai" parameter can appear in the "tel" URI at most once.
Absence of the "dai" parameter indicates that there is no dial-
Yu, et al. Expires April 8, 2007 [Page 3]
Internet-Draft DAI Parameter for the "tel" URI October 2006
around indication available. The "dai" parameter MUST NOT be
present if the "cic" parameter is not present. Please see [TELNP]
for the syntax specification of the "cic" parameter.
Below are the descriptions of the values of the "dai" parameter.
"presub" indicates "presubscribed; no caller input".
"presub-da" indicates "presubscribed; caller input".
"presub-daUnkwn" indicates "presubscribed; input by caller
undetermined".
"no-presub" indicates "no presubscription; caller input".
"CIC-chrgPty" indicates "primary preferred carrier of charged
party".
"altCIC-chrgPty" indicates "alternate preferred carrier of charged
party".
"verbal-clgPty" indicates "selected carrier identification
presubscription unknown (verbal) instructions from calling party".
"verbal-chrgPty" indicates "selected carrier identification
presubscription unknown (verbal) from charged party".
"emergency" indicates "emergency call handling".
5. 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 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 [RFC3261] URI. 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.
Figure 1 is used to help describing the rules. 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 PSTN.
"User Device" generates the signaling message requesting a call
setup.
"Network Node A" receives the call request and is the one that 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
Yu, et al. Expires April 8, 2007 [Page 4]
Internet-Draft DAI Parameter for the "tel" URI October 2006
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.
+-------------------------------+
| |
+---------+ +---------+ +---------+ +---------+
| Network | | Network | | Network | | User |
| Node C |-----| Node B |-----| Node A |------| Device |
+---------+ +---------+ +---------+ +---------+
| | |
| | |
| | +---------+ +---------+
| +----------| GSTN | | GSTN |
+--------------------------| GW |------| SW |
+---------+ +---------+
Figure 1. Network Model.
"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" receives 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 network. 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.
5.1 Adding the "dai" Parameter to the "tel" URI
This section discusses the cases when "Network Node A" receives a
call request from "User Device" and may need to add the "dai"
parameter to the "tel" URI.
Yu, et al. Expires April 8, 2007 [Page 5]
Internet-Draft DAI Parameter for the "tel" URI October 2006
A. CIC Information provided in call signaling from "User Device"
"User Device" can provide the CIC information via call signaling
in two ways.
a.
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.
"User Device" SHOULD NOT include the "dai" parameter in the
"tel" URI. When included by the "User Device", "Network Node A"
SHALL ignore the "dai" parameter.
b.
Include the selected CIC information in the dialed string
(e.g., "101XXXX" followed by a national number). [String]
specifies one way to deliver the dialed string in the SIP
protocol [RFC3261]. It is outside the scope of this document as
to how the dialed string is carried in the signaling message and
how "Network Node A" knows how to identify the caller selected
CIC information when applicable and the called phone number from
the received dialed string.
When receiving a call request containing the "cic" parameter or
the CIC information in the signaling message from "User Device"
and an operator is not involved in call handling, "Network Node A"
MUST follow the rules described below. The cases when an operator
is involved in determining/selecting a carrier to handle the call
is addressed in C and D below.
- 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.
- If "Network Node A" selects a carrier other than the caller’s
pre-subscribed carrier or the one specified by "User Device" to
handle the call (e.g., does not allow the caller to specify the
carrier to handle the call), "Network Node A" MUST set the "cic"
parameter to contain the CIC it selects and include the "cic"
parameter, if not yet present, in the "tel" URI. "Network Node
A" MUST NOT include the "dai" parameter in the "tel" URI.
- 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", "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.
But if "Network Node A" is not sure whether the CIC information
is provided by "User Device" (e.g., a proxy server between "User
Yu, et al. Expires April 8, 2007 [Page 6]
Internet-Draft DAI Parameter for the "tel" URI October 2006
Device" and "Network Node A" is involved), it MUST set the "dai"
parameter to "presub-daUnkwn" in the process described above.
- 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 "no-presub" and
include the parameter in the "tel" URI.
B. CIC Information not provided in call signaling
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 when an operator is involved in determining/
selecting a carrier to handle the call is addressed in C and D
below.
- 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.
- 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 NOT
include the "dai" parameter in the "tel" URI.
- 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.
C. 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.
Yu, et al. Expires April 8, 2007 [Page 7]
Internet-Draft DAI Parameter for the "tel" URI October 2006
- 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.
- 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 NOT include the "dai" parameter in the "tel" URI.
- 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.
But 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.
- If the carrier specified by "User Device" in call signaling or
by caller via the interaction with the operator is different
from the caller's pre-subscribed carrier, "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
"no-presub" and include the parameter in the "tel" URI.
- If the operator receives verbal instructions from the caller to
use a specific carrier and it is not unknown 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.
D. 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
Yu, et al. Expires April 8, 2007 [Page 8]
Internet-Draft DAI Parameter for the "tel" URI October 2006
information from the charged party or retrieve the primary and
alternate preferred carrier 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 are ignored if they are present.
"Network Node A" through the assistance of an operator MUST follow
the rules described below.
- 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.
- 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
NOT include the "dai" parameter in the "tel" URI.
- If "Network Node A" receives the CIC from the charged party
verbally and that carrier can handle the call, it MUST set the
"cic" parameter to contain that CIC 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.
- 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" MSUT 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.
- 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" MSUT 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.
- If the operator receives verbal instructions from the charged
party to use a specific carrier and it is not unknown 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.
- If the caller contacts an operator for an emergency situation
and a carrier that "Network Node A" is not associated with needs
Yu, et al. Expires April 8, 2007 [Page 9]
Internet-Draft DAI Parameter for the "tel" URI October 2006
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.
E. 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 has the
"Carrier Selection Information" parameter that carries the CIC
information. There is a one-to-one mapping between the ANSI ISUP
"Carrier Selection Information" parameter and the "dai" parameter
with one exception - the "dai" parameter is not included in the
"tel" URI when the ISUP "Carrier Selection Information" parameter
is set to "0" (no indication).
5.2 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 "cic" parameter, or "dai" and "cic" parameters in the
"tel" URI.
A. 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 [TELNP] to "Network
Node B", "Network Node C" or "GSTN GW". "Network Node A" MAY
record the "dai" value in the call detail record. Absence of the
"dai" parameter indicates that no DAI is available.
B. 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 [TELNP] to another
"Network Node B", "Network Node C" or "GSTN GW". "Network Node B"
MAY record the "dai" value in the call detail record. Absence of
the "dai" parameter indicates that no DAI is available.
C. Network Node C
Since "Network Node C" is associated with the carrier identified
by the CIC in the "cic" parameter, it removes 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 call detail record. Absence of the "dai" parameter indicates
that no DAI is available. How "Network Node C" continues the
call routing/handling is outside the scope of this document.
Yu, et al. Expires April 8, 2007 [Page 10]
Internet-Draft DAI Parameter for the "tel" URI October 2006
D. GSTN GW
When "GSTN GW" determines that the call is to be routed to "GSTN
SW" and SS7 ISUP is used in the GSTN, it MUST map the "dai"
parameter to the corresponding ISUP parameter. In ANSI ISUP, the
"Carrier Selection Information" parameter is the one for mapping.
There is a one-to-one mapping between the ANSI ISUP "Carrier
Selection Information" parameter and the "dai" parameter with one
exception - the "dai" parameter is not included in the "tel" URI
when the ANSI ISUP "Carrier Selection Information" parameter is
set to "0" (no indication). "GSTN GW" MAY record the "dai" value
in the call detail record. Absence of the "dai" parameter
indicates that no DAI is available.
E. 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).
6. Examples
A. 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 below.
tel:+1-202-533-1234;cic=+1-6789;dai=presub
B. 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.
"Network Node A" recognizes that the caller has selected a non-
presubscribed carrier to handle the call. It includes the "dai"
and "cic" parameters to the "tel" URI as shown below.
tel:+1-202-533-1234;cic=+1-2345;dai=no-presub
C. 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 shown below.
tel:+1-202-533-1234;cic=+1-3456;dai=verbal-chrgPty
Yu, et al. Expires April 8, 2007 [Page 11]
Internet-Draft DAI Parameter for the "tel" URI October 2006
7. 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 "no-presub" 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 "no-presub" 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).
It is RECOMMENDED that protocols carrying the "tel" URI provide hop
by hop integrity for the URI including the parameters. This allows
detection of any unauthorized changes to the contents of the “tel”
URI.
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.
8. 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
9. References
9.1 Normative References
[RFC2026] S. Bradner, RFC2026, "The Internet Standards Process --
Revision 3", October 1996.
[RFC2119] S. Bradner, RFC2119, "Key words for use in RFCs to
Indicate Requirement Levels", March 1997.
Yu, et al. Expires April 8, 2007 [Page 12]
Internet-Draft DAI Parameter for the "tel" URI October 2006
[RFC3966] H. Schulzrinne, RFC3966, "The tel URI for Telephone
Numbers", December 2004.
[RDC4234] D. Crocker and P. Overell, RFC4234, "Augmented BNF for
Syntax Specifications: ABNF", October 2005.
[TELNP] J. Yu, ietf-draft-iptel-tel-np-11.txt, "NP Parameters for
the "tel" URI", August 2006 (Work in Progress; will become
a RFC soon).
9.2 Informative References
[RFC3261] J. Rosenberg, et al., RFC3261, "SIP: Session Initiation
Protocol," June 2002.
[RFC3761] P. Faltstrom and M. Mealling, RFC3761, "The E.164 to
Uniform Resource Identifiers (URI) - Dynamic Delegation
Discovery System (DDDS) Application (ENUM)", April 2004.
[String] B. Rosen, draft-rosen-iptel-dialstring-04.txt, "Dialstring
parameter for the Session Initiation Protocol Uniform
Resource Identifier", June 2006 (Work in Progress).
10. Acknowledgments
The author 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
Cable Labs
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
Yu, et al. Expires April 8, 2007 [Page 13]
Internet-Draft DAI Parameter for the "tel" URI October 2006
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
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
Yu, et al. Expires April 8, 2007 [Page 14]
Internet-Draft DAI Parameter for the "tel" URI October 2006
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, et al. Expires April 8, 2007 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-24 03:14:15 |