Home eBook Buy SIPKnowledge Hall Of Fame (Top 1%) FAQ About Contact
iLearn iCertify iLAB 3GPP IMS Specifications SIP RFCs IMS? SIP? DEMO
SIP Feature/Topic Of The Month SIP Glossary VoIP Glossary (3GPP) IMS Glossary
Test Your SIP Knowledge Test Your IMS Knowledge Test Your VoIP Knowledge SIP Books "The" SIP RFC (3261) - Annotated

 

 

 

SIP IETF RFCs/WGs - Last update: Dec 26 2009 (the content of this page is updated once every four months)

 

 
 
 

SIP RFCs organized by IETF Work Group (WG)

 

Conferencing

 

bullet

The XCON WG - Centralized Conferencing - Goto XCON IETF page

 

Data for Reachability/Routing

 

bullet

The DRINKS WG - Data for Reachability of Inter/tra-NetworK SIP - Goto DRINKS IETF page
 

Features interop

 

bullet

The BLISS WG - Basic Level of Interoperability for SIP Services - Goto BLISS IETF page

 

Instant Messaging and Presence and Voice Messaging

 
bullet

The IMPP WG - Instant Messaging and Presence Protocol - (OLD - WG activity has concluded!)

bullet

The SIMPLE WG - SIP for Instant Messaging and Presence Leveraging Extensions - Goto SIMPLE IETF page

bullet

The XMPP WG - open, XML-based protocol for near real-time extensible messaging and presence - (OLD - WG activity has concluded!)

bullet

The VPIM WG - Voice Profile for Internet Mail - (OLD - WG activity has concluded!)

 

IP Telephony (VoIP and beyond)

 

bullet

The AVT WG - Audio/Video Transport (RTP) - Goto AVT IETF page

bullet

The IPTEL WG - IP Telephony (CPL, GW location, TRIP) - Goto IPTEL IETF page (WG activity has concluded!)

bullet

The mmusic WG – Multiparty Multimedia Session Control (SIP, SDP, conferencing) - Goto MMUSIC IETF page

bullet

The SIP WG - signaling for call setup - (WG activity has concluded!)

bullet

The SIPPING WG - Session Initiation Proposal Investigation - (WG activity has concluded!)

 

Interop with Circuit domain

 
bullet

The ENUM WG - Telephone Number Mapping - Goto ENUM IETF page

bullet

The megaco WG – Media Gateway Control (IP telephony gateways) - (OLD - WG activity has concluded!)

bullet

The pint WG – PSTN and Internet Internetworking (mixed services) - (OLD - WG activity has concluded!)

bullet

The sigtran WG – Signaling Transport (PSTN signaling over IP) - (OLD - WG activity has concluded!)

bullet

The SPIRITS WG - Service in the PSTN/IN Requesting InTernet Service - (OLD - WG activity has concluded!)

 

Media Control

 

bullet

The MEDIACTRL WG - Media Server Control - Goto MEDIACTRL IETF page

bullet

The speechsc WG - Speech Services Control - Goto SPEECHSC IETF page
 

Misc. (Location Based Services, Compression, Interaction with Firewalls/NATs)

 
bullet

The GEOPRIV WG - Geographic Location/Privacy - Goto GEOPRIV IETF page

bullet

The rohc WG - Robust Header Compression (SigComp) - Goto ROHC IETF page

bullet

The MIDCOM WG - Middlebox Communication (NAT, IPV4-IPV6) - (OLD - WG activity has concluded!)

bullet

The BEHAVE WG - Behavior Engineering for Hindrance Avoidance - Goto BEHAVE IETF page

 

QoS

 
bullet

The diffserv WG – Differentiated Services (QoS in backbone) - (OLD - WG activity has concluded!)

bullet

The Intserv WG - Integrated Services (end-to-end QoS) - (OLD - WG activity has concluded!)

bullet

The MPLS WG - Multiprotocol Label Switching - Goto MPLS IETF page

bullet

The rsvp WG - Resource Reservation Setup Protocol - (OLD - WG activity has concluded!)

 

Peer-to-Peer paradigm for SIP

 

bullet

The P2PSIP WG - Peer-to-Peer Session Initiation Protocol - Goto P2PSIP IETF page

bullet

The SPEERMINT WG - Session PEERing for Multimedia INTerconnect - Goto SPEERMINT page

 

Security and Emergency Calls (911)

 

bullet

The MSEC WG - Multicast Security - Goto MSEC IETF page

bullet

The ECRIT WG - Emergency Context Resolution with Internet Technologies (E911) - Goto ECRIT IETF page

 

 

SIP RFCs table(s) 

ALL RFCs created by The SIP Working Group
RFC#  Name Description (abstract)
2976 The SIP INFO Method 

This RFC proposes an extension to the Session Initiation Protocol (SIP). This extension adds the INFO method to the SIP protocol. The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. One example of such session control information is ISUP and ISDN signaling messages used to control telephony call services.

3204 (updated by RFC 3459) MIME media types for ISUP and QSIG Objects 

This RFC describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048. These types can be used to identify ISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to the PSTN.

3261 (obsoletes RFC 2543/ updated by RFC 3853,RFC 4320) SIP: Session Initiation Protocol

This RFC describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols.

3262 (obsoletes RFC 2543) Reliability of Provisional Responses in SIP

This RFC specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method.

3263 (obsoletes RFC 2543) SIP: Locating SIP Servers

The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This RFC describes those DNS procedures in detail.

3265 (obsoletes RFC 2543) SIP-Specific Event Notification

This RFC describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred.

3310 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)

This RFC specifies an Authentication and Key Agreement (AKA) based one-time password generation mechanism for Hypertext Transfer Protocol (HTTP) Digest access authentication. The HTTP Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The AKA mechanism performs user authentication and session key distribution in Universal Mobile Telecommunications System (UMTS) networks. AKA is a challenge- response based mechanism that uses symmetric cryptography.

3311 The Session Initiation Protocol UPDATE Method

This RFC defines the new UPDATE method for the Session Initiation Protocol (SIP). UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. In that sense it is like a re-INVITE, but unlike re-INVITE, it can be sent before the initial INVITE has been completed. This makes it very useful for updating session parameters within early dialogs.

3312 (updated by RFC 4032) Integration of Resource Management and SIP

This RFC defines a generic framework for preconditions, which are extensible through IANA registration. This RFC also discusses how network quality of service can be made a precondition for establishment of sessions initiated by the Session Initiation Protocol (SIP). These preconditions require that the participant reserve network resources before continuing with the session. We do not define new quality of service reservation mechanisms; these preconditions simply require a participant to use existing resource reservation mechanisms before beginning the session.

3313 Private Session Initiation Protocol (SIP)Extensions for Media Authorization

This RFC describes the need for Quality of Service (QoS) and media authorization and defines a Session Initiation Protocol (SIP) extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS, belong to that administrative domain or federation of domains.

3319 Dynamic Host Configuration Protocol (DHCPv6)Options for Session Initiation Protocol (SIP) Servers

This RFC defines a Dynamic Host Configuration Protocol version 6 (DHCPv6) option that contains a list of domain names or IPv6 addresses that can be mapped to one or more Session Initiation Protocol (SIP) outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server.

3323 A Privacy Mechanism for the Session Initiation Protocol (SIP)

This RFC defines new mechanisms for the Session Initiation Protocol (SIP) in support of privacy. Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A new "privacy service" logical role for intermediaries is defined to answer some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service.

3325 Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks

This RFC describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the identity of authenticated users, and the application of existing privacy mechanisms to the identity problem. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This RFC does NOT offer a general privacy or identity model suitable for use between different trust domains, or use in the Internet at large.

