Login Form
RECENT IETF DRAFTS
SIP internet drafts statistics
- 53 SIP related internet drafts (IETF).
- 1 new and updated drafts posted in the last 14 days.
| Title | Author | Date |
| The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Data Model | Vijay Gurbani, Eric Burger, Tricha Anjali, Humberto Abdelnur, Olivier Festor | 2012-02-06 |
| Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de-facto standard formats are invaluable to system administrators for trouble-shooting a server and tool writers to craft tools that mine the log files and produce reports and trends. Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol (SIP) does not have a common log format, and as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. We propose a common log file format for SIP servers that can be used uniformly by user agents, proxies, registrars, redirect servers as well as back-to-back user agents. | ||
| Session Initiation Protocol (SIP) Load balancing survey | Parthasarathi Ravindran, Vijay Gurbani, Paul Erkkila | 2012-01-23 |
| SIP Load balancing across a farm of SIP servers can be done today, but without generally agreed upon principles on how to best do accomplish this. Confounding the problem is that a SIP farm may consist of hosts with varying capabilities, example, a SIP proxy, a back-to-back user agent (B2BUA), a public-switched telephone system (PSTN) gateway, SIP Media servers etc. The capabilities and processing capacity on hosts in the farm may be different, sometimes vastly, from each other. This document present the survey of existing literature and common practice on SIP load balancing. | ||
| Session Initiation Protocol (SIP) Overload Control | Vijay Gurbani, Volker Hilt, Henning Schulzrinne | 2012-01-18 |
| Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines the behaviour of SIP servers involved in overload control, and in addition, it specifies a loss-based overload scheme for SIP. | ||
| A SIP Usage for RELOAD | Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman Baset, Henning Schulzrinne | 2012-01-17 |
| This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD), The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system. The SIP Usage provides lookup service for AoRs stored in the overlay. The SIP Usage also defines GRUUs that allow the registrations to map an AoR to a specific node reachable through the overlay. The AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. | ||
| Alert-Info URNs for the Session Initiation Protocol (SIP) | Laura Liess, Roland Jesske, Alan Johnston, Dale Worley, Paul Kyzivat | 2012-01-17 |
| The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UA when the user is alerted. This is done using the Alert-Info header field. However, the reference addresses only network resources with specific rendering properties. There is currently no support for predefined standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome this limitation and support new applications, a new family of URNs for use in SIP Alert-Info header fields is defined in this specification. This document normatively updates [RFC3261], the Session Initiation Protocol (SIP). It changes the usage of the SIP Alert-Info header field defined in the [RFC3261] by additionally allowing its use in all provisional responses to INVITE (except the 100 response). | ||
| The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) | Inaki Baz Castillo, Jose Millan, Victor Pascual | 2012-01-15 |
| This document specifies a WebSocket Sub-Protocol for a new transport in SIP (Session Initiation Protocol). The WebSocket protocol enables two-way realtime communication between clients and servers. | ||
| iSCSI Extensions for RDMA Specification | Mike Ko, Alexander Nezhinsky | 2012-01-15 |
| iSCSI Extensions for RDMA provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA- Capable Protocol. This document obsoletes RFC 5046. | ||
| Session Initiation Protocol (SIP) Extensions for Blocking VoIP Spam Using PSTN Validation | Marc Petit-Huguenin, Jonathan Rosenberg, Cullen Jennings | 2012-01-11 |
| Verification Involving PSTN Reachability (ViPR) is a new technique for inter-domain federation of SIP calls. ViPR makes use of the PSTN as an introduction mechanism to verify the correctness of mappings from phone numbers to domains. The PSTN introduction mechanism can also be used as a technique for blocking spam - a SIP caller is only authorized when its calling domain has previously called that same number over the PSTN. This document describes an extension to SIP which enables authorization of SIP calls based on a prior PSTN introduction. | ||
| A Session Initiation Protocol (SIP) Load Control Event Package | Charles Shen, Henning Schulzrinne, Arata Koike | 2012-01-10 |
| We define a load control event package for the Session Initiation Protocol (SIP). It allows SIP servers to distribute load filters to other SIP servers in the network. The load filters contain rules to throttle calls based on their source or destination domain, telephone number prefix or for a specific user. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts. | ||
| Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) | Keith Drage, Christer Holmberg, Roland Jesske | 2012-01-09 |
| This document describes a set of private Session Initiation Protocol (SIP) header fields (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-header fields are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. | ||
| Media Multihoming in SIP Sessions | Rohit verma | 2012-01-09 |
| This document discusses the requirements and procedures to achieve the multihoming of media for voice over IP sessions using the transport layer protocol as signaling Control Transmission Protocol. Media is an essential part of any voice over IP session. SIP (RFC 3261) is a text based signaling protocol and Multihoming using SIP can be achieved by using the SCTP as a transport protocol (RFC 4168), therefore the application level resiliency can be guaranteed even in case of any middle node or terminal failures. But any voice over IP or multimedia session is nearly insignificant, if the media path is broken during a call and is waiting for a timeout which further shall lead to a call drop.A complete solution to Multihoming can be achieved if a system is capable of a performing the failovers at both application and media plane and still maintaining the session irrespective of the application or media path failures or at least to detect a signaling or media path failure and terminate the session rather than waiting for timeouts. The requirement of Multihoming in media can also be derived from the fact that in any voice, video or data session, the signaling and call setup time use to be incomparably short than that of real media session at media plane. Therefore providing the resiliency at the signaling level does not provide the guaranteed and best effort service from a media session point of view as not only signaling but media is an integral part of it. | ||
| Problem Statement and Requirements for Transporting User to User Call Control Information in SIP | Alan Johnston, Laura Liess | 2012-01-03 |
| This document introduces the transport of call control related User to User Information (UUI) using the Session Initiation Protocol (SIP), and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application. This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the ISDN UUI Service, this extension will also be used for native SIP endpoints requiring application UUI. | ||
| Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) | Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan | 2011-12-29 |
| This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This feature allows several user agents (UAs) to share a common AOR, learn about calls placed and received by other UAs in the group, and pick up or join calls within the group. This document discusses use cases, lists requirements and defines extensions to implement this feature. | ||
| P2PSIP Overlay Diagnostics | Song Haibin, XingFeng Jiang, Roni Even, David Bryan | 2011-12-28 |
| This document describes mechanisms for P2PSIP diagnostics. It defines extensions to the RELOAD P2PSIP base protocol RELOAD [I-D.ietf-p2psip-base] to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in a P2PSIP overlay networks. | ||
| A Mechanism for Negotiating Multi-Stream Continuous Presence Video in SIP | Adel Mostafa | 2011-12-23 |
| The NextGen video conferencing clients require multiple concurrent video streams to provide a User eXperience (UX) in which multiple participants can be viewed at the same time, this user experience is called Continuous Presence (CP) video. The multi-stream CP video provides more client control of the UX and less processing on the conference server since the video streams are relayed by the server rather than mixed to compose a CP video stream. The client CP layout, processing power and bandwidth limitations require a per stream bandwidth and resolution to be negtiated in the SIP Offer/ Answer with the conference server. Standard methods are used to achieve this negotiation in addition to a new SDP parameter. This document explains the methodology and solution to achieve this in SIP and SDP. | ||
| Format for the Session Initiation Protocol (SIP) Common Log Format (CLF) | Gonzalo Salgueiro, Vijay Gurbani, Adam Roach | 2011-12-17 |
| The SIPCLF Workgroup has defined a common log format framework for Session Initiation Protocol (SIP) servers. This common log format mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid. This document proposes an indexed text encoding format for the SIP Common Log Format (CLF) that retains the key advantages of a text-based format, while significantly increasing processing performance over a purely text-based implementation. This file format adheres to the SIP CLF data model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record. | ||
| A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart Overload Control | Charles Shen, Henning Schulzrinne, Arata Koike | 2011-12-15 |
| When a large number of clients register with a SIP registrar server at approximately the same time, the server may become overloaded. Near-simultaneous floods of SIP SUBSCRIBE and PUBLISH requests may have similar effects. Such request avalanches can occur, for example, after a power failure and recovery in a metropolitan area. This document describes how to avoid such overload situations. Under this mechanism, a server estimates an avalanche restart backoff interval during its normal operation and conveys this interval to its clients through a new Restart-Timer header in normal response messages. Once an avalanche restart actually occurs, the clients perform backoff based on the previously received Restart-Timer header value before sending out the first request attempt. Thus, the mechanism spreads all the initial client requests and prevents them from overloading the server. | ||
| Session Initiation Protocol (SIP) Rate Control | Eric Noel, Philip Williams | 2011-12-12 |
| The prevalent use of Session Initiation Protocol (SIP) [RFC3261] in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. Already [draft-ietf-soc-overload-control-05] proposes a loss-based solution to remedy known vulnerabilities of the [RFC3261] SIP 503 (service unavailable) overload control mechanism. This document proposes a rate-based control solution to complement the loss-based control defined in [draft-ietf-soc-overload-control-05]. | ||
| Requirements for indication of features supported by a SIP proxy | Christer Holmberg, Ivo Sedlacek | 2011-12-05 |
| The Session Initiation Protocol (SIP) "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP message to convey information relating to the originator\'s supported features/ capabilities. This document defines requirements for a mechanism that would allow SIP proxies to convey information relating to the proxy\'s supported features/capabilities. | ||
| Call Completion for Session Initiation Protocol (SIP) | Dale Worley, Martin Huelsemann, Roland Jesske, Denis Alexeitsev | 2011-11-29 |
| The call completion feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call. For the realization of a basic solution without queuing, this document references the usage of the dialog event package (RFC 4235) that is described as \'automatic redial\' in the SIP Service Examples (RFC 5359). For the realization of a more comprehensive solution with queuing , this document introduces an architecture for implementing these features in the Session Initiation Protocol where "Call completion" implementations associated with the caller\'s and callee\'s endpoints cooperate to place the caller\'s request for call completion into a queue at the callee\'s endpoint, and when a caller\'s request is ready to be serviced, re-attempt of the original, failed call is made. The architecture is designed to interoperate well with existing call- completion solutions in other networks. | ||
| Requirements for Interworking WebRTC with Current SIP Deployments | Hadriel Kaplan | 2011-11-22 |
| The IETF RTCWEB WG has been discussing how to interwork WebRTC with deployed SIP equipment and domains. Doing so may require an Interworking Function middlebox in the media-plane. This document lists some WebRTC-to-SIP use-cases, the WebRTC requirements to support such, and the complexity involved in interworking if the requirements cannot be met. | ||
| Evaluation of using SIP or an independent protocol for CLUE messaging | Robert Hansen, Allyn Romanow | 2011-11-17 |
| This document evaluates the advantages and disadvantages of using SIP or an independent protocol for conveying CLUE messages/ | ||
| A Mechanism for Transporting User to User Call Control Information in SIP | Alan Johnston, James Rafferty | 2011-10-31 |
| There is a class of applications which benefit from using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. The rules which apply for a certain application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism. | ||
| Interworking ISDN Call Control User Information with SIP | Keith Drage, Alan Johnston | 2011-10-31 |
| The motivation and use cases for interworking and transporting ITU-T DSS1 User-user information element data in SIP are described in the "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP" document. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to- end transparency. This document defines a usage of the User-to-User header field to enable interworking with this ISDN service. This document covers the interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed. | ||
| Real-time Transport Protocol (RTP) Recommendations for SIPREC | Charles Eckel | 2011-10-31 |
| This document provides recommendations and guidelines for RTP and RTCP in the context of SIPREC. This document exists as a standalone document to facilitate discussion of the RTP recommendations, and it is anticipated that portions of this document will be incorporated into [I-D.ietf-siprec-protocol] rather than this document itself being adopted as a working group document. | ||
| << Start < Prev 1 2 3 Next > End >> | ||
| Display # Results 1 - 25 of 53 | ||