Skip to main content

The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
RFC 5630

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>, 
    sip mailing list <>, 
    sip chair <>
Subject: Protocol Action: 'The use of the SIPS URI Scheme in the 
         Session Initiation Protocol (SIP)' to Proposed Standard 

The IESG has approved the following document:

- 'The use of the SIPS URI Scheme in the Session Initiation Protocol 
   (SIP) '
   <draft-ietf-sip-sips-09.txt> as a Proposed Standard

This document is the product of the Session Initiation Protocol Working 

The IESG contact persons are Cullen Jennings and Jon Peterson.

A URL of this Internet-Draft is:

Ballot Text

Technical Summary:

This document updates RFC 3261 to provide clarifications and
guidelines concerning the use of the SIPS URI scheme in the Session
Initiation Protocol (SIP).  This document also provides a discussion
of possible future steps in specification.

The SIPS URI scheme was originally documented in RFC 3261, but
experience has shown that the specification therein is incomplete, and
that at least one use case that increased the complexity of the
specification (the "last hop exception") can be eliminated.

Several possible error conditions relating to mismatch of sips vs. sip
on sending and receiving ends exist. This documents adds new SIP error
codes to provide for the detection and correction of these error

Working Group Summary:

There were several topics of significance that are worth noting.

The foremost is the deprecation of the "last hop exception" from RFC
3261. This exception allowed a proxy/registrar supporting SIPS to
relay requests received using SIPS on to user agent servers that did
not indicate support for SIPS. This increases the complexity of
implementations and weakens the end-to-end assurance of signaling
security provided by SIPS. After extensive debate, the working group
resolved to eliminate this exception and make SIPS fully
end-to-end. Doing so required extensive discussion and annotation on
what "end to end" means in the context of gateways to non-SIP

Detection and correction of error conditions resulting where a UAC has
specified a SIPS request and the terminating UAS has not registered a
SIP contact, or where the UAC has specified a SIP request and the
terminating UAS has registered only a SIP contact was another problem
requiring extensive discussion. The "obvious" approach of using 400
class responses created problems when interacting with forking
proxies. The WG concluded on using two new 300-class SIP response
codes to enable request resolution in these scenarios.

During the process of developing this specification, the working group
began to converge on a new process for incrementally updating RFC
3261. As a precursor to this process, this specification contains an
appendix that provides explicit in-context changes to RFC 3261 as
required by this specification. The intent here is to reduce the
complexity of discussions at interoperability events.

Document Quality
There are several notable implementations of the specification at
varying levels of maturity. The SIPIt interop events have included
SIPS for some time, and the changes in this specification were in-part
driven by experiences at those interop events.

The document' Acknowledgements section cites numerous active
participants for providing detailed review.

RFC Editor Note