Login Form

Lost Password?

No account yet? Register

RECENT IETF DRAFTS

SIP internet drafts statistics

  • 45 SIP related internet drafts (IETF).
  • 0 new and updated drafts posted in the last 14 days.

Read more ...

Title Author Date
Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan 0000-00-00
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.

Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic session setup and registration Carol Davids, Vijay Gurbani, Scott Poretsky 0000-00-00
This document provides a terminology for benchmarking the Session Initiation Protocol (SIP) performance of devices. Methodology related to benchmarking SIP devices is described in the companion methodology document. Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars and Session Border Controllers. The term "performance" in this context means the capacity of the device-under- test (DUT) to process SIP messages. Media streams are used only to study how they impact the signaling behavior. The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices. Test setup parameters and a methodology is 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.

Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic session setup and registration Carol Davids, Vijay Gurbani, Scott Poretsky 0000-00-00
This document provides a methodology for benchmarking the Session Initiation Protocol (SIP) performance of devices. Terminology related to benchmarking SIP devices is described in the companion terminology document. Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars and Session Border Controllers. The term "performance" in this context means the capacity of the device-under- test (DUT) to process SIP messages. Media streams are used only to study how they impact the signaling behavior. The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices. Test setup parameters and a methodology is 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 Transporting User to User Call Control Information in SIP Alan Johnston, James Rafferty 0000-00-00
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 syntax and semantics for the UUI data used by a specific application. 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 0000-00-00
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 (a new package) 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. The package is identified by a new value "isdn-uui" of the "purpose" header field parameter.

Requirements for Marking SIP Messages to be Logged Peter Dawes 0000-00-00
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 of interest 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.

Using Interactive Connectivity Establishment (ICE) with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP) Marc Petit-Huguenin, Ari Keranen 0000-00-00
This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP).

A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart Overload Control Charles Shen, Henning Schulzrinne, Arata Koike 0000-00-00
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.

EDNS Option Code for SIP and PSTN Source Reference Info Hadriel Kaplan, Robert Walter, Pierce Gorman, Manjul Maharishi 0000-00-00
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.

A Session Initiation Protocol (SIP) INFO package for Private Wire Richard Beauchamp, Finlay Fraser, Chris Boulton 0000-00-00
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.

P-Charge-Info - A Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) Dan York, Tolga Asveren 0000-00-00
This text documents \'P-Charge-Info\', an existing 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. NOTE: This document has been in development since 2008 under the name draft-york-sipping-p-charge-info. This -03 document is identical to draft-york-sipping-p-charge-info-15 except for edits to the text to indicate this is now for the DISPATCH working group as the SIPPING working group no longer exists.

Interoperability Impacts of IPv6 Interworking with Existing IPv4 SIP Implementations Carl Klatsky, oej, Rifaat Shekh-Yusef, Andrew Hutton, Gonzalo Salgueiro 0000-00-00
This document captures potential impacts to IPv4 SIP implementations when interworking with IPv6 SIP implementations. Although some amount of interworking translation will occur at the network and application layers, an IPv4 SIP application may still encounter a SIP message with some IPv6 values in it, resulting in unforeseen error conditions. Such potential scenarios will be identified in this document so that SIP application developers can define solutions to handle these cases. Note, this document is not intended to be an exhaustive list, rather to provide an overview of some of the more commonly encountered potential scenarios.

Offer & Answer interworking between JSEP & SIP Parthasarathi Ravindran, Uwe Rauschenbach, Elangovan Manickam 0000-00-00
Real time communcation Web (RTCWeb) workgroup defines the real time commmunication using JavaScript Session establishment protocol (JSEP) as an offer/answer mechanism. Session Initiation protocol (SIP) is IETF defined and well deployed protocol for real time communication. This document provides offer & answer interworking between JSEP and SIP.

Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network oej, Gonzalo Salgueiro 0000-00-00
RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document supplements the DNS procedures described in RFC 3263 for dual-stack SIP implementations and ensures that they properly align to the optimizations detailed by Happy Eyeballs.

PCP for SIP Deployments in Managed Networks Mohamed Boucadair 0000-00-00
This document discusses how PCP (Port Control Protocol) can be used in SIP deployments in managed networks.

A Proposal for Backwards Compatibility of the INSIPID Session-ID James Polk, Paul Jones 0000-00-00
This is a proposal for backwards compatibility for the INSIPID Session-ID SIP header. This draft is never intended to reach RFC status, and is written merely to make a concrete proposal that everyone can view - and if agreed upon, it will be woven into the INSIPID solution draft.

