One document matched: draft-ietf-sip-sips-07.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "http://xml.resource.org/authoring/rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!ENTITY I-D.ietf-sip-outbound SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-outbound.xml">
<!ENTITY rfc2543 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2543.xml">
<!ENTITY rfc3327 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3327.xml">
<!ENTITY rfc3515 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3515.xml">
<!ENTITY rfc3608 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3608.xml">
<!ENTITY rfc3725 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3725.xml">
<!ENTITY rfc3891 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3891.xml">
<!ENTITY rfc3893 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3893.xml">
<!ENTITY rfc3911 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3911.xml">
<!ENTITY rfc4168 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4168.xml">
<!ENTITY rfc4244 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4244.xml">
<!ENTITY rfc4474 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml">
<!ENTITY I-D.ietf-sip-gruu SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-gruu.xml">
<!ENTITY I-D.gurbani-sip-sipsec SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.gurbani-sip-sipsec.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc category="std" docName="draft-ietf-sip-sips-07" ipr="full3978"
updates="3261, 3608">
<front>
<title abbrev="SIPS">The use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)</title>
<author fullname="Francois Audet" initials="F." surname="Audet">
<organization>Nortel</organization>
<address>
<postal>
<street>4655 Great America Parkway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95054</code>
<country>US</country>
</postal>
<phone>+1 408 495 2456</phone>
<email>audet@nortel.com</email>
</address>
</author>
<date day="13" month="November" year="2007" />
<area>Real-time Applications and Infrastructure</area>
<workgroup>SIP</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>SIPS</keyword>
<keyword>SIP</keyword>
<keyword>TLS</keyword>
<abstract>
<t>This document provides clarifications and guidelines concerning the
use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It
also makes normative changes to SIP. This document also provides a
discussion of possible future steps in specification.</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>The meaning and usage of the SIPS URI scheme and of TLS <xref
target="RFC4346"></xref> is underspecified in SIP <xref
target="RFC3261"></xref> and has been a source of confusion for
implementers.</t>
<t>This document provides clarifications and guidelines concerning the
use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It
also makes normative changes to SIP (including both <xref
target="RFC3261"></xref> and <xref target="RFC3608"></xref>. This
document also provides a discussion of possible future steps in
specification.</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Background">
<section title="Models for Using TLS in SIP">
<t>This section describes briefly the usage of TLS in SIP.</t>
<section anchor="server-provided" title="Server-Provided Certificate">
<t>In this model, only the TLS server provides a certificate during
the TLS handshake. This is applicable only between a UA and a proxy,
where the UA is the TLS client and the proxy is the TLS server, and
hence the UA uses TLS to authenticate the proxy but the proxy does
not use TLS to authenticate the UA. If the proxy needs to
authenticate the UA, this can be achieved by SIP HTTP digest
authentication. This directionality implies that the TLS connection
always needs to be setup by the UA (e.g., during the registration
phase). Since SIP allows for requests in both directions (e.g, an
incoming call), the UA is expected to keep the TLS connection alive
and that connection is expected to be re-used for both incoming and
outgoing requests.</t>
<t>This solution of having the UA always initiate and keep alive the
connection also solves the NAT and firewall problem as it ensures
that responses and further requests will always be deliverable on
the existing connection.</t>
<t><xref target="I-D.ietf-sip-outbound"></xref> provides the
mechanism for initiating and maintaining outbound connections in a
standard interoperable way.</t>
</section>
<section title="Mutual authentication">
<t>In this model, both the TLS client and the TLS server provide a
certificate in the TLS handshake phase. When used between a UA and a
proxy (or between two UAs), this implies that a UA is in possession
of a certificate. When sending a SIP request when there is not
already a suitable TLS connection in place, a UAC takes on the role
of TLS client in establishing a new TLS connection. When
establishing a TLS connection for receipt of a SIP request, a UAS
takes on the role of TLS server. Since in SIP, a UA or a Proxy act
both as UAC and UAS depending on if they are sending or receiving
requests, the symmetrical nature of mutual TLS is very convenient.
This allows for TLS connections to be set-up or torn down at will
and does not rely on keeping the TLS connection alive for further
requests.</t>
<t>However, there are some significant limitations.</t>
<t>The first obvious limitation is not with mutual authentication
per se, but with the model where the underlying TCP connection can
be established by either side, interchangeably, which is not
possible in many environments. For examples, NATs and firewalls will
often allow TCP connections to be established in one direction only.
This includes most residential SIP deployments, for example. Mutual
authentication can be used in those environments, but only if the
connection is always started by the same side, for example, by using
<xref target="I-D.ietf-sip-outbound"></xref> as described in <xref
target="server-provided"></xref>. Having to rely on <xref
target="I-D.ietf-sip-outbound"></xref> in this case negates many of
the advantages of mutual authentication.</t>
<t>The second significant limitation is that mutual authentication
requires both sides to exchange a certificate. This has proven to be
impractical in many environments, in particular for SIP UAs, because
of the difficulties of setting up a certificate infrastructure for a
wide population of users.</t>
<t>For these reasons, mutual authentication is mostly used in
server-to-server communications (e.g., between SIP proxies, or
between proxies and gateways or media servers), and in environments
where using certificates on both sides is possible (e.g.,
high-security devices used within an enterprise).</t>
</section>
<section title="Using TLS with SIP instead of SIPS">
<t>Because a SIPS URI implies that requests sent to the resource
identified by it be sent over each SIP hop over TLS, SIPS URIs are
not suitable for "best-effort TLS": they are only suitable for
"TLS-only" requests. This is recognized in section <xref
target="RFC3261"></xref>/26.2.2:</t>
<t><list>
<t>"Users that distribute a SIPS URI as an address-of-record may
elect to operate devices that refuse requests over insecure
transports."</t>
</list></t>
<t>If one wants to use "best-effort TLS" for SIP, one just needs to
use a SIP URI, and send the request over TLS.</t>
<t>Using SIP over TLS is very simple. A UA opens a TLS connection
and uses SIP URIs instead of SIPS URIs for all the header fields in
a SIP message (From, To, Request-URI, Contact header field, Route,
etc.). When TLS is used, the Via header field indicates TLS.</t>
<t><xref target="RFC3261"></xref>/26.3.2.1 states:</t>
<t><list>
<t>"When a UA comes online and registers with its local
administrative domain, it SHOULD establish a TLS connection with
its registrar (...). Once the registration has been accepted by
the registrar, the UA SHOULD leave this TLS connection open
provided that the registrar also acts as the proxy server to
which requests are sent for users in this administrative domain.
The existing TLS connection will be reused to deliver incoming
requests to the UA that had just completed registration."</t>
</list></t>
<t><xref target="I-D.ietf-sip-outbound"></xref> describes how to
establish and maintain a TLS connection in environments where it can
only be initiated by the UA.</t>
<t>Similarly, proxies can forward requests using TLS if they can
open a TLS connection, even if the route set used SIP URIs instead
of SIPS URIs. The proxies can insert Record-Route header fields
using SIP URIs even if it uses TLS transport. <xref
target="RFC3261"></xref>/26.3.2.2 explains how interdomain requests
can use TLS.</t>
<t>Some user agents, redirect servers and proxies might have local
policies that enforce TLS on all connections, independently of if
SIPS is used or not.</t>
</section>
<section anchor="transportparam"
title="Usage of the transport=tls URI Parameter and the TLS Via Parameter">
<t><xref target="RFC3261"></xref>/26.2.2 deprecated the
"transport=tls" URI transport parameter in SIPS or SIP URIs:</t>
<t><list>
<t>"Note that in the SIPS URI scheme, transport is independent
of TLS, and thus "sips:alice@atlanta.com;transport=TCP" and
"sips:alice@atlanta.com;transport=sctp" are both valid (although
note that UDP is not a valid transport for SIPS). The use of
"transport=tls" has consequently been deprecated, partly because
it was specific to a single hop of the request. This is a change
since RFC 2543."</t>
</list></t>
<t>The "tls" parameter has not been eliminated from the ABNF in
<xref target="RFC3261"></xref>/25 since the parameter needs to
remain in the ABNF for backward compatibility in order for parsers
to be able to process the parameter correctly. The transport=tls
parameter has never been defined in an RFC, but only in some of the
Internet drafts between <xref target="RFC2543"></xref> and <xref
target="RFC3261"></xref>.</t>
<t>This specification does not make use of the transport=tls
parameter.</t>
<t>The reinstatement of the transport=tls parameter, or an
alternative mechanism for indicating the use of the TLS on a single
hop in a URI, are outside the scope of this specification (see <xref
target="future-transport"></xref>).</t>
<t>For Via header fields, the following transport protocol are
defined in <xref target="RFC3261"></xref>: "UDP", "TCP", "TLS",
"SCTP", and in <xref target="RFC4168"></xref>: "TLS-SCTP".</t>
</section>
</section>
<section title="Detection of Hop-by-Hop Security">
<t>The presence of a SIPS Request-URI does not necessarily indicate
that the request was sent securely on each hop. So how does a UAS know
if SIPS was used for the entire request path to secure the request
end-to-end? Effectively, the UAS cannot know for sure. However, <xref
target="RFC3261"></xref>/26.4.4 recommends how a UAS can make some
checks to validate the security. Additionally, the History-Info header
field <xref target="RFC4244"></xref> could be inspected for detecting
retargeting from SIP and SIPS. Retargeting from SIP to SIPS by a proxy
is an issue because it can leave the receiver of the request with the
impression that the request was delivered securily on each hop, while
in fact, in was not.</t>
<t>To emphasize, all the checking can be circumvented by any proxies
or B2BUAs on the path that do not follow the rules and recommendations
of this specification and of <xref target="RFC3261"></xref>.</t>
<t>Proxies can have their own policies regarding routing of requests
to SIP or SIPS URIs. For example, some proxies in some environment can
be configured to only route SIPS URIs. Some proxies can be configured
to detect non-compliances and reject un-secure requests. For example,
proxies could inspect Request-URIs, Path, Record-Route, To, From,
Contact header fields and Via header fields to enforce SIPS.</t>
<t><xref target="RFC3261"></xref>/26.4.4 explains that S/MIME can also
be used by the originating UAC to ensure that the original form of the
To header field is carried end-to-end. While not specifically
mentioned in <xref target="RFC3261"></xref>/26.4.4, this is meant to
imply that <xref target="RFC3893"></xref> would be used to "tunnel"
important header fields (such as To and From) in an encrypted and
signed S/MIME body, replicating the information in the SIP message,
and allowing the UAS to validate the content of those important header
fields. While this approach is certainly legal, a preferable approach
is to use the SIP Identity mechanism defined in <xref
target="RFC4474"></xref>. SIP Identity creates a signed identity
digest which includes, amongst other things, the AOR of the sender
(from the From header field) and the AOR of the original target (from
the To header field).</t>
</section>
<section anchor="problems"
title="The Problems with the Meaning of SIPS in RFC 3261">
<t><xref target="RFC3261"></xref>/19.1 describes a SIPS URI as
follows:</t>
<t><list>
<t>"A SIPS URI specifies that the resource be contacted securely.
This means, in particular, that TLS is to be used between the UAC
and the domain that owns the URI. From there, secure
communications are used to reach the user, where the specific
security mechanism depends on the policy of the domain."</t>
</list></t>
<t>Section 26.2.2 re-iterates it, with regards to Request-URIs:</t>
<t><list>
<t>"When used as the Request-URI of a request, the SIPS scheme
signifies that each hop over which the request is forwarded, until
the request reaches the SIP entity responsible for the domain
portion of the Request-URI, must be secured with TLS; once it
reaches the domain in question it is handled in accordance with
local security and routing policy, quite possibly using TLS for
any last hop to a UAS. When used by the originator of a request
(as would be the case if they employed a SIPS URI as the
address-of-record of the target), SIPS dictates that the entire
request path to the target domain be so secured."</t>
</list></t>
<t>Let's take the classic SIP trapezoid to explain the meaning of a
sips:b@B URI. Instead of using real domain names like example.com and
example.net, logical names like "A" and "B" are used, for clarity.</t>
<figure align="center" title="SIP trapezoid with last hop exception">
<artwork><![CDATA[
.......................... ...........................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | Proxy |-----TLS---- | Proxy | .
. | A | . . | B | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. TLS . . Policy-based .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | UAC a | . . | UAS b | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
.......................... ...........................
]]></artwork>
</figure>
<t>According to <xref target="RFC3261"></xref>, if a@A is sending a
request to sips:b@B, the following applies:<list style="symbols">
<t>TLS is required between UA a@A and Proxy A</t>
<t>TLS is required between Proxy A and Proxy B</t>
<t>TLS is required between Proxy B and UA b@B, depending on local
policy.</t>
</list></t>
<t>One can then wonder why TLS is mandatory between UA a@A and Proxy A
but not between Proxy B and UA b@B. The main reason is that <xref
target="RFC3261"></xref> was written before <xref
target="I-D.ietf-sip-outbound"></xref>. At that time, it was
recognized that in many practical deployments, Proxy B might not be
able to establish a TLS connection with UA b because only Proxy B
would have a certificate to provide and UA b would not. Since UA b
would be the TLS Server, it would then not be able to accept the
incoming TLS connection. The consequence is that an <xref
target="RFC3261"></xref>-compliant UAS b, while it might not need to
support TLS for incoming requests, will nevertheless have to support
TLS for outgoing requests as it takes the UAC role. Contrary to what
many believed erroneously, the last-hop exception was not created to
allow for using a SIPS URI to address a UAS that does not support TLS:
the last-hop exception was an attempt to allow for incoming requests
to not be transported over TLS when a SIPS URI is used, and it does
not apply to outgoing requests. The rationale for this was somewhat
flawed, and since then, <xref target="I-D.ietf-sip-outbound"></xref>
has provided a more satisfactory solution to this problem. <xref
target="I-D.ietf-sip-outbound"></xref> also solves the problem that if
UA b is behind a NAT or Firewall, proxy B would not even be able to
establish a TCP session in the first place.</t>
<t>Furthermore, consider the problem of using SIPS inside a dialog. If
a@A sends a request to b@B using a SIPS Request-URI, then, according
to <xref target="RFC3261"></xref>/8.1.1.8, "the Contact header field
MUST contain a SIPS URI as well". This means that b@B, upon sending a
new Request within the dialog (e.g., a BYE or re-INVITE), will have to
use a SIPS URI. If there is no Record-Route entry, or if the last
Record-Route entry consist of a SIPS URI, this implies that b@B is
expected to understand SIPS in the first place, and is required to
also support TLS. If the last Record-Route entry however is a sip URI,
then b would be able to send requests without using TLS (but b would
still have to be able to handle SIPS schemes when parsing the
message). In either case, the Request-URI in the request from b@B to B
would be a SIPS URI.</t>
</section>
</section>
<section title="Overview of Operations">
<t>Because of all the problems described in <xref
target="problems"></xref>, this specification deprecates the last hop
exception when forwarding a request to the last hop (see <xref
target="proxy-behavior"></xref>). This will ensure that TLS is used on
all hops all the way up to the remote target.</t>
<figure align="center" title="SIP trapezoid without last hop exception">
<artwork><![CDATA[
.......................... ...........................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | Proxy |-----TLS---- | Proxy | .
. | A | . . | B | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. TLS . . TLS .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | UAC a | . . | UAS b | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
.......................... ...........................
]]></artwork>
</figure>
<t>The SIPS scheme implies transitive trust. Obviously, there is nothing
that prevents proxies from cheating (see <xref
target="RFC3261"></xref>/26.4.4). While SIPS is useful to request that a
resource be contacted securely, it is not useful as an indication that a
resource was in fact contacted securely. Therefore, it is not
appropriate to infer that because an incoming request had a Request-URI
(or even a To header field) containing a SIPS URI, that it necessarily
guarantees that the request was in fact transmitted securely on each
hop. Some have been tempted to believe that the SIPS scheme was
equivalent to an HTTPS scheme in the sense that one could provide a
visual indication to a user (e.g., a padlock icon) to the effect that
the session is secured. This is obviously not the case, and therefore
the meaning of a SIPS URI is not to be oversold. There is currently no
mechanism to provide an indication of end-to-end security for SIP. Other
mechanisms can provide a more concrete indication of some level of
security. For example, SIP Identity <xref target="RFC4474"></xref>
provides an authenticated identity mechanism and a domain-to-domain
integrity protection mechanism.</t>
<t>Some have asked why is SIPS useful in a global open environment such
as the Internet, if (when used in a Request-URI) it is not an absolute
guarantee that the request will in fact be delivered over TLS on each
hop? Why is SIPS any different than just using TLS transport with SIP?
The difference is that using a SIPS URI in a Request-URI means that if
you are instructing the network to use TLS over each hop, and if it is
not possible, to reject the request: i.e., that you would rather have
the request fail than have the request delivered without TLS. Just using
TLS with a SIP Request-URI instead of a SIPS Request-URI implies a
"best-effort" service: the request can but need not be delivered over
TLS on each hop.</t>
<t>Another common question is why not have a Proxy-Require and Require
option tag forcing the use of TLS instead? The answer is that it would
only be functionally equivalent to using SIPS in a Request-URI. SIPS
URIs however can be used in many other header fields: in Contact for
registration, Contact in dialog-creating requests, Route, Record-Route,
Path, From, To, Refer-To, Referred-By, etc. SIPS URIs can also be used
in human-usable format (e.g., business cards, user interface, etc.).
SIPS URIs can even be used in other protocols or document formats that
allow for including SIPS URIs (e.g., HTML).</t>
<t>This document specifies that SIPS means that the SIP resource
designated by the target SIPS URI is to be contacted securely, using TLS
on each hop between the UAC and the remote UAS (as opposed to only to
the proxy responsible for the target domain of the Request-URI). It is
outside of the scope of this document to specify what happens when a
SIPS URI identifies a UAS resource that "maps" outside of the SIP
network, for example, to other networks such as the PSTN.</t>
<section title="Routing">
<t>SIP and SIPS URIs that are identical except for the scheme itself
(e.g., sip:alice@example.com and sips:alice@example.com) refer to the
same resource. This requirement is implicit in <xref
target="RFC3261"></xref>/19.1 which states that "Any resource
described by a SIP URI can be "upgraded" to a SIPS URI by just
changing the scheme, if it is desired to communicate with that
resource securely". This does not mean that the SIPS URI will
necessarily be reachable, in particular, if the proxy cannot establish
a secure connection to a client or another proxy. This does not
suggest either that proxies would arbitrarily "upgrade" SIP URIs to
SIPS URIs when forwarding a request (see <xref
target="proxy-behavior"></xref>). Rather, it means that when a
resource is addressable with SIP, it will also be addressable with
SIPS.</t>
<t>For example, consider the case of a UA that has registered with a
SIPS Contact header field. If a UAC later addresses a request using a
SIP Request-URI, the proxy will forward the request addressed to a SIP
Request-URI to the UAS, as illustrated by message F13 in <xref
target="sip-bob"></xref> and in <xref target="sip-bob-tls"></xref>.
The proxy forwards the request to the UA using a SIP Request-URI and
not the SIPS Request-URI used in registration. The proxy does this by
replacing the SIPS scheme that was used in the registered Contact
header field binding with a SIP scheme while leaving the rest of the
URI as is, and then by using this new URI as the Request-URI. If the
proxy did not do this, and instead used a SIPS Request-URI, then the
response (e.g., a 200 to an INVITE) would have to include a SIPS
Contact header field. That SIPS Contact header field would then force
the other UA to use a SIPS Contact header field in any mid-dialog
request, including the ACK (which would not be possible if that UA did
not support SIPS).</t>
<t>This specification mandates that when a proxy is forwarding a
request, a resource described by a SIPS Request-URI cannot be
"downgraded" to a SIP URI by changing the scheme, or by sending the
associated request over a non-secure link. If a request needs to be
rejected because otherwise it would be a "downgrade", the request
would be rejected with a 480 (Temporarily Unavailable) response
(potentially with a Warning header with warn-code 380 "SIPS Not
Allowed"). Similarly, this specification mandates that when a proxy is
forwarding a request, a resource described by a SIP Request-URI cannot
be "upgraded" to a SIPS URI by changing the scheme (otherwise it would
be an "upgrade" only for that hop onwards rather than on all hops, and
would therefore mislead the UAS). If a request needs to be rejected
because otherwise it would be a misleading "upgrade", the request
would be rejected with a 480 (Temporarily Unavailable) response
(potentially with a Warning header field with warn-code 381 "SIPS
Required"). See <xref target="proxy-behavior"></xref> for more
details.</t>
<t>For example, the sip:bob@example.com and sips:bob@example.com AORs
refers to the same user "Bob" in the domain "example.com": the first
URI is the SIP version, and the second one is the SIPS version. From
the point of view of routing, requests to either sip:bob@example.com
and sips:bob@example.com are treated the same way. When Bob registers,
it therefore does not really matter if he is using a SIP or a SIPS
AOR, since they both refer to the same user. At first glance, section
<xref target="RFC3261"></xref>/19.1.4 seems to contradict this idea by
stating that a SIP and a SIPS URI are never equivalent. Specifically,
it says that they are never equivalent for the purpose of comparing
bindings in Contact header field URIs in REGISTER requests. The key
point is that this statement applies to the Contact header field
bindings in a registration: it is the association of the Contact
header field with the AOR that will determine if the user is reachable
or not with a SIPS URI.</t>
<t>Consider this example: if Bob (AOR bob@example.com) registers with
a SIPS Contact header field (e.g., sips:bob@bobphone.example.com), the
registrar and the location service then know that Bob is reachable at
sips:bob@bobphone.example.com, and at sip:bob@bobphone.example.com. If
a request is sent to AOR sips:bob@example.com, Bob's proxy will route
it to Bob at Request-URI sips:bob@bobphone.example.com. If a request
is sent to AOR sip:bob@example.com, Bob's proxy will route it to Bob
at Request-URI sip:bob@bobphone.example.com.</t>
<t>If Bob wants to ensure that every request delivered to him always
be transported over TLS, Bob can use <xref
target="I-D.ietf-sip-outbound"></xref> when registering.</t>
<t>However, if Bob had registered with a SIP Contact header field
instead of a SIPS Contact header field (e.g.,
sip:bob@bobphone.example.com), then a request to AOR
sips:bob@example.com would not be routed to Bob, since there is no
SIPS Contact header field for Bob, and "downgrades" from SIPS to SIP
are not allowed.</t>
<t>See <xref target="flows"></xref> for illustrative call flows.</t>
</section>
</section>
<section title="Normative Requirements">
<t>This section describes all the normative requirements defined by this
specification.</t>
<section title="General User Agent Behavior">
<section title="UAC Behavior">
<t>When presented with a SIPS URI, a UAC MUST NOT change it to a SIP
URI. For example, if a directory entry includes a SIPS AOR, the UAC
is not expected to send requests to that AOR using a SIP
Request-URI. Similarly, if a user reads a business card with a SIPS
URI, it is not possible to infer a SIP URI. If a 3XX response
includes a SIPS Contact header field, the UAC does not replace it
with a SIP Request-URI (e.g., by replacing the SIPS scheme with a
SIP scheme) when sending a request as a result of the
redirection.</t>
<t>As mandated by <xref target="RFC3261"></xref>/8.1.1.8, in a
request, "If the Request-URI or top Route header field value
contains a SIPS URI, the Contact header field MUST contain a SIPS
URI as well".</t>
<t>Upon receiving a 416 response or a 480 (Temporarily Unavailable)
response with a Warning header with warn-code 380 "SIPS Not
Allowed", a UAC MUST NOT re-attempt the request by automatically
replacing the SIPS scheme with a SIP scheme as described in <xref
target="RFC3261"></xref>/8.1.3.5 as it would be a security
vulnerability. If the UAC does re-attempt the call with a SIP URI,
the UAC SHOULD get a confirmation from the user to authorize
re-initiating the session with a SIP Request-URI instead of a SIPS
Request-URI.</t>
<t>When the route set is not empty (e.g., when a service route <xref
target="RFC3608"></xref> is returned by the registrar), it is the
responsibility of the UAC to use a Route header field consisting of
all SIPS URIs when using a SIPS Request-URI. Specifically, if the
route set included any SIP URI, the UAC MUST change the SIP URIs to
SIPS URIs simply by changing the scheme from "sip" to "sips" before
sending the request. This allows for configuring or discovering one
service route with all SIP URIs and allowing sending requests to
both SIP and SIPS URIs.</t>
<t>When the UAC is using a SIP Request-URI, if the route set is not
empty and the topmost Route header field entry is a SIPS URI with
the lr parameter, the UAC MUST send the request over TLS (using a
SIP Request-URI). If the route is not empty and the Route header
field entry is a SIPS URI without the lr parameter, the UAC MUST
send the request over TLS using a SIPS Request-URI corresponding to
the topmost entry in the route set.</t>
<t>To emphasise what is already defined in <xref
target="RFC3261"></xref>, UAs MUST NOT use the "transport=tls"
parameter.</t>
<section title="Registration">
<t>The UAC registers Contacts header fields to either a SIPS or a
SIP AOR.</t>
<t>If a UA wishes to be reachable with a SIPS URI, the UA MUST
register with a SIPS Contact header field. Requests addressed to
that UA's AOR using either a SIP or SIPS Request-URI will be
routed to that UA. This includes UAs that support both SIP and
SIPS. This specification does not provide any SIP-based mechanism
for a UA to provision its proxy to only forward requests using a
SIPS Request-URI. A non-SIP mechanism such as a web interface
could be used to provision such a preference. A SIP mechanism for
provisioning such a preference is outside the scope of this
specification.</t>
<t>If a UA does not wish to be reached with a SIPS URI, it MUST
register with a SIP Contact header field.</t>
<t>Because registering with a SIPS Contact header field implies a
binding of both a SIPS Contact and a corresponding SIP Contact to
the AOR, a UA MUST NOT include both the SIPS and the SIP version
of the same Contact header field in a REGISTER request; the UA
MUST only use the SIPS version in this case. Similarly, a UA
SHOULD NOT register both a SIP Contact header field and a SIPS
Contact header field in separate registrations as the SIP Contact
header field would be superfluous. If it does, the second
registration replaces the first one (e.g., a UA could register
first with a SIP Contact header field - meaning it does not
support SIPS- and later register with a SIPS Contact header field
(meaning it now supports SIPS).</t>
<t><xref target="I-D.ietf-sip-outbound"></xref> can be used by a
UA if it wants to ensure that no requests are delivered to it
without using the TLS connection it used when registering.</t>
<t>If all the Contact header fields in a REGISTER request are
SIPS, the UAC MUST use SIPS AORs in the From and To header fields
in the REGISTER request. If at least one of the Contact header
fields is not SIPS (e.g., sip, mailto, tel, http, https), the UAC
MUST use SIP AORs in the From and To header fields in the REGISTER
request.</t>
<t>To emphasise what is already defined in <xref
target="RFC3261"></xref>, UACs MUST NOT use the "transport=tls"
parameter.</t>
</section>
<section title="SIPS in a Dialog">
<t>If the Request-URI in a request that initiates a dialog is a
SIP URI, then the UAC needs to be careful about what to use in the
Contact header field (in case Record-Route is not used for this
hop). If the Contact header field was a SIPS URI, it would mean
that the UAS would only accept mid-dialog requests that are sent
over secure transport on each hop. Since the Request-URI in this
case is a SIP URI, it is quite possible that the UA sending a
request to that URI might not be able to send requests to SIPS
URIs. If the top Route header field does not contain a SIPS URI,
the UAC MUST use a SIP URI in the Contact header field, even if
the request is sent over a secure transport (e.g., the first hop
could be re-using a TLS connection to the proxy as would be the
case with <xref target="I-D.ietf-sip-outbound"></xref>).</t>
<t>When a target refresh occurs within a dialog (e.g., re-INVITE
request, UPDATE request), the UAC MUST include a Contact header
field with a SIPS URI if the original request used a SIPS
Request-URI.</t>
</section>
<section title="Derived Dialogs and Transactions">
<t>Sessions, dialogs and transactions can be "derived" from
existing ones. A good example of a derived dialog is one that was
established as a result of using the REFER method <xref
target="RFC3515"></xref>.</t>
<t>As a general principle, derived dialogs and transactions cannot
result in an effective downgrading of SIPS to SIP, without the
explicit authorization of the entities involved.</t>
<t>For example, when a REFER request is used to perform a call
transfer, it results in an existing dialog being terminated and
another one being created based on the Refer-To URI. If that
initial dialog was established using SIPS, then the UAC MUST NOT
establish a new one using SIP, unless there is an explicit
authorization given by the recipient of the REFER request. This
could be a warning provided to the user. Having such a warning
could be useful for example for a secure directory service
application, resulting in being routed to a UA that does not
support SIPS.</t>
<t>A REFER request can also be used for referring to resources
that do not result in dialogs being created. In fact, a REFER
request can be used to point to resources that are of a different
type than the original one (i.e., not SIP or SIPS). Please see
<xref target="RFC3515"></xref>/5.2 for security considerations
related to this.</t>
<t>Other examples of derived dialogs and transactions include the
use of Third-Party Call Control <xref target="RFC3725"></xref>,
the Replaces header field <xref target="RFC3891"></xref>, and the
Join header field <xref target="RFC3911"></xref>. Again, the
general principle is that these mechanism SHOULD NOT result in an
effective downgrading of SIPS to SIP, without the proper
authorization.</t>
</section>
<section title="GRUU">
<t>When a GRUU <xref target="I-D.ietf-sip-gruu"></xref> is
assigned to an instance ID/AOR pair, both SIP and SIPS GRUUs will
be assigned. When a GRUU is obtained through registration, if the
Contact header field in the REGISTER request contains a SIP URI,
the SIP version of the GRUU is returned. If the Contact header
field in the REGISTER request contains a SIPS URI, the SIPS
version of the GRUU is returned.</t>
<t>If the wrong scheme is received in the GRUU (which would be an
error in the registrar), the UAC SHOULD treat it as if the proper
scheme was used (i.e., it SHOULD replace the scheme with the
proper scheme before using the GRUU).</t>
</section>
</section>
<section title="UAS Behavior">
<t>When presented with a SIPS URI, a UAS MUST NOT change it to a SIP
URI.</t>
<t>As mandated by <xref target="RFC3261"></xref>/12.1.1, "If the
request that initiated the dialog contained a SIPS URI in the
Request-URI or in the top Record-Route header field value, if there
was any, or the Contact header field if there was no Record-Route
header field, the Contact header field in the response MUST be a
SIPS URI".</t>
<t>If a UAS does not wish to be reached with a SIPS URI but only
with a SIP URI, the UAS MUST respond with a 480 (Temporarily
Unavailable) response. The UAS SHOULD include a Warning header with
warn-code 380 "SIPS Not Allowed". <xref
target="RFC3261"></xref>/8.2.2.1 states that UASs that do not
support the SIPS URI scheme at all "SHOULD reject the request with a
416 (Unsupported URI scheme) response".</t>
<t>If a UAS does not wish to be contacted with a SIP URI but instead
by a SIPS URI, it MUST reject a request to a SIP Request-URI with a
480 (Temporarily Unavailable) response. The UAS SHOULD include a
Warning header with warn-code 381 "SIPS Required".</t>
<t>It is a matter of local policy for a UAS to accept incoming
requests addressed to a URI scheme that does not correspond to what
it used for registration. For example, a UA with a policy of "always
SIPS" would address the Registrar using a SIPS Request-URI over TLS,
would register with a SIPS Contact header field, and the UAS would
reject requests using the SIP scheme with a 480 (Temporarily
Unavailable) response with a Warning header with warn-code 381 "SIPS
Required". A UA with a policy of "best-effort SIPS" would address
the Registrar using a SIPS Request-URI over TLS, would register with
a SIPS Contact header field, and the UAS would accept requests
addressed to either SIP or SIPS Request-URIs. A UA with a policy of
"No SIPS" would address the Registrar using a SIP Request-URI, could
use TLS or not, would register with a SIP AOR and a SIP Contact
header field, and the UAS would accept requests addressed to a SIP
Request-URI.</t>
<t>If a UAS needs to reject a request because the URIs are used
inconsistenty (e.g,, the Request-URI is a SIPS URI, but the Contact
header field is a SIP URI), the UAS MUST reject the request with a
400 (Bad Request) response.</t>
<t>When a target refresh occurs within a dialog (e.g., re-INVITE
request, UPDATE request), the UAS MUST include a Contact header
field with a SIPS URI if the original request used a SIPS
Request-URI.</t>
<t>To emphasise what is already defined in <xref
target="RFC3261"></xref>, UASa MUST NOT use the "transport=tls"
parameter.</t>
</section>
</section>
<section title="Registrar Behavior">
<t>The UAC registers Contacts header fields to either a SIPS or a SIP
AOR. From a routing perspective, it does not matter which one is used
for registration as they identify the same resource. The registrar
MUST consider AORs that are identical except for one having the SIP
scheme and the other having the SIPS scheme to be equivalent.</t>
<t>A registrar MUST only accept a binding to a SIPS Contact header
field if all the appropriate URIs are of the SIPS scheme, otherwise
there could be an inadvertent binding of a secure resource (SIPS) to
an unsecured one (SIP). This includes the Request-URI, the Contacts
and all the Path header fields, but does not include the From and To
header fields. If the URIs are not of the proper SIPS scheme, the
registrar MUST reject the REGISTER with a 400 (Bad Request).</t>
<t>A registrar can return a service route <xref
target="RFC3608"></xref> and impose some constraints on whether TLS
will be mandatory or not on specific hops. For example, if the topmost
entry in the Path header field returned by the registrar is a SIPS
URI, the registrar is telling the UAC that TLS is to be be used for
the first hop, even if the Request-URI is SIP.</t>
<t>If a UA registered with a SIPS Contact header field, the registrar
returning a service route <xref target="RFC3608"></xref> MUST return a
service route consisting of SIP URIs if the intent of the registrar is
to allow both SIP and SIPS to be used in requests sent by that client.
If a UA registers with a SIPS Contact header field, the registrar
returning a service route MUST return a service route consisting of
SIPS URIs if the intent of the registrar is to allow only SIPS URIs to
be used in requests sent by that UA.</t>
<section title="GRUU">
<t>When a GRUU <xref target="I-D.ietf-sip-gruu"></xref> is assigned
to an instance ID/AOR pair through registration, the registrar MUST
assign both a SIP GRUU and a SIPS GRUU. If the Contact header field
in the REGISTER request contains a SIP URI, the registrar MUST
return the SIP version of the GRUU. If the Contact header field in
the REGISTER request contains a SIPS URI, the registrar MUST return
the SIPS version of the GRUU.</t>
</section>
</section>
<section anchor="proxy-behavior" title="Proxy Behavior">
<t>Proxies MUST NOT use the last hop exception of <xref
target="RFC3261"></xref> when forwarding or retargeting a request to
the last hop. Specifically, when a proxy receives a request with a
SIPS Request-URI, the proxy MUST only forward or retarget the request
to a SIPS Request-URI. If the target UAS had registered previously
using a SIP Contact header field instead of a SIPS Contact header
field, the proxy MUST NOT forward the request to the URI indicated in
the Contact header field. If the proxy needs to reject the request for
that reason, the proxy MUST reject it with a 480 (Temporarily
Unavailable) response. In this case, the proxy SHOULD include a
Warning header with warn-code 380 "SIPS Not Allowed".</t>
<t>Proxies SHOULD transport requests using a SIP URI over TLS when it
is possible to set up a TLS connection, or re-use an existing one.
<xref target="I-D.ietf-sip-outbound"></xref> for example, allows for
re-using an existing TLS connection. Some proxies could have policies
that prohibit sending any request over anything but TLS.</t>
<t>When a proxy receives a request with a SIP Request-URI, the proxy
MUST NOT forward the request to a SIPS Request-URI. If the target UAS
had registered previously using a SIPS Contact header field, and the
proxy decides to forward the request, the proxy MUST replace that SIPS
scheme with a SIP scheme while leaving the rest of the URI as is, and
use the resulting URI as the Request-URI of the forwarded request. The
proxy MUST use TLS to forward the request to the UAS. Some proxies
could have a policy of not forwarding at all requests using a non-SIPS
Request-URI if the UAS had registered using a SIPS Contact header
fields. If the proxy elects to reject the request because it has such
a policy or because it is not capable of establishing a TLS
connection, the proxy MAY reject it with a 480 (Temporarily
Unavailable) response with a Warning header with warn-code 381 "SIPS
Required".</t>
<t>If a proxy needs to reject a request because the URIs are used
inconsistenty (e.g,, the Request-URI is a SIPS URI, but the Contact
header field is a SIP URI), the proxy SHOULD use response code 400
(Bad Request).</t>
<t>It is RECOMMENDED that the proxy use the outbound proxy procedures
defined in <xref target="I-D.ietf-sip-outbound"></xref> for supporting
UACs that cannot provide a certificate for establishing a TLS
connection (i.e., when server-side authentication is used).</t>
<t>When a proxy sends a request using a SIPS Request-URI and receives
a 3XX response with a SIP Contact header field, or, a 416 response, or
a 480 (Temporarily Unavailable) response with a Warning header with
warn-code 380 "SIPS Not Allowed" response, the proxy MUST NOT recurse
on the response. In this case, the proxy SHOULD forward the best
response instead of recursing, in order to allow for the UAC to take
the appropriate action.</t>
<t>When a proxy sends a request using a SIP Request-URI and receives a
3XX response with a SIPS Contact header field, or, a 480 (Temporarily
Unavailable) response with a Warning header with warn-code 381 "SIPS
Required", the proxy MUST NOT recurse on the response. In this case,
the proxy SHOULD forward the best response instead of recursing, in
order to allow for the UAC to take the appropriate action.</t>
<t>To emphasise what is already defined in <xref
target="RFC3261"></xref>, proxies MUST NOT use the "transport=tls"
parameter.</t>
</section>
<section title="Redirect Server Behavior">
<t>Using a redirect server with TLS instead of using a proxy has some
limitations that have to be taken into account. Since there no
pre-established connection between the proxy and the UAS (such as with
<xref target="I-D.ietf-sip-outbound"></xref>), it is only appropriate
for scenarios where inbound connections are allowed. For example, it
could be used in a server to server environment (redirect server or
proxy server) where TLS mutual authentication is used, and where there
are no NAT traversal issues. A redirect server would not be able to
redirect to an entity that does not have a certificate. A redirect
server might not be usable if there is a NAT between the server and
the UAS.</t>
<t>When a redirect server receives a request with a SIP Request-URI,
the redirect server MAY redirect with a 3XX response to either a SIP
or a SIPS Contact header field. If the target UAS had registered
previously using a SIPS Contact header field, the redirect server
SHOULD return a SIPS Contact header field if it is in an environment
where TLS is usable (as described in the previous paragraph). If the
target UAS had registered previously using a SIP Contact header field,
the redirect server MUST return a SIP Contact header field in a 3XX
response if it redirects the request.</t>
<t>When a redirect server receives a request with a SIPS Request-URI,
the redirect server MAY redirect with a 3XX response to a SIP or a
SIPS Contact header field. If the target UAS had registered previously
using a SIPS Contact header field, the redirect server SHOULD return a
SIPS Contact header field if it is in an environment where TLS is
usable. If the target UAS had registered previously using a SIP
Contact header field, the redirect server MUST return a SIP Contact
header field in a 3XX response if it chooses to redirect; otherwise
the UAS MAY reject the request with a 480 (Temporarily Unavailable)
response with a Warning header with warn-code 380 "SIPS Not Allowed".
If a redirect server redirects to a UAS that it has no knowledge of
(e.g., a AOR in a different domain), the Contact header field could be
of any scheme.</t>
<t>If a redirect server needs to reject a request because the URIs are
used inconsistenty (e.g,, the Request-URI is a SIPS URI, but the
Contact header field is a SIP URI), the redirect server SHOULD use
response code 400 (Bad Request).</t>
<t>To emphasise what is already defined in <xref
target="RFC3261"></xref>, redirect servers MUST NOT use the
"transport=tls" parameter.</t>
</section>
</section>
<section anchor="flows" title="Call Flows">
<t>The following diagram illustrates the topology used for the examples
in this section:</t>
<figure align="center" title="Topology">
<preamble></preamble>
<artwork><![CDATA[
example.com . example.net
.
|-------------| . |------------|
| Registrar/ |__________| Proxy A |
| Auth. Proxy | . | (proxya) |
| (pb) | . |------------|
|-------------| . |
| . |
| . |
|-----------| . |
| Edge | . |
| Proxy B | . |
| (eb) | . |
|-----------| . |
/ | . |
/ | . |
/ | . |
______ | . |
| | _____ . _____
|______| O / \ O . O / \ O
/_______/ /___\ . /___\
.
bob@bobpc bob@bobphone . alice
]]></artwork>
<postamble></postamble>
</figure>
<t></t>
<t>In the following examples, Bob has two clients, one is a SIP PC
client running on his computer, and the other one is a SIP Phone. The PC
client does not support SIPS and consequently only registers with a SIP
Contact header field. The SIP phone however does support SIPS and TLS,
and consequently registers with a SIPS Contact header field. Both of
Bob's devices are going through Edge Proxy B, and consequently, they
include a Route header field indicating eb.example.com. Edge Proxy B
removes the Route header field corresponding to itself, and adds itself
in a Path header field. The registration process call flow is
illustrated in <xref target="registration-ex"></xref>.</t>
<t>After registration, there are two Contact bindings associated with
Bob's AOR of bob@example.com: sips:bob@bobphone.example.com and
sip:bob@bobpc.example.com.</t>
<t>Alice then calls Bob through her own Proxy A. Proxy A locates Bob's
domain example.com. In this example, that domain is owned by Bob's
Registrar/Authoritative Proxy B. Proxy A removes the Route header field
corresponding to itself, and inserts itself in the Record-Route and
forwards the request to Registrar/Authoritative Proxy B.</t>
<t>The following subsections illustrates registration and three
examples. In the first example (<xref target="sips-bob"></xref>), Alice
calls Bob using Bob's SIPS URI. In the second example (<xref
target="sip-bob"></xref>), Alice calls Bob's SIP AOR using TCP
transport. In the third example (<xref target="sip-bob-tls"></xref>),
Alice calls Bob's SIP AOR using TLS transport.</t>
<section anchor="registration-ex" title="Bob Registers his Contacts">
<t>This flow illustrates the registration process by which Bob's
device registers. His PC client (Bob@bobpc) registers with a SIP
scheme and his SIP Phone (Bob@phone) registers with a SIPS scheme.</t>
<figure align="center" title="Bob Registers His Contacts">
<preamble></preamble>
<artwork><![CDATA[ (eb) (pb)
Edge Registrar/
Bob@bobpc Proxy B Auth. Proxy B
| | |
| REGISTER F1 | |
|------------------>| REGISTER F2 |
| |-------------->|
| | 200 F3 |
| 200 F4 |<--------------|
|<------------------| |
| | |
| Bob@bobphone | |
| | | |
| |REGISTER F5 | |
| |----------->| REGISTER F6 |
| | |-------------->|
| | | 200 F7 |
| | 200 F8 |<--------------|
| |<-----------| |
| | | |
]]></artwork>
<postamble></postamble>
</figure>
<t>Message details</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F1 REGISTER Bob's PC Client -> Edge Proxy B
REGISTER sip:pb.example.com SIP/2.0
Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Supported: path, outbound
Route: <sip:eb.example.com;lr;keep>
Contact: <sip:bob@bobpc.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F2 REGISTER Edge Proxy B -> Registrar/Authoritative Proxy B
REGISTER sip:pb.example.com SIP/2.0
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Supported: path
Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;keep;ob>
Contact: <sip:bob@bobpc.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F3 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds
To: Bob <sip:bob@example.com>;tag=2493K59K9
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Required: outbound
Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;keep;ob>
Contact: <sip:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
;expires=3600
Date: Mon, 12 Jun 2006 16:43:12 GMT
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F4 200 (REGISTER) Edge Proxy B -> Bob's PC Client
SIP/2.0 200 OK
Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds
To: Bob <sip:bob@example.com>;tag=2493K59K9
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Required: outbound
Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;keep;ob>
Contact: <sip:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
;expires=3600
Date: Thu, 09 Aug 2007 16:43:12 GMT
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F5 REGISTER Bob's Phone -> Edge Proxy B
REGISTER sips:pb.example.com SIP/2.0
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
Max-Forwards: 70
To: Bob <sips:bob@example.com>
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Supported: path
Route: <sips:eb.example.com;lr;keep>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F6 REGISTER Edge Proxy B -> Registrar/Authoritative Proxy B
REGISTER sips:pb.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
Max-Forwards: 69
To: Bob <sips:bob@example.com>
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Supported: path
Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F7 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
To: Bob <sips:bob@example.com>;tag=5150
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Required: outbound
Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
;expires=3600
Date: Thu, 09 Aug 2007 16:43:50 GMT
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F8 200 (REGISTER) Edge Proxy B -> Bob's Phone
SIP/2.0 200 OK
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
To: Bob <sips:bob@example.com>;tag=5150
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Required: outbound
Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
;expires=3600
Date: Thu, 09 Aug 2007 16:43:50 GMT
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
</section>
<section anchor="sips-bob" title="Alice Calls Bob's SIPS AOR">
<t>Bob's registration has already occurred as per <xref
target="registration-ex"></xref>.</t>
<t>In this first example, Alice calls Bob's SIPS AOR
(sips:bob@example.com). Registrar/Authoritative Proxy B consults the
binding in the registration database, and finds the two Contact header
field bindings. Alice had addressed Bob with a SIPS Request-URI
(sips:bob@example.com), so Registrar/Authoritative Proxy B determines
that the calls needs to be routed only to bobphone (which registered
using a SIPS Contact header field), and therefore the request is only
sent to sips:bob@bobphone.example.com, through Edge Proxy B. Both
Registrar/Authoritative Proxy B and Edge Proxy B inserts themselves in
the Record-Route. Bob answers at sips:bob@bobphone.example.com.</t>
<figure align="center" title="Alice Calls Bob's SIPS AOR">
<preamble></preamble>
<artwork><![CDATA[ (eb) (pb)
Edge Registrar/
Bob@bobpc Proxy B Auth. Proxy B Proxy A Alice
| | | | |
| | | | INVITE F9 |
| Bob@bobphone | | INVITE F11 |<-----------|
| | | INVITE F13 |<-----------| 100 F10 |
| | INVITE F15 |<-----------| 100 F12 |----------->|
| |<-----------| 100 F14 |----------->| |
| | 180 F16 |----------->| | |
| |----------->| 180 F17 | | |
| | 200 F20 |----------->| 180 F18 | |
| |----------->| 200 F21 |----------->| 180 F19 |
| | |----------->| 200 F22 |----------->|
| | | |----------->| 200 F23 |
| | | | |----------->|
| | | | | ACK F24 |
| | | | ACK F25 |<-----------|
| | | ACK F26 |<-----------| |
| | ACK F27 |<-----------| | |
| |<-----------| | | |
| | | | | |
]]></artwork>
<postamble></postamble>
</figure>
<t>Message details</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F9 INVITE Alice -> Proxy A
INVITE sips:bob@example.com SIP/2.0
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F10 100 (INVITE) Proxy A -> Alice
SIP/2.0 100 Trying
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F11 INVITE Proxy A -> Registrar/Authoritative Proxy B
INVITE sips:bob@example.com SIP/2.0
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 100 Trying
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
INVITE sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@edge.example.com;lr;keep;ob>
Record-Route: <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 100 Trying
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F15 INVITE Edge Proxy B -> Bob's phone
INVITE sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 67
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F16 180 (INVITE) Bob's Phone -> Edge Proxy B
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F18 180 Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F19 180 (INVITE) Proxy A -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F20 200 (INVITE) Bob's Phone -> Edge Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F22 200 Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 200 OK
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F23 200 (INVITE) Proxy A -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F24 ACK Alice -> Proxy A
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 70
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sips:proxya.example.net;lr>, <sips:pb.example.com;lr>,
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;keep;ob>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F25 ACK Proxy A -> Registrar/Authoritative Proxy B
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 69
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sips:pb.example.com;lr>,
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;keep;ob>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F26 ACK Registrar/Authoritative Proxy B -> Edge Proxy B
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bK8msdu2
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 69
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sips:pb.example.com;lr>,
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;keep;ob>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F27 ACK Proxy B -> Bob's Phone
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKkmfdgk
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bK8msdu2
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 68
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
</section>
<section anchor="sip-bob" title="Alice Calls Bob's SIP AOR using TCP">
<t>Bob's registration has already occurred as per <xref
target="registration-ex"></xref>.</t>
<t>In the second example, Alice calls Bob's SIP AOR instead
(sip:bob@example.com), and she uses TCP as a transport.
Registrar/Authoritative Proxy B consults the binding in the
registration database, and finds the two Contact header field
bindings. Alice had addressed Bob with a SIP Request-URI
(sip:bob@example.com), so Registrar/Authoritative Proxy B determines
that the calls needs to be routed both to bobpc (which registered with
a SIP Contact header field) and bobphone (which registered with a SIPS
Contact header field), and therefore the request is forked to
sip:bob@bobpc.example.com and sip:bob@bobphone.example.com, through
Edge Proxy B. Note that Registar/Authoritative Proxy B preserved the
SIP scheme of the Request-URI instead of replacing it with the SIPS
scheme of the Contact header field that was used for registration.
Both Registrar/Authoritative Proxy B and Edge Proxy B inserts
themselves in the Record-Route. Bob's phone's policy is to accept
calls to SIP and SIPS (i.e., "best effort") so both his PC Client and
his SIP Phone ring simultaneously. Bob answers on his SIP phone, and
the forked call leg to the PC client is canceled.</t>
<figure align="center" title="Alice Calls Bob's SIP AOR">
<preamble></preamble>
<artwork><![CDATA[ (eb) (pb)
Edge Registrar/
Bob@bobpc Proxy B Auth. Proxy B Proxy A Alice
| | | | |
| | | | INVITE F9 |
| | | INVITE F11 |<-----------|
| | INVITE F13'|<-----------| 100 F10 |
| INVITE F15' |<-----------| 100 F12 |----------->|
|<------------------| 100 F14' |----------->| |
| 180 F16' |----------->| | |
|------------------>| 180 F17' | | |
| |----------->| 180 F18' | |
| Bob@bobphone | |----------->| 180 F19' |
| | | INVITE F13 | |----------->|
| | INVITE F15 |<-----------| | |
| |<-----------| 100 F14 | | |
| | 180 F16 |----------->| | |
| |----------->| 180 F17 | | |
| | 200 F20 |----------->| 180 F18 | |
| |----------->| 200 F21 |----------->| 180 F19 |
| | |----------->| 200 F22 |----------->|
| | | |----------->| 200 F23 |
| | | | |----------->|
| | | | | ACK F24 |
| | | | ACK F25 |<-----------|
| | | ACK F26 |<-----------| |
| | ACK F27 |<-----------| | |
| |<-----------| | | |
| | CANCEL F26'| | |
| CANCEL F27' |<-----------| | |
|<------------------| | | |
| 200 F28' | | | |
|------------------>| 200 F29' | | |
| 487 F30' |----------->| | |
|------------------>| 487 F31' | | |
| |----------->| | |
]]></artwork>
<postamble></postamble>
</figure>
<t>Message details</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F9 INVITE Alice -> Proxy A
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F10 100 (INVITE) Proxy A -> Alice
SIP/2.0 100 Trying
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F11 INVITE Proxy A -> Registrar/Authoritative Proxy B
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 100 Trying
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F13' INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
INVITE sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;keep;ob>
Record-Route: <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F14' 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 100 Trying
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F15' INVITE Edge Proxy B -> Bob's PC Client
INVITE sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 67
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;keep;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F16' 180 (INVITE) Bob's PC Client -> Edge Proxy B
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;keep;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F17' 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;keep;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F18' 180 (INVITE) Registar/Authoritative Proxy B -> Proxy A
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;keep;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F19' 180 (INVITE) Proxy A -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;keep;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>
Record-Route: <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 100 Trying
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F15 INVITE Edge Proxy B -> Bob's Phone
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F16 180 (INVITE) Bob's Phone -> Edge Proxy B
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F18 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F19 180 (INVITE) Proxy A -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F20 200 (INVITE) Bob's Phone -> Edge Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F22 200 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F23 200 (INVITE) Proxy A -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F24 ACK Alice -> Proxy A
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:proxya.example.net;lr>, <sip:pb.example.com;lr>,
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@edge.example.com;lr;keep;ob>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F25 ACK Proxy A -> Registrar/Authoritative Proxy B
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:pb.example.com;lr>,
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F26 ACK Registrar/Authoritative Proxy B -> Edge Proxy B
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F27 ACK Proxy B -> Bob's Phone
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F26' CANCEL Registrar/Authoritative Proxy B -> Edge Proxy B
CANCEL sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;keep;ob>
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F27' CANCEL Edge Proxy B -> Bob's PC Client
CANCEL sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F28' 200 (CANCEL) Bob's PC Client -> Edge Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F29' 200 (CANCEL) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F30' 487 (INVITE) Bob's PC Client -> Edge Proxy B
SIP/2.0 487 Request Terminated
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
<figure>
<preamble></preamble>
<artwork><![CDATA[
F31' 487 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 487 Request Terminated
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0]]></artwork>
<postamble></postamble>
</figure>
</section>
<section anchor="sip-bob-tls"
title="Alice Calls Bob's SIP AOR using TLS">
<t>Bob's registration has already occurred as per <xref
target="registration-ex"></xref>.</t>
<t>The third example is identical to the second one, except that Alice
uses TLS as the transport for her connection to her proxy. Such an
arrangement would be common if Alice's UA supported TLS and wanted to
use a single connection to the proxy (as would be the case when using
<xref target="I-D.ietf-sip-outbound"></xref>). In the example below,
Proxy A is also using TLS as a transport to communicate with Outbound
proxy B, but it is not necessarily the case.</t>
<t>When using a SIP URI in the Request-URI, but TLS as a transport for
sending the request, the Via field indicates TLS. The Route header
field (if present) typically would use a SIP URI (but it could also be
a SIPS URI). The Contact header fields, To and From however would also
normally indicate a SIP URI.</t>
<t>The call flow would be exactly as per the second example (<xref
target="sip-bob"></xref>). The only difference would be that all the
Via header fields would use TLS Via parameters. The URIs would remain
SIP URIs and not SIPS URIs.</t>
</section>
</section>
<section title="Further Considerations">
<t>SIP <xref target="RFC3261"></xref> itself introduces some
complications with using SIPS, for example when Record-Route is not
used. When a SIPS URI is used in a Contact header field in a
dialog-initiating request and Record-Route is not used, that SIPS URI
might not be usable by the other end. If the other end does not support
SIPS and/or TLS, it will not be able to use it. The "last-hop exception"
is an example of when this can occur. In this case, using Record-Route
so that the requests are sent through proxies can help in making it
work. Another example is that even in a case where the Contact header
field is a SIPS URI, no Record-Route is used, and the far end supports
SIPS and TLS, it might still not be possible for the far end to
establish a TLS connection with the SIP originating end if the
certificate cannot be validated by the far end. This could typically be
the case if the originating end was using server-side authentication as
described below, or if the originating end is not using a certificate
that can be validated.</t>
<t>TLS itself has a significant impact on how SIPS can be used.
"Server-side authentication" (where the server side provides its
certificate but the client side does not) is typically used between a
SIP end-user device acting as the TLS client side (e.g., a phone or a
personal computer), and its SIP server (proxy or registrar) acting as
the TLS server side. TLS mutual authentication (where both the client
and the server side provide their respective certificates) is typically
used between SIP servers (proxies, registrars), or statically configured
devices such as PSTN gateways or media servers. In the mutual
authentication model, for two entities to be able to establish a TLS
connection, it is required that both sides be able to validate each
other's certificates, either by static configuration or by being able to
recurse to a valid root certificate. With server-side authentication,
only the client side is capable of validating the server side's
certificate, as the client side does not provide a certificate. The
consequences of all this are that whenever a SIPS URI is used to
establish a TLS connection, it is expected to be possible for the entity
establishing the connection (the client) to validate the certificate
from the server side. For server-side authentication, <xref
target="I-D.ietf-sip-outbound"></xref> is the recommended approach. For
mutual authentication, one needs to ensure that the architecture of the
network is such that connections are made between entities that have
access to each other's certificates. Record-Route <xref
target="RFC3261"></xref> and Path <xref target="RFC3327"></xref> are
very useful in ensuring that previously established TLS connections can
be re-used. Other mechanisms might also be used in certain
circumstances: for example, using root certificates that are widely
recognized allows for more easily created TLS connections.</t>
<t>The "last hop exception" introduces significant potential
vulnerabilities in SIP and it has therefore been deprecated by this
specification.</t>
</section>
<section title="Security Considerations">
<t>Most of this document can be considered to be security considerations
since it applies to the usage of the SIPS URI.</t>
</section>
<section title="IANA Considerations">
<t>This specification registers two new warning codes, namely 380 "No
SIPS Contacts Registered" and 381 "SIPS Required". The warning codes are
defined by the following information, which has been included to the
Warn-codes sub-registry under
http://www.iana.org/assignments/sip-parameters.</t>
<t><list hangIndent="5" style="hanging">
<t hangText="380">SIPS Not Allowed: The UAS or proxy cannot process
the request because the SIPS scheme is not allowed (e.g., because
there are currently no registered SIPS Contacts).</t>
<t></t>
<t hangText="381">SIPS Required: The UAS or proxy cannot process the
request because the SIPS scheme is required.</t>
</list></t>
<t>Reference: RFC XXX [Note to IANA Editor, please replace with RFC
number of this document]</t>
</section>
<section title="IAB Considerations ">
<t>There are no IAB considerations.</t>
</section>
<section title="Acknowledgments">
<t>The author would like to thank Jon Peterson, Cullen Jennings,
Jonathan Rosenberg, John Elwell, Paul Kyzivat, Eric Rescorla, Robert
Sparks, Rifaat Shekh-Yusef, Peter Reissner, Tina Tsou, Keith Drage,
Brian Stucker, Patrick Ma, Lavis Zhou, Joel Halpern, Hisham Karthabil,
Dean Willis, Éric Tremblay, Hans Persson and Ben Campbell for
their careful review and input. Many thanks to Rohan Mahy for helping me
with the subtleties of <xref target="I-D.ietf-sip-outbound"></xref>.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3261;
&rfc4346;
&I-D.ietf-sip-outbound;
</references>
<references title="Informational References">
&rfc2543;
&rfc3327;
&rfc3515;
&rfc3608;
&rfc3725;
&rfc3891;
&rfc3893;
&rfc3911;
&rfc4168;
&rfc4244;
&rfc4474;
&I-D.ietf-sip-gruu;
&I-D.gurbani-sip-sipsec;
</references>
<section title="Future Steps in Specification">
<t>This section is a placeholder for a discussion of possible future
steps in specification, and the pros and cons of making such changes.
Protocol and normative changes to any specifications (such as RFC 3261)
resulting from this discussion would be specified in further
documents.</t>
<section title="Indication of Validity of SIPS">
<t>Since the presence of a SIPS URI in a Request-URI in an incoming
request currently does not guarantee that SIPS and TLS was indeed used
on every hop along the path, it has been suggested that it would be
useful to define a mechanism for a verifiable assertion that TLS and
SIPS were used on every hop.</t>
</section>
<section title="True End-to-End Encryption of SIP">
<t>Another suggestion has been to define a mechanism to encrypt SIP
end-to-end. This would require either an peer-to-peer SIP model, or
alternatively a mechanism that allows the encrypted SIP signalling to
be tunnelled through proxies. <xref
target="I-D.gurbani-sip-sipsec"></xref> is an example of such a
mechanism.</t>
</section>
<section anchor="future-transport"
title="Use of the transport parameter for TLS on a single hop">
<t>A way to describe in a URI that TLS is intended to be used on a
specific hop (similar to what transport=tls used to mean) has been
suggested as a possible area for future steps in specification. See
discussion in <xref target="transportparam"></xref>.</t>
</section>
</section>
<section anchor="bugs" title="Bug Fixes for RFC 3261">
<t>The last sentence of the fifth paragraph of 8.1.3.5 is replaced
by:</t>
<t><list>
<t>The client SHOULD retry the request, this time, using a SIP URI
unless the original Request-URI used a SIPS scheme, in which case
the client MUST NOT retry the request automatically.</t>
</list></t>
<t>The fifth paragraph of section 10.2.1 is replaced by:</t>
<t><list>
<t>If the address-of-record in the To header field of a REGISTER
request is a SIPS URI, then the UAC MUST also include only SIPS URIs
in any Contact header field value in the requests.</t>
</list></t>
<t>In section 16.7 on p. 112 describing Record-Route, the second
paragraph is deleted.</t>
<t>The last paragraph of section 19.1 is reworded as follows:</t>
<t><list>
<t>A SIPS URI specifies that the resource be contacted securely.
This means, in particular, that TLS is to be used on each hop
between the UAC and the resource identified by the target SIPS URI.
Any resources described by a SIP URI (...)</t>
</list></t>
<t>The second paragraph of section 26.2.2 is reworded as follows:</t>
<t><list>
<t>(...) When used as the Request-URI of a request, the SIPS scheme
signifies that each hop over which the request is forwarded, until
the request reaches the resource identified by the Request-URI, is
secured with TLS. When used by the originator of a request (as would
be the case if they employed a SIPS URI as the address-of-record of
the target), SIPS dictates that the entire request path to the
target domain be so secured.</t>
</list></t>
<t>The first paragraph of section 26.4.4 is replaced by the
following:</t>
<t><list>
<t>Actually using TLS on every segment of a request path entails
that the terminating UAS is reachable over TLS (by registering with
a SIPS URI as a contact address). The SIPS scheme implies transitive
trust. Obviously, there is nothing that prevents proxies from
cheating. Thus SIPS cannot guarantee that TLS usage will be truly
respected end-to-end on each segment of a request path. Note that
since many UAs will not accept incoming TLS connections, even those
UAs that do support TLS will be required to maintain persistent TLS
connections as described in the TLS limitations section above in
order to receive requests over TLS as a UAS.</t>
</list></t>
<t>The fourth paragraph of section 26.4.4 is deleted.</t>
<t>The last sentence of the fifth paragraph of section 26.4.5 is
reworded as follows:</t>
<t><list>
<t>(...) S/MIME or, preferably, [RFC4474] may also be used (...)</t>
</list></t>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-22 21:49:56 |