Skip to content

IETF Drafts


A P-Served-User Header Field Parameter for Originating CDIV session case in Session Initiation Protocol (SIP)

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.

SIP Call-Info Parameters for Labeling Calls

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.

Location Source Parameter for the SIP Geolocation Header Field

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.

Third-Party Authentication for Session Initiation Protocol (SIP)

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.

An Extension for SIP Instant Message Using Publish/Subscribe Mode

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.

Marking SIP Messages to be Logged

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.

Happy EarBalls: Success with Dual-Stack, Connection-Oriented SIP

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.

SIP Call-Info Parameters for Labeling Calls

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.

Setting up a SIP (Session Initiation Protocol) connection in a dual stack network using connection oriented transports

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.

Location Source Parameter for the SIP Geolocation Header Field

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.

Upcoming Events