Internet DRAFT - draft-dcsgroup-sipping-arch
draft-dcsgroup-sipping-arch
SIPPING Working Group W. Marshall
Internet Draft AT&T
Document: <draft-dcsgroup-sipping-arch-01.txt>
Category: Informational M. Osman
CableLabs
F. Andreasen
Cisco
D. Evans
ARRIS
January 15, 2003
Architectural Considerations for Providing Carrier Class Telephony
Services Utilizing Session Initiation Protocol (SIP)-based
Distributed Call Control Mechanisms
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document provides an overview of a SIP-based Distributed Call
Signaling (DCS) architecture to support carrier class packet-based
voice, video, and other real time multimedia services. Companion
documents address a specific set of SIP 2.0 protocol extensions and
usage rules that are necessary to implement the DCS architecture in
an interoperable fashion.
The DCS architecture takes advantage of endpoint intelligence in
supporting telephony services without sacrificing the network's
ability to provide value through mechanisms such as resource
management, lookup of directory information and translation
databases, routing services, security, and privacy enforcement. At
the same time, the architecture provides flexibility to allow
DCS Group Category: Informational - Expiration 04/30/03 1
DCS Architecture October 2002
evolution in the services that may be provided by endpoints and the
network.
DCS also takes into account the need to manage access to network
resources and account for resource usage. The SIP usage rules
defined in the accompanying IDs specifically address the
coordination between Distributed Call Signaling and dynamic quality
of service control mechanisms for managing resources over the access
network. In addition, the DCS architecture defines the interaction
needed between network provided call controllers, known as a "DCS-
proxy" for supporting these services.
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Table of Contents..................................................2
1. Introduction....................................................2
2. Background and Motivation.......................................3
2.1 Requirements And Design Principles.............................4
2.2 Distributed Call Signaling Architecture........................6
2.3 Trust Boundary.................................................9
2.4 Basic Call Flow................................................9
3. Resource Management............................................12
4. Distributed Call State.........................................13
5. DCS Proxy - DCS Proxy Communications...........................15
6. Privacy........................................................16
7. Security Considerations........................................18
8. Notice Regarding Intellectual Property Rights..................18
9. Informative References.........................................18
10. Acknowledgements..............................................19
11. Author's Addresses............................................19
Full Copyright Statement..........................................21
Acknowledgement...................................................21
1. Introduction
This document provides an overview of a SIP[6]-based Distributed
Call Signaling (DCS) architecture to support carrier class packet-
based voice, video, and other real time multimedia services. The
DCS architecture and the corresponding SIP protocol enhancements
(described in companion documents) are being developed as part of
the cable industry's PacketCable initiative, managed out of
CableLabs (see www.cablelabs.com). PacketCable is defining a series
of interface specifications that will enable vendors to develop
interoperable products for providing internet telephony and other
multimedia services over DOCSIS-enabled cable data networks.
The DCS architecture described herein has its roots in the DOSA work
performed by AT&T Laboratories ["Distributed Open Signaling
Architecture"; Kalmanek, Marshall, Mishra, Nortz, Ramakrishnan, et
al.; October, 1998]. A relatively large group of vendors have
cooperated in an intensive effort to develop the DCS architecture
and SIP protocol extensions described here and in the accompanying
DCS Group Category: Informational - Expiration 04/30/03 2
DCS Architecture October 2002
protocol drafts. Although DCS was originally designed with cable
access networks in mind, the SIP signaling enhancements have general
applicability to carrier class Voice over IP (VoIP) services running
over Quality of Service (QoS) enabled IP networks.
The authors have submitted this document to the IETF in order to
provide general information regarding the DCS architecture and to
convey the motivation behind the SIP enhancements recommended in the
accompanying protocol drafts. We believe that providing SIP
extensions for the concepts and mechanisms described in this set of
drafts will significantly enhance SIP's ability to function as a
carrier-class signaling protocol. Such an enhancement to SIP would
undoubtedly aid in its widespread acceptance and deployment. We have
incorporated several useful comments received from the IETF SIP and
SIPPING Working groups on earlier versions of this and the other DCS
related drafts.
The PacketCable Draft Specification for DCS is available from the
CableLabs website at:
ftp://ftp.cablelabs.com/pub/pkt-sp-dcs-d03-000428.pdf
2. Background and Motivation
The design of the Distributed Call Signaling (DCS) architecture
recognizes the trend towards use of packet networks as the
underlying framework for communications. These networks will
provide a broad range of services, including traditional best-effort
data service as well as enhanced, value-added services, such as
telephony. At the same time, improvements in silicon will reinforce
the trend towards increased functionality in endpoints. These
intelligent endpoints will take advantage of the widespread
availability of packet networks to enable a rich set of applications
and services for users.
However, when the network is used for real-time telephony
applications, it is essential to have service differentiation at the
IP layer. The ability to control and monitor usage is needed for
the provider to be able to provide service differentiation and to
derive revenue from the enhanced services. At the same time, the
availability of best effort communications and the migration of
functionality to the endpoints pose a challenge to the provider to
find incentives for users to use or pay for enhanced services.
We see three key functions that a provider can offer, as incentives
to use enhanced services. First, the network service provider has
the unique ability to manage and provide network layer quality of
service. When users depend on the quality of the service, as with
telephony, there is a strong incentive to use the enhanced service,
rather than a best effort service. Second, the network service
provider can play an important role as a trusted intermediary. This
includes ensuring the integrity of call routing, as well as ensuring
both the accuracy and the privacy of information that is exchanged.
DCS Group Category: Informational - Expiration 04/30/03 3
DCS Architecture October 2002
The service provider can also add value by ensuring that services
are provided consistently and reliably, even when an endpoint is
unavailable. Finally, there are a number of services that may be
offered more efficiently by the network service provider rather than
in endpoints. For example, conference bridging may be more cost
effective to implement in a multi-point bridge rather than in every
endpoint attached to the network.
A key contribution of the DCS architecture is a recognition of the
need for coordination between call signaling, which controls access
to telephony specific services, and resource management, which
controls access to network-layer resources. This coordination is
designed to meet the user expectations and human factors associated
with telephony. For example, the called party should not be
alerted until the resources necessary to complete the call are
available. If resources were not available when the called party
picked up, the user would experience a call defect. In addition,
users expect to be charged for service only after the called party
answers the phone. As a result, usage accounting starts only after
the called party picks up. Coordination between call signaling and
resource management is also needed to prevent fraud and theft of
service. The coordination between DCS and Dynamic QoS protocols
ensures that users are authenticated and authorized before receiving
access to the enhanced QoS associated with the telephony service.
It is important to be able to deploy a residential telephone service
at very large scale, cost-effectively. To achieve this, DCS
minimizes the messaging overhead on network call servers, and does
not require these servers to maintain call state for active calls.
Once a call is established, call state is maintained only where it
is needed, in keeping (informally) with the principle of "fate-
sharing" at the endpoints that are involved in the call, and at the
Edge Routers in the bearer path that are providing differentiated
service to the media flow. This allows the network call servers to
scale to support more users, and imposes less stringent reliability
requirements on those servers.
DCS is also designed so that calling users receive consistent
service even when a called endpoint is unavailable. For example,
when an endpoint is unavailable, service logic in a network call
server can forward telephone calls to a voice mailbox.
2.1 Requirements And Design Principles
In this section, we briefly describe the application requirements
that led to a set of DCS signaling design principles. In its most
basic implementation, DCS supports a residential telephone service
comparable to the local telephone services offered today. In
addition to the commonly used service features that need to be
supported, there are important requirements in the areas of
reliability, performance, and scalability that influence the
signaling architecture. Supporting an IP telephony service
DCS Group Category: Informational - Expiration 04/30/03 4
DCS Architecture October 2002
comparable to the telephony service offered today requires enhanced
bearer channel and signaling performance, including:
. Low delay - end-to-end packet delay must be small enough that it
does not interfere with normal voice conversations. The ITU
recommends no greater than 300 ms roundtrip delay for telephony
service.
. Low packet loss - packet loss must be small enough to not
perceptibly impede voice quality or performance of fax and voice
band modems.
. Short post-dial delay - the delay between the user dialing the
last digit and receiving positive confirmation from the network
must be short enough that users do not perceive a difference with
post-dial delay in the circuit switched network or believe that
the network has failed.
. Short post pickup delay - the delay between a user picking up a
ringing phone and the voice path being cut through must be short
enough so that the "hello" from either the initiator or the
receiver of the call is not clipped.
We identify a number of key design principles that arise from the
requirements and philosophy outlined above:
1. It is essential to provide differentiated network-layer quality of
service, while allowing the provider to derive revenues from the
use of such differentiated services.
2. The architecture should allow, and even encourage, implementation
of services and features in the intelligent endpoints, where
economically feasible, while still retaining value in the network
and network-based services.
3. The architecture must ensure that the network is protected from
fraud and theft of service. The service provider must be able to
authenticate users requesting service and ensure that only those
authorized to receive a particular service be able to obtain it.
4. The architecture must enable the service provider to add value by
supporting the functions of a trusted intermediary. This includes
protecting the privacy of calling and called party information,
and ensuring the accuracy of the information that is provided in
messages from the network.
5. The architecture must enable the service provider to give a
consistent view of basic services and features even when customer
premise equipment is unavailable, and allow users to take
advantage of functionality that is provided in the network, when
it is cost-effective and easy to use.
DCS Group Category: Informational - Expiration 04/30/03 5
DCS Architecture October 2002
6. The architecture must be implementable, cost-effectively, at very
large scale.
2.2 Distributed Call Signaling Architecture
The Distributed Call Signaling Architecture follows the principles
outlined above to support a robust telephony service. Figure 1
introduces the key components in the architecture.
The architecture assumes a broad range of DCS-compliant endpoints
that provide telephony service to the user including Media Terminal
Adapters (MTAs) that may be integrated with a Cable Modem or is a
standalone device, as well as other endpoints such as personal
computers. The access network interfaces to an IP backbone through a
system we refer to as the Edge Router (ER). The ER is the first
trusted element within the provider's network and is considered to
be the edge of the network for providing access to differentiated
quality of service. We believe that the access network is likely to
manage resources on a per-flow basis, with associated signaling
mechanisms (such as RSVP). The ER performs resource management, acts
as a policy enforcement point and as a source of billing
information.
DCS-proxies (DPs) process call signaling messages and support number
translation, call routing, feature support and admission control.
In the context of SIP, a DCS-proxy is a SIP proxy that is involved
in processing and forwarding of SIP requests. DPs act as trusted
decision points for controlling when resources are committed to
particular users. Media servers represent network-based components
that operate on media flows to support the service. Media servers
perform audio bridging, play terminating announcements, provide
interactive voice response services, etc. Finally, PSTN gateways
interface to the Public Switched Telephone Network.
DCS Group Category: Informational - Expiration 04/30/03 6
DCS Architecture October 2002
+-----+
| MTA | MTA: media terminal adapter
+-----+
| ER: Edge Router
Access Network |
|
+----+
| ER |
+----+
| +-----------+
|----| DCS Proxy |
| +-----------+
|
| +------------+
Backbone Network |----|Media Server|
| +------------+
|
| +------------+
|----|PSTN Gateway|
| +------------+
+----+
| ER |
+----+
|
Access Network |
|
+-----+
| MTA |
+-----+
Figure 1: A Simple view of Components of an IP Telephony
Architecture used in a HFC Cable Environment.
Telephony endpoints are considered to be "clients" of the telephony
service. Consistent with the design principles, the architecture
allows a range of services to be implemented by intelligent
endpoints. They collect dialed digits, participate in signaling and
contain the service logic required for basic call setup and feature
support. Endpoints also participate in end-to-end capability
negotiation. However, endpoints are not trusted to provide accurate
information to the network or to keep information that is received
private, except when it is in the endpoint's best interests to do
so.
Access to network resources on a differentiated basis is likely to
be controlled by the service provider. The ER receives resource
management requests from endpoints, and is responsible for ensuring
that packets are provided the QoS they are authorized to receive
(either through packet marking, or through routing and queuing the
packets as a specific QoS assured flow). The ER requires
authorization from a network entity (on a call-by-call basis for the
telephony service) before providing access to enhanced QoS for an
end-to-end IP flow. The obvious point where this policy and control
function resides is the DCS-proxy (also called a gate-controller,
DCS Group Category: Informational - Expiration 04/30/03 7
DCS Architecture October 2002
because of this responsibility for managing access to enhanced QoS).
Thus, the ER is able to ensure that enhanced QoS is only provided
for end-to-end flows that have been authorized and for which usage
accounting is being done. Since the ER knows about the resource
usage associated with individual IP flows, it generates the usage
events that allow a user to be charged for service.
We introduce the concept of a "gate" in the ER, which manages access
to enhanced quality of service. The gate is a packet classifier and
policer that ensures that only those IP flows that have been
authorized by the DCS-proxy are granted access to enhanced QoS in
the access and backbone networks. Gates are "opened" selectively for
a flow. For the telephony service, they are opened for individual
calls. Opening a gate involves an admission control check that is
performed when a resource management request is received from the
endpoint for an individual call, and it may involve resource
reservation in the network for the call if necessary. The packet
filter in the gate allows a flow of packets to receive enhanced QoS
for a call from a specific IP source address and port number to a
specific IP destination address and port number.
The DCS-proxy, in addition to implementing many of the call control
functions, is responsible for the policy decision regarding whether
the gate should be opened. DCS sets up a gate in advance of a
resource management message. This allows the policy function, which
is at the DCS-proxy, to be "stateless" in that it does not need to
know the state of calls that are already in progress.
DCS-proxies are typically organized in domains. A DCS-proxy is
responsible for a set of endpoints and the associated ERs. While
endpoints are not trusted, there is a trust relationship between the
ER and its associated DCS-proxy, since the DCS-proxy plays a role as
a policy server controlling when the ER can provide enhanced QoS
service. There is also a trust relationship among DCS-proxies.
Details of the security model are outside the scope of this draft.
The DCS-proxy is designed as a simple transaction server, so that
the failure of a DCS-proxy does not affect calls in progress. A
domain will likely have a primary and one or more secondary DCS-
proxies. If the primary DCS-proxy fails, only calls in a transient
state are affected. The endpoints involved in those calls will time
out and retry. All active calls are unaffected. This is possible
because the DCS-proxy retains no call state for stable calls. We
believe this design makes the DCS-proxy efficient and highly
scalable, and keeps the reliability requirements manageable.
DCS supports inter-working with the circuit switched telephone
network through PSTN gateways. A PSTN gateway may be realized as a
combination of a media gateway controller, media gateway, and a
signaling gateway. A media gateway acts as the IP peer of an
endpoint for media packets, converting between the data format used
over the IP network and the PCM format required for transmission
over the PSTN. The media gateway controller or the signaling gateway
DCS Group Category: Informational - Expiration 04/30/03 8
DCS Architecture October 2002
acts as the IP peer of an endpoint for signaling packets, providing
signaling inter-working between DCS and conventional telephony
signaling protocols such as ISUP/SS7. When the media gateway
controller is the peer, it communicates with the signaling gateway.
A media gateway control protocol is used to control the operation of
the media gateway from the media gateway controller.
There are additional system elements that may be involved in
providing the telephony service. For example, the DCS-proxy may
interface with other servers that implement the authorization or
translation functions. Similarly, three way calling may be supported
using media servers in the network.
2.3 Trust Boundary
The DCS architecture defines a trust boundary around the various
systems and servers that are owned, operated by, and/or controlled
by the service provider. These trusted systems include the proxies
and various servers such as bridge servers, voicemail servers,
announcement servers, etc. Outside of the trust boundary lie the
customer premises equipment, and various media servers operated by
third-party service providers.
Certain subscriber-specific information, such as billing and
accounting information, stays within the trust boundary. Other
subscriber-specific information, such as endpoint identity, may be
presented to untrusted endpoints or may be withheld based on
subscriber profiles.
The SIP User Agent (UA) may be either within the trust boundary
(e.g. PSTN gateway) or outside the trust boundary (e.g. MTA),
depending on exactly what function is being performed and exactly
how it is being performed. Accordingly, the procedures followed by
a User Agent, as contained in the accompanying drafts, are different
depending on whether the UA is within the trust boundary or outside
the trust boundary. A trusted user agent is, in almost all cases,
equivalent to the combination of an untrusted user agent and a
proxy.
2.4 Basic Call Flow
Figure 2 presents a high-level overview of a basic MTA-to-MTA call
flow in DCS. Each MTA is associated with a DCS-proxy, which acts as
a SIP proxy. When a user goes off-hook and dials a telephone number,
the originating MTA (MTA-o) collects the dialed digits and sends the
initial INVITE message in SIP, to the "originating" DCS-proxy (DP-
o). This INVITE contains SDP proposing a set of codecs that are
acceptable to MTA-o (and their implied bandwidth requirements), and
an indication of the (mandatory) QoS preconditions [7] needed for
the session. DP-o verifies that MTA-o is a valid subscriber of the
telephony service (using authentication information in the INVITE
message) and determines whether this subscriber is authorized to
place this call. DP-o then translates the dialed number into the
DCS Group Category: Informational - Expiration 04/30/03 9
DCS Architecture October 2002
address of a "terminating" DCS-proxy (DP-t) and forwards the INVITE
message to it.
We assume that the originating and terminating DCS-proxies trust
each other. DP-o augments the INVITE message that it forwards with
additional information, such as billing information containing the
account number of the caller. DP-t then translates the dialed number
into the address of the terminating MTA (MTA-t) and forwards the
INVITE message to MTA-t to notify it about the incoming call.
The initial INVITE message may invoke call feature handling at the
terminating MTA, such as call-forwarding. Assuming that the call is
not forwarded, MTA-t negotiates the coding style and bandwidth
requirements for the media streams. A reliable provisional 1xx
response to the initial INVITE is sent back through the DCS-proxies.
DCS Group Category: Informational - Expiration 04/30/03 10
DCS Architecture October 2002
MTA-o ER-o DP-o DP-t ER-t MTA-t
| INVITE | | | | |
|----------|--------->| INVITE | | |
| | |--------->| | |
| | | | INVITE | |
| | | |----------|--------->|
| | | | | 183 SDP |
| | | |<---------|----------|
| | | | | |
| | Gate | 183 SDP |Gate Setup| |
| | Setup |<---------|--------->| |
| |<---------| | | |
| 183 SDP | | | | |
|<---------|----------| | | |
| | | PRACK | | |
|----------|----------|----------|----------|--------->|
| | 200 OK (acknowledging PRACK) | |
|<---------|----------|----------|----------|----------|
| | | | | |
|<---------|--------Reserve Resources-------|--------->|
| | | | | |
| | UPDATE | |
|----------|--------- |----------|----------|--------->|
| 200 OK (acknowledging UPDATE) |
|<---------|----------|----------|----------|----------|
| | | | | 180 Ring |
| | | 180 Ring |<---------|----------|
| | 180 Ring |<---------| | |
|<---------|----------| | | |
| | | PRACK | | |
|----------|----------|----------|----------|--------->|
| | 200 OK (acknowledging PRACK) | |
|<---------|----------|----------|----------|----------|
| | | | | | User
| | | | | 200 OK | Answers
| | | 200 OK |<---------|----------|
| | 200 OK |<---------| | |
|<---------|----------| | | |
| ACK | | | | |
|----------|----------|----------|----------|--------->|
| | | | | |
|<---------|----------Active Call----------|--------->|
| | | | | | User
| | | | | BYE | Hangs Up
|<---------|----------|----------|----------|----------|
| | | | | 200 OK |
|----------|----------|----------|----------|--------->|
Figure 2: A Basic Call Flow, including Resource Management functions
In the figure, MTA-t sends a 183 SDP message to DP-t. The 183 SDP
contains a subset of the capabilities in the INVITE message that are
acceptable to MTA-t. The SDP also carries the QoS preconditions from
DCS Group Category: Informational - Expiration 04/30/03 11
DCS Architecture October 2002
the INVITE. DP-t sends a GATE-SETUP message to the terminating ER
(ER-t), conveying policy instructions allowing ER-t to open a gate
for the IP flow associated with this phone call. The GATE_SETUP
message contains billing information containing the account number
of the subscriber that will pay for the call.
DP-t forwards the 183 SDP to DP-o. DP-o sends a GATE-SETUP message
to the originating ER (ER-o) to indicate that it can open a gate for
the IP flow associated with the phone call. Finally, DP-o forwards
200 OK to MTA-o. The initial INVITE request and 183 SDP response
contain a SIP Contact header to indicate the IP address of the
remote MTA to be used for subsequent end-to-end SIP signaling
exchanges. MTA-o acknowledges the 183 SDP by sending a PRACK [5]
directly to MTA-t.
Once the initial INVITE/183/PRACK exchange has completed, both MTAs
reserve the resources that will be needed for the media streams.
Once MTA-o has successfully made its reservation, it sends an UPDATE
message [7] to MTA-t, which is immediately acknowledged by MTA-t
with a 200-OK. MTA-o uses the UPDATE message to communicate the fact
that the desired pre-conditions necessary for the session as
perceived by MTA-o are satisfied (e.g., successful reservation of
resources, as perceived by MTA-o). MTA-t acknowledges the UPDATE
message with a 200 OK final response directly to MTA-o. However,
resource reservation from MTA-t's perspective may not be completed
yet. Thus, the 200 OK acknowledging the UPDATE message does not
indicate successful resource reservation. Once MTA-t successfully
reserves the resources needed for the call and starts alerting the
called user, it sends a 180 Ringing through the proxies to indicate
that the phone is ringing, and that the calling party should be
given a ringback call progress tone. We have not described, in
detail, the messaging involved in resource reservation here, as we
believe that it is appropriate to allow for a variety of resource
management mechanisms. Thus, the MTA may use the resource management
mechanism that is most suitable to the network segment that it is
attached to. When the called party answers by going off-hook, MTA-t
sends a 200 OK final response through the proxies, which MTA-o
acknowledges with an end-to-end ACK. At this point the resources
that were previously reserved are committed to this conversation,
and the call is "cut through."
Either party can terminate the call. An MTA that detects an on-hook
sends a SIP BYE message to the remote MTA, which is acknowledged.
3. Resource Management
DCS's resource management protocols distinguish between two phases:
a "Reserve" phase and a "Commit" phase. During the Reserve phase,
resources are reserved but are not yet made available to the
endpoint. This ensures that resources are available before ringing
the far-end telephone. The Commit phase, which commits the resources
associated with the flow, is initiated after ringing the far-end
telephone and after the called party picks up. At this point, the
DCS Group Category: Informational - Expiration 04/30/03 12
DCS Architecture October 2002
resources are made available to the endpoint, and usage recording is
started so that the user can be billed for usage. The use of a two-
phase approach is essential because of the unique requirements
associated with human communication, such as telephony. Recognition
of the need for a two phase resource management approach is a
significant motivation for the call flow adopted in the previous
section.
Although we believe that issues of billing ought not to be the
primary consideration in the design of the protocol, the protocol
design should not preclude the possibility of usage sensitive
billing. Therefore, in addition to ensuring that resources are
available before ringing the phone, the two-phase resource
management protocol also allows us to preserve the semantics of
billing that users are accustomed to, whereby usage recording is not
started until the called party picks up the phone. Backbone
resources are reserved and allocated in the first phase of the two-
phase resource reservation protocol. This is important in order to
limit the impact of backbone resource management on post-pickup
delay (this minimizes the likelihood of clipping the first few
syllables of the conversation).
4. Distributed Call State
In order to provide enhanced services to millions of endpoints, we
need an architecture that can be implemented cost-effectively at
very large scale. Just as we enable flexibility by exploiting
intelligence at the endpoints, services can be provided in a
scaleable manner by storing the state associated with applications
at the endpoints, rather than in network servers. Especially with
telephony, endpoints are directly involved in handling calls and
therefore need to maintain and use call state. In contrast, while
network servers may need to be involved when setting up a call to
gain access to enhanced QoS, there is no fundamental need for those
servers to be involved throughout the lifetime of the call.
Maintaining state for every call at network servers, while
achievable, increases the reliability requirements and load on the
servers. The less state kept in the network, the better.
As a result, the DCS-proxies in DCS are designed to be Call
stateless transaction servers. The proxy maintains SIP transaction
state. So, when a DCS-proxy processes a service request from an
endpoint, it maintains state until the transaction is complete, but
does not maintain any per-call state about active calls in the
network. There are two major advantages to this design. First the
reliability of the service does not depend on the reliability of an
individual DCS-proxy. A DCS-proxy can fail without affecting calls
that are currently in progress. Second, it removes many complex
synchronization problems where two (or more) entities need to have
simultaneously accurate information. Since interactions with the
DCS-proxies are simple stateless transactions, it is not necessary
for consecutive calls to be processed by the same DCS-proxy. DCS-
proxy crashes affect only the transient calls (the calls that are in
DCS Group Category: Informational - Expiration 04/30/03 13
DCS Architecture October 2002
the process of being set up), and not stable conversations.
Further, it is likely that most calls in a transient state can be
recovered and successfully established through a backup or spare
DCS-proxy using endpoint retransmission, with no explicit
synchronization protocol required between the DCS-proxies. We
believe this design principle will enable us to operate in very
large scale, cost effectively. Furthermore it places the function of
managing the state of a call where it belongs - at the endpoint. An
existing call can only be affected by failures along the path or by
failure of the endpoints: there are no unnecessary elements involved
in a call.
We note that there are many services that involve the use of servers
or proxy endpoints that communicate directly with clients. Since
these endpoints are directly involved in providing service, it is
necessary and appropriate for them to maintain state. Examples of
proxy endpoints include application layer firewalls, caching
servers, transcoders, network-based conference bridges, interactive
voice response systems, and PSTN gateways. The DCS architecture
models these as end-points, that maintain appropriate call state.
We now turn to the mechanisms that allow us to avoid state in the
DCS-proxies. A number of examples of the need for distributed state
arise in the implementation of telephony features. These give rise
to two types of information that a DCS-proxy may present to an
endpoint that may subsequently be given back to the proxy by the
endpoint. The first type of information is Remote endpoint
identification, contained in the "P-Asserted-Identity" header. The
second type of information is associated with an active session that
an endpoint is participating in. This latter information, stored in
the "State" header[3], is information that a service provider or
proxy may need for methods that are invoked by an endpoint related
to that session. Thus, a DCS-proxy stores the state information
about the calls at an endpoint in two new headers, "State" and "P-
Asserted-Identity". The State header is both encrypted and signed by
the proxy to ensure the privacy and the integrity of the information
contained in the header. The information that may be contained in
State includes resource information (such as Gate information) and
billing information (such as a billing id). The P-Asserted-Identity
is only encrypted when privacy is requested by the endpoint (covered
in detail in the Section 6 below.)
When needed, the endpoint provides the State to the DCS-proxy that
generated it, which can use the information to provide additional
functionality. Because the State header is encrypted and signed by
the DCS-proxy, the information it contains is trusted by the network
even though the endpoint itself is not trusted. In addition, DCS-
proxies store service-specific opaque data associated with a call at
the edge router. Since charging for telephony services may be tied
to the use of resources, this information is best stored at the edge
router, where knowledge of resource usage exists.
DCS Group Category: Informational - Expiration 04/30/03 14
DCS Architecture October 2002
The endpoint returns the state (possibly both State and P-Asserted-
Identity) information to the DCS-proxy when it is needed to
implement specific features. The endpoint cannot interpret the
information in the encrypted and signed State header (and P-
Asserted-Identity if it is also encrypted), and any attempt to
tamper with it can be detected by the DCS-proxy.
An example of use of the State information is one where a change in
coding method in the middle of a call (e.g., upon detection of a fax
tone) may require the proxies to authorize additional resources.
Services such as call-transfer and three-way-calling require the
proxy to be involved in authorizing resources for packet flows to
the new destination(s).
5. DCS Proxy - DCS Proxy Communications
DCS-proxies implement a set of service-specific control functions
required to support the telephony service:
. Authentication and authorization: Since services are only provided
to authorized subscribers, DCS-proxies authenticate signaling
messages and authorize requests for service on a call-by-call
basis.
. Name/number translation and call routing: DCS-proxies translate
dialed E.164 numbers, or names, to a terminating IP address based
on call routing logic to support a wide range of call features.
. Service-specific admission control: DCS-proxies can implement a
broad range of admission control policies for the telephony
service. For example, DCS-proxies may provide precedence for
particular calls (e.g., 911 calls). Admission control may also be
used to implement overload control mechanisms, e.g. to restrict
the number of calls to a particular location or to restrict the
frequency of call setup to avoid signaling overload.
. Signaling and service feature support: While many service features
are implemented by endpoints, the DCS-proxy also plays a role in
feature support. DCS signaling provides a set of service
primitives to end-points that are mediated by the DCS-proxy. The
DCS-proxy is involved in implementing service features that depend
on the privacy of calling information, e.g., caller-ID blocking.
It also plays a role in supporting service features that require
users to receive a consistent view of feature operation even when
an endpoint is down. For example, while an endpoint may normally
participate in call forwarding, the DCS-proxy can control call
forwarding on behalf of an endpoint when the endpoint is
unavailable.
Endpoints MTA-o and MTA-t communicate through the DCS-Proxies DP-o
and DP-t, as shown in Figure 2. The interface of concern in this
section is the one between the DCS-Proxies DP-o and DP-t. In
contrast to a true stateless SIP proxy, the DCS-Proxy maintains
DCS Group Category: Informational - Expiration 04/30/03 15
DCS Architecture October 2002
transaction state. During the interval that a call is being setup, a
DCS-Proxy keeps state related to a request until a response is
received.
For each call made to a phone number, DP-o may need to perform the
functions needed for Local Number Portability (LNP). If a LNP
database lookup is performed and the resulting dialed string is
modified, DP-o must modify the Request-URI to include the result of
the LNP lookup. The originating proxy DP-o generates and stores the
State header. This information is intended to be sent to endpoint
MTA-o and included with the first response that is returned to MTA-
o. The originating DCS-Proxy, DP-o, may then use the call state
information provided to it in the State header to manipulate call-
legs when requested by MTA-o.
As with conventional SIP proxies, DP-o adds its address to the top
of the Via: header list when forwarding the request. In addition, to
support billing functions for a carrier, DP-o appends opaque billing
information in the form of P-DCS-Billing-Info. In addition, to
support the resource management functions (such as manipulating
Gates for resource management in concert with call-leg
manipulation), a P-DCS-Gate: header[2] is included. This allows for
the subsequent generation of requests for access network QoS by the
end-points.
We also depend on originating DCS-Proxy, DP-o to be responsible for
manipulating call legs. For instance, when a call is being
forwarded, information about the new destination that the call is
being forwarded to is provided by DP-t to DP-o. The new INVITE is
then issued from DP-o. The information exchanged between the DCS-
proxies enables such a function to be performed.
6. Privacy
Many conventional telephony systems have the ability to provide
information about the identity of the calling party to the called
party before the latter accepts the call (such a capability is
typically termed "Caller-ID"). Systems that support Caller-ID
usually provide a mechanism that allows the calling party to
instruct the network to refrain from delivering this information to
the destination.
In order for an IP-based network to provide a caller with a similar
capability, a new SIP header is needed to signal the desire for
anonymity to the network elements that would otherwise provide the
caller's identity to the destination party. If a caller desires to
remain anonymous, several additional changes to standard SIP are
necessary.
The triplet {From:, To:, Call-ID:} is used to (at least in RFC 2543-
based implementations) identify a call leg in both endpoints and in
proxies. Because call state information is pushed to the edge of the
DCS Group Category: Informational - Expiration 04/30/03 16
DCS Architecture October 2002
network, this information must be delivered unchanged to the
destination endpoint.
The SIP From: header normally contains information that identifies
the caller. In order to hide the identity of the caller, the From:
header information is provided as anonymous.
Normally, the SIP Call-ID: header also contains information about
the caller. In the DCS architecture, to support privacy the value of
the Call-ID: header is a cryptographic hash string that contains no
information about the user.
Since all the normally available mechanisms for passing information
about the caller are no longer available, a new SIP header, P-
Asserted-Identity[1], is used to pass the caller's identity to the
destination. The P-Asserted-Identity header is primarily used for
endpoint identification. This header contains the information that
would normally be present in the From: header; the network passes it
to the destination endpoint only if the caller has not requested
anonymity. If the caller had requested anonymity, then the P-
Asserted-Identity header contains an encrypted string that can be
used by the proxy in handling further requests.
If the user at an endpoint wants to return the last call (e.g., by
dialing *69 on a traditional telephone) the "call return" function
is invoked. If the user had subscribed to the caller ID service
feature, the terminating endpoint could store the information (phone
number or IP address) associated with the last call. However, it
may be the case that the user does not subscribe to the feature, or
the originator of the previous call may have requested that this
information be blocked in order to retain privacy. In this case,
call return can be implemented, while keeping the caller's identity
private, by using the encrypted P-Asserted-Identity header.
In addition to the usual privacy elements provided by telephone
systems, IP-based systems must implement methods of hiding the
source IP address from the destination if the caller requires
privacy. The entire address must be obscured, since even a few
address bits may provide partial location information. Likewise, IP
addresses of the destination should not be revealed to the caller,
in order to maintain privacy of transfer destinations.
IP addresses typically appear in the Contact: header; they also
appear in SDP descriptions contained in SIP messages. These must all
be protected. We choose to use an application-level anonymizer that
inspects the SIP call signaling messages and replaces any
identifying information contained therein in a consistent manner.
The identifying information is modified such that when the messages
are delivered to the destination endpoint, any identifying
information has been replaced with fields that obscure the identity
of the party seeking privacy.
DCS Group Category: Informational - Expiration 04/30/03 17
DCS Architecture October 2002
This mechanism does not require any modification to the call
signaling initiated by the endpoints: the application-level
anonymizer performs these functions silently within the network.
7. Security Considerations
Building an IP-based system that matches services and matches the
perceived security present in the PSTN is a daunting challenge.
Certain mechanisms that are defined in SIP for end-to-end security,
such as S/MIME, are incompatible with services being offered by the
proxies inside the network. It is therefore necessary to implement
security on a hop-by-hop basis and depend on all the proxies and
trusted User-Agents on the signaling path to properly secure their
links. Billing, accounting, and lawful surveillance information is
particularly sensitive and needs adequate safeguards. It is
therefore REQUIRED that all proxies and trusted User Agents
implement security on a hop-by-hop basis with IPsec or with TLS.
Careful network administration is required to maintain the trust
boundary, and interconnection agreements between service providers
must carefully specify the administration requirements.
Similarly, the links between each MTA and its DCS-Proxy must be
protected with IPsec or with TLS.
See section 6 for a separate discussion of the security
considerations of a caller-id service, and its associated caller-id-
blocking service.
Each of the extensions described in this document are more properly and
formally defined in separate Internet-Drafts and RFCs. Each contains
further security considerations related to their specific extension.
8. Notice Regarding Intellectual Property Rights
The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
9. Informative References
1. Jennings, C., Peterson, J., and Watson, M., Private Extensions to
the Session Initiation Protocol (SIP) for Asserted Identity within
Trusted Networks, RFC3325, November 2002.
2. "SIP proxy-to-proxy extensions for supporting Distributed Call
State", Internet Draft: <draft-dcsgroup-sipping-proxy-proxy-
01.txt>, October 2002.
3. "SIP extensions for supporting Distributed Call State", Internet
Draft: <draft-ietf-sip-state-00.txt>, November 2000.
DCS Group Category: Informational - Expiration 04/30/03 18
DCS Architecture October 2002
4. "Private Session Initiation Protocol (SIP) Extensions for Media
Authorization", RFC3313, February 2003.
5. "Reliability of Provisional Responses in the Session Initiation
Protocol", RFC3262, June, 2002.
6. "SIP: Session Initiation Protocol", RFC3261, June 2002.
7. "Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC3312, October 2002.
10. Acknowledgements
The Distributed Call Signaling work in the PacketCable project is
the work of a large number of people, representing many different
companies. The authors would like to recognize and thank the
following for their assistance: John Wheeler, Motorola; David
Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows,
Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin,
Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks;
Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho,
Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-
Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent
Cable Communications.
Previous versions further acknowledged, as co-authors, several
people for providing the text of this document. They are: K. K.
Ramakrishnan (kk@teraoptic.com), TeraOptic Networks; Ed Miller
(edward.miller@terayon.com), Terayon; Glenn Russell
(G.Russell@Cablelabs.com), CableLabs; Burcak Beser
(burcak@juniper.net), Juniper Networks; Mike Mannette (Michael_
Mannette@3com.com) and Kurt Steinbrenner (Kurt_
Steinbrenner@3com.com), 3Com; Dave Oran (oran@cisco.com), Cisco
Systems; John Pickens (jpickens@com21.com), Com21; Poornima Lalwaney
(poornima.lalwaney@nokia.com), Nokia; Jon Fellows
(jfellows@coppermountain.com), Copper Mountain Networks; and Keith
Kelly (keith@netspeak.com), NetSpeak.
11. Author's Addresses
Bill Marshall
AT&T
Florham Park, NJ 07932
Email: wtm@research.att.com
Matt Osman
CableLabs
Louisville, CO 80027
Email: M.Osman@Cablelabs.com
DCS Group Category: Informational - Expiration 04/30/03 19
DCS Architecture October 2002
Flemming Andreasen
Cisco
Edison, NJ
Email: fandreas@cisco.com
Doc Evans
ARRIS
Boulder, CO 80303
Email: n7dr@arrisi.com
DCS Group Category: Informational - Expiration 04/30/03 20
DCS Architecture October 2002
Full Copyright Statement
"Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns. This document and the information contained herein is
provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
This memo is filed as <draft-dcsgroup-sipping-arch-01.txt>, and
expires June 30, 2003.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
DCS Group Category: Informational - Expiration 04/30/03 21
