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 |
| Concepts and Terminology for Peer to Peer SIP | David Bryan, Philip Matthews, Eunsoo Shim, Dean Willis, Spencer Dawkins | 2011-10-31 |
| This document defines concepts and terminology for the use of the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message routing functions are replaced by a distributed mechanism. These mechansims may be implemented using a distributed hash table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group and the RELOAD protocol ([I-D.ietf-p2psip-base], [I-D.ietf-p2psip-sip]) defined by the working group. | ||
| Session Initiation Protocol (SIP) Recording Metadata | Ram R, Parthasarathi Ravindran, Paul Kyzivat | 2011-10-31 |
| 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. | ||
| Session Initiation Protocol (SIP) History-Info Header Call Flow Examples | Mary Barnes, Francois Audet, Shida Schubert, Detecon Gmbh, Christer Holmberg | 2011-10-30 |
| This document describes use cases and documents call flows which require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. | ||
| An Extension to the Session Initiation Protocol (SIP) for Request History Information | Mary Barnes, Francois Audet, Shida Schubert, Detecon Gmbh, Christer Holmberg | 2011-10-30 |
| 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 specific to the History-Info header field. This document obsoletes RFC 4244. | ||
| SIP Message Information Export using IPFIX | Brian Trammell, Saverio Niccolini, Benoit Claise, Hadriel Kaplan | 2011-10-27 |
| This draft defines a set of Information Elements and example Templates for IP Flow Information Export (IPFIX) based on the SIP Common Log Format data model, as well as additional useful SIP Information Elements, to allow IPFIX export of application-layer information about SIP messages. | ||
| Session Initiation Protocol (SIP) Header Parameter for Debugging | Peter Dawes | 2011-10-24 |
| 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. | ||
| 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. | ||
| Routing SIP Requests with ENUM | Hadriel Kaplan, Colin Pons, Pierce Gorman | 2011-10-24 |
| A common ENUM use-case is for hop-by-hop or domain-by-domain "routing" of SIP requests, using private DNS trees and servers. This document describes this use-case, and a mechanism for a source- based query/answer mechanism for such. | ||
| Session Initiation Protocol (SIP) emergency call back identification | Christer Holmberg | 2011-10-24 |
| This specification define a new type of Globally Routable User Agent URI (GRUU) [RFC5627], called emergency GRUU (eGRUU). When a User Agent (UA) provides makes an emergency call, it can provide the eGRUU to a PSAP, which can then use it to make a PSAP callback call. The specification also defines a new URI parameter, "psapcb", which can be used to indicate that a URI can be used for PSAP callback calls. A registrar will provide the URI parameter as part of the generated eGRUU value. Later, when a PSAP makes a PSAP callback call the URI, including the "psapcb" URI parameter, can be used by SIP entities to identity callback calls. | ||
| SIP to RTCWeb Offer/Answer Protocol (ROAP) Gateway | Cullen Jennings, Suhas Nandakumar, Christer Holmberg | 2011-10-24 |
| This document proposes behavior of a RTCWeb signaling gateway for mapping message representations between RTCWeb Offer/Answer Protocol (ROAP) scheme and native SIP messaging scheme. Such a signaling gateway is intended to translate to and from/SIP for enabling use cases between a RTCWeb enabled browser and legacy SIP devices. | ||
| Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) | Hadriel Kaplan, Victor Pascual | 2011-10-24 |
| SIP Back-to-Back User Agents (B2BUAs) can cause unending SIP request routing loops because, as User Agent Clients, they can generate SIP requests with new Max-Forwards values. This document discusses the difficulties associated with loop detection for B2BUAs, and requirements for them to prevent infinite loops. | ||
| A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information in support of the Communication Diversion (CDIV) Notification (CDIVN) CDIV service | Ranjit Avasarala, John Bakker | 2011-10-20 |
| 3GPP and TISPAN are defining the protocol specification for the Communication Diversion (CDIV) service using IP Multimedia (IM) Core Network (CN) subsystem supplementary service. As part of CDIV, a SIP based Event package framework is used for notifying users about diversions (re-directions or forwarding) of their incoming communication sessions. This document proposes a new SIP event package for allowing users to subscribe to and receive such notifications. Users can further define filters to control the rate and content of such notifications. The proposed event package is applicable to the CDIV supplementary service in IMS and may not be applicable to the general internet. . | ||
| SIP-Specific Event Notification | Adam Roach | 2011-10-19 |
| This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. | ||
| A Session Initiation Protocol (SIP) INFO package for Private Wire | Richard Beauchamp, Finlay Fraser, Chris Boulton | 2011-10-18 |
| 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. | ||
| A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents | Hadriel Kaplan | 2011-10-14 |
| There are numerous types of SIP Back-to-Back User Agents (B2BUAs), performing different roles in different ways. This document identifies several common B2BUA roles, in order to provide taxonomy other documents can use and reference. | ||
| A Media-based Traceroute Function for the Session Initiation Protocol (SIP) | Hadriel Kaplan | 2011-10-14 |
| SIP already provides the ability to perform hop-by-hop traceroute for SIP messages using the Max-Forwards header field, in order to determine the reachability path of requests to a target. A new mechanism for media-loopback calls is also being defined separately, which enables test calls to be generated which result in media being looped back to the originator. This document is a strawman proposal for a means of performing hop-by-hop traceroute-style test calls using the media-loopback mechanism, in order to test the media path when SIP sessions go through media-relaying B2BUAs. | ||
| Session Initiation Protocol (SIP) Extension for logging and debugging. | Adarsh Kaithal | 2011-10-12 |
| The current mechanisms to debug issues in SIP network are not very efficient. It requires to enable debugging logs across different devices, recreate the problem and then collect the logs. The idea is to provide a solution to automatically enable relevant logs (SIP messages and any other debugging logs meaningful to SIP devices), and also to indicate where the logs are to be collected or stored. The enabling of logs will happen at all the SIP devices(upstream or downstream). This will help to get the logs from all the SIP devices in a Common logging format (CLF). The solution extends SIP to provide the infrastructure to enable logging for upstream and downstream devices with each server deciding how much troubleshooting information it wants to log - with freedom to simply ignore requests if required. This document specifies a new header called "Log-Me" Header in all the SIP messages. | ||
| Sieve Notification Mechanism: SIP MESSAGE | Alexey Melnikov, Qian Sun, Barry Leiba, Kepeng Li | 2011-10-11 |
| This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE. | ||
| The References Header for SIP | Dale Worley | 2011-10-10 |
| 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. | ||
| Avoidance of Security Issues in SIP and Internet | Samir Srivastava | 2011-10-05 |
| This memo lists the security issues not addressed by SIPS and other drafts in progress. It provides two solutions to it. First solution calls for fixing issues one by one. The second solution avoids the security issues altogether. It has potential to obviate the need of \'Security Consideration\' section from IETF documents. It requires wider acceptance from the community. Author is requesting IETF community to voice it\'s opinion and share the second solution with non-IETF members also to have their opinion. | ||
| Verification Involving PSTN Reachability (VIPR) enabled SIP Intermediaries | Marc Petit-Huguenin | 2011-10-04 |
| This document presents some of the problems created by SIP intermediaries inside a VIPR federation. | ||
| The Continue Header Field for the Session Initiation Protocol (SIP) | Amardeep Sinha, Subhrajyoti De, Sunil Kumar Sinha | 2011-10-03 |
| Before placing a call, it is quite often useful for the Caller to know whether a Callee is in favourable state to receive a call or not. This document defines an optional tag "continue" and a header "Continue" to address the purpose. The "Continue" header field is to confirm the session continuity with the Callee from the Caller after an option for session continuity is placed by the Callee based on the unfavorable state of the Callee. This functionality is needed to resolve the unwillingness of the Callee to receive any call. An option is given to the Callee by the Service Provider or by the Handset Manufacturer or by the Carrier to establish this requirement. | ||
| P-Charge-Info - A Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) | Dan York, Tolga Asveren | 2011-09-15 |
| This document describes \'P-Charge-Info\', a private Session Initiation Protocol (SIP) header (P-header) used to convey billing information about the party to be charged. This P-Header is currently in production usage by a number of equipment vendors and carriers and this document is submitted to request the registration of this header with IANA. This P-Header may also be used in some situations to carry the ISUP Charge Number parameter for PSTN interconnection. | ||
| 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. | ||
| IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications | James Polk | 2011-06-06 |
| This document creates the new Session Initiation Protocol (SIP) Resource Priority header field namespace "esnet" for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations, and places this namespace in the IANA registry. | ||
| << Start < Prev 1 2 3 Next > End >> | ||
| Display # Results 26 - 50 of 53 | ||