One document matched: draft-dcsgroup-sip-state-00.txt
SIP Working Group W. Marshall
Internet Draft K. Ramakrishnan
Document: <draft-dcsgroup-sip-state-00.txt> AT&T
Category: Informational
E. Miller
G. Russell
CableLabs
B. Beser
M. Mannette
K. Steinbrenner
3Com
D. Oran
Cisco
J. Pickens
Com21
P. Lalwaney
J. Fellows
General Instrument
D. Evans
Lucent Cable
K. Kelly
NetSpeak
F. Andreasen
Telcordia
October, 1999
SIP Extensions for supporting Distributed Call State
Status of this Memo
This document is an Internet-Draft and is NOT offered in accordance
with Section 10 of RFC2026[1], and the author does not provide the
IETF with any rights other than to publish as an Internet-Draft.
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."
DCS Group Internet Draft - Expiration 04/30/00 1
SIP Extensions for Distributed Call State October 1999
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.
The distribution of this memo is unlimited. It is filed as <draft-
dcsgroup-sip-state-01.txt>, and expires April 30, 2000. Please send
comments to the authors.
1. Abstract
This document describes extensions to the Session Initiation
Protocol RFC(2543) for supporting telephony services using the
Distributed Call Signaling architecture described in [2]. This
document discusses the semantics associated with the user parameter
in the SIP URL for supporting a call signaling architecture where
call state is distributed to the clients during call setup and
stored there for the duration of the call while the proxy server
remains stateless. Additional headers in SIP messages for passing
call state information between the clients and their proxies, and
support for PSTN-based operator services are also discussed in this
document. In addition, the need for the Also and Replaces headers
(previously discussed in [3]) are mentioned here.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [4].
3. Introduction
The Distributed call signaling (DCS) architecture provides signaling
support for creating a session using a two-phase signaling scheme so
that call state is distributed to the clients and network resources
reserved prior to alerting the called party. The SIP proxy server in
the DCS architecture is referred to as a DCS-Proxy. The SIP user
agent is referred to as a client or endpoint.
From a call signaling perspective, the DCS Proxies are involved in
setting up a call. All requests from clients that affect the
characteristic of a call are sent to the DCS-Proxy. During a
successful call setup, call state and the associated billing
information is encrypted by the proxies and sent to the clients
using the proposed "State" header. This is sent in the initial
INVITE to the "called" client (and in the 200 OK to the "calling"
client/caller. The DCS-Proxy in effect, transfers call state to the
DCS Group Internet Draft - Expiration 04/30/00 2
SIP Extensions for Distributed Call State October 1999
clients and other network entities during the call-setup phase and
then remains stateless for the duration of the call.
If the client wishes to change call characteristics (e.g. invoke
calling features like forwarding, call transfer etc.), it passes the
encrypted state information in the SIP INVITE request to its proxy
server. We propose the use of the "private=" token in the user field
of the SIP URL to indicates that "token" can only be interpreted by
the DCS-Proxy. The semantics of the telephony subscriber URL and
associated user-param values to support number identification and
portability are discussed in Section 4.1.
The OSPS (Operator Services Provisioning System) header is proposed
for supporting PSTN based operator services of "Busy-Line-Verify"
and "Emergency Interrupt". The response of the client (in an active
call) to a SIP INVITE that includes this header is not to return
busy to the PSTN media gateway (and thereby the operator) that
initiated this request.
The Distributed Call Signaling Architecture uses the Also and
Replaces headers for implementing call transfers. The addition of
parties referenced in the Also header and the removal of parties
referenced in the Replaces header are used for implementing services
that require the addition and removal of call-legs to an existing
call.
4. SIP Extensions
In this section, we propose the SIP extensions to address the issues
identified in the Introduction.
The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in RFC-2234 [5].
4.1 SIP URL Extensions
The distributed call signaling protocol defines the semantics of the
user field of the SIP-URL and refers to such as a DCS-URL.
These URLs MUST be in accordance with SIP version 2 section 2,
Figure 2 of RFC-2543.
The DCS protocol defines the SIP-URL 'user' syntax to allow
endpoints to be identified by an encrypted string that may be
decrypted only by the DCS proxy. This allows end-point address
information and billing information to be encrypted, stored in
client devices, then later delivered to a trusted DCS proxy in
support of CLASS features such as 3-way-calling, call-trace and
return-call. Additionally, the DCS protocol defines the SIP-URL
DCS Group Internet Draft - Expiration 04/30/00 3
SIP Extensions for Distributed Call State October 1999
'user' syntax to allow endpoints to be identified by phone numbers
augmented with additional parameters. This allows DCS proxies to
support local number portability (LNP) location services. The user
syntax for a DCS-URL in BNF is shown below.
User = telephone-subscriber *("," dcs-user-param)
| dcs-user-param *("," dcs-user-param)
| *(unreserved | escaped | "&" | "=" | "+" | "$" | ",")
telephone-subscriber = global-phone-number
| local-phone-number
| special-service-name
dcs-user-param = lnp-param | private-param
| other-param
lnp-param = "lnp=" token
private-param = "private=" token
special-service-name = "return-call" | "call-trace"
|"bridge"
A standard SIP parser will accept this definition as a valid
username.
The user-param "user=ip" is optional and may be included when the
destination is identified using hostname or IPv4address syntax.
Therefore, the DCS-URL "sip: John Doe" is equivalent to DCS-URL
"sip:John Doe;user=ip".
When a DCS-URL includes the user-param "user=phone", the user field
MUST contain an ITU recommendation E.164 phone number and MUST use
DCS-URL telephone-subscriber syntax. An example of a valid DCS-URL
containing the user-param "user=phone" is:
sip:212.555.1212@dcs-proxy.provider;user=phone
When a DCS-URL includes the lnp-param, the user field MUST contain
an ITU recommendation E.164 phone number, and user-param MUST
include user=phone. An example of a DCS-URL containing the lnp-
param is:
sip:212-555-1212,lnp=212-234@dcsproxy.provider;user=phone
When a DCS-URL includes the private-param, the token in the private-
param MUST be a string encrypted by the DCS Proxy using its private
key. An example of a DCS-URL containing the private-param is:
sip: return-call,private=x419d2b70a3@dcsproxy.provider
DCS Group Internet Draft - Expiration 04/30/00 4
SIP Extensions for Distributed Call State October 1999
4.2 State
The State extension conveys encrypted state information between a
Proxy and a client. This state information allows the Proxy to
reliably and securely store state information in the client that may
be needed for subsequent feature invocation, allowing the Proxy to
remain stateless.
State = "State" ":" token
The State field is an alphanumeric (starting with alphabetic only)
string that is syntactically identical to a token. It is an
encoding of an encrypted structure containing multiple pieces of
information needed by the proxy to perform various mid-call
features. The encrypted structure is returned from the client to
the Proxy for various call services, such as return-call, call-
trace, call-forwarding-no-answer, etc.
The State field typically includes but is not limited to the
following information: the calling and called party address
information, the indication of privacy requested, optional billing
information, sequence of via's and calling party id, for support of
call-trace and return-call. This information is encrypted and signed
by the proxy.
The State header field discussed in this section should not be
confused with HTTP1.1 Cookies as described in [6]. The intended use
of the two is very different. HTTP uses the Cookie for "state"
management, or as a handle to pass session context change from
server to client where the server is the other endpoint of the
session. On the otherhand, the State header is sent by the SIP proxy
to the client so that call state can be securely stored at the
endpoint making the associated proxy "stateless" during the call.
The state header can be considered to be a handle to request session
change by the endpoint from its proxy. In addition, there are no
attribute value pairs associated with the state header as in the
Cookie that clients make use of.
4.3 OSPS
Operator services support for Busy line verification (BLV) and
Emergency interrupt(EI) services initiated by an operator on the
PSTN network motivates the need for the OSPS header. This header is
intended to be used in SIP INVITE messages from the PSTN gateway to
the client being queried or interrupted. The tag values permitted in
this header are "BLV" for busy line verification and "EI" for
emergency interrupt.
OSPS = "OSPS" ":" OSPS-Tag
DCS Group Internet Draft - Expiration 04/30/00 5
SIP Extensions for Distributed Call State October 1999
OSPS-Tag = "BLV" | "EI"
The response of the client to an INVITE with this header is not to
return busy.
4.4 Also
The Also header is required for adding new participants to an
existing call. Its functionality is described in the SIP Call
Control Services draft [3]. It is discussed here for completeness
and is required to realize many services in the DCS architecture.
The Also header advises the recipient to issue INVITE requests to
the addresses listed in the header.
Also = "Also" ":" SIP-URL *[ "," SIP-URL]
The URL extensions discussed in Section 4.1 are permitted in the
Also header. If a client receives an INVITE with an Also header that
includes a URL tagged with private=<string>, it SHOULD send the
INVITE for the new call-leg to its DCS-Proxy with the Request-URI
copied from the Also header of the received INVITE request.
4.5 Replaces
The Replaces header is required for removing participants from an
existing call. Its functionality was originally described in the
expired SIP Call Control Services draft [3]. It is discussed here
for completeness and is required to realize many services in the DCS
architecture.
The Replaces extension asks the recipient to issue a BYE to the
addresses listed.
Replaces = "Replaces" ":" SIP-URL *[ "," SIP-URL]
As with the Also header, the URL extensions discussed in Section 4.1
are permitted in the Replaces header.
5. Security Considerations
The clients are untrusted entities in the DCS architecture. The
contents of all headers tagged as "private" are verified by DCS-
Proxies. DCS-Proxies are responsible for verifying the contents and
consistency of the headers and extended URL's discussed in this
document.
6. References
DCS Group Internet Draft - Expiration 04/30/00 6
SIP Extensions for Distributed Call State October 1999
1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 DCS Group, "Architectural Considerations for Providing Carrier
Class Telephony Services Utilizing SIP-based Distributed Call
Control Mechanisms", draft-dcsgroup-sip-arch-01.txt, October
1999.
3 Schulzrinne, H and Rosenberg, J, SIP Call Control Services,
draft-ietf-mmusic-sip-cc-01.txt, June 1999, expires December
1999.
4 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
5 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997
6 K r i s t ol, D. and Montulli, L. ," HTTP State Management
Mechanism", RFC 2109, February 1997.See current working draft
<draft-ietf-http-state-man-mec-12.txt > modified by the same
authors based on field implementation feedback.
7. Acknowledgments
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, General Instruments; Doug
Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay
Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael
Ramalho, Cisco; and Chuck Kalmanek, Doug Nortz, John Lawser, James
Cheng, Tung-Hai Hsiao, and Partho Mishra, AT&T.
8. Author's Addresses
Bill Marshall
AT&T
Florham Park, NJ 07932
Email: wtm@research.att.com
K. K. Ramakrishnan
AT&T
Florham Park, NJ 07932
Email: kkrama@research.att.com
DCS Group Internet Draft - Expiration 04/30/00 7
SIP Extensions for Distributed Call State June 1999
Ed Miller
CableLabs
Louisville, CO 80027
Email: E.Miller@Cablelabs.com
Glenn Russell
CableLabs
Louisville, CO 80027
Email: G.Russell@Cablelabs.com
Burcak Beser
3Com
Rolling Meadows, IL 60008
Email: Burcak_Beser@3com.com
Mike Mannette
3Com
Rolling Meadows, IL 60008
Email: Michael_Mannette@3com.com
Kurt Steinbrenner
3Com
Rolling Meadows, IL 60008
Email: Kurt_Steinbrenner@3com.com
Dave Oran
Cisco
Acton, MA 01720
Email: oran@cisco.com
John Pickens
Com21
San Jose, CA
Email: jpickens@com21.com
Poornima Lalwaney
General Instrument
San Diego, CA 92121
Email: plalwaney@gi.com
Jon Fellows
General Instrument
San Diego, CA 92121
Email: jfellows@gi.com
Doc Evans
Lucent Cable Communications
Westminster, CO 30120
Email: n7dr@lucent.com
Keith Kelly
NetSpeak
DCS Group Internet Draft - Expiration 04/30/00 8
SIP Extensions for Distributed Call State June 1999
Boca Raton, FL 33587
Email: keith@netspeak.com
Flemming Andreasen
Telcordia
Piscataway, NJ
Email: fandreas@telcordia.com
DCS Group Internet Draft - Expiration 04/30/00 9
SIP Extensions for Distributed Call State June 1999
Full Copyright Statement
"Copyright (C) The Internet Society (date). 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 implmentation 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."
Expiration Date This memo is filed as <draft-dcsgroup-sip-state-
01.txt>, and expires April 30, 2000.
DCS Group Internet Draft - Expiration 04/30/00 10
| PAFTECH AB 2003-2026 | 2026-04-24 01:11:15 |