Paul Jones, James Polk, Gonzalo Salgueiro, Chris Pearce
This document describes an end-to-end Session Identifier for use in
IP-based multimedia communication systems that enables endpoints,
intermediate devices, and management systems to identify a session
end-to-end, associate multiple endpoints with a given multipoint
conference, track communication sessions when they are redirected,
and associate one or more media flows with a given communication
This document also describes a backwards compatibility mechanism for
an existing (RFC 7329) session identifier implementation that is
sufficiently different from the procedures defined in this document.
SIP networks use signalling 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 signalling will take between clients, and
therefore impractical to monitor SIP signalling 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 signalling. However, such marking can be
carried end-to-end including the SIP terminals, even if a session
originates and terminates in different networks.
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
Thomas, Enrico Marocco, Christer Holmberg
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).
This text documents \'P-Charge-Info\', an existing private Session
Initiation Protocol (SIP) header (P-header) used to convey billing
information about the party to be charged. This P-Header is
currently in production usage by a number of equipment vendors and
carriers and this document is submitted to request the registration
of this header with IANA. This P-Header may also be used in some
situations to carry the ISUP Charge Number parameter for PSTN
NOTE: This document has been in development since 2008 under the name
draft-york-sipping-p-charge-info. This -05 document is identical to
draft-york-sipping-p-charge-info-15 except for edits to the text to
indicate this is now for the DISPATCH working group as the SIPPING
working group no longer exists.
This document describes how the SIP Instance ID as defined in RFC
5626  is used by the Open Mobile Alliance (OMA), for Push-to-talk
over Cellular (PoC) and Push-to-Communicate for Public Safety (PCPS)
and addresses security concerns with use of the SIP instance ID in
non-register requests and responses.
This document updates RFC 7255  to allow the use of the
International Mobile Equipment Identity (IMEI) as an instance ID in
the Contact header field of non-register requests and responses by
the OMA PoC and PCPS enablers for the purposes described in this
Although the SIP History-Info header field is the solution adopted in
IETF, the non-standard Diversion header field is nevertheless already
implemented and used for conveying call diversion related information
in the Session Initiation Protocol (SIP) signaling.
On one hand, the non-standard Diversion header field is described, as
Historic, in [RFC5806]. On the other hand, the History-Info header
field is described in [RFC7044] that obsoletes the original[RFC4244]
describing the History-Info header field. [RFC7044] defines the SIP
header field, History-Info, for capturing the history information in
requests and new SIP header field parameters for the History-Info and
Contact header fields to tag the method by which the target of a
request is determined. [RFC7044] also defines a value for the
Privacy header field that directs the anonymization of values in the
History-Info header field.
Since the Diversion header field is used in existing network
implementations for the transport of call diversion information, its
interworking with the SIP History-Info standardized solution is
needed. This document describes a recommended interworking guideline
between the Diversion header field and the History-Info header field
to handle call diversion information. In addition, an interworking
policy is proposed to manage the headers\' coexistence. This work is
intended to enable the migration from non-standard implementations
and deployments toward IETF specification-based implementations and
This document obsoletes [RFC6044]that describes the interworking
between the Diversion header field [RFC5806] and the obsoleted
History-Info header field as defined on [RFC4244].
SIPREC is capable of recording interactive text media that is
transmitted via RTP. However that format is not commonly used for
message or chat scenarios. There is also a need for recording text
media carried via MSRP. One case of note is exchange of text between
hearing-impaired users and emergence service bureaus. Also,
recording support is needed for MSRP used in chat conferences and
This document describes how to achieve MSRP channel recording within
the mechanism of SIP Recording (SIPREC).
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.
Ram R, Tirumaleswar Reddy, Gonzalo Salgueiro,
Victor Pascual, Parthasarathi Ravindran
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)
often function on the media plane, rather than just on the signaling
path. This document describes the behavior B2BUAs should follow when
acting on the media plane that use Secure Real-time Transport (SRTP)
security context setup with Datagram Transport Layer Security (DTLS)
[RFC4458] defines a "cause" URI parameter as having predefined values
for Redirecting reasons as a mapping from ITU-T Q.732.2-5 Redirecting
Reasons. The "cause" URI parameter is to be used in SIP or SIPs URI.
In particular, it may appear in the Request-URI of a SIP request.
This specification creates a new predefined value for the "cause" URI
parameter for cases when the retargeting is due to specific service
action leading to a called service access number translation.
This document updates [RFC4458].
This document specifies the way that the elliptic curve secure remote
protocol (EC-SRP) is applied to SIP authentication. SIP Client and
server perform mutual authenticate by using the modern \'zero
knowledge\' method without disclosing the password in the process. It
has low computation complexity and low bandwidth consumption due to
the use of elliptical curve cryptography. This makes it more suitable
for resource-constrained environments,e.g. wireless network. The
security of the scheme is based on the computational intractability
of the elliptic curve discrete logarithm problem. It is resilient to
various kinds of attacks, including off-line dictionary attacks.
This document proposes an extension to the Session Initiation
Protocol (SIP). This extension provides the ability for calling SIP
User to specify the call urgency while originating a call and for
called SIP user agent to identify that call is an \'Urgent\' call.
RFC 5727 defines several processes for the Real-time Applications and
Infrastructure (RAI) area. These processes include the evolution of
the Session Initiation Protocol (SIP) and related protocols, as well
as the operation of the DISPATCH and SIPCORE working groups. This
document updates RFC 5727 to allow flexibility for the area and
working group structure, while preserving the SIP change processes.
It also generalizes the DISPATCH working group processes so that they
can be easily adopted by other working groups.
Winterbottom, Laura Liess, Bruno Chatras, Andrew Hutton
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.
This document specifies the SIP P-User-Location-Info P-header. This
header field addresses an issue that was identified when non-3GPP
access and non-trusted networks are integrated to IMS (IP Multimedia
Subsystem) networks. This header field conveys the trusted network
determined location information of a served user when the user is
registered for IMS services via non-3GPP access networks.
The User Agent capabilities specification allows Session Initiation
Protocol (SIP) User Agents to convey their capabilities and
characteristics to other User Agents and to the registrar for its
domain. This information is conveyed as parameters of the Contact
header field. Amongst those capabilities are the type of User Agent
that is available at a SIP Uniform Resource Identifier (URI). This
document extends the User Agent capabilities specification to allow
indication of Back-to-Back User Agent (B2BUA) types.
David Bryan, Philip
Matthews, Eunsoo Shim, Dean Willis, Spencer Dawkins
This document defines concepts and terminology for the use of the
Session Initiation Protocol in a peer-to-peer environment where the
traditional proxy-registrar and message routing functions are
replaced by a distributed mechanism. These mechanisms may be
implemented using a distributed hash table or other distributed data
mechanism with similar external properties. This document includes a
high-level view of the functional relationships between the network
elements defined herein, a conceptual model of operations, and an
outline of the related problems addressed by the P2PSIP working group
and the RELOAD protocol and SIP usage ([RFC6940],
[I-D.ietf-p2psip-sip]) defined by the working group.
Cullen Jennings, Bruce Lowekamp, Eric
Rescorla, Salman Baset, Henning Schulzrinne, Thomas Schmidt
This document defines a SIP Usage for REsource LOcation And Discovery
(RELOAD). The SIP Usage provides the functionality of a SIP proxy or
registrar in a fully-distributed system and includes a lookup service
for Address of Records (AORs) stored in the overlay. It also defines
Globally Routable User Agent Uris (GRUUs) that allow the
registrations to map an AOR to a specific node reachable through the
overlay. After such initial contact of a peer, the AppAttach method
is used to establish a direct connection between nodes through which
SIP messages are exchanged.
John Haluska, Richard Ahern, Marty Cruze, Chris Blackwell
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.
RFC 3263 defines how a Session Initiation Protocol (SIP)
implementation, given a SIP Uniform Resource Identifier (URI), should
locate the next hop SIP server using Domain Name System (DNS)
procedures. As SIP networks increasingly transition from IPv4-only
to dual-stack, a quality user experience must be ensured for dual-
stack SIP implementations. This document supplements the DNS
procedures described in RFC 3263 for dual-stack SIP implementations
and ensures that they properly align to the optimizations detailed by
Experience since the publication of the most recent SIP Events
framework has shown that there is room for interpretation around the
use of Globally Routable User Agent URIs in that specification. This
document clarifies the intended behavior.
This document updates RFC 6665.