Internet Assigned Numbers Authority (IANA) Registration of the Session Initiation Protocol (SIP) Feature-Capability indicators Andrew Allen 0000-00-00
This document registers with IANA the SIP Feature-Capability indicators in the "SIP Feature-Capability Indicator Registration Tree" of the IANA "Proxy-Feature Feature-Capability Indicator Trees" registry for use with the SIP Feature-Caps header field.

Authenticated Identity Management in the Session Initiation Protocol (SIP) Jon Peterson, Cullen Jennings, Eric Rescorla 0000-00-00
The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining new SIP header fields for conveying a signature used for validating the identity, and for conveying a reference to the credentials of the signer.

TLS sessions in SIP using DNS-based Authentication of Named Entities (DANE) TLSA records oej 0000-00-00
Use of TLS in the SIP protocol is defined in multiple documents, starting with RFC 3261. The actual verification that happens when setting up a SIP TLS connection to a SIP server based on a SIP URI is described in detail in RFC 5922 - SIP Domain Certificates. In this document, an alternative method is defined, using DNS-Based Authentication of Named Entities (DANE). By looking up TLSA DNS records and using DNSsec protection of the required queries, including lookups for NAPTR and SRV records, a SIP Client can verify the identity of the TLS SIP server in a different way, matching on the SRV host name in the X.509 PKIX certificate instead of the SIP domain. This provides more scalability in hosting solutions and make it easier to use standard CA certificates (if needed at all).

The Session Initiation Protocol (SIP) Digest Authentication Scheme Rifaat Shekh-Yusef 0000-00-00
This document updates the Digest Access Authentication scheme used by the Session Initiation Protocol (SIP) to add support for SHA2 digest algorithms to replace the MD5 algorithm.

Requirements for Marking SIP Messages to be Logged Peter Dawes 0000-00-00
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 of interest 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.

Solutions for Marking SIP Messages to be Logged Peter Dawes 0000-00-00
SIP networks use signalling monitoring tools to diagnose user reported problem and for regression testing if network or user agent 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 user agents, and therefore impractical to monitor SIP signalling end-to-end. This draft describes potential solutions to meet requirements for adding an indicator to the SIP protocol which can be used to mark signalling as of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in regular user agent signalling. However, such marking can be carried end-to-end including the SIP user agents, even if a session originates and terminates in different networks.

Indicating WebSocket Protocol as a Transport in the Session Initiation Protocol (SIP) Common Log Format (CLF) Gonzalo Salgueiro, Victor Pascual, Anton Roman, Sergio Garcia 0000-00-00
RFC 7118 [RFC7118] specifies a WebSocket sub-protocol as a reliable real-time transport mechanism between SIP (Session Initiation Protocol) entities to enable usage of SIP in web-oriented deployments. This document updates the SIP Common Log Format (CLF), defined in RFC 6873 [RFC6873], with a new "Transport Flag" for such SIP WebSocket transport.

Mapping and interworking of Diversion information Between Diversion and History-Info Headers in the Session Initiation Protocol (SIP) Marianne Mohali 0000-00-00
[This version of the document is a draft version for an RFC6044bis that will describe the mapping between the Diversion header defined in RFC5806 and the new History-Info header defined in RFC7044.] Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless already 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 non-standard Diversion header is described, as Historic, in [RFC5806]. The History-Info header is described in [RFC7044] that obsoletes [RFC4244] initially describing the History-Info header. [RFC7044] defines an optional SIP header field, History-Info, for capturing the history information in requests and 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. RFC7044 also defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field. Since the Diversion header is used in existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This work is intended to enable the migration from non- standard implementations and deployment toward IETF specification- based implementations and deployment. This document obsoletes [RFC6044].

Overview for MSRP Recording based on SIPREC Michael Yan, Paul Kyzivat 0000-00-00
SIPREC is capable of recording interactive text media that is transmitted via RTP. However that format is not commonly used for message or chat scenarios. There is also a need for recording text media carried via MSRP. One case of note is exchange of text between hearing-impaired users and emergence service bureaus. Also, recording support is needed for MSRP used in chat conferences and multimedia conferences. This document describes how to achieve MSRP channel recording within the mechanism of SIP Recording (SIPREC).

<< Start < Prev 1 2 Next > End >>
Display # Results 1 - 25 of 45