3326 The Reason Header Field for the Session Initiation Protocol (SIP)

For creating services, it is often useful to know why a Session Initiation Protocol (SIP) request was issued. This RFC defines a header field, Reason, that provides this information. The Reason header field is also intended to be used to encapsulate a final status code in a provisional response. This functionality is needed to resolve the "Heterogeneous Error Response Forking Problem", or HERFP.

3327 Session Initiation Protocol Extension for Registering Non-Adjacent Contacts

The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: <sip:alice@pc33.atlanta.com> and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This RFC defines an extension header field, "Path" which provides such a mechanism.

3329 Security Mechanism Agreement for the Session Initiation Protocol (SIP) Sessions

This RFC defines new functionality for negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity. This new functionality supplements the existing methods of choosing security mechanisms between SIP entities.

3361 DHCP Option for SIP Servers

This RFC defines a Dynamic Host Configuration Protocol (DHCP-for-IPv4) option that contains a list of domain names or IPv4 addresses that can be mapped to one or more Session Initiation Protocol (SIP) outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server.

3420 Internet Media Type message/sipfrag

This RFC registers the message/sipfrag Multipurpose Internet Mail Extensions (MIME) media type. This type is similar to message/sip, but allows certain subsets of well formed Session Initiation Protocol (SIP) messages to be represented instead of requiring a complete SIP message. In addition to end-to-end security uses, message/sipfrag is used with the REFER method to convey information about the status of a referenced request.

3428 Session Initiation Protocol Extension for Instant Messaging

Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. This RFC proposes the MESSAGE method, an extension to the Session Initiation Protocol (SIP) that allows the transfer of Instant Messages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request.

3486 Compressing the Session Initiation Protocol

This RFC describes a mechanism to signal that compression is desired for one or more Session Initiation Protocol (SIP) messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity.

3515 The Session Initiation Protocol (SIP) Refer Method

This RFC defines the REFER method. This Session Initiation Protocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer. In addition to the REFER method, this RFC defines the the refer event package and the Refer-To request header.

3581 An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing

The Session Initiation Protocol (SIP) operates over UDP and TCP, among others. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port from which the request originated.

3608 Session Initiation Protocol Extension Header Field for Service Route Discovery During Registration

This RFC defines a Session Initiation Protocol (SIP) extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering user agent (UA) of a service route that the UA may use to request outbound services from the registrar's domain.

3840 Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)

This specification defines mechanisms by which a Session Initiation Protocol (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.

3841 Caller Preferences for the Session Initiation Protocol (SIP)

This RFC 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 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.

3853 (updates RFC 3261)

S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)

RFC 3261 currently specifies 3DES as the mandatory-to-implement ciphersuite for implementations of S/MIME in the Session Initiation Protocol (SIP). This RFC updates the normative guidance of RFC 3261 to require the Advanced Encryption Standard (AES) for S/MIME.

3891 The Session Initiation Protocol (SIP) "Replaces" Header

This RFC defines a new header for use with Session Initiation Protocol (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.

3892 The Session Initiation Protocol (SIP) Referred-By Mechanism

The Session Initiation Protocol (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 RFC 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.

3893 Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format

RFC 3261 introduces the concept of adding an S/MIME body to a Session Initiation Protocol (SIP) request or response in order to provide reference integrity over its headers. This RFC 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 RFC. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given.

3911 The Session Initiation Protocol (SIP) "Join" Header

This RFC 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.

3903 Session Initiation Protocol (SIP) Extension for Event State Publication

This RFC describes an extension to the Session Initiation Protocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information. The mechanism described in this RFC 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.

3968 (updates RFC 3427) The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)

This RFC creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (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.

3969 (updates RFC 3427) The Internet Assigned Number Authority (IANA) Universal Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)

This RFC creates an Internet Assigned Number Authority (IANA) registry for the Session Initiation Protocol (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.

4028 Session Timers in the Session Initiation Protocol (SIP)

This RFC defines an extension to the Session Initiation Protocol (SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields: Session-Expires, which conveys the lifetime of the session, and Min-SE, which conveys the minimum allowed value for the session timer.

4032 (updates RFC 3312) Update to the Session Initiation Protocol (SIP) Preconditions Framework

This RFC updates RFC 3312, which defines the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility.

4092 Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)

This RFC describes how to use the Alternative Network Address Types (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP. In particular, we define the sdp-anat SIP option-tag. This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT.

4168 The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)

This RFC specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between SIP (Session Initiation Protocol) entities. SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that exchange a large amount of messages, including gateways and proxies. As SIP is transport-independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP.

4244 An Extension to the Session Initiation Protocol (SIP) for Request History Information

This RFC defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This RFC defines a new optional SIP header, History-Info, for capturing the history information in requests.

4320 (updates RFC 3261) Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction

This RFC describes modifications to the Session Initiation Protocol (SIP) to address problems that have been identified with the SIP non-INVITE transaction. These modifications reduce the probability of messages losing the race condition inherent in the non-INVITE transaction and reduce useless network traffic. They also improve the robustness of SIP networks when elements stop responding. These changes update behavior defined in RFC 3261.

4321 Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction

This RFC describes several problems that have been identified with the Session Initiation Protocol's (SIP) non-INVITE transaction.

4412 Communications Resource Priority for
the Session Initiation Protocol (SIP)

This RFC defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely, "Resource-Priority" and "Accept-Resource-Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior of IP routers.

4474 Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)

The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context.  This RFC defines a mechanism for securely identifying originators of SIP messages.  It does so by defining two new SIP header fields, Identity, for conveying a signature used for   validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer.

4483 A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages

This RFC defines an extension to the URL MIME External-Body Access-Type to satisfy the content indirection requirements for the Session Initiation Protocol (SIP).  These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI.

4485 Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)

The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across the Internet.  Part of this flexibility is the ease with which it can be extended.  In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions.  This RFC outlines a set of such guidelines for authors of SIP extensions.

4488 Suppression of Session Initiation Protocol (SIP)
REFER Method Implicit Subscription

The Session Initiation Protocol (SIP) REFER extension as defined in RFC 3515 automatically establishes a typically short-lived event subscription used to notify the party sending a REFER request about the receiver's status in executing the transaction requested by the REFER. These notifications are not needed in all cases. This specification provides a way to prevent the automatic establishment of an event subscription and subsequent notifications using a new SIP extension header field that may be included in a REFER request.

4508 Conveying Feature Tags with Session Initiation Protocol (SIP) REFER Method

The SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request.  The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request.  This RFC extends the REFER method to use the mechanism of RFC 3840.  By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach.

4538 Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)

This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog.  This header field is used in requests that create SIP dialogs.  It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers.  The recipient can then authorize the request based on this awareness.

4780 Management Information Base for the Session Initiation Protocol (SIP)

This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, and Proxy, Redirect and Registrar servers.

4916 Connected Identity in the Session Initiation Protocol (SIP) - Updates RFC 3261

This RFC provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This RFC normatively updates RFC 3261 (SIP).

5079 Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) (RFC 5079)

The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity. This specification defines a new SIP response code for this purpose.

5360 A Framework for Consent-based Communications in the Session Initiation Protocol (SIP) (RFC 5360)

SIP supports communications for several services, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification and DoS (Denial of Service) attacks. This RFC identifies a framework for consent-based communications in SIP.

5365 Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP) (RFC 5365)

