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