On selection of IN parameters for the SPIRITS Protocol
draft-ietf-spirits-in-03

Document Type Expired Internet-Draft (spirits WG)
Author Kumar Vemuri 
Last updated 2005-05-26 (latest revision 2002-07-01)
Stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Expired & archived
pdf htmlized (tools) htmlized bibtex
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state Expired (IESG: Dead)
Action Holders
(None)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Jon Peterson
IESG note Responsible: Working Group
Send notices to <smb@research.att.com>, <abrusilovsky@ieee.org>

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-ietf-spirits-in-03.txt

Abstract

This document describes INAP parameters (IN information and its encoding) which the SPIRITS protocol can transport from the PSTN into the IP network. The SPIRITS protocol is a protocol through which PSTN can request actions (services) to be carried out in the IP network in response to events occurring within the PSTN/IN. These services include, but are not limited to: Incoming Call Notification (Internet Call Waiting), Internet Caller-Id Delivery, and Internet Call Forwarding ('Follow Me'). This draft outlines, what INAP parameters are of immediate interest to SPIRITS, how they may be extracted and encoded for use within the SPIRITS domain. INAP is used as an example protocol to clarify the SPIRITS message encoding process. This Internet-Draft has been written in response to the SPIRITS WG Chairs' call for SPIRITS Protocol proposals. It may be viewed as being a direct contribution to the Informational RFC on the SPIRITS protocol parameters. Among other contributions, this I-D is based on: o Informational RFC2995, 'Pre-SPIRITS implementations' o SPIRITS Architecture, presented in draft-ietf-spirits-architecture-02, RFC 3136 o SPIRITS Protocol Requirements, presented in draft-ietf-spirits-reqs-04, current candidate for Informational RFC.

Authors

Kumar Vemuri (vvkumar@lucent.com)

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