3rd Party Call Control
Application Interaction
Interfaces
REFER and Tranfer
draft-ietf-sipping-cc-framework
draft-ietf-sip-callerprefs
draft-ietf-sip-serverfeatures
draft-ietf-sipping-dialog-package
draft-ietf-sipping-mwi
draft-mahy-sip-cc-models
draft-mahy-sipping-message-waiting
draft-mahy-sipping-signaled-digits
draft-mahy-sip-cc-uri-params
draft-ietf-sipping-dialog-package
rfc3087
draft-ietf-sipping-cc-framework-02.txt
 |
"A Call Control and Multi-party usage framework for the Session
Initiation Protocol (SIP)", Rohan Mahy, 07-MAR-03,
This document defines a framework and requirements for multi-party usage of SIP. To enable discussion of multi-party features and applications we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually setup the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state, and session history. This framework also describes other goals which embody the spirit of SIP applications as used on the Internet. |
| draft-ietf-sip-callerprefs-08.txt
|
"Caller Preferences and Callee Capabilities for the Session Initiation
Protocol (SIP)", Jonathan Rosenberg, Henning Schulzrinne, Paul Kyzivat,
07-MAR-03, This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which URIs a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining four new request headers, Accept-Contact, Reject- Contact, Require-Contact and Request-Disposition, which specify the caller's preferences. The extension also defines new parameters for the Contact header that describe the capabilities and characteristics of a UA. |
| draft-ietf-sip-serverfeatures-06.txt
|
| draft-ietf-sipping-dialog-package-01.txt
|
"An INVITE Inititiated Dialog Event Package for the Session Initiation
Protocol (SIP", Jonathan Rosenberg, Henning Schulzrinne, 05-MAR-03,
This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user, an receive notifications about the changes in state of INVITE initiated dialogs that the user is involved in. |
| draft-ietf-sipping-mwi-02.txt
|
"A Message Summary and Message Waiting Indication Event Package for the
Session Initiation Protocol (SIP)", Rohan Mahy, 06-MAR-03,
This draft proposes a SIP event package to carry message waiting status and message summaries from a messaging system to an interested User Agent. |
| draft-mahy-sip-cc-models-02.txt
|
| draft-mahy-sipping-message-waiting-01.txt
|
| draft-mahy-sipping-signaled-digits-02.txt
|
| draft-mahy-sip-cc-uri-params-01.txt
|
| draft-ietf-sipping-dialog-package-01.txt
|
"An INVITE Inititiated Dialog Event Package for the Session Initiation
Protocol (SIP", Jonathan Rosenberg, Henning Schulzrinne, 05-MAR-03,
This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user, an receive notifications about the changes in state of INVITE initiated dialogs that the user is involved in. |
| rfc3087.txt | Control of Service Context using SIP Request-URI |
| Author(s) | B. Campbell, R. Sparks |
| Organization | ietf |
| State | informational |
| Size | 83612 bytes |
| Abstract | This memo provides information for the Internet community. It describes a useful way to conceptualize the use of the standard SIP (Session Initiation Protocol) Request-URI (Uniform Resource Identifier) that the authors and many members of the SIP community think is suitable as a convention. It does not define any new protocol with respect to RFC 2543. In a conventional telephony environment, extended service applications often use call state information, such as calling party, called party, reason for forward, etc, to infer application context. In a SIP/2.0 call, much of this information may be either non- existent or unreliable. This document proposes a mechanism to communicate context information to an application. Under this proposal, a client or proxy can communicate context through the use of a distinctive Request-URI. This document continues with examples of how this mechanism could be used in a voice mail application. |