Login Form
RECENT IETF DRAFTS
SIP internet drafts statistics
- 41 SIP related internet drafts (IETF).
- 1 new and updated drafts posted in the last 14 days.
| Title | Author | Date |
| Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions | Peter Saint-Andre | 2013-02-20 |
| This document defines a bi-directional protocol mapping for use by gateways that enable the exchange of media signalling messages between systems that implement the Jingle extensions to the Extensible Messaging and Presence Protocol (XMPP) and those that implement the Session Initiation Protocol (SIP). | ||
| A Session Initiation Protocol (SIP) usage for Trickle ICE | Emil Ivov, Adam Roach | 2013-02-18 |
| This document registers the application/sdpfrag Multipurpose Internet Mail Extensions (MIME) media type. This type is similar to application/sdp, but allows certain subsets of well formed session descriptions, as per the Session Description Protocol (SDP), to be represented instead of requiring a complete SDP session description. The "a=candidate" lines that are incrementally exchanged between Trickle ICE agents are one example usage of the application/sdpfrag. | ||
| A Session Initiation Protocol (SIP) usage for Trickle ICE | Emil Ivov, Enrico Marocco, Christer Holmberg | 2013-02-07 |
| The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking. This document defines usage semantics for Trickle ICE with SIP. | ||
| Session Initiation Protocol (SIP) Overload Control | Vijay Gurbani, Volker Hilt, Henning Schulzrinne | 2013-02-01 |
| 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 Session Initiation Protocol (SIP) usage for Trickle ICE | Emil Ivov, Enrico Marocco, Christer Holmberg | 2013-01-30 |
| The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking. This document defines usage semantics for Trickle ICE with SIP. | ||
| Session Initiation Protocol (SIP) Recording Metadata | Ram R, Parthasarathi Ravindran, Paul Kyzivat | 2013-01-29 |
| Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS) and the Recording metadata format. | ||
| A Session Initiation Protocol (SIP) INFO package for Private Wire | Richard Beauchamp, Finlay Fraser, Chris Boulton | 2013-01-28 |
| Application level data exchanged using the SIP INFO method are supported and documented in specifications known as \'INFO Packages\'. This document defines functionality associated with Session Initiation Protocol (SIP) Private Wire functionality and creates an \'INFO Package\' for carrying such application level data. | ||
| Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) | Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan | 2013-01-16 |
| 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. This specification updates RFC3261 and RFC4235. | ||
| An Extension to the Session Initiation Protocol (SIP) for Request History Information | Mary Barnes, Francois Audet, Shida Schubert, Hans van Elburg, Christer Holmberg | 2013-01-11 |
| This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field. This document obsoletes RFC 4244. | ||
| Requirements for Marking SIP Messages to be Logged | Peter Dawes | 2013-01-09 |
| SIP networks use signalling monitoring tools to diagnose user reported problem and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signalling will take between clients, and therefore impractical to monitor SIP signalling end-to-end. This draft describes requirements for adding an indicator to the SIP protocol which can be used to mark signalling as subject to logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signalling. However, such marking can be carried end-to-end including the SIP terminals, even if a session originates and terminates in different networks. | ||
| Methodology for Benchmarking SIP Networking Devices | Carol Davids, Vijay Gurbani, Scott Poretsky | 2013-01-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 | Carol Davids, Vijay Gurbani, Scott Poretsky | 2013-01-08 |
| This document provides a terminology for benchmarking the SIP performance of networking devices. The term performance in this context means the capacity of the device- or system-under-test to process SIP messages. 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 signaling plane only. The terms are intended for use in a companion methodology document for characterizing the performance of a SIP networking device under a variety of conditions. The intent of the two documents is to enable a comparison of the capacity of SIP networking devices. Test setup parameters and a methodology document are necessary because SIP allows a wide range of configuration and operational conditions that can influence performance benchmark measurements. A standard terminology and methodology will ensure that benchmarks have consistent definition and were obtained following the same procedures. | ||
| A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart Overload Control | Charles Shen, Henning Schulzrinne, Arata Koike | 2012-12-31 |
| 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. | ||
| SIP signalling for ICE trickling | Shitao Li | 2012-12-06 |
| Trickle ICE is a mechanism that allows ICE agents to send and receive candidates incrementally rather than exchanging complete lists. This document gives several solutions for trickle ICE with SIP protocol. Note Discussion and suggestions for improvement are requested, and should be sent to dispatch@ietf.org. | ||
| EDNS Option Code for SIP and PSTN Source Reference Info | Hadriel Kaplan, Robert Walter, Pierce Gorman, Manjul Maharishi | 2011-10-24 |
| This document requests an IANA allocation for an EDNS0 Option-Code, per [RFC2671], for a UTF-8 encoded string field containing a URI for private use. The intended use of this field is for providing SIP and PSTN-type source information for ENUM-resolution DNS queries, in private DNS server environments such as Private ENUM. | ||
| Considerations for Information Services and Operator Services Using SIP | John Haluska, Richard Ahern, Marty Cruze, Chris Blackwell | 2011-08-15 |
| Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to describe how current operator services can continue to be provided to PSTN based subscribers via a SIP based operator services architecture. It also looks at how current operator services might be provided to SIP based subscribers via such an architecture, but does not consider the larger question of the need for or usefulness or suitability of each of these services for SIP based subscribers. This document addresses the needs of current Operator and Information Services providers; as such, the intended audience includes vendors of equipment and services to such providers. | ||
| << Start < Prev 1 2 Next > End >> | ||
| Display # Results 26 - 41 of 41 | ||