|
|
|
| |
|
|
|
|
|
|
| | | | RFC4504
05/2006
(37 p.)
pdf(p) | H. Sinnreich
S. Lass
C. Stredicke | - |
| SIP Telephony Device Requirements and Configuration | This 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. |
|
|
|
|
|
|
|
| | | | RFC4508
05/2006
(6 p.)
pdf(p) | O. Levin
A. Johnston | SIP |
| Conveying Feature Tags with the SIP REFER Method | | The SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request. The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request. This document extends the REFER method to use the mechanism of RFC 3840 . By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4538
06/2006
(17 p.)
pdf(p) | J. Rosenberg | SIP |
| Request Authorization through Dialog Identification in SIP | | This 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4566
07/2006
(49 p.)
pdf(p) | M. Handley
V. Jacobson
C. Perkins | MMUSIC |
| SDP: Session Description Protocol | | This 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. |
|
|
|
|
|
|
|
| | | | RFC4567
07/2006
(30 p.)
pdf(p) | J. Arkko
F. Lindholm
M. Naslund
K. Norrman
E. Carrara | MMUSIC |
| Key Management Extensions for SDP and RTSP | This 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4568
07/2006
(44 p.)
pdf(p) | F. Andreasen
M. Baugher
D. Wing | MMUSIC |
| SDP Security Descriptions for Media Streams | | This 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4569
07/2006
(4 p.)
pdf(p) | G. Camarillo | SIPPING |
| IANA Registration of the 'Message' Media Feature Tag | This 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 in RFC 3840 . |
|
|
|
|
|
|
|
| | | | RFC4570
07/2006
(14 p.)
pdf(p) | B. Quinn
R. Finlayson | MMUSIC |
| SDP Source Filters | | This 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4572
07/2006
(17 p.)
pdf(p) | J. Lennox | MMUSIC |
| Connection-Oriented Media Transport over the TLS Protocol in SDP | | This 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. |
|
|
|
|
|
|
|
| | | | RFC4574
08/2006
(8 p.)
pdf(p) | O. Levin
G. Camarillo | MMUSIC |
| The SDP Label Attribute | | This 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4575
08/2006
(40 p.)
pdf(p) | J. Rosenberg
H. Schulzrinne
O. Levin | SIPPING |
| A SIP Event Package for Conference State | This 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 . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4579
08/2006
(43 p.)
pdf(p) | A. Johnston
O. Levin | SIPPING |
| SIP Call Control - Conferencing for User Agents | | This 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. |
|
|
| | | Up | Status: | Best Current Practice (BCP: 119) | |
|
|
|
|
| | | | RFC4582
11/2006
(65 p.)
pdf(p) | G. Camarillo
J. Ott
K. Drage | XCON |
| The Binary Floor Control Protocol (BFCP) | Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.
This 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 . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4589
07/2006
(12 p.)
pdf(p) | H. Schulzrinne
H. Tschofenig | GEOPRIV |
| Location Types Registry | | This 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4596
07/2006
(40 p.)
pdf(p)
pdf(v) | J. Rosenberg
P. Kyzivat | SIPPING |
| Guidelines for Usage of the SIP Caller Preferences Extension | | This 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 of RFC 3841 . |
|
|
|
|
|
|
|
| | | | RFC4597
07/2006
(17 p.)
pdf(p) | R. Even
N. Ismail | XCON |
| Conferencing Scenarios | | This 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. |
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
| | | | RFC4648
10/2006
(18 p.)
pdf(p) | S. Josefsson | - |
| The Base16, Base32, and Base64 Data Encodings | | This 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4660
09/2006
(31 p.)
pdf(p) | H. Khartabil
E. Leppanen
M. Lonnfors
J. Costa-Requena | SIMPLE |
| Functional Description of Event Notification Filtering | The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to the state of a resource. The 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4661
09/2006
(24 p.)
pdf(p) | H. Khartabil
E. Leppanen
M. Lonnfors
J. Costa-Requena | SIMPLE |
| An XML-Based Format for Event Notification Filtering | The SIP event notification framework describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The 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 . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4662
08/2006
(39 p.)
pdf(p) | A. B. Roach
B. Campbell
J. Rosenberg | SIMPLE |
| A SIP Event Notification Extension for Resource Lists | This 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 . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4694
10/2006
(15 p.)
pdf(p) | J. Yu | IPTEL |
| Number Portability Parameters for the "tel" URI | | This 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. |
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
| | | | RFC4715
11/2006
(14 p.)
pdf(p) | M. Munakata
S. Schubert
T. Ohba | IPTEL |
| The ISDN Subaddress Encoding Type for tel URI | | Without 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. |
|
|
|
|
|
|
|
| | | | RFC4730
11/2006
(56 p.)
pdf(p) | E. Burger
M. Dolly | SIPPING |
| A 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 in draft-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 . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4745
02/2007
(32 p.)
pdf(p) | H. Schulzrinne
J. Morris
H. Tschofenig
J. Cuellar
J. Polk
J. Rosenberg | GEOPRIV |
| Common Policy: A Document Format for Expressing Privacy Preferences | This 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 . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4756
11/2006
(6 p.)
pdf(p) | A. Li | MMUSIC |
| Forward Error Correction Grouping Semantics | | This 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4759
11/2006
(8 p.)
pdf(p) | R. Stastny
R. Shockey
L. Conroy | IPTEL |
| The ENUM Dip Indicator Parameter for the "tel" URI | | This 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. |
|
|
|
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4770
01/2007
(7 p.)
pdf(p) | C. Jennings
J. Reschke | IMPP |
| vCard 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4776
11/2006
(19 p.)
pdf(p) | H. Schulzrinne | GEOPRIV |
| Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information | This 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). |
|
|
|
|
|
|
|
| | | | RFC4780
04/2007
(83 p.)
pdf(p) | K. Lingle
J-F. Mule
J. Maeng
D. Walker | SIP |
| Management Information Base for SIP | | This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Session Initiation Protocol (SIP) entities, which include User Agents, and Proxy, Redirect and Registrar servers. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4796
02/2007
(11 p.)
pdf(p) | J. Hautakorpi
G. Camarillo | MMUSIC |
| The SDP Content Attribute | | This 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| |
|
|
|
|
|
|
| | | | RFC4825
05/2007
(71 p.)
pdf(p) | J. Rosenberg | SIMPLE |
| The 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 the xcap-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 . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4826
05/2007
(31 p.)
pdf(p) | J. Rosenberg | SIMPLE |
| XML Formats for Representing Resource Lists | In multimedia communications, presence, and instant messaging systems, there is a need to define Uniform Resource Identifiers (URIs) that represent services that are associated with a group of users. One example is a resource list service. If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents. One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists that are referenced from the first. This list of users can be utilized by other applications and services. Both documents can be created and managed with the XML Configuration Access Protocol (XCAP).
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 . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4827
05/2007
(11 p.)
pdf(p) | M. Isomaki
E. Leppanen | SIMPLE |
| An XCAP Usage for Manipulating Presence Document Contents | This 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 . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4896
06/2007
(28 p.)
pdf(p) | A. Surtees
M. West
A.B. Roach | ROHC |
| Signaling Compression (SigComp) Corrections and Clarifications | | This 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). |
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | | RFC4916
06/2007
(24 p.)
pdf(p) | J. Elwell | SIP |
| Connected Identity in SIP | This 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 the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway.
This document defines the SIP option tag 'from-change '. |
|
|
|
|
|
|
|
| | | | RFC4960
09/2007
(152 p.)
pdf(p) | R. Stewart | TSVWG |
| Stream 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. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | | RFC4967
07/2007
(6 p.)
pdf(p) | B. Rosen | IPTEL |
| Dial String Parameter for the SIP URI | RFC 3966 explicitly 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 in RFC 3969 . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4975
09/2007
(63 p.)
pdf(p) | B. Campbell
R. Mahy
C. Jennings | SIMPLE |
| The 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. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC4976
09/2007
(36 p.)
pdf(p) | C. Jennings
R. Mahy
A. B. Roach | SIMPLE |
| Relay Extensions for the Message Session Relay Protocol (MSRP) | | Two separate models for conveying instant messages have been defined. Page-mode messages stand alone and are not part of a Session Initiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session Relay Protocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP. This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. |
|
|
| | | Up | Status: | Proposed Standard | |
|
扫一扫
664
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
