Session Initiation Protocol (SIP) INFO Method Use
draft-burger-sip-info-02
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Eric Burger | ||
| Last updated | 2007-11-18 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
The purpose of the INFO request for the Session Initiation Protocol (SIP), as described by RFC 2976, is to provide mid-session SIP User Agent (UA)-to-SIP UA application data transport. In the years since the introduction of the INFO request, experience with the use of the INFO request indicates a number of problems. This document explains why there are INFO-based, proprietary protocols in the wild; the flaws of using INFO; and explains why it is not possible to create a framework to rescue INFO for general purpose use. Since SIP has evolved considerably since the introduction of INFO, this document highlights some of the new, robust mechanisms for achieving the work that previously led people to use INFO. As these mechanisms are now available, this document formally deprecates the use of INFO for new usages beyond the existing standardized ones, namely RFC 3372 (SIP-T) and RFC 4497 (QSIG). 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 [1].
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)