SIP RFC 关系图汇总--超全---part3
来源：互联网 发布：夏普网络打印机连接 编辑：程序博客网 时间：2024/06/04 17:47
SIP RFC 关系图汇总--超全---part3
04/2005
(28 p.)
pdf(v)
pdf(p) S. Donovan
J. RosenbergSIPSession Timers in SIPThis document defines an extension to SIP. Thisextension allows for a periodic refresh of SIP sessions through are-INVITE or UPDATE request. The refresh allows both user agents andproxies to determine whether the SIP session is still active. Theextension 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 StandardRFC4032
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 providesguidelines for authors of new precondition types and describes how touse SIP preconditions in situations that involve session mobility. UpStatus:Proposed Standard -- updates: RFC 3312RFC4079
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 definesvarious scenarios for the distribution of location objects that requirethe concepts of subscriptions and asynchronous notifications. Thisdocument examines some existing IETF work on the concept of presence,shows how presence architectures map onto GEOPRIV architectures, andmoreover demonstrates that tools already developed for presence couldbe reused to simplify the standardization and implementation ofGEOPRIV. UpStatus:InformationalRFC4083
05/2005
(36 p.)
pdf(p) M. Garcia-MartinSIPPINGInput 3GPP Release 5 Requirements on SIPThe 3rd-Generation Partnership Project (3GPP) hasselected SIP as the session establishment protocol for the 3GPP IPMultimedia Core Network Subsystem (IMS). IMS is part of Release 5 ofthe 3GPP specifications. Although SIP is a protocol that fulfills mostof the requirements for establishing a session in an IP network, SIPhas never been evaluated against the specific 3GPP requirements foroperation in a cellular network. In this document, we express therequirements identified by 3GPP to support SIP for Release 5 of the3GPP IMS in cellular networks. UpStatus:InformationalRFC4091
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 AddressTypes (ANAT) semantics for SDP grouping framework. The ANAT semanticsallow alternative types of network addresses to establish a particularmedia stream. UpStatus:Proposed StandardRFC4092
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 AlternativeNetwork Address Types (ANAT) semantics of SDP grouping framework inSIP. In particular, we define the 'sdp-anat'SIP option tag. This SIP option-tag ensures that SDP sessiondescriptions that use ANAT are only handled by SIP entities with ANATsupport. To justify the need for such a SIP option-tag, we describewhat could possibly happen if an ANAT-unaware SIP entity tried tohandle media lines grouped with ANAT. UpStatus:Proposed StandardTopp. 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 transcodingservices using SIP and third party call control. This way of invocationmeets the requirements for SIP regarding transcoding servicesinvocation to support deaf, hard of hearing and speech-impairedindividuals. UpStatus:InformationalRFC4119
12/2005
(24 p.)
pdf(p) J. PetersonGEOPRIVA Presence-based GEOPRIV Location Object FormatThis document describes an object format for carryinggeographical information on the Internet. This location object extendsthe Presence Information Data Format (PIDF), which was designed forcommunicating privacy-sensitive presence information and which hassimilar properties. UpStatus:Proposed Standard -- Updated by: RFC 5139RFC4122
07/2005
(32 p.)
pdf(p) P. Leach
M. Mealling
R. Salz-A Universally Unique IDentifier (UUID) URN NamespaceThis specification defines a Uniform Resource Namenamespace for UUIDs (Universally Unique IDentifier), also known asGUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and canguarantee uniqueness across space and time. UUIDs were originally usedin the Apollo Network Computing System and later in the Open SoftwareFoundation's (OSF) Distributed Computing Environment (DCE), and then inMicrosoft Windows platforms.
This specification is derived fromthe DCE specification with the kind permission of the OSF (now known asThe Open Group). Information from earlier versions of the DCEspecification have been incorporated into this document. UpStatus:Proposed StandardRFC4123
07/2005
(16 p.)
pdf(p) H. Schulzrinne
C. AgbohSIPSIP-H.323 Interworking RequirementsThis document describes the requirements for thelogical entity known as the Session Initiation Protocol (SIP)-H.323Interworking Function (SIP-H.323 IWF) that will allow the interworkingbetween SIP and H.323. UpStatus:InformationalRFC4145
09/2005
(15 p.)
pdf(p) D. Yon
G. CamarilloMMUSICTCP-Based Media Transport in SDPThis document describes how to express mediatransport over TCP using SDP. It defines the SDP 'TCP' protocolidentifier, the SDP 'setup' attribute, which describes the connectionsetup procedure, and the SDP 'connection' attribute, which handlesconnection reestablishment. UpStatus:Proposed Standard -- updated by RFC4572RFC4168
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 mechanismbetween SIP (Session Initiation Protocol) entities. SCTP is a newprotocol that provides several features that may prove beneficial fortransport between SIP entities that exchange a large amount ofmessages, including gateways and proxies. As SIP istransport-independent, support of SCTP is a relatively straightforwardprocess, nearly identical to support for TCP.
This RFC adds the SIPS+D2S NAPTR service field value to the registry defined in RFC 3263. UpStatus:Proposed StandardRFC4169
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 clientfails to authenticate the server in TLS, or if the same passwords areused for authentication in some other context without TLS. This is ageneral problem that exists not just with HTTP Digest, but also withother IETF protocols that use tunneled authentication. This documentspecifies 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:InformationalRFC4189
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 inspectits message bodies and/or headers contained in its message. The UAmight want to protect the message bodies and/or headers fromintermediaries, except those that provide services based on itscontent. This situation requires a mechanism called "end-to-middlesecurity" to secure the information passed between the UA andintermediaries, which does not interfere with end-to-end security. Thisdocument defines a set of requirements for a mechanism to achieveend-to-middle security. UpStatus:InformationalRFC4190
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 supportingauthorized, emergency-related communication within the context of IPtelephony. We present a series of objectives that reflect a generalview of how authorized emergency service, in line with the EmergencyTelecommunications Service (ETS), should be realized within today's IParchitecture and service models. From these objectives, we present acorresponding set of protocols and capabilities, which provide a morespecific set of recommendations regarding existing IETF protocols.Finally, we present two scenarios that act as guiding models for theobjectives and functions listed in this document. These models, coupledwith an example of an existing service in the Public Switched TelephoneNetwork (PSTN), contribute to a constrained solution space. UpStatus:InformationalTopp. 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 inThird Generation Partnership Project (3GPP) packet networks. Thesenetworks are based on General Packet Radio Service (GPRS) technology,and the radio network architecture is based on Global System for MobileCommunications (GSM) or Universal Mobile Telecommunications System(UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.
Thefocus is on analyzing different transition scenarios and applicabletransition mechanisms and finding solutions for those transitionscenarios. In these scenarios, the User Equipment (UE) connects toother nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanismsare needed. UpStatus:InformationalRFC4235
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 formatused in notifications for this package. The dialog package allows usersto subscribe to another user and to receive notification of the changesin state of INVITE-initiated dialog usages in which the subscribed-touser 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. UpStatus:Proposed StandardRFC4240
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 providebasic network media services. Such services include networkannouncements, user interaction, and conferencing services. Theseservices are basic building blocks, from which one can constructinteresting applications. In order to have interoperability betweenservers offering these building blocks (also known as Media Servers)and application developers, one needs to be able to locate and invokesuch services in a well defined manner.
This document describes amechanism for providing an interoperable interface between ApplicationServers, which provide application services to SIP-based networks, andMedia Servers, which provide the basic media processing buildingblocks.
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". UpStatus:InformationalRFC4244
11/2005
(44 p.)
pdf(p)
pdf(v) M. BarnesSIPAn Extension to SIP for Request History InformationThis document defines a standard mechanism forcapturing the history information associated with a Session InitiationProtocol (SIP) request. This capability enables many enhanced servicesby providing the information as to how and why a call arrives at aspecific application or user. This document defines a new optional SIPheader, "History-Info", for capturing the history information in requests.
This specification defines the 'histinfo' SIP option tag. UpStatus:Proposed StandardRFC4245
11/2005
(12 p.)
pdf(p) O. Levin
R. EvenSIPPINGHigh-Level Requirements for Tightly Coupled SIP ConferencingThis document examines a wide range of conferencingrequirements for tightly coupled SIP conferences. Separate documentswill map the requirements to existing protocol primitives, define newprotocol extensions, and introduce new protocols as needed. Together,these documents will provide a guide for building interoperable SIPconferencing applications. UpStatus:InformationalRFC4282
12/2005
(16 p.)
pdf(p) B. Aboba
M. Beadles
J. Arkko
P. EronenRADEXTNetwork Access IdentifierIn order to provide roaming services, it is necessaryto have a standardized method for identifying users. This documentdefines the syntax for the Network Access Identifier (NAI), the useridentity submitted by the client during network authentication."Roaming" may be loosely defined as the ability to use any one ofmultiple Internet Service Providers (ISPs), while maintaining a formal,customer-vendor relationship with only one. Examples of where roamingcapabilities might be required include ISP "confederations" andISP-provided corporate network access support. UpStatus:Standards TrackTopp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
12/2005
(20 p.)
pdf(p) D. OranSPEECHSCRequirementsfor Distributed Control of Automatic Speech Recognition (ASR), SpeakerIdentification / Speaker Verification (SI/SV), and Text-to-Speech (TTS)ResourcesThis document outlines the needs and requirements fora protocol to control distributed speech processing of audio streams.By speech processing, this document specifically means automatic speechrecognition (ASR), speaker recognition -- which includes both speakeridentification (SI) and speaker verification (SV) -- and text-to-speech(TTS). Other IETF protocols, such as SIP and Real Time StreamingProtocol (RTSP), address rendezvous and control for generalized mediastreams. However, speech processing presents additional requirementsthat none of the extant IETF protocols address. UpStatus:InformationalRFC4317
12/2005
(24 p.)
pdf(p) A. Johnston
R. SparksMMUSICSDP Offer/Answer ExamplesThis document gives examples of Session DescriptionProtocol (SDP) offer/answer exchanges. Examples include codecnegotiation and selection, hold and resume, and addition and deletionof media streams. The examples show multiple media types,bidirectional, unidirectional, inactive streams, and dynamic payloadtypes. Common Third Party Call Control (3pcc) examples are also given. UpStatus:InformationalSee 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 SessionInitiation Protocol (SIP) to address problems that have been identifiedwith the SIP non-INVITE transaction. These modifications reduce theprobability of messages losing the race condition inherent in thenon-INVITE transaction and reduce useless network traffic. They alsoimprove the robustness of SIP networks when elements stop responding.These changes update behavior defined in RFC 3261. UpStatus:Proposed Standard -- updates: RFC3261RFC4321
01/2006
(10 p.)
pdf(p) R. SparksSIPProblems Identified Associated with the SIP Non-INVITE TransactionThis document describes several problems that havebeen identified with the Session Initiation Protocol's (SIP) non-INVITEtransaction. UpStatus:InformationalRFC4353
02/2006
(29 p.)
pdf(p) J. RosenbergSIPPINGA Framework for Conferencing with SIPThe Session Initiation Protocol (SIP) supports theinitiation, modification, and termination of media sessions betweenuser agents. These sessions are managed by SIP dialogs, which representa SIP relationship between a pair of user agents. Because dialogs arebetween pairs of user agents, SIP's usage for two-party communications(such as a phone call), is obvious. Communications sessions withmultiple participants, generally known as conferencing, are morecomplicated. This document defines a framework for how suchconferencing can occur. This framework describes the overallarchitecture, terminology, and protocol components needed formulti-party conferencing. UpStatus:InformationalRFC4354
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 thePush-to-talk over Cellular (PoC) service where SIP is the protocol usedto 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, andnotification of additional capabilities required by the PoC service.This SIP event package is applicable to the PoC service and may not beapplicable to the general Internet.
This document registers a new MIME type, application/ poc-settings+xml. UpStatus:InformationalRFC4376
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 exclusiveaccess to shared resources in a (multiparty) conferencing environment.Thereby, floor control complements other functions -- such asconference and media session setup, conference policy manipulation, andmedia control -- that are realized by other protocols. This documentdefines the requirements for a floor control protocol for multipartyconferences in the context of an existing framework. UpStatus:InformationalTopp. 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 SIP Reason Header (RFC 3326)to be included in a BYE Method Request as a result of a sessionpreemption event, either at a user agent (UA), or somewhere in thenetwork involving a reservation-based protocol such as the ResourceReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). Thisdocument does not attempt to address routers failing in the packetpath; instead, it addresses a deliberate tear down of a flow betweenUAs, and informs the terminated UA(s) with an indication of whatoccurred. 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. UpStatus:Proposed StandardRFC4412
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 SIPuser agents (such as telephone gateways and IP telephones) and SIPproxies. It does not directly influence the forwarding behavior of IProuters.
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 StandardRFC4453
04/2006
(8 p.)
pdf(p) J. Rosenberg
G. Camarillo
D. WillisSIPPINGRequirements for Consent-Based Communications in SIPThe Session Initiation Protocol (SIP) supportscommunications across many media types, including real-time audio,video, text, instant messaging, and presence. In its current form, itallows session invitations, instant messages, and other requests to bedelivered from one party to another without requiring explicit consentof the recipient. Without such consent, it is possible for SIP to beused for malicious purposes, including spam and denial-of-serviceattacks. This document identifies a set of requirements for extensionsto SIP that add consent-based communications. UpStatus:InformationalRFC4457
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 the3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem)to provide SIP registrars and SIP proxy servers with the address of thedatabase that contains the user profile of the user that generated aparticular request. UpStatus:InformationalRFC4458
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 usedto initiate connections to applications such as voicemail orinteractive voice recognition systems. This specification describes aconvention for forming SIP service URIs that request particularservices 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. UpStatus:InformationalRFC4463
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 usedto initiate This document describes a Media Resource Control Protocol(MRCP) that was developed jointly by Cisco Systems, Inc., NuanceCommunications, and Speechworks, Inc. It is published as an RFC asinput for further IETF development in this area.
MRCP controlsmedia service resources like speech synthesizers, recognizers, signalgenerators, signal detectors, fax servers, etc., over a network. Thisprotocol is designed to work with streaming protocols like RTSP (RealTime Streaming Protocol) or SIP (Session Initiation Protocol), whichhelp establish control connections to external media streaming devices,and media delivery mechanisms like RTP (Real Time Protocol). UpStatus:InformationalRFC4474
08/2006
(41 p.)
pdf(p) J. Peterson
C. JenningsSIPEnhancements for Authenticated Identity Management in SIPThe existing security mechanisms in the SessionInitiation Protocol (SIP) are inadequate for cryptographically assuringthe identity of the end users that originate SIP requests, especiallyin an interdomain context. This document defines a mechanism forsecurely identifying originators of SIP messages. It does so bydefining 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. UpStatus:Proposed StandardRFC4475
05/2006
(53 p.)
pdf(p) R. Sparks
A. Hawrylyshen
A. Johnston
J. Rosenberg
H. SchulzrinneSIPPINGSIP Torture Test MessagesThis informational document gives examples of SessionInitiation Protocol (SIP) test messages designed to exercise and"torture" a SIP implementation. UpStatus:InformationalRFC4479
07/2006
(35 p.)
pdf(p) J. RosenbergSIMPLEA Data Model for PresenceThis document defines the underlying presence datamodel used by Session Initiation Protocol (SIP) for Instant Messagingand Presence Leveraging Extensions (SIMPLE) presence agents. The datamodel provides guidance on how to map various communications systemsinto presence documents in a consistent fashion. UpStatus:Proposed StandardRFC4480
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 abasic format for representing presence information for a presentity.This format defines a textual note, an indication of availability (openor closed) and a Uniform Resource Identifier (URI) for communication.The Rich Presence Information Data format (RPID) described here is anextension that adds optional elements to the Presence Information DataFormat (PIDF). These extensions provide additional information aboutthe presentity and its contacts. The information is designed so thatmuch of it can be derived automatically, e.g., from calendar files oruser activity.
This extension includes information about what theperson is doing, a grouping identifier for a tuple, when a service ordevice was last used, the type of place a person is in, what mediacommunications might remain private, the relationship of a servicetuple to another presentity, the person's mood, the time zone it islocated in, the type of service it offers, an icon reflecting thepresentity's status, and the overall role of the presentity.
These extensions include presence information for persons, services (tuples), and devices. UpStatus:Proposed StandardRFC4481
07/2006
(9 p.)
pdf(p) H. SchulzrinneSIMPLETimedPresence Extensions to the Presence Information Data Format (PIDF) toIndicate Status Information for Past and Future Time IntervalsThe Presence Information Data Format (PIDF) defines abasic 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 itsstatus for a time interval fully in the future or the past. UpStatus:Proposed StandardRFC4482
07/2006
(11 p.)
pdf(p) H. SchulzrinneSIMPLECIPID: Contact Information for the Presence Information Data FormatThe Presence Information Data Format (PIDF) defines abasic 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 provideadditional contact information about a presentity and its contacts,including references to address book entries and icons. UpStatus:Proposed StandardRFC4483
05/2006
(17 p.)
pdf(p) E. BurgerSIPA Mechanism for Content Indirection in SIP MessagesThis document defines an extension to the URL MIMEExternal-Body Access-Type to satisfy the content indirectionrequirements for the Session Initiation Protocol (SIP). Theseextensions are aimed at allowing any MIME part in a SIP message to bereferred to indirectly via a URI. UpStatus:Proposed StandardRFC4484
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 relatedto trait-based authorization for the Session Initiation Protocol (SIP).While some authentication mechanisms are described in the base SIPspecification, trait-based authorization provides information used tomake policy decisions based on the attributes of a participant in asession. This approach provides a richer framework for authorization,as well as allows greater privacy for users of an identity system. UpStatus:InformationalRFC4485
05/2006
(23 p.)
pdf(p) J. Rosenberg
H. SchulzrinneSIPGuidelines for Authors of Extensions to SIPThe Session Initiation Protocol (SIP) is a flexibleyet simple tool for establishing interactive communications sessionsacross the Internet. Part of this flexibility is the ease with which itcan be extended. In order to facilitate effective and interoperableextensions to SIP, some guidelines need to be followed when developingSIP extensions. This document outlines a set of such guidelines forauthors of SIP extensions. UpStatus:InformationalRFC4488
05/2006
(8 p.)
pdf(p) O. LevinSIPSuppression of SIP REFER Method Implicit SubscriptionThe Session Initiation Protocol (SIP) REFER extension as defined in RFC 3515automatically establishes a typically short-lived event subscriptionused to notify the party sending a REFER request about the receiver'sstatus in executing the transaction requested by the REFER. Thesenotifications are not needed in all cases. This specification providesa way to prevent the automatic establishment of an event subscriptionand 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 StandardRFC4497
05/2006
(65 p.)
pdf(p) J. Elwell
F. Derks
P. Mourot
O. RousseauSIPPINGInterworking between SIP and QSIGThis document specifies interworking between theSession Initiation Protocol (SIP) and QSIG within corporatetelecommunication networks (also known as enterprise networks). SIP isan Internet application-layer control (signalling) protocol forcreating, modifying, and terminating sessions with one or moreparticipants. These sessions include, in particular, telephone calls.QSIG is a signalling protocol for creating, modifying, and terminatingcircuit-switched calls (in particular, telephone calls) within PrivateIntegrated Services Networks (PISNs). QSIG is specified in a number ofEcma Standards and published also as ISO/IEC standards. UpStatus:Best Current Practice (BCP: 117)
Topp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
40xx
# RFC 4028Session Timers in SIP# RFC 4032Update to SIP Preconditions Framework# RFC 4079A Presence Architecture for the Distribution of GEOPRIV Location Objects# RFC 4083Input 3GPP Release 5 Requirements on SIP# RFC 4091ANAT Semantics for SDP Grouping Framework# RFC 4092ANAT Usage in SDPRFC402804/2005
(28 p.)
pdf(v)
pdf(p) S. Donovan
J. RosenbergSIPSession Timers in SIPThis document defines an extension to SIP. Thisextension allows for a periodic refresh of SIP sessions through are-INVITE or UPDATE request. The refresh allows both user agents andproxies to determine whether the SIP session is still active. Theextension 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 StandardRFC4032
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 providesguidelines for authors of new precondition types and describes how touse SIP preconditions in situations that involve session mobility. UpStatus:Proposed Standard -- updates: RFC 3312RFC4079
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 definesvarious scenarios for the distribution of location objects that requirethe concepts of subscriptions and asynchronous notifications. Thisdocument examines some existing IETF work on the concept of presence,shows how presence architectures map onto GEOPRIV architectures, andmoreover demonstrates that tools already developed for presence couldbe reused to simplify the standardization and implementation ofGEOPRIV. UpStatus:InformationalRFC4083
05/2005
(36 p.)
pdf(p) M. Garcia-MartinSIPPINGInput 3GPP Release 5 Requirements on SIPThe 3rd-Generation Partnership Project (3GPP) hasselected SIP as the session establishment protocol for the 3GPP IPMultimedia Core Network Subsystem (IMS). IMS is part of Release 5 ofthe 3GPP specifications. Although SIP is a protocol that fulfills mostof the requirements for establishing a session in an IP network, SIPhas never been evaluated against the specific 3GPP requirements foroperation in a cellular network. In this document, we express therequirements identified by 3GPP to support SIP for Release 5 of the3GPP IMS in cellular networks. UpStatus:InformationalRFC4091
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 AddressTypes (ANAT) semantics for SDP grouping framework. The ANAT semanticsallow alternative types of network addresses to establish a particularmedia stream. UpStatus:Proposed StandardRFC4092
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 AlternativeNetwork Address Types (ANAT) semantics of SDP grouping framework inSIP. In particular, we define the 'sdp-anat'SIP option tag. This SIP option-tag ensures that SDP sessiondescriptions that use ANAT are only handled by SIP entities with ANATsupport. To justify the need for such a SIP option-tag, we describewhat could possibly happen if an ANAT-unaware SIP entity tried tohandle media lines grouped with ANAT. UpStatus:Proposed StandardTopp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
41xx
# RFC 41173pcc Transcoding in SIP# RFC 4119Presence-based GEOPRIV Location Object Format# RFC 4122Universally Unique IDentifier (UUID) URN Namespace# RFC 4123SIP-H.323 Interworking Requirements# RFC 4145TCP-Based Media Transport in SDP# RFC 4168SCTP as a Transport for SIP# RFC 4169HTTP Digest AKAv2# RFC 4189Requirements for End-to-Middle Security for SIP# RFC 4190Framework 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 transcodingservices using SIP and third party call control. This way of invocationmeets the requirements for SIP regarding transcoding servicesinvocation to support deaf, hard of hearing and speech-impairedindividuals. UpStatus:InformationalRFC4119
12/2005
(24 p.)
pdf(p) J. PetersonGEOPRIVA Presence-based GEOPRIV Location Object FormatThis document describes an object format for carryinggeographical information on the Internet. This location object extendsthe Presence Information Data Format (PIDF), which was designed forcommunicating privacy-sensitive presence information and which hassimilar properties. UpStatus:Proposed Standard -- Updated by: RFC 5139RFC4122
07/2005
(32 p.)
pdf(p) P. Leach
M. Mealling
R. Salz-A Universally Unique IDentifier (UUID) URN NamespaceThis specification defines a Uniform Resource Namenamespace for UUIDs (Universally Unique IDentifier), also known asGUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and canguarantee uniqueness across space and time. UUIDs were originally usedin the Apollo Network Computing System and later in the Open SoftwareFoundation's (OSF) Distributed Computing Environment (DCE), and then inMicrosoft Windows platforms.
This specification is derived fromthe DCE specification with the kind permission of the OSF (now known asThe Open Group). Information from earlier versions of the DCEspecification have been incorporated into this document. UpStatus:Proposed StandardRFC4123
07/2005
(16 p.)
pdf(p) H. Schulzrinne
C. AgbohSIPSIP-H.323 Interworking RequirementsThis document describes the requirements for thelogical entity known as the Session Initiation Protocol (SIP)-H.323Interworking Function (SIP-H.323 IWF) that will allow the interworkingbetween SIP and H.323. UpStatus:InformationalRFC4145
09/2005
(15 p.)
pdf(p) D. Yon
G. CamarilloMMUSICTCP-Based Media Transport in SDPThis document describes how to express mediatransport over TCP using SDP. It defines the SDP 'TCP' protocolidentifier, the SDP 'setup' attribute, which describes the connectionsetup procedure, and the SDP 'connection' attribute, which handlesconnection reestablishment. UpStatus:Proposed Standard -- updated by RFC4572RFC4168
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 mechanismbetween SIP (Session Initiation Protocol) entities. SCTP is a newprotocol that provides several features that may prove beneficial fortransport between SIP entities that exchange a large amount ofmessages, including gateways and proxies. As SIP istransport-independent, support of SCTP is a relatively straightforwardprocess, nearly identical to support for TCP.
This RFC adds the SIPS+D2S NAPTR service field value to the registry defined in RFC 3263. UpStatus:Proposed StandardRFC4169
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 clientfails to authenticate the server in TLS, or if the same passwords areused for authentication in some other context without TLS. This is ageneral problem that exists not just with HTTP Digest, but also withother IETF protocols that use tunneled authentication. This documentspecifies 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:InformationalRFC4189
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 inspectits message bodies and/or headers contained in its message. The UAmight want to protect the message bodies and/or headers fromintermediaries, except those that provide services based on itscontent. This situation requires a mechanism called "end-to-middlesecurity" to secure the information passed between the UA andintermediaries, which does not interfere with end-to-end security. Thisdocument defines a set of requirements for a mechanism to achieveend-to-middle security. UpStatus:InformationalRFC4190
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 supportingauthorized, emergency-related communication within the context of IPtelephony. We present a series of objectives that reflect a generalview of how authorized emergency service, in line with the EmergencyTelecommunications Service (ETS), should be realized within today's IParchitecture and service models. From these objectives, we present acorresponding set of protocols and capabilities, which provide a morespecific set of recommendations regarding existing IETF protocols.Finally, we present two scenarios that act as guiding models for theobjectives and functions listed in this document. These models, coupledwith an example of an existing service in the Public Switched TelephoneNetwork (PSTN), contribute to a constrained solution space. UpStatus:InformationalTopp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
42xx
# RFC 4215IPv6 Transition in 3GPP Networks# RFC 4235INVITE-Initiated Dialog Event Package for SIP# RFC 4240Basic Network Media Services with SIP# RFC 4244SIP Request History Information# RFC 4245High-Level Requirements for Tightly Coupled SIP Conferencing# RFC 4282Network Access IdentifierRFC421510/2005
(24 p.)
pdf(p) J. WiljakkaV6OPSAnalysis on IPv6 Transition in 3GPP NetworksThis document analyzes the transition to IPv6 inThird Generation Partnership Project (3GPP) packet networks. Thesenetworks are based on General Packet Radio Service (GPRS) technology,and the radio network architecture is based on Global System for MobileCommunications (GSM) or Universal Mobile Telecommunications System(UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.
Thefocus is on analyzing different transition scenarios and applicabletransition mechanisms and finding solutions for those transitionscenarios. In these scenarios, the User Equipment (UE) connects toother nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanismsare needed. UpStatus:InformationalRFC4235
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 formatused in notifications for this package. The dialog package allows usersto subscribe to another user and to receive notification of the changesin state of INVITE-initiated dialog usages in which the subscribed-touser 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. UpStatus:Proposed StandardRFC4240
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 providebasic network media services. Such services include networkannouncements, user interaction, and conferencing services. Theseservices are basic building blocks, from which one can constructinteresting applications. In order to have interoperability betweenservers offering these building blocks (also known as Media Servers)and application developers, one needs to be able to locate and invokesuch services in a well defined manner.
This document describes amechanism for providing an interoperable interface between ApplicationServers, which provide application services to SIP-based networks, andMedia Servers, which provide the basic media processing buildingblocks.
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". UpStatus:InformationalRFC4244
11/2005
(44 p.)
pdf(p)
pdf(v) M. BarnesSIPAn Extension to SIP for Request History InformationThis document defines a standard mechanism forcapturing the history information associated with a Session InitiationProtocol (SIP) request. This capability enables many enhanced servicesby providing the information as to how and why a call arrives at aspecific application or user. This document defines a new optional SIPheader, "History-Info", for capturing the history information in requests.
This specification defines the 'histinfo' SIP option tag. UpStatus:Proposed StandardRFC4245
11/2005
(12 p.)
pdf(p) O. Levin
R. EvenSIPPINGHigh-Level Requirements for Tightly Coupled SIP ConferencingThis document examines a wide range of conferencingrequirements for tightly coupled SIP conferences. Separate documentswill map the requirements to existing protocol primitives, define newprotocol extensions, and introduce new protocols as needed. Together,these documents will provide a guide for building interoperable SIPconferencing applications. UpStatus:InformationalRFC4282
12/2005
(16 p.)
pdf(p) B. Aboba
M. Beadles
J. Arkko
P. EronenRADEXTNetwork Access IdentifierIn order to provide roaming services, it is necessaryto have a standardized method for identifying users. This documentdefines the syntax for the Network Access Identifier (NAI), the useridentity submitted by the client during network authentication."Roaming" may be loosely defined as the ability to use any one ofmultiple Internet Service Providers (ISPs), while maintaining a formal,customer-vendor relationship with only one. Examples of where roamingcapabilities might be required include ISP "confederations" andISP-provided corporate network access support. UpStatus:Standards TrackTopp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
43xx
# RFC 4313Speech Services Control Requirements# RFC 4317SDP Offer/Answer Examples# RFC 4320SIP Non-INVITE Actions# RFC 4321SIP Non-INVITE Problems# RFC 4353Conferencing Framework with SIP# RFC 4354PoC Settings Event Package# RFC 4376Floor Control Protocol RequirementsRFC431312/2005
(20 p.)
pdf(p) D. OranSPEECHSCRequirementsfor Distributed Control of Automatic Speech Recognition (ASR), SpeakerIdentification / Speaker Verification (SI/SV), and Text-to-Speech (TTS)ResourcesThis document outlines the needs and requirements fora protocol to control distributed speech processing of audio streams.By speech processing, this document specifically means automatic speechrecognition (ASR), speaker recognition -- which includes both speakeridentification (SI) and speaker verification (SV) -- and text-to-speech(TTS). Other IETF protocols, such as SIP and Real Time StreamingProtocol (RTSP), address rendezvous and control for generalized mediastreams. However, speech processing presents additional requirementsthat none of the extant IETF protocols address. UpStatus:InformationalRFC4317
12/2005
(24 p.)
pdf(p) A. Johnston
R. SparksMMUSICSDP Offer/Answer ExamplesThis document gives examples of Session DescriptionProtocol (SDP) offer/answer exchanges. Examples include codecnegotiation and selection, hold and resume, and addition and deletionof media streams. The examples show multiple media types,bidirectional, unidirectional, inactive streams, and dynamic payloadtypes. Common Third Party Call Control (3pcc) examples are also given. UpStatus:InformationalSee 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 SessionInitiation Protocol (SIP) to address problems that have been identifiedwith the SIP non-INVITE transaction. These modifications reduce theprobability of messages losing the race condition inherent in thenon-INVITE transaction and reduce useless network traffic. They alsoimprove the robustness of SIP networks when elements stop responding.These changes update behavior defined in RFC 3261. UpStatus:Proposed Standard -- updates: RFC3261RFC4321
01/2006
(10 p.)
pdf(p) R. SparksSIPProblems Identified Associated with the SIP Non-INVITE TransactionThis document describes several problems that havebeen identified with the Session Initiation Protocol's (SIP) non-INVITEtransaction. UpStatus:InformationalRFC4353
02/2006
(29 p.)
pdf(p) J. RosenbergSIPPINGA Framework for Conferencing with SIPThe Session Initiation Protocol (SIP) supports theinitiation, modification, and termination of media sessions betweenuser agents. These sessions are managed by SIP dialogs, which representa SIP relationship between a pair of user agents. Because dialogs arebetween pairs of user agents, SIP's usage for two-party communications(such as a phone call), is obvious. Communications sessions withmultiple participants, generally known as conferencing, are morecomplicated. This document defines a framework for how suchconferencing can occur. This framework describes the overallarchitecture, terminology, and protocol components needed formulti-party conferencing. UpStatus:InformationalRFC4354
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 thePush-to-talk over Cellular (PoC) service where SIP is the protocol usedto 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, andnotification of additional capabilities required by the PoC service.This SIP event package is applicable to the PoC service and may not beapplicable to the general Internet.
This document registers a new MIME type, application/ poc-settings+xml. UpStatus:InformationalRFC4376
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 exclusiveaccess to shared resources in a (multiparty) conferencing environment.Thereby, floor control complements other functions -- such asconference and media session setup, conference policy manipulation, andmedia control -- that are realized by other protocols. This documentdefines the requirements for a floor control protocol for multipartyconferences in the context of an existing framework. UpStatus:InformationalTopp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
44xx
# RFC 4411SIP Reason Header for Preemption Events# RFC 4412SIP Resource Priority# RFC 4453Requirements for Consent-Based Communications in SIP# RFC 4457SIP P-User-Database Private-Header# RFC 4458SIP Voicemail URI# RFC 4463MRCP by Cisco, Nuance, and Speechworks# RFC 4474Enhancements for Authenticated Identity Management in SIP# RFC 4475SIP Torture Test Messages# RFC 4479Presence Data Model# RFC 4480RPID: Rich Presence Extensions to PIDF# RFC 4481Timed Presence Extensions to PIDF# RFC 4482CIPID: Contact Information for PIDF# RFC 4483Content Indirection in SIP Messages# RFC 4484Trait-Based Authorization Requirements for SIP# RFC 4485Guidelines for Authors of Extensions to SIP# RFC 4488Suppression of SIP REFER Method Implicit Subscription# RFC 4497Interworking 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 SIP Reason Header (RFC 3326)to be included in a BYE Method Request as a result of a sessionpreemption event, either at a user agent (UA), or somewhere in thenetwork involving a reservation-based protocol such as the ResourceReSerVation Protocol (RSVP) or Next Steps in Signaling (NSIS). Thisdocument does not attempt to address routers failing in the packetpath; instead, it addresses a deliberate tear down of a flow betweenUAs, and informs the terminated UA(s) with an indication of whatoccurred. 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. UpStatus:Proposed StandardRFC4412
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 SIPuser agents (such as telephone gateways and IP telephones) and SIPproxies. It does not directly influence the forwarding behavior of IProuters.
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 StandardRFC4453
04/2006
(8 p.)
pdf(p) J. Rosenberg
G. Camarillo
D. WillisSIPPINGRequirements for Consent-Based Communications in SIPThe Session Initiation Protocol (SIP) supportscommunications across many media types, including real-time audio,video, text, instant messaging, and presence. In its current form, itallows session invitations, instant messages, and other requests to bedelivered from one party to another without requiring explicit consentof the recipient. Without such consent, it is possible for SIP to beused for malicious purposes, including spam and denial-of-serviceattacks. This document identifies a set of requirements for extensionsto SIP that add consent-based communications. UpStatus:InformationalRFC4457
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 the3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem)to provide SIP registrars and SIP proxy servers with the address of thedatabase that contains the user profile of the user that generated aparticular request. UpStatus:InformationalRFC4458
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 usedto initiate connections to applications such as voicemail orinteractive voice recognition systems. This specification describes aconvention for forming SIP service URIs that request particularservices 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. UpStatus:InformationalRFC4463
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 usedto initiate This document describes a Media Resource Control Protocol(MRCP) that was developed jointly by Cisco Systems, Inc., NuanceCommunications, and Speechworks, Inc. It is published as an RFC asinput for further IETF development in this area.
MRCP controlsmedia service resources like speech synthesizers, recognizers, signalgenerators, signal detectors, fax servers, etc., over a network. Thisprotocol is designed to work with streaming protocols like RTSP (RealTime Streaming Protocol) or SIP (Session Initiation Protocol), whichhelp establish control connections to external media streaming devices,and media delivery mechanisms like RTP (Real Time Protocol). UpStatus:InformationalRFC4474
08/2006
(41 p.)
pdf(p) J. Peterson
C. JenningsSIPEnhancements for Authenticated Identity Management in SIPThe existing security mechanisms in the SessionInitiation Protocol (SIP) are inadequate for cryptographically assuringthe identity of the end users that originate SIP requests, especiallyin an interdomain context. This document defines a mechanism forsecurely identifying originators of SIP messages. It does so bydefining 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. UpStatus:Proposed StandardRFC4475
05/2006
(53 p.)
pdf(p) R. Sparks
A. Hawrylyshen
A. Johnston
J. Rosenberg
H. SchulzrinneSIPPINGSIP Torture Test MessagesThis informational document gives examples of SessionInitiation Protocol (SIP) test messages designed to exercise and"torture" a SIP implementation. UpStatus:InformationalRFC4479
07/2006
(35 p.)
pdf(p) J. RosenbergSIMPLEA Data Model for PresenceThis document defines the underlying presence datamodel used by Session Initiation Protocol (SIP) for Instant Messagingand Presence Leveraging Extensions (SIMPLE) presence agents. The datamodel provides guidance on how to map various communications systemsinto presence documents in a consistent fashion. UpStatus:Proposed StandardRFC4480
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 abasic format for representing presence information for a presentity.This format defines a textual note, an indication of availability (openor closed) and a Uniform Resource Identifier (URI) for communication.The Rich Presence Information Data format (RPID) described here is anextension that adds optional elements to the Presence Information DataFormat (PIDF). These extensions provide additional information aboutthe presentity and its contacts. The information is designed so thatmuch of it can be derived automatically, e.g., from calendar files oruser activity.
This extension includes information about what theperson is doing, a grouping identifier for a tuple, when a service ordevice was last used, the type of place a person is in, what mediacommunications might remain private, the relationship of a servicetuple to another presentity, the person's mood, the time zone it islocated in, the type of service it offers, an icon reflecting thepresentity's status, and the overall role of the presentity.
These extensions include presence information for persons, services (tuples), and devices. UpStatus:Proposed StandardRFC4481
07/2006
(9 p.)
pdf(p) H. SchulzrinneSIMPLETimedPresence Extensions to the Presence Information Data Format (PIDF) toIndicate Status Information for Past and Future Time IntervalsThe Presence Information Data Format (PIDF) defines abasic 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 itsstatus for a time interval fully in the future or the past. UpStatus:Proposed StandardRFC4482
07/2006
(11 p.)
pdf(p) H. SchulzrinneSIMPLECIPID: Contact Information for the Presence Information Data FormatThe Presence Information Data Format (PIDF) defines abasic 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 provideadditional contact information about a presentity and its contacts,including references to address book entries and icons. UpStatus:Proposed StandardRFC4483
05/2006
(17 p.)
pdf(p) E. BurgerSIPA Mechanism for Content Indirection in SIP MessagesThis document defines an extension to the URL MIMEExternal-Body Access-Type to satisfy the content indirectionrequirements for the Session Initiation Protocol (SIP). Theseextensions are aimed at allowing any MIME part in a SIP message to bereferred to indirectly via a URI. UpStatus:Proposed StandardRFC4484
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 relatedto trait-based authorization for the Session Initiation Protocol (SIP).While some authentication mechanisms are described in the base SIPspecification, trait-based authorization provides information used tomake policy decisions based on the attributes of a participant in asession. This approach provides a richer framework for authorization,as well as allows greater privacy for users of an identity system. UpStatus:InformationalRFC4485
05/2006
(23 p.)
pdf(p) J. Rosenberg
H. SchulzrinneSIPGuidelines for Authors of Extensions to SIPThe Session Initiation Protocol (SIP) is a flexibleyet simple tool for establishing interactive communications sessionsacross the Internet. Part of this flexibility is the ease with which itcan be extended. In order to facilitate effective and interoperableextensions to SIP, some guidelines need to be followed when developingSIP extensions. This document outlines a set of such guidelines forauthors of SIP extensions. UpStatus:InformationalRFC4488
05/2006
(8 p.)
pdf(p) O. LevinSIPSuppression of SIP REFER Method Implicit SubscriptionThe Session Initiation Protocol (SIP) REFER extension as defined in RFC 3515automatically establishes a typically short-lived event subscriptionused to notify the party sending a REFER request about the receiver'sstatus in executing the transaction requested by the REFER. Thesenotifications are not needed in all cases. This specification providesa way to prevent the automatic establishment of an event subscriptionand 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 StandardRFC4497
05/2006
(65 p.)
pdf(p) J. Elwell
F. Derks
P. Mourot
O. RousseauSIPPINGInterworking between SIP and QSIGThis document specifies interworking between theSession Initiation Protocol (SIP) and QSIG within corporatetelecommunication networks (also known as enterprise networks). SIP isan Internet application-layer control (signalling) protocol forcreating, modifying, and terminating sessions with one or moreparticipants. These sessions include, in particular, telephone calls.QSIG is a signalling protocol for creating, modifying, and terminatingcircuit-switched calls (in particular, telephone calls) within PrivateIntegrated Services Networks (PISNs). QSIG is specified in a number ofEcma Standards and published also as ISO/IEC standards. UpStatus:Best Current Practice (BCP: 117)
