|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | | RFC3725
04/2004
(31 p.)
pdf(p) | J. Rosenberg
J. Peterson
H. Schulzrinne
G. Camarillo | SIPPING |
| Best Current Practices for Third Party Call Control (3pcc) in SIP | | Third party call control refers to the ability of one entity to create a call in which communication is actually between other parties. Third party call control is possible using the mechanisms specified within SIP. However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of SIP for third party call control. |
|
|
| | | Up | Status: | Best Current Practice (BCP: 85) | |
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard -- obsoletes: RFC 2916 | |
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| | | | RFC3824
06/2004
(16 p.)
pdf(p) | J. Peterson
H. Liu
J. Yu
B. Campbell | SIPPING |
| Using E.164 numbers with SIP | | There are a number of contexts in which telephone numbers are employed by SIP applications, many of which can be addressed by ENUM. Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations. This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications. It also provides guidelines for instances in which ENUM, for whatever reason, cannot be used to resolve a telephone number. |
|
|
|
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3840
08/2004
(36 p.)
pdf(v)
pdf(p) | J. Rosenberg
H. Schulzrinne
P. Kyzivat | SIP |
| Indicating User Agent Capabilities in SIP | This specification defines mechanisms by which a SIP user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the "Contact " header field.
This document defines the 'pref ' SIP option tag.
This specification serves to create the "SIP Media Feature Tag Registration Tree (1.3.6.1.8.4) " with the "sip. " prefix (see: http://www.iana.org/ assignments/media-feature-tags ) and it registers a number of new Media feature tags:
| sip.audio (1) | sip.application (2) | sip.data (3) | | sip.control (4) | sip.video (5) | sip.text (6) | | sip.automata (7) | sip.class (8) | sip.duplex (9) | | sip.mobility (10) | sip.description (11) | sip.events (12) | | sip.priority (13) | sip.methods (14) | sip.extensions (15) | | sip.schemes (16) | sip.actor (17) | sip.isfocus (18) |
|
|
|
|
|
|
|
|
| | | | RFC3841
08/2004
(26 p.)
pdf(v)
pdf(p) | J. Rosenberg
H. Schulzrinne
P. Kyzivat | SIP |
| Caller Preferences for SIP | | This document describes a set of extensions to SIP which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which Uniform Resource Identifiers (URI) a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request header fields, "Accept-Contact ", "Reject-Contact ", and "Request-Disposition ", which specify the caller's preferences. |
|
|
|
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard -- updates: RFC3261 | |
|
|
|
|
| | | | RFC3856
08/2004
(27 p.)
pdf(p) | J. Rosenberg | SIMPLE |
| A Presence Event Package for SIP | | This document describes the usage of SIP for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining the 'presence ' event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence Profile (CPP) framework. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3857
08/2004
(20 p.)
pdf(p) | J. Rosenberg | SIMPLE |
| A Watcher Information Event Template-Package for SIP | | This document defines the 'winfo ' template-package for SIP event framework. Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. This event package is a template-package because it can be applied to any event package, including itself. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3858
08/2004
(13 p.)
pdf(p) | J. Rosenberg | SIMPLE |
| An XML Based Format for Watcher Information | Watchers are defined as entities that request (i.e., subscribe to) information about a resource. There is fairly complex state associated with these subscriptions. The union of the state for all subscriptions to a particular resource is called the watcher information for that resource. This state is dynamic, changing as subscribers come and go. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular resource. In order to enable this, a format is needed to describe the state of watchers on a resource. This specification describes an Extensible Markup Language (XML) document format for such state.
This document registers a new MIME type, application/watcherinfo+xml . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3859
08/2004
(15 p.)
pdf(p) | J. Peterson | IMPP |
| Common Profile for Presence (CPP) | | At the time this document was written, numerous presence protocols were in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for presence to facilitate the creation of gateways between presence services. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3860
08/2004
(13 p.)
pdf(p) | J. Peterson | IMPP |
| Common Profile for Instant Messaging (CPIM) | | At the time this document was written, numerous instant messaging protocols were in use, and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3861
08/2004
(8 p.)
pdf(p) | J. Peterson | IMPP |
| Address Resolution for Instant Messaging and Presence | | Presence and instant messaging are defined in RFC 2778 . The Common Profiles for Presence and Instant Messaging define two Universal Resource Identifier (URI) schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3862
08/2004
(30 p.)
pdf(p) | G. Klyne
D. Atkins | IMPP |
| CPIM: Message Format | | This memo defines the MIME content type 'Message/CPIM', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3863
08/2004
(28 p.)
pdf(p) | H. Sugano
S. Fujimoto
G. Klyne
A. Bateman
W. Carr
J. Peterson | IMPP |
| Presence Information Data Format (PIDF) | | This memo specifies the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant Presence protocols, and also defines a new media type "application/ pidf+xml" to represent the XML MIME entity for PIDF. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3880
10/2004
(74 p.)
pdf(p) | J. Lennox
X. Wu
H. Schulzrinne | IPTEL |
| Call Processing Language (CPL): A Language for User Control of Internet Telephony Services | This document defines the Call Processing Language (CPL), a language to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agents. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs.
This document registers a new MIME type, application/cpl+xml . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3890
09/2004
(22 p.)
pdf(p) | M. Westerlund | MMUSIC |
| A Transport Independent Bandwidth Modifier for SDP | This document defines an SDP Transport Independent Application Specific Maximum (TIAS) bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used.
The existing SDP bandwidth modifiers and their values include the bandwidth needed for the transport and IP layers. When using SDP with protocols like the Session Announcement Protocol (SAP), SIP, and the Real-Time Streaming Protocol (RTSP), and when the involved hosts has different transport overhead, for example due to different IP versions, the interpretation of what lower layer bandwidths are included is not clear. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3891
09/2004
(16 p.)
pdf(p) | R. Mahy
B. Biggs
R. Dean | SIP |
| The SIP Replaces Header | This document defines a new header for use with SIP multi-party applications and call control. The "Replaces " header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Attended Transfer" and "Call Pickup". Note that the definition of these example features is non-normative.
This document defines the 'replaces ' SIP option tag. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3892
09/2004
(25 p.)
pdf(p) | R. Sparks | SIP |
| The SIP Referred-By Mechanism | The SIP REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI (the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present.
This document defines the "Referred-By " header field. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3893
09/2004
(13 p.)
pdf(p) | J. Peterson | SIP |
| SIP Authenticated Identity Body (AIB) Format | | RFC 3261 introduces the concept of adding an S/MIME body to a SIP request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message, or message fragment. A standard format for such bodies (known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
|
|
| |
|
|
|
|
|
|
| | | | RFC3903
10/2004
(32 p.)
pdf(v)
pdf(p) | A. Niemi | SIP |
| SIP Extension for Event State Publication | This document describes an extension to SIP for publishing event state used within the SIP Events framework. It defines the "PUBLISH " method. The first application of this extension is for the publication of presence information. The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose.
This document defines the "SIP-ETag " and "SIP-If-Match " header fields. |
|
|
|
|
|
|
|
| | | | RFC3910
10/2004
(50 p.)
pdf(p) | V. Gurbani
A. Brusilovsky
I. Faynberg
J. Gato
H. Lu
M. Unmehopa | SPIRITS |
| The SPIRITS (Services in PSTN requesting Internet Services) Protocol | This document describes the Services in PSTN (Public Switched Telephone Network) requesting Internet Services (SPIRITS) protocol. The purpose of the SPIRITS protocol is to support services that originate in the cellular or wireline PSTN and necessitate interactions between the PSTN and the Internet. On the PSTN side, the SPIRITS services are most often initiated from the Intelligent Network (IN) entities. Internet Call Waiting and Internet Caller-ID Delivery are examples of SPIRITS services, as are location-based services on the cellular network. The protocol defines the building blocks from which many other services can be built.
This document defines the 'spirits-INDPs ' and 'spirits-user-prof ' SIP event packages. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3911
10/2004
(17 p.)
pdf(p) | R. Mahy
D. Petrie | SIP |
| The SIP "Join" Header | This document defines a new header for use with SIP multi-party applications and call control. The "Join " header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Barge-In", answering-machine-style "Message Screening" and "Call Center Monitoring". Note that definition of these example features is non-normative.
This document defines the 'join ' SIP option tag. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3959
12/2004
(11 p.)
pdf(p) | G. Camarillo | SIPPING |
| The Early Session Disposition Type for SIP | This document defines a new disposition type (early-session) for the Content-Disposition header field in SIP. The treatment of "early-session" bodies is similar to the treatment of "session" bodies. That is, they follow the offer/answer model. Their only difference is that session descriptions whose disposition type is "early-session" are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs.
This document defines the 'early-session ' SIP option tag. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3960
12/2004
(13 p.)
pdf(p) | G. Camarillo
H. Schulzrinne | SIPPING |
| Early Media and Ringing Tone Generation in SIP | | This document describes how to manage early media in SIP using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | | RFC3968
12/2004
(8 p.)
pdf(p) | G. Camarillo | SIP |
| The IANA Header Field Parameter Registry for SIP | | This document creates an Internet Assigned Number Authority (IANA) registry for SIP header field parameters and parameter values. It also lists the already existing parameters and parameter values to be used as the initial entries for this registry. |
|
|
| | | Up | Status: | Best Current Practice (BCP: 98) -- updates: RFC 3427 | |
|
|
|
|
| | | | RFC3969
12/2004
(6 p.)
pdf(p) | G. Camarillo | SIP |
| The IANA URI Parameter Registry for SIP | This document creates an Internet Assigned Number Authority (IANA) registry for SIP and SIPS Uniform Resource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry.
This sub-registry is defined under http://www.iana.org/assignments/ sip-parameters , and is labeled "SIP/SIPS URI Parameters ".
The initial parameters defined in this sub-registry are: "lr ", "maddr ", "method ", "transport ", "ttl ", "user ", defined in RFC 3261 , as well as "comp ", defined in RFC 3486 . |
|
|
| | | Up | Status: | Best Current Practice (BCP: 99) -- updates: RFC 3427 | |
|
|
|
|
| | | | RFC3976
01/2005
(25 p.)
pdf(p) | V. K. Gurbani
F. Haerens
V. Rastogi | - |
| Interworking SIP and Intelligent Network (IN) Applications | | Public Switched Telephone Network (PSTN) services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This document addresses means to support existing IN services from Session Initiation Protocol (SIP) endpoints for an IP-host-to-phone call. The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in the PSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this document describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP). |
|
|
|
|
|
|
|
| | | | RFC3986
12/2004
(61 p.)
pdf(v)
pdf(p) | T. Berners-Lee
R. Fielding
L. Masinter | - |
| URI Generic Syntax | | A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. |
|
|
|
|
|
|
|
| | | | RFC3987
12/2004
(46 p.)
pdf(p) | M. Duerst
M. Suignard | - |
| Internationalized Resource Identifiers (IRIs) | This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement to the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources.
The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC3994
01/2005
(13 p.)
pdf(p) | H. Schulzrinne | SIMPLE |
| Indication of Message Composition for Instant Messaging | In instant messaging (IM) systems, it is useful to know during an IM conversation whether the other party is composing a message; e.g., typing or recording an audio message. This document defines a new status message content type and XML namespace that conveys information about a message being composed. The status message can indicate the composition of a message of any type, including text, voice, or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves.
This document registers a new MIME type, application/im-iscomposing+xml . |
|
|
| | | Up | Status: | Proposed Standard |
|
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
