Enterprise Connect 2019

IETF Drafts


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.

A SIP Response Code for Unwanted Calls

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.

Clarifications for when to use the name-addr production in SIP messages

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

Authenticated Identity Management in the Session Initiation Protocol (SIP)

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 a SIP header field for conveying a signature used for validating the identity, and for conveying a reference to the credentials of the signer.

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.

A Session Initiation Protocol (SIP) usage for Trickle ICE

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

Remote Call Control and Call Pick-up in SIP

This memo defines a mechanism by which a SIP user agent could inspect calls at another user agent, and control a call, including picking up for itself.

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.

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.