|
|
|
| |
|
|
|
|
|
|
| | | | RFC5318
12/2008
(12 p.)
pdf(p) | J. Hautakorpi
G. Camarillo | SIPPING |
| SIP P-Refused-URI-List Private-Header | | This document specifies the Session Initiation Protocol (SIP) "P-Refused-URI-List " Private-Header (P-Header). This P-Header is used in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system. It enables URI-list servers to refuse the handling of incoming URI lists that have embedded URI lists. This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI list that caused the rejection and the individual URIs that form such a URI list. |
|
|
|
|
| |
| |
| |
| | | | RFC5321
10/2008
(95 p.)
pdf(p) | J. Klensin | - |
| Simple Mail Transfer Protocol | | This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. |
|
|
|
|
|
|
|
| | | | RFC5322
10/2008
(57 p.)
pdf(p) | P. Resnick | - |
| Internet Message Format | | This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. |
|
|
|
|
|
|
|
| | | | RFC5341
09/2008
(7 p.)
pdf(p) | C. Jennings
V. Gurbani | IPTEL |
| The IANA tel Uniform Resource Identifier (URI) Parameter Registry | | This document creates an Internet Assigned Number Authority (IANA) registry for tel Uniform Resource Identifier (URI) parameters and their values. It populates the registry with the parameters defined in the tel URI specification, along with the parameters in tel URI extensions defined for number portability and trunk groups. |
|
|
|
|
|
|
|
| | | | RFC5344
10/2008
(9 p.)
pdf(p) | A. Houri
E. Aoki
S. Parameswar | SPEERMINT |
| Presence and Instant Messaging Peering Use Cases | | This document describes several use cases of peering of non-VoIP (Voice over IP) services between two or more Service Providers. These Service Providers create a peering relationship between themselves, thus enabling their users to collaborate with users on the other Service Provider network. The target of this document is to drive requirements for peering between domains that provide the non-VoIP based collaboration services with presence and, in particular, Instant Messaging (IM). |
|
|
|
|
| |
| |
| |
| | | | RFC5359
10/2008
(170 p.)
pdf(v)
pdf(p) | A. Johnston
R. Sparks
C. Cunningham
S. Donovan
K. Summers | SIPPING |
| SIP Service Examples | | This document gives examples of Session Initiation Protocol (SIP) services. This covers most features offered in so-called IP Centrex offerings from local exchange carriers and PBX (Private Branch Exchange) features. Most of the services shown in this document are implemented in the SIP user agents, although some require the assistance of a SIP proxy. Some require some extensions to SIP including the REFER , SUBSCRIBE , and NOTIFY methods and the Replaces and Join header fields. These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
|
|
|
|
|
|
| | | | RFC5360
10/2008
(31 p.)
pdf(p) | J. Rosenberg
G. Camarillo
D. Willis | SIP |
| A Framework for Consent-Based Communications in SIP | SIP supports communications for several services, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification and DoS (Denial of Service) attacks. This document identifies a framework for consent-based communications in SIP.
This document defines the "Trigger-Consent " and "Permission-Missing " header fields, as well as a new SIP response code: '470 Consent Needed' . |
|
|
| | | Up | Status: | Proposed Standard | | |
|
| |
| |
| |
| | | | RFC5361
10/2008
(14 p.)
pdf(p) | G. Camarillo | SIPPING |
| A Document Format for Requesting Consent | This document defines an Extensible Markup Language (XML) format for a permission document used to request consent. A permission document written in this format is used by a relay to request a specific recipient permission to perform a particular routing translation.
This specification requests the following registrations at the IANA:
urn:ietf:params:xml:ns:consent-rules XML namespace,
urn:ietf:params:xml:schema:consent-rules XML schema. |
|
|
| | | Up | Status: | Proposed Standard | | |
|
| |
| |
| |
|
|
| | | Up | Status: | Proposed Standard | | |
|
| |
| |
| |
|
|
| | | Up | Status: | Proposed Standard | | |
|
| |
| |
| |
| | | | RFC5364
10/2008
(17 p.)
pdf(p) | M. Garcia-Martin
G. Camarillo | SIPPING |
| XML Format Extension for Representing Copy Control Attributes in Resource Lists | | In certain types of multimedia communications, a Session Initiation Protocol (SIP) request is distributed to a group of SIP User Agents (UAs). The sender sends a single SIP request to a server which further distributes the request to the group. This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request. This URI list is expressed as a resource list XML document. This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing email systems. |
|
|
| | | Up | Status: | Proposed Standard | | |
|
| |
| |
| |
| | | | RFC5365
10/2008
(18 p.)
pdf(p) | M. Garcia-Martin
G. Camarillo | SIP |
| Multiple-Recipient MESSAGE Requests in SIP | This document specifies a mechanism that allows a SIP User Agent Client (UAC) to send a SIP MESSAGE request to a set of destinations, by using a SIP URI-list (Uniform Resource Identifier list) service. The UAC sends a SIP MESSAGE request that includes the payload along with the URI list to the MESSAGE URI-list service, which sends a MESSAGE request including the payload to each of the URIs included in the list.
This document defines the 'recipient-list-message ' SIP option tag. |
|
|
| | | Up | Status: | Proposed Standard | | |
|
| |
| |
| |
|
|
| | | Up | Status: | Proposed Standard | | |
|
| |
| |
| |
| | | | RFC5367
10/2008
(9 p.)
pdf(p) | G. Camarillo
A.B. Roach
O. Levin | SIP |
| Subscriptions to Request-Contained Resource Lists in SIP | This document specifies a way to create subscription to a list of resources in SIP. This is achieved by including the list of resources in the body of a SUBSCRIBE request. Instead of having a subscriber send a SUBSCRIBE request for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' states using a single SUBSCRIBE dialog.
This document defines the 'recipient-list-subscribe ' SIP option tag, and the 'list-management' value for the "purpose" parameter of the Call-Info header field. |
|
|
|
|
|
|
|
| | | | RFC5368
10/2008
(13 p.)
pdf(p) | G. Camarillo
A. Niemi
M. Isomaki
M. Garcia-Martin
H. Khartabil | SIP |
| Referring to Multiple Resources in SIP | | This document defines extensions to the SIP REFER method so that it can be used to refer to multiple resources in a single request. These extensions include the use of pointers to Uniform Resource Identifier (URI) lists in the Refer-To header field and the 'multiple-refer ' SIP option-tag. |
|
|
| | | Up | Status: | Proposed Standard | | |
|
| |
| |
| |
| | | | RFC5369
10/2008
(10 p.)
pdf(p) | G. Camarillo | SIPPING |
| Framework for Transcoding with SIP | | This document defines a framework for transcoding with SIP. This framework includes how to discover the need for transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed: the conference bridge model and the third-party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. |
|
|
|
|
| |
| |
| |
| | | | RFC5370
10/2008
(11 p.)
pdf(p) | G. Camarillo | SIPPING |
| The SIP Conference Bridge Transcoding Model | | This document describes how to invoke transcoding services using the conference bridge model. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. |
|
|
| | | Up | Status: | Proposed Standard | | |
|
| |
| |
| |
| | | | RFC5373
11/2008
(24 p.)
pdf(p) | D. Willis
A. Allen | SIP |
| Requesting Answering Modes for SIP | This document extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode ", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or, instead, accepts the request without waiting on user input. The second header, "Priv-Answer-Mode ", is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as push-to-talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined.
This specification defines the 'answermode ' SIP option tag. |
|
|
| | | Up | Status: | Proposed Standard | | |
|
| |
| |
| |
| | | | RFC5390
12/2008
(14 p.)
pdf(p) | J. Rosenberg | SIPPING |
| Requirements for Management of Overload in SIP | | Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insufficient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This document summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution. |
|
|
|
|
| |
| |
| |
| | | | RFC5393
12/2008
(20 p.)
pdf(v)
pdf(p) | R. Sparks
S. Lawrence
A. Hawrylyshen
B. Campen | SIP |
| Addressing an Amplification Vulnerability in SIP Forking Proxies | This document normatively updates RFC 3261 , the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic.
This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a "Max-Breadth " mechanism for limiting the number of concurrent branches pursued for any given request.
This document defines the "Max-Breadth " header field, as well as a new SIP response code: '440 Max-Breadth Exceeded' . |
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
| | | | RFC5407
12/2008
(60 p.)
pdf(p) | M. Hasebe
J. Koshiko
Y. Suzuki
T. Yoshikawa
P. Kyzivat | SIPPING |
| Example Call Flows of Race Conditions in SIP | | This document gives example call flows of race conditions in the Session Initiation Protocol (SIP). Race conditions are inherently confusing and difficult to thwart; this document shows the best practices to handle them. The elements in these call flows include SIP User Agents and SIP Proxy Servers. Call flow diagrams and message details are given. |
|
|
| | | Up | Status: | Best Current Practice (BCP: 147) | | |
|
| |
| |
| |
| | | | RFC5411
02/2009
(39 p.)
pdf(p) | J. Rosenberg | SIPPING |
| Hitchhiker's Guide to SIP | | The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. This specification serves as a guide to the SIP RFC series. It lists a current snapshot of the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. |
|
|
|
|
| |
| |
| |
| | | | RFC5432
03/2009
(9 p.)
pdf(p) | J. Polk
S. Dhesikan
G. Camarillo | MMUSIC |
| Quality of Service (QoS) Mechanism Selection in SDP | | The offer/answer model for the Session Description Protocol (SDP) assumes that endpoints somehow establish the Quality of Service (QoS) required for the media streams they establish. Endpoints in closed environments typically agree out-of-band (e.g., using configuration information) regarding which QoS mechanism to use. However, on the Internet, there is more than one QoS service available. Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use for a particular media stream. This document defines such a mechanism.. |
|
|
| | | Up | Status: | Proposed Standard | | |
|
| |
| |
| |
| | | | RFC5438
02/2009
(38 p.)
pdf(p) | E. Burger
H. Khartabil | SIMPLE |
| Instant Message Disposition Notification (IMDN) | Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications (IMDN), including delivery, processing, and display notifications, for page-mode instant messages.
The Common Presence and Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs.
This document also describes how SIP entities behave using this extension. |
|
|
| | | Up | Status: | Proposed Standard | | |
|
| |
| |
| |
| | | | RFC5478
03/2009
(6 p.)
pdf(p) | J. Polk | SIP |
| New SIP RPH Namespaces for DISA | | This document creates additional Session Initiation Protocol (SIP) Resource-Priority namespaces to meet the requirements of the US Defense Information Systems Agency, and places these namespaces in the IANA registry. |
|
|
| | | Up | Status: | Proposed Standard | | |
|
| |
| |
| |
|
|
|
|
| |
| |
| |
| | | | RFC5491
03/2009
(28 p.)
pdf(p) | J. Winterbottom
M. Thomson
H. Tschofenig | GEOPRIV |
| GEOPRIV PIDF-LO Usage Clarification, Considerations, and Recommendations | | The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented. In these circumstances, the range of options that need to be implemented are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent, and interpret locations in a PIDF-LO. It further recommends a subset of Geography Markup Language (GML) 3.1.1 that is mandatory to implement by applications involved in location-based routing. |
|
|
| | | Up | Status: | Proposed Standard | | |
|
| |
| |
| |
|
|
|
|
| |
|
|
|
|
|
|
| | | | RFC5503
03/2009
(34 p.)
pdf(p) | F. Andreasen
B. McKibben
B. Marshall | SIPPING |
| Private SIP Proxy-to-Proxy Extensions for supporting PacketCable DCS Architecture | In order to deploy a residential telephone service at a very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol, RFC 3261, for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required.
This document defines the "P-DCS-Trace-Party-ID ", "P-DCS-OSPS ", "P-DCS-Billing-Info ", "P-DCS-LAES ", and "P-DCS-Redirect " header fields. |
|
|
|
|
3047
非常没帮助
没帮助
一般
有帮助
非常有帮助
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
