SIP RFC 关系图汇总--超全---part4
来源：互联网 发布：远程控制软件排行 编辑：程序博客网 时间：2024/06/11 16:25
SIP RFC 关系图汇总--超全---part4
05/2006
(37 p.)
pdf(p)H. Sinnreich
S. Lass
C. Stredicke-SIP Telephony Device Requirements and ConfigurationThis document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones.
We present a glossary of the most common settings and some of the more widely used values for some settings. UpStatus:Informational RFC4508
05/2006
(6 p.)
pdf(p)O. Levin
A. JohnstonSIPConveying Feature Tags with the SIP REFER MethodThe SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request. The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request. This document extends the REFER method to use the mechanism ofRFC 3840. By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach. UpStatus:Proposed Standard RFC4538
06/2006
(17 p.)
pdf(p)J. RosenbergSIPRequest Authorization through Dialog Identification in SIPThis specification defines the "Target-Dialog" header field for the Session Initiation Protocol (SIP), and the corresponding 'tdialog' option tag. This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness. UpStatus:Proposed Standard RFC4566
07/2006
(49 p.)
pdf(p)M. Handley
V. Jacobson
C. PerkinsMMUSICSDP: Session Description ProtocolThis memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. UpStatus:Proposed Standard -- obsoletes RFC 2327 ,RFC 3266RFC4567
07/2006
(30 p.)
pdf(p)J. Arkko
F. Lindholm
M. Naslund
K. Norrman
E. CarraraMMUSICKey Management Extensions for SDP and RTSPThis document defines general extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol.
General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the Multimedia Internet KEYing (MIKEY) key management protocol is also defined. UpStatus:Proposed Standard RFC4568
07/2006
(44 p.)
pdf(p)F. Andreasen
M. Baugher
D. WingMMUSICSDP Security Descriptions for Media StreamsThis document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. UpStatus:Proposed Standard RFC4569
07/2006
(4 p.)
pdf(p)G. CamarilloSIPPINGIANA Registration of the 'Message' Media Feature TagThis document registers with the IANA (Internet Assigned Numbers Authority) a new media feature tag associated with the 'message' media type. This media feature tag indicates that a particular device supports 'message' as a streaming media type. Media feature tags can be used to route calls to devices that support certain features.
This new Media feature tag: sip.message (21) is placed into the SIP Media Feature Tag Registration Tree, which is defined inRFC 3840. UpStatus:Informational RFC4570
07/2006
(14 p.)
pdf(p)B. Quinn
R. FinlaysonMMUSICSDP Source FiltersThis document describes how to adapt the Session Description Protocol (SDP) to express one or more source addresses as a source filter for one or more destination "connection" addresses. It defines the syntax and semantics for an SDP "source-filter" attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations. In particular, an inclusive source-filter can be used to specify a Source-Specific Multicast (SSM) session. UpStatus:Proposed Standard RFC4572
07/2006
(17 p.)
pdf(p)J. LennoxMMUSICConnection-Oriented Media Transport over the TLS Protocol in SDPThis document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. UpStatus:Proposed Standard -- updates: RFC 4145 RFC4574
08/2006
(8 p.)
pdf(p)O. Levin
G. CamarilloMMUSICThe SDP Label AttributeThis document defines a new Session Description Protocol (SDP) media-level attribute: "label". The "label" attribute carries a pointer to a media stream in the context of an arbitrary network application that uses SDP. The sender of the SDP document can attach the "label" attribute to a particular media stream or streams. The application can then use the provided pointer to refer to each particular media stream in its context. UpStatus:Proposed Standard RFC4575
08/2006
(40 p.)
pdf(p)J. Rosenberg
H. Schulzrinne
O. LevinSIPPINGA SIP Event Package for Conference StateThis document defines a 'conference' event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference Uniform Resource Identifier (URI). Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components.
This document registers a new MIME type, application/ conference-info+xml . UpStatus:Proposed Standard RFC4579
08/2006
(43 p.)
pdf(p)A. Johnston
O. LevinSIPPINGSIP Call Control - Conferencing for User AgentsThis specification defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from the perspective of different user agent (UA) types: conference-unaware, conference-aware, and focus UAs. The use of Uniform Resource Identifiers (URIs) in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. The usage of the isfocus feature tag is defined. UpStatus:Best Current Practice (BCP: 119) RFC4582
11/2006
(65 p.)
pdf(p)G. Camarillo
J. Ott
K. DrageXCONThe Binary Floor Control Protocol (BFCP)Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.
This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers.
This RFC defines several sub-registries under
http://www.iana.org/assignments/bfcp-parameters:
"Attribute , "Primitive , "Request Status , and "Error Code . UpStatus:Proposed Standard RFC4583
11/2006
(12 p.)
pdf(p)G. CamarilloMMUSICSDP Format for Binary Floor Control Protocol (BFCP) StreamsThis document specifies how to describe Binary Floor Control Protocol (BFCP) streams in Session Description Protocol (SDP) descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. UpStatus:Proposed Standard RFC4589
07/2006
(12 p.)
pdf(p)H. Schulzrinne
H. TschofenigGEOPRIVLocation Types RegistryThis document creates a registry for describing the types of places a human or end system might be found. The registry is then referenced by other protocols that need a common set of location terms as protocol constants. Examples of location terms defined in this document include aircraft, office, and train station. UpStatus:Proposed Standard RFC4596
07/2006
(40 p.)
pdf(p)
pdf(v)J. Rosenberg
P. KyzivatSIPPINGGuidelines for Usage of the SIP Caller Preferences ExtensionThis document contains guidelines for usage of the Caller Preferences Extension to the Session Initiation Protocol (SIP). It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in Section 7.2 ofRFC 3841. UpStatus:Informational See also:RFC 3840, RFC 3841 RFC4597
07/2006
(17 p.)
pdf(p)R. Even
N. IsmailXCONConferencing ScenariosThis document describes multimedia conferencing scenarios. It describes both basic and advanced conferencing scenarios involving voice, video, text, and interactive text sessions. These scenarios will help with the definition and evaluation of the protocols being developed in the centralized conferencing XCON working group. UpStatus:Informational Topp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
10/2006
(18 p.)
pdf(p)S. Josefsson-The Base16, Base32, and Base64 Data EncodingsThis document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. UpStatus:Proposed Standard RFC4660
09/2006
(31 p.)
pdf(p)H. Khartabil
E. Leppanen
M. Lonnfors
J. Costa-RequenaSIMPLEFunctional Description of Event Notification FilteringThe SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to the state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved.
This document describes the operations a subscriber performs in order to put filtering rules associated with a subscription to event notification information in place. The handling, by the subscriber, of responses to subscriptions carrying filtering rules and the handling of notifications with filtering rules applied to them are also described. Furthermore, the document conveys how the notifier behaves when receiving such filtering rules and how a notification is constructed. UpStatus:Proposed Standard RFC4661
09/2006
(24 p.)
pdf(p)H. Khartabil
E. Leppanen
M. Lonnfors
J. Costa-RequenaSIMPLEAn XML-Based Format for Event Notification FilteringThe SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved. Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying triggers that cause that information to be delivered. In order to enable this, a format is needed to enable the subscriber to describe the state changes of a resource that cause notifications to be sent to it and what those notifications are to contain. This document presents a format in the form of an XML document.
This document registers a new MIME type, application/ simple-filter+xml . UpStatus:Proposed Standard RFC4662
08/2006
(39 p.)
pdf(p)A. B. Roach
B. Campbell
J. RosenbergSIMPLEA SIP Event Notification Extension for Resource ListsThis document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list and then receive notifications when the state of any of the resources in the list changes.
This extension uses the 'eventlist' SIP option tag.
This document registers a new MIME type, application/ rlmi+xml . UpStatus:Proposed Standard RFC4694
10/2006
(15 p.)
pdf(p)J. YuIPTELNumber Portability Parameters for the "tel" URIThis document defines five parameters in the "tel" Uniform Resource Identifier (URI) to carry the number portability (NP)-related information. Those parameters can be passed to the next-hop network node after an NP database dip has been performed. UpStatus:Proposed Standard See also:RFC 3966
ABNF for "tel" URITopp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
11/2006
(14 p.)
pdf(p)M. Munakata
S. Schubert
T. OhbaIPTELThe ISDN Subaddress Encoding Type for tel URIWithout a tel URI parameter to carry an encoding type of Integrated Services Digital Network (ISDN) subaddress, interworking between ISDN User Part (ISUP) network and a Session Initiation Protocol (SIP) network is impossible in some cases. To solve this problem, this document specifies a new optional tel URI parameter to carry the encoding type of ISDN subaddress. UpStatus:Informational See also:RFC 3966
ABNF for "tel" URIRFC4730
11/2006
(56 p.)
pdf(p)E. Burger
M. DollySIPPINGA SIP Event Package for Key Press Stimulus (KPML)This document describes a SIP event package 'kpml' that enables monitoring of Dual Tone Multi-Frequency (DTMF) signals and uses Extensible Markup Language (XML) documents referred to as Key Press Markup Language (KPML).
The kpml Event Package may be used to support applications consistent with the principles defined indraft-ietf-sipping-app-interaction-framework.
The event package uses SUBSCRIBE messages and allows for XML documents that define and describe filter specifications for capturing key presses (DTMF Tones) entered at a presentation-free User Interface SIP User Agent (UA). The event package uses NOTIFY messages and allows for XML documents to report the captured key presses (DTMF tones), consistent with the filter specifications, to an Application Server. The scope of this package is for collecting supplemental key presses or mid-call key presses (triggers).
This document registers two new MIME types:
application/ kpml-request+xml and application/ kpml-response+xml . UpStatus:Proposed Standard RFC4745
02/2007
(32 p.)
pdf(p)H. Schulzrinne
J. Morris
H. Tschofenig
J. Cuellar
J. Polk
J. RosenbergGEOPRIVCommon Policy: A Document Format for Expressing Privacy PreferencesThis document defines a framework for authorization policies controlling access to application-specific data. This framework combines common location- and presence-specific authorization aspects. An XML schema specifies the language in which common policy rules are represented. The common policy framework can be extended to other application domains.
This specification requests the registration of a new MIME type:
application/auth-policy+xml .
It also registers a new XML namespace and a new XML schema:
urn:ietf:params:xml:ns:common-policy ,
urn:ietf:params:xml:schema:common-policy . UpStatus:Proposed Standard RFC4756
11/2006
(6 p.)
pdf(p)A. LiMMUSICForward Error Correction Grouping SemanticsThis document defines the semantics that allow for grouping of Forward Error Correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP). The semantics defined in this document are to be used with "Grouping of Media Lines in the Session Description Protocol" (RFC 3388) to group together "m" lines in the same session. UpStatus:Proposed Standard RFC4759
11/2006
(8 p.)
pdf(p)R. Stastny
R. Shockey
L. ConroyIPTELThe ENUM Dip Indicator Parameter for the "tel" URIThis document defines a new parameter "enumdi" for the "tel" Uniform Resource Identifier (URI) to support the handling of ENUM queries in Voice over Internet Protocol (VoIP) network elements. A VoIP network element may receive a URI containing an E.164 number, where that URI contains an "enumdi" parameter. The presence of the "enumdi" parameter indicates that an ENUM query has already been performed on the E.164 number by a previous VoIP network element. Equally, if a VoIP network element sends such a URI, it asserts that an ENUM query has been carried out on this number. UpStatus:Proposed Standard See also:RFC 3966
ABNF for "tel" URIRFC4769
11/2006
(13 p.)
pdf(p)J. Livingood
R. ShockeyENUMIANA Registration for an Enumservice Containing PSTN Signaling InformationThis document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype "sip" using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification,RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where number portability exists. UpStatus:Proposed Standard RFC4770
01/2007
(7 p.)
pdf(p)C. Jennings
J. ReschkeIMPPvCard Extensions for Instant Messaging (IM)This document describes an extension to vCard to support Instant Messaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books. It allows a URI that is associated with IM or PP to be specified inside a vCard. UpStatus:Proposed Standard RFC4776
11/2006
(19 p.)
pdf(p)H. SchulzrinneGEOPRIVDynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration InformationThis document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages.
RFC Editor Note: RFC 4776 is being published to correct an error in the assignment of the numeric value of the DHCPv6 option-code in RFC 4676 (Section 3.2). UpStatus:Proposed Standard -- obsoletes RFC 4676 RFC4780
04/2007
(83 p.)
pdf(p)K. Lingle
J-F. Mule
J. Maeng
D. WalkerSIPManagement Information Base for SIPThis memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, and Proxy, Redirect and Registrar servers. UpStatus:Proposed Standard RFC4796
02/2007
(11 p.)
pdf(p)J. Hautakorpi
G. CamarilloMMUSICThe SDP Content AttributeThis document defines a new Session Description Protocol (SDP) media- level attribute, 'content'. The 'content' attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big or small screen) based on its content. UpStatus:Proposed Standard Topp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
05/2007
(71 p.)
pdf(p)J. RosenbergSIMPLEThe XML Configuration Access Protocol (XCAP)This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write, and modify application configuration data stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. This specification requests the registration of several new MIME types:
application/xcap-el+xml ,
application/xcap-att+xml ,
application/xcap-ns+xml ,
application/xcap-error+xml ,
application/xcap-caps+xml .
This specification instructs IANA to create a new registry for XCAP application unique IDs (AUIDs) with thexcap-caps initial entry (capabilities of an XCAP server).
It registers two new XML namespaces:
urn:ietf:params:xml:ns:xcap-error ,
urn:ietf:params:xml:ns:xcap-caps .
It registers two new XML schemas:
urn:ietf:params:xml:schema:xcap-error ,
urn:ietf:params:xml:schema:xcap-caps . UpStatus:Proposed Standard RFC4826
05/2007
(31 p.)
pdf(p)J. RosenbergSIMPLEXML Formats for Representing Resource ListsIn multimedia communications, presence, and instant messaging systems, there is a need to define Uniform Resource Identifiers (URIs) that represent services that are associated with a group of users. One example is a resource list service. If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents. One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists that are referenced from the first. This list of users can be utilized by other applications and services. Both documents can be created and managed with the XML Configuration Access Protocol (XCAP).
This specification requests the registration of two new MIME types:
application/resource-lists+xml ,
application/rls-services+xml .
This specification registers two new AUIDs:
resource-lists ,
rls-services .
It registers two new XML namespaces:
urn:ietf:params:xml:ns:resource-lists ,
urn:ietf:params:xml:ns:rls-services .
It registers two new XML schemas:
urn:ietf:params:xml:schema:resource-lists ,
urn:ietf:params:xml:schema:rls-services . UpStatus:Proposed Standard RFC4827
05/2007
(11 p.)
pdf(p)M. Isomaki
E. LeppanenSIMPLEAn XCAP Usage for Manipulating Presence Document ContentsThis document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence documents. It is intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs on which it builds the overall presence state for the presentity.
This specification registers a new AUID: pidf-manipulation . UpStatus:Proposed Standard RFC4896
06/2007
(28 p.)
pdf(p)A. Surtees
M. West
A.B. RoachROHCSignaling Compression (SigComp) Corrections and ClarificationsThis document describes common misinterpretations and some ambiguities in the Signaling Compression Protocol (SigComp), and offers guidance to developers to resolve any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). UpStatus:Proposed Standard -- updates: RFC 3320 ,RFC 3321, RFC 3485 Topp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
06/2007
(19 p.)
pdf(p)V. Gurbani
C. JenningsIPTELRepresenting Trunk Groups in tel/sip URIsThis document describes a standardized mechanism to convey trunk group parameters insip and tel Uniform Resource Identifiers (URIs). An extension to the tel URI is defined for this purpose. UpStatus:Proposed Standard See also:RFC 3966
ABNF for "tel" URIRFC4916
06/2007
(24 p.)
pdf(p)J. ElwellSIPConnected Identity in SIPThis document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in theToheader field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway.
This document defines the SIP option tag 'from-change'. UpStatus:Proposed Standard -- updates: RFC 3261 RFC4960
09/2007
(152 p.)
pdf(p)R. StewartTSVWGStream Control Transmission Protocol (STCP)This document describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.
SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users: -acknowledged error-free non-duplicated transfer of user data, -data fragmentation to conform to discovered path MTU size, -sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, -optional bundling of multiple user messages into a single SCTP packet, and -network-level fault tolerance through supporting of multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. UpStatus:Proposed Standard -- obsoletes RFC 2960 ,RFC 3309RFC4964
09/2007
(32 p.)
pdf(p)A. Allen
J. Holm
T. HallinSIPPINGThe P-Answer-State Header Extension to SIP for the OMA Push to Talk over CellularThis document describes a private Session Initiation Protocol (SIP) header (P-header) used by the Open Mobile Alliance (OMA) for Push to talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application. The "P-Answer-State" header is used for indicating the answering mode of the handset, which is particular to the PoC application. UpStatus:Informational RFC4967
07/2007
(6 p.)
pdf(p)B. RosenIPTELDial String Parameter for the SIP URIRFC 3966explicitly states that 'tel' URIs may not represent a dial string. That leaves no way specify a dial string in a standardized way. Great confusion exists with the SIP URI parameter "user=phone", and specifically, if it can represent a dial string. This memo creates a new value for the user parameter "dialstring ", so that one may specify "user=dialstring" to encode a dial string as a 'sip:' or 'sips:' URI.
This RFC has been added to the references listed for the "user" parameter in the "SIP/SIPS URI Parameters " registry as defined inRFC 3969. UpStatus:Proposed Standard RFC4975
09/2007
(63 p.)
pdf(p)B. Campbell
R. Mahy
C. JenningsSIMPLEThe Message Session Relay Protocol (MSRP)This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol.
This specification instructs IANA to create a new registry for MSRP parameters:
http://www.iana.org/assignments/msrp-parameters, under which it introduces sub-registries for MSRP method names, status codes, and header field names. UpStatus:Proposed Standard RFC4976
09/2007
(36 p.)
pdf(p)C. Jennings
R. Mahy
A. B. RoachSIMPLERelay Extensions for the Message Session Relay Protocol (MSRP)Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a Session Initiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session Relay Protocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. UpStatus:Proposed Standard
Topp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
45xx
# RFC 4504 SIP Telephony Device Requirements# RFC 4508 Feature Tags with SIP REFER# RFC 4538 Request Authorization through Dialog Identification in SIP# RFC 4566 SDP: Session Description Protocol# RFC 4567 Key Management Extensions for SDP and RTSP# RFC 4568 SDP Security Descriptions for Media Streams# RFC 4569 Message Feature Tag# RFC 4570 SDP Source Filters# RFC 4572 Comedia over TLS in SDP# RFC 4574 SDP Label Attribute# RFC 4575 SIP Event Package for Conference State# RFC 4579 SIP Call Control - Conferencing for User Agents# RFC 4582 Binary Floor Control Protocol (BFCP)# RFC 4583 SDP Format for BFCP Streams# RFC 4589 Location Types Registry# RFC 4596 Guidelines for Usage of the SIP Caller Preferences Extension# RFC 4597 Conference ScenariosRFC450405/2006
(37 p.)
pdf(p)H. Sinnreich
S. Lass
C. Stredicke-SIP Telephony Device Requirements and ConfigurationThis document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones.
We present a glossary of the most common settings and some of the more widely used values for some settings. UpStatus:Informational RFC4508
05/2006
(6 p.)
pdf(p)O. Levin
A. JohnstonSIPConveying Feature Tags with the SIP REFER MethodThe SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request. The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request. This document extends the REFER method to use the mechanism ofRFC 3840. By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach. UpStatus:Proposed Standard RFC4538
06/2006
(17 p.)
pdf(p)J. RosenbergSIPRequest Authorization through Dialog Identification in SIPThis specification defines the "Target-Dialog" header field for the Session Initiation Protocol (SIP), and the corresponding 'tdialog' option tag. This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness. UpStatus:Proposed Standard RFC4566
07/2006
(49 p.)
pdf(p)M. Handley
V. Jacobson
C. PerkinsMMUSICSDP: Session Description ProtocolThis memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. UpStatus:Proposed Standard -- obsoletes RFC 2327 ,RFC 3266RFC4567
07/2006
(30 p.)
pdf(p)J. Arkko
F. Lindholm
M. Naslund
K. Norrman
E. CarraraMMUSICKey Management Extensions for SDP and RTSPThis document defines general extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol.
General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the Multimedia Internet KEYing (MIKEY) key management protocol is also defined. UpStatus:Proposed Standard RFC4568
07/2006
(44 p.)
pdf(p)F. Andreasen
M. Baugher
D. WingMMUSICSDP Security Descriptions for Media StreamsThis document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. UpStatus:Proposed Standard RFC4569
07/2006
(4 p.)
pdf(p)G. CamarilloSIPPINGIANA Registration of the 'Message' Media Feature TagThis document registers with the IANA (Internet Assigned Numbers Authority) a new media feature tag associated with the 'message' media type. This media feature tag indicates that a particular device supports 'message' as a streaming media type. Media feature tags can be used to route calls to devices that support certain features.
This new Media feature tag: sip.message (21) is placed into the SIP Media Feature Tag Registration Tree, which is defined inRFC 3840. UpStatus:Informational RFC4570
07/2006
(14 p.)
pdf(p)B. Quinn
R. FinlaysonMMUSICSDP Source FiltersThis document describes how to adapt the Session Description Protocol (SDP) to express one or more source addresses as a source filter for one or more destination "connection" addresses. It defines the syntax and semantics for an SDP "source-filter" attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations. In particular, an inclusive source-filter can be used to specify a Source-Specific Multicast (SSM) session. UpStatus:Proposed Standard RFC4572
07/2006
(17 p.)
pdf(p)J. LennoxMMUSICConnection-Oriented Media Transport over the TLS Protocol in SDPThis document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured. UpStatus:Proposed Standard -- updates: RFC 4145 RFC4574
08/2006
(8 p.)
pdf(p)O. Levin
G. CamarilloMMUSICThe SDP Label AttributeThis document defines a new Session Description Protocol (SDP) media-level attribute: "label". The "label" attribute carries a pointer to a media stream in the context of an arbitrary network application that uses SDP. The sender of the SDP document can attach the "label" attribute to a particular media stream or streams. The application can then use the provided pointer to refer to each particular media stream in its context. UpStatus:Proposed Standard RFC4575
08/2006
(40 p.)
pdf(p)J. Rosenberg
H. Schulzrinne
O. LevinSIPPINGA SIP Event Package for Conference StateThis document defines a 'conference' event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference Uniform Resource Identifier (URI). Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components.
This document registers a new MIME type, application/ conference-info+xml . UpStatus:Proposed Standard RFC4579
08/2006
(43 p.)
pdf(p)A. Johnston
O. LevinSIPPINGSIP Call Control - Conferencing for User AgentsThis specification defines conferencing call control features for the Session Initiation Protocol (SIP). This document builds on the Conferencing Requirements and Framework documents to define how a tightly coupled SIP conference works. The approach is explored from the perspective of different user agent (UA) types: conference-unaware, conference-aware, and focus UAs. The use of Uniform Resource Identifiers (URIs) in conferencing, OPTIONS for capabilities discovery, and call control using REFER are covered in detail with example call flow diagrams. The usage of the isfocus feature tag is defined. UpStatus:Best Current Practice (BCP: 119) RFC4582
11/2006
(65 p.)
pdf(p)G. Camarillo
J. Ott
K. DrageXCONThe Binary Floor Control Protocol (BFCP)Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.
This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers.
This RFC defines several sub-registries under
http://www.iana.org/assignments/bfcp-parameters:
"Attribute , "Primitive , "Request Status , and "Error Code . UpStatus:Proposed Standard RFC4583
11/2006
(12 p.)
pdf(p)G. CamarilloMMUSICSDP Format for Binary Floor Control Protocol (BFCP) StreamsThis document specifies how to describe Binary Floor Control Protocol (BFCP) streams in Session Description Protocol (SDP) descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. UpStatus:Proposed Standard RFC4589
07/2006
(12 p.)
pdf(p)H. Schulzrinne
H. TschofenigGEOPRIVLocation Types RegistryThis document creates a registry for describing the types of places a human or end system might be found. The registry is then referenced by other protocols that need a common set of location terms as protocol constants. Examples of location terms defined in this document include aircraft, office, and train station. UpStatus:Proposed Standard RFC4596
07/2006
(40 p.)
pdf(p)
pdf(v)J. Rosenberg
P. KyzivatSIPPINGGuidelines for Usage of the SIP Caller Preferences ExtensionThis document contains guidelines for usage of the Caller Preferences Extension to the Session Initiation Protocol (SIP). It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in Section 7.2 ofRFC 3841. UpStatus:Informational See also:RFC 3840, RFC 3841 RFC4597
07/2006
(17 p.)
pdf(p)R. Even
N. IsmailXCONConferencing ScenariosThis document describes multimedia conferencing scenarios. It describes both basic and advanced conferencing scenarios involving voice, video, text, and interactive text sessions. These scenarios will help with the definition and evaluation of the protocols being developed in the centralized conferencing XCON working group. UpStatus:Informational Topp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
46xx
# RFC 4648 Base-N Encodings# RFC 4660 Functional Description of Event Notification Filtering# RFC 4661 XML-Based Format for Event Notification Filtering# RFC 4662 SIP Event Notification Extension for Resource Lists# RFC 4694 Number Portability Parameters for the "tel" URIRFC464810/2006
(18 p.)
pdf(p)S. Josefsson-The Base16, Base32, and Base64 Data EncodingsThis document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. UpStatus:Proposed Standard RFC4660
09/2006
(31 p.)
pdf(p)H. Khartabil
E. Leppanen
M. Lonnfors
J. Costa-RequenaSIMPLEFunctional Description of Event Notification FilteringThe SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to the state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved.
This document describes the operations a subscriber performs in order to put filtering rules associated with a subscription to event notification information in place. The handling, by the subscriber, of responses to subscriptions carrying filtering rules and the handling of notifications with filtering rules applied to them are also described. Furthermore, the document conveys how the notifier behaves when receiving such filtering rules and how a notification is constructed. UpStatus:Proposed Standard RFC4661
09/2006
(24 p.)
pdf(p)H. Khartabil
E. Leppanen
M. Lonnfors
J. Costa-RequenaSIMPLEAn XML-Based Format for Event Notification FilteringThe SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved. Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying triggers that cause that information to be delivered. In order to enable this, a format is needed to enable the subscriber to describe the state changes of a resource that cause notifications to be sent to it and what those notifications are to contain. This document presents a format in the form of an XML document.
This document registers a new MIME type, application/ simple-filter+xml . UpStatus:Proposed Standard RFC4662
08/2006
(39 p.)
pdf(p)A. B. Roach
B. Campbell
J. RosenbergSIMPLEA SIP Event Notification Extension for Resource ListsThis document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list and then receive notifications when the state of any of the resources in the list changes.
This extension uses the 'eventlist' SIP option tag.
This document registers a new MIME type, application/ rlmi+xml . UpStatus:Proposed Standard RFC4694
10/2006
(15 p.)
pdf(p)J. YuIPTELNumber Portability Parameters for the "tel" URIThis document defines five parameters in the "tel" Uniform Resource Identifier (URI) to carry the number portability (NP)-related information. Those parameters can be passed to the next-hop network node after an NP database dip has been performed. UpStatus:Proposed Standard See also:RFC 3966
ABNF for "tel" URITopp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
47xx
# RFC 4715 ISDN for tel URI# RFC 4730 SIP Event Package for Key Press Stimulus (KPML)# RFC 4745 Common Policy: A Document Format for Expressing Privacy Preferences# RFC 4756 FEC Grouping Semantics in SDP# RFC 4759 ENUM Dip Indicator "tel" URI parameter# RFC 4769 IANA Registration for an Enumservice Containing PSTN Signaling Information# RFC 4770 vCard Extensions for Instant Messaging (IM)# RFC 4776 DHCPv4 and DHCPv6 Option for Civic Addresses Configuration Information# RFC 4780 SIP MIB Modules# RFC 4796 SDP Content AttributeRFC471511/2006
(14 p.)
pdf(p)M. Munakata
S. Schubert
T. OhbaIPTELThe ISDN Subaddress Encoding Type for tel URIWithout a tel URI parameter to carry an encoding type of Integrated Services Digital Network (ISDN) subaddress, interworking between ISDN User Part (ISUP) network and a Session Initiation Protocol (SIP) network is impossible in some cases. To solve this problem, this document specifies a new optional tel URI parameter to carry the encoding type of ISDN subaddress. UpStatus:Informational See also:RFC 3966
ABNF for "tel" URIRFC4730
11/2006
(56 p.)
pdf(p)E. Burger
M. DollySIPPINGA SIP Event Package for Key Press Stimulus (KPML)This document describes a SIP event package 'kpml' that enables monitoring of Dual Tone Multi-Frequency (DTMF) signals and uses Extensible Markup Language (XML) documents referred to as Key Press Markup Language (KPML).
The kpml Event Package may be used to support applications consistent with the principles defined indraft-ietf-sipping-app-interaction-framework.
The event package uses SUBSCRIBE messages and allows for XML documents that define and describe filter specifications for capturing key presses (DTMF Tones) entered at a presentation-free User Interface SIP User Agent (UA). The event package uses NOTIFY messages and allows for XML documents to report the captured key presses (DTMF tones), consistent with the filter specifications, to an Application Server. The scope of this package is for collecting supplemental key presses or mid-call key presses (triggers).
This document registers two new MIME types:
application/ kpml-request+xml and application/ kpml-response+xml . UpStatus:Proposed Standard RFC4745
02/2007
(32 p.)
pdf(p)H. Schulzrinne
J. Morris
H. Tschofenig
J. Cuellar
J. Polk
J. RosenbergGEOPRIVCommon Policy: A Document Format for Expressing Privacy PreferencesThis document defines a framework for authorization policies controlling access to application-specific data. This framework combines common location- and presence-specific authorization aspects. An XML schema specifies the language in which common policy rules are represented. The common policy framework can be extended to other application domains.
This specification requests the registration of a new MIME type:
application/auth-policy+xml .
It also registers a new XML namespace and a new XML schema:
urn:ietf:params:xml:ns:common-policy ,
urn:ietf:params:xml:schema:common-policy . UpStatus:Proposed Standard RFC4756
11/2006
(6 p.)
pdf(p)A. LiMMUSICForward Error Correction Grouping SemanticsThis document defines the semantics that allow for grouping of Forward Error Correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP). The semantics defined in this document are to be used with "Grouping of Media Lines in the Session Description Protocol" (RFC 3388) to group together "m" lines in the same session. UpStatus:Proposed Standard RFC4759
11/2006
(8 p.)
pdf(p)R. Stastny
R. Shockey
L. ConroyIPTELThe ENUM Dip Indicator Parameter for the "tel" URIThis document defines a new parameter "enumdi" for the "tel" Uniform Resource Identifier (URI) to support the handling of ENUM queries in Voice over Internet Protocol (VoIP) network elements. A VoIP network element may receive a URI containing an E.164 number, where that URI contains an "enumdi" parameter. The presence of the "enumdi" parameter indicates that an ENUM query has already been performed on the E.164 number by a previous VoIP network element. Equally, if a VoIP network element sends such a URI, it asserts that an ENUM query has been carried out on this number. UpStatus:Proposed Standard See also:RFC 3966
ABNF for "tel" URIRFC4769
11/2006
(13 p.)
pdf(p)J. Livingood
R. ShockeyENUMIANA Registration for an Enumservice Containing PSTN Signaling InformationThis document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype "sip" using the URI scheme 'sip' as per the IANA registration process defined in the ENUM specification,RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where number portability exists. UpStatus:Proposed Standard RFC4770
01/2007
(7 p.)
pdf(p)C. Jennings
J. ReschkeIMPPvCard Extensions for Instant Messaging (IM)This document describes an extension to vCard to support Instant Messaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books. It allows a URI that is associated with IM or PP to be specified inside a vCard. UpStatus:Proposed Standard RFC4776
11/2006
(19 p.)
pdf(p)H. SchulzrinneGEOPRIVDynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration InformationThis document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or the DHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages.
RFC Editor Note: RFC 4776 is being published to correct an error in the assignment of the numeric value of the DHCPv6 option-code in RFC 4676 (Section 3.2). UpStatus:Proposed Standard -- obsoletes RFC 4676 RFC4780
04/2007
(83 p.)
pdf(p)K. Lingle
J-F. Mule
J. Maeng
D. WalkerSIPManagement Information Base for SIPThis memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, and Proxy, Redirect and Registrar servers. UpStatus:Proposed Standard RFC4796
02/2007
(11 p.)
pdf(p)J. Hautakorpi
G. CamarilloMMUSICThe SDP Content AttributeThis document defines a new Session Description Protocol (SDP) media- level attribute, 'content'. The 'content' attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently (e.g., show it on a big or small screen) based on its content. UpStatus:Proposed Standard Topp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
48xx
# RFC 4825 XCAP# RFC 4826 XML Resource Lists# RFC 4827 XCAP for Manipulating Presence Document# RFC 4896 SigComp Corrections and ClarificationsRFC482505/2007
(71 p.)
pdf(p)J. RosenbergSIMPLEThe XML Configuration Access Protocol (XCAP)This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write, and modify application configuration data stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. This specification requests the registration of several new MIME types:
application/xcap-el+xml ,
application/xcap-att+xml ,
application/xcap-ns+xml ,
application/xcap-error+xml ,
application/xcap-caps+xml .
This specification instructs IANA to create a new registry for XCAP application unique IDs (AUIDs) with thexcap-caps initial entry (capabilities of an XCAP server).
It registers two new XML namespaces:
urn:ietf:params:xml:ns:xcap-error ,
urn:ietf:params:xml:ns:xcap-caps .
It registers two new XML schemas:
urn:ietf:params:xml:schema:xcap-error ,
urn:ietf:params:xml:schema:xcap-caps . UpStatus:Proposed Standard RFC4826
05/2007
(31 p.)
pdf(p)J. RosenbergSIMPLEXML Formats for Representing Resource ListsIn multimedia communications, presence, and instant messaging systems, there is a need to define Uniform Resource Identifiers (URIs) that represent services that are associated with a group of users. One example is a resource list service. If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents. One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists that are referenced from the first. This list of users can be utilized by other applications and services. Both documents can be created and managed with the XML Configuration Access Protocol (XCAP).
This specification requests the registration of two new MIME types:
application/resource-lists+xml ,
application/rls-services+xml .
This specification registers two new AUIDs:
resource-lists ,
rls-services .
It registers two new XML namespaces:
urn:ietf:params:xml:ns:resource-lists ,
urn:ietf:params:xml:ns:rls-services .
It registers two new XML schemas:
urn:ietf:params:xml:schema:resource-lists ,
urn:ietf:params:xml:schema:rls-services . UpStatus:Proposed Standard RFC4827
05/2007
(11 p.)
pdf(p)M. Isomaki
E. LeppanenSIMPLEAn XCAP Usage for Manipulating Presence Document ContentsThis document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence documents. It is intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs on which it builds the overall presence state for the presentity.
This specification registers a new AUID: pidf-manipulation . UpStatus:Proposed Standard RFC4896
06/2007
(28 p.)
pdf(p)A. Surtees
M. West
A.B. RoachROHCSignaling Compression (SigComp) Corrections and ClarificationsThis document describes common misinterpretations and some ambiguities in the Signaling Compression Protocol (SigComp), and offers guidance to developers to resolve any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). UpStatus:Proposed Standard -- updates: RFC 3320 ,RFC 3321, RFC 3485 Topp. 13261-32xx33xx34xx35xx36xx37xx38xx39xx PrevNext40xx41xx42xx43xx44xx45xx46xx47xx 48xx49xx50xx51xx52xx53xx54xx55xx 56xx57xx58xx59xx60xx61xx62xxBefore 3261
49xx
# RFC 4904 Trunk Groups in tel/sip URIs# RFC 4916 SIP Connected ID# RFC 4960 Stream Control Transmission Protocol (SCTP)# RFC 4964 P-Answer-State Header for OMA PoC# RFC 4967 Dial String Parameter for the SIP URI# RFC 4975 Message Session Relay Protocol (MSRP)# RFC 4976 MSRP RelaysRFC490406/2007
(19 p.)
pdf(p)V. Gurbani
C. JenningsIPTELRepresenting Trunk Groups in tel/sip URIsThis document describes a standardized mechanism to convey trunk group parameters insip and tel Uniform Resource Identifiers (URIs). An extension to the tel URI is defined for this purpose. UpStatus:Proposed Standard See also:RFC 3966
ABNF for "tel" URIRFC4916
06/2007
(24 p.)
pdf(p)J. ElwellSIPConnected Identity in SIPThis document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in theToheader field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway.
This document defines the SIP option tag 'from-change'. UpStatus:Proposed Standard -- updates: RFC 3261 RFC4960
09/2007
(152 p.)
pdf(p)R. StewartTSVWGStream Control Transmission Protocol (STCP)This document describes the Stream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks, but is capable of broader applications.
SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users: -acknowledged error-free non-duplicated transfer of user data, -data fragmentation to conform to discovered path MTU size, -sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages, -optional bundling of multiple user messages into a single SCTP packet, and -network-level fault tolerance through supporting of multi-homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks. UpStatus:Proposed Standard -- obsoletes RFC 2960 ,RFC 3309RFC4964
09/2007
(32 p.)
pdf(p)A. Allen
J. Holm
T. HallinSIPPINGThe P-Answer-State Header Extension to SIP for the OMA Push to Talk over CellularThis document describes a private Session Initiation Protocol (SIP) header (P-header) used by the Open Mobile Alliance (OMA) for Push to talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application. The "P-Answer-State" header is used for indicating the answering mode of the handset, which is particular to the PoC application. UpStatus:Informational RFC4967
07/2007
(6 p.)
pdf(p)B. RosenIPTELDial String Parameter for the SIP URIRFC 3966explicitly states that 'tel' URIs may not represent a dial string. That leaves no way specify a dial string in a standardized way. Great confusion exists with the SIP URI parameter "user=phone", and specifically, if it can represent a dial string. This memo creates a new value for the user parameter "dialstring ", so that one may specify "user=dialstring" to encode a dial string as a 'sip:' or 'sips:' URI.
This RFC has been added to the references listed for the "user" parameter in the "SIP/SIPS URI Parameters " registry as defined inRFC 3969. UpStatus:Proposed Standard RFC4975
09/2007
(63 p.)
pdf(p)B. Campbell
R. Mahy
C. JenningsSIMPLEThe Message Session Relay Protocol (MSRP)This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol.
This specification instructs IANA to create a new registry for MSRP parameters:
http://www.iana.org/assignments/msrp-parameters, under which it introduces sub-registries for MSRP method names, status codes, and header field names. UpStatus:Proposed Standard RFC4976
09/2007
(36 p.)
pdf(p)C. Jennings
R. Mahy
A. B. RoachSIMPLERelay Extensions for the Message Session Relay Protocol (MSRP)Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a Session Initiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session Relay Protocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. UpStatus:Proposed Standard
