Network Working Group J. Haluska
Internet Draft Telcordia
Intended status: Informational R. Ahern
Expires: December 2009 AT&T Customer Information Services
P. Lum Lung
Qwest Communications International
C. Blackwell
Verizon
June 19, 2009
Considerations for Information Services and Operator Services Using
SIP
draft-haluska-sipping-directory-assistance-08.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. This document may not be
modified, and derivative works of it may not be created, and it may
not be published except as an Internet-Draft.
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. This document may not be
modified, and derivative works of it may not be created, except to
publish it as an RFC and to translate it into languages other than
English.
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."
<Lastname> Expires December 19, 2009 [Page 1]
Internet-Draft Information Services Using SIP June 2009
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 19, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
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, to identity existing protocol
gaps, and to provide a set of Best Current Practices to facilitate
interoperability. For Operator Services, the intention is to
reproduce the current PSTN behaviour.
Table of Contents
1. Introduction...................................................4
2. Protocol Gaps..................................................5
Haluska, et al. Expires December 19, 2009 [Page 2]
Internet-Draft Information Services Using SIP June 2009
3. Terminology....................................................6
4. High Level Requirements........................................9
5. Information Services..........................................13
6. Operator Services.............................................17
6.1. Inter Provider Capabilities..............................19
6.2. Inter OISP Capabilities..................................19
6.3. Intra OISP Capabilities..................................20
6.4. Capabilities Required for Specific Services..............21
7. OISP Internal Architecture....................................22
8. General Approach..............................................24
9. Signaling Mechanisms..........................................26
9.1. PSTN Protocol Interworking...............................26
9.2. Conveying Application Specific Information...............27
9.3. Calling Party's Identity.................................28
9.4. Provider Identification..................................30
9.4.1. Home Provider.......................................30
9.4.2. Intermediate Provider...............................31
9.5. Originating Line Information/ANI II Value................33
9.6. Trunk Group Identifier...................................34
9.7. Identification of PSTN Originated Calls..................36
9.8. Dialed Digits............................................36
9.9. Retargeting to Identify the Desired Service..............37
9.10. Charge Number...........................................37
9.11. Access Prefix...........................................38
9.12. Signaling of Carrier Information........................39
9.13. Transit Network Selection...............................41
9.14. Carrier Selection Information...........................41
9.15. Passing Whisper.........................................42
9.16. Calling Equipment Capabilities and Characteristics......45
9.17. Media Server Returning Data to the Application Server...46
9.18. Control of Cut Through Direction for PSTN Interworking..47
9.19. With Holding of Final Responses.........................47
10. Example Call Flow - Directory Assistance.....................48
10.1. Basic Flow..............................................48
10.2. OISP Drops Out at Call Completion Setup.................58
10.3. OISP Drops Out After Call Completion Call is Answered...59
10.4. OISP Drops Out After Interaction with Called Party......62
10.5. OISP Remains in Path....................................64
10.6. Return of Call to OISP..................................66
10.7. PSTN Origination........................................67
10.8. PSTN Termination........................................69
10.9. Call Completion By Releasing Call Back to PSTN..........71
11. Operator Services Example Call Flows.........................74
11.1. Network Controlled Coin Calls...........................74
11.2. Busy Line Verification and Interrupt....................81
11.2.1. PSTN Target........................................81
11.2.2. SIP Target.........................................84
Haluska, et al. Expires December 19, 2009 [Page 3]
Internet-Draft Information Services Using SIP June 2009
11.3. Inward Calls............................................86
11.4. Intercept...............................................87
11.4.1. Intercept Request Via SIP..........................87
11.4.2. Intercept Request Via PSTN.........................90
11.5. Operator Assisted Collect Call..........................92
11.6. Operator Assisted Third Party Billing...................99
12. Summary and Conclusions.....................................103
13. Security Considerations.....................................104
14. IANA Considerations.........................................104
15. References..................................................105
15.1. Normative References...................................105
15.2. Informative References.................................105
Author's Addresses..............................................108
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 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.
Haluska, et al. Expires December 19, 2009 [Page 4]
Internet-Draft Information Services Using SIP June 2009
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.
Some of the services discussed in this document are based on
Operator Services offered in North America. Also, many of the
signaling issues described are based on North American PSTN
signaling. However, the ideas in this document are not intended to
be exclusive to North America, and are intended to be useful in
other environments as well.
It is assumed that appropriate business relationships are in place
between involved providers, and that the providers involved have
trust relationships as described in [RFC3325]. In other words, this
document does not assume general operation on the open internet, but
rather between sets of providers with appropriate business and trust
relationships. Individual providers may decide to provide handling
for other requests, but this is beyond the scope of this document.
2. Protocol Gaps
As indicated above, one of the purposes of this document is to identify
gaps in existing protocols, with respect to implementing Directory
Assistance and Operator Services in SIP. Several gaps have been
identified, and these are listed in this section of the document for
convenience to the reader. These include:
Haluska, et al. Expires December 19, 2009 [Page 5]
Internet-Draft Information Services Using SIP June 2009
o Originating Line Information/ANI II Digits
o Charge Number
o Coin Deposit Tones
o Carrier Information: ISUP TNS, CIP, and CSI parameters, and
"cic", "dai" tel URI parameters
3. Terminology
This section defines terms that will be used to discuss Information
and Operator Services.
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
Haluska, et al. Expires December 19, 2009 [Page 6]
Internet-Draft Information Services Using SIP June 2009
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.
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,
Haluska, et al. Expires December 19, 2009 [Page 7]
Internet-Draft Information Services Using SIP June 2009
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.
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
Haluska, et al. Expires December 19, 2009 [Page 8]
Internet-Draft Information Services Using SIP June 2009
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
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.
4. 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.
Haluska, et al. Expires December 19, 2009 [Page 9]
Internet-Draft Information Services Using SIP June 2009
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.
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
Haluska, et al. Expires December 19, 2009 [Page 10]
Internet-Draft Information Services Using SIP June 2009
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
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:
Haluska, et al. Expires December 19, 2009 [Page 11]
Internet-Draft Information Services Using SIP June 2009
+--------+ +--------+ +--------+ +---------+ +------+
| 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.
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.
Haluska, et al. Expires December 19, 2009 [Page 12]
Internet-Draft Information Services Using SIP June 2009
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.
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.
5. 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.
Haluska, et al. Expires December 19, 2009 [Page 13]
Internet-Draft Information Services Using SIP June 2009
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
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.
Haluska, et al. Expires December 19, 2009 [Page 14]
Internet-Draft Information Services Using SIP June 2009
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
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
Haluska, et al. Expires December 19, 2009 [Page 15]
Internet-Draft Information Services Using SIP June 2009
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.
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.
Haluska, et al. Expires December 19, 2009 [Page 16]
Internet-Draft Information Services Using SIP June 2009
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.
6. 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
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.
Haluska, et al. Expires December 19, 2009 [Page 17]
Internet-Draft Information Services Using SIP June 2009
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.
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
Haluska, et al. Expires December 19, 2009 [Page 18]
Internet-Draft Information Services Using SIP June 2009
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.
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.
6.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.
6.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.
Haluska, et al. Expires December 19, 2009 [Page 19]
Internet-Draft Information Services Using SIP June 2009
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.
6.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. Other models may be possible.
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.
Haluska, et al. Expires December 19, 2009 [Page 20]
Internet-Draft Information Services Using SIP June 2009
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.
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.
6.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
Haluska, et al. Expires December 19, 2009 [Page 21]
Internet-Draft Information Services Using SIP June 2009
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. Handling of these
types of calls is outside the scope of this document. Standards for
emergency calling with SIP are still in development.
7. 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. Two different models of ACD include a "query"
model, where the ACD accepts a request and returns a response (such
as a SIP redirection response) identifying the selected resource,
and an "inline" model, where the ACD server accepts a request and
inserts itself into the signaling path, making its selection and
sending requests to that resource. There is currently work in the
MEDIACTL working group regarding Media Resource Brokers (MRBs) which
may be relevant to this.
The ACD server may also contain functionality for tracking and
maintaining statistics about resource utilization; this is sometimes
referred to as force management.
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.
Haluska, et al. Expires December 19, 2009 [Page 22]
Internet-Draft Information Services Using SIP June 2009
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.
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 - OISPs need 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.
Haluska, et al. Expires December 19, 2009 [Page 23]
Internet-Draft Information Services Using SIP June 2009
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. Communications between elements are assumed to traverse a
proxy, which has been omitted from the figure for brevity.
+--------+ +---------+ +---------+
| OIS-AS |-+-| OIS-MS1 |...| OIS-MSk |
+--+-----+ | +---------+ +---------+
|
| | +---------+ +---------+
| +-| OWS1 |...| OWSk |
+--+--+ | +---------+ +---------+
| ACD | |
+-----+ | +--+---+
+-|PSTNGW|
+------+
Figure 5 Simplified view of OISP Internal Architecture
8. 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, as
described in [RFC3725]. 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
Haluska, et al. Expires December 19, 2009 [Page 24]
Internet-Draft Information Services Using SIP June 2009
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 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 [RFC3840] Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)can be used for this. The capabilities
Haluska, et al. Expires December 19, 2009 [Page 25]
Internet-Draft Information Services Using SIP June 2009
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 [RFC4483].
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.
Note that the IETF MEDIACTRL working group is currently developing
mechanisms for control of SIP based MSs by ASs; this work may be
applicable for OIS as well.
9. Signaling Mechanisms
This section discusses the signaling mechanisms required to provide
OIS services.
9.1. PSTN Protocol Interworking
Operator Services will need to interoperate with the existing PSTN.
This includes both receiving incoming call requests from the PSTN as
well as initiating calls towards the PSTN. There are several issues
which are specific to PSTN interworking.
Current Operator Services systems use both SS7 ISUP and MF
signaling. PSTN gateways interwork between the PSTN signaling and
SIP signaling, and between the PSTN's circuit switched bearer
channels and RTP. [RFC3398] defines ISUP-SIP interworking
procedures. . ATIS, which is responsible for defining North American
specific telecommunications standards, provides North American
procedures in [T1679]. There is currently no standard for MF-SIP
interworking. Since ISUP descended from MF, it's reasonable to
assume a gateway model whereby MF signaling is logically mapped to
ISUP, then ISUP-SIP interworking procedures are applied.
Haluska, et al. Expires December 19, 2009 [Page 26]
Internet-Draft Information Services Using SIP June 2009
ISUP interworking involves two mechanisms; parameter mapping and
encapsulation. Some concepts exist natively in both PSTN and SIP
signaling, and thus both PSTN signaling and SIP define protocol
mechanisms for conveying such information. Mapping between these is
specified in interworking standards such as [RFC3398] and [T1679].
Other ISUP parameters have no direct equivalent in SIP, but are
needed in SIP headers so that proxies and other SIP entities can
route calls; extensions have defined SIP headers and parameters for
this purpose. In order to convey those parameters which have no
mapping to SIP headers, encapsulation of ISUP messages is used,
whereby the ISUP message content is encoded in a MIME body which is
carried in SIP messages. [T1679] specifies that the entire ISUP
message be encapsulated in a MIME body of type "application/ISUP",
as registered with IANA and defined in [RFC3204]. [NSS] defines a
MIME type "application/NSS"; this standard specifies that the only
parameters which do not have mappings to SIP be included in the NSS
body, along with identification of the ISUP version and ISUP message
type, rather than encapsulating the entire ISUP message. [T1679] is
the ATIS standard for North American networks.
Thus, PSTN gateways send SIP messages containing SIP headers and
parameters mapped from ISUP parameters where specified, and carrying
an "application/ISUP" MIME body containing an entire encapsulated
ISUP messages.
9.2. Conveying Application Specific Information
Some information carried by PSTN signaling, such as the ISUP Called
Party Number is required for routing calls. Other information, such
as Charge Number, is for use by applications such as operator
services, and is not needed for routing the call.
With SIP, information needed for routing requests, or which
otherwise needs to be available to proxies, should be present in
message headers. Note that proxies may add headers and modify header
content.
Message bodies can be carried in SIP requests and responses. Such
bodies are generated by and consumed by endpoints, and are expected
to be passed transparently by proxies. Additional headers such as
Content-type and Content-disposition describe the MIME type of the
message body as well as how the receiving endpoint is to handle
unsupported MIME types. Messages can contain more than one body, as
described in [RFC2045].
Haluska, et al. Expires December 19, 2009 [Page 27]
Internet-Draft Information Services Using SIP June 2009
Moreover, much of the information delivered to an operator services
system is expected to be provided by trusted equipment in the
caller's home provider, rather than by the caller's user equipment.
Architectures such as IMS include application servers which have the
ability to act as Back to Back User Agents (B2BUAs). Whereas proxies
cannot insert message bodies, B2BUAs can in fact do so, because they
act as SIP endpoints.
Not all information passed in PSTN signaling can be conveyed
natively in SIP, but operator services systems expect this
information. One option for doing this is to have an application
server in the caller's home provider, acting as a B2BUA, populate a
MIME body in the INVITE sent to the operator services provider, for
consumption by an OIS AS. There is at the time of this writing no
agreement on a MIME type to use for this purpose.
Some ISUP information for which SIP mappings are not currently
defined is also expected to be relevant for calls initiated using
SIP. Charge Number is business related information, and is expected
to apply regardless of whether a caller is using a SIP or PSTN
device. The same is true for Originating Line Information. The
motivation for discussing a MIME body for conveying such information
is to address the case of SIP callers, given that at the time of
this writing, there are no standards for doing this.
9.3. 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 [RFC4474] provides a
standardized, architecture agnostic SIP mechanism for cryptographically
assuring the user's identity.
The P-Asserted-Identity header [RFC3325] is a private extension which
can be used to carry a network asserted identity of the caller between
trusted providers.
Haluska, et al. Expires December 19, 2009 [Page 28]
Internet-Draft Information Services Using SIP June 2009
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], 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 [RFC3325], "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.
Haluska, et al. Expires December 19, 2009 [Page 29]
Internet-Draft Information Services Using SIP June 2009
INVITE sip:da@provider-c.example SIP/2.0
Via: SIP/2.0/UDP proxy-b.provider-b.example.com:5060
;branch=y9hG4bK74bf9
Via: SIP/2.0/UDP proxy-a.provider-a.example.com:5060
;branch=x9hG4bK74bf9
Via: SIP/2.0/UDP client.provider-a.example.com:5060
;branch=z9hG4bK74bf9
From: <sip:7327581234@provider-a.example.com>;tag=1234567
To: 411 <tel:+411>
Contact: <sip:7327581234@provider-a.example.com>
P-Asserted-Identity: "732758123" <sip:73237581234@provider-
a.example.com>
Content-Type: application/sdp
Content-Length: ...
[SDP not shown]
9.4. Provider Identification
As discussed, in some deployment scenarios, the OISP makes use vof
the identities of other providers involved in the call. This section
discusses how those identities can be conveyed using SIP.
9.4.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.
[RFC3261] 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.
Haluska, et al. Expires December 19, 2009 [Page 30]
Internet-Draft Information Services Using SIP June 2009
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
domain. 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.
9.4.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 [RFC4244], 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 [RFC4244], entries should be added to the History-Info
header whenever the Request-URI is modified. Cases may exist where the
Haluska, et al. Expires December 19, 2009 [Page 31]
Internet-Draft Information Services Using SIP June 2009
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.
Caller Provider-A Provider-B Provider-C
| | | |
| | | |
| | | |
|(1) INVITE tel:+411 | |
|------------->| | |
| | | |
| | | |
| |(2) INVITE sip:da@prov-b.example.com
| |------------->| |
| | | |
| | | |
| | |(3) INVITE sip:da@prov-
c.example.com
| | |------------->|
| | | |
| | | |
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.example.com", and
adds a History-Info header which includes the targeted-from URI:
INVITE sip:DA@prov-b.example.com SIP/2.0
History-Info: <tel: +411>; index=1
(other message content omitted)
Haluska, et al. Expires December 19, 2009 [Page 32]
Internet-Draft Information Services Using SIP June 2009
3. Proxy-B retargets this to "SIP: da@prov-c.example.com", and appends
another entry to the History-Info header:
INVITE sip:DA@prov-b.example.com SIP/2.0
History-Info: <tel: +411>; index=1, <sip:da@prov-b.example.com>;
index=2
(other message content omitted)
When this request arrives a Proxy-C in Provider C (OISP), it conveys
the following:
o The Request-URI (SIP: da@prov-c.example.com) indicates this as
a DA call
o The History-Info header conveys the history of the request:
o It started as a tel URI for digits "411"
o It was then targeted to provider B
o It 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.
9.5. Originating Line Information/ANI II Value
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. The ability to convey this information
natively with SIP is currently lacking.
It is also desirable to characterize certain types of originating SIP
based callers using these same values, e.g. prison, police, etc.
Haluska, et al. Expires December 19, 2009 [Page 33]
Internet-Draft Information Services Using SIP June 2009
There is currently no standardized mechanism for conveying OLI
information in SIP. Current potential options include the "cpc" tel URI
parameter, the "isup-oli" parameter, and use of a MIME body.
[draft-mahy-iptel-cpc] proposes a "cpc" tel URI parameter, which is is
intended to interwork the ISUP Calling Party's Category (CPC)
parameter. It is also intended to carry information from the ISUP OLI
parameter or from MF ANI II digits.
For interworking with the North American PSTN, there are at least two
issues with using this parameter to convey OLI information.
The ANSI ISUP used in the North American PSTN makes use of the CPC
parameter. To meet the needs of this environment, it was necessary to
define an additional, North American specific parameter, the OLI. The
CPC and OLI are separate parameters, which allows both pieces of
information to be signaled separately. Since the "cpc" tel URI
parameter can be used to convey only CPC values or OLI values, it does
not meet the need to signal this information separately.
Additionally, the cpc tel URI parameter is intended to convey only a
limited subset of OLI values, and any additional desired values require
IANA registration. However, in the North American PSTN, the set of OLI
values is not constrained in this way. Rather, OLI carries a 2 digit
value, and excepting a few reserved values, any of these could
potentially be encountered.
The "isup-oli" parameter is not standardized, but is used to carry the
OLI information.
For PSTN interworking, [T1679] does not specify a SIP mapping for the
OLI parameter. Thus, it is carried in an encapsulated ISUP message in a
MIME body. The proposed "cpc" tel URI parameter as currently defined is
not intended to carry the entire possible range of ANI II values.
For SIP originated calls, there is no currently standardized way to
carry this information. The isup-oli parameter would be useful to this
end.
9.6. 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
Haluska, et al. Expires December 19, 2009 [Page 34]
Internet-Draft Information Services Using SIP June 2009
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.
[RFC4904], "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.
[T1679], which specifies PSTN interworking for North American networks,
does not include this mechanism, possibly because it predates
[RFC4904]. However, gateways should include this information for
operator services.
The following example shows an INVITE containing a trunk group
identification in the Contact header:
Haluska, et al. Expires December 19, 2009 [Page 35]
Internet-Draft Information Services Using SIP June 2009
INVITE sip:da@provider-c.example.com SIP/2.0
Via: SIP/2.0/UDP proxy-b.provider-b.example.com:5060
;branch=y9hG4bK74bf9
Via: SIP/2.0/UDP proxy-a.provider-a.example.com:5060
;branch=x9hG4bK74bf9
Via: SIP/2.0/UDP client.provider-a.example.com:5060
;branch=z9hG4bK74bf9
From: <sip:7327581234@provider-a.example.com>;tag=1234567
To: 411 <tel:+411>
Contact: < sip:7327581234@provider-b.example.com;tgrp=101; trunk-
context=provider-b.example.com@proxy-b.provider-
b.example.com;user=phone>
P-Asserted-Identity: "7327581234" <sip:73237581234@provider-
a.example.com>
Content-Type: application/sdp
Content-Length: ...
9.7. Identification of PSTN Originated Calls
Since calls arriving via PSTN trunks may require different processing
from those received from SIP endpoints, it must be able to distinguish
between these types of calls. For PSTN originated calls, the Contact
header identifies the gateway, and also the presence of the "tgrp"
parameter in that header indicates that the call was received via a
PSTN trunk. Obviously the presence of an encapsulated ISUP message also
identifies the call as such.
9.8. 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 [RFC4244] 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.
Haluska, et al. Expires December 19, 2009 [Page 36]
Internet-Draft Information Services Using SIP June 2009
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.example.com SIP/2.0
(other message content omitted)
History-Info: <tel: +411>; index=1, <sip:da@prov-b.example.com>;
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.
9.9. 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.example.com", 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.example.com".
A similar approach is taken for identifying resources in [RFC4240].
[CSI], a work in progress, discusses explicit service identifiers for
using in IMS [IMS] based networks.
9.10. Charge Number
In the current PSTN in North America, a Charge Number is signaled
with call originations. The Charge Number identifies the customer or
account with which the caller is associated. In many cases it is the
same as the Calling Party Number, while in others it is different -
Haluska, et al. Expires December 19, 2009 [Page 37]
Internet-Draft Information Services Using SIP June 2009
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. The need to convey equivalent information for
SIP based callers is also under investigation.
[PCI] proposes a "P-Charge-Info" SIP header for carrying charge
information for a call. It is intended to facilitate carrying
information equivalent to OLI for SIP originated calls. It is also
intended to support PSTN interworking by carrying the ISUP Charge
Number value.
For PSTN interworking, [T1679] does not specify a SIP mapping for
the Charge Number parameter. Thus, it is carried in an encapsulated
ISUP message in a MIME body. The P-Charge-Info header, if
standardized, would be useful in this role.
For SIP originated calls, there is no currently standardized way to
carry this information. The P-Charge-Info header, if standardized,
would be useful in this role. The use of a MIME body populated by an
application server in the home provider's network is another option.
9.11. Access Prefix
In the current PSTN in North America, operator services calls are
often originated by dialing a prefix such as "0". In ISUP signaling,
the "0" is not carried in the Called Party Number parameter. Rather,
it is stripped, and the ISUP Operator Services Information (OSI)
parameter carries an indication of the original access prefix.
For PSTN originations, this information is conveyed via the Operator
Services Information parameter in the encapsulated ISUP.
For SIP originations, there are several options. First, the dialed
digits, including any prefix, can be included in the Request-URI.
Alternatively, an AS in the caller's home provider can retarget the
request based on the digits, such that new Request-URI identifies
Haluska, et al. Expires December 19, 2009 [Page 38]
Internet-Draft Information Services Using SIP June 2009
the requested service. The original dialed digits can be carried in
the retargeted-from Request-URI in a History-Info header. For
example, a Request-URI containing a zero plus 10 digits might be
retargeted at an AS to sip:operator-assistance@provider-
b.example.com.Though not currently standardized, these options can
also be used for PSTN interworking. I.e., the GW could choose to
prepend a prefix to the digits in the Request-URI based on the
received Operator Services Information parameter. Additionally, the
GW could support building a Request-URI which specifies the
requested service, based on analysis of the incoming ISUP signaling.
9.12. Signaling of Carrier Information
In North American telecommunications networks, PSTN calls utilizing
Interexchange Carrier (IXC) networks have specific signaling
requirements. The application of SIP signaling to such scenarios is
documented in several specifications, but there are issues with
these specifications. This documents points out some of these
issues, but does not attempt to resolve them here.
The ISUP Transit Network Selection (TNS) parameter is used to route
calls to a specific carrier. In North American networks, it is used
on several different interfaces to request that a call be routed to
a particular carrier. TNS is also used in ITU-T ISUP.
Specialized switches called Access Tandems (ATs) provide IXC
networks with access to Local Exchange Carrier (LEC) switches. When
a LEC switch originates an IXC call through an AT, it uses the TNS
to inform the AT which IXC it should send the call to.
Based on business arrangements, IXCs may also provide access to
other IXCs. Thus a LEC switch may need to route a call using IXC B,
but might have connectivity to only IXC A. The LEC switch could,
depending on arrangements, send the call to IXC A, with the TNS
parameter specifying IXC B. This requests IXC A to hand the call to
IXC B.
Also in North America, carrier selection procedures allow a caller
to presubscribe to a particular IXC, and further to casually dial on
a per call basis yet a different IXC to be used. Based on business
arrangements, the carrier which will actually carry the call may be
different from the presubscribed or dialed carrier. In ANSI ISUP,
the Carrier Identification Parameter (CIP) is used to convey the
Haluska, et al. Expires December 19, 2009 [Page 39]
Internet-Draft Information Services Using SIP June 2009
dialed or presubscribed carrier. The definition of a separate ISUP
parameter underscores the importance of separately identifying the
dialed or presubscribed carrier from the carrier which actually
routes the call.
Both [RFC3398] and [T1679] discuss interworking between the "cic"
tel URI parameter and the ISUP TNS and/or CIP parameters. This
document points out that there are issues with both these
specifications, but does not attempt to resolve those issues here.
[RFC3398] provides guidance on mapping between the "cic" tel URI
parameter and the corresponding ISUP parameter. It essentially
states that "cic" maps to TNS except for North American networks
where it maps to CIP, also allowing for local policy to apply.
Some information not discussed in [RFC3398] includes the fact that
for North American networks it is not an either/or choice between
inclusion of TNS and CIP, that both ISUP parameters may be present,
the nature of the relationship between these parameters, or what to
do in the ISUP to SIP direction when both TNS and CIP are present.
Also, for a given "cic" parameter received by the gateway, and
depending on the outgoing PSTN interface type, a TNS value may also
need to be determined and populated in the outgoing IAM, in addition
to the CIP parameter.
[T1679] specifies a mapping between the ISUP TNS parameter and the
"cic" parameter in the Request-URI for North American networks. In
doing so, it precludes the use of the "cic" parameter to convey the
identity of the dialed or presubscribed carrier for PSTN
interworking scenarios, as is suggested in [RFC4694] and in [DAI].
Also, when the "cic" parameter is used to convey TNS for PSTN
interworking scenarios, then if the "cic" parameter were also to be
used to convey the dialed or presubscribed carrier for SIP
originated calls, there is a potential for ambiguity regarding the
meaning of a received "cic" parameter.
The signaling of carrier selection information for non interworked,
all-SIP calls in North American networks is for further study.
Haluska, et al. Expires December 19, 2009 [Page 40]
Internet-Draft Information Services Using SIP June 2009
9.13. Transit Network Selection
In addition to the issues regarding signaling of carrier information
in SIP, there is an issue with the currently defined usage of the
"cic" parameter for mapping the ISUP TNS parameter.
[T1679] specifies a mapping between the ISUP TNS parameter and the
"cic" parameter in the Request-URI. The TNS is also available in the
encapsulated ISUP.
The ISUP TNS comprises two components, a Carrier Identification Code
(CIC) and a Circuit Code (CC). Neither [RFC4694] nor [T1679] provide
a means to include the circuit code. The formal syntax of the cic
parameter does not specify a maximum number of digits. Thus, it's
possible to define a convention whereby the circuit code digits are
appended to the CIC digits in the "cic" parameter. The CC is defined
to be two digits in length, plus a leading zero. Thus we can append
"-0zz", where zz represents the CC value, to the "cic" value to
convey the circuit code.
As an example, if an IAM is received with a TNS with CIC=0123, and
Circuit Code=045, the corresponding tel URI would appear as: "tel:
+1-732-555-1212; cic=+1-0123-045.
The cic parameter could also be used to convey a TNS value
(including both CIC and Circuit Code) for SIP originations, where
deployments require its use. This is for further study.
9.14. Carrier Selection Information
In the current PSTN in North America, callers can specify the
carrier they want to use for a particular long distance call.
Otherwise, their presubscribed carrier is used. In either case the
carrier identification code (CIC) of the chosen carrier is signaled.
In ISUP this is signaled in the Carrier Information Parameter (CIP).
Additionally, the ISUP Carrier Selection Information (CSI) parameter
describes how this carrier was chosen; e.g. presubscribed, dialed,
etc. Operator services calls can include call completion, whereby a
call is initiated on behalf of the caller. In order to know which
carrier to use, and how that carrier was chosen, the operator
services provider needs to receive the CIP and Carrier Selection
Information.
For PSTN originations, this information is included in the
encapsulated ISUP.
Haluska, et al. Expires December 19, 2009 [Page 41]
Internet-Draft Information Services Using SIP June 2009
For SIP originations, the use of a MIME body populated by an
application server in the home provider's network is one option.
The "dai" parameter proposed in [DAI] provides another option. This
document identifies this option with the caveat that there are
currently issues regarding the mapping of the "cic" tel URI
parameter and the ISUP TNS or CIP parameters.
9.15. 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
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.
[RFC4483] defines an extension to the URL MIME External-Body Access-
Type to satisfy the content indirection requirements for SIP. These
Haluska, et al. Expires December 19, 2009 [Page 42]
Internet-Draft Information Services Using SIP June 2009
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.
AS MS Operator
| | |
| | |
| | |
|(1) INVITE | |
|------------->| |
| | |
|(2) 200 OK | |
|<-------------| |
|(3) ACK | |
|------------->| |
| | |
|MS prompts user, collects whisper
| | |
| | |
|(4) BYE, body w. status, whisper URI
|<-------------| |
| | |
|(5) 200 OK | |
|------------->| |
| | |
|(6) INVITE w. whisper URI |
|---------------------------->|
| | |
|(7) 200 OK SDP| |
|<----------------------------|
|(8) ACK | |
|---------------------------->|
| | |
| | |
Figure 7 Call flow illustrating passing of whisper
Haluska, et al. Expires December 19, 2009 [Page 43]
Internet-Draft Information Services Using SIP June 2009
1. INVITE AS->MS
INVITE sip:da@ms-1.oisp-c.example.com SIP/2.0
[remainder of message omitted]
2. 200 OK MS->AS
SIP/2.0 200 OK
[remainder of message omitted]
4. BYE MS->AS
BYE sip:as-1@as-1.oisp-c.example.com SIP/2.0
[non relevant portions of message omitted]
Content-Type: message/external-body; access-type="URL";
URL="http://ms1.oisp-c.example.com/whisper/20070206092700-
0001.wav"
expiration="Tues, 06 Feb 2007 09:30:00 GMT";
<CRLF>
Content-Type: audio/x-wav
Content-Disposition: render
<CRLF>
5. 200 OK AS->MS
SIP/2.0 200 OK
[remainder of message omitted]
6. INVITE AS->Operator Workstation
INVITE sip:operator@operator-123.oisp-c.example.com SIP/2.0
[non relevant portions of message omitted]
Content-Type: message/external-body; access-type="URL";
URL="http://ms1.oisp-c.example.com/whisper/20070206092700-
0001.wav"
expiration="Tues, 06 Feb 2007 09:30:00 GMT";
<CRLF>
Content-Type: audio/x-wav
Content-Disposition: render
<CRLF>
7. 200 OK Operator->AS
SIP/2.0 200 OK
[remainder of message omitted]
Haluska, et al. Expires December 19, 2009 [Page 44]
Internet-Draft Information Services Using SIP June 2009
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.
9.16. 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.
[RFC3840] 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.
Haluska, et al. Expires December 19, 2009 [Page 45]
Internet-Draft Information Services Using SIP June 2009
INVITE sip:da@provider-c.example.com SIP/2.0
Via: SIP/2.0/UDP proxy-b.provider-b.example.com:5060
;branch=y9hG4bK74bf9
Via: SIP/2.0/UDP proxy-a.provider-a.example.com:5060
;branch=x9hG4bK74bf9
Via: SIP/2.0/UDP client.provider-a.example.com:5060
;branch=z9hG4bK74bf9
From: <sip:7327581234@provider-a.example.com>;tag=1234567
To: 411 <tel:+411>
Contact: <sip:7327581234@provider-a.example.com>;audio;video;text
;actor="principle";automata;mobility="fixed"
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
P-Asserted-Identity: "7327581234" <sip:73237581234@provider-
a.example.com>
P-Asserted-Identity: tel:+7327581234
Content-Type: application/sdp
Content-Length: ...
[SDP not shown]
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.
9.17. 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
Haluska, et al. Expires December 19, 2009 [Page 46]
Internet-Draft Information Services Using SIP June 2009
to the OIS-AS. SIP Interface to VoiceXML Media Services - draft-
burke-vxml-03.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.
9.18. Control of Cut Through Direction for PSTN Interworking
For PSTN interworking scenarios, it may be desirable to explicitly
control the "duplex" of the PSTN circuit; whether it be a two way
connection or one way in the forward direction. The rules about SDP
offer/answer indicate that as soon as an entity sends an SDP, it should
be prepared to receive media for that session. SDP provides a "mode"
attribute with values such as "a=sendonly", "a=recvonly", "a=sendrecv"
for explicit control of the directionality.
This mode attribute can be included in the SDP sent toward the PSTN GW
in order to signal what duplex and directionality is desired. If it's
desired to have a talk path only in the backward direction, such that
audio is sent toward the caller but not in the opposite direction, then
SDP with "a=sendonly" can be sent to the GW. When it's desired to have
both-way cut through, an updated SDP can be sent with "a=sendrecv".
This should affect not only the duplex of the voice path but also the
related PSTN signaling sent by the GW towards the PSTN switch. For
example, with ISUP, the GW should send an ACM with the User Network
Interaction bit set in the Optional Backward Call Indication. Existing
standards on PSTN interworking do not address this aspect of gateway
behaviour.
9.19. With Holding of Final Responses
Currently in the PSTN, for operator services, signaling of Answer,
whether this be an ISUP ANM or MF Answer Supervision, is often with
held, leaving the call in an alerting state while the caller interacts
with the operator services system. The motivation for this is that in
the PSTN, billing normally starts when answer is signaled. For some
Haluska, et al. Expires December 19, 2009 [Page 47]
Internet-Draft Information Services Using SIP June 2009
calls answer may never be signaled; in others it may be signaled for
instance when a call completion call is answered.
The equivalent of answer indication in SIP is the 200 OK final
response. It is not an intrinsic property of SIP based systems that
billing must start upon 200 OK. In cases where it's desired to emulate
the PSTN behaviour, the 200 OK can be with held. When this is done,
normal SIP procedures need to be followed to prevent the session from
timing out.
10. Example Call Flow - Directory Assistance
10.1. Basic Flow
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 December 19, 2009 [Page 48]
Internet-Draft Information Services Using SIP June 2009
Caller Proxy A Proxy B Proxy C OIS-AS OIS-MS1
| | | | | |
| | | | | |
| | | | | |
|(1) INVITE tel:411 | | | |
|-------->| | | | |
| | | | | |
| |(2) INVITE sip:da@prov-b.example.com | |
| |-------->| | | |
| | | | | |
| | |(3) INVITE sip:da@prov-c.example.com |
| | |-------->| | |
| | | | | |
| | | |(4) INVITE sip:da-cc@prov-
c.example.com
| | | |-------->| |
| | | | | |
| | | | |(5) INVITE prompt &
collect
| | | | |-------->|
| | | | | |
| | | | |(6) 200 OK w.SDP
| | | | |<--------|
| | | | |(7) Ack |
| | | | |-------->|
| | | | | |
| | | |(8) 200 OK w.SDP |
| | | |<--------| |
| | | |(9) Ack | |
| | | |-------->| |
| | | | | |
| | |(10) 200 OK w.sdp | |
| | |<--------| | |
| | |(11) Ack | | |
| | |-------->| | |
| | | | | |
| |(12) 200 OK w.sdp | | |
| |<--------| | | |
| |(13) Ack | | | |
| |-------->| | | |
| | | | | |
|(14) 200 OK w.sdp | | | |
|<--------| | | | |
|(15) Ack | | | | |
|-------->| | | | |
Haluska, et al. Expires December 19, 2009 [Page 49]
Internet-Draft Information Services Using SIP June 2009
| | | | | |
| | | | | |
| | | | | |
Figure 8 DA Call flow, part 1
For brevity, only relevant SIP headers will be shown. The following
test refers to Figure 8.
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.example.com:5060
;branch=z9hG4bK74bf9
From: <sip:7327581234@provider-a.example.com>;tag=1234567
To: 411 <tel:+411>
Contact: <sip:7327581234@provider-a.example.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 December 19, 2009 [Page 50]
Internet-Draft Information Services Using SIP June 2009
2. INVITE proxy-a -> proxy-b
INVITE sip:411@provider-b.example.com SIP/2.0
Via: SIP/2.0/UDP proxy-a.provider-a.example.com:5060
;branch=x9hG4bK74bf9
Via: SIP/2.0/UDP client.provider-a.example.com:5060
;branch=z9hG4bK74bf9
From: <sip:7327581234@provider-a.example.com>;tag=1234567
To: 411 <tel:+411>
Contact: <sip:7327581234@provider-a.example.com>
P-Asserted-Identity: "7327581234" <sip:73237581234@provider-
a.example.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 December 19, 2009 [Page 51]
Internet-Draft Information Services Using SIP June 2009
3. INVITE proxy-b -> proxy-c
INVITE sip:da@provider-c.example.com SIP/2.0
Via: SIP/2.0/UDP proxy-b.provider-b.example.com:5060
;branch=y9hG4bK74bf9
Via: SIP/2.0/UDP proxy-a.provider-a.example.com:5060
;branch=x9hG4bK74bf9
Via: SIP/2.0/UDP client.provider-a.example.com:5060
;branch=z9hG4bK74bf9
From: <sip:7327581234@provider-a.example.com>;tag=1234567
To: 411 <tel:+411>
Contact: <sip:7327581234@provider-a.example.com>
P-Asserted-Identity: "732758123" <sip:73237581234@provider-
a.example.com>
P-Asserted-Identity: tel:+7327581234
History-Info: <tel: +411>; index=1, <sip:da@provider-a.example.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 [RFC4240],
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 December 19, 2009 [Page 52]
Internet-Draft Information Services Using SIP June 2009
5. INVITE OIS-AS -> MS1
INVITE sip:dialog@ois-as.prov-c.example.com; \
voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml \
SIP/2.0
Via: SIP/2.0/UDP ois-as.prov-c.example.com:5060
;branch=z9hG4bK74bf9
From: <sip:ois-as@ois-as.prov-c.com>;tag=1234567
To: sip:dialog@ois-as.prov-c.example.com; \
voicexml=http://vxmlserver.example.net/cgi-bin/script.vxml
Contact: <sip:ois-as@ois-as.prov-c.example.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 December 19, 2009 [Page 53]
Internet-Draft Information Services Using SIP June 2009
Caller OIS-AS OIS-MS1 ACD OWS
| | | | |
|(16) RTP session | | |
|...................| | |
| | | | |
| |(17) INFO w.URI, body |
| |<--------| | |
| | | | |
| |(18) INVITE | |
| |------------------>| |
| | | | |
| |(19) 182 Queued | |
| |<------------------| |
| | | | |
| |(20) 3xx Redirection |
| |<------------------| |
| | | | |
| |(21) INVITE | |
| |---------------------------->|
| | | | |
| |(22) 200 OK | |
| |<----------------------------|
| |(23) ACK | | |
| |---------------------------->|
| | | | |
| |(24) BYE | | |
| |-------->| | |
| |(25) 200 OK | |
| |<--------| | |
| | | | |
|(26) re INVITE | | |
|<--------| | | |
| | | | |
|(27) 200 OK | | |
|-------->| | | |
|(28) ACK | | | |
|<--------| | | |
| | | | |
|(29) RTP session | | |
|.......................................|
| | | | |
| |(30) BYE | | |
| |<----------------------------|
| |(31) 200 OK | |
| |---------------------------->|
Haluska, et al. Expires December 19, 2009 [Page 54]
Internet-Draft Information Services Using SIP June 2009
Figure 9 DA Call flow, part 2
The following text refers to Figure 9.
The user is now connected (16) 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 (18) 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.
If the call needs to be queued due to lack of an immediately
available resource, the ACD may send a 812 Queued response (19). In
this example, the ACD server is implemented as a redirect server -
it sends a 3XX response (20) 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 (21) 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 (22) with its
SDP, which the OIS-AS sends toward the caller in a re-INVITE (26).
Haluska, et al. Expires December 19, 2009 [Page 55]
Internet-Draft Information Services Using SIP June 2009
Only when the workstation has sent a final response to the INVITE,
the AS sends a BYE (24) to the MS.
The caller is now connected to the operator (29), and the operator
helps the caller with the listing. The operator workstation launches
a query, and a response is received. The operator signals a BYE (30)
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.
Haluska, et al. Expires December 19, 2009 [Page 56]
Internet-Draft Information Services Using SIP June 2009
Caller OIS-AS OIS-MS2
| | |
| | |
| | |
| |(32) INVITE
| |-------->|
| | |
| |(33) 200 OK
| |<--------|
| |(34) ACK |
| |-------->|
| | |
|(35) re INVITE |
|<--------| |
| | |
|(36) 200 OK |
|-------->| |
|(37) ACK | |
|<--------| |
| | |
|(38) RTP session |
|...................|
| | |
| |(39) BYE w.URI, body
| |<--------|
| | |
| |(40) 200 OK
| |-------->|
| | |
|(41) REFER |
|<--------| |
| | |
| | |
Figure 10D A Call flow, part 3
Haluska, et al. Expires December 19, 2009 [Page 57]
Internet-Draft Information Services Using SIP June 2009
The following text refers to Figure 10.
The OIS-AS sends an INVITE (32) to another OIS-MS, MS2, for back end
automation. (Note that though MS2 is shown as a separate element,
the functionality it provides may or may not require a separate
element.) When it receives MS2's SDP in the 200 OK (33), it sends a
re INVITE (35) 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 (38). The MS plays the listing information, and offers
call completion service. The caller accepts, so OIS-MS2 sends a BYE
(39) with a message body containing the result of the call
completion offer. Since call completion was requested, the OIS-AS
sends a REFER (41) 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.2. OISP Drops Out at Call Completion Setup
The OISP may want to support different call flow options with
respect to call completion. Reasons for this may include the desire
to free up resources quickly, provide additional functionality, etc.
When the OISP wants to provide the listing information and free
resources as soon as possible, a simple flow based on REFER can be
used, as illustrated below.
In this flow, the caller is already connected to an OISP resource
such as an MS, and requests call completion. In (2), the OISP sends
a REFER to initiate the call completion call. The caller's UA
indicates acceptance of the REFER by sending a 202 Accepted (3). It
then sends a NOTIFY indicating that it is attempting to contact the
indicated resource, by sending an INVITE (10). When the AS receives
this notification, it understands that the caller is attempting the
call completion call, so it drops the call by sending BYE in (6)and
(8). The various notifications sent by the caller to the OISP can be
used to monitor progress of the call, or may simply be ignored from
an application standpoints (from a protocol standpoint they must be
acknowledged).
Haluska, et al. Expires December 19, 2009 [Page 58]
Internet-Draft Information Services Using SIP June 2009
Caller AS MS Called Party
| | | |
| | | |
|(1) Caller connected to e.g., MS |
|.............................| |
| | | |
|(2) REFER (Called) | |
|<-------------| | |
|(3) 202 Accepted | |
|------------->| | |
| | | |
|(4) NOTIFY (Trying) | |
|------------->| | |
|(5) 200 OK | | |
|<-------------| | |
| | | |
| |(6) BYE | |
| |------------->| |
| |(7) 200 OK | |
| |<-------------| |
| | | |
|(8) BYE | | |
|<-------------| | |
|(9) 200 OK | | |
|------------->| | |
| | | |
|(10) INVITE | | |
|------------------------------------------->|
| | | |
|(11) 200 OK | | |
|<-------------------------------------------|
|(12) Ack | | |
|------------------------------------------->|
| | | |
|(13) NOTIFY (200 OK) | |
|------------->| | |
|(14) 200 OK | | |
|<-------------| | |
| | | |
10.3. OISP Drops Out After Call Completion Call is Answered
The OISP may need to remain in the signaling path until the call
completion call is answered. One way to implement this is to use the
REFER method with the Replaces header, as described in [RFC 3891].
Haluska, et al. Expires December 19, 2009 [Page 59]
Internet-Draft Information Services Using SIP June 2009
In this case, once the call completion call is answered (5), the
OISP's AS sends a REFER (6) toward the caller with a Replaces header
identifying the current dialog between the AS and called party, and
Referred-by header identifying the AS. This causes an INVITE (10) to
be sent toward the called party, also with Replaces and Referred-by
headers. As described in [RFC 3891], this causes a new session to
be set up with the called party, replacing the existing sessions. As
part of this, the original session is torn down (16). Thus, the
OISP's resources are removed from the call.
Haluska, et al. Expires December 19, 2009 [Page 60]
Internet-Draft Information Services Using SIP June 2009
Caller AS MS Called Party
| | | |
| | | |
| | | |
|(1) Caller listening to announcements, etc |
|.............................| |
| | | |
| |(2) INVITE | |
| |---------------------------->|
| | | |
| |(3) 183 Ringing |
| |<----------------------------|
| | | |
| |(4) 200 OK | |
| |<----------------------------|
| | | |
| |(5) ACK | |
| |---------------------------->|
| | | |
|[Called party has answered] | |
| | | |
|(6) REFER (Called Party, Replaces:AS, Referred-by:AS)
|<-------------| | |
| | | |
|(7) 202 Accepted | |
|------------->| | |
| | | |
|(8) NOTIFY (100 Trying) | |
|------------->| | |
| | | |
|(9) 200 OK | | |
|<-------------| | |
| | | |
|(10) INVITE (Replaces:AS, Referred-by:AS) |
|------------------------------------------->|
| | | |
|(11) 200 OK | | |
|<-------------------------------------------|
| | | |
|(12) ACK | | |
|------------------------------------------->|
| | | |
|[Called Party replaces existing dialog from Step 2 with new one]
| | | |
| | | |
|(13) RTP [Called and Calling Party are now connected ]
Haluska, et al. Expires December 19, 2009 [Page 61]
Internet-Draft Information Services Using SIP June 2009
|............................................|
| | | |
| | | |
|[ Remainder of steps cleanup dialogs between Caller-AS and AS-
Called ]
| | | |
|(14) NOTIFY (200 OK) | |
|------------->| | |
| | | |
|(15) 200 OK | | |
|<-------------| | |
| | | |
| |(16) BYE (as a result of receiving Replaces)
| |<----------------------------|
| | | |
| |(17) 200 OK | |
| |---------------------------->|
| | | |
|(18) BYE | | |
|<-------------| | |
| | | |
|(19) 200 OK | | |
|------------->| | |
| | | |
10.4. OISP Drops Out After Interaction with Called Party
In this scenario, the OISP needs to interact with the called party,
then desired to remove its resources from the call. Collect calls
are one example where this might be used. This also uses REFER with
Replaces. The OISP places a call to the called party, and
interactions between OISP resources (automated or human) occur. The
OISP then sends a REFER with Replaces and Referred-by to the calling
party, which then sends an INVITE as described for the previous
scenario.
In this scenario, the OISP has one media session (1) with the caller
and another (2) with the called party. After interactions have been
completed, the OISP initiates the transfer by sending a REFER (3)
with Replaces and Referred-by headers. This causes the caller's UA
to send a corresponding INVITE (7) containing those headers. As with
the previous scenario, this causes initiation of a new session
replacing the existing session, as well as teardown (10) of the
existing session.
Haluska, et al. Expires December 19, 2009 [Page 62]
Internet-Draft Information Services Using SIP June 2009
Caller AS MS Called
| | | |
| | | |
| | | |
|[ Calling party has some RTP session with MS ] |
| | | |
| | | |
|(1) RTP | | |
|.......................................| |
| | | |
|[ Called party has different RTP session with MS ] |
| | | |
| | | |
| | |(2) RTP |
| | |...................|
| | | |
|[ AS initiates transfer with REFER ] | |
| | | |
| | | |
|(3) REFER (to called, Replaces:AS, Referred-by:AS) |
|<------------------| | |
| | | |
| | | |
|(4) 202 Accepted | | |
|------------------>| | |
| | | |
|(5) NOTIFY (trying)| | |
|------------------>| | |
| | | |
|(6) 200 OK | | |
|<------------------| | |
| | | |
|[ Replaces header causes Called to replace old call with new ]
| | | |
| | | |
|(7) INVITE (Replaces:AS, Referred-by:AS) |
|---------------------------------------------------------->|
| | | |
| | | |
|(8) 200 OK (SDP-called) | |
|<----------------------------------------------------------|
| | | |
|(9) ACK | | |
|---------------------------------------------------------->|
| | | |
|[ Calling and Called are now talking directly ] |
Haluska, et al. Expires December 19, 2009 [Page 63]
Internet-Draft Information Services Using SIP June 2009
| | | |
| | | |
| | | |
|[As a result of Replaces operation, called ends session with MS]
| | | |
| |(10) BYE (as a result of processing Replaces)
| |<--------------------------------------|
| | | |
| |(11) 200 OK | |
| |-------------------------------------->|
| | | |
|[AS ends session with Calling] | |
| | | |
|(12) BYE | | |
|<------------------| | |
|(13) 200 OK | | |
|------------------>| | |
| | | |
|(14) NOTIFY (200 OK) | |
|------------------>| | |
|(15) 200 OK | | |
|<------------------| | |
| | | |
10.5. OISP Remains in Path
In some cases, the OISP desires to maintain its elements in the
signaling path and possibly in the media path as well for the
duration of the call completion call. One possible reason for doing
this is so that the caller can request to be returned to the OISP
for additional services after the call has completed.
The figure below begins with the caller already connected to OISP
resources. The AS initiates call completion in steps 2 through 5 by
sending an INVITE toward the called party. The AS then sends a re-
INVITE toward the caller to update the SDP, and step 9 shows the
media session established between the caller and the called party,
and in step 10 clears the previous session with the MS. When the
called party hangs up in step 12, the AS responds. In step 14, the
AS has the opportunity to redirect the caller to a MS or other
resource to offer additional services, but in this case simply
clears the dialog with the caller.
Haluska, et al. Expires December 19, 2009 [Page 64]
Internet-Draft Information Services Using SIP June 2009
Caller AS MS Called Party
| | | |
| | | |
| | | |
|(1) Caller has media session with MS |
|.............................| |
| | | |
|AS initiates call completion | |
| | | |
| | | |
| |(2) INVITE | |
| |---------------------------->|
| | | |
| |(3) 180 Ringing |
| |<----------------------------|
| | | |
| |(4) 200 OK | |
| |<----------------------------|
| | | |
| |(5) ACK | |
| |---------------------------->|
| | | |
|Called party has answered | |
| | | |
| | | |
|(6) re-INVITE | | |
|<-------------| | |
| | | |
|(7) 200 OK | | |
|------------->| | |
| | | |
|(8) ACK | | |
|<-------------| | |
| | | |
|(9) Media Session | |
|............................................|
| | | |
| |(10) BYE | |
| |------------->| |
| | | |
| |(11) 200 OK | |
| |<-------------| |
| | | |
|Called party hangs up | |
| | | |
| | | |
| |(12) BYE | |
Haluska, et al. Expires December 19, 2009 [Page 65]
Internet-Draft Information Services Using SIP June 2009
| |<----------------------------|
| | | |
| |(13) 200 OK | |
| |---------------------------->|
| | | |
|AS clears call back to Caller| |
| | | |
| | | |
|(14) BYE | | |
|<-------------| | |
| | | |
|(15) 200 OK | | |
|------------->| | |
| | | |
| | | |
10.6. Return of Call to OISP
In some cases, it is desirable that the caller be able to request,
typically via keypad stimulus such as the octothorpe or pound sign,
to be returned to the OISP operator (human or automated). One way
this can be accomplished is for the OISP to use KPML [RFC4730] to
subscribe to the desired keypress. The flow presented here assumes
that the calling UA, or an intermediary acting on its behalf,
supports this event package, and is able to detect the desired
keypress. Examples of such intermediaries include back to back user
agents (B2BUAs) and Session Border Controllers (SBCs). Another
option is for the OISP to insert some element such as a MS into the
media stream, which is capable of detecting and notifying the
desired keypress.
In (1) the caller has already been connected to called party via the
AS. In (2), the AS subscribes to KPML events from the caller's UA.
Note that in some environments, this could be intercepted and acted
upon by intermediaries such as B2BUAs or SBCs. As long as this does
not interfere with notification, this is transparent to the OISP.
When the caller presses the specified keypress to request return to
the OISP, a NOTIFY (6) is sent to the AS. At this time, the OISP can
perform whatever actions are necessary, such as perhaps sending a
re-INVITE or UPDATE to move the media session to an OISP resource.
Haluska, et al. Expires December 19, 2009 [Page 66]
Internet-Draft Information Services Using SIP June 2009
Caller AS MS Called Party
| | | |
|(1) Caller connected to called via 3PCC |
|............................................|
| | | |
|(2) SUBSCRIBE (KPML body specifying "#") |
|<-------------| | |
|(3) 200 OK | | |
|------------->| | |
| | | |
|(4) NOTIFY (result of subscription) |
|------------->| | |
|(5) 200 OK | | |
|<-------------| | |
| | | |
|[ Some time passes ] | |
| | | |
|[ Caller wants back to OISP, hits "#" ] |
| | | |
| | | |
|(6) NOTIFY (KPML body specifying "#") |
|------------->| | |
|(7) 200 OK | | |
|<-------------| | |
10.7. PSTN Origination
The following example shows a call from a PSTN caller. In this case,
the incoming IAM is translated at the PSTN gateway to a SIP INIVTE.
Though not specifically shown, the INVITE contains the IAM
encapsulated in a MIME body, and any ISUP parameters are mapped to
SIP headers and/or parameters as described in [T1679]; additionally
the mechanisms described in this document are also applied, such as
encoding of the trunk group information in the Contact header per
[RFC4904].
Haluska, et al. Expires December 19, 2009 [Page 67]
Internet-Draft Information Services Using SIP June 2009
EO GW AS MS1 MS2 Called Party
| | | | | |
| | | | | |
| | | | | |
|Incoming ISUP Call | | | |
| | | | | |
|(1) IAM | | | | |
|---------->| | | | |
| |(2) INVITE (GW SDP) | | |
| |---------->| | | |
| | |(3) INVITE (GW SDP) | |
| | |---------->| | |
| | |(4) 200 OK (MS1 SDP) | |
| | |<----------| | |
| | |(5) ACK | | |
| | |---------->| | |
| |(6) 183 Session Progress (MS1 SDP) | |
| |<----------| | | |
|(7) ACM | | | | |
|<----------| | | | |
| |(8) PRACK | | | |
| |---------->| | | |
| |(9) 200 OK | | | |
| |<----------| | | |
| |(10) RTP Session | | |
| |.......................| | |
|E.g. Front End Announcements | | |
| | | | | |
| | |(11) BYE | | |
| | |<----------| | |
| | |(12) 200 OK| | |
| | |---------->| | |
| | | | | |
| | |(13) INVITE (GW SDP) | |
| | |---------------------->| |
| | |(14) 200 OK (MS2 SDP) | |
| | |<----------------------| |
| | |(15) ACK | | |
| | |---------------------->| |
| |(16) UPDATE (MS2 SDP) | | |
| |<----------| | | |
| |(17) 200 OK| | | |
| |---------->| | | |
| |(18) RTP Session | | |
| |...................................| |
| | |(19) INVITE| | |
| | |---------------------------------->|
Haluska, et al. Expires December 19, 2009 [Page 68]
Internet-Draft Information Services Using SIP June 2009
| | |(20) 183 Session Progress |
| | |<----------------------------------|
| | |(21) PRACK | | |
| | |---------------------------------->|
| | |(22) 200 OK| | |
| | |<----------------------------------|
| |(23) UPDATE (Called SDP) | |
| |<----------| | | |
| |(24) 200 OK| | | |
| |---------->| | | |
| | |(25) BYE | | |
| | |<----------------------| |
| | |(26) 200 OK| | |
| | |---------------------->| |
| |(27) RTP Session | | |
| |...............................................|
| | |(28) 200 OK| | |
| | |<----------------------------------|
| | |(29) Ack | | |
| | |---------------------------------->|
| |(30) 200 OK| | | |
| |<----------| | | |
| |(31) ACK | | | |
| |---------->| | | |
|(32) ANM | | | | |
|<----------| | | | |
| | | | | |
10.8. PSTN Termination
The following example shows a call which results in call completion
to a destination on the PSTN. In Step 17 the AS sends an INVITE
toward the PSTN gateway which results in an IAM being sent which
intiates the PSTN call leg.
Haluska, et al. Expires December 19, 2009 [Page 69]
Internet-Draft Information Services Using SIP June 2009
Calling Party AS MS1 MS2 GW EO
| | | | | |
| | | | | |
| | | | | |
|Incoming SIP call | | | |
| | | | | |
|(1) INVITE (Caller SDP)| | | |
|---------->| | | | |
| |(2) INVITE (Caller SDP)| | |
| |---------->| | | |
| |(3) 200 OK (MS1 SDP) | | |
| |<----------| | | |
| |(4) ACK | | | |
| |---------->| | | |
|(5) 183 Session Progress (MS1 SDP) | | |
|<----------| | | | |
|(6) PRACK | | | | |
|---------->| | | | |
|(7) 200 OK | | | | |
|<----------| | | | |
|(8) RTP Session | | | |
|.......................| | | |
|E.g. Front End Announcements | | |
| | | | | |
| |(9) BYE | | | |
| |<----------| | | |
| |(10) 200 OK| | | |
| |---------->| | | |
| | | | | |
| |(11) INVITE (Caller SDP) | |
| |---------------------->| | |
| |(12) 200 OK (MS2 SDP) | | |
| |<----------------------| | |
| |(13) ACK | | | |
| |---------------------->| | |
|(14) UPDATE (MS2 SDP) | | | |
|<----------| | | | |
|(15) 200 OK| | | | |
|---------->| | | | |
|(16) RTP Session | | | |
|...................................| | |
| |(17) INVITE| | | |
| |---------------------------------->| |
| | | | |(18) IAM |
| | | | |---------->|
| | | | |(19) ACM |
| | | | |<----------|
Haluska, et al. Expires December 19, 2009 [Page 70]
Internet-Draft Information Services Using SIP June 2009
| |(20) 183 Session Progress | |
| |<----------------------------------| |
| |(21) PRACK | | | |
| |---------------------------------->| |
| |(22) 200 OK| | | |
| |<----------------------------------| |
|(23) UPDATE (GW SDP) | | | |
|<----------| | | | |
|(24) 200 OK| | | | |
|---------->| | | | |
| | | | |(25) ANM |
| | | | |<----------|
| |(26) 200 OK| | | |
| |<----------------------------------| |
| |(27) Ack | | | |
| |---------------------------------->| |
|(28) 200 OK(GW SDP) | | | |
|<----------| | | | |
|(29) ACK | | | | |
|---------->| | | | |
|(30) RTP Session | | | |
|...............................................| |
| | | | |(31) REL |
| | | | |<----------|
| | | | |(32) RLC |
| | | | |---------->|
| |(33) BYE | | | |
| |<----------------------------------| |
| |(34) 200 OK| | | |
| |---------------------------------->| |
|(35) BYE | | | | |
|<----------| | | | |
|(36) 200 OK| | | | |
|---------->| | | | |
| | | | | |
10.9. Call Completion By Releasing Call Back to PSTN
This example shows how when a call is received from the PSTN, call
completion can be achieved by releasing the call back to the PSTN to
have a PSTN switch initiate the call completion call. This allows
call completion to occur in the PSTN, and completely drops the call
from the OISP. The PSTN feature which supports this is called
Release To Pivot; other implementations may also exist. The
gateway's connection to the PSTN needs to be specifically
Haluska, et al. Expires December 19, 2009 [Page 71]
Internet-Draft Information Services Using SIP June 2009
provisioned to support this feature. There is currently no standard
describing the invocation of this feature using SIP; nor does this
document intend to do this. Rather, it intends to illustrate one way
in which it might be done. This flow appears as the equivalent of a
blind transfer with the PSTN gateway as the originator; the key
thing is that the PSTN gateway needs to understand this as a request
for Release to Pivot or equivalent PSTN feature.
Haluska, et al. Expires December 19, 2009 [Page 72]
Internet-Draft Information Services Using SIP June 2009
EO GW AS MS1 EO-2
| | | | |
| | | | |
| | | | |
|Incoming ISUP Call | | |
| | | | |
|(1) IAM | | | |
|------------->| | | |
| |(2) INVITE (GW SDP) | |
| |------------->| | |
| | |(3) INVITE (GW SDP) |
| | |------------->| |
| | |(4) 200 OK (MS1 SDP) |
| | |<-------------| |
| | |(5) ACK | |
| | |------------->| |
| |(6) 183 Session Progress (MS1 SDP) |
| |<-------------| | |
|(7) ACM | | | |
|<-------------| | | |
| |(8) PRACK | | |
| |------------->| | |
| |(9) 200 OK | | |
| |<-------------| | |
| |(10) RTP Session | |
| |.............................| |
|E.g. Front End Announcements | | |
| | | | |
| | |(11) BYE | |
| | |<-------------| |
| | |(12) 200 OK | |
| | |------------->| |
| |(13) REFER (call completion number) |
| |<-------------| | |
| |(14) 202 Accepted | |
| |------------->| | |
| |(15) NOTIFY(trying) | |
| |------------->| | |
| |(16) 200 OK | | |
| |<-------------| | |
|(17) REL | | | |
|<-------------| | | |
|(18) RLC | | | |
|------------->| | | |
| |(19) NOTIFY(200 OK) | |
| |------------->| | |
| |(20) 200 OK | | |
Haluska, et al. Expires December 19, 2009 [Page 73]
Internet-Draft Information Services Using SIP June 2009
| |<-------------| | |
|(21) IAM, etc.| | | |
|---------------------------------------------------------->|
| | | | |
| | | | |
11. Operator Services Example Call Flows
The following call flows provide examples of how specific operator
services could be implemented using the mechanisms described in this
document. The purpose is to illustrate one way to implement these
services using the proposed signaling mechanisms.
11.1. Network Controlled Coin Calls
This flow depicts a SIP based OISP handling calls from a network
controlled coin station. The OISP needs to determine the coinage
deposited by the station. Note that "smart" coin stations do not
require interaction with the OISP. This discussion only addresses
control of TDM based network controlled coin stations.
The configuration is as follows. Network controlled coin stations
are connected to TDM based end offices (EOs) using special access
lines, the characteristics of which are not important to this
discussion. The EO exchanges signaling with the station over this
access line, but does not perform the coin control. Operator
Services switches historically provide the control for these types
of calls, and the EO connects to the Operator Switch via special
coin control trunks. The EO translates between coin access and coin
trunk signaling.
The signaling includes coin station control and coin deposit
indications. The OISP uses coin station control signaling to
instruct the station to collect coins, return coins, etc. The coin
deposit signaling indicates the coinage inserted by the user.
Coin deposit signaling is sent as tones on the access line and on
the trunk. The values of these tones are described elsewhere. In
order to convey these tones, either a new event package would need
to be defined, or extensions to an existing event package, such as
KPML [RFC4730].
Haluska, et al. Expires December 19, 2009 [Page 74]
Internet-Draft Information Services Using SIP June 2009
Coin trunks can be SS7 or MF trunks. Both of these have native
signaling formats for conveying coin control events. PSTN gateways
interwork between PSTN and SIP signaling. Other than PSTN
interworking mechanisms, there is no currently defined mechanism for
conveying coin control events using SIP.
One potential way to address this would be to standardize a new
event package (or extend an existing package), so that SIP
notification mechanisms can be used. This is subject to the level of
IETF community interest and support.
Since coin deposit events are conveyed over the trunk as inband tone
bursts, this would not be covered by current PSTN interworking
mechanisms. There is no existing protocol mechanism which can
currently be used to convey coin deposit tones. KPML [RFC4730] is a
potential candidate for extension; this is for further study.
The main idea of the scheme presented here is that the OIS AS
exchanges coin control signaling with the coin station via the PSTN
GW, which speaks either MF or ISUP toward the end office serving the
coin station, and speaks SIP to the AS. The PSTN GW and AS exchange
encapsulated ISUP in SIP message bodies, which includes the ISUP SAP
parameter, and the PSTN GW uses either ISUP or MF to communicate
with the end office. The coin deposit signals are detected on the
voice path by the PSTN GW, and conveyed to the AS using either
extensions to KPML or a new SIP event package.
Note that the only reason for exchanging encapsulated ISUP here is
to exchange the SAP parameter. This also includes having the AS
generate encapsulated ISUP simply so that it can convey the SAP
information. An alternative option would be to define a MIME type
and carry this as a body in the SIP messages instead of encapsulated
ISUP. Generation of full ISUP messages when only the SAP parameter
is needed requires support of a full ISUP protocol stack at the AS,
which is otherwise unnecessary. One potential MIME media type which
might be used to this end is defined in [NSS].
In the following flow, the EO is the end office service the coin
station, the PSTN GW is the GW terminating the voice trunks and
signaling from the EO, the AS is the OIS AS, the MS is a media
server in the OIS provider, and the called party is self
explanatory.
In step 1, the coin station (not shown) has signaled a call request
to the EO, which in turn selects a coin trunk toward the OISP PSTN
GW, and initiates the corresponding signaling. In steps 2 through 4,
the PSTN GW sends an INVITE to the AS, which accepts the call.
Haluska, et al. Expires December 19, 2009 [Page 75]
Internet-Draft Information Services Using SIP June 2009
In steps 5 through 7, the AS sends a SIP INFO message containing
encapsulated ISUP, which contains an ISUP SAP parameter with the
Feature Code Indicator (FCI) indicating "Network Service Attached",
which is an instruction to the coin station that an Operator
Services System has been connected. The GW sends the corresponding
PSTN signaling back toward the coin station.
In steps 8 through 10, the AS using the same procedures sends
encapsulated ISUP with a SAP parameter with the FCI indicating "Coin
Collect" which instructs the coin station to collect and report on
coin deposits.
The coin deposits will be signaled as tones over the trunk, so the
AS in steps 11 through 14 subscribes to these events at the GW. This
example assumes an extension to KPML to support these tones, but the
mechanism is the same even if a new event package were defined.
In 15, the user deposits coins into the station, and these events
are signaled by the EO to the GW. In step 16, the GW sends SIP
NOTIFY messages to the AS for each such event.
When the AS determines that adequate payment has been collected, it
routes the call, as depicted in steps 18 through 24.
In this example, the caller exceeds his credit, and hangs up the
phone. This is represented by steps 25 through 27.
Using similar signaling, the OISP sends an Operator Hold and
Ringback request toward the station, to "keep the line open" and to
ring the station so that the user can be prompted to pay the
exceeded credit. This is represented in steps 28 through 36. In this
case, the honest user inserts the required coins, and this is
signaled to the OISP in steps 39 through 41. From steps 42 on, the
line is "released".
Haluska, et al. Expires December 19, 2009 [Page 76]
Internet-Draft Information Services Using SIP June 2009
EO GW AS MS Called Party
| | | | |
| | | | |
| | | | |
|(1) Call Request Indication | |
|-------->| | | |
| | | | |
| |(2) INVITE | |
| |-------->| | |
| | | | |
| |(3) 200 OK | |
| |<--------| | |
| | | | |
| |(4) ACK | | |
| |-------->| | |
| | | | |
| |(5) INFO (ISUP),SAP FCI=Network Service Attach)
| |<--------| | |
| | | | |
| |(6) 200 OK | |
| |-------->| | |
| | | | |
|(7) corresponding MF or ISUP signaling |
|<--------| | | |
| | | | |
| |(8) INFO (ISUP,SAP FCI=Coin Collect)
| |<--------| | |
| | | | |
| |(9) 200 OK | |
| |-------->| | |
| | | | |
|(10) corresponding MF or ISUP signaling|
|<--------| | | |
| | | | |
|(11) SUBSCRIBE (KPML body specifying coin deposit tones)
|<------------------| | |
| | | | |
|(12) 200 OK | | |
|------------------>| | |
| | | | |
|(13) NOTIFY (result of subscription) |
|------------------>| | |
| | | | |
|(14) 200 OK | | |
|<------------------| | |
| | | | |
|[ User inserts coins ] | |
Haluska, et al. Expires December 19, 2009 [Page 77]
Internet-Draft Information Services Using SIP June 2009
| | | | |
| | | | |
|(15) Coin deposit signals | |
|-------->| | | |
| | | | |
| |(16) NOTIFY (KPML body specifying coin deposit
tones)
| |-------->| | |
| | | | |
| |(17) 200 OK | |
| |<--------| | |
| | | | |
|[ AS determines adequate coinage, routes call ]
| | | | |
| | | | |
| | |(18) INVITE |
| | |------------------>|
| | | | |
| | |(19) 180 Ringing |
| | |<------------------|
| | | | |
| | |(20) 200 OK |
| | |<------------------|
| | | | |
| | |(21) ACK | |
| | |------------------>|
| | | | |
| |(22) re-INVITE (Called SDP) |
| |<--------| | |
| | | | |
| |(23) 200 OK | |
| |-------->| | |
| | | | |
| |(24) RTP | | |
| |.............................|
| | | | |
|[ Conversation, exceeds credit ] |
| | | | |
| | | | |
|[ Caller hangs up, tries to run ] |
| | | | |
| | | | |
|(25) Disconnect Request | |
|-------->| | | |
| | | | |
| |(26) INFO (ISUP,SAP FCI=Disconnect Request)
| |-------->| | |
Haluska, et al. Expires December 19, 2009 [Page 78]
Internet-Draft Information Services Using SIP June 2009
| | | | |
| |(27) 200 OK | |
| |<--------| | |
| | | | |
|[ AS requests Connection Hold and Ringback ]
| | | | |
| | | | |
| |(28) INFO (ISUP,SAP FCI=Hold Request)
| |<--------| | |
| | | | |
| |(29) 200 OK | |
| |-------->| | |
| | | | |
|(30) corresponding MF or ISUP signaling|
|<--------| | | |
| | | | |
|(31) Hold Acknowledge | |
|-------->| | | |
| | | | |
| |(32) INFO (ISUP,SAP FCI=Hold Acknowledge)
| |-------->| | |
| | | | |
| |(33) 200 OK | |
| |<--------| | |
| | | | |
| |(34) INFO (ISUP,SAP FCI=Ringback Request)
| |<--------| | |
| | | | |
| |(35) 200 OK | |
| |-------->| | |
| | | | |
|(36) corresponding MF or ISUP signaling|
|<--------| | | |
| | | | |
|[ User inserts coins ] | |
| | | | |
| | | | |
|(37) NOTIFY (KPML body specifying coin deposit tones)
|------------------>| | |
| | | | |
|(38) 200 OK | | |
|<------------------| | |
| | | | |
|[ Billing satisfied ] | |
| | | | |
| | | | |
| |(39) INFO (ISUP,SAP FCI=Hold Release Request)
Haluska, et al. Expires December 19, 2009 [Page 79]
Internet-Draft Information Services Using SIP June 2009
| |<--------| | |
| | | | |
| |(40) 200 OK | |
| |-------->| | |
| | | | |
|(41) corresponding MF or ISUP signaling|
|<--------| | | |
| | | | |
|[ User hangs up ] | | |
| | | | |
| | | | |
|(42) Disconnect Request | |
|-------->| | | |
| | | | |
| |(43) INFO (ISUP,SAP FCI=Disconnect Request)
| |-------->| | |
| | | | |
| |(44) 200 OK | |
| |<--------| | |
| | | | |
| |(45) BYE | | |
| |<--------| | |
| | | | |
| |(46) 200 OK | |
| |-------->| | |
| | | | |
|(47) corresponding MF or ISUP signaling|
|<--------| | | |
| | | | |
| | |(48) BYE | |
| | |------------------>|
| | | | |
| | |(49) 200 OK |
| | |<------------------|
| | | | |
| | | | |
| | | | |
Haluska, et al. Expires December 19, 2009 [Page 80]
Internet-Draft Information Services Using SIP June 2009
11.2. Busy Line Verification and Interrupt
An existing PTSN service is Busy Line Verification and Interrupt. In
the Busy Line Verification (BLV) Service, a customer obtains
operator assistance to determine if a called line is in use. In
Operator Interrupt Service, the operator provides a BLV Service and,
if requested by the caller, interrupts a conversation in progress
and relays a message. If the interrupted party is willing to hang
up, the call can be reoriginated by the caller to the called party.
At the caller's request, the connection between the caller and the
called party can be reinitiated and handled by the operator as a
Call Completion Service.
11.2.1. PSTN Target
Currently, BLV/I is handled by the Operator Services System placing
calls via special BLV/I trunk toward the target. Use of this type of
trunk results in the Operator Services System being able to monitor
a scrambled version of the target's conversation, and being able to
barge in to speak to the target. In this document, the focus of
BLV/I toward a PSTN target is on having the OIS components such as
OWS and AS be able to communicate with the EO via BLV/I trunks. For
IP targets, SIP capabilities are used.
The following figure depicts a BLV/I call to a PSTN target. In steps
(1) through (8) the caller is routed to an AS which performs 3PCC to
connect this caller to an operator workstation.
The operator determines the user's request, and initiates (9) a call
toward the target via a BLV/I trunk. Ensuring that the call is
routed via the correct type of trunk can be handled the same using
SIP as in the PSTN; that is, by prepending specified routing digits
to the target number. The operator is bridged by the EO onto the
target's line, during which time no voice is sent toward the caller.
A one way connection can be explicitly signaled, or the operator
workstation can simply not send RTP at this time. The operator
workstation or GW implements a scrambler so that only the presence
or absence of speech can be determined, and the operator then
reports to the caller on the status. If there is speech, then the
operator reports that the line is busy, and may offer to interrupt
the caller.
Haluska, et al. Expires December 19, 2009 [Page 81]
Internet-Draft Information Services Using SIP June 2009
If this is desired, the operator removes the scrambler, and
indicates to the target of the caller's desire to call them, and
drops off. The operator informs the caller of the result, and drops
the caller, who may then re attempt the call. The option where the
OISP offers the call as a call completion service is not shown here,
but this poses no unique requirements with respect to call
completion.
Haluska, et al. Expires December 19, 2009 [Page 82]
Internet-Draft Information Services Using SIP June 2009
Caller AS WS gw
|[ Caller dials 0+ or 0- ] |
|(1) INVITE | |
|-------->| | |
|(2) 180 Ringing | |
|<--------| | |
| |(3) INVITE |
| |-------->| |
| |(4) 200 OK |
| |<--------| |
| |(5) ACK | |
| |-------->| |
|(6) 200 OK | |
|<--------| | |
|(7) ACK | | |
|-------->| | |
|(8) RTP | | |
|...................| |
|[ Caller is now connected to operator ]
| | |(9) INVITE
| | |-------->|
| | |(10) 200 OK
| | |<--------|
| | |(11) ACK |
| | |-------->|
| | |(12) RTP |
| | |.........|
|[ Operator is now connected to BLV trunk ]
| | |(13) BYE |
| | |-------->|
| | |(14) 200 OK
| | |<--------|
|[ Operator drops caller ]
|(15) BYE | | |
|<------------------| |
|(16) 200 OK | |
|------------------>| |
|[ Caller may or may not place call, OISP uninvolved ]
Figure 11 BLV/I to PSTN Target
Haluska, et al. Expires December 19, 2009 [Page 83]
Internet-Draft Information Services Using SIP June 2009
11.2.2. SIP Target
The following depicts a BLV/I call to a SIP target. The approach
detailed here is based on that described in the PacketCable
Residential SIP Telephony Feature Specification, [RST].
The main aspects of this approach include using the Event dialog
package [RFC4235] to determine whether the device has an active
call, and using the Join header in order to bridge onto the current
conversation for monitoring and interrupting the user. Additional
aspects include the operator workstation performing the scrambling
function, and the use of a preconfigured network asserted
workstation identity from which the user device must accept and
process the BLV/I related requests.
Steps 1 through 8 represent an incoming call to the OISP being
connected to an operator workstation. The operator interacts with
the caller and determines the BLV/I request.
In steps 9 through 12, the operator workstation subscribes to the
Dialog event package at the target party's UA, and receives a NOTIFY
identifying any active dialogs.
In 13 through 16, the workstation sends an INVITE with a Join header
[RFC3911] to bridge onto the active call. The INVITE includes a P-
Asserted-Identity value corresponding to the value prearranged
between the OISP and the target's home provider. The user devices
are configured to accept SUBSCRIBEs for Dialog event package and
INVITEs with the Join header when the P-Asserted-Identity contains
this value. Thus, the user device accepts the Join header.
Initially, the workstation acts in a receive only mode, and further,
implements an audio scrambler such that speech is distinguishable as
such, but is non intelligible. Thus the operator can determine
whether the person at the target device is in active conversation.
During this time, the workstation does not exchange media with the
caller, who may be put on hold (not show here).
The operator can then report the status to the caller, and offer the
Interrupt service. If accepted, the scrambling function is removed
from the voice path between operator and target, and the operator
"barges in" on the conversation, informs the target party of the
caller's request, and asks whether the target would like to accept
the call. The operator can then drop the session with the target and
inform the caller about the target's response. There is of course no
guarantee of the target's or caller's subsequent actions.
Haluska, et al. Expires December 19, 2009 [Page 84]
Internet-Draft Information Services Using SIP June 2009
Caller AS WS Target
|[ Caller dials 0+ or 0- ] |
|(1) INVITE | |
|-------->| | |
|(2) 180 Ringing | |
|<--------| | |
|[ Simplified flow for brevity - straight to oper*
| |(3) INVITE |
| |-------->| |
| |(4) 200 OK |
| |<--------| |
| |(5) ACK | |
| |-------->| |
|(6) 200 OK | |
|<--------| | |
|(7) ACK | | |
|-------->| | |
|(8) RTP | | |
|...................| |
|[ Caller is now connected to operator ]
| | |(9) SUBSCRIBE (Dialog)
| | |-------->|
| | |(10) 200 OK
| | |<--------|
| | |(11) NOTIFY (Dialog state)
| | |<--------|
| | |(12) 200 OK
| | |-------->|
| | |(13) INVITE (Join, dialog id)
| | |-------->|
| | |(14) 200 OK
| | |<--------|
| | |(15) ACK |
| | |-------->|
| | |(16) RTP |
| | |.........|
| | |(17) BYE |
| | |-------->|
| | |(18) 200 OK
| | |<--------|
|[ Operator informs caller of target's disposition ]
|(19) BYE | | |
|<------------------| |
|(20) 200 OK | |
|------------------>| |
Haluska, et al. Expires December 19, 2009 [Page 85]
Internet-Draft Information Services Using SIP June 2009
11.3. Inward Calls
Typically, operator services are provided by the OISP serving a
user's originating provider. In some cases, another OISP must be
involved. One example is BLV/I, where an OISP can only invoke BLV/I
for targets served by providers that the OISP serves. In the case
of a caller desiring to invoke BLV/I to a target served by a
different provider, the caller's request would be routed to the same
OISP as usual. That OISP would identify the OISP serving the target,
and initiate an "inward" call to an operator in that OISP, and
request that operator to perform the BLV/I. For this feature, the
initiating OISP acts as the caller to the OISP serving the target.
Currently, Inward calls are originated by operators at operator
workstations, and terminated to operators at operator workstations.
Inward calls need to be distinguishable from calls from subscribers
that are routed to operators. Further, inward calls should be
accepted only from other OISPs, never from subscribers, and only
from those OISPs with appropriate business relationships.
The request should be screened based on the identity of originator.
Since the From header can easily be spoofed, a network-asserted
identity should be used for this. Within trust domains that use the
P-Asserted-Identity [RFC3325] header as a network asserted identity,
this header should be used for this purpose. Alternatively, the SIP
Identity mechanism [RFC4474] can be used in domains where this is
used for network asserted identity. Rather than maintain lists of
every possible URI for which Inward requests are allowed, the
decision could be based on the domain in the SIP URI. Requests from
domains corresponding only to OISPs which are authorized to make
Inward requests would be accepted.
In the current North American PSTN, the digits dialed by the
operator placing Inward call can be used to identify the type of
service being requested, so that the destination OISP can properly
handle the request. These digits are known as Operator Special
Dialed Code (OSDC) digits. Thus, the Request-URI should include the
OSDC digits, and the AS should populate the Request-URI as a SIP URI
which includes the SIP domain of the destination OISP as well as the
OSDC code.
For Inward calls to PSTN based OISPs, the call should be placed via
a PSTN gateway, and should appear to the destination OISP the same
as any other Inward call.
Haluska, et al. Expires December 19, 2009 [Page 86]
Internet-Draft Information Services Using SIP June 2009
11.4. Intercept
Intercept service provides the capability for a customer to be
informed that a working number is no longer in service or why a
working number is no longer in service. Basically, it provides
announcements to the caller, which may be fixed or dynamic.
Currently in the North American PSTN, Intercept may be handled by
individual end offices, or may be sent to Operator Services Systems,
which have specialized resources for handling such requests. When a
call reaches a PSTN switch for a number which requires Intercept
treatment, that switch, known as the "intercepted switch", initiates
an Intercept request for that "intercepted number". The request to
an OISP specifies the intercepted number, and an "intercept type",
which provides an indication of the general reason for intercept.
Often, the OISP needs to consult an "intercept database" to
determine specific processing for a particular intercepted number.
Currently, with MF, dedicated Intercept trunk groups are typically
used, so the call is implicitly identified as such. The ANI digits
identify the intercepted number, and the II digits identify the
intercept type. For ISUP, dedicated trunk groups may or may not be
used, but the SAP parameter identifies the intercept type, and the
Called Party Number parameter identifies the intercepted number. In
both cases, the key information conveyed include identification of
the request as intercept, intercept type, and intercepted number.
11.4.1. Intercept Request Via SIP
Intercept requests to a SIP based OISP need to convey the same
information currently conveyed. Such requests can be treated as a
call forwarded to an Intercept service. Thus, the Request-URI should
identify the request as Intercept, as well as conveying the
intercept type. The currently defined values for intercept type
include regular, blank, and trouble. Prepending these with
"intercept-" in the left hand side of the Request-URI unambiguously
identifies the request as intercept and conveys the intercept type.
Treating this as a redirection, the SIP History-Info header can be
used to convey the intercepted number. An example of such an INVITE
(relevant fields only) follows:
Haluska, et al. Expires December 19, 2009 [Page 87]
Internet-Draft Information Services Using SIP June 2009
INVITE sip:intercept-trouble@oisp-c.example.com SIP/2.0
From: <sip:7327581111@provider-a.example.com>;tag=1234567
To: <sip:7327582222@provider-b.example.com>
History-Info: <sip:7327582222@provider-b.example.com>; index=1
Content-Type: application/sdp
Content-Length: ...
Upon receiving such a request, the AS would typically perform any
required processing, including database lookups, and generate a
request to a MS to play the specified announcement. The conventions
described in [RFC4240] can be used for this.
An example high level message flow follows:
Haluska, et al. Expires December 19, 2009 [Page 88]
Internet-Draft Information Services Using SIP June 2009
Intercepted domain AS MS
| | |
| | |
| | |
[ Receives a call requiring Intercept service ]
| | |
| | |
|(1) INVITE ( r-URI->intercept type, Hist-
Info=intercepted number )
|------------->| |
| | |
| |(2) INVITE (r-URI->RFC 4240 annc)
| |------------->|
| | |
| |(3) 200 OK |
| |<-------------|
| | |
| |(4) ACK |
| |------------->|
| | |
|(5) 183 Session Progress |
|<-------------| |
| | |
|(6) RTP (announcements) |
|.............................|
| | |
|Caller hangs up |
| | |
| | |
|(7) BYE | |
|------------->| |
| | |
|(8) 200 OK | |
|<-------------| |
| | |
| |(9) BYE |
| |------------->|
| | |
| |(10) 200 OK |
| |<-------------|
| | |
| | |
Haluska, et al. Expires December 19, 2009 [Page 89]
Internet-Draft Information Services Using SIP June 2009
11.4.2. Intercept Request Via PSTN
When intercept requests are received from PSTN interfaces, the PSTN
gateway needs to translate the incoming signaling to SIP. The
preferred approach is to have the PSTN gateway construct an INVITE
request of the form described above for requests received via SIP.
This method requires additional functionality on the part of the
gateway, but the AS only needs to recognize one type of INVITE
request for Intercept.
Alternatively, the gateway could construct an INVITE containing
encapsulated ISUP, in which the Called Party Number and SAP fields
are most significant. Also, the Request-URI should contain the
Called Party Number. With this method, the PSTN gateway treats the
INVITE the same as other INVITEs, but requires the AS to recognize
this as an Intercept request by examining the encapsulated ISUP body
contents.
Haluska, et al. Expires December 19, 2009 [Page 90]
Internet-Draft Information Services Using SIP June 2009
Intercepted
Switch PSTN GW AS MS
| | | |
| | | |
| | | |
|[ Receives a call requiring Intercept service ]
| | | |
| | | |
|(1) IAM ( CdPN digits=intcptd number, CdPN NOA=op req,
SAP=intcpt type )
|------------->| | |
| | | |
| |(2) INVITE (see above)
| |------------->| |
| | | |
| | |(3) INVITE (r-URI->RFC 4240 annc)
| | |------------->|
| | | |
| | |(4) 200 OK |
| | |<-------------|
| | | |
| | |(5) ACK |
| | |------------->|
| | | |
| |(6) 183 Session Progress |
| |<-------------| |
| | | |
|(7) ACM | | |
|<-------------| | |
| | | |
| |(8) RTP (announcements) |
| |.............................|
| | | |
|(9) TDM (announcements) | |
|..............| | |
| | | |
|Caller hangs up | |
| | | |
| | | |
|(10) REL | | |
|------------->| | |
| | | |
| |(11) BYE | |
| |------------->| |
| | | |
| |(12) 200 OK | |
| |<-------------| |
Haluska, et al. Expires December 19, 2009 [Page 91]
Internet-Draft Information Services Using SIP June 2009
| | | |
|(13) RLC | | |
|<-------------| | |
| | | |
| | |(14) BYE |
| | |------------->|
| | | |
| | |(15) 200 OK |
| | |<-------------|
| | | |
11.5. Operator Assisted Collect Call
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 December 19, 2009 [Page 92]
Internet-Draft Information Services Using SIP June 2009
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 December 19, 2009 [Page 93]
Internet-Draft Information Services Using SIP June 2009
| | | | | | |
| | |(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 December 19, 2009 [Page 94]
Internet-Draft Information Services Using SIP June 2009
| | | |.........| | |
| | | | | | |
|[ 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 December 19, 2009 [Page 95]
Internet-Draft Information Services Using SIP June 2009
|[ 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 December 19, 2009 [Page 96]
Internet-Draft Information Services Using SIP June 2009
|(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 December 19, 2009 [Page 97]
Internet-Draft Information Services Using SIP June 2009
| | | | | | |
| | | | | | |
| | | | | | |
Figure 12 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 December 19, 2009 [Page 98]
Internet-Draft Information Services Using SIP June 2009
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.6. Operator Assisted Third Party Billing
The Operator Assisted Third Party Billing service allows a caller to
request billing of a call to a third party. In such a service, the
caller calls the operator, who places a call to the billed party to
obtain authorization for billing. If authorized, the OISP places the
call to the called party, and bills it to the billed party. This
document focuses on the call flow and SIP signaling, and does not
discuss the billing mechanisms.
In 1 through 8 below, the caller is connected to the operator. In 9
through 14, the operator places the caller on hold, and in 15
through 18 the operator calls the billed party to ask for
authorization. In 21, the operator un-holds the caller and informs
of the authorization. In 18 the operator initiates a call to the
called party via the AS by sending a REFER to the AS.
Haluska, et al. Expires December 19, 2009 [Page 99]
Internet-Draft Information Services Using SIP June 2009
Caller CSCF AS WS Billed Called
| | | | | |
| | | | | |
| | | | | |
|[ Caller dials 0+ or 0- ] | | |
| | | | | |
| | | | | |
|(1) INVITE | | | |
|------------------>| | | |
|(2) 100 Trying | | | |
|<------------------| | | |
| | | | | |
|[ AS determines operator is needed, performs 3PCC ]
| | | | | |
| | | | | |
| | |(3) INVITE | |
| | |-------->| | |
| | |(4) 200 OK | |
| | |<--------| | |
| | |(5) ACK | | |
| | |-------->| | |
| | | | | |
|(6) 200 OK | | | |
|<------------------| | | |
|(7) ACK | | | | |
|------------------>| | | |
| | | | | |
|[ Caller is now connected to operator ]| |
| | | | | |
| | | | | |
|(8) RTP | | | | |
|.............................| | |
| | | | | |
|[ Operator determines caller's request and places on hold]
| | | | | |
| | | | | |
| | |(9) re-INVITE (HOLD) |
| | |<--------| | |
| | |(10) 200 OK | |
| | |-------->| | |
| | |(11) ACK | | |
| | |<--------| | |
| | | | | |
|[ AS could optionally send caller to advertisements vs hold ]
| | | | | |
| | | | | |
Haluska, et al. Expires December 19, 2009 [Page 100]
Internet-Draft Information Services Using SIP June 2009
|(12) re-INVITE (HOLD) | | |
|<------------------| | | |
|(13) 200 OK | | | |
|------------------>| | | |
|(14) ACK | | | | |
|<------------------| | | |
| | | | | |
|[ Operator calls billed party ] | |
| | | | | |
| | | | | |
| | | |(15) INVITE |
| | | |-------->| |
| | | |(16) 200 OK |
| | | |<--------| |
| | | |(17) ACK | |
| | | |-------->| |
| | | | | |
| | | |(18) RTP | |
| | | |.........| |
| | | | | |
|[ Charges OK, operator disconnects billed party ]|
| | | | | |
| | | | | |
| | | | | |
| | | |(19) BYE | |
| | | |-------->| |
| | | |(20) 200 OK |
| | | |<--------| |
| | | | | |
|[ Operator informs AS of result, un-HOLDs caller ]
| | | | | |
| | | | | |
| | |(21) re-INVITE(result, un-HOLD)
| | |<--------| | |
| | | | | |
|(22) re-INVITE(un-HOLD) | | |
|<------------------| | | |
|(23) 200 OK | | | |
|------------------>| | | |
|(24) ACK | | | | |
|<------------------| | | |
| | | | | |
| | |(25) 200 OK | |
| | |-------->| | |
| | |(26) ACK | | |
| | |<--------| | |
| | | | | |
Haluska, et al. Expires December 19, 2009 [Page 101]
Internet-Draft Information Services Using SIP June 2009
|(27) RTP | | | | |
|.............................| | |
| | | | | |
|[ Operator informs caller, transfers AS to initiate call ]
| | | | | |
| | | | | |
| | |(28) REFER | |
| | |<--------| | |
| | |(29) 202 Accepted | |
| | |-------->| | |
| | | | | |
| | |(30) NOTIFY (trying) |
| | |-------->| | |
| | |(31) 200 OK | |
| | |<--------| | |
| | | | | |
|[ AS places call to called party, notifies WS on success ]
| | | | | |
| | | | | |
| | |(32) INVITE | |
| | |---------------------------->|
| | |(33) 180 | | |
| | |<----------------------------|
| | |(34) 200 OK | |
| | |<----------------------------|
| | |(35) ACK | | |
| | |---------------------------->|
| | | | | |
|(36) re-INVITE | | | |
|<------------------| | | |
|(37) 200 OK | | | |
|------------------>| | | |
|(38) ACK | | | | |
|<------------------| | | |
| | | | | |
| | |(39) NOTIFY (Call completed) |
| | |-------->| | |
| | |(40) 200 OK | |
| | |<--------| | |
| | | | | |
|[ Operator drops] | | | |
| | | | | |
| | | | | |
| | |(41) BYE | | |
| | |<--------| | |
| | |(42) 200 OK | |
| | |-------->| | |
Haluska, et al. Expires December 19, 2009 [Page 102]
Internet-Draft Information Services Using SIP June 2009
| | | | | |
Figure 13 Operator Assisted Third Party Billed Call
12. Summary and Conclusions
The intent of this document is to explain how Directory Assistance and
Operator Services work, and explore how they could be implemented with
SIP. This includes both SIP originated requests as well as interworking
with requests from the PSTN.
A basic architecture utilizing an application server as the primary
controller, performing third party call control to route incoming calls
among media servers, operator workstations, etc. is described.
Interface to the PSTN is described using PSTN gateways which interwork
between ISUP or MF signaling and SIP.
Operator services in the North American PSTN often utilize MF trunks.
As there is currently no specific specification for MF/SIP
interworking, we assume that the PSTN gateway performs an internal MF
to ISUP translation.
The use of existing SIP mechanisms is described where possible. Some of
the main mechanisms described include third party call control, the
REFER method with several extensions (e.g. Replaces), the Join header,
Netann, and some of the ongoing work in the MEDIACTRL working group.
Several protocol gaps and issues were identified. These include:
Originating Line Information/ANI II Digits
Charge Number
Coin Deposit Tones
Carrier Information: ISUP TNS, CIP, and CSI parameters, and "cic",
"dai" tel URI parameters/
Haluska, et al. Expires December 19, 2009 [Page 103]
Internet-Draft Information Services Using SIP June 2009
For conveyance of coin deposit tones, the document suggests that
extensions to KPML are one potential option, and shows how KPML could
be used to this end. Definition of an operator services SIP event
package is mentioned as another alternative.
The desired next steps include soliciting feedback from the IETF
community on the choices and intended usages of the proposed
mechanisms.
13. Security Considerations
This document does not introduce any new security considerations. It
describes the use of protocol mechanisms which may have security
implications; the Security Considerations sections of the documents
defining these mechanisms should be consulted.
14. IANA Considerations
This revision of this document does not 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 December 19, 2009 [Page 104]
Internet-Draft Information Services Using SIP June 2009
15. References
15.1. Normative References
[RFC3261] Rosenberg, et al, J., "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC4474] Peterson, Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol
(SIP)", RFC 4474, August 2006.
[RFC3325] Jennings, et al, "Private Extensions to the Session
Initiation Protocol (SIP) for Asserted Identity within
Trusted Networks", RFC 3325, November 2002.
15.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)
[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.
[RFC4240] Burger, et al, "Basic Network Media Services with SIP",
RFC 4240, December 2005.
[RFC3725] Rosenberg, et al, "Best Current Practices for Third
Party Call Control (3pcc) in the Session Initiation
Protocol (SIP)", RFC 3725, April 2004.
Haluska, et al. Expires December 19, 2009 [Page 105]
Internet-Draft Information Services Using SIP June 2009
[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)
[NSS] American National Standards Institute, Inc., "ANSI Extensions
to the Narrowband Signaling Syntax (NSS) - Syntax
Definition", ATIS-1000008.2006, January 2006.
[RFC4904] Gurbani, et al, "Representing Trunk Groups in tel/sip
Uniform Resource Identifiers (URIs)", RFC 4904, June 2007.
[RFC4730] Burger, Dolly, "A Session Initiation Protocol (SIP) Event
Package for Key Press Stimulus (KPML)", RFC 4730, November
2006.
[RST] PacketCable, " Residential SIP Telephony Feature
Specification", PKT-SP-RSTF-I01-060927, September 2006.
[RFC4235] Rosenberg, et al, "An INVITE-Initiated Dialog Event
Package for the Session Initiation Protocol (SIP)", RFC
4235, November 2005.
[RFC3911] Mahy, et al, "The Session Initiation Protocol (SIP) "Join"
Header", RFC 3911, October 2004.
[RFC3398] Camarillo, et al, "Integrated Services Digital Network
(ISDN) User Part (ISUP) to Session Initiation Protocol
(SIP) Mapping", RFC 3398, December 2002.
[RFC3840] Rosenberg, et al, "Indicating User Agent Capabilities in
the Session Initiation Protocol (SIP)", RFC 3840, August
2004.
[RFC4483] Burger, et al, "A Mechanism for Content Indirection in
Session Initiation Protocol (SIP) Messages", RFC 4483, May
2006.
[RFC2045] Freed, et al, "Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies", RFC
2045, November 1996.
[RFC3204] Zimmerer, et al, "MIME media types for ISUP and QSIG
Objects", RFC 3204, November 2001.
Haluska, et al. Expires December 19, 2009 [Page 106]
Internet-Draft Information Services Using SIP June 2009
[RFC3325] Jennings, et al, "Private Extensions to the Session
Initiation Protocol (SIP) for Asserted Identity within
Trusted Networks", RFC 3325, November 2002.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
3966, December 2004.
[RFC4244] Barnes, et al, "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", RFC 4244,
November 2005.
[RFC4694] Yu, J., "Number Portability Parameters for the "tel" URI",
RFC 4694, October 2006.
[DAI] Yu, et al, "DAI Parameter for the tel URI", draft-yu-tel-dai-
05, June 2008. (work in progress)
[T1679] Alliance for Telecommunications Industry Solutions (ATIS)
Committee T1, "American National Standard for
Telecommunications - Interworking between Session
Initiation Protocol (SIP) and Bearer Independent Call
Control or ISDN User Part", ATIS T1.679-2004, June 2004.
[PCI] York, et al, "P-Charge-Info: A Private Header (P-Header)
Extension to the Session Intitiation Protocol (SIP)",
draft-york-sipping-p-charge-info-05, November 2008. (work
in progress)
Haluska, et al. Expires December 19, 2009 [Page 107]
Internet-Draft Information Services Using SIP June 2009
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 December 19, 2009 [Page 108]
Internet-Draft Information Services Using SIP June 2009
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
D. E. Scott
VoltDelta
2401 N. Glassell St.
Orange, CA 92865-2705
Email: dscott@voltdelta.com
Haluska, et al. Expires December 19, 2009 [Page 109]