SIP RFC 关系图汇总--超全---part3
来源：互联网 发布：远程控制软件排行 编辑：程序博客网 时间：2024/06/11 23:14
SIP RFC 关系图汇总--超全---part3
04/2005
(28 p.)
pdf(v)
pdf(p)S. Donovan
J. RosenbergSIPSession Timers in SIPThis 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. UpStatus:Proposed Standard RFC4032
03/2005
(10 p.)
pdf(p)G. Camarillo
P. KyzivatSIPUpdate to SIP Preconditions FrameworkThis 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. UpStatus:Proposed Standard -- updates: RFC 3312 RFC4079
07/2005
(7 p.)
pdf(p)J. PetersonGEOPRIVA Presence Architecture for the Distribution of GEOPRIV Location ObjectsGEOPRIV 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. UpStatus:Informational RFC4083
05/2005
(36 p.)
pdf(p)M. Garcia-MartinSIPPINGInput 3GPP Release 5 Requirements on SIPThe 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. UpStatus:Informational RFC4091
06/2005
(7 p.)
pdf(p)G. Camarillo
J. RosenbergMMUSICThe Alternative Network Address Types (ANAT) Semantics for SDP Grouping FrameworkThis 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. UpStatus:Proposed Standard RFC4092
06/2005
(6 p.)
pdf(p)G. Camarillo
J. RosenbergSIPUsage of SDP Alternative Network Address Types (ANAT) Semantics in SIPThis 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. UpStatus:Proposed Standard Topp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
06/2005
(19 p.)
pdf(p)G. Camarillo
E. Burger
H. Schulzrinne
A. van WijkSIPPINGTranscoding 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. UpStatus:Informational RFC4119
12/2005
(24 p.)
pdf(p)J. PetersonGEOPRIVA Presence-based GEOPRIV Location Object FormatThis 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. UpStatus: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 NamespaceThis 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. UpStatus:Proposed Standard RFC4123
07/2005
(16 p.)
pdf(p)H. Schulzrinne
C. AgbohSIPSIP-H.323 Interworking RequirementsThis 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. UpStatus:Informational RFC4145
09/2005
(15 p.)
pdf(p)D. Yon
G. CamarilloMMUSICTCP-Based Media Transport in SDPThis 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. UpStatus:Proposed Standard -- updated by RFC4572 RFC4168
10/2005
(10 p.)
pdf(p)J. Rosenberg
H. Schulzrinne
G. CamarilloSIPThe Stream Control Transmission Protocol (SCTP) as a Transport for SIPThis 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 inRFC 3263. UpStatus:Proposed Standard RFC4169
11/2005
(13 p.)
pdf(p)V. Torvinen
J. Arkko
M. NaslundHTTPHTTP Digest Authentication using Authentication and Key Agreement (AKA) Version-2HTTP 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. UpStatus:Informational RFC4189
10/2005
(12 p.)
pdf(p)K. Ono
S. TachimotoSIPPINGRequirements for End-to-Middle Security for SIPA 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. UpStatus:Informational RFC4190
11/2005
(28 p.)
pdf(p)K. Carlberg
I. Brown
C. BeardIEPREPFramework for Supporting Emergency Telecommunications Service (ETS) in IP TelephonyThis 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. UpStatus:Informational Topp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
10/2005
(24 p.)
pdf(p)J. WiljakkaV6OPSAnalysis on IPv6 Transition in 3GPP NetworksThis 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. UpStatus:Informational RFC4235
11/2005
(39 p.)
pdf(p)J. Rosenberg
H. Schulzrinne
R. MahySIPPINGAn INVITE-Initiated Dialog Event Package for SIPThis 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) andsip.rendering (20) , placed into the SIP Media Feature Tag Registration Tree, which is defined inRFC 3840. UpStatus:Proposed Standard RFC4240
12/2005
(24 p.)
pdf(p)
pdf(v)E. Burger
J. Van Dyke
A. SpitzerSIPPINGBasic Network Media Services with SIPIn 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 inRFC 3969: "play ", "content-type ", "delay ", "duration ", "repeat ", "locale ", "param[n] ", and "voicexml ". UpStatus:Informational RFC4244
11/2005
(44 p.)
pdf(p)
pdf(v)M. BarnesSIPAn Extension to SIP for Request History InformationThis 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. UpStatus:Proposed Standard RFC4245
11/2005
(12 p.)
pdf(p)O. Levin
R. EvenSIPPINGHigh-Level Requirements for Tightly Coupled SIP ConferencingThis 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. UpStatus:Informational RFC4282
12/2005
(16 p.)
pdf(p)B. Aboba
M. Beadles
J. Arkko
P. EronenRADEXTNetwork Access IdentifierIn 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. UpStatus:Standards Track Topp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
12/2005
(20 p.)
pdf(p)D. OranSPEECHSCRequirements 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. UpStatus:Informational RFC4317
12/2005
(24 p.)
pdf(p)A. Johnston
R. SparksMMUSICSDP Offer/Answer ExamplesThis 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. UpStatus:Informational See also:RFC 3264RFC4320
01/2006
(7 p.)
pdf(p)R. SparksSIPActions Addressing Identified Issues with the SIP Non-INVITE TransactionThis 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. UpStatus:Proposed Standard -- updates: RFC3261 RFC4321
01/2006
(10 p.)
pdf(p)R. SparksSIPProblems Identified Associated with the SIP Non-INVITE TransactionThis document describes several problems that have been identified with the Session Initiation Protocol's (SIP) non-INVITE transaction. UpStatus:Informational RFC4353
02/2006
(29 p.)
pdf(p)J. RosenbergSIPPINGA Framework for Conferencing with SIPThe 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. UpStatus:Informational RFC4354
01/2006
(21 p.)
pdf(p)M. Garcia-MartinSIPPINGA SIP Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) ServiceThe 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 . UpStatus:Informational RFC4376
02/2006
(14 p.)
pdf(p)P. Koskelainen
J. Ott
H. Schulzrinne
X. WuXCONRequirements for Floor Control ProtocolsFloor 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. UpStatus:Informational Topp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
02/2006
(22 p.)
pdf(p)J. PolkSIPPINGExtending SIP Reason Header for Preemption EventsThis document proposes an IANA Registration extension to the SIPReasonHeader (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-namespaceregistry, with 4 defined cause codes. UpStatus:Proposed Standard RFC4412
02/2006
(36 p.)
pdf(p)H. Schulzrinne
J. PolkSIPCommunications Resource Priority for SIPThis 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. UpStatus:Proposed Standard RFC4453
04/2006
(8 p.)
pdf(p)J. Rosenberg
G. Camarillo
D. WillisSIPPINGRequirements for Consent-Based Communications in SIPThe 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. UpStatus:Informational RFC4457
04/2006
(8 p.)
pdf(p)G. Camarillo
G. BlancoSIPPINGThe 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. UpStatus:Informational RFC4458
04/2006
(21 p.)
pdf(p)C. Jennings
F. Audet
J. ElwellSIPSIP 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 inRFC 3969. UpStatus: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 SpeechworksThe 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). UpStatus:Informational RFC4474
08/2006
(41 p.)
pdf(p)J. Peterson
C. JenningsSIPEnhancements for Authenticated Identity Management in SIPThe 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 and438 Invalid Identity Header . This RFC also defines two new sub-registries labeled "Identity-Info Parameters " and "Identity-Info Algorithm Parameter Values " underhttp://www.iana.org/assignments/sip-parameters. UpStatus:Proposed Standard RFC4475
05/2006
(53 p.)
pdf(p)R. Sparks
A. Hawrylyshen
A. Johnston
J. Rosenberg
H. SchulzrinneSIPPINGSIP Torture Test MessagesThis informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" a SIP implementation. UpStatus:Informational RFC4479
07/2006
(35 p.)
pdf(p)J. RosenbergSIMPLEA Data Model for PresenceThis 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. UpStatus:Proposed Standard RFC4480
07/2006
(37 p.)
pdf(p)H. Schulzrinne
V. Gurbani
P. Kyzivat
J. RosenbergSIMPLERPID: 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. UpStatus:Proposed Standard RFC4481
07/2006
(9 p.)
pdf(p)H. SchulzrinneSIMPLETimed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time IntervalsThe 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 (<timed-status> element) that allows a presentity to declare its status for a time interval fully in the future or the past. UpStatus:Proposed Standard RFC4482
07/2006
(11 p.)
pdf(p)H. SchulzrinneSIMPLECIPID: Contact Information for the Presence Information Data FormatThe 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. UpStatus:Proposed Standard RFC4483
05/2006
(17 p.)
pdf(p)E. BurgerSIPA Mechanism for Content Indirection in SIP MessagesThis 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. UpStatus:Proposed Standard RFC4484
08/2006
(15 p.)
pdf(p)J. Peterson
J. Polk
D. Sicker
H. TschofenigSIPPINGTrait-Based Authorization Requirements for SIPThis 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. UpStatus:Informational RFC4485
05/2006
(23 p.)
pdf(p)J. Rosenberg
H. SchulzrinneSIPGuidelines for Authors of Extensions to SIPThe 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. UpStatus:Informational RFC4488
05/2006
(8 p.)
pdf(p)O. LevinSIPSuppression of SIP REFER Method Implicit SubscriptionThe Session Initiation Protocol (SIP) REFER extension as defined inRFC 3515automatically 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'. UpStatus:Proposed Standard RFC4497
05/2006
(65 p.)
pdf(p)J. Elwell
F. Derks
P. Mourot
O. RousseauSIPPINGInterworking between SIP and QSIGThis 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. UpStatus:Best Current Practice (BCP: 117)
Topp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 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 SDPRFC402804/2005
(28 p.)
pdf(v)
pdf(p)S. Donovan
J. RosenbergSIPSession Timers in SIPThis 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. UpStatus:Proposed Standard RFC4032
03/2005
(10 p.)
pdf(p)G. Camarillo
P. KyzivatSIPUpdate to SIP Preconditions FrameworkThis 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. UpStatus:Proposed Standard -- updates: RFC 3312 RFC4079
07/2005
(7 p.)
pdf(p)J. PetersonGEOPRIVA Presence Architecture for the Distribution of GEOPRIV Location ObjectsGEOPRIV 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. UpStatus:Informational RFC4083
05/2005
(36 p.)
pdf(p)M. Garcia-MartinSIPPINGInput 3GPP Release 5 Requirements on SIPThe 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. UpStatus:Informational RFC4091
06/2005
(7 p.)
pdf(p)G. Camarillo
J. RosenbergMMUSICThe Alternative Network Address Types (ANAT) Semantics for SDP Grouping FrameworkThis 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. UpStatus:Proposed Standard RFC4092
06/2005
(6 p.)
pdf(p)G. Camarillo
J. RosenbergSIPUsage of SDP Alternative Network Address Types (ANAT) Semantics in SIPThis 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. UpStatus:Proposed Standard Topp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 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 TelephonyRFC411706/2005
(19 p.)
pdf(p)G. Camarillo
E. Burger
H. Schulzrinne
A. van WijkSIPPINGTranscoding 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. UpStatus:Informational RFC4119
12/2005
(24 p.)
pdf(p)J. PetersonGEOPRIVA Presence-based GEOPRIV Location Object FormatThis 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. UpStatus: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 NamespaceThis 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. UpStatus:Proposed Standard RFC4123
07/2005
(16 p.)
pdf(p)H. Schulzrinne
C. AgbohSIPSIP-H.323 Interworking RequirementsThis 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. UpStatus:Informational RFC4145
09/2005
(15 p.)
pdf(p)D. Yon
G. CamarilloMMUSICTCP-Based Media Transport in SDPThis 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. UpStatus:Proposed Standard -- updated by RFC4572 RFC4168
10/2005
(10 p.)
pdf(p)J. Rosenberg
H. Schulzrinne
G. CamarilloSIPThe Stream Control Transmission Protocol (SCTP) as a Transport for SIPThis 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 inRFC 3263. UpStatus:Proposed Standard RFC4169
11/2005
(13 p.)
pdf(p)V. Torvinen
J. Arkko
M. NaslundHTTPHTTP Digest Authentication using Authentication and Key Agreement (AKA) Version-2HTTP 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. UpStatus:Informational RFC4189
10/2005
(12 p.)
pdf(p)K. Ono
S. TachimotoSIPPINGRequirements for End-to-Middle Security for SIPA 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. UpStatus:Informational RFC4190
11/2005
(28 p.)
pdf(p)K. Carlberg
I. Brown
C. BeardIEPREPFramework for Supporting Emergency Telecommunications Service (ETS) in IP TelephonyThis 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. UpStatus:Informational Topp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 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 IdentifierRFC421510/2005
(24 p.)
pdf(p)J. WiljakkaV6OPSAnalysis on IPv6 Transition in 3GPP NetworksThis 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. UpStatus:Informational RFC4235
11/2005
(39 p.)
pdf(p)J. Rosenberg
H. Schulzrinne
R. MahySIPPINGAn INVITE-Initiated Dialog Event Package for SIPThis 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) andsip.rendering (20) , placed into the SIP Media Feature Tag Registration Tree, which is defined inRFC 3840. UpStatus:Proposed Standard RFC4240
12/2005
(24 p.)
pdf(p)
pdf(v)E. Burger
J. Van Dyke
A. SpitzerSIPPINGBasic Network Media Services with SIPIn 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 inRFC 3969: "play ", "content-type ", "delay ", "duration ", "repeat ", "locale ", "param[n] ", and "voicexml ". UpStatus:Informational RFC4244
11/2005
(44 p.)
pdf(p)
pdf(v)M. BarnesSIPAn Extension to SIP for Request History InformationThis 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. UpStatus:Proposed Standard RFC4245
11/2005
(12 p.)
pdf(p)O. Levin
R. EvenSIPPINGHigh-Level Requirements for Tightly Coupled SIP ConferencingThis 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. UpStatus:Informational RFC4282
12/2005
(16 p.)
pdf(p)B. Aboba
M. Beadles
J. Arkko
P. EronenRADEXTNetwork Access IdentifierIn 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. UpStatus:Standards Track Topp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 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 RequirementsRFC431312/2005
(20 p.)
pdf(p)D. OranSPEECHSCRequirements 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. UpStatus:Informational RFC4317
12/2005
(24 p.)
pdf(p)A. Johnston
R. SparksMMUSICSDP Offer/Answer ExamplesThis 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. UpStatus:Informational See also:RFC 3264RFC4320
01/2006
(7 p.)
pdf(p)R. SparksSIPActions Addressing Identified Issues with the SIP Non-INVITE TransactionThis 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. UpStatus:Proposed Standard -- updates: RFC3261 RFC4321
01/2006
(10 p.)
pdf(p)R. SparksSIPProblems Identified Associated with the SIP Non-INVITE TransactionThis document describes several problems that have been identified with the Session Initiation Protocol's (SIP) non-INVITE transaction. UpStatus:Informational RFC4353
02/2006
(29 p.)
pdf(p)J. RosenbergSIPPINGA Framework for Conferencing with SIPThe 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. UpStatus:Informational RFC4354
01/2006
(21 p.)
pdf(p)M. Garcia-MartinSIPPINGA SIP Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) ServiceThe 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 . UpStatus:Informational RFC4376
02/2006
(14 p.)
pdf(p)P. Koskelainen
J. Ott
H. Schulzrinne
X. WuXCONRequirements for Floor Control ProtocolsFloor 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. UpStatus:Informational Topp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 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 QSIGRFC441102/2006
(22 p.)
pdf(p)J. PolkSIPPINGExtending SIP Reason Header for Preemption EventsThis document proposes an IANA Registration extension to the SIPReasonHeader (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-namespaceregistry, with 4 defined cause codes. UpStatus:Proposed Standard RFC4412
02/2006
(36 p.)
pdf(p)H. Schulzrinne
J. PolkSIPCommunications Resource Priority for SIPThis 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. UpStatus:Proposed Standard RFC4453
04/2006
(8 p.)
pdf(p)J. Rosenberg
G. Camarillo
D. WillisSIPPINGRequirements for Consent-Based Communications in SIPThe 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. UpStatus:Informational RFC4457
04/2006
(8 p.)
pdf(p)G. Camarillo
G. BlancoSIPPINGThe 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. UpStatus:Informational RFC4458
04/2006
(21 p.)
pdf(p)C. Jennings
F. Audet
J. ElwellSIPSIP 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 inRFC 3969. UpStatus: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 SpeechworksThe 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). UpStatus:Informational RFC4474
08/2006
(41 p.)
pdf(p)J. Peterson
C. JenningsSIPEnhancements for Authenticated Identity Management in SIPThe 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 and438 Invalid Identity Header . This RFC also defines two new sub-registries labeled "Identity-Info Parameters " and "Identity-Info Algorithm Parameter Values " underhttp://www.iana.org/assignments/sip-parameters. UpStatus:Proposed Standard RFC4475
05/2006
(53 p.)
pdf(p)R. Sparks
A. Hawrylyshen
A. Johnston
J. Rosenberg
H. SchulzrinneSIPPINGSIP Torture Test MessagesThis informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" a SIP implementation. UpStatus:Informational RFC4479
07/2006
(35 p.)
pdf(p)J. RosenbergSIMPLEA Data Model for PresenceThis 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. UpStatus:Proposed Standard RFC4480
07/2006
(37 p.)
pdf(p)H. Schulzrinne
V. Gurbani
P. Kyzivat
J. RosenbergSIMPLERPID: 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. UpStatus:Proposed Standard RFC4481
07/2006
(9 p.)
pdf(p)H. SchulzrinneSIMPLETimed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time IntervalsThe 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 (<timed-status> element) that allows a presentity to declare its status for a time interval fully in the future or the past. UpStatus:Proposed Standard RFC4482
07/2006
(11 p.)
pdf(p)H. SchulzrinneSIMPLECIPID: Contact Information for the Presence Information Data FormatThe 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. UpStatus:Proposed Standard RFC4483
05/2006
(17 p.)
pdf(p)E. BurgerSIPA Mechanism for Content Indirection in SIP MessagesThis 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. UpStatus:Proposed Standard RFC4484
08/2006
(15 p.)
pdf(p)J. Peterson
J. Polk
D. Sicker
H. TschofenigSIPPINGTrait-Based Authorization Requirements for SIPThis 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. UpStatus:Informational RFC4485
05/2006
(23 p.)
pdf(p)J. Rosenberg
H. SchulzrinneSIPGuidelines for Authors of Extensions to SIPThe 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. UpStatus:Informational RFC4488
05/2006
(8 p.)
pdf(p)O. LevinSIPSuppression of SIP REFER Method Implicit SubscriptionThe Session Initiation Protocol (SIP) REFER extension as defined inRFC 3515automatically 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'. UpStatus:Proposed Standard RFC4497
05/2006
(65 p.)
pdf(p)J. Elwell
F. Derks
P. Mourot
O. RousseauSIPPINGInterworking between SIP and QSIGThis 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. UpStatus:Best Current Practice (BCP: 117)
