Architectural Considerations for Providing Carrier Class Telephony Services Utilizing Session Initiation Protocol SIP-based Distributed Call Control Mechanisms
draft-dcsgroup-sipping-arch-01

Document Type Expired Internet-Draft (individual in tsv area)
Last updated 2015-10-14 (latest revision 2003-01-16)
Stream IETF
Intended RFC status Informational
Formats
Expired & archived
pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state Expired (IESG: Dead)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Jon Peterson
IESG note After some investigation, it doesn't appear this draft will be revised; setting it to dead.
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-dcsgroup-sipping-arch-01.txt

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 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.

Authors

Matt Osman (M.Osman@Cablelabs.com)
Flemming Andreasen (fandreas@telcordia.com)
David Evans (dae@lcl.cmu.edu)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)