Login Form

Lost Password?

No account yet? Register

RECENT IETF DRAFTS

SIP internet drafts statistics

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

Read more ...

Title Author Date
Session Initiation Protocol (SIP) Cause URI parameter for Service Number translation Marianne Mohali, Mary Barnes 0000-00-00
RFC4458 (SIP URIs for applications) defines a "cause" URI parameter, which may appear in the Request-URI of a SIP request, that is used to indicate a reason why the request arrived to the User Agent Server (UAS) receiving the message. This document creates a new predefined value for the "cause" URI parameter to cover service number translation for cases of retargeting due to specific service action leading to the translation of a called service access number. This document also provides guidance, which was missing in RFC4458, for using the "cause" URI parameter within the History-Info header field since this use is mandatory in some IP networks\' implementations. This document updates RFC4458.

IANA Registration of New Session Initiation Protocol (SIP) Resource- Priority Namespace for Mission Critical Push To Talk service Christer Holmberg, Joergen Axell 0000-00-00
This document creates an additional Session Initiation Protocol (SIP) Resource-Priority namespace to meet the requirements of the 3GPP defined Mission Critical Push To Talk, and places this namespace in the IANA registry.

Requirements for Marking SIP Messages to be Logged Peter Dawes, Chidambaram Arunachalam 0000-00-00
SIP networks use signaling monitoring tools to debug customer reported problems 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 signaling will take between clients, and therefore impractical to monitor SIP signaling end-to-end. This draft describes requirements for adding an indicator to the SIP protocol data unit (PDU, or a SIP message) that marks the PDU as a candidate for logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signaling. 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, Suhas Nandakumar 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, Thomas Stach, 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).

A Session Initiation Protocol (SIP) INFO package for Private Wire 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.

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.

The Session Initiation Protocol (SIP) OAuth Rifaat Shekh-Yusef, Victor Pascual, Christer Holmberg 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.

Location Source Parameter for the SIP Geolocation Header Field James Winterbottom, Laura Liess, Bruno Chatras, Andrew Hutton, Roland Jesske 0000-00-00
There are some circumstances where a geolocation header field may contain more than one location value. Knowing the identity of the node adding the location value allows the recipient more freedom in selecting the value to look at first rather than relying solely on the order of the location values.

A P-Served-User Header Field Parameter for Originating CDIV session case in Session Initiation Protocol (SIP) Marianne Mohali 0000-00-00
This specification defines a new parameter of the P-Served-User header field in the Session Initiation Protocol (SIP). This new "orig-cdiv" parameter defines the session case used by a proxy when handling an originating session after Call Diversion (CDIV) services has been invoked for the served user. The P-Served-User header field is defined in RFC5502 to convey the identity of the served user and the session case that applies to this particular communication session and application invocation. This document updates RFC5502 to add the "originating after CDIV" session case and to provide more guidance for using the P-Served-User header field in IP networks that were missing in RFC5502.

Clarifications for when to use the name-addr production in SIP messages Robert Sparks 0000-00-00
RFC3261 constrained several SIP header fields whose grammar contains the "name-addr / addr-spec" alternative to use name-addr when certain characters appear. Unfortunately it expressed the constraints with prose copied into each header field definition, and at least one header field was missed. Further, the constraint has not been copied into documents defining extension headers whose grammar contains the alternative. This document updates RFC3261 to state the constraint generically, and clarifies that the constraint applies to all SIP header fields where there is a choice between using name-addr or addr-spec. It also updates those extension SIP header fields that use the alternative to clarify that the constraint applies (RFCs 3325, 3515, 3892, 4508, 5002, 5318, 5360, and 5502).

Setting up a SIP (Session Initiation Protocol) connection in a dual stack network using connection oriented transports Olle Johansson, Gonzalo Salgueiro, Dale Worley 0000-00-00
The Session Initiation Protocol (SIP) supports multiple transports running both over IPv4 and IPv6 protocols. In more and more cases, a SIP user agent (UA) is connected to multiple network interfaces. In these cases setting up a connection from a dual stack client to a dual stack server may suffer from the issues described in RFC 6555 [RFC6555] - Happy Eyeballs - significant delays in the process of setting up a working flow to a server. This negatively affects user experience. This document builds on RFC 6555 and explains how a RFC3261 [RFC3261] compliant SIP implementation can quickly set up working flows to a given hostname (located by using DNS NAPTR and SRV lookups) in a dual stack network using connection oriented transport protocols. A solution for connectionless transport protocols is discussed in a separate document.

SIP Call-Info Parameters for Labeling Calls Henning Schulzrinne 0000-00-00
Called parties often wish to decide whether to accept, reject or redirect calls based on the likely nature of the call. For example, they may want to reject unwanted telemarketing or fraudulent calls, but accept emergency alerts from numbers not in their address book. This document describes SIP Call-Info parameters and a feature tag that allow originating, intermediate and terminating SIP entities to label calls as to their type, spam probability and references to additional information.

