Login Form
RECENT IETF DRAFTS
SIP internet drafts statistics
- 83 SIP related internet drafts (IETF).
- 12 new and updated drafts posted in the last 14 days.
| Title | Author | Date |
| Methodology for Benchmarking SIP Networking Devices | Scott Poretsky, Vijay Gurbani, Carol Davids | 2010-02-08 |
| This document describes the methodology for benchmarking Session Initiation Protocol (SIP) performance as described in SIP benchmarking terminology document. The methodology and terminology are to be used for benchmarking signaling plane performance with varying signaling and media load. Both scale and establishment rate are measured by signaling plane performance. The SIP Devices to be benchmarked may be a single device under test (DUT) or a system under test (SUT). Benchmarks can be obtained and compared for different types of devices such as SIP Proxy Server, SBC, and server paired with a media relay or Firewall/NAT device. | ||
| Terminology for Benchmarking Session Initiation Protocol (SIP) Networking Devices | Scott Poretsky, Vijay Gurbani, Carol Davids | 2010-02-08 |
| This document provides a terminology for benchmarking SIP performance in networking devices. Terms are included for test components, test setup parameters, and performance benchmark metrics for black-box benchmarking of SIP networking devices. The performance benchmark metrics are obtained for the SIP control plane and media plane. The terms are intended for use in a companion methodology document for complete performance characterization of a device in a variety of conditions making it possible to compare performance of different devices. It is critical to provide test setup parameters and a methodology document for SIP performance benchmarking because SIP allows a wide range of configuration and operational conditions that can influence performance benchmark measurements. It is necessary to have terminology and methodology standards to ensure that reported benchmarks have consistent definition and were obtained following the same procedures. Benchmarks can be applied to compare performance of a variety of SIP networking devices. | ||
| Requirements for multiple address of record (AOR) reachability information in the Session Initiation Protocol (SIP) | John Elwell | 2010-02-08 |
| This document states requirements for a standardized SIP registration mechanism for multiple addresses of record, the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized PBXs. The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers. This work is being discussed on the martini@ietf.org mailing list. | ||
| The Common Log Format (CLF) for the Session Initiation Protocol (SIP) | Vijay Gurbani, Eric Burger, Tricha Anjali, Humberto Abdelnur, Olivier Festor | 2010-02-08 |
| 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 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 proxies, registrars, redirect servers as well as back-to-back user agents. | ||
| A SIP Event Package for Subscribing to Changes to an HTTP Resource | Adam Roach | 2010-02-04 |
| The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from being able to discover, in near-real- time, when a specific HTTP resource is created, changed, or deleted. This document proposes a mechanism, based on the SIP events framework, for doing so. | ||
| Mapping and interworking of Diversion information Between Diversion and History-Info Headers in the Session Initiation Protocol (SIP) | Marianne Mohali | 2010-02-03 |
| Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless widely implemented and used for conveying call diversion related information in the Session Initiation Protocol (SIP) signaling. This document describes a recommended interworking guideline between the Diversion header and the History-Info header to handle call diversion information. In addition, an interworking policy is proposed to manage the headers coexistence. The History-Info header is described in [RFC4244] and the non-standard Diversion header is described, as Historic, in the [draft-levy-sip-diversion-11]. Note to the RFC-Editor: The reference to this draft should be replaced by the Historic RFC reference (work in progress). Since the Diversion header is used in many existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. | ||
| Diversion Indication in SIP | Steve Levy, Marianne Mohali | 2010-02-02 |
| This RFC, which contains the text of an Internet Draft that was submitted originally to the SIP Working Group, is being published now for the historical record and to provide a reference for later Informational RFCs. The original Abstract follows. This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent. This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies which receive diversion information may use this as supplemental information for feature invocation decisions. | ||
| Private Extension to the Session Initiation Protocol (SIP) for Debugging | Peter Dawes | 2010-02-02 |
| Networks that use SIP to start and stop sessions between their users will frequently be upgraded with software and hardware changes. Users will similarly frequently change their client software and the way they use the network. In order to allow troubleshooting and regression testing, it is useful to provide debugging as part of the network fabric. This draft describes an event package that provides debugging configuration to SIP entities and a SIP private header that triggers logging of SIP signalling and identifies logs at mulitiple SIP entities as belonging to a single end-to-end session. | ||
| Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP) | Adam Roach | 2010-02-02 |
| This document defines a mechanism by which a SIP server acting as a traditional Private Branch Exchange (PBX) can register with a SIP Service Provider (SSP) to receive phone calls for extensions designated by phone numbers. In order to function properly, this mechanism relies on the fact that the phone numbers are fully qualified and globally unique. | ||
| Session Initiation Protocol (SIP) INFO Method and Package Framework | Christer Holmberg, Eric Burger, Hadriel Kaplan | 2010-02-01 |
| This document defines a method, INFO, for the Session Initiation Protocol (SIP) [RFC3261], and an Info Package mechanism. The document obsoletes [RFC2976]. For backward compatibility the document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in [RFC2976], referred to as "legacy INFO Usage" in this document. | ||
| Identifying Individual Telephone Instruments in SIP | Dale Worley | 2010-01-30 |
| When requesting and reporting dialog status in SIP, users often want to know the status of a particular telephone instrument, rather than the status of an Address of Record (AOR). The architecture of SIP makes it difficult to obtain the status of a telephone instrument in a way that is convenient for use in common situations, in particular, in an organization\'s PBX. This document describes two methods for identifying which telephone instrument is making each registration request that is convenient to deploy in PBXs. This information can be used to obtain the status of individual telephone instruments. | ||
| A SIP/SIPS URI parameter for passing subscription data | Keith Drage | 2010-01-28 |
| This document provides a SIP/SIPS URI parameter to enable subscription data related to a SIP/SIPS URI to accompany that SIP/ SIPS URI when required by other entities in the same system. This can then be used by the receiving entity to assist in the provision of capabilities associated with that SIP/SIPS URI, either in this request or in other subsequent requests. | ||
| B2BUAs with SIP Call Control | Dale Worley | 2010-01-24 |
| Some SIP architectures use "application servers", B2BUAs that are inserted between two user agents during a conversation, to provide additional processing. Since B2BUAs do not follow the rules for SIP proxies, they do not by default interoperate with SIP call control operations. Augmenting application servers with suitable behaviors for handling SIP call control operations mitigates these problems, and in many cases, allows standard user agents to use SIP call control features without modification. | ||
| Example call flows using Session Initiation Protocol (SIP) security mechanisms | Cullen Jennings, Kumiko Ono, Robert Sparks, Brian Hibbard | 2010-01-22 |
| This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. | ||
| SIP APIs for Communications on the Web | Henry Sinnreich, Alan Johnston | 2010-01-19 |
| Interactive communications are becoming part of rich Internet applications (RIA). This can be accomplished entirely by using Web technology and developing it as an Internet standard. Voice over IP (VoIP) features developed for Session Initiation Protocol (SIP 2.0) can be preserved in rich multimedia communications and applications on the web. Hyper Text Transport Protocol (HTTP) is used for control and signaling data and RTP for interactive media transport respectively. No other network application protocols are required. Web, fixed and mobile device application development tools can thus be used to include components and widgets for Internet presence, Instant Messaging (IM), voice and video. This opens Internet communications, including voice to application developers and will also enhance the user experience with real-time Web and mobile communications. Usage scenarios include service providers, private IP networks, device application developers and media companies providing a mix of integrated communications, applications and media. This memo argues for the development and standardization of Application Programming Interfaces (APIs) to allow the benefits of SIP to be used by Rich Internet Applications (RIA), for fixed and mobile devices. | ||
| Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) | Gonzalo Camarillo, Christer Holmberg, Gao yang | 2010-01-19 |
| In this document, we clarify the handling of re-INVITEs in SIP. We clarify in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, we clarify issues related to target-refresh requests. | ||
| VoIP SIP Peering Use Cases | Adam Uzelac, Yiu Lee | 2010-01-19 |
| This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) Peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today. | ||
| SIP (Session Initiation Protocol) Usage of the Offer/Answer Model | Paul Kyzivat, Takuya Sawada | 2010-01-18 |
| The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the Session Description Protocol (SDP). The description of the offer/answer model in SIP is dispersed across multiple RFCs. This document summarizes all the current usages of the offer/answer model in SIP communication. | ||
| The Common Log Format (CLF) for the Session Initiation Protocol (SIP) | Vijay Gurbani, Eric Burger, Tricha Anjali, Humberto Abdelnur, Olivier Festor | 2010-01-15 |
| 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 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 proxies, registrars, redirect servers as well as back-to-back user agents. | ||
| An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification | Aki Niemi, Dean Willis | 2010-01-14 |
| The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. | ||
| The isup-oli SIP URI Parameter | John Haluska | 2010-01-13 |
| A SIP URI parameter "isup-oli" is being used for interworking the ISUP Originating Line Information parameter or equivalent PSTN signaling information with SIP. This parameter has been also been discussed in various documentation, but nowhere is it formally documented. This document formally documents the usage, syntax, and semantics of this parameter, providing a reference for discussion of this parameter. It does not seek to achieve standardization of this parameter. | ||
| Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control | Aki Niemi, Krisztian Kiss, Salvatore Loreto | 2010-01-08 |
| This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. | ||
| The References Header for SIP | Dale Worley | 2010-01-06 |
| This document defines a SIP extension header, References, to be used within SIP messages to signify that the message (and the dialog containing it) is related to one or more other dialogs. It is expected to be used largely for diagnostic purposes. | ||
| A Unified Proposal for Multiple AOR Registrations in the Session Initiation Protocol (SIP) | Adam Roach | 2010-01-06 |
| This document contains a unified proposal for solving the problems related to providing dynamic SIP routing information for multiple AORs with a single SIP transaction. The proposed solution is designed to work both for subsets of URIs within a domain, and for entire domains. | ||
| Filtering Location Notifications in the Session Initiation Protocol (SIP) | Rohan Mahy, Brian Rosen, Hannes Tschofenig | 2009-12-28 |
| This document describes filters that limit asynchronous location notifications to compelling events, designed as an extension to RFC 4661, an XML-based format for event notification filtering, and based on RFC 3856, the SIP presence event package. The resulting location information is conveyed in existing location formats wrapped in the Presence Information Data Format Location Object (PIDF-LO). | ||
| << Start < Prev 1 2 3 4 Next > End >> | ||
| Display # Results 1 - 25 of 83 | ||