SIP RFC 关系图汇总--超全---part3

SIP RFC 关系图汇总--超全---part3

Top p. 1 3261-32xx 33xx 34xx 35xx 36xx 37xx 38xx 39xx   Prev Next 40xx 41xx 42xx 43xx 44xx 45xx 46xx 47xx       48xx 49xx 50xx 51xx 52xx 53xx 54xx 55xx       56xx 57xx 58xx 59xx 60xx 61xx 62xx Before 3261       40xx # RFC 4028 Session Timers in SIP # RFC 4032 Update to SIP Preconditions Framework # RFC 4079 A Presence Architecture for the Distribution of GEOPRIV Location Objects # RFC 4083 Input 3GPP Release 5 Requirements on SIP # RFC 4091 ANAT Semantics for SDP Grouping Framework # RFC 4092 ANAT Usage in SDP RFC4028 04/2005 (28 p.) pdf(v) pdf(p) S. Donovan J. Rosenberg SIP Session Timers in SIP This document defines an extension to 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. This document defines the 'timer ' SIP option tag and the 422 Session Interval Too Small response code.   Up Status: Proposed Standard               RFC4032 03/2005 (10 p.) pdf(p) G. Camarillo P. Kyzivat SIP Update to SIP Preconditions Framework This document updates RFC 3312 , which defines the framework for preconditions in SIP. It provides guidelines for authors of new precondition types and describes how to use SIP preconditions in situations that involve session mobility.   Up Status: Proposed Standard -- updates: RFC 3312 RFC4079 07/2005 (7 p.) pdf(p) J. Peterson GEOPRIV A Presence Architecture for the Distribution of GEOPRIV Location Objects GEOPRIV defines the concept of a 'using protocol' -- a protocol that carries GEOPRIV location objects. GEOPRIV also defines various scenarios for the distribution of location objects that require the concepts of subscriptions and asynchronous notifications. This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto GEOPRIV architectures, and moreover demonstrates that tools already developed for presence could be reused to simplify the standardization and implementation of GEOPRIV.   Up Status: Informational               RFC4083 05/2005 (36 p.) pdf(p) M. Garcia-Martin SIPPING Input 3GPP Release 5 Requirements on SIP The 3rd-Generation Partnership Project (3GPP) has selected 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 document, we express the requirements identified by 3GPP to support SIP for Release 5 of the 3GPP IMS in cellular networks.   Up Status: Informational               RFC4091 06/2005 (7 p.) pdf(p) G. Camarillo J. Rosenberg MMUSIC The Alternative Network Address Types (ANAT) Semantics for SDP Grouping Framework This document defines the Alternative Network Address Types (ANAT) semantics for SDP grouping framework. The ANAT semantics allow alternative types of network addresses to establish a particular media stream.   Up Status: Proposed Standard               RFC4092 06/2005 (6 p.) pdf(p) G. Camarillo J. Rosenberg SIP Usage of SDP Alternative Network Address Types (ANAT) Semantics in SIP This document describes how to use the Alternative Network Address Types (ANAT) semantics of 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.   Up Status: Proposed Standard             Top p. 1 3261-32xx 33xx 34xx 35xx 36xx 37xx 38xx 39xx   Prev Next 40xx 41xx 42xx 43xx 44xx 45xx 46xx 47xx       48xx 49xx 50xx 51xx 52xx 53xx 54xx 55xx       56xx 57xx 58xx 59xx 60xx 61xx 62xx Before 3261       41xx # RFC 4117 3pcc Transcoding in SIP # RFC 4119 Presence-based GEOPRIV Location Object Format # RFC 4122 Universally Unique IDentifier (UUID) URN Namespace # RFC 4123 SIP-H.323 Interworking Requirements # RFC 4145 TCP-Based Media Transport in SDP # RFC 4168 SCTP as a Transport for SIP # RFC 4169 HTTP Digest AKAv2 # RFC 4189 Requirements for End-to-Middle Security for SIP # RFC 4190 Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony RFC4117 06/2005 (19 p.) pdf(p) G. Camarillo E. Burger H. Schulzrinne A. van Wijk SIPPING Transcoding Services Invocation in SIP using Third Party Call Control (3pcc) This document describes how to invoke transcoding services using 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.   Up Status: Informational               RFC4119 12/2005 (24 p.) pdf(p) J. Peterson GEOPRIV A Presence-based GEOPRIV Location Object Format This document describes an object format for carrying geographical information on the Internet. This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties.   Up Status: Proposed Standard -- Updated by: RFC 5139 RFC4122 07/2005 (32 p.) pdf(p) P. Leach M. Mealling R. Salz - A Universally Unique IDentifier (UUID) URN Namespace This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation's (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document.   Up Status: Proposed Standard               RFC4123 07/2005 (16 p.) pdf(p) H. Schulzrinne C. Agboh SIP SIP-H.323 Interworking Requirements This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between SIP and H.323.   Up Status: Informational               RFC4145 09/2005 (15 p.) pdf(p) D. Yon G. Camarillo MMUSIC TCP-Based Media Transport in SDP This document describes how to express media transport over TCP using SDP. It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment.   Up Status: Proposed Standard -- updated by RFC4572 RFC4168 10/2005 (10 p.) pdf(p) J. Rosenberg H. Schulzrinne G. Camarillo SIP The Stream Control Transmission Protocol (SCTP) as a Transport for SIP This document 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. This RFC adds the SIPS+D2S NAPTR service field value to the registry defined in RFC 3263 .   Up Status: Proposed Standard               RFC4169 11/2005 (13 p.) pdf(p) V. Torvinen J. Arkko M. Naslund HTTP HTTP Digest Authentication using Authentication and Key Agreement (AKA) Version-2 HTTP Digest, as specified in RFC 2617 , is known to be vulnerable to man-in-the-middle attacks if the client fails to authenticate the server in TLS, or if the same passwords are used for authentication in some other context without TLS. This is a general problem that exists not just with HTTP Digest, but also with other IETF protocols that use tunneled authentication. This document specifies version 2 of the HTTP Digest AKA algorithm (RFC 3310 ). This algorithm can be implemented in a way that it is resistant to the man-in-the-middle attack.   Up Status: Informational               RFC4189 10/2005 (12 p.) pdf(p) K. Ono S. Tachimoto SIPPING Requirements for End-to-Middle Security for 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 document defines a set of requirements for a mechanism to achieve end-to-middle security.   Up Status: Informational               RFC4190 11/2005 (28 p.) pdf(p) K. Carlberg I. Brown C. Beard IEPREP Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with the Emergency Telecommunications Service (ETS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space.   Up Status: Informational             Top p. 1 3261-32xx 33xx 34xx 35xx 36xx 37xx 38xx 39xx   Prev Next 40xx 41xx 42xx 43xx 44xx 45xx 46xx 47xx       48xx 49xx 50xx 51xx 52xx 53xx 54xx 55xx       56xx 57xx 58xx 59xx 60xx 61xx 62xx Before 3261       42xx # RFC 4215 IPv6 Transition in 3GPP Networks # RFC 4235 INVITE-Initiated Dialog Event Package for SIP # RFC 4240 Basic Network Media Services with SIP # RFC 4244 SIP Request History Information # RFC 4245 High-Level Requirements for Tightly Coupled SIP Conferencing # RFC 4282 Network Access Identifier RFC4215 10/2005 (24 p.) pdf(p) J. Wiljakka V6OPS Analysis on IPv6 Transition in 3GPP Networks This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications System (UMTS)/Wideband Code Division Multiple Access (WCDMA) technology. The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed.   Up Status: Informational               RFC4235 11/2005 (39 p.) pdf(p) J. Rosenberg H. Schulzrinne R. Mahy SIPPING An INVITE-Initiated Dialog Event Package for SIP This document defines the '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. This RFC registers a new MIME type, application/ dialog-info+xml . It also registers two new Media feature tags, sip.byeless (19) and sip.rendering (20) , placed into the SIP Media Feature Tag Registration Tree, which is defined in RFC 3840 .   Up Status: Proposed Standard               RFC4240 12/2005 (24 p.) pdf(p) pdf(v) E. Burger J. Van Dyke A. Spitzer SIPPING Basic Network Media Services with SIP In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner. This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks. This specification adds new values to the IANA registration in the "SIP/SIPS URI Parameters " registry as defined in RFC 3969 : "play ", "content-type ", "delay ", "duration ", "repeat ", "locale ", "param[n] ", and "voicexml ".   Up Status: Informational               RFC4244 11/2005 (44 p.) pdf(p) pdf(v) M. Barnes SIP An Extension to SIP for Request History Information This document 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 document defines a new optional SIP header, "History-Info ", for capturing the history information in requests. This specification defines the 'histinfo ' SIP option tag.   Up Status: Proposed Standard               RFC4245 11/2005 (12 p.) pdf(p) O. Levin R. Even SIPPING High-Level Requirements for Tightly Coupled SIP Conferencing This document examines a wide range of conferencing requirements for tightly coupled SIP conferences. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guide for building interoperable SIP conferencing applications.   Up Status: Informational               RFC4282 12/2005 (16 p.) pdf(p) B. Aboba M. Beadles J. Arkko P. Eronen RADEXT Network Access Identifier In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and ISP-provided corporate network access support.   Up Status: Standards Track             Top p. 1 3261-32xx 33xx 34xx 35xx 36xx 37xx 38xx 39xx   Prev Next 40xx 41xx 42xx 43xx 44xx 45xx 46xx 47xx       48xx 49xx 50xx 51xx 52xx 53xx 54xx 55xx       56xx 57xx 58xx 59xx 60xx 61xx 62xx Before 3261       43xx # RFC 4313 Speech Services Control Requirements # RFC 4317 SDP Offer/Answer Examples # RFC 4320 SIP Non-INVITE Actions # RFC 4321 SIP Non-INVITE Problems # RFC 4353 Conferencing Framework with SIP # RFC 4354 PoC Settings Event Package # RFC 4376 Floor Control Protocol Requirements RFC4313 12/2005 (20 p.) pdf(p) D. Oran SPEECHSC Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification / Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources This document 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 Status: Informational               RFC4317 12/2005 (24 p.) pdf(p) A. Johnston R. Sparks MMUSIC SDP Offer/Answer Examples This document gives examples of Session Description Protocol (SDP) offer/answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams, and dynamic payload types. Common Third Party Call Control (3pcc) examples are also given.   Up Status: Informational   See also: RFC 3264 RFC4320 01/2006 (7 p.) pdf(p) R. Sparks SIP Actions Addressing Identified Issues with the SIP Non-INVITE Transaction This document 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.   Up Status: Proposed Standard -- updates: RFC3261 RFC4321 01/2006 (10 p.) pdf(p) R. Sparks SIP Problems Identified Associated with the SIP Non-INVITE Transaction This document describes several problems that have been identified with the Session Initiation Protocol's (SIP) non-INVITE transaction.   Up Status: Informational               RFC4353 02/2006 (29 p.) pdf(p) J. Rosenberg SIPPING A Framework for Conferencing with 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 document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi-party conferencing.   Up Status: Informational               RFC4354 01/2006 (21 p.) pdf(p) M. Garcia-Martin SIPPING A SIP Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service The Open Mobile Alliance (OMA) is defining the Push-to-talk over Cellular (PoC) service where SIP is the protocol used to establish half-duplex media sessions across different participants, to send instant messages, etc. This document defines the 'poc-settings ' SIP event package to support publication, subscription, and notification of additional capabilities required by the PoC service. This SIP event package is applicable to the PoC service and may not be applicable to the general Internet. This document registers a new MIME type, application/ poc-settings+xml .   Up Status: Informational               RFC4376 02/2006 (14 p.) pdf(p) P. Koskelainen J. Ott H. Schulzrinne X. Wu XCON 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 document defines the requirements for a floor control protocol for multiparty conferences in the context of an existing framework.   Up Status: Informational         Top p. 1 3261-32xx 33xx 34xx 35xx 36xx 37xx 38xx 39xx   Prev Next 40xx 41xx 42xx 43xx 44xx 45xx 46xx 47xx       48xx 49xx 50xx 51xx 52xx 53xx 54xx 55xx       56xx 57xx 58xx 59xx 60xx 61xx 62xx Before 3261       44xx # RFC 4411 SIP Reason Header for Preemption Events # RFC 4412 SIP Resource Priority # RFC 4453 Requirements for Consent-Based Communications in SIP # RFC 4457 SIP P-User-Database Private-Header # RFC 4458 SIP Voicemail URI # RFC 4463 MRCP by Cisco, Nuance, and Speechworks # RFC 4474 Enhancements for Authenticated Identity Management in SIP # RFC 4475 SIP Torture Test Messages # RFC 4479 Presence Data Model # RFC 4480 RPID: Rich Presence Extensions to PIDF # RFC 4481 Timed Presence Extensions to PIDF # RFC 4482 CIPID: Contact Information for PIDF # RFC 4483 Content Indirection in SIP Messages # RFC 4484 Trait-Based Authorization Requirements for SIP # RFC 4485 Guidelines for Authors of Extensions to SIP # RFC 4488 Suppression of SIP REFER Method Implicit Subscription # RFC 4497 Interworking between SIP and QSIG RFC4411 02/2006 (22 p.) pdf(p) J. Polk SIPPING Extending SIP Reason Header for Preemption Events This document proposes an IANA Registration extension to the SIP Reason Header (RFC 3326 ) 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 document 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. This RFC defines a new protocol value: Preemption to the "Reason Protocols " sub-registry. It also defines the http://www.iana.org/assignments/preemption-namespace registry, with 4 defined cause codes.   Up Status: Proposed Standard               RFC4412 02/2006 (36 p.) pdf(p) H. Schulzrinne J. Polk SIP Communications Resource Priority for SIP This document defines two new 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. This document defines the 'resource-priority ' SIP option tag and the 417 Unknown Resource-Priority Response Code. This RFC defines two new sub-registries labeled "Resource-Priority Namespaces ", and "Resource-Priority Priority-values " under http://www.iana.org/assignments/sip-parameters .   Up Status: Proposed Standard               RFC4453 04/2006 (8 p.) pdf(p) J. Rosenberg G. Camarillo D. Willis SIPPING Requirements for Consent-Based Communications in 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 document identifies a set of requirements for extensions to SIP that add consent-based communications.   Up Status: Informational               RFC4457 04/2006 (8 p.) pdf(p) G. Camarillo G. Blanco SIPPING The SIP P-User-Database Private-Header (P-Header) This document specifies the SIP "P-User-Database " Private-Header (P-header). This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the address of the database that contains the user profile of the user that generated a particular request.   Up Status: Informational               RFC4458 04/2006 (21 p.) pdf(p) C. Jennings F. Audet J. Elwell SIP SIP URIs for Applications such as Voicemail and Interactive Voice Response (IVR) The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems. This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications. This specification adds two new values ("target " and "cause ") to the IANA registration in the "SIP/SIPS URI Parameters " registry as defined in RFC 3969 .   Up Status: Informational               RFC4463 04/2006 (86 p.) pdf(p) S. Shanmugham P. Monaco B. Eberman - A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks The Session Initiation Protocol (SIP) is often used to initiate This document describes a Media Resource Control Protocol (MRCP) that was developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks, Inc. It is published as an RFC as input for further IETF development in this area. MRCP controls media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers, etc., over a network. This protocol is designed to work with streaming protocols like RTSP (Real Time Streaming Protocol) or SIP (Session Initiation Protocol), which help establish control connections to external media streaming devices, and media delivery mechanisms like RTP (Real Time Protocol).   Up Status: Informational               RFC4474 08/2006 (41 p.) pdf(p) J. Peterson C. Jennings SIP Enhancements for Authenticated Identity Management in 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 document 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. This RFC defines the following Response Codes: 428 Use Identity Header , 436 Bad Identity-Info , 437 Unsupported Certificate and 438 Invalid Identity Header . This RFC also defines two new sub-registries labeled "Identity-Info Parameters " and "Identity-Info Algorithm Parameter Values " under http://www.iana.org/assignments/sip-parameters .   Up Status: Proposed Standard               RFC4475 05/2006 (53 p.) pdf(p) R. Sparks A. Hawrylyshen A. Johnston J. Rosenberg H. Schulzrinne SIPPING SIP Torture Test Messages This informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" a SIP implementation.   Up Status: Informational               RFC4479 07/2006 (35 p.) pdf(p) J. Rosenberg SIMPLE A Data Model for Presence This document 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.   Up Status: Proposed Standard               RFC4480 07/2006 (37 p.) pdf(p) H. Schulzrinne V. Gurbani P. Kyzivat J. Rosenberg SIMPLE 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.   Up Status: Proposed Standard               RFC4481 07/2006 (9 p.) pdf(p) H. Schulzrinne SIMPLE 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 document extends PIDF, adding a timed status extension ( element) that allows a presentity to declare its status for a time interval fully in the future or the past.   Up Status: Proposed Standard               RFC4482 07/2006 (11 p.) pdf(p) H. Schulzrinne SIMPLE CIPID: Contact Information for the 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.   Up Status: Proposed Standard               RFC4483 05/2006 (17 p.) pdf(p) E. Burger SIP A Mechanism for Content Indirection in SIP Messages This document 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.   Up Status: Proposed Standard               RFC4484 08/2006 (15 p.) pdf(p) J. Peterson J. Polk D. Sicker H. Tschofenig SIPPING Trait-Based Authorization Requirements for SIP This document 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.   Up Status: Informational               RFC4485 05/2006 (23 p.) pdf(p) J. Rosenberg H. Schulzrinne SIP Guidelines for Authors of Extensions to 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 document outlines a set of such guidelines for authors of SIP extensions.   Up Status: Informational               RFC4488 05/2006 (8 p.) pdf(p) O. Levin SIP Suppression of 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 "Refer-Sub ", header field that may be included in a REFER request. This document also registers a new SIP option tag: 'norefersub '.   Up Status: Proposed Standard               RFC4497 05/2006 (65 p.) pdf(p) J. Elwell F. Derks P. Mourot O. Rousseau SIPPING Interworking between SIP and QSIG This document 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.   Up Status: Best Current Practice (BCP: 117)