Network Working Group J. Haluska
Internet Draft R. Berkowitz
Expires: January 2008 P. Roder
W. Downum
Telcordia Technologies, Inc.
R. Ahern
AT&T Customer Information Services
P. Lum Lung
Qwest Communications International
N. Costantino
Soleo Communications, Inc.
C. Blackwell
J. Mellinger
Verizon
D. Scott
Volt Delta
July 5, 2007
Considerations for Information Services and Operator Services Using
SIP
draft-haluska-sipping-directory-assistance-03.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."
Haluska, et al. Expires January 5, 2008 [Page 1]
Internet-Draft Information Services Using SIP July 2007
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 January 5, 2008.
Abstract
Information Services are services whereby information is provided
in response to user requests, and may include involvement of a
human or automated agent. A popular existing Information Service is
Directory Assistance (DA). Moving ahead, Information Services
providers envision exciting multimedia services that support
simultaneous voice and data interactions with full operator backup
at any time during the call. Information Services providers are
planning to migrate to SIP based platforms, which will enable such
advanced services, while continuing to support traditional DA
services. Operator Services are traditional PSTN services which
often involve providing human or automated assistance to a caller,
and often require the specialized capabilities traditionally
provided by an operator services switch. Market and/or regulatory
factors in some jurisdictions dictate that some subset of Operator
Services continue to be provided going forward. This document aims
to identify how Operator and Information Services can be
implemented using existing or currently proposed SIP mechanisms,
and to provide a set of Best Current Practices to facilitate
interoperability.
Table of Contents
1. Introduction..................................................3
2. Terminology...................................................4
3. High Level Requirements.......................................8
4. Information Services.........................................12
5. Operator Services............................................15
5.1. Inter Provider Capabilities.............................18
5.2. Inter OISP Capabilities.................................18
5.3. Intra Provider Capabilities.............................19
5.4. Capabilities Required for Specific Services.............20
6. OISP Internal Architecture...................................21
7. General Approach.............................................23
8. Signaling Mechanisms.........................................25
Haluska, et al. Expires January 5, 2008 [Page 2]
Internet-Draft Information Services Using SIP July 2007
8.1. Calling Party's Identity................................25
8.2. Provider Identification.................................26
8.2.1. Home Provider......................................27
8.2.2. Intermediate Provider..............................28
8.3. Originating Station Type................................30
8.4. Trunk Group Identifier..................................31
8.5. Dialed Digits...........................................32
8.6. Retargeting to Identify the Desired Service.............33
8.7. Charge Number...........................................33
8.8. Passing Whisper.........................................33
8.9. Calling Equipment Capabilities and Characteristics......37
8.10. Media Server Returning Data to the Application Server..38
8.11. Service Discovery......................................38
9. Example Call Flow - Directory Assistance.....................39
10. Example Call Flow - Operator Services.......................48
11. VoIP Information Services - Summary and Next Steps..........55
12. Security Considerations.....................................56
13. IANA Considerations.........................................56
14. References..................................................57
14.1. Normative References...................................57
14.2. Informative References.................................57
Author's Addresses..............................................59
1. Introduction
Information Services are services whereby information is provided
in response to user requests. This may include involvement of a
human or automated agent. Information Services may include call
completion to a requested telephone number and other extensions
provided on behalf of the owner of the information, such as
assistance with purchases. The users normally access the
Information Services by dialing a Directory Assistance (DA) dialing
sequence and verbally requesting an operator or automated system
for the information. The users may also request information through
other access methods, such as chat (IM), email, Web (HTTP) or SMS
initiated requests. The Information may be delivered to the user
via any mode, such as verbal announcements, chat (IM), email, Web
(HTTP), MMS, or SMS.
A popular existing Information Service is Directory Assistance
(DA). 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 provide a user with telephone number
associated with a name and locality provided by the user, can
complete the call for the user, and can send SMS with the listing
Haluska, et al. Expires January 5, 2008 [Page 3]
Internet-Draft Information Services Using SIP July 2007
to the user's wireless phone. Other Information Services provide
the user with a wide range of information, such as movie listings
and the weather.
Moving ahead, Information Services 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 directions Information 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.
Operator Services are traditional PSTN services which often involve
providing human or automated assistance to a caller, and often
require the specialized capabilities traditionally provided by an
operator services switch. Market and/or regulatory factors in some
jurisdictions dictate that some subset of Operator Services
continue to be provided going forward. Some examples of such
services include collect calls, third party billed calls, and busy
line verification.
Operator and Information Services providers are planning to migrate
to SIP based platforms, which will enable such advanced services,
while continuing to support traditional DA services.
Implementing Operator and Information Services with SIP will
require the exchange of certain information, and possibly the use
of specialized capabilities which are not normally required for
other types of calls. This document aims to identify such
information, and stimulate discussion about how this information
could be exchanged. Existing mechanisms will be used where
appropriate, and currently existing proposals will be favored over
new extensions. It is intended to provide a Best Current Practices
document to facilitate interoperability.
2. Terminology
This section defines terms that will be used to discuss Information
and Operator Services.
Haluska, et al. Expires January 5, 2008 [Page 4]
Internet-Draft Information Services Using SIP July 2007
Application Server (AS) - An Application Server is a server
providing value added services. It may influence and impact SIP
sessions on behalf of the services supported by the service
provider's network.
Back End Automation - Back End Automation refers to automation of
the function that provides listing information to the caller. This
includes playing a verbal announcement with the listing
information, and may also include prompting the user for call
completion service.
Branding - Branding is a service where customized announcements are
provided to the caller to identify the service provider. For
example, if the service is provided to a Home Provider's
subscribers by a third party provider, branded service might
include a message thanking them for using that Home Provider. Thus
the user experience is that the service is provided by their Home
Provider rather than some third party. Branding can be influenced
by a number of factors, including but not limited to the identity
of the caller's Home Provider, or of other providers involved in
the call.
Call Completion - Call Completion is a service where a call is
initiated by the provider on behalf of the user. For example, in
the DA service, once the DA provider has identified the requested
listing, it may offer to complete the call for the caller, usually
for some additional fee. This relieves the user from having to
remember the number and then dial it.
DA Provider -The DA provider is the provider of DA services to end
users. Since DA services are a subset of IS services, a DA provider
is also an IS provider, and the definition of IS provider holds
true for DA provider, except that the scope of services is limited
to DA services.
Front End Automation - Front End Automation refers to automation of
the initial customer contact, whereby a branded announcement may be
played, a prompt is played to the user, and the user's spoken
request is recorded. Speech recognition and querying for the
listing information are performed as part of front end automation.
Home Provider - The service provider who is responsible for
providing voice services to the calling customer. This is the
service provider that has the business relationship with the
calling customer. The identity of the home provider influences call
processing treatment, such as branding and operator queue
selection.
Haluska, et al. Expires January 5, 2008 [Page 5]
Internet-Draft Information Services Using SIP July 2007
HSS - Home Subscriber Server. The Home Subscriber Server is an IMS
network element similar to a Home Location Register. It is a
database containing information about the subscriber, user
equipment, filter criteria for call processing triggers, etc.
Information Services (IS) Provider - The IS provider is the
provider of Information Services to end users. The Information
Services provider provides retail services directly to end users,
and provides wholesale services to other service providers.
Intermediate Provider - In the context of this document, an
Intermediate Provider is a provider which has agreements with home
providers to handle OIS requests, and with OISPs which actually
provide the requested services. Note that some home providers will
have direct relationships with OISPs, rather than using an
Intermediate Provider. Intermediate Providers are the targets of
SIP requests from home providers since they are involved when a
home provider does not have a direct relationship with an OISP.
Intermediate Providers perform retargeting of received SIP requests
toward the OISP.
Layer 3 connectivity - This refers to IP connectivity, for example
as provided by an Internet Service Provider or Managed IP service
provider. If one entity has Layer 3 connectivity to another entity,
then it can route packets to that entity. This does not imply
anything about any physical path between the entities. Nor does it
imply any application layer connectivity between the entities.
Media Server - A Media Server is a general-purpose platform for
executing real-time media processing tasks. Examples of typical
functions performed by media servers include playing announcements,
collecting speech and/or DTMF digits, and performing conferencing
functions.
Operator and Information Services Provider (OISP) - In this
document, this term refers to an Information Services Provider,
Directory Assistance Provider, or Operator Services Provider,
depending on the context. This term is used for brevity. We are
also defining this to be an adjective, thus "OISP services" is a
convenient, intuitive way to say "Operator and Information
Services".Operator Services - Traditional PSTN services which often
involve providing human or automated assistance to a caller, and
often require the specialized capabilities traditionally provided
by an operator services switch. Some examples of such services
include collect calls, third party billed calls, and busy line
verification.
Haluska, et al. Expires January 5, 2008 [Page 6]
Internet-Draft Information Services Using SIP July 2007
Retail OIS service - A retail OIS service is one which is provided
to a user by the user's Home Provider.
SIP Layer connectivity - When one entity has SIP level connectivity
to another entity, this implies that the second entity will accept,
process, and route SIP requests from the first entity. This would
usually involve business agreements as well.
Time Division Multiplexed (TDM) Local Exchange Carriers (LECs) -
ATDM LEC provides local exchange service to end users utilizing
TDM-based switching systems.
Transit Provider - In the context of this document, a transit
provider simply "moves calls", and has no concept of OIS services.
It may perform SIP rerouting of the request, but does not perform
SIP retargeting. Such a provider is used when a provider cannot
directly route calls to another provider. For example, an
Intermediate Provider might use a Transit Provider if for some
reason (e.g. error condition) it cannot route a call directly to an
OISP.
Transport Services Provider (TSP) - The TSP provides access at
Layer 3 or below to other providers. The most obvious case of TSP
is that of an internet service provider or managed IP services
provider. VSPs, and IS or DA providers may or may not share the
same TSP for access to each other. Further, each of these providers
may have multiple TSPs. In this case, the decision as to which is
used is determined by the policy of the entity sending the traffic;
the Border Gateway Protocol (BGP) is often used. It is entirely
possible that the traffic from each entity towards the other takes
separate paths; i.e. it should not be assumed that the incoming and
outgoing paths are symmetric.
Voice Services Provider (VSP) - An entity that provides transport
of SIP signaling to its customers. It may also provide media
streams to its customers. Such a service provider may additionally
be interconnected with other service providers; that is, it may
"peer" with other service providers. A VSP may also interconnect
with the PSTN.
Whisper - During front end automation, the OIS-MS will record and
may time compress the caller's perhaps meandering speech into what
is known as the "whisper". This is intended to be played into a
human operator's ear, should the call be referred to an operator,
to avoid the operator from having to prompt the caller again. The
Haluska, et al. Expires January 5, 2008 [Page 7]
Internet-Draft Information Services Using SIP July 2007
whisper is obtained during the front end automation, and saved as
an audio file.
Wholesale OIS service -A wholesale OIS service is one which is
provided to a user by a Service Provider other than the user's Home
Provider.
Zero Minus ("0-") Dialing - Invocation of Operator Services by
dialing "0" with no further digits.
Zero Plus ("0+") Dialing - Invocation of Operator Services by
dialing "0" followed by a phone number.
3. High Level Requirements
In addition to all-IP scenarios, it must be possible to support
interworking with existing PSTN and wireless based providers, via
both SS7 and MF interconnections.
It must be possible to support accounting. This includes both
online and offline accounting. It must be possible to perform
accounting for all actions associated with a particular call, and
further to be able to correlate actions across multiple provider
elements and across providers.
It must be possible to support multiple Operator and Information
Services Providers (OISPs) per originating provider. The choice as
to which OISP to be used could be on a per subscriber basis, or on
other criteria.
It must be possible to support multiple OISP providers per call.
For example, one provider might be used for front end automation,
and another used for operator assistance.
It must be possible to provide an automated announcement to the
user, and prompt the user for the type of query and query
information.
It must be possible to pass a "whisper" to the operator
workstation.
Haluska, et al. Expires January 5, 2008 [Page 8]
Internet-Draft Information Services Using SIP July 2007
It must be possible to connect the user to a human operator.
It must be possible to provide an automated announcement of the
requested information.
It must be possible to prompt the user for call completion.
It must be possible to perform call completion.
It must be possible to support the case where OIS services are
provided by the caller's Home Provider. This scenario is known in
the OIS industry as the Retail scenario. In this case, the caller's
Home Provider is also an OISP, and provides OIS service to its own
subscribers. This is illustrated in the following figure:
+--------+ +--------------------+
| Caller |----| Home +------+ |
| | | Provider | OISP | |
| | | +------+ |
+--------+ +--------------------+
Figure 1 Services Provider by Home Provider
It must be possible to support the case where OIS services are
provided by a direct third party provider. In this scenario, the
OISP is a third party service provider, and there is direct SIP
layer connectivity as well as business relationships between the
calling user's provider and the OISP. This is illustrated in the
following figure:
+--------+ +----------+ +------+
| Caller |----| Home |---| OISP |
| | | Provider | | |
+--------+ +----------+ +------|
Figure 2 Services Provider by a Direct Third Party Provider
Haluska, et al. Expires January 5, 2008 [Page 9]
Internet-Draft Information Services Using SIP July 2007
It must be possible to support the case where services are provided
by an indirect third party provider. In this scenario, the OISP is
a third party provider, but the caller's Home Provider does not
have direct SIP connectivity to the OISP. Further, it's possible
that it has no business relationship with the OISP. The caller's
provider routes the call to a provider with whom it does have a
relationship, referred to in this document as an "intermediate
provider", and this intermediate provider in turn routes either to
the OISP, with which it has a relationship, or there could be
multiple intermediate providers. This is illustrated in the
following figure:
+--------+ +--------+ +---------+ +------+
| Caller | |Home | | Inter- | | OISP |
| |----|Provider|---| mediate |---| |
| | | | | Provider| | |
| | | (A) | | (B) | | (C) |
+--------+ +--------+ +---------+ +------+
Figure 3 Services Provided by an Indirect Third Party Provider
It must be possible to support the case where transit providers are
included between any other providers involved in the call. The
transit provider only "moves calls" between other providers, and is
involved in no other way with OIS services. This is illustrated in
the following figure:
+--------+ +--------+ +--------+ +---------+ +------+
| Caller | |Home | |Transit | | Inter- | | OISP |
| |----|Provider|---|Provider|---| mediate |---| |
| | | | | | | Provider| | |
| | | (A) | | (B) | | (C) | | (D) |
+--------+ +--------+ +--------+ +---------+ +------+
Figure 4 Involvement of a Transit Provider
The following are potential future requirements.
Haluska, et al. Expires January 5, 2008 [Page 10]
Internet-Draft Information Services Using SIP July 2007
Operation via the general internet, not specific to any particular
SDO's architecture, and not depending on any protocol extensions
specific to those architectures, should be supported.
In addition to the basic DA functionality, the architecture will
need to support additional technical capabilities. These
capabilities are currently under investigation. The following are
some business needs which drive these capabilities.
It must be possible to support multiple Information Services
providers per originating provider. For instance, a Home Provider
must be able to select an appropriate Information Services provider
from among several Information Services providers based on criteria
including but not limited to the identity of the calling
subscriber. It must also be possible to support multiple
Information Services providers per call. For example, once the
initial request has been satisfied, the user may make another
Information Services request without hanging up, and it must be
possible in this case to select the appropriate Information
Services provider for the next request. In such cases the
Information Services provider may be involved in selecting a
different Information Services provider.
It must be possible to support non voice initiated Information
Services requests. Possible examples include chat (IM), email, Web
(HTTP) or SMS initiated requests. In the case that the subscriber
makes a purchase via some online auction service, that subscriber
can via IM or email request the assistance of an operator.
It must be possible to support both Information Services as well as
Operator Services. Examples of Operator services include Operator
Intercept, Busy Line Verification, Call Restrictions, etc.
It must be possible to support Purchase services and Concierge
services. Such services facilitate the Information Services
operator providing assistance to the caller after the listing has
been announced and perhaps call completion performed. The call is
routed to an Information Services operator who interacts with the
customer, offering to help make a purchase. Concierge service is
similar; the Information Services operator offers to make e.g.
restaurant reservations for the caller.
It must be possible to provide an application interface to other
types of systems. An example could be a web based API, so that once
some online search engine has located some business listing, the
services of the Information Services provider could be invoked by
the user from the web page.
Haluska, et al. Expires January 5, 2008 [Page 11]
Internet-Draft Information Services Using SIP July 2007
It must be possible to support IPTV interactive services. As
multiple services such as IM and telephony are integrated with
IPTV, it must be possible to initiate Information Services requests
in this context as well.
4. Information Services
Information Services (IS) are services whereby information is
provided in response to user requests. This may include involvement
of a human or automated agent. Usually, the user accesses the
Information Service by placing a voice call to the automated
Information Service and verbally requests the information, such as
phone number, movie listings, weather, etc. Frequently, a live
operator is attached to recognize the user's verbal request.
Sometimes, the user can utilize other access methods, such as SMS,
IM, or HTTP-initiated requests. These additional methods are not
currently covered in this document.
Information Services are often provided on a wholesale basis to
Home Providers, and include features such as branded announcements.
Directory Assistance (DA) is a specific type of Information Service
whereby end users request a telephone number for an entity.
The following represents a list of representative steps taken
during the course of a typical DA request and identifies a set of
required high level capabilities.
1. Initial recognition of an OIS call. At some point, the call
needs to be identified as an OIS call, and appropriate routing or
other logic must be invoked in order to fulfill the request. This
could be based on any number of criteria, including but not limited
to analysis of the "address information" - e.g. the digits or
Request-URI emitted by the caller's UA. This could occur at any
number of places - e.g. in the caller's UA, in a proxy in the home
provider, or in some downstream element.
2. Identification of the requested service. There are many possible
OIS services, and the number of these is only expected to increase
as providers respond to customer needs. At some point during call
processing it is necessary to identify exactly which service is
desired. For example "directory assistance with call completion" is
a service where after the listing information is provided to the
Haluska, et al. Expires January 5, 2008 [Page 12]
Internet-Draft Information Services Using SIP July 2007
caller, the option is provided for the call to be placed
automatically, so the customer need not hang up, remember the
digits, and dial the number. Another example is "directory
assistance only", where call completion is not offered. There are
multiple factors which could affect the service which is to be
offered, and the logic deciding this could be located anywhere
along the path to the OIS provider. Some of the information
required to make such decisions could include:
o The digits dialed by the caller.
o The Request-URI emitted by the caller's UA.
o The identity of the calling party, for instance the calling
party number.
o The charge number associated with the caller's account.
o The identity of the calling party's home provider.
o The identity of the provider which directly hands off the call
to the OISP.
o The identity of other provider which the request might traverse
o The Originating Station Type, in case the call was originated
in the PSTN.
o Trunk group information, in case the call was originated in the
PSTN.
o Capabilities and characteristics of the caller's user
equipment.
3. Routing of the OIS call. The call must be routed towards an
entity which can provide the requested service. Each entity or
network handling the call routes it based on the logic located in
that provider, and the information currently available. For
instance, the home provider may know very little about OIS
services, having farmed that service out to another provider.
Consequently it might simply route all such calls towards the OIS
provider, which decides which service is to be offered.
4. Authentication. When one provider passes a call to another
provider, there is a need for the providers involved to be sure of
Haluska, et al. Expires January 5, 2008 [Page 13]
Internet-Draft Information Services Using SIP July 2007
each other's identity. This might be through explicit security
mechanisms such as mutual TLS or security gateways using IPSec
tunnel mode, it might be through reliance on a closed set of
trusted interconnected providers, or some other policy set by the
providers involved.
5. Receipt of the OIS call. The OIS provider needs to be able to
receive such calls.
6. Querying upstream providers for information. The OISP, or an
intermediate provider may require information from an upstream
provider. For instance, the capabilities and characteristics of the
caller's equipment may be needed in order to influence call
processing.
7. Selection of automated voice platform. When it has been
determined that the call must be routed to an automated voice
platform, there are a number of factors to be taken into account to
determine an appropriate, available platform for the call. It must
be possible to determine an appropriate, available automated voice
platform to which the call should be routed.
8. Connection of caller to automated voice platform. The OISP must
be able to connect the caller to an appropriate automated voice
platform.
9. Provision of branded announcements. The OISP must be capable of
providing custom announcements to the caller based on a number of
criteria. For example, it might greet the caller, thanking them for
using their Home Provider's service. Though the service is actually
provided by the OISP, business arrangements would dictate such
branded announcements.
10. Query the caller. The OISP must be capable of playing a voice
request to the customer asking them for the listing. For example
"Name and city, please."
11. Recording a spoken request. The OISP must be capable of
recording the caller's spoken request. This both for speech
recognition, and also for playing back the "whisper" to a human
operator should one be required, to prevent having to ask the
customer to repeat the request.
12. Speech recognition. The OISP must be able to pass the caller's
spoken request to speech recognition system, suitable for querying
a listing database.
Haluska, et al. Expires January 5, 2008 [Page 14]
Internet-Draft Information Services Using SIP July 2007
13. Listing database query. The OISP must be capable of querying
one or more listings databases using the request.
14. Decide to use human operator if listing query fails. If the
listing query fails, or the speech recognition fails, the OISP must
be able to decide to send the call to a human operator.
15. Selection of appropriate operator. When it has been determined
that the call must be routed to a human operator, there are a
number of factors to be taken into account to determine the
appropriate operator for the call. It must be possible to determine
an available, appropriate human operator to which the call should
be routed.
16. Routing of call to operator workstation. Once the appropriate
operator has been identified, the call must be routed to that
operator's workstation.
17. Whisper. Once the operator answers the call, the previously
recorded request should be played to the operator as a "whisper",
prior to connecting the caller to the operator.
18. Connection of caller to operator. Once the operator has heard
the whisper, the caller can be connected to the human operator. The
operator queries the caller for the request, and initiates a query
to the listing database.
19. Playing listing information. Once the listing information is
returned from the database, the caller must be connected to a media
resource which speaks the listing information to the caller.
20. Prompting for call completion. If the identified service
includes call completion, the caller should be prompted for this
service, for example by pressing some DTMF key.
21. Call completion. If the caller requests call completion, the
call should be automatically initiated for the caller.
5. Operator Services
Operator Services are traditional PSTN services which often involve
providing human or automated assistance to a caller, and often
require the specialized capabilities traditionally provided by an
operator services switch. Market and/or regulatory factors in some
Haluska, et al. Expires January 5, 2008 [Page 15]
Internet-Draft Information Services Using SIP July 2007
jurisdictions dictate that some subset of Operator Services
continue to be provided going forward.
This document assumes an architecture with SIP based OISPs, SIP
based home providers, and SIP based end users. Since it is
necessary to maintain backward compatibility with traditional TDM
based providers and end users, these are also considered. It may
not be necessary, desirable, or technically feasible to support
every existing Operator Service using SIP, or to support both SIP
and TDM based end users for all Operator Services. This is the
subject of ongoing investigation, and the current iteration of this
document assumes that both SIP and TDM based home providers and end
users are in scope for these services, unless specifically
indicated to the contrary. A future revision may update this
assumption based on the findings of the investigation.
With respect to Operator Services, this iteration of this document
intends to provide an introduction to and descriptions of some of
these services, as well as provide some high level requirements. It
is intended that the subsequent iteration will build upon this,
providing more detailed requirements, suggested SIP mechanisms, and
more call flows.
Operator Services are typically provided by the requesting party's
OISP. In some cases, such as Busy Line Verification, the target or
called party's OISP may be involved as well.
Next, several traditional Operator Services will be described. As
indicated above, the current iteration of this document is silent
regarding which of these may or may not be candidates for
implementation with SIP, or towards SIP end users. Note that unless
specifically indicated, most of these services are traditionally
provided by the caller's OISP.
Operator Assistance. This allows the caller to perform either "zero
minus" or "zero plus" dialing to be connected to a human or
automated system for assistance with the call.
Collect calls. This allows the caller to request that the called
party accept the charges for the call. Typically an OISP utilizes a
human operator or automated system to provide this service.
Rate Quotes. This allows the caller to request a quote for the cost
or rate for specific calls.
Haluska, et al. Expires January 5, 2008 [Page 16]
Internet-Draft Information Services Using SIP July 2007
Third party billed calls. This allows the caller to request that a
third party (different than the calling or called party) be contacted
and requested to accept charges for the call (although in some
limited cases, contacting the third party is not necessary).
Busy Line Verification and Interrupt. This allows a caller to have
the OISP determine whether a target line is in use, and if so, to
"barge in" to the conversation and request whether the target party
is willing to accept a call from the caller. This service is
initially handled by the caller's OISP, which then contacts the
target party's OISP, which is able to perform the verification and
interrupt on the target party.
Coin Calls. Operator services systems must be able to control TDM-
based network controlled coin stations (payphones). This includes
monitoring of coin deposit tones (to verify payment) sent from the
coin station, as well as sending supervision (control) signals to
the coin station. Network controlled coin stations are connected to
TDM based end offices via specialized phone lines which support the
required signaling. These end offices, in turn, connect to TDM
based OISPs using specialized trunks capable of conveying the coin
signaling. The OISP monitors and controls the coin station via
these trunks. "Smart" coin stations perform coin detection locally
and do not require network control, and are not discussed here.
This service is provided by the OISP associated with the coin
station.
Emergency Calls. Sometimes a caller dials "0" instead of the
standard emergency dialstring, resulting in placement of an
emergency call to the OISP. The OISP must properly route such a
call toward the PSAP. This service is provided by the caller's
OISP.
Calling Card Billing Service. This enables a calling party to bill
a call to a calling card number.
Commercial Credit Card Billing Service. This enables a calling
party to bill a call to a commercial credit card.
Directory Assistance (DA). In some contexts, DA is considered as an
Operator Service. Within the context of this document, we consider
DA as an Information Service, which is related to but distinct from
Operator Services.
Haluska, et al. Expires January 5, 2008 [Page 17]
Internet-Draft Information Services Using SIP July 2007
The following sections describe an initial set of basic high level
capabilities required for supporting Operator Services. The
capabilities for Information Services generally apply for Operator
Services as well. This work is currently under study, and a
complete set of required capabilities is expected to be identified
in the near future. Similarly to the required capabilities for
Information Services, the use of existing SIP mechanisms will be
investigated for providing these capabilities.
5.1. Inter Provider Capabilities
Ability to accept requests from other providers. This is the
ability to accept incoming OIS requests from other providers,
including home providers, intermediate providers, and transit
providers.
Ability to terminate calls to other providers. This applies to call
completion services, as well as other services such as third party
billing.
5.2. Inter OISP Capabilities
These are capabilities between OISPs.
Inward connection. This is a call from one OISP to another, e.g. so
that the originating OISP may request services from the terminating
OISP. One example of this is Busy Line Verification, where the
caller calls their own OISP, and this OISP places an "inward" call
to the target party's OISP, which would have the capability to
perform the verification of the target party.
Transfer between OISPs. In this case, one OISP transfers the call
to another OISP, to be handled by that OISP.
Moving connection from one OISP to another. An example of this case
is where one OISP farms out a specific service to another OISP. The
first OISP performs initial handling of the call, to determine the
desired service. The call is sent to a different OISP with which
the first has a relationship. The first OISP remains in the
signaling path, and when the provided service is complete, the
first OISP determines what if any additional processing may be
necessary. This is similar to a third party call control type
arrangement.
Haluska, et al. Expires January 5, 2008 [Page 18]
Internet-Draft Information Services Using SIP July 2007
5.3. Intra OISP Capabilities
Note that some of the following capabilities may be required for
inter OISP scenarios as well; this is the subject of ongoing
analysis and is not covered in the current iteration of this
document.
Placing a caller on hold, possibly with announcements. This is used
in many services, including Information Services.
Exchanging information between Application Server and Operator
Workstations/Automated Platforms. This capability is required
whenever an operator workstation or automated platform is used.
Because an Operator Workstation interacts with a human user, it is
expected that additional information, beyond that which an
automated system would exchange with an application server, will be
required. Further, several modes of application server control are
currently under investigation. The first is where the workstation
or automated platform is more or less autonomous, and is capable of
initiating calls and directly impacting call processing. The other
is more of a master-slave relationship, where the AS is in complete
control. The master-slave model requires that more information be
exchanged with the AS than does the autonomous model.
Queuing and call distribution. Resources including human operators
and automated platforms need to be tracked and managed, and the
appropriate resource of the appropriate type needs to be selected
on a per invocation basis. What is needed is that for a particular
call, that a set of criteria be provided and the best match
resource be selected. This is the job of the ACD server. Some means
is needed to communicate the selection criteria for human operators
and automated platforms to the ACD server.
Operator Registration and Location. Human operators may not be
interchangeable, and have specific attributes such as skillsets
which can be used to identify the best human operator to service a
particular call. Operators log in at workstations at the beginning
of a shift, and log out during breaks and at the end of a shift. It
is important to associate each available operator with the
workstation at which they are logged in, so that requests can be
sent to the appropriate human operator. This is needed because the
selection process described above identifies a particular human
operator; it is then necessary to identify the workstation at which
that operator can be reached.
Haluska, et al. Expires January 5, 2008 [Page 19]
Internet-Draft Information Services Using SIP July 2007
Bridging and removal of operator or automated system. Many operator
services require that either a human operator or automated system
be "bridged" onto a call, and to be removed at some point.
5.4. Capabilities Required for Specific Services.
Connection Hold and Ringback. This capability involves having the
OISP "hold" the connection, such that the originating caller
remains connected, even if they attempt to hang up. This is mainly
used in relation to emergency services. Ringback is the ability for
the OISP to call back the calling party after they have hung up.
This too is often used in conjunction with emergency calls.
Coin Station Control. This is the ability of the OISP to determine
the coinage deposited into a TDM based network controlled coin
station (as opposed to an "intelligent" coin station which performs
such functions locally). This involves interpretation of the coin
control signals sent via specialized trunks from the end office to
which the TDM based coin station is connected via a specialized
phone line. Additionally, the need to signal toward the coin
station needs to be supported as well, for example to instruct the
station to return coins to the caller. This capability is intended
to interact with the specialized coin trunk.
Network Service Recall. After a call resulting from Operator
Services is completed, the caller may signal the desire to return
back to the OISP, without placing another call. In the traditional
PSTN, this is typically accomplished by the user signaling a hook
flash or other distinctive stimulus.
Verification and Interrupt. This is used in the Busy Line
Verification and Interrupt service, and allows the OISP to
determine if the target number is in use, to listen to a scrambled
representation of the conversation, and to interrupt the target
party's conversation to ask if they would accept a call from the
caller.
Transfer of emergency services call to selective router. Sometimes
a caller places an emergency call using a dial string which invokes
operator assistance (such as "0" in North America), rather than an
emergency call dial string. In such cases, the OISP must be able to
pass the emergency call to the appropriate PSAP.
Haluska, et al. Expires January 5, 2008 [Page 20]
Internet-Draft Information Services Using SIP July 2007
6. OISP Internal Architecture
This section describes an initial view of the elements internal to
the OISP architecture.
The following types of elements may be present within the OISP
infrastructure:
Automatic Call Distributor (ACD) server - The ACD provides queuing
and call distribution functions for human operators. Specifically,
it is the component that tracks the availability of the human
operators and selects an available operator utilizing complex
algorithms based on operator skills, type of call, type of request,
calling party information, etc. Similar functionality is required
with respect to automated platforms. The ACD server is modeled as
an Application Server. There is currently work in the MEDIACTL
working group regarding Media Resource Brokers (MRBs) which may be
relevant to this.
Customer Profile Database - The Customer Profile Database is a per
subscriber database maintained by an OISP about its customers. Some
of this information might be statically provisioned, other
information such as customer preferences or session information
might be populated dynamically as a result of customer
interactions.
Messaging Gateways - Messaging Gateways provide access and data via
E-mail, SMS, MMS, WAP.
Operator and Information Services Application Server (OIS-AS) - The
OIS-AS contains AS functions specifically for directory assistance
and information services as well as other Operator Services. This
may coordinate multiple call legs, connecting the caller in
sequence to one or more OIS-MS and/or operator workstations
according to the logic contained within. The OIS-AS may need to
communicate with elements of other providers, for instance to query
information about the capabilities and characteristics of the
caller's equipment, or to access another provider's operator
resources.
Operator and Information Services Media Server (OIS-MS) - The OIS-
MS provides the media resources for playing announcements,
performing voice recognition, performing listing database queries,
generating whisper from the user's verbal request, etc.
Haluska, et al. Expires January 5, 2008 [Page 21]
Internet-Draft Information Services Using SIP July 2007
Operator Workstations - Operator Workstations provide an interface
to the human operator. They may receive the customer's recorded
request (e.g. name and city of requested listing), information from
listing or other databases, and also terminate a multimedia session
with the customer. Operator workstations are specialized SIP
endpoints, and may be modeled in various ways, such as UAs or media
servers.
PSTN Gateways - OISPsneed to interface with the PSTN. Thus,
gateways are needed to interface between the OISP and both
signaling and bearer. The bearer is handled by trunk gateways,
which interface RTP streams on the OISP side to TDM trunks on the
PSTN side. The signaling may be handled by signaling gateways which
interface SS7 on the PSTN side and SIP on the OISP side. Currently
in North America, inband signaling on MF trunks is common for
interfacing to OISPs, and trunk gateways need to be able to
interpret and report as well as generate the appropriate MF
signaling.
Service Databases - Service Databases store service specific
information (e.g. listing information such as name, address, and
phone number, etc.) These may be located in the OISP's network
and/or in other networks, and more than one may be used.
SIP Proxy - One or more SIP proxies may be present in the OISP
network, to facilitate SIP communications with other providers as
well as to perform call processing functions between OISP
components.
The following figure shows a simplified view of an OISP internal
architecture. The lines show logical connectivity; elements
communicate via the proxy. A single OIS-AS is shown, along with up
to "k" OIS-MS and up to "m" Operator Work Stations, and an ACD
server.
Haluska, et al. Expires January 5, 2008 [Page 22]
Internet-Draft Information Services Using SIP July 2007
+-------+ +--------+ +---------+ +---------+
| Proxy |----| OIS-AS |-+-| OIS-MS1 |...| OIS-MSk |
+-------+ +--+-----+ | +---------+ +---------+
|
| | +---------+ +---------+
| +-| OWS1 |...| OWSk |
+--+--+ | +---------+ +---------+
| ACD | |
+-----+ | +--+---+
+-|PSTNGW|
+------+
Figure 5 Simplified view of OISP Internal Architecture
7. General Approach
This section describes one possible way to implement DA using SIP.
Other ways may be possible.
The general approach involves having the OIS-AS host most of the
processing logic, and to control the call in general. The OIS-AS
implements a third party call control (3PCC) functionality. It
terminates the signaling dialog from the caller, and originates
dialogs towards other components as necessary. There may be
multiple sequential sessions set up during the course of a DA call.
For example, the OIS-AS would initiate a new dialog towards a MS
for front-end automation. When it gets the 200 OK from the MS with
SDP, it passes that SDP back toward the caller. When the front end
automation has completed, the OIS-MS sends a BYE containing message
bodies conveying the success of the operation (i.e., was it able to
obtain the listing) as well as any data related to the operation.
In case of success, the body might carry the listing information,
or a URI pointing to it. In case of failure, it might carry a URI
pointing to the whisper file.
In case of failure, the OIS-AS would determine that the call needs
to be routed to a human operator. The OIS-AS first needs to
identify a suitable operator to handle this request. The ACD server
has this responsibility, and could be implemented as a redirect
server facing the OIS-AS, redirecting towards the best suited
Haluska, et al. Expires January 5, 2008 [Page 23]
Internet-Draft Information Services Using SIP July 2007
available operator. Facing the operator workstations, the ACD
server could be implemented as a presence server, maintaining
availability of each operator, as well as the associated
information for each (e.g. languages, skill level, cost, etc).
The OIS-AS would then send an INVITE toward the identified operator
workstation. This INVITE includes the caller's SDP as well as a URI
pointing to the whisper file. The workstation could play the
whisper to the operator as the call is answered. The operator
workstation's SDP would be passed back to the caller via a re-
INVITE or UPDATE request.
If the operator is successful in locating the desired listing, the
workstation would send a BYE containing message bodies with an
indication of success, and either the listing information of a
pointer to the same.
The OIS-AS would then initiate a call leg towards an OIS-MS for
back end automation. The INVITE would include the same body with
the listing information that was sent by the operator workstation.
The OIS-MS returns its SDP, which the OIS-AS would propagate back
over the originating leg via a re-INVITE or UPDATE request. The
back end automation process includes audibly playing out the
listing information, and possibly offering call completion service.
The OIS-MS sends a BYE with a message body indicating whether call
completion is desired.
If call completion is desired, the OIS-AS sends a REFER back over
the originating call leg to the caller, and clears the call.
These examples describe simple voice scenarios. Other media types
may be possible. For example, it may be desirable to send the
listing information via text message to the caller's terminal, or
to show a video clip. Such features require knowledge of the
calling terminal's capabilities and characteristics. The mechanism
described in RFC 3840 Indicating User Agent Capabilities in the
Session Initiation Protocol (SIP)can be used for this. The
capabilities might have been signaled in the initial INVITE
request. Otherwise, the OIS-AS can query for capabilities using an
OPTIONS request. Additionally, some non SIP mechanism might be
used, such as querying a database (e.g. IMS HSS) in the caller's
network.
References to a whisper file can be passed using the mechanism
described in RFC 4483 A Mechanism For Content Indirection in the
Session Initiation Protocol (SIP).
Haluska, et al. Expires January 5, 2008 [Page 24]
Internet-Draft Information Services Using SIP July 2007
Other information signaled via message bodies includes the success
or failure status of operations (such as identifying the requested
listing), or other data (such as the listing information).
Context information may be maintained on a per call basis. It could
include such information as the caller's preferred language, etc. A
URI pointing to the context information could be passed between
elements in the OISP infrastructure.
8. Signaling Mechanisms
This section discusses the signaling mechanisms required to provide
OIS services.
8.1. Calling Party's Identity
In many cases, downstream providers may need to know the calling
party's identity. This might be needed to influence call processing,
or for accounting purposes. Also, the calling party's identity in the
form of a SIP URI might be needed so that the identity of the home
provider can be determined.
The calling party's equipment populates the From header in SIP
messages. This is not trusted. There are several methods for providing
"network-asserted identities", which under the appropriate conditions
can be trusted.
The SIP Identity mechanism defined in [SIP-IDENT] provides a
standardized, architecture agnostic SIP mechanism for
cryptographically assuring the user's identity.
The P-Asserted-Identity header [PAI] is a private extension which can
be used to carry a network asserted identity of the caller between
trusted providers.
Note that some networks may allow their users to hide their identity.
In the current North American PSTN, for such cases the caller id
information is often transported through the network, marked with a
privacy indication such that it will not be presented to the called
party.
Bilateral agreements between VOIP providers determine whether
providers are within the same "trust domain" as defined in [RFC3324],
Haluska, et al. Expires January 5, 2008 [Page 25]
Internet-Draft Information Services Using SIP July 2007
and what information, including network-asserted identities, may be
exchanged between providers. Depending on such agreements, it is
possible that the caller identity information is obscured or
completely absent. As indicated in [PAI], "Masking identity
information at the originating user agent will prevent certain
services, e.g., call trace, from working in the Public Switched
Telephone Network (PSTN) or being performed at intermediaries not
privy to the authenticated identity of the user."
When an OISP is outside any trust domain with the caller's home
provider, or is not otherwise privy based on bilateral agreements to
network asserted identity information from the calling network when
the caller has requested privacy, it is unable to implement any call
processing logic based on such information.
If the OISP desires to reject anonymous calls, a mechanism is proposed
in "Rejecting Anonymous Requests in the Session Initiation Protocol
(SIP) - draft-ietf-sip-acr-code-03", which defines a specific response
code for this.
The following shows an example of an INVITE message contain a P-
Asserted-Identity header.
INVITE sip:da@provider-c.com SIP/2.0
Via: SIP/2.0/UDP proxy-b.provider-b.com:5060 ;branch=y9hG4bK74bf9
Via: SIP/2.0/UDP proxy-a.provider-a.com:5060 ;branch=x9hG4bK74bf9
Via: SIP/2.0/UDP client.provider-a.com:5060 ;branch=z9hG4bK74bf9
From: <sip:7327581234@provider-a.com>;tag=1234567
To: 411 <tel:+411>
Contact: <sip:7327581234@provider-a.com>
P-Asserted-Identity: "732758123" <sip:73237581234@provider-a.com>
Content-Type: application/sdp
Content-Length: ...
[SDP not shown]
8.2. Provider Identification
As discussed, in some deployment scenarios, the OISP makes use of
the identities of other providers involved in the call. This
section discusses how those identities can be conveyed using SIP.
Haluska, et al. Expires January 5, 2008 [Page 26]
Internet-Draft Information Services Using SIP July 2007
8.2.1. Home Provider
In many cases, the OISP needs to identify the caller's Home Provider.
This may be needed for branding purposes as well as to potentially
influence treatment in other ways.
The basic mechanism for determining the home provider is to derive it
from the right hand side (RHS) of the network asserted identity.
In SIP, identities are expressed as URIs. These can be SIP (or SIPS)
URIs, or "tel" URIs.
[1] defines the SIP URI, which is used for identifying SIP resources.
The RHS can be expressed as a DNS domain name or as an IPv4 or IPv6
address. The hostname format is most suitable for providing an
identity to reach the calling party. For instance the mechanisms
defined in [RFC3263] for locating SIP servers depends on the use of
domain names for the various types of DNS lookups such as NAPTR, SRV,
and A.
If a provider decides to provide network asserted identities expressed
as SIP URIs using IP addresses instead of hostnames, it forfeits the
use of such standardized mechanisms for reaching its users. It also
becomes difficult to derive the home provider identity from the
network asserted identity.
RFC3966 defines the "tel" URI, which is used for describing resources
identified by phone numbers. The "tel" URI format does not include a
hostname. Thus, if the network asserted identity includes only a "tel"
URI, no direct information about the home provider is provided.
The SIP Identity mechanism is intended for use with SIP URIs. The PAI
mechanism can use either a SIP URI, a "tel" URI, or both.
This document depends on the home provider providing a network
asserted identity containing a hostname. This includes the SIP
identity where the SIP URI contains a hostname, or a PAI header
containing at least a SIP URI with a hostname.
Very simply, the RHS of the hostname in the SIP URI is extracted and
used as the basis to influence call processing. In cases where the
caller's identity is not available, as discussed in the "Calling
Party's Identity" section, then the home provider's identity is
consequently also not available, and call processing logic based on
such information (such as branding) cannot take place.
Haluska, et al. Expires January 5, 2008 [Page 27]
Internet-Draft Information Services Using SIP July 2007
8.2.2. Intermediate Provider
In some cases, the OISP may need to know the identity of an
intermediate provider which the call has traversed. Recall that for
our purposes, we define "intermediate provider" as having a business
relationship with both the home provider (to handle OIS requests) and
with an OISP (which will actually provide the requested service.) This
may be needed to influence treatment.
The use of the SIP History-Info mechanism defined in RFC 4244, An
Extension to SIP for Request History Information, can be used for
this. As the call moves from one provider to the next and is
retargeted, corresponding entries are added to the SIP History-Info
header. If the domain name format is used for the retargeted entities,
then the History-Info header now includes a list of traversed SIP
domains or providers, which can be consulted by the OISP.
According to RFC 4244, entries should be added to the History-Info
header whenever the Request-URI is modified. Cases may exist where the
call is sent to another provider but the URI is not modified. In such
cases, the provider is not captured by the History-Info header.
The following figure illustrates the use of the History-Info header
for this purpose.
Haluska, et al. Expires January 5, 2008 [Page 28]
Internet-Draft Information Services Using SIP July 2007
Caller Provider-A Provider-B Provider-C
| | | |
| | | |
| | | |
|(1) INVITE tel:+411 | |
|------------->| | |
| | | |
| | | |
| |(2) INVITE sip:da@prov-b.net |
| |------------->| |
| | | |
| | | |
| | |(3) INVITE sip:da@prov-c.net
| | |------------->|
| | | |
| | | |
Figure 6 Use of History-Info header to identity traversed providers
1. The user dials "411", and the resulting INVITE to its home proxy is
for "tel: +411". No History-Info header is included yet.
INVITE tel:+411 SIP/2.0
(other message content omitted)
2. The home proxy retargets this to "sip:da@prov-b.net", and adds a
History-Info header which includes the targeted-from URI:
INVITE sip:DA@prov-b.net SIP/2.0
History-Info: <tel: +411>; index=1
(other message content omitted)
3. Proxy-B retargets this to "SIP: da@prov-c.net", and appends another
entry to the History-Info header:
INVITE sip:DA@prov-b.net SIP/2.0
History-Info: <tel: +411>; index=1, <sip:da@prov-b.net>; index=2
(other message content omitted)
Haluska, et al. Expires January 5, 2008 [Page 29]
Internet-Draft Information Services Using SIP July 2007
When this request arrives a Proxy-C in Provider C (OISP), it conveys
the following:
oThe Request-URI (SIP: da@prov-c.net) indicates this as a DA call
oThe History-Info header conveys the history of the request:
oIt started as a tel URI for digits "411"
oIt was then targeted to provider B
oIt is now targeted to provider C
Please note that if a transit provider were encountered, the transit
provider would simply route the request toward Provider C, and would
not perform retargeting. It would not modify the Request-URI nor the
SIP History-Info header contents.
8.3. Originating Station Type
In the current PSTN in North America, OIS 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. To
support interworking with the PSTN, it must be possible to convey the
Originating Station Type value.
It is also desirable to characterize certain types of originating SIP
based callers using these same values, e.g. prison, police, etc.
Ways to represent this information in SIP need to be explored. There
are currently two proposals being considered in the IETF which might
potentially satisfy this requirement.
oThe Calling Party's Category tel URI Parameter - draft-mahy-
iptel-cpc-06.txt (work in progress) [IPTEL-CPC]
This defines a new parameter "cpc" which is applied to the SIP or tel
URI of the calling user. It allows for values such as "ordinary",
"prison", "police", "test", "operator", "payphone", "unknown",
"hospital", "cellular", "cellular-roaming". An example from the
internet draft:
Haluska, et al. Expires January 5, 2008 [Page 30]
Internet-Draft Information Services Using SIP July 2007
INVITE sip:bob@biloxi.example.com SIP/2.0
To: "Bob" <sip:bob@biloxi.example.com>
From: <tel:+17005554141;cpc=payphone>;tag=1928301774
oConveying Calling Party Category (CPC) and Originating Line
Information (OLI) using the Security Assertion Markup Language
(SAML) - draft-schubert-sipping-saml-cphc-02.txt [CPC-SAML]
While [IPTEL-CPC] is simple to implement, [CPC-SAML] provides a
cryptographically verifiable assertion. Both are currently works in
progress, and any document with normative dependencies to such works
cannot be published until the works in progress are published.
Further, there is an open question as to whether [IPTEL-CPC] can carry
OLI information as well as CPC or ANI II information.
8.4. Trunk Group Identifier
The incoming trunk group number provides information which could be
used to influence call processing, thus this information is needed.
Trunks are point to point circuits and as such, their remote
termination point is unambiguously known. As such, knowledge of the
incoming trunk group conveys the identity of the provider offering the
call.
For PSTN interworking, the incoming trunk group identifier is a key
piece of information and must be known. Thus, at a PSTN to IP
interworking point, the trunk group information must be kept and
signaled forward. This holds for OISP's accepting incoming calls from
the PSTN as well as upstream providers accepting calls from the PSTN.
RFC 4904, "Representing trunk groups in tel/sip Uniform Resource
Identifiers (URIs)" defines a way to signal incoming and/or outgoing
trunk group information as a parameter in SIP URIs and tel URIs.
To represent incoming trunk groups, the trunk group parameter is
included in the Contact header of the SIP message. The "trunk-context"
parameter should also be included, to ensure that the trunk group is
unambiguously identified, since trunk group numbers are not globally
unique.
The following example shows an INVITE containing a trunk group
identification in the Contact header:
Haluska, et al. Expires January 5, 2008 [Page 31]
Internet-Draft Information Services Using SIP July 2007
INVITE sip:da@provider-c.com SIP/2.0
Via: SIP/2.0/UDP proxy-b.provider-b.com:5060 ;branch=y9hG4bK74bf9
Via: SIP/2.0/UDP proxy-a.provider-a.com:5060 ;branch=x9hG4bK74bf9
Via: SIP/2.0/UDP client.provider-a.com:5060 ;branch=z9hG4bK74bf9
From: <sip:7327581234@provider-a.com>;tag=1234567
To: 411 <tel:+411>
Contact: < sip:7327581234@provider-b.com;tgrp=101; trunk-
context=provider-b.com@proxy-b.provider-b.com;user=phone>
P-Asserted-Identity: "7327581234" <sip:73237581234@provider-a.com>
Content-Type: application/sdp
Content-Length: ...
8.5. Dialed Digits
Currently in the North American PSTN, the OIS provider may take into
account the digits dialed by the user. In that scenario the dialed
digits are frequently forwarded to the OIS provider.
Using SIP, the dialed digits would typically be sent by the user's
equipment in the form of a tel URI or SIP URI in the Request-URI of a
SIP INVITE. It is possible that retargeting could take place, in which
case the dialed digits would be lost.
The SIP History-Info mechanism defined in RFC 4244 provides a
mechanism for solving exactly this type of problem. It defines a new
optional SIP header, History-Info, to provide a standard mechanism for
capturing the request history information. Whenever a node which
supports this mechanism modifies the Request-URI of a request, it
captures this in the History-Info header.
The following example shows an INVITE containing a History-Info
header, which conveys the original dialed digits, after having been
retargeted.
INVITE sip:DA@prov-b.net SIP/2.0
(other message content omitted)
History-Info: <tel: +411>; index=1, <sip:da@prov-b.net>; index=2
Please see the section titled "Arbitrary Involved Provider" for an
example of a flow where the History-Info mechanism delivers the dialed
digits to the OISP when retargeting has occurred.
Haluska, et al. Expires January 5, 2008 [Page 32]
Internet-Draft Information Services Using SIP July 2007
8.6. Retargeting to Identify the Desired Service
It is necessary to identify the service being requested. Such services
might include directory assistance with or without call completion.
The logic to determine this might reside in one or more points in the
network. Additionally, the identification of the service might be
refined as the request traverses potentially multiple networks,
depending on the availability of additional information.
It is proposed here to retarget the Request-URI of the SIP request to
specify the desired service. While the initial Request-URI might
specify "SIP:411@provider-a.net", a downstream element might invoke
service logic and determine that this call should be sent to OISP C's
network for directory assistance with call completion, and change the
Request-URI to "SIP:da-with-call-completion@oisp-c.net".
A similar approach is taken for identifying resources in [NETANN].
[CSI], a work in progress, discusses explicit service identifiers for
using in IMS based networks.
8.7. Charge Number
There is a need to convey a charge number, which may differ from
the calling party's identity. The charge number usually identifies
the customer or account with which the caller is associated, e.g.
the main number for a business which has many individual calling
numbers. This might be needed for accounting, but it also could
influence call processing, especially when a particular type of
service applies for any caller associated with a particular charge
number.
There is currently no IETF standardized mechanism to convey the
Charge Number in SIP. This is currently under investigation. The
need to convey equivalent information for SIP based callers is also
under investigation.
8.8. Passing Whisper
During front end automation, the OIS-MS will record and may time
compress the caller's perhaps meandering speech into what is known
Haluska, et al. Expires January 5, 2008 [Page 33]
Internet-Draft Information Services Using SIP July 2007
as the "whisper". This is intended to be played into a human
operator's ear, should the call be referred to an operator, to
avoid the operator from having to prompt the caller again. The
whisper is obtained during the front end automation, and saved to
an audio file.
If the call needs to be transferred to a human operator, the
whisper will need to be played to the operator at the same time or
slightly prior to connecting the caller to the operator. Thus, the
operator workstation needs to be able to access the whisper file.
When the OIS-MS performs front end automation, it generates the
whisper and saves it as an audio file. The location, storage type,
and format are out of the scope of this document. What is needed is
a way for the OIS-MS to convey the whisper information to the OIS-
AS, so it could potentially be used for later processing, such as
passing to a human operator.
Due to size constraints, it may not be feasible or desirable to
pass the actual audio file containing the whisper. This document
will discuss the most general case of passing a pointer, in the
form of a URI, to the audio content. What follows is a description
of one possible way to implement this. The work of the recently
formed IETF MEDIACTRL working group may provide alternatives.
Since the whisper is an output of the front end automation process,
it makes sense to return this upon completion of that process. The
most reasonable time to do this is when the OIS-MS sends the BYE.
Any SIP request, including BYE, can contain a message body. RFC
4483 A Mechanism for Content Indirection in Session Initiation
Protocol (SIP) Messages defines an extension to the URL MIME
External-Body Access-Type to satisfy the content indirection
requirements for SIP. These extensions are aimed at allowing any
MIME part in a SIP message to be referred to indirectly via a URI.
This is illustrated in the following figure. Note that the proxy
has been omitted for clarity, as have some messages not crucial to
illustrating the use of this mechanism. All SIP signaling traverses
the proxy.
Haluska, et al. Expires January 5, 2008 [Page 34]
Internet-Draft Information Services Using SIP July 2007
AS MS Operator
| | |
| | |
| | |
|(1) INVITE | |
|------------->| |
| | |
| | |
|(2) 200 OK | |
|<-------------| |
| | |
| | |
|MS prompts user, collects whisper
| | |
| | |
| | |
|(3) BYE, body w. status, whisper URI
|<-------------| |
| | |
| | |
|(4) 200 OK | |
|------------->| |
| | |
| | |
|(5) INVITE w. whisper URI |
|---------------------------->|
| | |
| | |
|(6) 200 OK SDP| |
|<----------------------------|
| | |
| | |
| | |
| | |
Figure 7 Call flow illustrating passing of whisper
1. INVITE AS->MS
INVITE sip:da@ms-1.oisp-c.net SIP/2.0
[remainder of message omitted]
Haluska, et al. Expires January 5, 2008 [Page 35]
Internet-Draft Information Services Using SIP July 2007
2. 200 OK MS->AS
SIP/2.0 200 OK
[remainder of message omitted]
3. BYE MS->AS
BYE sip:as-1@as-1.oisp-c.net SIP/2.0
[non relevant portions of message omitted]
Content-Type: message/external-body; access-type="URL";
URL="http://ms1.oisp-c.net/whisper/20070206092700-0001.wav"
expiration="Tues, 06 Feb 2007 09:30:00 GMT";
<CRLF>
Content-Type: audio/x-wav
Content-Disposition: render
<CRLF>
4. 200 OK AS->MS
SIP/2.0 200 OK
[remainder of message omitted]
5. INVITE AS->Operator Workstation
INVITE sip:operator@operator-123.oisp-c.net SIP/2.0
[non relevant portions of message omitted]
Content-Type: message/external-body; access-type="URL";
URL="http://ms1.oisp-c.net/whisper/20070206092700-0001.wav"
expiration="Tues, 06 Feb 2007 09:30:00 GMT";
<CRLF>
Content-Type: audio/x-wav
Content-Disposition: render
<CRLF>
6. 200 OK Operator->AS
SIP/2.0 200 OK
[remainder of message omitted]
Note that this same mechanism also supports the case where front
end automation is performed by one provider, and another provider
provides the operator assistance. In this type of scenario,
provisions need to made such that the second provider can access
the resources referenced by the URI.
Haluska, et al. Expires January 5, 2008 [Page 36]
Internet-Draft Information Services Using SIP July 2007
8.9. Calling Equipment Capabilities and Characteristics
It may be necessary for the OIS provider to learn the capabilities
and characteristics of the caller's equipment. This would be useful
when the OIS provider wishes to provide content to the caller other
than that which was used on the call to the OISP. For example, the
OIS provider might wish to send listing information via text
message, or play a video clip about a particular venue about which
he has requested information.
RFC 3840 Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP), defines mechanisms by which a UA can
convey its capabilities and characteristics to other user agents
and to the registrar for its domain. This information is conveyed
as parameters of the Contact header field.
This information might be included in the incoming INVITE to the
OISP, if the caller's UA supports this mechanism and is configured
to do so. Otherwise, the OISP could query the caller's UA by
sending a SIP OPTIONS request, and the UA, if it supports this
mechanism, would include its capability feature tags in the
response to the OISP.
The following is an example of an INVITE containing capability
feature tags, as it arrives at the OISP. In this case, the UA
supports audio, video, and text. Other included tags provide
additional information.
INVITE sip:da@provider-c.com SIP/2.0
Via: SIP/2.0/UDP proxy-b.provider-b.com:5060 ;branch=y9hG4bK74bf9
Via: SIP/2.0/UDP proxy-a.provider-a.com:5060 ;branch=x9hG4bK74bf9
Via: SIP/2.0/UDP client.provider-a.com:5060 ;branch=z9hG4bK74bf9
From: <sip:7327581234@provider-a.com>;tag=1234567
To: 411 <tel:+411>
Contact: <sip:7327581234@provider-a.com>;audio;video;text
;actor="principle";automata;mobility="fixed"
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
P-Asserted-Identity: "7327581234" <sip:73237581234@provider-a.com>
P-Asserted-Identity: tel:+7327581234
Content-Type: application/sdp
Content-Length: ...
[SDP not shown]
Haluska, et al. Expires January 5, 2008 [Page 37]
Internet-Draft Information Services Using SIP July 2007
If the OISP wishes to query the UA, it can send an OPTIONS request
to the UA, and the UA, if it supports this mechanism, would include
the feature capability tags in the Contact header, as show above,
in the 200 OK response.
8.10. Media Server Returning Data to the Application Server
The OIS-AS needs to know the outcome of the operations performed by
the OIS-MS, e.g. success/failure of front end automation, etc. Some
mechanism is needed to convey this information. This could be
conveyed using non SIP mechanisms.
Any SIP message, including BYE, can carry message bodies. The
simplest way for a OIS-MS to return data to an OIS-AS is to
encapsulate the data in a MIME body. This requires agreement
between both sides on the format and semantics of these bodies.
Another approach is to use the content indirection mechanism to
point to the data, however this may be rather cumbersome if only a
small amount of data is to be returned.
Some OIS service may make use of VoiceXML, whereby the OIS-AS
invokes VoiceXML scripts on the OIS-MS, and the OIS-MS returns data
to the OIS-AS. SIP Interface to VoiceXML Media Services - draft-
burke-vxml-02.txt (work in progress) describes a SIP interface to
VoiceXML media services, which is commonly employed between
application servers and media servers offering VoiceXML processing
capabilities. This may be found useful for OIS services.
The topic of application server control of media services is
currently under study, and is the subject of the IETF MEDIACTRL
working group's efforts.
This information can also be conveyed using non SIP mechanisms.
Describing such mechanisms is out of the scope of this document.
8.11. Service Discovery
An OISP might desire that its service be discoverable on the
internet, instead of or in addition to static provisioning into
provider networks. The Service URN concept discussed in the work in
Haluska, et al. Expires January 5, 2008 [Page 38]
Internet-Draft Information Services Using SIP July 2007
progress "A Uniform Resource Name (URN) for Services - draft-ietf-
ecrit-service-urn-05" can be used to facilitate this. This allows
for discovery of the service in a context dependent manner, where
context could include for example the user's location. Thus a user
agent could send a SIP request to "urn: service: info", and this
very generic URI could be resolved to a point to a specific network
element belonging to a specific provider. If some other context
information such as the user's location is available, this could be
used to refine the resolution to e.g. an element best suited for
that particular location.
9. Example Call Flow - Directory Assistance
The following call flow provides examples of how a DA service could
be implemented using the mechanisms described in this document. It
is intended to illustrate the intended use of the proposed
signaling mechanism. Some messages not crucial to this may be
omitted for clarity.
Haluska, et al. Expires January 5, 2008 [Page 39]
Internet-Draft Information Services Using SIP July 2007
Caller Proxy A Proxy B Proxy C OIS-AS OIS-MS1
| | | | | |
| | | | | |
| | | | | |
|(1) INVITE tel:411 | | | |
|-------->| | | | |
| | | | | |
| |(2) INVITE sip:da@prov-b.com | |
| |-------->| | | |
| | | | | |
| | |(3) INVITE sip:da@prov-c.com |
| | |-------->| | |
| | | | | |
| | | |(4) INVITE sip:da-cc@prov-c.com
| | | |-------->| |
| | | | | |
| | | | |(5) INVITE prompt &
collect
| | | | |-------->|
| | | | | |
| | | | |(6) 200 OK w.SDP
| | | | |<--------|
| | | | | |
| | | |(7) 200 OK w.SDP |
| | | |<--------| |
| | | | | |
| | |(8) 200 OK w.sdp | |
| | |<--------| | |
| | | | | |
| |(9) 200 OK w.sdp | | |
| |<--------| | | |
| | | | | |
|(10) 200 OK w.sdp | | | |
|<--------| | | | |
| | | | | |
| | | | | |
| | | | | |
Figure 8 DA Call flow, part 1
For brevity, only relevant SIP headers will be shown. The following
test refers to Figure 8.
Haluska, et al. Expires January 5, 2008 [Page 40]
Internet-Draft Information Services Using SIP July 2007
The user, homed in provider A, initiates a request for an OIS
service, for instance by dialing "411". The user's UA sends a SIP
INVITE. It might contain a "tel" URI.
1. INVITE UE -> Home Proxy
INVITE tel:+411 SIP/2.0
Via: SIP/2.0/UDP client.provider-a.com:5060
;branch=z9hG4bK74bf9
From: <sip:7327581234@provider-a.com>;tag=1234567
To: 411 <tel:+411>
Contact: <sip:7327581234@provider-a.com>
Content-Type: application/sdp
Content-Length: ...
The home provider knows nothing of OISP services, for instance it
might be a rather small scale provider. It is essentially set up to
forward all calls of this type to Provider B. It translates the
Request-URI to a SIP URI and sends the call on to provider B.
Because of this retargeting, it adds a History-Info header to
capture the dialed digits.
The caller's identity is verified in a manner consistent with this
provider's policies, and the proxy adds two P-Asserted-Identity
headers: one with a SIP URI, and another with a "tel" URI.
Haluska, et al. Expires January 5, 2008 [Page 41]
Internet-Draft Information Services Using SIP July 2007
2. INVITE proxy-a -> proxy-b
INVITE sip:411@provider-b.com SIP/2.0
Via: SIP/2.0/UDP proxy-a.provider-a.com:5060 ;branch=x9hG4bK74bf9
Via: SIP/2.0/UDP client.provider-a.com:5060
;branch=z9hG4bK74bf9
From: <sip:7327581234@provider-a.com>;tag=1234567
To: 411 <tel:+411>
Contact: <sip:7327581234@provider-a.com>
P-Asserted-Identity: "732758123" <sip:73237581234@provider-a.com>
P-Asserted-Identity: tel:+7327581234
History-Info: <tel: +411>; index=1
Content-Type: application/sdp
Content-Length: ...
Proxy-b in provider-b's network receives the request. This is a
larger network, and it has business relationships with several OIS
providers, as well as with several providers which serve
subscribers. This provider has logic which requires it to query the
Home Provider's network to find some information related to the
caller. This is not likely to be a SIP related function, and is
thus out of scope for this document. The logic executes, taking the
result of this query into account. It is determined that the call
is for directory assistance, and that the call should be routed to
provider C for handling.
So, proxy-b retargets the Request-URI to reflect this, and routes
the call to provider C (the OISP). It adds another entry to the
History-Info header to capture this retargeting.
Haluska, et al. Expires January 5, 2008 [Page 42]
Internet-Draft Information Services Using SIP July 2007
3. INVITE proxy-b -> proxy-c
INVITE sip:da@provider-c.com SIP/2.0
Via: SIP/2.0/UDP proxy-b.provider-b.com:5060 ;branch=y9hG4bK74bf9
Via: SIP/2.0/UDP proxy-a.provider-a.com:5060 ;branch=x9hG4bK74bf9
Via: SIP/2.0/UDP client.provider-a.com:5060
;branch=z9hG4bK74bf9
From: <sip:7327581234@provider-a.com>;tag=1234567
To: 411 <tel:+411>
Contact: <sip:7327581234@provider-a.com>
P-Asserted-Identity: "732758123" <sip:73237581234@provider-a.com>
P-Asserted-Identity: tel:+7327581234
History-Info: <tel: +411>; index=1, <sip:da@provider-a.com>;
index=2
Content-Type: application/sdp
Content-Length: ...
Proxy-c in provider C's network receives the request. The source of
the request is authenticated via mechanisms not described here. It
needs to know how to bill this call, and thus needs to know which
provider it came from. It looks at the topmost Via header, and sees
that the call came from provider B.
It examines the History-Info header, and is able to identity the
dialed digits. It can also determine from the SIP URI which domains
have been traversed, as long as each has retargeted and appended an
entry in the header.
The proxy determines that the call needs to go the OIS-AS for
handling, so it retargets if necessary and forwards the INVITE.
The OIS-AS performs 3PCC. It determines that the call needs a
branded announcement based on the identity of the home provider,
which it derives from the P-Asserted-Identity header. It initiates
a new call leg toward OIS-MS1 for front end automation. Per RFC
4240, the "dialog" portion of the Request-URI indicates the "prompt
& collect" service. The URI identifies the VoiceXML script to be
executed. The SDP is the caller's SDP.
Haluska, et al. Expires January 5, 2008 [Page 43]
Internet-Draft Information Services Using SIP July 2007
5. INVITE OIS-AS -> MS1
INVITE sip:dialog@ois-as.prov-c.com; \
voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml \
SIP/2.0
Via: SIP/2.0/UDP ois-as.prov-c.com:5060
;branch=z9hG4bK74bf9
From: <sip:ois-as@ois-as.prov-c.com>;tag=1234567
To: sip:dialog@ois-as.prov-c.com; \
voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml
Contact: <sip:ois-as@ois-as.prov-c.com>
Content-Type: application/sdp
Content-Length: ...
The OIS-MS responds with a 200 OK, with its own SDP. The OIS-AS now
sends a 200 OK response back toward the caller, with the MS's SDP.
Note that the OIS-AS could first have sent non final response back
toward the user.
Haluska, et al. Expires January 5, 2008 [Page 44]
Internet-Draft Information Services Using SIP July 2007
Caller OIS-AS OIS-MS1 ACD OWS
| | | | |
| | | | |
| | | | |
|(11) RTP session | | |
|...................| | |
| | | | |
| |(12) INFO w.URI, body |
| |<--------| | |
| | | | |
| |(13) INVITE | |
| |------------------>| |
| | | | |
| |(14) 3xx | | |
| |<------------------| |
| | | | |
| |(15) INVITE | |
| |---------------------------->|
| | | | |
| |(16) 200 OK | |
| |<----------------------------|
| | | | |
| |(17) BYE | | |
| |-------->| | |
| | | | |
| |(18) 200 OK | |
| |<--------| | |
| | | | |
|(19) re INVITE | | |
|<--------| | | |
| | | | |
|(20) 200 OK | | |
|-------->| | | |
| | | | |
|(21) RTP session | | |
|.......................................|
| | | | |
| |(22) BYE | | |
| |<----------------------------|
| | | | |
| |(23) 200 OK | |
| |---------------------------->|
| | | | |
| | | | |
| | | | |
Haluska, et al. Expires January 5, 2008 [Page 45]
Internet-Draft Information Services Using SIP July 2007
Figure 9 DA Call flow, part 2
The following text refers to Figure 9.
The user is now connected (11) to the MS, which plays a branded
announcement, and prompts for the listing information. When the
user speaks his request, the MS processes the audio to obtain a
"whisper" file, or condensed version of the request. In this
example, the MS is unable to successfully perform the query, so it
sends an indication of this to the AS. In this example, the
indication is sent using an as yet unspecified protocol message
carried in a message body in a SIP INFO message, which also carries
a URI which points to the whisper file. Other mechanisms, including
non SIP mechanisms, could also be used to this end (this is the
subject of further study). The AS allows the caller to remain
connected to the MS while it sets up a call to an operator
workstation (OWS), allowing for the possibility to play custom
announcements to the caller.
The OIS-AS decides based on the failure indication that it needs to
route the call to a human operator. It sends an INVITE (13) to the
ACD server. This INVITE carries information about the required
characteristics, such as language and skill set, of the operator
which should be selected for this call. The means by which this
information is carried has yet to be defined. One possible way an
ACD could be implemented is as a presence server, such that it
keeps track of the availability of all the operators. The Media
Resource Broker being discussed in the IETF MEDIACTRL working group
also represents an approach to ACD.
In this example, the ACD server is implemented as a redirect server
- it sends a 3XX response (14) which identifies the operator the
OIS-AS should contact. Alternately, the ACD server could have
proxied the request to the operator.
The OIS-AS now sends an INVITE (15) containing the URI to the
whisper, as well as the caller's SDP, to the indicated operator
workstation. The operator workstation sends a 200 OK (16) with its
SDP, which the OIS-AS sends toward the caller in a re-INVITE (19).
Only when the workstation has sent a final response to the INVITE,
the AS sends a BYE (17) to the MS.
The caller is now connected to the operator (21), and the operator
helps the caller with the listing. The operator workstation
launches a query, and a response is received. The operator signals
Haluska, et al. Expires January 5, 2008 [Page 46]
Internet-Draft Information Services Using SIP July 2007
a BYE (22) toward the OIS-AS, which may contain the listing
information in a message body, a pointer (URI) to the listing
information, or it may pass this information to the OIS-AS using
some other, non SIP mechanism.
Caller OIS-AS OIS-MS2
| | |
| | |
| | |
| |(24) INVITE
| |-------->|
| | |
| |(25) 200 OK
| |<--------|
| | |
|(26) re INVITE |
|<--------| |
| | |
|(27) 200 OK |
|-------->| |
| | |
|(28) RTP session |
|...................|
| | |
| |(29) BYE w.body
| |<--------|
| | |
|(30) REFER |
|<--------| |
| | |
| | |
| | |
Figure 10DA Call flow, part 3
Haluska, et al. Expires January 5, 2008 [Page 47]
Internet-Draft Information Services Using SIP July 2007
The following text refers to Figure 10.
The OIS-AS sends an INVITE (24) to another OIS-MS, MS2, for back
end automation. When it receives MS2's SDP in the 200 OK (25), it
sends a re INVITE (26) toward the user to update the SDP. At this
point an audio session is in place between the caller and the back
end automation MS (28). The MS plays the listing information, and
offers call completion service. The caller accepts, so OIS-MS2
sends a BYE (29) with a message body containing the result of the
call completion offer. Since call completion was requested, the
OIS-AS sends a REFER (30) to the caller, to cause it to place a
call to the listed party. The OIS-AS may or may not care about
subsequent NOTIFYs from the caller, and drops out of the call.
10. Example Call Flow - Operator Services
The following call flow provides examples of how a specific
operator service, Operator Assisted Collect Call, could be
implemented using the mechanisms described in this document. The
purpose is to illustrate one way to implement this service using
the proposed signaling mechanisms. In practice, this particular
service could be implemented in an automated fashion without human
intervention.
Haluska, et al. Expires January 5, 2008 [Page 48]
Internet-Draft Information Services Using SIP July 2007
Caller Proxy AS WS Called MS ACD
| | | | | | |
| | | | | | |
| | | | | | |
|[ Caller dials 0+ or 0- ] | | | |
| | | | | | |
| | | | | | |
|(1) INVITE | | | | |
|------------------>| | | | |
| | | | | | |
|(2) 100 Trying | | | | |
|<------------------| | | | |
| | | | | | |
|[ AS determines operator is needed, performs 3PCC ] |
| | | | | | |
| | | | | | |
| | |(3) INVITE | | |
| | |-------------------------------------->|
| | | | | | |
| | |(4) 3xx redirect to WS where selected
operator registered
| | |<--------------------------------------|
| | | | | | |
| | |(5) INVITE | | |
| | |-------->| | | |
| | | | | | |
| | |(6) 200 OK | | |
| | |<--------| | | |
| | | | | | |
| | |(7) ACK | | | |
| | |-------->| | | |
| | | | | | |
|(8) 200 OK | | | | |
|<------------------| | | | |
| | | | | | |
|(9) ACK | | | | | |
|------------------>| | | | |
| | | | | | |
|[ Caller is now connected to operator ]| | |
| | | | | | |
| | | | | | |
|(10) RTP | | | | | |
|.............................| | | |
| | | | | | |
|[ Operator determines calling's request and places on hold]|
| | | | | | |
Haluska, et al. Expires January 5, 2008 [Page 49]
Internet-Draft Information Services Using SIP July 2007
| | | | | | |
| | |(11) re-INVITE (HOLD) | |
| | |<--------| | | |
| | | | | | |
| | |(12) 200 OK | | |
| | |-------->| | | |
| | | | | | |
| | |(13) ACK | | | |
| | |<--------| | | |
| | | | | | |
|[ AS logic determines announcements should be played instead ]
| | | | | | |
| | | | | | |
| | |(14) INVITE (play announcements) |
| | |---------------------------->| |
| | | | | | |
| | |(15) 200 OK (SDP-MS) | |
| | |<----------------------------| |
| | | | | | |
| | |(16) ACK | | | |
| | |---------------------------->| |
| | | | | | |
|(17) reINVITE (SDP-MS) | | | |
|<------------------| | | | |
| | | | | | |
|(18) 200 OK (SDP-calling) | | | |
|------------------>| | | | |
| | | | | | |
|(19) ACK | | | | | |
|<------------------| | | | |
| | | | | | |
|(20) RTP (MS plays announcements to calling) | |
|.................................................| |
| | | | | | |
|[ Operator calls called party ] | | |
| | | | | | |
| | | | | | |
| | | |(21) INVITE | |
| | | |-------->| | |
| | | | | | |
| | | |(22) 200 OK | |
| | | |<--------| | |
| | | | | | |
| | | |(23) ACK | | |
| | | |-------->| | |
| | | | | | |
| | | |(24) RTP | | |
Haluska, et al. Expires January 5, 2008 [Page 50]
Internet-Draft Information Services Using SIP July 2007
| | | |.........| | |
| | | | | | |
|[ Called agrees to accept charges ] | | |
| | | | | | |
| | | | | | |
|[ Operator takes Calling off hold ] | | |
| | | | | | |
| | | | | | |
| | |(25) re-INVITE (un-HOLD) | |
| | |<--------| | | |
| | | | | | |
|[ AS logic directs Calling from MS back to WS ] | |
| | | | | | |
| | | | | | |
|(26) re-INVITE (SDP-ws) | | | |
|<------------------| | | | |
| | | | | | |
|(27) 200 OK | | | | |
|------------------>| | | | |
| | | | | | |
| | |(28) 200 OK | | |
| | |-------->| | | |
| | | | | | |
| | |(29) ACK | | | |
| | |<--------| | | |
| | | | | | |
|(30) ACK | | | | | |
|<------------------| | | | |
| | | | | | |
|(31) RTP | | | | | |
|.............................| | | |
| | | | | | |
|[ AS releases MS ] | | | | |
| | | | | | |
| | | | | | |
| | |(32) BYE | | | |
| | |---------------------------->| |
| | | | | | |
| | |(33) 200 OK | | |
| | |<----------------------------| |
| | | | | | |
|[ Calling and Called both have RTP session with WS ] |
| | | | | | |
| | | | | | |
|[ WS bridges conversations together internally ] | |
| | | | | | |
| | | | | | |
Haluska, et al. Expires January 5, 2008 [Page 51]
Internet-Draft Information Services Using SIP July 2007
|[ After brief interlude WS transfers Calling directly to Called
]
| | | | | | |
| | | | | | |
|[ then drops out ] | | | | |
| | | | | | |
| | | | | | |
| | |(34) REFER (to called) | |
| | |<--------| | | |
| | | | | | |
| | |(35) 202 Accepted | | |
| | |-------->| | | |
| | | | | | |
| | |(36) NOTIFY (trying) | |
| | |-------->| | | |
| | | | | | |
| | |(37) 200 OK | | |
| | |<--------| | | |
| | | | | | |
|[ Replaces header causes Called to replace old call with new ]
| | | | | | |
| | | | | | |
| | |(38) INVITE (replaces: WS ) | |
| | |------------------>| | |
| | | | | | |
| | |(39) 200 OK (SDP-called) | |
| | |<------------------| | |
| | | | | | |
| | |(40) ACK | | | |
| | |------------------>| | |
| | | | | | |
| | | |(41) BYE | | |
| | | |<--------| | |
| | | | | | |
| | | |(42) 200 OK | |
| | | |-------->| | |
| | | | | | |
|[ The following interactions synch up SDP - optimization
possible ]
| | | | | | |
| | | | | | |
|(43) re-INVITE (SDP-called) | | | |
|<------------------| | | | |
| | | | | | |
|(44) 200 OK (SDP-calling) | | | |
|------------------>| | | | |
| | | | | | |
Haluska, et al. Expires January 5, 2008 [Page 52]
Internet-Draft Information Services Using SIP July 2007
|(45) ACK | | | | | |
|<------------------| | | | |
| | | | | | |
| | |(46) re-INVITE (SDP-calling) | |
| | |------------------>| | |
| | | | | | |
| | |(47) 200 OK | | |
| | |<------------------| | |
| | | | | | |
| | |(48) ACK | | | |
| | |------------------>| | |
| | | | | | |
|(49) RTP | | | | | |
|.......................................| | |
| | | | | | |
|[ Calling and Called are now talking directly ] | |
| | | | | | |
| | | | | | |
| | |(50) NOTIFY (Call completed) | |
| | |-------->| | | |
| | | | | | |
| | |(51) 200 OK | | |
| | |<--------| | | |
| | | | | | |
|[ Operator now drops out ] | | | |
| | | | | | |
| | | | | | |
| | | |(52) BYE | | |
| | | |-------->| | |
| | | | | | |
| | | |(53) 200 OK | |
| | | |<--------| | |
| | | | | | |
|[ AS remains in signaling path until call ends ] | |
| | | | | | |
| | | | | | |
|(54) BYE | | | | | |
|------------------>| | | | |
| | | | | | |
| | |(55) BYE | | | |
| | |------------------>| | |
| | | | | | |
| | |(56) 200 OK | | |
| | |<------------------| | |
| | | | | | |
|(57) 200 OK | | | | |
|<------------------| | | | |
Haluska, et al. Expires January 5, 2008 [Page 53]
Internet-Draft Information Services Using SIP July 2007
| | | | | | |
| | | | | | |
| | | | | | |
Figure 11 Operator Service Call flow (Operator Assisted Collect
Call)
The caller initiates the call by dialing 0+ or 0-.
The call is routed to the AS. The AS examines the calling party
number and calling party's home provider, which are derived from
the P-Asserted-Identity header. The charge number is also needed,
in case the caller's service is determined by agreements with
another party, such as the caller's employer. The employer may have
a large number of calling identities representing its employees,
which are covered under its agreement with the OISP. Rather than
provision every possible calling number/identity with the OISP (and
this may be constantly changing), the ability to pass a charge
number would allow the OISP to determine whether this charge number
has any associated treatment on a per charge number basis.
In any case, in our example, the AS examines the request and
determines that the call is for an operator assisted collect call.
Typically a MS could be initially connected to prompt the user for
the type of call. This step is omitted in this example.
The AS performs third party call control (3PCC). It sends a 18x
response towards the caller. It needs to initiate a call leg to an
operator workstation. It populates the selection criteria in an
INVITE message (the exact mechanism for this is under study) which
it sends to the ACD server in (3). The ACD server identifies the
best match available operator and returns the contact information
for the workstation where that operator is currently registered in
a 3xx redirection response.
In (5) the AS sets up a call to the workstation identified by the
ACD server, and using 3PCC connects the caller to the WS, resulting
in an RTP session in (10).
The operator determines the caller's requested number, and sends an
INVITE toward the AS to put the caller on hold. The logic in the AS
determines that instead the caller should be connected to custom
announcements, and in (14) through (20) creates a session between
the caller and a MS.
Haluska, et al. Expires January 5, 2008 [Page 54]
Internet-Draft Information Services Using SIP July 2007
Meanwhile, in (21) the WS places a call to the called party, and
asks whether the called party would accept the charges for a
collect call. In this example, the called party agrees to the
request.
In (25), the operator takes the caller off hold (recall that it
believes it has placed the caller on hold). The AS, in (26) through
(33), performs 3PCC, and removes the caller from the MS which is
playing custom announcements, and reconnects the caller back to the
WS. The WS uses its own internal bridging functionality to
conference the operator, calling, and called parties.
After a brief interlude, the operator initiates a transfer of the
calling and called parties directly together using a REFER in (34)
through (37). The AS, performing 3PCC, utilizes the SIP Replaces
mechanism beginning in (38) to complete the transfer. When the
transfer is complete, the operator drops out completely. Note that
the AS, performing 3PCC, remains in the signaling path until the
call is torn down in (54) through (57).
11. VoIP Information Services - Summary and Next Steps
A list of information which needs to be conveyed has been developed,
and candidate proposals identified for each of these.
The desired next steps include soliciting feedback from the IETF
community on the choices and intended usages of the proposed
mechanisms.
An initial set of required capabilities for Operator Services has been
identified. The next revision of this document is expected to contain
a complete set of required capabilities. Once such a set is
identified, existing SIP mechanisms will be examined for supporting
these capabilities.
Future revisions of this document will need to include security
considerations as well as IANA considerations. Example messages and
message flows will be more complete. The References section will also
need to be complete.
Haluska, et al. Expires January 5, 2008 [Page 55]
Internet-Draft Information Services Using SIP July 2007
12. Security Considerations
This revision of this document does not yet address security
considerations. A subsequent revision will do so, and will likely
include the following among items it considers:
Usage of headers such as P-Asserted-Identity which are intended to use
between trusted providers.
Potentially revealing information about subscribers or service
provider infrastructure via signaling messages.
Security of signaling and bearer.
Implications of inter provider signaling.
13. IANA Considerations
This revision of this document does not yet address IANA
considerations. It is not anticipated that this document will define
any new protocol extensions or other values requiring action of IANA.
Haluska, et al. Expires January 5, 2008 [Page 56]
Internet-Draft Information Services Using SIP July 2007
14. References
14.1. Normative References
[1] Rosenberg, et al, J., "SIP: Session Initiation Protocol", RFC
3261, June 2002.
[TRKGRP] Gurbani, Jennings, "Representing trunk groups in tel/sip
Uniform Resource Identifiers (URIs)", draft-ietf-iptel-
trunk-group-08.txt, October 2006. (work in progress)
[SIP-IDENT] Peterson, Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol
(SIP)", RFC 4474, August 2006.
[PAI] Jennings, et al, "Private Extensions to the Session
Initiation Protocol (SIP) for Asserted Identity within
Trusted Networks", RFC 3325, November 2002.
[IPTEL-CPC] Mahy, "The Calling Party's Category tel URI
Parameter", draft-mahy-iptel-cpc-04.txt, October 2006.
(work in progress)
[CPC-SAML] Schubert, et al, "Conveying Calling Party Category
(CPC) and Originating Line Information (OLI) using the
Security Assertion Markup Language (SAML)", draft-
schubert-sipping-saml-cpc-02.txt, July 2006. (work in
progress)
[CONNECTED-ID] Elwell, et al, "Analysis of TISPAN requirements for
Connected Identity in the Session Initiation Protocol
SIP)", draft-elwell-sip-tispan-connected-identity-01.txt,
June 2006. (work in progress)
14.2. Informative References
[CSI] Loreto, Terril, "Input 3rd-Generation Partnership Project
(3GPP) Communications Service Identifiers Requirements on
the Session Initiation Protocol (SIP)", draft-loreto-
sipping-3gpp-ics-requirements-00.txt, June 2006. (work in
progress)
Haluska, et al. Expires January 5, 2008 [Page 57]
Internet-Draft Information Services Using SIP July 2007
[RFC3324] Watson, "Short Term Requirements for Network Asserted
Identity", RFC 3324, November 2004.
[RFC3263] Rosenberg, Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[NETANN] Burger, et al, "Basic Network Media Services with SIP",
RFC 4240, December 2005.
[REFER] Sparks, "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[3PCC] Rosenberg, et al, "Best Current Practices for Third Party
Call Control (3pcc) in the Session Initiation Protocol
(SIP)", RFC 3725, April 2004.
[IMS] 3GPP TS 23.228 V7.4.0 (2006-06) - 3rd Generation Partnership
Project; Technical Specification Group Services and
System Aspects; IP Multimedia Subsystem (IMS); Stage 2
(Release 7)
Haluska, et al. Expires January 5, 2008 [Page 58]
Internet-Draft Information Services Using SIP July 2007
Author's 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
Wesley Downum
Telcordia Technologies, Inc.
One Telcordia Drive
Piscataway, NJ 08854-4157
USA
Phone: +1 732 699 6201
Email: wdownum@telcordia.com
Richard Ahern
AT&T Customer Information Services
1876 Data Drive
Room 314
Haluska, et al. Expires January 5, 2008 [Page 59]
Internet-Draft Information Services Using SIP July 2007
Hoover, AL 35244
USA
Email: Richard.Ahern@bellsouth.com
Paul Lum Lung
Qwest Communications International
1801 California Street
Suite 1210
Denver, CO 80202
USA
Email: paul.lumlung@qwest.com
Nicholas S. Costantino
Soleo Communications, Inc.
300 Willowbrook Drive
Fairport, NY 14450
Email: ncostantino@soleocommunications.com
Chris Blackwell
Verizon
1000 Century Tel Dr
Room 115
Wentzville, MO 63385
Email: chris.blackwell@verizon.com
Jim Mellinger
Verizon
7979 N Beltline Rd
Irving, TX 75063
Email: james.j.mellinger@verizon.com
D. E. Scott
VoltDelta
2401 N. Glassell St.
Orange, CA 92865-2705
Email: dscott@voltdelta.com
Haluska, et al. Expires January 5, 2008 [Page 60]
Internet-Draft Information Services Using SIP July 2007
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, THE
IETF TRUST 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 IETF Trust (2007).
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 January 5, 2008 [Page 61]