This RFC specifies a mechanism that allows a SIP User Agent Client (UAC) to send a SIP MESSAGE request to a set of destinations, by using a SIP URI-list (Uniform Resource Identifier list) service. The UAC sends a SIP MESSAGE request that includes the payload along with the URI list to the MESSAGE URI-list service, which sends a MESSAGE request including the payload to each of the URIs included in the list.

5366 Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP) (RFC 5366)

This RFC describes how to create a conference using SIP URI-list services.  In particular, it describes a mechanism that allows a User Agent Client to provide a conference server with the initial list of participants using an INVITE-contained URI list.

5367 Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP) (RFC 5367)

This RFC specifies a way to create subscription to a list of resources in SIP. This is achieved by including the list of resources in the body of a SUBSCRIBE request. Instead of having a subscriber send a SUBSCRIBE request for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' states using a single SUBSCRIBE dialog.

5368 Referring to Multiple Resources in the Session Initiation Protocol (SIP) (RFC 5368)

This RFC defines extensions to the SIP REFER method so that it can be used to refer to multiple resources in a single request. These extensions include the use of pointers to Uniform Resource Identifier (URI) lists in the Refer-To header field and the "multiple-refer" SIP option-tag.

5373 Requesting Answering Modes for the Session Initiation Protocol (SIP) (RFC 5373)

This RFC extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or, instead, accepts the request without waiting on user input. The second header, "Priv-Answer-Mode", is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as push-to-talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined.

5393 Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies (RFC 5393)

This RFC normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP
networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic.
This RFC strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this RFC defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request.

5411 A Hitchhiker's Guide to the Session Initiation Protocol (SIP)

The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right RFC, or even to determine the set of Request for Comments (RFC) about SIP. This specification serves as a guide to the SIP RFC series. It lists a current snapshot of the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories.

5478 IANA Registration of New Session Initiation Protocol (SIP)
Resource-Priority Namespaces

 

This RFC creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the US Defense Information Systems Agency, and places these namespaces in the IANA registry.

5479 Requirements and Analysis of Media Security Management Protocols

 

This RFC describes requirements for a protocol to negotiate a security context for SIP-signaled Secure RTP (SRTP) media. In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways. A number of proposals have been published and a summary of these proposals is in the appendix of this document.

[Up]

ALL RFCs created by The SIPPING Working Group
RFC#  Name Description (abstract)
3324 Short Term Requirements for Network Asserted Identity 

A Network Asserted Identity is an identity initially derived by a Session Initiation Protocol (SIP) network intermediary as a result of an authentication process. This RFC describes short term requirements for the exchange of Network Asserted Identities within networks of securely interconnected trusted nodes and to User Agents securely connected to such networks. There is no requirement for identities asserted by a UA in a SIP message to be anything other than the user's desired alias.

3351 User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired individuals 

This RFC presents a set of Session Initiation Protocol (SIP) user requirements that support communications for deaf, hard of hearing and speech-impaired individuals. These user requirements address the current difficulties of deaf, hard of hearing and speech-impaired individuals in using communications facilities, while acknowledging the multi-functional potential of SIP-based communications. A number of issues related to these user requirements are further raised in this RFC. Also included are some real world scenarios and some technical requirements to show the robustness of these requirements on a concept-level.

3372 Session Initiation Protocol (SIP) for Telephones (SIP-T): Context and Architectures 

The popularity of gateways that interwork between the PSTN (PublicSwitched Telephone Network) and SIP networks has motivated the publication of a set of common practices that can assure consistent behavior across implementations. This RFC taxonomizes the uses of PSTN-SIP gateways, provides uses cases, and identifies mechanisms necessary for interworking. The mechanisms detail how SIP provides for both 'encapsulation' (bridging the PSTN signaling across a SIP network) and 'translation' (gatewaying).

3398 Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping

This RFC describes a way to perform the mapping between two signaling protocols: the Session Initiation Protocol (SIP) and the Integrated Services Digital Network (ISDN) User Part (ISUP) of Signaling System No. 7 (SS7). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN).

3485 The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)

The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, the Session Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent.

3578 Mapping of of Integrated Services Digital Network (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)

This RFC describes a way to map Integrated Services Digital Network User Part (ISUP) overlap signalling to Session Initiation Protocol (SIP). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN).

3665 Session Initiation Protocol Basic Call Flow Examples

This informational RFC gives examples of Session Initiation Protocol (SIP) call flows. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers. Scenarios include SIP Registration and SIP session establishment. Call flow diagrams and message details are shown.

3666 Session Initiation Protocol PSTN Call Flows

This informational RFC contains best current practice examples of Session
Initiation Protocol (SIP) call flows showing interworking with the Public Switched Telephone Network (PSTN). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and PSTN Gateways. Scenarios include SIP to PSTN, PSTN to SIP, and PSTN to PSTN via SIP. PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ISUP (ISDN User Part), and FGB (Feature Group B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Call flow diagrams and message details are shown.

3680 A Session Initiation Protocol (SIP) Event Package for Registrations

This RFC defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations. Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications.

3702 Authentication, Authorization and Accounting Requirements for the Session Initiation Protocol

As Session Initiation Protocol (SIP) services are deployed on the Internet, there is a need for authentication, authorization, and accounting of SIP sessions. This RFC sets out the basic requirements for this work.

3725 Best Current Practices for Third Party Call Control in the Session Initiation Protocol

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 the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This RFC discusses best current practices for the usage of SIP for third party call control.

3824 Using E.164 numbers with the Session Initiation Protocol (SIP)

There are a number of contexts in which telephone numbers are employed by Session Initiation Protocol (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 RFC 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.

3842 A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)

This RFC describes a Session Initiation Protocol (SIP) event package to carry message waiting status and message summaries from a messaging system to an interested User Agent.

3959 The Early Session Disposition Type for the Session Initiation Protocol (SIP)

This RFC defines a new disposition type (early-session) for the Content-Disposition header field in the Session Initiation Protocol (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.

3960 Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)

This RFC describes how to manage early media in the Session Initiation Protocol (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.

4083 Input 3rd-Generation Partnership Project (3GPP) Release 5 requirements on the Session Initiation Protocol (SIP)

The 3rd-Generation Partnership Project (3GPP) has selected Session Initiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of Release 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this RFC, we express the requirements identified by 3GPP to support SIP for Release 5 of the 3GPP IMS in cellular networks.

4117 Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)

This RFC describes how to invoke transcoding services using Session Initiation Protocol (SIP) and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals.

4189 Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP)

A Session Initiation Protocol (SIP) User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message. The UA might want to protect the message bodies and/or headers from intermediaries, except those that provide services based on its content. This situation requires a mechanism called "end-to-middle security" to secure the information passed between the UA and intermediaries, which does not interfere with end-to-end security. This RFC defines a set of requirements for a mechanism to achieve end-to-middle security.

4235 An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)

This RFC 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 and to receive notification of the changes in state of INVITE- initiated dialog usages in which the subscribed-to user is involved.

4245 High-Level Requirements for Tightly Coupled SIP Conferencing

This RFC examines a wide range of conferencing requirements for tightly coupled SIP conferences. Separate RFCs will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these RFCs will provide a guide for building interoperable SIP conferencing applications.

4353 A Framework for Conferencing with the
Session Initiation Protocol (SIP)

The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This RFC defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi-party conferencing.

4411 Extending the Session Initiation Protocol (SIP)
Reason Header for Preemption Events

This RFC proposes an IANA Registration extension to the Session Initiation Protocol (SIP) Reason Header to be included in a BYE Method Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). This RFC does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred.

4453 Requirements for Consent-Based Communications
in the Session Initiation Protocol (SIP)

The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including spam and denial-of-service attacks. This RFC identifies a set of requirements for extensions to SIP that add consent-based communications.

