Network Working Group J. Haluska
Internet-Draft R. Berkowitz
Expires: December 18, 2006 P. Roder
Telcordia Technologies, Inc.
R. Ahern
BellSouth Corporation
P. Lum Lung
Qwest Communications International
June 16, 2006
Considerations for Directory Assistance Services Using SIP
draft-haluska-sipping-directory-assistance-00.txt
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 December 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Directory Assistance (DA) is a well known service in today's PSTN,
and is generally identified with "411" or "NPA-555-1212" type
services in North America. Today's DA services are already becoming
Haluska, et al. Expires December 18, 2006 [Page 1]
Internet-Draft Directory Assistance Using SIP June 2006
more advanced. Currently the DA service can complete the call for
the user, can send SMS with the listing to the user's wireless phone,
and can provide the user with a wide range of information, such as
movie listings and the weather.
Moving ahead, DA providers envision exciting multimedia services that
support simultaneous voice and data interactions with full operator
backup at any time during the call. For instance, a DA directions
service may announce and display directions to the requested listing,
with the option for the caller to request transfer to an operator
with the latest call context information.
DA providers are planning to migrate to SIP based platforms, which
will enable such advanced services, while continuing to support
traditional DA services.
Implementing DA services with SIP will require the exchange of
certain information which is not normally exchanged for other types
of calls. This document aims to identify such information, and
stimulate discussion about how this information could be exchanged.
Should it be decided that extensions to SIP are required, it is the
authors' intention to use the SIP change process documented in [BCP
67] to attain standardization.
Haluska, et al. Expires December 18, 2006 [Page 2]
Internet-Draft Directory Assistance Using SIP June 2006
1. Introduction
Directory Assistance (DA) is a well known service in today's PSTN,
and is generally identified with "411" or "NPA-555-1212" type
services in North America. Today's DA services are already becoming
more advanced. Currently the DA service can complete the call for
the user, can send SMS with the listing to the user's wireless phone,
and can provide the user with a wide range of information, such as
movie listings and the weather.
Moving ahead, DA providers envision exciting multimedia services that
support simultaneous voice and data interactions with full operator
backup at any time during the call. For instance, a DA directions
service may announce and display directions to the requested listing,
with the option for the caller to request transfer to an operator
with the latest call context information.
DA providers are planning to migrate to SIP [1] based platforms,
which will enable such advanced services, while continuing to support
traditional DA services.
Implementing DA services with SIP will require the exchange of
certain information which is not normally exchanged for other types
of calls. This document aims to identify such information, and
stimulate discussion about how this information could be exchanged.
Should it be decided that extensions to SIP are required, it is the
authors' intention to use the SIP change process documented in [BCP
67] to attain standardization.
Haluska, et al. Expires December 18, 2006 [Page 3]
Internet-Draft Directory Assistance Using SIP June 2006
2. Terminology
This section defines terms that will be used to discuss DA services.
Directory Assistance (DA) - a service whereby end users request
information such as telephone number about an entity. Currently, the
user places a telephone call to an automated DA service, verbally
requests the phone number for a name and locality, and an automation
system performs speech recognition, looks up the listing, and
announces the phone number. Frequently, a live operator is attached
to recognize the request and find the listing. DA services are often
provided on a wholesale basis to Voice Services Providers (VSPs), and
include features such as branded announcements. Some advanced
services such as sending listings via SMS to the caller's cellphone
are already available. With migration to VOIP based platforms, much
more advanced services are envisioned.
DA Provider - The DA provider is the provider of DA services to end
users. The DA provider provides retail services directly to end
users, and provides wholesale services to Local Services Providers,
such as the VSPs. Specifically, the DA providers provide DA services
to the end users that are served by other Local Services Providers,
such as VSPs. The DA provider needs to identify the VSP in order to
provide such services as customized announcements, and may also need
to know the identity of other intermediate entities for billing
purposes.
Voice Services Provider (VSP) - The VSP is the provider of voice
services to end users. The VSP may be directly connected to the DA
provider or they may communicate with the DA provider via an
Aggregation Services Provider (ASP) and/or Transport Services
Provider (TSP). The VSP may also be an ASP and/or TSP.
Aggregation Services Provider (ASP) - The ASP is the provider that
routes DA calls from multiple VSPs to a DA provider. The ASP may be
a VSP and/or a TSP. Also, VSPs may send their traffic to the DA
provider using multiple ASPs.
Transport Services Provider (TSP) - The TSP is the provider of the
transport network elements between the VSP's network and the DA
provider, and between the ASP's network and the DA provider. The TSP
transports the VoIP signaling and media streams (e.g., Session
Initiation Protocol for signaling and Real-time Transport Protocol
from media) from the VSPs and ASPs to the DA providers. The TSP may
support the physical layer (e.g., SONET), link layer (e.g.,
Ethernet), and network layer (IP) of the Open Systems Interconnection
(OSI) protocol model. This document assumes that the VSP, the ASP,
and the DA provider all use SIP for VoIP signaling and that the TSP
Haluska, et al. Expires December 18, 2006 [Page 4]
Internet-Draft Directory Assistance Using SIP June 2006
transparently passes the SIP signaling from the VSP to the DA
provider or from the ASP to the DA provider. The TSP may also be a
VSP and/or ASP.
Though the TSP is transparent at the application layer, it does play
a role because in some cases the incoming facility can be used to
identify the provider, for instance in cases where there is only one
provider connected via that TSP.
Time Division Multiplexed (TDM) Local Exchange Carriers (LECs) - The
TDM LECs provide local exchange service to end users utilizing TDM-
based switching systems.
Haluska, et al. Expires December 18, 2006 [Page 5]
Internet-Draft Directory Assistance Using SIP June 2006
3. The Need to Identify Service Providers
Because DA providers provide branded service on a wholesale basis,
and may need to route a call back through the originating VSP's
network, it is necessary to know which providers are involved in a
call. This section illustrates several potential deployment
scenarios for IP-based DA providers, serving both VOIP end users as
well as PSTN end users. These examples will identify the various
type of providers which could be involved in a DA call, and will show
that while in some cases provider identities are known implicitly,
that this is not the case in general and thus some means of signaling
this information explicitly will be needed.
1. VSP and DA provider
2. VSP, TSP, and DA provider
3. VSP, ASP, and DA provider
4. VSP, ASP, TSP and DA provider
5. TDM CLEC and DA provider
6. TDM CLEC, ASP, TSP and DA provider
3.1. Scenarios
3.1.1. Scenario 1: VSP and DA provider
In Scenario 1, the VoIP provider has a dedicated connection to the DA
provider that carries both SIP and IP traffic. This connection may
be a direct physical connection between the VSP's network and the DA
provider's network. Alternatively, this connection may be a
dedicated data link (like a Frame Relay link) over a shared physical
medium (like a SONET Ring) between the VSP's network and the DA
provider's network. The VoIP provider routes all DA calls to the DA
provider via this dedicated connection by exchanging SIP messages and
RTP media streams with the DA provider.
The DA provider needs to know the identity of the VSP in order to
brand and bill DA calls from the VSP, route these calls back to the
VSP when call completion is needed, and perform additional call
processing functions, such as operator queue selection. Since there
is a dedicated connection from the VSP to the DA provider, the DA
provider implicitly knows the VSP's identity.
Haluska, et al. Expires December 18, 2006 [Page 6]
Internet-Draft Directory Assistance Using SIP June 2006
3.1.2. Scenario 2: VSP, TSP and DA provider
In Scenario 2, the VoIP provider communicates with the DA provider
via a TSP's network. In this scenario, the TSP's network may either
be a physical layer network (e.g., a SONET ring), a link layer
network (e.g. Frame Relay links carried over a SONET ring), or a
network layer network (e.g. an IP network that contains IP routers,
and that carries IP packets over Frame Relay links over a SONET
ring). The VoIP provider routes all DA calls to the DA provider via
the TSP's network. The VoIP provider logically exchanges SIP
messages and RTP media streams with the DA provider, since the TSP
transparently passes the SIP messages and RTP media streams.
The DA provider needs to know the identity of the VSP in order to
brand and bill DA calls from the VSP, route these calls back to the
VSP when call completion is needed, and perform additional call
processing functions, such as operator queue selection. Since there
may be multiple VSPs served via the TSP, the DA provider does not
implicitly know the VSP's identity. Thus the DA provider needs some
way to identify the VSP. This could be done either via explicit
signaling or via a database lookup based on the caller's Directory
Number (DN). In the latter case, the VSP needs the caller's DN from
the VSP.
3.1.3. Scenario 3: VSP, ASP and DA provider
In Scenario 3, the VoIP provider communicates with the ASP and the
ASP communicates with the DA provider directly. In this scenario,
the ASP has a dedicated connection to the DA provider. The VoIP
provider routes all DA calls to the ASP, and the ASP routes all DA
calls to the DA provider via this dedicated connection.
The DA provider needs to know the identity of the VSP for branding,
and needs to know the identity of the ASP for billing. Additionally,
the DA provider may use the identity of the ASP to determine the
appropriate route (e.g., to route the call back to the ASP for call
completion). The DA provider may use the VSP and/or ASP identities
for additional call processing functions, such as operator queue
selection. The ASP identity is implicitly known because it is served
by a dedicated connection, much as the VSP is implicitly known in
Scenario 1. As in Scenario 2, the VSP's identity is not implicitly
known, so it must be explicitly signaled, or derived from the
caller's DN.
3.1.4. Scenario 4: VSP, ASP, TSP, and DA provider
In Scenario 4, the VoIP provider communicates with the ASP and the
ASP communicates with the DA provider via the TSP. In this scenario,
Haluska, et al. Expires December 18, 2006 [Page 7]
Internet-Draft Directory Assistance Using SIP June 2006
as in the previous one, the TSP's network may either be a physical
layer network a link layer network, or a network layer IP network.
The VoIP provider routes all DA calls to the ASP, and the ASP routes
the DA calls to the DA provider via the TSP. The VoIP provider
exchanges SIP messages and RTP media streams with the ASP, and the
ASP logically exchanges SIP messages and RTP media streams with the
DA provider via the TSP, since the TSP transparently passes the SIP
messages and RTP media streams.
In this scenario, neither the VSP nor the ASP identities are
implicitly known. Again, the VSP identity could either be explicitly
signaled or derived from the caller's DN. The ASP identity, however,
needs to be explicitly signaled.
3.1.5. Scenario 5: TDM CLEC or Wireless Carrier and DA provider
In Scenario 5, the TDM CLEC or Wireless Carrier routes the DA calls
to the VoIP Gateway via a TDM trunk. The Gateway then translates the
TDM call to a VoIP call and sends SIP messages to the DA provider to
set up the VoIP call.
In this scenario, the DA provider needs the identity of the TDM CLEC
/ Wireless Carrier for branding, billing, routing, and additional
call processing functions. The incoming trunk group at the VoIP
Gateway uniquely identifies the TDM CLEC. As a result, consideration
should be given to signaling the TDM CLEC/Wireless Carrier's identity
(e.g., as an incoming trunk group identifier or an Operating Company
Number) from the VoIP Gateway to the DA provider via a SIP message.
3.1.6. Scenario 6: TDM CLEC or Wireless Carrier, ASP, TSP, and DA
provider
In Scenario 6, the TDM CLEC or Wireless Carrier routes the DA calls
to the VoIP Gateway via a TDM trunk. The Gateway then translates the
TDM call to a VoIP call and sends SIP messages to the ASP to set up
the VoIP call. The ASP then routes the call to the DA provider via
the TSP.
In this scenario, the DA provider needs the identity of the TDM CLEC
or Wireless Carrier for branding and the identity of the ASP for
billing and routing. The identity of the TDM CLEC or Wireless
Carrier or the ASP identity may be used for additional call
processing functions, such as operator queue selection. The incoming
trunk group at the VoIP Gateway uniquely identifies the TDM CLEC/
Wireless Carrier. As a result, consideration should be given to
signaling the TDM CLEC/Wireless Carrier's identity (e.g., as an
incoming trunk group identifier or an Operating Company Number) from
the VoIP Gateway to the ASP using a SIP message. If the ASP receives
Haluska, et al. Expires December 18, 2006 [Page 8]
Internet-Draft Directory Assistance Using SIP June 2006
the TDM CLEC/Wireless Carrier's identity, it should send it to the DA
provider via the TSP using a SIP message.
3.2. Potential Provider Identifiers
The following are several possible ways to identify the providers
(VSPs, ASPs, TDM CLECs, and TDM Wireless Carriers) which are involved
in a call. All the options are not applicable to all types of
providers.
1. A unique identity for each provider, such as the National
Exchange Carrier Association (NECA) Operating Company Number
(OCN), which comprises 4 alphanumeric characters. The OCN may be
delivered to the DA provider in the SIP INVITE message, if a
standardized field is defined in the SIP message to carry it (for
example: OCN: VSP1).
2. The right hand side of the values in "Via" headers inserted by
the providers. The first Via would presumably be inserted by the
serving VSP, while additional Via headers are inserted by ASPs.
E.g. (irrelevant headers omitted):
INVITE sip:411@VSP1.net SIP/2.0
From: Alice <sip:alice@VSP1.net>;tag=1234567
To: sip:411@VSP1.net
Via: proxy1@VSP1.net
Via: proxy2@ASP1.net
3. If the calling party's DN is signaled to the DA provider, then
the VSP identity could be derived from the calling DN. Since
this option requires VSPs to provide their end users' DNs to the
DA providers, the use of this option depends on VSP business
arrangements. This option is not expected to be used by all
VSPs.
4. Implicit knowledge of the provider when it is served via a
dedicated connection.
Haluska, et al. Expires December 18, 2006 [Page 9]
Internet-Draft Directory Assistance Using SIP June 2006
4. Other Required Information
In addition to utilizing VoIP Network identifiers for branding,
billing, routing, and additional call processing functions, DA
providers use other information associated with the calling end
user's equipment to influence call processing. Specifically, the DA
provider needs the following additional signaling information:
o Originating Station Type
o SS7 versus MF indication
o Network Type Identifier
o Codecs
o Dialed Digits
4.1. Originating Station Type
In the current PSTN in North America, DA providers have the ability
to tailor treatment based on the type of originating station. For
instance, calls from prison phones are restricted from accessing DA
services. Example values include POTS, coin, hospital, prison/
inmate, cellular, etc. In the PSTN in North America, this
information is signaled for SS7 calls using the Originating Line
Information (OLI) information element, and in MF calls using the ANI
II digits.
Ways to represent this information in SIP need to be explored.
4.2. SS7 Versus MF Indication
DA providers need to know whether the call came in via an SS7 or MF
connection.
Ways to represent this information in SIP need to be explored.
4.3. Network Type Identifier
Today, DA providers perform call processing functions based on the
type of network. For example, a unique operator queue can be
selected if the call is wireless. Plus, the DA Automation (DAA)
recognition rates can be improved with the knowledge of the type of
network. One way DA providers can benefit from receiving an
indicator that the type of network is VoIP is by setting up operator
teams that are especially suited to handle calls from VoIP providers.
Haluska, et al. Expires December 18, 2006 [Page 10]
Internet-Draft Directory Assistance Using SIP June 2006
Ways to represent this information in SIP need to be explored.
4.4. Codec
By knowing the codec, the success rate for automated speech
recognition can be improved.
This is currently signaled in the SDP
4.5. Dialed Digits
For DA, the dialed digits continue to be important to differentiate
411 calls from 555 calls and direct dialed calls from 0+ dialed
calls.
This information is carried in the initial INVITE, but due to
retargeting or other reasons, it may be modified. It will be
important to maintain this information along the entire path. There
may be existing mechanisms in SIP to handle this, further study is
needed.
Haluska, et al. Expires December 18, 2006 [Page 11]
Internet-Draft Directory Assistance Using SIP June 2006
5. VoIP DA - Summary and Next Steps
Directory Assistance is a service seen as useful by end users and is
revenue-generating for providers. DA providers wish to migrate to
SIP based platforms. In doing so, they need to continue to support
existing PSTN service. In order to support both existing PSTN
services as well as move ahead with IP based services, certain
information needs to be exchanged. It is expected that currently SIP
will not support the exchange of all of this information, and that
extensions will be needed.
This document has laid out some of the information required for IP
based DA services. The intended next steps would be to stimulate
discussion with the SIPPING working group on how this information
could be exchanged, and to pursue standardization of any identified
required extensions per the SIP change process.
Haluska, et al. Expires December 18, 2006 [Page 12]
Internet-Draft Directory Assistance Using SIP June 2006
6. Security Considerations
This document is an initial version and at this point security
considerations have not yet been developed.
Haluska, et al. Expires December 18, 2006 [Page 13]
Internet-Draft Directory Assistance Using SIP June 2006
7. IANA Considerations
This document is an initial version and at this point IANA
considerations have not yet been developed.
8. References
[1] Rosenberg, et al, J., "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
Haluska, et al. Expires December 18, 2006 [Page 14]
Internet-Draft Directory Assistance Using SIP June 2006
Authors' Addresses
John Haluska
Telcordia Technologies, Inc.
331 Newman Springs Road
Room 2Z-323
Red Bank, NJ 07701-5699
USA
Phone: +1 732 758 5735
Email: jhaluska@telcordia.com
Renee Berkowitz
Telcordia Technologies, Inc.
One Telcordia Drive
Piscataway, NJ 08854-4157
USA
Phone: +1 732 699 4784
Email: rberkowi@telcordia.com
Paul Roder
Telcordia Technologies, Inc.
One Telcordia Drive
Room RRC-4A619
Piscataway, NJ 08854-4157
USA
Phone: +1 732 699 6191
Email: proder2@telcordia.com
Richard Ahern
BellSouth Corporation
1876 Data Drive
Room 314
Hoover, AL 35244
USA
Email: Richard.Ahern@bellsouth.com
Haluska, et al. Expires December 18, 2006 [Page 15]
Internet-Draft Directory Assistance Using SIP June 2006
Paul Lum Lung
Qwest Communications International
1801 California Street
Suite 1210
Denver, CO 80202
USA
Email: paul.lumlung@qwest.com
Haluska, et al. Expires December 18, 2006 [Page 16]
Internet-Draft Directory Assistance Using SIP June 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
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Haluska, et al. Expires December 18, 2006 [Page 17]