Enterprise Connect 2019

IETF Drafts


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.

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.

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.

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.

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.