Happy EarBalls: Success with Dual-Stack, Connection-Oriented SIP Olle Johansson, Gonzalo Salgueiro, Dale Worley 0000-00-00
The Session Initiation Protocol (SIP) supports multiple transports running both over IPv4 and IPv6 protocols. In more and more cases, a SIP user agent (UA) is connected to multiple network interfaces. In these cases setting up a connection from a dual stack client to a dual stack server may suffer from the issues described in RFC 6555 [RFC6555] ("Happy Eyeballs") - significant delays in the process of setting up a working flow to a server. This negatively affects user experience. This document builds on RFC 6555 and explains how a [RFC3261] compliant SIP implementation can minimize delays when contacting a host name (obtained by using DNS NAPTR and SRV lookups) in a dual stack network using connection-oriented transport protocols.

An Extension for SIP Instant Message Using Publish/Subscribe Mode Jianping Zheng, Yichuan Wu, Weimin Lei, Wei Zhang, Hao Li 0000-00-00
SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) is a protocol suite for instant messaging (IM) service, but it is inefficient in processing instant message in session mode due to its complex signaling processes and heavy header overheads, which makes it difficult to meet the QoE (quality of experience) requirement, especially in the usage scenario of mobile Internet and other traffic sensitive networks. This document describes an alternative Session Initiation Protocol (SIP) extension for instant messaging service. The extension uses the publish-subscribe mode to simplify signaling procedures and introduces message user agent (MUA) to publish and receive message, and message broker (MB) as an intermediary to exchange messages between MUAs. Message is tagged with a topic, and the lightweight message format is more suitable for traffic sensitive networks.

Third-Party Authentication for Session Initiation Protocol (SIP) Rifaat Shekh-Yusef, Christer Holmberg, Victor Pascual 0000-00-00
This document defines an authentication mechanism for SIP, that is based on the OAuth 2.0 and OpenID Connect Core 1.0 specifications, to enable the delegation of the user authentication to a dedicated third-party IdP entity that is separate from the SIP network elements that provide the SIP service.

Location Parameter for the SIP Reason Header Field Roland Jesske 0000-00-00
The SIP Reason header field is defined for Q.850 cause values. Some services in SIP networks may need to know the location where the call was released in the PSTN network to correctly interpret the reason of release.

Location Source Parameter for the SIP Geolocation Header Field James Winterbottom, Roland Jesske, Bruno Chatras, Andrew Hutton 0000-00-00
There are some circumstances where a geolocation header field may contain more than one location value. Knowing the identity of the node adding the location value allows the recipient more freedom in selecting the value to look at first rather than relying solely on the order of the location values.

TBD: Happy Earballs: Success with Dual-Stack SIP Dale Worley 0000-00-00
TBD: The Session Initiation Protocol (SIP) supports multiple transports running both over IPv4 and IPv6 protocols. In more and more cases, a SIP user agent (UA) is connected to network interfaces with multiple address families. In these cases sending a message from a dual stack client to a dual stack server may suffer from the issues described in [RFC6555] ("Happy Eyeballs"): the UA attempts to send the message using IPv6, but IPv6 connectivity is not working to the server. This can cause significant delays in the process of sending the message to the server. This negatively affects the user\'s experience. TBD: This document builds on [RFC6555] by modifying the procedures specified in [RFC3263] and related specifications to require that a client ensure that communication targets are accessible before sending messages to them, to allow a client to contact targets out of the order required by other specifications, and to require a client to properly distribute the message load among targets over time.

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.

Best Practices for Securing RTP Media Signaled with SIP Jon Peterson, Eric Rescorla, Richard Barnes, Russ Housley 0000-00-00
Although the Session Initiation Protocol (SIP) includes a suite of security services that has been expanded by numerous specifications over the years, there is no single place that explains how to use SIP to establish confidential media sessions. Additionally, existing mechanisms have some feature gaps that need to be identified and resolved in order for them to address the pervasive monitoring threat model. This specification describes best practices for negotiating confidential media with SIP, including both comprehensive protection solutions which bind the media to SIP-layer identities as well as opportunistic security solutions.

A SIP Response Code for Unwanted Calls Henning Schulzrinne 0000-00-00
This document defines the 666 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly.

Content ID header field in Session Initiation Protocol (SIP) Christer Holmberg, Ivo Sedlacek 0000-00-00
This document specifies the Content-ID header field for usage in the Session Initiation Protocol (SIP).

Session Initiation Protocol (SIP) Recording Call Flows 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 organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document lists call flows with metadata snapshots sent from a Session Recording Client(SRC) to a Session Recording Server(SRS).

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