4475 Session Initiation Protocol (SIP) Torture Test Messages

This informational RFC gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" a SIP implementation. 

4484 Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)

This RFC lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol (SIP).  While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session.  This approach provides a richer framework for authorization, as well as allows greater privacy for users of an identity system. 

4497 Interworking between the Session Initiation Protocol (SIP) and QSIG

This RFC specifies interworking between the Session Initiation Protocol (SIP) and QSIG within corporate telecommunication networks (also known as enterprise networks). SIP is an Internet application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include, in particular, telephone calls. QSIG is a signalling protocol for creating, modifying, and terminating circuit-switched calls (in particular, telephone calls) within Private Integrated Services Networks (PISNs). QSIG is specified in a number of Ecma Standards and published also as ISO/IEC standards.

4569 Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag

This RFC registers with the IANA a new media feature tag associated with the 'message' media type. This media feature tag indicates that a particular device supports 'message' as a streaming media type. Media feature tags can be used to route calls to devices that support certain features.

4575 A Session Initiation Protocol (SIP) Event Package for Conference State

This RFC defines a conference event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for this package.  The conference package allows users to subscribe to a conference Uniform Resource Identifier (URI).  Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components.

4579 Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents

This specification defines conferencing call control features for the Session Initiation Protocol (SIP).  This RFC builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works.  The approach is explored from the perspective of different user agent (UA) types:  conference-unaware, conference-aware, and focus UAs.  The use of Uniform   Resource Identifiers (URIs) in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams.  The usage of the isfocus feature tag is defined.

4596 Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension

This RFC contains guidelines for usage of the Caller Preferences Extension to the Session Initiation Protocol (SIP).  It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in Section 7.2 of RFC 3841. 

4730 A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML)

This RFC describes a SIP Event Package "kpml" that enables monitoring of Dual Tone Multi-Frequency (DTMF) signals and uses Extensible Markup Language (XML) documents referred to as Key Press Markup Language (KPML).  The kpml Event Package may be used to support applications consistent with the principles defined in the document titled "A Framework for Application Interaction in the Session Initiation Protocol (SIP)".  The event package uses SUBSCRIBE   messages and allows for XML documents that define and describe filter   specifications for capturing key presses (DTMF Tones) entered at a presentation-free User Interface SIP User Agent (UA).  The event package uses NOTIFY messages and allows for XML documents to report the captured key presses (DTMF tones), consistent with the filter specifications, to an Application Server.  The scope of this package is for collecting supplemental key presses or mid-call key presses (triggers). 

5039 The Session Initiation Protocol (SIP) and Spam

Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email. It can affect any system that enables user-to-user communications. The Session Initiation Protocol (SIP) defines a system for user-to-user multimedia communications. Therefore, it is susceptible to spam, just as email is. In this RFC, we analyze the problem of spam in SIP. We first identify the ways in which the problem is the same and the ways in which it is different from email. We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP.

5057 Multiple Dialog Usages in the Session Initiation Protocol

Several methods in the Session Initiation Protocol (SIP) can create an association between endpoints known as a dialog. Some of these methods can also create a different, but related, association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. Processing multiple dialog usages correctly is not completely understood. What is understood is difficult to implement. This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them. This is an informative RFC and makes no normative statements of any kind.

5118 Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6)

This RFC provides examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" the code of an IPv6-enabled SIP implementation.

5194 Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP)

This RFC lists the essential requirements for real-time Text-over-IP (ToIP) and defines a framework for implementation of all required functions based on the Session Initiation Protocol (SIP) and the Real-Time Transport Protocol (RTP).  This includes interworking between Text-over-IP and existing text telephony on the Public Switched Telephone Network (PSTN) and other networks.

5359 Session Initiation Protocol Service Examples (RFC 5359)

This RFC gives examples of Session Initiation Protocol (SIP) services. This covers most features offered in so-called IP Centrex offerings from local exchange carriers and PBX (Private Branch Exchange) features. Most of the services shown in this RFC are implemented in the SIP user agents, although some require the assistance of a SIP proxy. Some require some extensions to SIP including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces and Join header fields. These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment.

5361 A Document Format for Requesting Consent (RFC 5361)

This RFC defines an Extensible Markup Language (XML) format for a permission document used to request consent. A permission document written in this format is used by a relay to request a specific
recipient permission to perform a particular routing translation.

5362 The Session Initiation Protocol (SIP) Pending Additions Event Package (RFC 5362)

This RFC defines the SIP Pending Additions event package. This event package is used by SIP relays to inform user agents about the consent-related status of the entries to be added to a resource list.

5363 Framework and Security Considerations for Session Initiation Protocol (SIP) Uniform Resource Identifier (URI)-List Services (RFC 5363)

This RFC describes the need for SIP URI-list services and provides requirements for their invocation.  Additionally, it defines a framework for SIP URI-list services, which includes security   considerations applicable to these services.

5364 Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists (RFC 5364)

In certain types of multimedia communications, a Session Initiation Protocol (SIP) request is distributed to a group of SIP User Agents (UAs). The sender sends a single SIP request to a server which further distributes the request to the group. This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request. This URI list is expressed as a resource list XML document. This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing email systems.

5369 Framework for Transcoding with the Session Initiation Protocol (SIP) (RFC 5369)

This RFC defines a framework for transcoding with SIP. This framework includes how to discover the need for transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed: the conference bridge model and the third-party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals.

5370 The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model (RFC 5370)

This RFC describes how to invoke transcoding services using the conference bridge model. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals.

5390 Requirements for Management of Overload in the Session Initiation Protocol (RFC 5390)

Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insufficient resources to complete the processing of a request. SIP provides limited support for overload
handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This RFC summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution.

5407 Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP) (RFC 5407)

This RFC gives example call flows of race conditions in the Session Initiation Protocol (SIP). Race conditions are inherently confusing and difficult to thwart; this RFC shows the best practices to handle them. The elements in these call flows include SIP User Agents and SIP Proxy Servers. Call flow diagrams and message details are given.

[Up]

ALL RFCs created by The SPIRITS Working Group
RFC#  Name Description (abstract)
2995 Pre-Spirits Implementations of PSTN-initiated Services

This RFC contains information relevant to the work underway in The Services in the PSTN/IN Requesting InTernet Services (SPIRITS) Working Group. It describes four existing implementations of SPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN.

3136 The SPIRITS Architecture 

This RFC describes the architecture for supporting SPIRITS services, which are those originating in the PSTN (Public Switched Telephone Network) and necessitating the interactions between the PSTN and the Internet. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services.) Specifically, it defines the components constituting the architecture and the interfaces between the components.

3298 SPIRITS Protocol Requirements 

This RFC describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public Switched Telephone Network (PSTN) and necessitate the interactions between the PSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, and Internet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlier IETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN. To this end, this RFC lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The RFC also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol.

3910 The SPIRITS (Services in PSTN requesting Internet Services) Protocol 

This RFC 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.

[Up]

ALL RFCs created by The IPTEL Working Group
RFC#  Name Description (abstract)
2824 Call Processing Language Framework and Requirements 

A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete. We want a simple and standardized way to create such services to make them easier to implement and deploy. This RFC describes an architectural framework for such a mechanism, which we call a call processing language. It also outlines requirements for such a language.

2871 A Framework for a Gateway Location Protocol 

