Session Initiation Protocol (SIP) INFO Method and Package Framework
draft-ietf-sip-info-events-03
| Document | Type |
Replaced Internet-Draft
(sip WG)
Expired & archived
|
|
|---|---|---|---|
| Authors | Eric Burger , Hadriel Kaplan , Christer Holmberg | ||
| Last updated | 2009-07-20 (Latest revision 2009-01-27) | ||
| Replaces | draft-kaplan-sip-info-events | ||
| Replaced by | draft-ietf-sipcore-info-events | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Replaced by draft-ietf-sipcore-info-events | |
| Consensus boilerplate | Unknown | ||
| 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
This document defines the new SIP INFO method and a mechanism for defining, negotiating and exchanging Info Packages that use the INFO method. Applications that need to exchange session-related information within a SIP INVITE-created dialog, also known as application level information, use these INFO requests. This draft addresses issues and open items from RFC 2976 and replaces it. 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 [RFC2119]. The terminology in this document conforms to the Internet Security Glossary [RFC4949]. Be mindful of the terms User Agent Server (UAS) and User Agent Client (UAC). This document strictly follows RFC 3261 [RFC3261]. The UAC issues a SIP request and the UAS responds. This terminology may be confusing when one combines the INFO case with the INVITE case. For an INVITE, the initiator of the session is the UAC and the target of the session is the UAS. However, it is possible for the target UA of the session, the UAS of the INVITE transaction, to send an INFO to the initiating UA of the session, the UAC of the INVITE transaction. From the perspective of the INFO, the target UA of the session (INVITE UAS) is, in fact, the UAC (sender) of the INFO request. Likewise, from the perspective of the INFO, the initiating UA of the session (INVITE UAC) is the UAS (recipient) of the INFO request. Since this document strictly follows RFC 3261, we refer to the UA that issues the INVITE as the "initiating UA" and the UA that responds to the INVITE as the "target UA" to remove any confusion.
Authors
Eric Burger
Hadriel Kaplan
Christer Holmberg
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)