Login Form

Lost Password?

No account yet? Register

RECENT IETF DRAFTS

SIP internet drafts statistics

  • 31 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 are necessary because SIP allows a wide range of configuration and operational conditions that can influence performance benchmark measurements.

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.

Marking SIP Messages to be Logged Peter Dawes 0000-00-00
SIP networks use signalling monitoring tools to diagnose user reported problems 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 document describes an indicator for 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.

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 Session Initiation Protocol (SIP) usage for Trickle ICE Emil Ivov, Enrico Marocco, Christer Holmberg 0000-00-00
The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism 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 and by executing them in parallel. This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP).

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.

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 -04 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.

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. The specification repeatedly states that the implementation should look up IPv4 or IPv6 addresses. This is not a suitable solution and one that can cause severely degraded user experience dual-stack clients, as detailed in the Happy Eyeballs specification. This document specifies amended procedures for dual- stack SIP implementations so that they look up both IPv4 and IPv6 addresses. This way, the SIP implementation can find the preferred network path and protocol with an improved chance of successfully reaching the desired service. This document also clarifies DNS SRV usage for single-stack clients.

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.

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).

3rd-Generation Partnership Project (3GPP) SIP URI Inter Operator Traffic Leg parameter Christer Holmberg, Jan Holm, Roland Jesske, Martin Dolly 0000-00-00
In 3rd-Generation Partnership Project (3GPP) networks, the signalling path between a calling user and a called user can be partioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators, and will have its own characteristics that can be different from other traffic legs in the same call. A traffic leg might be associated with multiple SIP dialogs, e.g. in case a B2BUA which modifies the SIP dialog identifier is located within the traffic leg. This document defines a new SIP URI parameter, \'iotl\'. The parameter can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs). The SIP URI \'iotl\' parameter defined in this document has known uses in 3GPP networks. Usage in other networks is also possible.

The Session Initiation Protocol (SIP) OAuth Rifaat Shekh-Yusef, Victor Pascual 0000-00-00
This document defines an authorization framework for SIP that is based on the OAuth 2.0 framework, and adds a simple identity layer on top of that, based on the OpenID Connect Core 1.0, to enable Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User.

DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) Ram R, Tirumaleswar Reddy, Gonzalo Salgueiro, Victor Pascual, Parthasarathi Ravindran 0000-00-00
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) often function on the media plane, rather than just on the signaling path. This document describes the behavior B2BUAs should follow when acting on the media plane that use Secure Real-time Transport (SRTP) security context setup with Datagram Transport Layer Security (DTLS) protocol.

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.

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).

Session Initiation Protocol (SIP) Cause URI parameter for Service Number translation Marianne Mohali 0000-00-00
[RFC4458] defines a "cause" URI parameter as having predefined values for Redirecting reasons as a mapping from ITU-T Q.732.2-5 Redirecting Reasons. The "cause" URI parameter is to be used in SIP or SIPs URI. In particular, it may appear in the History-Info header defined in [RFC7044] that MUST be added in retargeted requests. This specification creates a new predefined value for cases when the retargeting is caused by a specific service action leading to a called number translation. This document updates [RFC4458].

Session Initiation Protocol (SIP) Cause URI parameter for Service Number translation Marianne Mohali 0000-00-00
[RFC4458] defines a "cause" URI parameter as having predefined values for Redirecting reasons as a mapping from ITU-T Q.732.2-5 Redirecting Reasons. The "cause" URI parameter is to be used in SIP or SIPs URI. In particular, it may appear in the History-Info header field defined in [RFC7044] that must be added in retargeted requests. This specification creates a new predefined value for cases when the retargeting is caused by a specific service action leading to a called service access number translation. This document updates [RFC4458].

A clarification on the use of Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP) Event Notification Framework Adam Roach 0000-00-00
Experience since the publication of the most recent SIP Events framework has shown that there is room for interpretation around the use of Globally Routable User Agent URIs in that specification. This document clarifies the intended behavior. This document updates RFC 6665.

Telecommunications Relay Service Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP) Paul Kyzivat 0000-00-00
This document defines and registers a value of "original-identity" for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP).

Considerations for Information Services and Operator Services Using SIP John Haluska, Richard Ahern, Marty Cruze, Chris Blackwell 0000-00-00
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.

URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP) Laura Liess, Roland Jesske, Alan Johnston, Dale Worley, Paul Kyzivat 0000-00-00
The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UA as an alerting signal (e.g., a ring tone or ringback tone) when the user is alerted. This is done using the Alert-Info header field. However, the reference (typically a URL) addresses only a specific network resource with specific rendering properties. There is currently no support for 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 these limitations and support new applications, a new family of URNs for use in Alert-Info header fields (and situations with similar requirements) is defined in this specification. This document normatively updates RFC3261, which defines the Session Initiation Protocol (SIP): It changes the usage of the Alert-Info header field defined in RFC3261 by additionally allowing its use in any non-100 provisional response to INVITE.This document also permits proxies to add or remove an Alert-Info header field, and to add or remove Alert-Info header field values.

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.

Session Initiation Protocol (SIP) Recording Metadata Ram R, Parthasarathi Ravindran, Paul Kyzivat 0000-00-00
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.

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