This RFC serves as a framework for Telephony Routing over IP (TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. The RFC defines the problem of telephony routing exchange, and motivates the need for the protocol. It presents an architectural framework for TRIP, defines terminology, specifies the various protocol elements and their functions, overviews the services provided by the protocol, and discusses how it fits into the broader context of Internet Telephony.

3219 Telephony Routing over IP (TRIP) 

This RFC presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers,and for advertising attributes of the routes to those destinations. TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4.

3872 Management Information Base for Telephony Routing over IP (TRIP) 

This memo defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Telephony Routing over IP (TRIP) devices.

3880 Call Processing Language (CPL): A Language for User Control of Internet Telephony Services

This RFC 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.

3966 (obsoletes RFC 2806) The tel URI for Telephone Numbers

This RFC specifies the URI (Uniform Resource Identifier) scheme "tel". The "tel" URI describes resources identified by telephone numbers. This RFC obsoletes RFC 2806.

4694 Number Portability Parameters for the "tel" URI

This RFC defines five parameters in the "tel" Uniform Resource Identifier (URI) to carry the number portability (NP)-related information. Those parameters can be passed to the next-hop network node after an NP database dip has been performed.

4759 The ENUM Dip Indicator Parameter for the "tel" URI

This RFC defines a new parameter "enumdi" for the "tel" Uniform Resource Identifier (URI) to support the handling of ENUM queries in Voice over Internet Protocol (VoIP) network elements.  A VoIP network element may receive a URI containing an E.164 number, where that URI contains an "enumdi" parameter.  The presence of the "enumdi" parameter indicates that an ENUM query has already been performed on the E.164 number by a previous VoIP network element.  Equally, if a VoIP network element sends such a URI, it asserts that an ENUM query has been carried out on this number.

4904 Representing trunk groups in tel/sip Uniform Resource Identifiers (URIs)

This RFC describes a standardized mechanism to convey trunk group parameters in sip and tel Uniform Resource Identifiers (URIs). An extension to the tel URI is defined for this purpose.

5140 A Telephony Gateway REgistration Protocol (TGREP)

This RFC describes the Telephony Gateway Registration Protocol (TGREP) for registration of telephony prefixes supported by telephony gateways and soft switches. The registration mechanism can also be used to export resource information. The prefix and resource information can then be passed on to a Telephony Routing over IP (TRIP) Location Server, which in turn can propagate that routing information within and between Internet Telephony Administrative Domains (ITADs). TGREP shares a lot of similarities with the TRIP protocol. It has similar procedures and finite state machine for session establishment. It also shares the same format for messages and a subset of attributes with TRIP.

5341 (updates 3966) The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry (RFC 5341)

This RFC creates an Internet Assigned Number Authority (IANA) registry for tel Uniform Resource Identifier (URI) parameters and their values. It populates the registry with the parameters defined in the tel URI specification, along with the parameters in tel URI extensions defined for number portability and trunk groups.

[Up]

ALL RFCs created by The ENUM Working Group
RFC#  Name Description (abstract)
2916 (Obsoleted by RFC 3761) E.164 number and DNS

This RFC discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. Routing of the actual connection using the service selected using these methods is not discussed.

3482 Number Portability in the Global Switched Telephone Network (GSTN): An Overview 

This RFC provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN). NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony works-in-progress with the IETF.

3761 (obsoletes RFC 2916) The E.164 to URI DDDS Application (ENUM)

This RFC discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the Dynamic Delegation Discovery System (DDDS) Application specification found in the RFC series specified in RFC 3401. It is very important to note that it is impossible to read and understand this RFC without reading the documents discussed in RFC 3401.

3762 ENUM Service Registration for H.323 URL

The H.323 specification defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This RFC registers a Telephone Number Mapping (ENUM) service for H.323 according to specifications and guidelines in RFC 3761.

3764 enumservice registration for SIP Addresses-of-Record 

This RFC registers an Electronic Number (ENUM) service for the Session Initiation Protocol (SIP), pursuant to the guidelines in RFC 3761. Specifically, this RFC focuses on provisioning SIP addresses-of-record in ENUM.

3953 Enumservice Registration for Presence Services

This RFC registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this RFC focuses on provisioning pres URIs in ENUM.

4002 IANA Registration for ENUMservices web and ft

This RFC registers the Enumservices 'web' and 'ft' by using the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in the ENUM specification (RFC 3761).

4114 E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)

This RFC describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers that represent domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers.

4355 IANA Registration for Enum services email, fax, mms, ems, and sms

This RFC registers the Enumservices "email", "fax", "sms", "ems", and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC 3761.

4414 An ENUM Registry Type
for the Internet Registry Information Service (IRIS)

This RFC describes an Internet Registry Information Service (IRIS) registry schema for registered ENUM information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by ENUM registries.

4415 IANA Registration for Enumservice Voice

This RFC registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in the ENUM specification RFC 3761. This service indicates that the contact held in the generated Uniform Resource Identifier (URI) can be used to initiate an interactive voice (audio) call.

4725 ENUM Validation Architecture

An ENUM domain name is tightly coupled with the underlying E.164 number.  The process of verifying whether or not the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation".  This RFC describes validation requirements and a high-level architecture for an ENUM validation infrastructure.

4769 IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information

This RFC registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype "sip" using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification, RFC 3761.  This Enumservice is used to facilitate the routing of telephone calls in those countries where number portability exists.

4969 IANA Registration for vCard Enumservice

This memo registers the Enumservice "vCard" using the URI schemes "http" and "https". This Enumservice is to be used to refer from an ENUM domain name to a vCard instance describing the user of the respective E.164 number. Information gathered from those vCards could be used before, during, or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call.

4979 IANA Registration for Enumservice 'XMPP'

This RFC requests IANA registration of an Enumservice for XMPP, the Extensible Messaging and Presence Protocol. This Enumservice specifically allows the use of 'xmpp' Uniform Resource Identifiers (URIs) in the context of E.164 Number Mapping (ENUM).

5028 A Telephone Number Mapping (ENUM) Service Registration for
Instant Messaging (IM) Services

This RFC registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this RFC focuses on provisioning 'im:' URIs (Uniform Resource Identifiers) in ENUM.

5067 Infrastructure ENUM Requirements

This RFC provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.)

5076 ENUM Validation Information Mapping for the Extensible Provisioning Protocol

This RFC describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range) that the E.164 Number Mapping (ENUM) domain name is based on. Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM Domain Names.

5105 ENUM Validation Token Format Definition

An ENUM domain name is tightly coupled with the underlying E.164 number.  The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation".  This RFC describes a signed XML data format -- the Validation Token -- with which    Validation Entities can convey successful completion of a validation procedure in a secure fashion.

5278 IANA Registration of Enumservices for Voice and Video Messaging

This RFC registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice, video, and unified communications to a messaging system. This vmsg Enumservice registers three Enumservice types: "voicemsg", "videomsg", and "unifmsg". Each type also registers the subtypes "sip", "sips", "http", and "https", as well as the subtype "tel" for the "voicemsg" type.

5346 Operational Requirements for ENUM-Based Softswitch Use

This RFC describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean Voice over IP (VoIP) carriers, gained
during the ENUM pre-commercial trial hosted by the National Internet Development Agency of Korea (NIDA) in 2006. These experiences show that an interim solution can maintain the stability of ongoing commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls.

5483 ENUM Implementation Issues and Experiences

This RFC captures experiences in implementing systems based on the ENUM protocol and experiences of ENUM data that have been created by others. As such, it clarifies the ENUM and Dynamic Delegation Discovery System standards. Its aim is to help others by reporting both what is "out there" and potential pitfalls in interpreting the set of documents that specify the ENUM protocol. It does not revise the standards but is intended to provide technical input to future revisions of those documents.

