|
|
|
| |
|
|
|
|
|
|
| | | | RFC5002
08/2007
(7 p.)
pdf(p) | G. Camarillo
G. Blanco | SIPPING |
| The SIP P-Profile-Key Private Header (P-Header) | | This document specifies the SIP "P-Profile-Key " P-header. This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the key of the profile corresponding to the destination SIP URI of a particular SIP request. |
|
|
|
|
|
|
|
| | | | RFC5009
09/2007
(15 p.)
pdf(p) | R. Ejzak | SIPPING |
| P-Header Extension to SIP for Authorization of Early Media | | This document describes the "P-Early-Media " private header field (P-Header) to be used by the European Telecommunications Standards Institute (ETSI) Telecommunications and Internet-converged Services and Protocols for Advanced Networks (TISPAN) for the purpose of authorizing early media flows in Third Generation Partnership Project (3GPP) IP Multimedia Subsystems (IMS). This header field is useful in any SIP network that is interconnected with other SIP networks and needs to control the flow of media in the early dialog state. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | | RFC5022
09/2007
(81 p.)
pdf(p) | J. Van Dyke
E. Burger
A. Spitzer | - |
| Media Server Control Markup Language (MSCML) and Protocol | See IESG Note: This RFC is not a candidate for any level of Internet Standard...
Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework.
This document describes the MSCML and its usage. It describes payloads that one can send to a media server using standard SIP INVITE and INFO methods and the capabilities these payloads implement. It registers a new MIME type, application/ mediaservercontrol+xml .
Prior to MSCML, there was not a standard way to deliver SIP-based enhanced conferencing. Basic SIP constructs, such as those described in RFC4240 , serve simple n-way conferencing well. The SIP URI provides a natural mechanism for identifying a specific SIP conference, while INVITE and BYE methods elegantly implement conference join and leave semantics. However, enhanced conferencing applications also require features such as sizing and resizing, in- conference IVR operations (e.g., recording and playing participant names to the full conference), and conference event reporting. MSCML payloads within standard SIP methods realize these features.
The structure and approach of MSCML satisfy the requirements set out in RFC4353 . In particular, MSCML serves as the interface between the conference server or focus and a centralized conference mixer. In this case, a media server has the role of the conference mixer.
MSCML fills the need for IVR and conference control with requests and responses over a SIP transport. VoiceXML [W3C REC REC-voicexml20 ] fills the need for IVR with requests and responses over a HTTP transport. This enables developers to use whatever model fits their needs best. The media server fulfills the role of the Media Resource Function (MRF) in the IP Multimedia Subsystem (IMS) [3GPP TS 23.228 ] as described by 3GPP. MSCML and RFC4240 , upon which MSCML builds, are specifically focused on the Media resource (Mr) interface which supports interactions between application logic and the MRF. |
|
|
|
|
|
|
|
| | | | RFC5025
12/2007
(28 p.)
pdf(p) | J. Rosenberg | SIMPLE |
| Presence Authorization Rules | Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted.
This specification requests the following registrations at the IANA:
pres-rules AUID,
urn:ietf:params:xml:ns:pres-rules XML namespace,
urn:ietf:params:xml:schema:pres-rules XML schema. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC5027
10/2007
(16 p.)
pdf(p) | F. Andreasen
D. Wing | MMUSIC |
| Security Preconditions for SDP Media Streams | | This document defines a new security precondition ("sec ") for the Session Description Protocol (SDP) precondition framework described in RFC 3312 and RFC 4032 . A security precondition can be used to delay session establishment or modification until media stream security for a secure media stream has been negotiated successfully. |
|
|
|
|
|
|
|
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC5031
01/2008
(15 p.)
pdf(p) | H. Schulzrinne | ECRIT |
| A Uniform Resource Name (URN) for Emergency and Other Well-Known Services | | The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows well-known context-dependent services that can be resolved in a distributed manner to be identified. Examples include emergency services, directory assistance, and call-before-you-dig hot lines. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC5039
01/2008
(28 p.)
pdf(p) | J. Rosenberg
C. Jennings | SIPPING |
| SIP and Spam | | Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email. It can affect any system that enables user-to-user communications. The Session Initiation Protocol (SIP) defines a system for user-to-user multimedia communications. Therefore, it is susceptible to spam, just as email is. In this document, we analyze the problem of spam in SIP. We first identify the ways in which the problem is the same and the ways in which it is different from email. We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP. |
|
|
|
|
|
|
|
| | | | RFC5049
12/2007
(21 p.)
pdf(p) | C. Bormann
Z. Liu
R. Price
G. Camarillo | ROHC |
| Applying Signaling Compression (SigComp) to SIP | | This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP and Session Description Protocol (SDP) static dictionary. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC5057
11/2007
(26 p.)
pdf(p) | R. Mahy | SIPPING |
| Multiple Dialog Usages in SIP | Several methods in the Session Initiation Protocol (SIP) can create an association between endpoints known as a dialog. Some of these methods can also create a different, but related, association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. Processing multiple dialog usages correctly is not completely understood. What is understood is difficult to implement.
This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them. This is an informative document and makes no normative statements of any kind. |
|
|
|
|
|
|
|
| | | | RFC5067
11/2007
(7 p.)
pdf(p) | S. Lind
P. Pfautz | ENUM |
| Infrastructure ENUM Requirements | | This document provides requirements for "infrastructure" or "carrier" ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) |
|
|
|
|
|
|
|
| | | | RFC5069
01/2008
(12 p.)
pdf(p) | T. Taylor
H. Tschofenig
H. Schulzrinne
M. Shanmugam | ECRIT |
| Security Threats and Requirements for Emergency Call Marking and Mapping | This document reviews the security threats associated with the marking of signalling messages to indicate that they are related to an emergency, and with the process of mapping locations to Universal Resource Identifiers (URIs) that point to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network.
Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls. |
|
|
|
|
|
|
|
| | | | RFC5079
12/2007
(8 p.)
pdf(p) | J. Rosenberg | SIP |
| Rejecting Anonymous Requests in SIP | The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity.
This specification defines a new SIP response code for this purpose: '433 Anonymity Disallowed' . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| |
|
|
|
|
|
|
| | | | RFC5112
01/2008
(25 p.)
pdf(p) | M. Garcia-Martin | SIMPLE |
| The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp) | | The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol is extended by the SIP-events notification framework to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is presence, which is expressed in XML documents called presence documents. SIP can be compressed by using Signaling Compression (SigComp), which is enhanced by using the SIP/ Session Description Protocol (SDP) dictionary to achieve better compression rates. However, the SIP/SDP dictionary is not able to increase the compression factor of (typically lengthy) presence documents. This memo defines the presence-specific static dictionary that SigComp can use in order to compress presence documents to achieve higher efficiency. The dictionary is compression-algorithm independent. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC5115
01/2008
(8 p.)
pdf(p) | K. Carlberg
P. O'Hanlon | - |
| Telephony Routing over IP (TRIP) Attribute for Resource Priority | | This document defines a new attribute for the Telephony Routing over IP (TRIP) protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the Public Switched Telephone Network (PSTN) are Government Emergency Telecommunications Service (GETS) in the U.S. and Government Telephone Preference Scheme (GTPS) in the U.K. The proposed attribute for TRIP is based on the NameSpace.Value tuple defined for the SIP Resource-Priority field. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC5118
02/2008
(18 p.)
pdf(p) | V. Gurbani
C. Boulton
R. Sparks | SIPPING |
| SIP Torture Test Messages for IPv6 | | This document provides examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" the code of an IPv6-enabled SIP implementation. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | | RFC5139
02/2008
(14 p.)
pdf(p) | M. Thomson
J. Winterbottom | GEOPRIV |
| Revised Civic Location Format for PIDF Location Object (PIDF-LO) | | This document defines an XML format for the representation of civic location. This format is designed for use with Presence Information Data Format Location Object (PIDF-LO) documents and replaces the civic location format in RFC 4119 . The format is based on the civic address definition in PIDF-LO, but adds several new elements based on the civic types defined for Dynamic Host Configuration Protocol (DHCP), and adds a hierarchy to address complex road identity schemes. The format also includes support for the xml:lang language tag and restricts the types of elements where appropriate. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | | | RFC5167
03/2008
(9 p.)
pdf(p) | M. Dolly
R. Even | MEDIACTRL |
| Media Server Control Protocol Requirements | This document addresses the communication between an application server and media server. The current work in IETF working groups shows these logical entities, but it does not address the physical decomposition and the protocol between the entities.
This document presents the requirements for a Media Server Control Protocol (MCP) that enables an application server to use a media server. It will address the aspects of announcements, Interactive Voice Response, and conferencing media services. |
|
|
|
|
|
|
|
| | | | RFC5194
06/2008
(31 p.)
pdf(p) | A. van Wijk
G. Gybels | SIPPING |
| Framework for Real-Time Text over IP using SIP | | This document lists the essential requirements for real-time Text- over-IP (ToIP) and defines a framework for implementation of all required functions based on the Session Initiation Protocol (SIP) and the Real-Time Transport Protocol (RTP). This includes interworking between Text-over-IP and existing text telephony on the Public Switched Telephone Network (PSTN) and other networks. |
|
|
|
|
|
|
|
| | | | RFC5196
09/2008
(30 p.)
pdf(p) | M. Lonnfors
K. Kiss | SIMPLE |
| SIP User Agent Capability Extension to PIDF | Presence Information Data Format (PIDF) defines a common presence data format for Common Profile for Presence (CPP) compliant presence protocols. This memo defines a PIDF extension to represent SIP User Agent capabilities.
IANA has registered one new XML namespace URN and one schema:
urn:ietf:params:xml:ns:pidf:caps
urn:ietf:params:xml:schema:pidf:caps |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| |
|
|
|
|
|
|
| | | | RFC5222
08/2008
(69 p.)
pdf(p) | T. Hardie
A. Newton
H. Schulzrinne
H. Tschofenig | ECRIT |
| LoST: A Location-to-Service Translation Protocol | | This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC5223
08/2008
(8 p.)
pdf(p) | H. Schulzrinne
J. Polk
H. Tschofenig | ECRIT |
| Discovering Location-to-Service Translation (LoST) Servers Using DHCP | The Location-to-Service Translation (LoST) Protocol describes an XML-based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere, but a placement closer to the end host, e.g., in the access network, is desirable. In disaster situations with intermittent network connectivity, such a LoST server placement provides benefits regarding the resiliency of emergency service communication.
This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC5239
06/2008
(57 p.)
pdf(p) | M. Barnes
C. Boulton
O. Levin | XCON |
| A Framework for Centralized Conferencing | | This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISDN User Part (ISUP), to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC5261
08/2008
(40 p.)
pdf(p) | J. Urpalainen | SIMPLE |
| An XML Patch Operations Framework Utilizing XML Path Language (XPath) Selectors | | Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic <add>, <replace>, and <remove> directives a set of patches can then be applied to update an existing XML document. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC5262
09/2008
(16 p.)
pdf(p) | M. Lonnfors
E. Leppanen
H. Khartabil
J. Urpalainen | SIMPLE |
| PIDF Extension for Partial Presence | The Presence Information Document Format (PIDF) specifies the baseline XML-based format for describing presence information. One of the characteristics of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist, it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type that enables transporting of either only the changed parts or the full PIDF-based presence information.
This specification requests the registration of a new MIME type:
application/pidf-diff+xml . |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC5263
09/2008
(16 p.)
pdf(p) | M. Lonnfors
J. Costa-Requena
E. Leppanen
H. Khartabil | SIMPLE |
| SIP Extension for Partial Notification of Presence Information | | By default, presence delivered using the presence event package for the Session Initiation Protocol (SIP) is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of only the presence data that has actually changed. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC5264
09/2008
(15 p.)
pdf(p) | A. Niemi
M. Lonnfors
E. Leppanen | SIMPLE |
| Publication of Partial Presence Information | | The Session Initiation Protocol (SIP) Extension for Event State Publication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using the Presence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bears a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitute a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC5278
07/2008
(22 p.)
pdf(p) | J. Livingood
D. Troshynski | ENUM |
| IANA Registration of Enumservices for Voice and Video Messaging | | This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice, video, and unified communications to a messaging system. This vmsg Enumservice registers three Enumservice types: "voicemsg", "videomsg", and "unifmsg". Each type also registers the subtypes "sip", "sips", "http", and "https", as well as the subtype "tel" for the "voicemsg" type. |
|
|
| | | Up | Status: | Proposed Standard | |
|
|
|
|
| | | | RFC5279
07/2008
(7 p.)
pdf(p) | A. Monrad
S. Loreto | SIPPING |
| A Uniform Resource Name (URN) Namespace for the 3GPP | | This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the 3rd Generation Partnership Project (3GPP). 3GPP defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the 3GPP Support Team. |
|
|
|
|
278
非常没帮助
没帮助
一般
有帮助
非常有帮助
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
