SIP F. Audet
Internet-Draft Nortel Networks
Intended status: Standards Track May 23, 2007
Expires: November 24, 2007
The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
draft-ietf-sip-sips-04
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 24, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
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.
Audet Expires November 24, 2007 [Page 1]
Internet-Draft SIPS May 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Meaning of SIPS . . . . . . . . . . . . . . . . . . . . . 3
3.1.1. Scope of SIPS . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Using TLS with SIP instead of SIPS . . . . . . . . . . 6
3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Detection of Hop-by-Hop Security . . . . . . . . . . . 9
3.2.2. Double Record Routing . . . . . . . . . . . . . . . . 10
3.3. Usage of the transport=tls URI Parameter and the TLS
Via Parameter . . . . . . . . . . . . . . . . . . . . . . 11
4. Normative Requirements . . . . . . . . . . . . . . . . . . . . 12
4.1. General User Agent Behavior . . . . . . . . . . . . . . . 12
4.1.1. Service Routes . . . . . . . . . . . . . . . . . . . . 14
4.1.2. Registration . . . . . . . . . . . . . . . . . . . . . 14
4.1.3. SIPS in a Dialog . . . . . . . . . . . . . . . . . . . 16
4.1.4. Derived Dialogs and Transactions . . . . . . . . . . . 17
4.1.5. GRUU . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Redirect Server Behavior . . . . . . . . . . . . . . . . . 20
5. Call Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Bob Registers his Contacts . . . . . . . . . . . . . . . . 22
5.2. Alice Calls Bob's SIPS AOR . . . . . . . . . . . . . . . . 26
5.3. Alice Calls Bob's SIP AOR using TCP . . . . . . . . . . . 31
5.4. Alice Calls Bob's SIP AOR using TLS . . . . . . . . . . . 41
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7. Security Considerations . . . . . . . . . . . . . . . . . . . 49
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 49
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
11.1. Normative References . . . . . . . . . . . . . . . . . . . 50
11.2. Informational References . . . . . . . . . . . . . . . . . 50
Appendix A. Future Steps in Specification . . . . . . . . . . . . 51
A.1. Indication of Validity of SIPS . . . . . . . . . . . . . . 51
A.2. True End-to-End Encryption of SIP . . . . . . . . . . . . 51
Appendix B. Bug Fixes for RFC 3261 . . . . . . . . . . . . . . . 51
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53
Intellectual Property and Copyright Statements . . . . . . . . . . 54
Audet Expires November 24, 2007 [Page 2]
Internet-Draft SIPS May 2007
1. Introduction
The meaning and usage of the SIPS URI scheme and of TLS [RFC4346] is
underspecified in SIP [RFC3261] and has been a source of confusion
for implementers.
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.
2. Terminology
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 [RFC2119].
3. Overview
3.1. Meaning of SIPS
[RFC3261]/19.1 describes a SIPS URI as follows:
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.
Section 26.2.2 re-iterates it, with regards to Request-URIs:
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.
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.
Audet Expires November 24, 2007 [Page 3]
Internet-Draft SIPS May 2007
.......................... ...........................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | Proxy |-----TLS---- | Proxy | .
. | A | . . | B | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. TLS . . Policy-based .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | UA a | . . | UA b | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
.......................... ...........................
SIP trapezoid
According to [RFC3261], if a@A is sending a request to sips:b@B, the
following applies:
o TLS must be used between UA a@A and Proxy A
o TLS must be used between Proxy A and Proxy B
o TLS may be used between Proxy B and UA b@B, depending on local
policy.
One may 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 [RFC3261]
was written before [I-D.ietf-sip-outbound]. At that time, it was
recognized that in many practical deployments, Proxy B may 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 [RFC3261]-
compliant UAS b, while it may 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, [I-D.ietf-sip-outbound] has provided a more
Audet Expires November 24, 2007 [Page 4]
Internet-Draft SIPS May 2007
satisfactory solution to this problem. [I-D.ietf-sip-outbound] 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.
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 [RFC3261]/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 must understand SIPS in
the first place, and must 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.
Because of all the problems caused by the last hop exception, this
specification deprecates the last hop exception when forwarding a
request to the last hop (see Section 4.2). This will ensure that TLS
is used on all hops all the way up to the remote target.
The SIPS scheme implies transitive trust. Obviously, there is
nothing that prevents proxies from cheating (see [RFC3261]/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 To header)
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 one must therefore be
careful not to oversell the meaning of a SIPS URI. There is
currently no mechanism to provide an indication of end-to-end
security for SIP. Other mechanisms may provide a more concrete
indication of some level of security. For example, SIP Identity
[RFC4474] provides an authenticated identity mechanism and a domain-
to-domain integrity protection mechanism.
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:
Audet Expires November 24, 2007 [Page 5]
Internet-Draft SIPS May 2007
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 may or may not be delivered over TLS on each hop.
Another common question is why not have a Proxy-Require and Require
option tag that forces 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. This
specification clarifies the significance of using SIPS URIs in these
cases. 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 that allow for including SIPS URIs (e.g., HTML).
3.1.1. Scope of SIPS
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.
3.1.2. Using TLS with SIP instead of SIPS
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 [RFC3261]/26.2.2
Users that distribute a SIPS URI as an address-of-record may elect
to operate devices that refuse requests over insecure transports.
If one wants to use "best-effort TLS" for SIP, one just needs to use
a SIP URI, and send the request over TLS. In fact, implementations
SHOULD try to establish a TLS connection when using a SIP URI.
Using SIP over TLS is very simple. A UA opens a TLS connection and
uses SIP URIs instead of SIPS URIs for all the headers in a SIP
message (From, To, Request-URI, Contact header field, Route, etc.).
Note that when TLS is used, the Via header indicates TLS.
[RFC3261]/26.3.2.1 states:
Audet Expires November 24, 2007 [Page 6]
Internet-Draft SIPS May 2007
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.
[I-D.ietf-sip-outbound] describes how to establish and maintain a TLS
connection in environments where it can only be initiated by the UA.
Similarly, proxies may 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 may insert Record-Route headers using SIP URIs
even if it uses TLS transport. [RFC3261]/26.3.2.2 explains how
interdomain requests can use TLS.
Some user agents, redirect servers and proxies may have local
policies that enforce TLS on all connections, independently of if
SIPS is used or not.
3.2. Routing
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 [RFC3261]/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 can not establish a secure connection to a client or another
proxy. This does not suggest either that proxies should arbitrarily
"upgrade" SIP URIs to SIPS URIs when forwarding a request (see
Section 4.2). Rather, it means that when a resource is addressable
with SIP, it will also be addressable with SIPS.
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
Section 5.3 and in Section 5.4. 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
Audet Expires November 24, 2007 [Page 7]
Internet-Draft SIPS May 2007
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 wouldn't be possible if that UA did not support SIPS).
This specification mandates that when a proxy is forwarding a
request, a resource described by a SIPS Request-URI can not be
"downgraded" to a SIP URI by changing the scheme, or by sending the
associated request over a non-secure link. See Section 4.2.
For example, the sip:bob@example.com and sips:bob@example.com AORs
must refer 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 [RFC3261]/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.
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. The proxy should
attempt to transport the request over TLS if a TLS connection can be
established even if a SIP URI is used. Indeed, some proxies may even
have local policies of always using TLS. Furthermore, if Bob wants
to ensure that every request delivered to him always be transported
over TLS, Bob can use [I-D.ietf-sip-outbound] when registering.
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.
See Section 5 for illustrative call flows.
Audet Expires November 24, 2007 [Page 8]
Internet-Draft SIPS May 2007
Since upgrading from SIP to SIPS is allowed in other circumstances
(e.g., a user "guessing" a SIPS AOR from a SIP AOR on a business
card), it is quite possible that a request will be rejected with
response code 416 (Unsupported URI Scheme), because the UAS only
supports the SIP scheme. When 416 (Unsupported URI Scheme) is
received, the request may be re-attempted with a SIP URI, but the
user should be informed. While guessing a SIPS AOR from a known SIP
AOR and using it to initiate a request is a valid thing to do, doing
the opposite (i.e., guessing a SIP AOR from a SIPS AOR and using it)
is not a valid thing to do as it would be a security downgrade.
Although "downgrading" from SIPS to SIP is disallowed, it is possible
that a redirect server or UAS sends a 3XX response to a request to a
SIPS URI with a Contact header field containing a SIP URI.
[RFC3261]/8.1.3.4 states that if the UAC decides to recurse to the
SIP URI, it "SHOULD inform the user". When a proxy is handling the
3XX, it obviously can not indicate to the user that a redirection has
occured from SIPS to SIP: therefore, proxies would not be able
recurse on the Contact header field, and instead would either forward
the 3XX to the UAC or reject the request.
3.2.1. Detection of Hop-by-Hop Security
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 can not know for sure. However,
[RFC3261]/26.4.4 recommends how a UAS may make some checks to
validate the security. Additionally, the History-Info header
[RFC4244] could be inspected for detecting retargeting between SIP
and SIPS.
It should be restated that all the checking may be circumvented by
any proxies or B2BUAs on the path that does not follow the rules and
recommendations of this specification and of [RFC3261].
Proxies can have their own policies regarding routing of requests to
SIP or SIPS URIs. For example, some proxies in some environment may
be configured to only route SIPS. Some proxies may 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 headers to enforce SIPS.
[RFC3261]/26.4.4 explains that S/MIME may 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
[RFC3261]/26.4.4, this is meant to imply that [RFC3893] would be used
to "tunnel" important headers (such as To and From) in an encrypted
Audet Expires November 24, 2007 [Page 9]
Internet-Draft SIPS May 2007
and signed S/MIME body, replicating the information in the SIP
message, and allowing the UAS to validate the content of those
important headers. While this approach is certainly legal, a
preferable approach is to use the SIP Identity mechanism defined in
[RFC4474]. SIP Identity creates a signed identity digest which
includes, amongst other things, the AOR of the sender (from the From
header) and the AOR of the original destination (from the To header).
3.2.2. Double Record Routing
While proxies conforming to this specification do not forward or
retarget from SIP to SIPS and vice-versa, it is possible that proxies
that conform to [RFC3261] but not to this specification may do so.
The use case for a proxy to forward a request from SIPS to SIP was
the "last hop exception" downgrade described in Section 1.
This section explains how such a proxy would be able to use "double
record route" in order to forward or retarget a request from SIP to
SIPS or from SIPS to SIP. This section is included for completeness,
to describe how to achieve backward compatibility. If a proxy
conforms to this specification, the procedures in this section are
not used.
When a proxy inserts a Record-Route entry, it must take care in using
the proper scheme so that further in-dialog requests are sent to the
proper URI. [RFC3261] sections 16.6 and 16.7 describe how this can
be done by having the proxy modifying the Record-Route in the
response. However, as described in [RFC3608], this is problematic.
It is preferable to use the procedures of [RFC3608], and instead of
following the procedure in [RFC3261], proxies that are inserting
Record-Route or Path header field URIs would record not one but two
route URIs when processing the request in the case where the scheme
is changed. The first value recorded indicates the scheme of the
receiving interface, and the second indicates the scheme of the
sending interface. When processing the response, no modification of
the recorded route is required. This optimization provides for fully
invertible routes that can be effectively used in construction of
service routes.
If the Request-URI or the topmost Route header on the receiving
interface is SIPS and the Request-URI on the sending interface is
SIP, then the first value recorded uses a SIPS URI and the second
value indicates a SIP URI. It is illustrated as follows:
Audet Expires November 24, 2007 [Page 10]
Internet-Draft SIPS May 2007
UA a Proxy UA b
-------REQUEST sips:-------->-------REQUEST sip:--------->
Record-Route: <sip:p;lr>,
<sips:p;lr>
<------Response sips:-------<-------Response sip:---------
Record-Route: <sip:p;lr> Record-Route: <sip:p;lr>,
<sips:p;lr> <sips:p;lr>
Record routing from SIPS to SIP
If the Request-URI on the receiving interface is SIP and the Request-
URI on the sending interface is SIPS, then the first value recorded
uses a SIP URI and the second value indicates a SIPS URI. It is
illustrated as follows:
UA a Proxy UA b
-------REQUEST sip:--------->-------REQUEST sips:-------->
Record-Route: <sips:p;lr>,
<sip:p;lr>
<------Response sip:--------<-------Response sips:--------
Record-Route: <sips:p;lr> Record-Route: <sips:p;lr>,
<sip:p;lr> <sip:p;lr>
Record routing from SIP to SIPS
Note that the same rules apply to the Path Header [RFC3327].
3.3. Usage of the transport=tls URI Parameter and the TLS Via Parameter
[RFC3261]/26.2.2 makes it clear that the use of the "transport=tls"
URI transport parameter in SIPS or SIP URIs has been deprecated:
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.
However, the "tls" parameter has not been eliminated from the ABNF in
[RFC3261]/25, and [RFC3261]/26.2.1 has a vague reference to it. This
has been a source of confusion. The reference in section 26.2.1 is
an error in [RFC3261] (see Appendix B). However, the parameter needs
Audet Expires November 24, 2007 [Page 11]
Internet-Draft SIPS May 2007
to remain in the ABNF for backward compatibility in order for parsers
to be able to process the parameter correctly.
Some implementations are currently using the transport=tls parameter
to indicate the use of TLS without SIPS. There are a number of
problems with that usage besides the ones mentioned above. In a
Contact header field in a REGISTER message, it is uncessary as the
the support for TLS can be implicitly determined from the fact that
TLS was used to perform the registration (not using TLS for
registration would be a security hole). In a Contact header field in
a dialog-creating request, it would only be useful in the cases where
Record-Route and [I-D.ietf-sip-outbound] are not used. However, as
described in the specification, this is extremely unlikely to work
because of the difficulty in establishing the TLS connection in this
case. In a Request-URI, the transport parameter would effectively be
an instruction by the UAC for the resource identified by the URI to
be contacted using TLS. If loose routing is used by all proxies in
the path, it would then be an instruction for the last proxy before
the UAS on which transport to use to reach the UAS. There is no
reason why it would be useful to be able to specify that only the
last hop should be transported over TLS. Complicating matters, if
strict routing is used in one or more proxies in the path, it would
then be an instruction for the proxy before the first strict route
for what transport to use for that last hop to that specific strict-
route proxy. The transport parameter would also not have any
transitive behavior (i.e., it would not be propagated to further
hops). The decision on whether or not to use TLS as a transport for
a specific hop, is hop-by-hop by nature. If one wants to enforce the
usage of TLS on all hops, the SIPS scheme must be used.
For Via headers, the following transport protocol are defined in
[RFC3261]: "UDP", "TCP", "TLS", "SCTP", and in [RFC4168]: "TLS-SCTP".
4. Normative Requirements
This section describes all the normative requirements defined by this
specification. The justification for the [RFC2119] language is
provided by the previous sections of this specification.
4.1. General User Agent Behavior
When presented with a SIPS URI, a UAC or UAS MUST NOT change it to a
SIP URI. For example, if a directory entry includes a SIPS AOR, the
UAC must not send requests to that AOR using a SIP Request-URI.
Similarly, if a user reads a business card with a SIPS URI, he should
not infer a SIP URI (unfortunately, we can not prevent people from
being foolish). If a 3XX response includes a SIPS Contact header
Audet Expires November 24, 2007 [Page 12]
Internet-Draft SIPS May 2007
field, the UAC MUST 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.
As mandated by [RFC3261]/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". Furthermore, as
mandated by [RFC3261]/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".
If a UAS does not support SIPS, "it SHOULD reject the request with a
416 (Unsupported URI scheme) response" as described in [RFC3261]/
8.2.2.1. Upon receiving a 416, a UAC MUST NOT re-attempt the request
by automatically replacing the SIPS scheme with a SIP scheme as
described in [RFC3261]/8.1.3.5 as it would be a security
vulnerability. If the UAC does re-attempt the call with a SIP URI,
it SHOULD get a confirmation from the user to authorize re-initiating
the session with a SIP Request-URI instead of a SIPS Request-URI.
If a UAS does not wish to be contacted with a SIP URI, it MAY reject
a request to a SIP Request-URI with response code 403 (Forbidden), or
it MAY redirect the request to a SIPS URI with a 3XX response. A 3XX
response has the advantage that it provides some indication to the
UAC on why the request was rejected, i.e., that the session SHOULD be
tried again to the SIPS Contact header field. If a UAS wishes to
indicate to the UAC that it does not wish to be reachable with a SIP
AOR, it MUST send a 301 (Moved Permanently) with a SIPS AOR instead.
Upon receiving a 3XX response with a SIPS Contact header field, the
UAC SHOULD automatically re-initiate the request using a SIPS
Request-URI (i.e., it does not need to get a confirmation from the
user to authorize re-initiating the session with a SIPS Request-URI
instead of a SIP Request-URI).
The "transport=tls" parameter MUST NOT be used by UAs. However, for
backward compatibility, if a "transport=tls" parameter is received by
a UA, it should be interpreted as per the following guidelines:
o In a Contact header field in a dialog-creating request, it could
be interpreted by the UAS as a request to send incoming mid-dialog
requests using TLS. Note that this would only have a significance
if [I-D.ietf-sip-outbound] and Record-Route are not used, and if
that URI is nevertheless reachable with TLS which is extremely
unlikely. If it was the case that it was reachable with TLS, say
because there is an active TLS connection, then that connection
could be re-used anyway, regardless of the presence of the
Audet Expires November 24, 2007 [Page 13]
Internet-Draft SIPS May 2007
transport parameter. It is RECOMMENDED that the "transport=tls"
parameter in a Contact header field in a dialog be ignored by the
UAS.
o In a Request-URI, the transport parameter would be an instruction
for the last proxy before the resource identified by the Request-
URI on what transport to use for delivering the request to that
resource, which is not useful (see Section 3.3). On the last hop
of an incoming request (as seen by the UAS), it is useless because
the transport is self-evident. Therefore, a UAS MUST ignore the
"transport=tls" parameter in a Request-URI.
o In a Contact header field in a 3XX response, it would essentially
mean a request to attempt to re-send the request, using the
transport=tls parameter in the Request-URI, as described in the
previous paragraph. Therefore, a transport=tls parameter SHOULD
be ignored by the recursing entity.
4.1.1. Service Routes
If a UA registers with a SIPS Contact header field, the registrar
returning a service route [RFC3608] 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. It is the responsibility of
the UAC to use a Route header consisting of all SIPS URIs when using
a SIPS Request-URI and Contact header field. Specifically, if the
service route included SIP URI, the UAC MUST upgrade the SIP URIs to
SIPS URIs simply by changing the scheme from "sip" to "sips" before
sending the request. Note that this allows for configuring or
discovering one service route with all SIP URIs and allowing sending
requests to both SIP and SIPS URIs.
4.1.2. Registration
This section describes the registration procedures of SIPS versus SIP
Contact header fields.
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.
If a UA wishes to be reachable with a SIPS URI, it 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.
Audet Expires November 24, 2007 [Page 14]
Internet-Draft SIPS May 2007
Note that 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 may be used to
provision such a preference. A SIP mechanism for provisioning such a
preference is outside the scope of this specification.
If a UA does not wish to be reached with a SIPS URI, it MUST register
with a SIP Contact header field.
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: it 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.
Note however that 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).
[I-D.ietf-sip-outbound] 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.
If all the Contact header fields in a REGISTER are SIPS, a SIPS AOR
MUST be used by the UAC in the REGISTER. If at least one of the
Contact header fields is SIP or is neither SIP nor SIPS (e.g.,
mailto, tel, http, https), a SIP AOR MUST also be used by the UAC.
However, the registrar MUST treat the SIP and SIPS schemes of the AOR
the same way (i.e., it MUST not care if it is SIP or SIPS). These
are purely mechanical rules with no influence on routing.
Furthermore, it is a matter of local policy for a UA 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 would
reject requests addressed to a SIP Request-URI with 403 (Forbidden).
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 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 would
accept requests addressed to a SIP Request-URI.
A registrar MUST only accept a binding to a SIPS Contact header field
Audet Expires November 24, 2007 [Page 15]
Internet-Draft SIPS May 2007
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 headers, but does not include the From and To headers.
If the URIs are not of the proper SIPS scheme, the registrar MUST
reject the REGISTER with a 403 (Forbidden).
The usage of the "transport" URI parameter in Contact header fields
in registration has been a source of confusion (not just for
transport=tls, but also in general, e.g., for transport=tcp).
[RFC3261] makes both TCP and UDP transport mandatory. Therefore,
there is no point in using the transport URI parameter in a Contact
header field in a REGISTER since both transports are supported.
However, field experience has shown that some implementations
(especially older ones) support UDP but not TCP. Newer revisions to
these implementations that have added TCP support have used the
transport parameter to explicitly tell the registrar that they now
supported TCP. The logic behind that argument is flawed as the
transport would be self-evident from the registration process.
Furthermore, proxies can revert back to UDP if TCP fails. Using the
transport parameter in a Contact in a REGISTER to determine the
preferred transport, instead of just using the actual transport, also
introduces some complexities and problems. For example, should all
the transports be listed separately (e.g, UDP, TCP, SCTP, TLS over
TCP, TLS over SCTP)? If so, how should they be prioritized? It
would not be possible to use multiple Contact header fields using a
q-value, because this would be interpreted by proxies as a forking
scenario and the multiple transports would be tried in series or
parallel depending on the q-value. Another issue is what happens if
a UAC fetches bindings by sending an empty REGISTER message. Would
the proxy respond with one or all the possible transports? All this
would generate unwarranted complexity. Exacerbating the problem is
the fact that some implementations have been using the transport=tls
parameter to explicitly indicate support for TLS.
It is therefore RECOMMENDED that UACs do not use any transport URI
parameters in Contact header fields in REGISTER.
For backward compatibility, a registrar should accept a REGISTER
message with a transport URI parameter in the Contact header field.
A registrar MUST ignore that parameter, and instead use the transport
used for the registration itself as the implied preferred transport.
4.1.3. SIPS in a Dialog
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
Audet Expires November 24, 2007 [Page 16]
Internet-Draft SIPS May 2007
Contact header field was a SIPS URI, it would mean that it 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 may not be
able to send requests to SIPS URIs. If the top Route header field
does not contain a SIPS URI, the Contact header field MUST be a SIP
URI, 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 [I-D.ietf-sip-outbound]).
When a target refresh occurs within a dialog (e.g., re-INVITE,
UPDATE), the UAC and UAS MUST include a Contact header field with a
SIPS URI if the original request used a SIPS Request-URI.
4.1.4. Derived Dialogs and Transactions
Sessions, dialogs and transactions may 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 [RFC3515].
As a general principle, derived dialogs and transactions MUST NOT
result in an effective downgrading of SIPS to SIP, without the
explicit authorization of the entities involved.
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 new one MUST NOT be established
using SIP, unless there is an explicit authorization given by the
recipient of the REFER. 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. If the proper treatment is to reject the
REFER, for example because warnings are impractical or impossible
with very simple phones, it could be rejected with error response 403
(Forbidden).
Note that a REFER may also be used for referring to resources that do
not result in dialogs being created. In fact, a REFER may be used to
point to resources that are of a different type than the original one
(i.e., not SIP or SIPS). Please see [RFC3515]/5.2 for security
considerations related to this.
Other examples of derived dialogs and transactions include the use of
Third-Party Call Control [RFC3725], the Replaces header [RFC3891],
and the Join header [RFC3911]. Again, the general principle is that
these mechanism SHOULD NOT result in an effective downgrading of SIPS
to SIP, without the proper authorization.
Audet Expires November 24, 2007 [Page 17]
Internet-Draft SIPS May 2007
4.1.5. GRUU
When a GRUU [I-D.ietf-sip-gruu] 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 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.
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).
4.2. Proxy Behavior
Proxies that conform to this specification MUST NOT use the last hop
exception 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, it MUST reject it with a 403 (Forbidden).
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.
[I-D.ietf-sip-outbound] for example, allows for re-using an existing
TLS connection. Some proxies MAY have policies that prohibits
sending any request over anything but TLS.
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, it 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 MAY 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, it MAY reject it with a 403 (Forbidden) or it MAY
redirect it to a SIPS Request-URI with a 3XX response. A 3XX
response has the advantage that it provides some indication to the
UAC on why the request was rejected, i.e., the session SHOULD be
retried using the Contact header field of the 3XX response as a
Audet Expires November 24, 2007 [Page 18]
Internet-Draft SIPS May 2007
target.
It is RECOMMENDED to use an outbound proxy as per the procedures
defined in [I-D.ietf-sip-outbound] for supporting UACs that can not
provide a certificate for establishing a TLS connection (i.e., when
server-side authentication is used).
When a proxy sends a request using a SIPS Request-URI and receives a
3XX response with a SIP Contact header field, it MUST NOT recurse on
the Contact header field. The Proxy SHOULD forward the 3XX to the
UAC instead of recursing, in order to allow for the UAC to take the
appropriate action. The proxy MAY instead reject the request with a
403 (Forbidden) if it is not its policy to allow redirection to be
done by the UA and consequently, the user will not receive any
indication of why the request was rejected.
When a proxy sends a request using a SIP Request-URI and receives a
3XX response with a SIPS Contact header field, it MUST NOT recurse on
the Contact header field. The Proxy SHOULD forward the 3XX to the
UAC instead of recursing, in order to allow for the UAC to take the
appropriate action. The proxy MAY instead respond to the request
with a 416 (Unsupported URI Scheme) if it is not its policy to allow
redirection to be done by the UA.
The "transport=tls" parameter must not be used by proxies. However,
for backward compatibility, if a "transport=tls" parameter is
received by a proxy, it should be interpreted as per the following
guidelines:
o [RFC3261]/16.7 states that in a Record-Route, "The URI SHOULD NOT
contain the transport parameter unless the proxy has knowledge
(such as in a private network) that the next downstream element
that will be in the path of subsequent requests supports this
transport". Generally, it is recommended that the transport
parameter never be used in a Record-Route, Route or Path header.
Since the transport=tls URI parameter has been deprecated, it MUST
NOT be used in Route, Record-Route or Path headers, and MUST be
ignored.
o In a Request-URI, the transport parameter would be an instruction
for the last proxy before the resource identified by the Request-
URI on what transport to use for delivering the request to that
resource, which is not useful (see Section 3.3). Therefore, a UAS
MUST ignore the "transport=tls" parameter in a Request-URI. A
proxy MUST ignore the "transport=tls" parameter in a Request-URI.
Audet Expires November 24, 2007 [Page 19]
Internet-Draft SIPS May 2007
4.3. Redirect Server Behavior
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
[I-D.ietf-sip-outbound]), 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
mutual TLS is used, and where there are no NAT traversal issues. A
redirect server would not be usable if server-side authentication is
used or if there is a NAT between the server and the UAS.
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.
When a redirect server receives a request with a SIPS 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 to "upgrade" to SIPS 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 chooses to redirect;
otherwise it may reject the request with a 416 (Unsupported URI
Scheme).
5. Call Flows
The following diagram illustrates the topology used for the examples
in this section:
Audet Expires November 24, 2007 [Page 20]
Internet-Draft SIPS May 2007
|-----------|
| Registrar |
|-----------|
|
|
|-----------| |-----------|
| Outbound |__________| Outbound |
| Proxy B | | Proxy A |
|-----------| |-----------|
/ | |
/ | |
/ | |
______ | |
| | _____ _____
|______| O / \ O O / \ O
/_______/ /___\ /___\
bob@bobpc bob@bobphone Alice
Topology
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 Outbound Proxy B, and
consequently, they include a Route header indicating Proxy B. Proxy B
removes the Route header corresponding to itself, and adds itself in
a Path header. The registration process call flow is illustrated in
Section 5.1.
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.
Alice then calls Bob through her own Outbound Proxy A, including a
Route header for Proxy A. Proxy A locates Bob's domain example.com.
In this example, that domain is co-located with Bob's outbound proxy,
but it could easily have been a separate proxy. Outbound Proxy A
removes the Route header corresponding to itself, and inserts itself
in the Record-Route and forwards the request to Outbound Proxy B.
The following subsections illustrates registration and three
examples. In the first example (Section 5.2), Alice calls Bob using
Bob's SIPS URI. In the second example (Section 5.3), Alice calls
Bob's SIP AOR using TCP transport. In the third example
Audet Expires November 24, 2007 [Page 21]
Internet-Draft SIPS May 2007
(Section 5.4), Alice calls Bob's SIP AOR using TLS transport.
5.1. Bob Registers his Contacts
This call 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.
Outbound
Bob@bobpc Proxy B Registrar
| | |
| REGISTER F1 | |
|------------------>| REGISTER F2 |
| |-------------->|
| | 200 F3 |
| 200 F4 |<--------------|
|<------------------| |
| | |
| Bob@bobphone | |
| | | |
| |REGISTER F5 | |
| |----------->| REGISTER F6 |
| | |-------------->|
| | | 200 F7 |
| | 200 F8 |<--------------|
| |<-----------| |
| | | |
Bob Registers His Contacts
Message details
Audet Expires November 24, 2007 [Page 22]
Internet-Draft SIPS May 2007
F1 REGISTER Bob's PC Client -> Proxy B
REGISTER sip:registrar.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
Route: <sip:proxyb.example.com;lr>
Contact: <sip:bob@bobpc.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
Expires: 7200
Content-Length: 0
F2 REGISTER Proxy B -> Registrar
REGISTER sip:registrar.example.com SIP/2.0
Via: SIP/2.0/TCP proxyb.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@proxyb.example.com;lr>
Contact: <sip:bob@bobpc.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
Expires: 7200
Content-Length: 0
Audet Expires November 24, 2007 [Page 23]
Internet-Draft SIPS May 2007
F3 200 (REGISTER) Registrar -> Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxyb.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
Supported: outbound
Path: <sip:laksdyjanseg237+fsdf@proxyb.example.com;lr>
Contact: <sip:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
;expires=7200
Date: Mon, 12 Jun 2006 16:43:12 GMT
Content-Length: 0
F4 200 (REGISTER) 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
Supported: outbound
Path: <sip:laksdyjanseg237+fsdf@proxyb.example.com;lr>
Contact: <sip:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
;expires=7200
Date: Mon, 12 Jun 2006 16:43:12 GMT
Content-Length: 0
Audet Expires November 24, 2007 [Page 24]
Internet-Draft SIPS May 2007
F5 REGISTER Bob's Phone -> Proxy B
REGISTER sips:registrar.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:proxyb.example.com;lr>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
Expires: 7200
Content-Length: 0
F6 REGISTER Proxy B -> Registrar
REGISTER sips:registrar.example.com SIP/2.0
Via: SIP/2.0/TLS proxyb.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+kkls@proxyb.example.com;lr>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
Expires: 7200
Content-Length: 0
Audet Expires November 24, 2007 [Page 25]
Internet-Draft SIPS May 2007
F7 200 (REGISTER) Registrar -> Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TLS proxyb.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
Supported: outbound
Path: <sips:psodkfsj+34+kkls@proxyb.example.com;lr>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
;expires=7200
Date: Mon, 12 Jun 2006 16:43:50 GMT
Content-Length: 0
F8 200 (REGISTER) 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
Supported: outbound
Path: <sips:psodkfsj+34+kkls@proxyb.example.com;lr>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
;expires=7200
Date: Mon, 12 Jun 2006 16:43:50 GMT
Content-Length: 0
5.2. Alice Calls Bob's SIPS AOR
Bob's registration has already occurred as per Section 5.1.
In this first example, Alice calls Bob's SIPS AOR
(sips:bob@example.com). 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 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. Proxy B inserts itself in the Record-
Audet Expires November 24, 2007 [Page 26]
Internet-Draft SIPS May 2007
Route. Bob answers at sips:bob@bobphone.example.com.
Outbound Outbound
Bob@bobpc Proxy B Proxy A Alice
| | | |
| Bob@bobphone | | INVITE F9 |
| | | INVITE F11 |<-------------|
| | INVITE F13 |<-------------| 100 F10 |
| |<-------------| 100 F12 |------------->|
| | 100 F14 |------------->| |
| |------------->| | |
| | 200 F15 | | |
| |------------->| 200 F16 | |
| | |------------->| 200 F17 |
| | | |------------->|
| | | | ACK F18 |
| | | ACK F19 |<-------------|
| | ACK F20 |<-------------| |
| |<-------------| | |
| | | | |
Alice Calls Bob's SIPS AOR
Message details
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}
Audet Expires November 24, 2007 [Page 27]
Internet-Draft SIPS May 2007
F10 100 (INVITE) Proxy A -> Alice
SIP/2.0 100 Trying
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
Content-Length: 0
F11 INVITE Proxy A -> 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:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F12 100 (INVITE) 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
Audet Expires November 24, 2007 [Page 28]
Internet-Draft SIPS May 2007
F13 INVITE Proxy B -> Bob's Phone
INVITE sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS proxyb.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
Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sips:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F14 100 (INVITE) Bob's Phone -> Proxy B
SIP/2.0 100 Trying
Via: SIP/2.0/TLS proxyb.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
Audet Expires November 24, 2007 [Page 29]
Internet-Draft SIPS May 2007
F15 200 (INVITE) Bob's Phone -> Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TLS proxyb.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:UJH-hUdvb65@proxyb.example.com;lr>,
<sips:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F16 200 (INVITE) 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:UJH-hUdvb65@proxyb.example.com;lr>,
<sips:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F17 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:UJH-hUdvb65@proxyb.example.com;lr>,
<sips:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
Audet Expires November 24, 2007 [Page 30]
Internet-Draft SIPS May 2007
F18 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:KFndf+47KsFH@proxya.example.net;lr>,
<sips:UJH-hUdvb65@proxyb.example.com;lr>
Content-Length: 0
F19 ACK Proxy A -> 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:UJH-hUdvb65@proxyb.example.com;lr>
Content-Length: 0
F20 ACK Proxy B -> Bob's Phone
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS proxyb.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
5.3. Alice Calls Bob's SIP AOR using TCP
Bob's registration has already occurred as per Section 5.1.
In the second example, Alice calls Bob's SIP AOR instead
(sip:bob@example.com), and she uses TCP as a transport. Proxy B
consults the binding in the registration database, and finds the two
Audet Expires November 24, 2007 [Page 31]
Internet-Draft SIPS May 2007
Contact header field bindings. Alice had addressed Bob with a SIP
Request-URI (sip:bob@example.com), so 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. Note
that the proxy replaced the SIPS scheme with the SIP scheme for
bob@bobphone.example.com. Outbound Proxy B inserts itself 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.
Audet Expires November 24, 2007 [Page 32]
Internet-Draft SIPS May 2007
Outbound Outbound
Bob@bobpc Proxy B Proxy A Alice
| | | |
| | | INVITE F9 |
| | INVITE F11 |<------------|
| INVITE F13' |<-------------| 100 F10 |
|<------------------| 100 F12 |------------>|
| 100 F14' |------------->| |
|------------------>| | |
| 180 F15' | | |
|------------------>| 180 F16' | |
| |------------->| 180 F17' |
| Bob@bobphone | |------------>|
| | | | |
| | INVITE F13 | | |
| |<-----------| | |
| | 100 F14 | | |
| |----------->| | |
| | 200 F15 | | |
| |----------->| 200 F16 | |
| | |------------->| 200 F17 |
| | | |------------>|
| | | | ACK F18 |
| | | ACK F19 |<------------|
| | ACK F20 |<-------------| |
| |<-----------| | |
| | | |
| CANCEL F20' | | |
|<------------------| | |
| 200 F21' | | |
|------------------>| | |
| 487 F22' | | |
|------------------>| | |
| | | |
Alice Calls Bob's SIP AOR
Message details
Audet Expires November 24, 2007 [Page 33]
Internet-Draft SIPS May 2007
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}
F10 100 (INVITE) Proxy A -> Alice
SIP/2.0 100 Trying
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
Content-Length: 0
F11 INVITE Proxy A -> 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:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
Audet Expires November 24, 2007 [Page 34]
Internet-Draft SIPS May 2007
F12 100 (INVITE) 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
F13' INVITE Proxy B -> Bob's PC Client
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP proxyb.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
Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F14' 100 (INVITE) Bob's PC Client -> Proxy B
SIP/2.0 100 Trying
Via: SIP/2.0/TCP proxyb.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
Audet Expires November 24, 2007 [Page 35]
Internet-Draft SIPS May 2007
F15' 180 (INVITE) Bob's PC Client -> Proxy B
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP proxyb.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:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F16' 180 (INVITE) 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:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F17' 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:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
Audet Expires November 24, 2007 [Page 36]
Internet-Draft SIPS May 2007
F13 INVITE Proxy B -> Bob's Phone
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS proxyb.example.com:5061;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: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F14 100 (INVITE) Bob's Phone -> Proxy B
SIP/2.0 100 Trying
Via: SIP/2.0/TLS proxyb.example.com:5061;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
Audet Expires November 24, 2007 [Page 37]
Internet-Draft SIPS May 2007
F15 200 (INVITE) Bob's Phone -> Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TLS proxyb.example.com:5061;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: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F16 200 (INVITE) 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: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
Audet Expires November 24, 2007 [Page 38]
Internet-Draft SIPS May 2007
F17 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: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F18 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:KFndf+47KsFH@proxya.example.net;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sips:UJH-hUdvb65@proxyb.example.com;lr>
Content-Length: 0
F19 ACK Proxy A -> 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:UJH-hUdvb65@proxyb.example.com;lr>,
<sips:UJH-hUdvb65@proxyb.example.com;lr>
Content-Length: 0
Audet Expires November 24, 2007 [Page 39]
Internet-Draft SIPS May 2007
F20 ACK Proxy B -> Bob's Phone
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS proxyb.example.com:5061;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
F20' CANCEL Proxy B -> Bob's PC Client
CANCEL sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP proxyb.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
Content-Length: 0
F21' 200 (CANCEL) Proxy B -> Bob's PC Client
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxyb.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
Audet Expires November 24, 2007 [Page 40]
Internet-Draft SIPS May 2007
F22' 487 (INVITE) Proxy B -> Bob's PC Client
SIP/2.0 487 Request Terminated
Via: SIP/2.0/TCP proxyb.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
5.4. Alice Calls Bob's SIP AOR using TLS
Bob's registration has already occurred as per Section 5.1.
The third example is identical to the second one, except that Alice
uses TLS as the transport for her connection to her outbound proxy.
Such an arrangement would be common if Alice's UA supported TLS and
wanted to use a single connection to the outbound proxy (as would be
the case when using [I-D.ietf-sip-outbound]). In the example below,
Outbound proxy A is also using TLS as a transport to communicate with
Outbound proxy B, but it is not necessarily the case.
It should be noted that 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 (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.
The call flow would be exactly as per the second example
(Section 5.3).
Messages F20'-F22' are identical to the ones in Section 5.3. The
other messages are as follows.
Audet Expires November 24, 2007 [Page 41]
Internet-Draft SIPS May 2007
F9 INVITE Alice -> Proxy A
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TLS alice-1.example.net:5061;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}
F10 100 (INVITE) Proxy A -> Alice
SIP/2.0 100 Trying
Via: SIP/2.0/TLS alice-1.example.net:5061;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
Content-Length: 0
F11 INVITE Proxy A -> Proxy B
INVITE sip: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 <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
Audet Expires November 24, 2007 [Page 42]
Internet-Draft SIPS May 2007
F12 100 (INVITE) 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 <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
F13' INVITE Proxy B -> Bob's PC Client
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2
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 <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F14' 100 (INVITE) Bob's PC Client -> Proxy B
SIP/2.0 100 Trying
Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2
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 <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
Audet Expires November 24, 2007 [Page 43]
Internet-Draft SIPS May 2007
F15' 180 (INVITE) Bob's PC Client -> Proxy B
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2
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 <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F16' 180 (INVITE) 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 <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F17' 180 (INVITE) Proxy A -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS alice-1.example.net:5061;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:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
Audet Expires November 24, 2007 [Page 44]
Internet-Draft SIPS May 2007
F13 INVITE Proxy B -> Bob's Phone
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1
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 <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F14 100 (INVITE) Bob's Phone -> Proxy B
SIP/2.0 100 Trying
Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1
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 <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
Audet Expires November 24, 2007 [Page 45]
Internet-Draft SIPS May 2007
F15 200 (INVITE) Bob's Phone -> Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1
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 <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F16 200 (INVITE) 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 <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
Audet Expires November 24, 2007 [Page 46]
Internet-Draft SIPS May 2007
F17 200 (INVITE) Proxy A -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/TLS alice-1.example.net:5061;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: <sips:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sip:KFndf+47KsFH@proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F18 ACK Alice -> Proxy A
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS alice-1.example.net:5061;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:KFndf+47KsFH@proxya.example.net;lr>,
<sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sips:UJH-hUdvb65@proxyb.example.com;lr>
Content-Length: 0
F19 ACK Proxy A -> Proxy B
ACK sip:bob@bobphone.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 <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>,
<sips:UJH-hUdvb65@proxyb.example.com;lr>
Content-Length: 0
Audet Expires November 24, 2007 [Page 47]
Internet-Draft SIPS May 2007
F20 ACK Proxy B -> Bob's Phone
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1
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 <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Content-Length: 0
6. Conclusion
SIP [RFC3261] 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 may 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
may occur. In this case, using Record-Route so that the requests are
sent through proxies may 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 may
still not be possible for the far end to establish a TLS connection
with the SIP originating end if the certificate can not 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.
TLS itself has a significant impact on how SIPS may 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. "Mutual TLS" (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 TLS
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
Audet Expires November 24, 2007 [Page 48]
Internet-Draft SIPS May 2007
URI is used to establish a TLS connection, it must be possible for
the entity establishing the connection (the client) to validate the
certificate from the server side. For server-side authentication,
[I-D.ietf-sip-outbound] is the recommended approach. For mutual TLS,
it means that one should be very careful that the architecture of the
network is such that connections are made between entities that have
access to each other's certificates. Record-Route [RFC3261] and Path
[RFC3327] are very useful in ensuring that previously established TLS
connections can be re-used. Other mechanisms may also be used in
certain circumstances: for example, using root certificates that are
widely recognized may allow for more easily created TLS connections.
The "last hop exception" introduces significant potential
vulnerabilities in SIP and it has therefore been deprecated by this
specification.
7. Security Considerations
Most of this document can be considered to be security considerations
since it applies to the usage of the SIPS URI.
8. IANA Considerations
There are no IANA Considerations.
9. IAB Considerations
There are no IAB considerations.
10. Acknowledgments
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 and Hans Persson for their careful review and
input.
11. References
Audet Expires November 24, 2007 [Page 49]
Internet-Draft SIPS May 2007
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
(SIP) Extension Header Field for Registering Non-Adjacent
Contacts", RFC 3327, December 2002.
11.2. Informational References
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
(SIP) Extension Header Field for Service Route Discovery
During Registration", RFC 3608, October 2003.
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
Camarillo, "Best Current Practices for Third Party Call
Control (3pcc) in the Session Initiation Protocol (SIP)",
BCP 85, RFC 3725, April 2004.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891,
September 2004.
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP)
Authenticated Identity Body (AIB) Format", RFC 3893,
September 2004.
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol
(SIP) "Join" Header", RFC 3911, October 2004.
[RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The
Stream Control Transmission Protocol (SCTP) as a Transport
for the Session Initiation Protocol (SIP)", RFC 4168,
October 2005.
[RFC4244] Barnes, M., "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", RFC 4244,
November 2005.
Audet Expires November 24, 2007 [Page 50]
Internet-Draft SIPS May 2007
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-08 (work in progress), March 2007.
[I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-13 (work in progress),
April 2007.
Appendix A. Future Steps in Specification
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.
A.1. Indication of Validity of SIPS
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.
A.2. True End-to-End Encryption of SIP
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.
Appendix B. Bug Fixes for RFC 3261
The last sentence of the fifth paragraph of 8.1.3.5 must be replaced
by:
Audet Expires November 24, 2007 [Page 51]
Internet-Draft SIPS May 2007
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.
The fifth paragraph of section 10.2.1 must be replaced by:
If the address-of-record in the To header field of a REGISTER
request is a SIPS URI, then any Contact header field value in the
request MUST also be SIPS URIs.
In section 16.7 on p. 112 describing Record-Route, the second
paragraph must be deleted.
The last paragraph of section 19.1 must be reworded as follows:
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 (...)
In section 26.2.1 delete the following phrase in the 6th paragraph:
; "tls" (signifying TLS over TCP) can be specified as the desired
transport protocol within a Via header field value or a SIP-URI"
The second paragraph of section 26.2.2 must be reworded as follows:
(...) 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,
must be 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.
The first paragraph of section 26.4.4 must be replaced by the
following:
Actually using TLS on every segment of a request path entails that
the terminating UAS must be 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
Audet Expires November 24, 2007 [Page 52]
Internet-Draft SIPS May 2007
a UAS.
The fourth paragraph of section 26.4.4 must be deleted.
The last sentence of the fifth paragraph of section 26.4.5 must be
reworded as follows:
(...) S/MIME or, preferably, [RFC4474] may also be used (...)
Author's Address
Francois Audet
Nortel Networks
4655 Great America Parkway
Santa Clara, CA 95054
US
Phone: +1 408 495 2456
Email: audet@nortel.com
Audet Expires November 24, 2007 [Page 53]
Internet-Draft SIPS May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Audet Expires November 24, 2007 [Page 54]