5526 The E.164 to Uniform Resource Identifiers (URI)
Dynamic Delegation Discovery System (DDDS) Application
for Infrastructure ENUM

This RFC defines the use case for Infrastructure ENUM and proposes its implementation as a parallel namespace to "e164.arpa", as defined in RFC 3761, as the long-term solution to the problem of allowing carriers to provision DNS records for telephone numbers independently of those provisioned by end users (number assignees).

5527 Combined User and Infrastructure ENUM in the e164.arpa Tree

This memo defines an interim solution for Infrastructure ENUM in order to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice. This interim solution will be deprecated after implementation of the long-term solution.

5333 IANA Registration of Enumservices for Internet Calendaring
 

This document registers Enumservices for Internet calendaring. Specifically, this document focuses on Enumservices for scheduling with iMIP (iCalendar Message-Based Interoperability Protocol) and for accessing Internet calendaring information with CalDAV (Calendaring Extensions to WebDAV).

[Up]

ALL RFCs created by The IMPP Working Group
RFC#  Name Description (abstract)
2778 A Model for Presence and Instant Messaging 

This RFC defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. The goal is to provide a common vocabulary for further work on requirements for protocols and markup for presence and instant messaging.

2779 Instant Messaging / Presence Protocol Requirements 

Presence and instant messaging have recently emerged as a new medium of communications over the Internet. Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. "online" or "offline") of other users. Instant messaging is a means for sending small, simple messages that are delivered immediately to online users. Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors. The goal of the Instant Messaging and Presence Protocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet. This RFC defines a minimal set of requirements that IMPP must meet.

3339 Date and Time on the Internet: Timestamps

This RFC defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.

3859 Common Profile for Presence (CPP)

At the time this RFC 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.

3860 Common Profile for Instant Messaging (CPIM)

At the time this RFC 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.

3861 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 RFC provides guidance for locating the resources associated with URIs that employ these schemes.

3862 Common Presence and Instant Messaging (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.

3863 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]

ALL RFCs created by The SIMPLE Working Group
RFC#  Name Description (abstract)
3856 A Presence Event Package for the Session Initiation Protocol (SIP) 

This RFC describes the usage of the Session Initiation Protocol (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 an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence Profile (CPP) framework.

3857 A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)

This RFC defines the watcher information template-package for the Session Initiation Protocol (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.

3858 An Extensible Markup Language (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.

3994 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 RFC 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.

4479 A Data Model for Presence

This RFC defines the underlying presence data model used by Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence agents.  The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion.

4480 RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)

The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity.  This format defines a textual note, an indication of availability (open or closed) and a Uniform Resource Identifier (URI) for communication.  The Rich Presence Information Data format (RPID) described here is an extension that adds optional elements to the Presence Information Data Format (PIDF).  These extensions provide additional information about the presentity and its contacts.  The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media communications might remain private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers, an icon reflecting the presentity's status, and the overall role of the presentity. These extensions include presence information for persons, services (tuples), and devices.

4481 Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals

The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity.  This RFC extends PIDF, adding a timed status extension (<timed-status> element) that allows a presentity to declare its status for a time interval fully in the future or the past.

4482 CIPID: Contact Information in Presence Information Data Format

The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity.  The Contact Information for the Presence Information Data format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons.

4660 Functional Description of Event Notification Filtering

The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to the state of a resource.  The RFC does not describe a mechanism whereby filtering of event notification information can be achieved. This RFC describes the operations a subscriber performs in order to put filtering rules associated with a subscription to event notification information in place.  The handling, by the subscriber, of responses to subscriptions carrying filtering rules and the handling of notifications with filtering rules applied to them are also described.  Furthermore, the RFC conveys how the notifier behaves when receiving such filtering rules and how a notification is constructed.

4661 An Extensible Markup Language (XML) Based Format for Event Notification Filtering

The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource.  The RFC does not describe a mechanism whereby filtering of event notification information can be achieved.  Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying triggers that cause that information to be delivered.  In order to enable this, a format is needed to enable the subscriber to describe the state changes of a resource that cause notifications to be sent to it and what those notifications are to contain.  this RFC presents a format in the form of an XML document.

4662 A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists

This RFC presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources.  Instead of sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list and then receive notifications when the state of any of the resources in the list changes.

4825 The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)

This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write, and modify application configuration data stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP.

4826 Extensible Markup Language (XML) Formats for Representing Resource Lists

In multimedia communications, presence, and instant messaging systems, there is a need to define Uniform Resource Identifiers (URIs) that represent services that are associated with a group of users. One example is a resource list service. If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents. One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists that are referenced from the first. This list of users can be utilized by other applications and services. Both documents can be created and managed with the XML Configuration Access Protocol (XCAP).

4827 An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents

This RFC describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence documents. It is intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs on which it builds the overall presence state for the presentity.

4975 The Message Session Relay Protocol (MSRP)

This RFC describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session.  Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol.

4976 Relay Extensions for the Message Session Relay Protocol (MSRP)

Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a Session Initiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session Relay Protocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This RFC introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them.

5025 Presence Authorization Rules

Authorization is a key function in presence systems.  Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when.  This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules.  Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted.

5196 Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)

Presence Information Data Format (PIDF) defines a common presence data format for Common Profile for Presence (CPP) compliant presence protocols. This memo defines a PIDF extension to represent SIP User Agent capabilities.

5261 An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors

Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This RFC describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic <add>, <replace>, and <remove> directives a set of patches can then be applied to update an existing XML document.

5262 Presence Information Data format (PIDF) Extension for Partial Presence

The Presence Information Document Format (PIDF) specifies the baseline XML-based format for describing presence information.  One of the characteristics of the PIDF is that the document always needs to carry all presence information available for the presentity.  In some environments where low bandwidth and high latency links can exist, it is often beneficial to limit the amount of transported   information over the network.  This RFC introduces a new MIME type that enables transporting of either only the changed parts or the full PIDF-based presence information.

5263 Session Initiation Protocol (SIP) extension for Partial Notification of Presence Information

By default, presence delivered using the presence event package for the Session Initiation Protocol (SIP) is represented in the Presence Information Data Format (PIDF).  A PIDF document contains a set of   elements, each representing a different aspect of the presence being reported.  When any subset of the elements change, even just a single element, a new document containing the full set of elements is   delivered.  This memo defines an extension allowing delivery of only the presence data that has actually changed.

5264 Publication of Partial Presence Information

The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent.  Using the
Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update.  As a consequence,   updating a sizeable presence document with small changes bears a considerable overhead and is therefore inefficient.  Especially with low bandwidth and high latency links, this can constitute a   considerable burden to the system.  This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for   publication of partial presence information.

5438 Instant Message Disposition Notification (IMDN)

Instant Messaging (IM) refers to the transfer of messages between users in real-time. This RFC provides a mechanism whereby endpoints can request Instant Message Disposition Notifications (IMDN), including delivery, processing, and display notifications,
for page-mode instant messages. The Common Presence and Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs.
This RFC also describes how SIP entities behave using this extension.

[Up]

ALL RFCs created by The XMPP Working Group
RFC#  Name Description (abstract)
3920 Extensible Messaging and Presence Protocol (XMPP): Core

This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.

3921 Extensible Messaging and Presence Protocol (XMPP):
Instant Messaging and Presence

This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779.

3922 Mapping the Extensible Messaging and Presence Protocol (XMPP) to
Common Presence and Instant Messaging (CPIM)

This memo describes a mapping between the Extensible Messaging and Presence Protocol (XMPP) and the Common Presence and Instant Messaging (CPIM) specifications.

