SIP F. Audet
Internet-Draft Nortel Networks
Expires: October 6, 2006 April 4, 2006
Guidelines for the use of the SIPS URI Scheme in the Session Initiation
Protocol (SIP)
draft-audet-sip-sips-guidelines-00
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 October 6, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document provides clarifications and guidelines concerning the
use of SIPS URI Scheme in the Session Initiation Protocol (SIP).
Audet Expires October 6, 2006 [Page 1]
Internet-Draft SIPS Guidelines April 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Upgrading and dowgrading between SIP and SIPS . . . . . . . . 3
4. Registration . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. AOR is to be reachable only with secure transport . . . . 5
4.2. AOR is to be reachable preferably with secure transport . 5
4.3. AOR is to be reachable only without secure transport . . . 6
5. SIPS within a dialog . . . . . . . . . . . . . . . . . . . . . 8
6. Usage of tls and TLS parameters . . . . . . . . . . . . . . . 8
7. REFER and sips . . . . . . . . . . . . . . . . . . . . . . . . 9
8. GRUU, Replaces, Join and Target-Dialog . . . . . . . . . . . . 9
9. Third-party call control . . . . . . . . . . . . . . . . . . . 9
10. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 13
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
15.1. Normative References . . . . . . . . . . . . . . . . . . . 13
15.2. Informational References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Audet Expires October 6, 2006 [Page 2]
Internet-Draft SIPS Guidelines April 2006
1. Introduction
The use of the SIPS URI scheme and of TLS is somewhat underspecified
in SIP [3] and has been the source of confusion for implementors.
The usage of SIPS in various fields such as "Request-URI", "To",
"From", "Contact" in different methods (e.g., REGISTER and INVITE),
and how it relates to the chosen transport has been particularly
confusing. This draft complements another draft that discusses the
use of TLS in SIP [9].
This document provides clarifications and guidelines concerning the
use of the SIPS URI scheme and TLS.
Section 7 [11] also summarizes key points regarding SIPS and TLS,
scattered through RFC 3261.
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 RFC 2119 [1].
3. Upgrading and dowgrading between SIP and SIPS
RFC 3261 allows for "upgrading" any SIP URI to a SIPS URI if it is
desired to communicate securily. It is quite possible that a request
will be rejected with response code 416 (either because TLS is not
supported, or because the policy is to never support secure
transport). When 416 is received, the request could be re-attempted
with a SIP URI, but the user should be informed.
Upgrading a SIP to a SIPS URI AOR is very useful when registering.
It allows for a UAC to register both SIP and SIPS contacts in a
single registration (with multiple contacts) against a single SIP AOR
(registrations only allows for single AOR, but multiple contacts).
The registrar, upon seeing both a SIP and SIPS contact (potentially
prioritized with a proper q-value), and a single SIP AOR MUST infer
that the user is reachabe with a SIPS AOR consisting of the same AOR
as the SIP URI, but with the scheme changed from "sip" to "sips".
OPEN ISSUE: Should we make the previous statement about infering a
SIPS AOR from a SIP AOR a MUST or a SHOULD for the registrar? The
problem with making it a SHOULD is that some registrars might then
expect 2 registrations, one for the SIP AOR, another one for the
SIPS AOR. This is quite wasteful. Furthermore, it would be an
issue for SIP device manufacturers: if they want their device to
Audet Expires October 6, 2006 [Page 3]
Internet-Draft SIPS Guidelines April 2006
be reachable with both a SIP and a SIPS URI, and the type of
registrar is not known, the device will have to perform 2
registration. This is quite troublesome because it is very
inexpensive for the device to do so, but very expensive for the
registrar, even if it is a "good" registrar that follows the
SHOULD.
However, when registering a Contact, a UAC MUST explicitely register
both the SIP and SIPS contacts if it expects to be contacted using
either SIP or SIPS. Similarly, a registrar SHOULD NOT "upgrade" SIP
contacts to SIPS contacts because it may create situations where a
contact is not reachable anymore by other users.
RFC 3261 however does not allow for "downgrading" from SIPS to SIP.
That being said, it is possible that redirect server or UAS send a
3XX response to a request to a SIPS URI with a Contact containing a
SIP URI. Section 8.1.3.4/RFC 3261 recommends that if the UAC decide
to recurse to the SIP URI, it SHOULD inform the user.
OPEN ISSUE: When a proxy is handling the 3XX, it can obviously not
indicate anything to the user that it is recursing from SIPS to
SIP. It is not clear what the proxy should do: should it forward
the 3XX to the user? Should it just ignore the 3XX?
4. Registration
When an AOR is assigned, it must be determined what policy will be
used for reachability.
AOR is to be reachable only with secure transport
AOR is to be reachable preferably with secure transport
AOR is to be reachable only without secure transport
This section provides examples on how the various SIP and SIPS URIs
used in different headers should be used for providing these
policies.
The UAC registers, including Contact values in the REGISTER for each
transport it supports, using a q-value to prioritize the transports.
The Registrar responds to the REGISTER with a 200 OK listing all the
successfully registered contacts. Note that the Registrar may decide
to accept one or many of the listed contacts. Sometimes, it makes
more sense for the Registrar to only accept one Contact: for example,
the registrar may decide to only use the most secure transport when
supported. Another reason for only using one transport is when SIP
is used with outbound connections (i.e., client initiated) [8].
In the examples in this section, it is assumed that TLS is the only
mechanism used for securing SIP. RFC 3261 provides a lot of "escape
Audet Expires October 6, 2006 [Page 4]
Internet-Draft SIPS Guidelines April 2006
clauses" which are meant to be used when the last hop is secured with
other means than TLS (e.g., IPsec in some network environments).
Those escape clauses have been confusing implementors who are using
TLS as the main means of security SIP.
4.1. AOR is to be reachable only with secure transport
If an AOR is to be reachable only with secure transport, the AOR MUST
be a SIPS AOR, and so MUST the contacts and the Request-URI. The Via
header MUST indicate TLS. TLS transport MUST be used to perform the
registration.
REGISTER sips:registrar.example.com;transport=tcp SIP/2.0
Via: SIP/2.0/TLS bobspc.example.com:5060;branch=z9hG4bKnashds
Max-Forwards: 70
To: Bob <sips:bob@example.com>
From: Bob <sips:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sips:bob@bobspc.example.com>;transport=tcp
Expires: 7200
Content-Length: 0
The registrar responds with a 200 OK as follows:
SIP 2.0 200 OK
Via: SIP/2.0/TLS bobspc.example.com:5060;branch=z9hG4bKnashds;
received=192.0.2.4
To: Bob <sips:bob@example.com>;tag=2493K59K9
From: Bob <sips:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sips:bob@bobspc.example.com>;transport=tcp
Expires: 7200
Content-Length: 0
The registrar MUST respond to the REGISTER using the same TLS
connection.
4.2. AOR is to be reachable preferably with secure transport
In many practical network deployment, a best-effort policy is
desireable, i.e., one wants to use a secure transport when possible,
but still allow for a non-secure transport when it is not possible.
In that situation, the UAC MUST use a SIP URI as an AOR, and not a
SIPS URI. The UAC MUST provide both a SIP URI contact and a SIPS URI
contact, appropriately prioritized with a q-value.
Audet Expires October 6, 2006 [Page 5]
Internet-Draft SIPS Guidelines April 2006
The transport used for performing the registration itself MUST be
TLS. The REGISTER message will be as follows:
REGISTER sips:registrar.example.com;transport=tcp SIP/2.0
Via: SIP/2.0/TLS 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
Contact: <sips:bob@bobspc.example.com>;transport=tcp;q=0.7,
<sip:bob@bobspc.example.com>;transport=tcp;q=0.5,
<sip:bob@bobspc.example.com>;transport=udp;q=0.1
Expires: 7200
Content-Length: 0
OPEN ISSUE: See open issue in section 3 [12].
In this example, the registrar responds with a 200 OK as follows, and
only adds the sips Contact, in order to force the use of TLS on that
link.
SIP 2.0 200 OK
Via: SIP/2.0/TLS bobspc.example.com:5060;branch=z9hG4bKnashds;
received=192.0.2.4
To: Bob <sip:bob@example.com>;tag=2493K59K9
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sips:bob@bobspc.example.com>;transport=tcp
Expires: 7200
Content-Length: 0
4.3. AOR is to be reachable only without secure transport
In some cases, disabling secure transport completely may be
desireable (although it is strongly discourage). This may apply when
the equipment does not support TLS, or when there are other security
mechanisms in place (like IPsec).
In that situation, the AOR MUST be a SIP URI. The contacts MUST also
be SIP URI. However, the transport used for performing the
registration itself may be either TLS or not.
If TLS is used for registration, the REGISTER message will be as
follows:
Audet Expires October 6, 2006 [Page 6]
Internet-Draft SIPS Guidelines April 2006
REGISTER sips:registrar.example.com;transport=tcp SIP/2.0
Via: SIP/2.0/TLS 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
Contact: <sip:bob@bobspc.example.com>;transport=tcp;q=0.5,
<sip:bob@bobspc.example.com>;transport=udp;q=0.1
Expires: 7200
Content-Length: 0
The registrar MUST respond to the REGISTER using the same TLS
connection. The registrar responds with a 200 OK as follows, picking
TCP as the only valid transport for the contact:
SIP 2.0 200 OK
Via: SIP/2.0/TLS bobspc.example.com:5060;branch=z9hG4bKnashds;
received=192.0.2.4
To: Bob <sip:bob@example.com>;tag=2493K59K9
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:bob@bobspc.example.com>;transport=tcp
Expires: 7200
Content-Length: 0
If TLS is not used for registration, the REGISTER message will be as
follows:
REGISTER sip:registrar.example.com;transport=tcp 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
Contact: <sip:bob@bobspc.example.com>;transport=tcp;q=0.5,
<sip:bob@bobspc.example.com>;transport=udp;q=0.2
Expires: 7200
Content-Length: 0
In his example, the registrar responds with a 200 OK and picks TCP as
the only valid transport for the contact:
Audet Expires October 6, 2006 [Page 7]
Internet-Draft SIPS Guidelines April 2006
SIP 2.0 200 OK
Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds;
received=192.0.2.4
To: Bob <sip:bob@example.com>;tag=2493K59K9
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Contact: <sip:bob@bobspc.example.com>;transport=tcp
Expires: 7200
Content-Length: 0
5. SIPS within a dialog
There MUST be only one Contact in any request resulting in the
establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER). If the
Request-URI or top Route header field contains a SIPS URI, the
Contact header filed MUST be a SIPS URI as well.
In the response, the Contact field MUST also be a SIPS URI if the
Request-URI contained a SIPS URI or if the topmost Record-Route
header contained a SIPS URI or if the Contact header contained one
and there was no Record-Route header.
OPEN ISSUE: RFC 3261 is not very clear what a UAS is to do if it
doesn't support SIPS and TLS, in which case the previous paragraph
obviously can not apply. Shoud we state that the UAS MUST reject
the request with response code 416? In that case, should we say
that the UAC MUST NOT re-attempt the request with a SIP URI by
automatically replacing the SIPS scheme with a SIP scheme?
When a target refresh occurs within a dialog (e.g., re-INVITE,
UPDATE), the UAC SHOULD include a Contact header with a SIPS URI if
the original request creating the dialog was sent over TLS, and the
Request-URI contained a SIPS URI.
OPEN ISSUE: Handling of annomalies are not very well defined in RFC
3261. For example, what if the request contains a SIPS contact
but the response contains a SIP contact? What if a UAS receives a
SIP Contact replacing a SIPS contact in a target refresh?
6. Usage of tls and TLS parameters
RFC 3261 makes it clear that the use of the "transport=tls" URI
transport parameter in SIPS or SIP URIs has been deprecated.
However, it has not been eliminated from the ABNF in section 25 of
RFC 3261.
Audet Expires October 6, 2006 [Page 8]
Internet-Draft SIPS Guidelines April 2006
For Via headers however, the following transport "UDP", "TCP", "TLS",
"SCTP", and "TLS-SCTP" (see RFC 4168 [7]) are supported.
7. REFER and sips
REFER [5] introduces its own set of issues with sips:
OPEN ISSUE: What if a UA with not support for TLS receives a SIPS URI
in a Refer-to header in a REFER request? Does it reject the
REFER, or accept REFER and send back a 416 in a NOTIFY?
OPEN ISSUE How should the UAC sending a REFER react if it receives a
416 in response to the REFER?
OPEN ISSUE What if a UA with TLS support receives a SIP URI in a
Refer-to header? Is it allowed to "upgrade" to a SIPS URI? It is
probably a bad idea in most scenarios, unless it already knows
that the other ends supports TLS (and has a SIPS URI).
8. GRUU, Replaces, Join and Target-Dialog
GRUU [10] specifies that when a GRUU is obtained through
registration, if the To header field in the REGISTER request contains
a SIP URI, the SIP version of the GRUU is returned. If the To header
filed in the REGISTER request contains a SIPS URI, the SIPS version
of the GRUU is returned.
OPEN ISSUE How should the UAC react if the returned GRUU is SIP but
the To was SIPS?
OPEN ISSUE How should the UAC react if the returned GRUU is SIPS but
the To was SIP?
TBD: Need to look at Replaces, Joing and Target-Dialog. For example,
what if this header field is received in a request to a SIPS URI but
the dialog to which it relates has a SIP local target, or vice-versa?
This is a placeholder for more investigation.
9. Third-party call control
TBD: this is a placeholder for [4]-related issues.
10. Background
The use of the SIPS URI scheme in SIP is scattered throughout the
following sections of RFC 3261 [3].
Audet Expires October 6, 2006 [Page 9]
Internet-Draft SIPS Guidelines April 2006
8.1.1.8 describes the use of the Contact header field. Of
particular importance are the following statements:
The Contact header field MUST be present and contain exactly
one SIP or SIPS URI in any request that can result in the
establishment of a dialog.
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.
8.1.3.4 describes processing of 3XX responses. Of particular
importance is the following statement:
If the original request had a SIPS URI in the Request-URI, the
client MAY choose to recurse to a non-SIPS URI, but SHOULD
inform the user of the redirection to an insecure URI.
8.1.3.5 and 8.2.2.1 implies that if a SIPS is not supported by
UAS, it can reject it with a 416, and the UAC SHOULD retry the
request with a SIP URI. However, although not discussed in RFC
3261, the user should be informed.
10.2.1 describes address binding of SIPS AOR during registration:
If the address-of-record in the To header field of a REGISTER
request is a SIPS URI, then any Contact header field values in
the request SHOULD also be SIPS URIs. Clients should only
register non-SIPS URIs under a SIPS address-of-record when the
security of the resource represented by the contact address is
guaranteed by other means. This may be applicable to URIs that
invoke protocols other than SIP, or SIP devices secured by
protocols other than TLS.
12.1.1 describes the UAS behavior when creating a dialog with a
SIPS Request-URI or a top Record-Route header:
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.
12.1.2 describes the UAC behavior when creating a dialog with a
SIPS Request-URI or a top Recored-Route header. Of particular
importance are the following statements:
If the request has a Request-URI or a topmost Route header
field value with a SIPS URI, the Contact header field MUST
contain a SIPS URI.
If the request was sent over TLS, and the Request-URI contained
a SIPS URI, the "secure" flag is set to TRUE.
12.2.1.1 expands on what this secure flag means when doing any
target refresh requests within that dialog:
Audet Expires October 6, 2006 [Page 10]
Internet-Draft SIPS Guidelines April 2006
A UAC SHOULD include a Contact header field in any target
refresh requests within a dialog, and unless there is a need to
change it, the URI SHOULD be the same as used in previous
requests within the dialog. If the "secure" flag is true, that
URI MUST be a SIPS URI.
16.6 bullet 4 describes Record Route processing for SIPS URIs by
proxies:
If the Request-URI contains a SIPS URI, or the topmost Route
header field value [...] contains a SIPS URI, the URI placed
into the Record-Route header field MUST be a SIPS URI.
Furthermore, if the request was not received over TLS, the
proxy MUST insert a Record-Route header field. In a similar
fashion, a proxy that receives a request over TLS, but
generates a request without a SIPS URI in the Request-URI or
topmost Route header field value [...], MUST insert a Record-
Route header field that is not a SIPS URI.
16.7 describes proxy response forwarding:
If the proxy received the request over TLS, and sent it outover
a non-TLS connection, the proxy MUST rewrite the URI in the
Record-Route header field to be a SIPS URI. If the proxy
received the request over a non-TLS connection, and sent it
outover TLS, the proxy MUST rewrite the URI in the Record-Route
header field to be a SIP URI.
19.1 describes the SIP and SIPS URI in general. Of particular
importance is the following statement:
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. 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.
19.1.4 describes rules for URI comparisons. Of particular
importance is the following statement:
A SIP and SIPS URI are never equivalent.
20.42 describes indicating TLS transport in Via headers:
A Via header field value contains the transport protocol used
to send the message, [...] Transport protocols defined here
are "UDP", "TCP", "TLS", and "SCTP". "TLS" means TLS over TCP.
When a request is sent to a SIPS URI, the protocol still
indicates "SIP", and the transport protocol is TLS.
Audet Expires October 6, 2006 [Page 11]
Internet-Draft SIPS Guidelines April 2006
26.2.1 describes Transport Layer Security [2]. Of particular
importance is the following statement:
"tls" (signifying TLS over TCP) can be specified as the desired
transport protocol within a Via header field value or a SIP-
URI.
26.2.2 is very important and describes the SIPS URI scheme. Of
particular importance is the following statements:
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.
[...]
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.
Users that distribute a SIPS URI as an address-of-record may
elect to operate devices that refuse requests over insecure
transports.
26.4.4 describes the limitations in what to infer from using SIPS
URIs. Of particular importance are the the following important
statement:
Actually using TLS on every segment of a request path entails
that the terminating UAS must be reachable over TLS (perhaps
registering with a SIPS URI as a contact address). This is the
preferred use of SIPS. Many valid architectures, however, use
TLS to secure part of the request path, but rely on some other
mechanism for the final hop to a UAS, for example. Thus SIPS
cannot guarantee that TLS usage will be truly end-to-end. [...]
The reader should also be familiar with RFC 3263 [4] which describes
the use of DNS with SIPS schemes.
Finally, because in practical implementations, TLS will often be
implemented using client-initiated connections, the reader should be
familar with [8].
Audet Expires October 6, 2006 [Page 12]
Internet-Draft SIPS Guidelines April 2006
11. Security Considerations
There are no security considerations introduced by this document.
12. IANA Considerations
There are no IANA considerations.
13. IAB Considerations
There are no IAB considerations.
14. Acknowledgments
The author would like to thank John Elwell, Rifaat Shekh-Yusef,
Meenakshi Kaushik and Samir Srivastava for thier valuable comments.
15. References
15.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
15.2. Informational References
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[3] 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.
[4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[5] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[6] 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.
Audet Expires October 6, 2006 [Page 13]
Internet-Draft SIPS Guidelines April 2006
[7] 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.
[8] Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-03 (work in progress), March 2006.
[9] Gurbani, V. and A. Jeffrey, "The Use of Transport Layer
Security (TLS) in the Session Initiation Protocol (SIP)",
draft-gurbani-sip-tls-use-00 (work in progress), February 2006.
[10] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-06 (work in progress),
October 2005.
URIs
[11] <background>
[12] <upgrade>
Audet Expires October 6, 2006 [Page 14]
Internet-Draft SIPS Guidelines April 2006
Author's Address
Francois Audet
Nortel Networks
4655 Great America Parkway
Santa Clara, CA 95054
US
Phone: +1 408 495 3756
Email: audet@nortel.com
Audet Expires October 6, 2006 [Page 15]
Internet-Draft SIPS Guidelines April 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Audet Expires October 6, 2006 [Page 16]