One document matched: draft-dcsgroup-mmusic-state-00.txt
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
June, 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 12/31/99 1
SIP Extensions for Distributed Call State June 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-mmusic-state-00.txt>, and expires December 31, 1999. 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 extensions to the host parameter in the SIP URL
for supporting the following: (a) a call signaling architecture
where call state is distributed to the clients during call setup and
stored there for the duration of the call, (b) support for local
number portability and (c) relaxation of the strong coupling between
the phone number and its gateway in the telephony subscriber URL as
defined in RFC 2543. 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 an MTA - "Multimedia terminal
adapter").
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 in the initial INVITE to the
DCS Group Internet Draft - Expiration 12/31/99 2
SIP Extensions for Distributed Call State June 1999
terminating MTA (called client) and in the 200 OK to the originating
MTA (calling client). The DCS-Proxy in effect, transfers call state
to the 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 addition of a host parameter value of
"private" and a user-param value of "private" to the SIP-URL for
supporting this capability. The presence of user-param = "private"
indicates that the contents of the host field can only be
interpreted by the DCS-Proxy.
The client initiating the call is responsible for "collecting the
digits" that represents the destination telephony URL. The DCS-Proxy
is responsible for resolving the dialed digits to the IP address of
the destination. The client initiating the call may not know of the
gateway associated with the destination. When "user=phone" is
present, we propose that the SIP host URL for the telephony
subscribe permit the use of a valid E.164 number as a URL and relax
the requirement on the need to add the gateway associated with the
number.
Support for local number portability functions requires another
extension to the telephony subscriber URL. We propose the addition
of an "augmented-phone-number" in the definition of the telephony
subscriber URL and the addition of user-param = "lnp-phone" for
supporting local number portability.
The OSPS 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].
DCS Group Internet Draft - Expiration 12/31/99 3
SIP Extensions for Distributed Call State June 1999
4.1 SIP URL Extensions
The SIP URL host syntax is extended to allow hosts to be identified
by a simple phone-number (E.164 number). The SIP client initiating
the call may not know of the gateway associated with the number. The
Telephony subscriber URL definition in RFC 2543 for a telephone
number requires the phone number and its gateway association in the
host parameter. We propose that this constraint be relaxed to allow
hosts to be identified by their E.164 numbers only. If this
interpretation of the hostname is used, the associated user-param
user=phone MUST be present.
Support for local number portability motivates the need for an
"augmented phone number" field in the telephony-subscriber URL. The
augmented phone number would be a number returned by a location
service for local number portability. The user-param field when the
augmented phone number is the lnp-phone number MUST include
user=lnp-phone.
All information about the parties in the call and associated billing
information is encrypted by the DCS-Proxy during call setup and
stored in the clients participating in the call. To invoke features
that involve change in call characteristics that affects the current
call leg or its billing information, the SIP client sends an INVITE
to its proxy that may include an encrypted string as the SIP URL
host field represented as "private" with the associated user-param
being "private". This user-param indicates that the DCS-Proxy
associated with the client is the only entity that can decrypt the
"private" information in the host field. The field is to be
interpreted as an opaque object by the clients.
The representation for the host parameter desired to support the DCS
architecture is shown below:
host = hostname | IPv4address
| telephone-subscriber | private
telephone-subscriber = global-phone-number
| local-phone-number
| augmented-phone-number
augmented-phone-number = 1*( phone-digit | dtmf-digit
| pause-character | "/")
private = alpha *alphanum
The SIP user-param is extended to include "private" and "lnp-phone"
keywords as described below.
user-param = "user=" ( "ip" | "phone"
| "lnp-phone" | "private" )
DCS Group Internet Draft - Expiration 12/31/99 4
SIP Extensions for Distributed Call State June 1999
The user-param "user=ip" is optional in a URL and MAY be included
when the host is identified using hostname or the IPv4address
syntax. Therefore, the URL "sip: John Doe" is equivalent to the URL
"sip:John Doe;user=ip".
When a URL includes the user-param "user=phone", the URL host field
MUST be a phone number and MUST use the telephone-subscriber syntax.
Additionally, when a URL includes the user-parameter "user=phone",
the userinfo field MAY NOT be present.
An example of a valid URL containing the user-param "user=phone" is:
sip:847.555.1212;user=phone
When a URL includes the user-param "user=lnp-phone", the SIP URL
host field MUST use the augmented-phone-number syntax, and contain
the local office code prepended to the phone number with a slash
separator. Additionally, when a URL includes the user-parameter
"user=lnp-phone", the SIP URL userinfo MUST NOT be present.
An example of a URL containing the user-param "user=lnp-phone" is:
sip:212-234/847-555-1212;user=lnp-phone
When a URL includes the user-param "user=private", the SIP URL host
field MUST be a string encrypted using the DCS-Proxy's private key.
Additionally, the encrypted string MUST use private URL syntax.
When a URL includes the user-parameter "user=private", the SIP URL
"userinfo" MUST NOT be present.
4.2 State
The State header conveys encrypted state information from a DCS-
Proxy to a DCS capable client. This state information allows the
DCS-Proxy to securely store state information in the client that may
be needed for subsequent feature invocation, allowing the DCS-Proxy
to remain stateless during the call.
State = "State" ":" private
The keyword "private" is defined in Section 4.1.
The State header is sent to the terminating MTA in the initial SIP
INVITE from its proxy. The State header is sent to the originating
MTA (from its proxy) in the 200 OK response to the initial INVITE.
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
DCS Group Internet Draft - Expiration 12/31/99 5
SIP Extensions for Distributed Call State June 1999
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
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 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 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 user=private, 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 (Multimedia Terminal Adapters) are untrusted entities in
the DCS architecture. The contents of all headers tagged as
"private" are verified by DCS-Proxies. DCS-Proxies are responsible
DCS Group Internet Draft - Expiration 12/31/99 6
SIP Extensions for Distributed Call State June 1999
for verifying the contents and consistency of the headers and
extended URL's discussed in this document.
6. References
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-mmusic-arch-00.txt, June
1999.
3 Schulzrinne, H and Rosenberg, J, SIP Call Control Services,
draft-ietf-mmmusic-sip-cc-00.txt, March 1998, expired August 1,
1998.
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
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 Guckle, Cisco;
and Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, 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 12/31/99 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 Kelley
Netspeak
Boca Raton, FL 33587
DCS Group Internet Draft - Expiration 12/31/99 8
SIP Extensions for Distributed Call State June 1999
Email: keith@netspeak.com
Flemming Andreasen
Telcordia
Piscataway, NJ
Email: fandreas@telcordia.com
DCS Group Internet Draft - Expiration 12/31/99 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-mmmusic-state-
00.txt>, and expires December 31, 1999.
DCS Group Internet Draft - Expiration 12/31/99 10
| PAFTECH AB 2003-2026 | 2026-04-24 02:45:37 |