3923 End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)

This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP).

[Up]

Key RFCs created by The INTSERV Working Group

Only the main RFC is shown below. You can see all other RFCs here.

RFC#  Name Description (abstract)
2212 Specification of Guaranteed Quality of Service

This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in the Internet. Guaranteed service provides firm (mathematically provable) bounds on end-to-end datagram queueing delays. This service makes it possible to provide a service that guarantees both delay and bandwidth. This specification follows the service specification template described in RFC 2216.

[Up]

Key RFCs created by The RSVP Working Group

Only the main RFC is shown below. You can see all other RFCs here.

RFC#  Name Description (abstract)
2205 (Note: This RFC does not appear in the OLD area of the WG. It appears as written by the Network WG... Still we see this RFC as the key RSVP RFC) Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification

This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties.

[Up]

Key RFCs created by The MIDCOM Working Group

Only the two main RFCs are shown below. You can see all other RFCs here.

RFC#  Name Description (abstract)
3304 Middlebox Communications (MIDCOM) Protocol Requirements

This RFC specifies the requirements that the Middlebox Communication (midcom) protocol must satisfy in order to meet the needs of applications wishing to influence the middlebox function. These requirements were developed with a specific focus on network address translation and firewall middleboxes.

3489 STUN - Simple Traversal of UDP Through Network Address Translators

Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet.  It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT.  STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure.

[Up]

Key RFCs created by The GEOPRIV Working Group

Only the main RFC is shown below. You can see all other RFCs here.

RFC#  Name Description (abstract)
3693 Geopriv requirements

Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved. This RFC focuses on the authorization, security and privacy requirements for such location-dependent services. Specifically, it describes the requirements for the Geopriv Location Object (LO) and for the protocols that use this Location Object. This LO is envisioned to be the primary data structure used in all Geopriv protocol exchanges to securely transfer location data.

[Up]

Key RFCs created by The DIFFSERV Working Group

Only the 2 main RFCs are shown below. You can see all other RFCs here.

RFC#  Name Description (abstract)
2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

Differentiated services enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop.

2475 An Architecture for Differentiated Services

This RFC defines an architecture for implementing scalable service differentiation in the Internet. This architecture achieves scalability by aggregating traffic classification state which is conveyed by means of IP-layer packet marking using the DS field [DSFIELD]. Packets are classified and marked to receive a particular per-hop forwarding behavior on nodes along their path. Sophisticated classification, marking, policing, and shaping operations need only be implemented at network boundaries or hosts. Network resources are allocated to traffic streams by service provisioning policies which govern how traffic is marked and conditioned upon entry to a differentiated services-capable network, and how that traffic is forwarded within that network. A wide variety of services can be implemented on top of these building blocks.

[Up]

Key RFCs created by The AVT Working Group

Only the main RFC (RTP/RTCP) is shown below. You can see all other AVT RFCs here.

RFC#  Name Description (abstract)
3550 (Obsoletes 1889) RTP: A Transport Protocol for Real-Time Applications

This RFC describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this RFC is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously.

[Up]

Key RFCs created by The megaco Working Group

Only the main RFC (Gateway Control protocol 1) is shown below. You can see all other RFCs here.

RFC#  Name Description (abstract)
3525 (obsoletes RFC 3015) Gateway Control Protocol Version 1 

This RFC defines the protocol used between elements of a physically decomposed multimedia gateway, i.e., a Media Gateway and a Media Gateway Controller. The protocol presented in this RFC meets the requirements for a media gateway control protocol as presented in RFC 2805. This RFC replaces RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T Study Group 16. It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the Megaco E-mail list and incorporated into the Study Group 16 Implementor's Guide for Recommendation H.248. The present version of this document underwent ITU-T Last Call as Recommendation H.248 Amendment 1. Because of ITU-T renumbering, it was published by the ITU-T as Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. Users of this specification are advised to consult the H.248 Sub-series Implementors' Guide at http://www.itu.int/itudoc/itu- t/com16/implgd for additional corrections and clarifications.

[Up]

Key RFCs created by The mmusic Working Group

Only the main RFCs are shown below. You can see all other RFCs here.

RFC#  Name Description (abstract)
2326 Real Time Streaming Protocol (RTSP) 

The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 1889).

2327 (updated by RFC 3266 and obsoleted by 4566 - see below) SDP: Session Description Protocol

This RFC defines the Session Description Protocol, SDP. SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.

3264 An Offer/Answer Model with SDP

This RFC defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP).

3266 (updates RFC 2327 but obsoleted by RFC 4566 - see above and below respectively) Support for IPv6 in Session Description Protocol (SDP) 

This RFC describes the use of Internet Protocol Version 6 (IPv6) addresses in conjunction with the Session Description Protocol (SDP). Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses..

4566 (obsoletes RFC 2327,RFC 3266
 - see above)
SDP: Session Description Protocol (RFC 4566) 

This RFC defines the Session Description Protocol (SDP).  SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.

[Up]

Key RFC created by The SIGTRAN Working Group

Only the main RFC is shown below. You can see all other RFCs here.

RFC#  Name Description (abstract)
2960 (updated by RFC 3309/obsoleted by RFC 4960) Stream Control Transmission Protocol 

This RFC describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport PSTN signaling messages over IP networks, but is capable of broader applications.

[Up]

ALL RFCs created by The PiNT Working Group
RFC#  Name Description (abstract)
2548 Toward the PSTN/Internet Inter-Networking --Pre-PINT Implementations 

This RFC contains the information relevant to the development of the inter-networking interfaces underway in the Public Switched Telephone Network (PSTN)/Internet Inter-Networking (PINT) Working Group. It addresses technologies, architectures, and several (but by no means all) existing pre-PINT implementations of the arrangements through which Internet applications can request and enrich PSTN telecommunications services. The common denominator of the enriched services (a.k.a. PINT services) is that they combine the Internet and PSTN services in such a way that the Internet is used for non-voice interactions, while the voice (and fax) are carried entirely over the PSTN. One key observation is that the pre-PINT implementations, being developed independently, do not inter-operate. It is a task of the PINT Working Group to define the inter-networking interfaces that will support inter-operation of the future implementations of PINT services.

2848 The PINT Service Protocol:Extensions to SIP and SDP for IP Access to Telephone Call Services

This RFC contains the specification of the PINT Service Protocol 1.0, which defines a protocol for invoking certain telephone services from an IP network. These services include placing basic calls, sending and receiving faxes, and receiving content over the telephone. The protocol is specified as a set of enhancements and additions to the SIP 2.0 and SDP protocols.

3055 Management Information Base for the PINT Services Architecture

This memo describes a proposed Management Information Base (MIB) for the PSTN/Internet Interworking (PINT) Services Architecture.

[Up]

Key RFCs created by The ROHC Working Group

Only the 4 main RFCs are shown below. You can see all other RFCs here.

RFC#  Name Description (abstract)
3096 Requirements for robust IP/UDP/RTP header compression 

This RFC contains requirements for robust IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression to be developed by the ROHC (Robust Header Compression) WG. It is based on the ROHC charter, discussions in the WG, the 3GPP document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as contributions from 3G.IP.

3320 (updated by RFC 4896) Signaling Compression - updated by RFC 4896

This RFC defines Signaling Compression (SigComp), a solution for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP) (RFC 3261) and the Real Time Streaming Protocol (RTSP) (RFC 2326). The architecture and prerequisites of SigComp are outlined, along with the format of the SigComp message. Decompression functionality for SigComp is provided by a Universal Decompressor Virtual Machine (UDVM) optimized for the task of running decompression algorithms. The UDVM can be configured to understand the output of many well-known compressors such as DEFLATE (RFC-1951).

3321 (updated by RFC 4896) SigComp - Extended Operations - updated by RFC 4896

This RFC describes how to implement certain mechanisms in Signaling Compression (SigComp), RFC 3320, which can significantly improve the compression efficiency compared to using simple per-message compression. SigComp uses a Universal Decompressor Virtual Machine (UDVM) for decompression, and the mechanisms described in this document are possible to implement using the UDVM instructions defined in RFC 3320.

4896 Signaling Compression (SigComp) Corrections and Clarifications

This RFC describes common misinterpretations and some ambiguities in the Signaling Compression Protocol (SigComp), and offers guidance to developers to resolve any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This RFC updates the following RFCs: RFC 3320, RFC 3321, and RFC 3485.

[Up]

ALL RFCs created by The XCON Working Group
RFC#  Name Description (abstract)
4376 Requirements for Floor Control Protocols

Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This RFC defines the requirements for a floor control protocol for multiparty conferences in the context of an existing framework.

4597 Conferencing Scenarios

This RFC describes multimedia conferencing scenarios. It describes both basic and advanced conferencing scenarios involving voice, video, text, and interactive text sessions. These scenarios will help with the definition and evaluation of the protocols being developed in the centralized conferencing XCON working group.

4582 The Binary Floor Control Protocol (BFCP)

Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.
This RFC specifies the Binary Floor Control Protocol (BFCP).BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers.

5018 Connection Establishment in the Binary Floor Control Protocol (BFCP)
 

This RFC specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS).

5239 A Framework for Centralized Conferencing
 

This RFC defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISDN User Part (ISUP), to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems.

[Up]

ALL RFCs created by The ECRIT Working Group
RFC#  Name Description (abstract)
5012 Requirements for Emergency Context Resolution with
Internet Technologies

This RFC defines terminology and enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end to end.

5031 A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services

The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows well-known context-dependent services that can be resolved in a distributed manner to be identified. Examples include emergency services, directory assistance, and call-before-you-dig hot lines.

5069 Security Threats and Requirements for
Emergency Call Marking and Mapping

This RFC reviews the security threats associated with the marking of signalling messages to indicate that they are related to an emergency, and with the process of mapping locations to Universal Resource Identifiers (URIs) that point to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network. Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls.

5222 LoST: A Location-to-Service Translation Protocol

This RFC describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location- appropriate Public Safety Answering Point (PSAP) for emergency services.

5223 Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)

The Location-to-Service Translation (LoST) Protocol describes an XML-based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators(URLs). LoST servers can be located anywhere, but a placement closer to the end host, e.g., in the access network, is desirable. In disaster situations with intermittent network connectivity, such a LoST server placement provides benefits regarding the resiliency of emergency service communication.
This RFC describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP).

5582 Location-to-URL Mapping Architecture and Framework

It is often desirable to allow users to access a service that provides a common function but that is actually offered by a variety of local service providers. In many of these cases, the service provider chosen depends on the location of the person wishing to access that service. Among the best-known public services of this kind is emergency calling, where emergency calls are routed to the most appropriate public safety answering point (PSAP) based on the caller's physical location. Other services, from food delivery to directory services and roadside assistance, also follow this general pattern. This is a mapping problem [RFC5012], where a geographic location and a service identifier [RFC5031] is translated into a set of URIs, the service URIs, that allow the Internet system to contact an appropriate network entity that provides the service.

[Up]

ALL RFCs created by The MEDIACTRL Working Group
RFC#  Name Description (abstract)
5167 Media Server Control Protocol Requirements

This RFC addresses the communication between an application server and media server. The current work in IETF working groups shows these logical entities, but it does not address the physical decomposition and the protocol between the entities.
This RFC presents the requirements for a Media Server Control Protocol (MCP) that enables an application server to use a media server. It will address the aspects of announcements, Interactive Voice Response, and conferencing media services.

5552 SIP Interface to VoiceXML Media Services

This RFC describes a SIP interface to VoiceXML media services. Commonly, Application Servers controlling Media Servers use this protocol for pure VoiceXML processing capabilities. This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism.

5567 An Architectural Framework for Media Server Control

This RFC describes an architectural framework for Media Server control.  The primary focus will be to define logical entities that exist within the context of Media Server control, and define the appropriate naming conventions and interactions between them.

[Up]

KEY RFCs created by The MSEC Working Group
RFC#  Name Description (abstract)
3740 The Multicast Group Security Architecture

This RFC provides an overview and rationale of the multicast security architecture used to secure data packets of large multicast groups. The document begins by introducing a Multicast Security Reference Framework, and proceeds to identify the security services that may be part of a secure multicast solution.

[Up]

ALL RFCs created by The P2PSIP Working Group
RFC#  Name Description (abstract)
NO RFCs have yet been generated by this WG

[Up]

ALL RFCs created by The speechsc Working Group
RFC#  Name Description (abstract)
4313 Requirements for Distributed Control of
Automatic Speech Recognition (ASR),
Speaker Identification/Speaker Verification (SI/SV), and
Text-to-Speech (TTS) Resources

This RFC outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition -- which includes both speaker identification (SI) and speaker verification (SV) -- and text-to-speech (TTS). Other IETF protocols, such as SIP and Real Time Streaming Protocol (RTSP), address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address.

[Up]

KEY RFCs created by The VPIM Working Group
RFC#  Name Description (abstract)
3773 High-Level Requirements for Internet Voice Mail

This RFC describes the high-level requirements for Internet Voice Mail (IVM) and establishes a baseline of desired functionality against which proposed MIME profiles for Internet Voice Messaging can be judged. IVM is an extension of the Voice Profile for Internet Mail (VPIM) version 2 designed to support interoperability with desktop clients. Other goals for this version of VPIM include expanded interoperability with unified messaging systems, conformance to Internet standards, and backward compatibility with voice messaging systems currently running in a VPIM enabled environment. This RFC does not include goals that were met fully by VPIM version 2.

3801 Voice Profile for Internet Mail - version 2 (VPIMv2)

This RFC specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. The profile is referred to as the Voice Profile for Internet Mail (VPIM) in this document. These platforms have historically been special-purpose computers and often do not have the same facilities normally associated with a traditional Internet Email-capable computer. As a result, VPIM also specifies additional functionality, as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between conforming systems.
This RFC obsoletes RFC 2421 and describes version 2 of the profile with greater precision. No protocol changes were made in this revision. A list of changes from RFC 2421 are noted in Appendix F. Appendix A summarizes the protocol profiles of this version of VPIM.

4239 Internet Voice Messaging (IVM)

This RFC describes the carriage of voicemail messages over Internet mail as part of a unified messaging infrastructure.
The Internet Voice Messaging (IVM) concept described in this document is not a successor format to VPIM v2 (Voice Profile for Internet Mail Version 2), but rather an alternative specification for a different application.

[Up]

ALL RFCs created by The SPEERMINT Working Group
RFC#  Name Description (abstract)
5344 Presence & Instant Messaging Peering Use Cases

This RFC describes several use cases of peering of non-VoIP (Voice over IP) services between two or more Service Providers. These Service Providers create a peering relationship between themselves, thus enabling their users to collaborate with users on the other Service Provider network. The target of this document is to drive requirements for peering between domains that provide the non-VoIP based collaboration services with presence and, in particular, Instant Messaging (IM).

5486 Session Peering for Multimedia Interconnect (SPEERMINT) Terminology

This RFC defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT).

[Up]

© 2003-2010, SIPKnowledge.