SIP: Session Initiation Protocol
RFC 3261

RFC 3261            SIP: Session Initiation Protocol           June 2002

   o  SIP URL BNF was made more general, allowing a greater set of
      characters in the user part.  Furthermore, comparison rules were
      simplified to be primarily case-insensitive, and detailed handling
      of comparison in the presence of parameters was described.  The
      most substantial change is that a URI with a parameter with the
      default value does not match a URI without that parameter.

   o  Removed Via hiding.  It had serious trust issues, since it relied
      on the next hop to perform the obfuscation process.  Instead, Via
      hiding can be done as a local implementation choice in stateful
      proxies, and thus is no longer documented.

   o  In RFC 2543, CANCEL and INVITE transactions were intermingled.
      They are separated now.  When a user sends an INVITE and then a
      CANCEL, the INVITE transaction still terminates normally.  A UAS
      needs to respond to the original INVITE request with a 487
      response.

   o  Similarly, CANCEL and BYE transactions were intermingled; RFC 2543
      allowed the UAS not to send a response to INVITE when a BYE was
      received.  That is disallowed here.  The original INVITE needs a
      response.

   o  In RFC 2543, UAs needed to support only UDP.  In this RFC, UAs
      need to support both UDP and TCP.

   o  In RFC 2543, a forking proxy only passed up one challenge from
      downstream elements in the event of multiple challenges.  In this
      RFC, proxies are supposed to collect all challenges and place them
      into the forwarded response.

   o  In Digest credentials, the URI needs to be quoted; this is unclear
      from RFC 2617 and RFC 2069 which are both inconsistent on it.

   o  SDP processing has been split off into a separate specification
      [13], and more fully specified as a formal offer/answer exchange
      process that is effectively tunneled through SIP.  SDP is allowed
      in INVITE/200 or 200/ACK for baseline SIP implementations; RFC
      2543 alluded to the ability to use it in INVITE, 200, and ACK in a
      single transaction, but this was not well specified.  More complex
      SDP usages are allowed in extensions.

Rosenberg, et. al.          Standards Track                   [Page 256]
RFC 3261            SIP: Session Initiation Protocol           June 2002

   o  Added full support for IPv6 in URIs and in the Via header field.
      Support for IPv6 in Via has required that its header field
      parameters allow the square bracket and colon characters.  These
      characters were previously not permitted.  In theory, this could
      cause interop problems with older implementations.  However, we
      have observed that most implementations accept any non-control
      ASCII character in these parameters.

   o  DNS SRV procedure is now documented in a separate specification
      [4].  This procedure uses both SRV and NAPTR resource records and
      no longer combines data from across SRV records as described in
      RFC 2543.

   o  Loop detection has been made optional, supplanted by a mandatory
      usage of Max-Forwards.  The loop detection procedure in RFC 2543
      had a serious bug which would report "spirals" as an error
      condition when it was not.  The optional loop detection procedure
      is more fully and correctly specified here.

   o  Usage of tags is now mandatory (they were optional in RFC 2543),
      as they are now the fundamental building blocks of dialog
      identification.

   o  Added the Supported header field, allowing for clients to indicate
      what extensions are supported to a server, which can apply those
      extensions to the response, and indicate their usage with a
      Require in the response.

   o  Extension parameters were missing from the BNF for several header
      fields, and they have been added.

   o  Handling of Route and Record-Route construction was very
      underspecified in RFC 2543, and also not the right approach.  It
      has been substantially reworked in this specification (and made
      vastly simpler), and this is arguably the largest change.
      Backwards compatibility is still provided for deployments that do
      not use "pre-loaded routes", where the initial request has a set
      of Route header field values obtained in some way outside of
      Record-Route.  In those situations, the new mechanism is not
      interoperable.

   o  In RFC 2543, lines in a message could be terminated with CR, LF,
      or CRLF.  This specification only allows CRLF.

Rosenberg, et. al.          Standards Track                   [Page 257]
RFC 3261            SIP: Session Initiation Protocol           June 2002

   o  Usage of Route in CANCEL and ACK was not well defined in RFC 2543.
      It is now well specified; if a request had a Route header field,
      its CANCEL or ACK for a non-2xx response to the request need to
      carry the same Route header field values.  ACKs for 2xx responses
      use the Route values learned from the Record-Route of the 2xx
      responses.

   o  RFC 2543 allowed multiple requests in a single UDP packet.  This
      usage has been removed.

   o  Usage of absolute time in the Expires header field and parameter
      has been removed.  It caused interoperability problems in elements
      that were not time synchronized, a common occurrence.  Relative
      times are used instead.

   o  The branch parameter of the Via header field value is now
      mandatory for all elements to use.  It now plays the role of a
      unique transaction identifier.  This avoids the complex and bug-
      laden transaction identification rules from RFC 2543.  A magic
      cookie is used in the parameter value to determine if the previous
      hop has made the parameter globally unique, and comparison falls
      back to the old rules when it is not present.  Thus,
      interoperability is assured.

   o  In RFC 2543, closure of a TCP connection was made equivalent to a
      CANCEL.  This was nearly impossible to implement (and wrong) for
      TCP connections between proxies.  This has been eliminated, so
      that there is no coupling between TCP connection state and SIP
      processing.

   o  RFC 2543 was silent on whether a UA could initiate a new
      transaction to a peer while another was in progress.  That is now
      specified here.  It is allowed for non-INVITE requests, disallowed
      for INVITE.

   o  PGP was removed.  It was not sufficiently specified, and not
      compatible with the more complete PGP MIME.  It was replaced with
      S/MIME.

   o  Added the "sips" URI scheme for end-to-end TLS.  This scheme is
      not backwards compatible with RFC 2543.  Existing elements that
      receive a request with a SIPS URI scheme in the Request-URI will
      likely reject the request.  This is actually a feature; it ensures
      that a call to a SIPS URI is only delivered if all path hops can
      be secured.

Rosenberg, et. al.          Standards Track                   [Page 258]
RFC 3261            SIP: Session Initiation Protocol           June 2002

   o  Additional security features were added with TLS, and these are
      described in a much larger and complete security considerations
      section.

   o  In RFC 2543, a proxy was not required to forward provisional
      responses from 101 to 199 upstream.  This was changed to MUST.
      This is important, since many subsequent features depend on
      delivery of all provisional responses from 101 to 199.

   o  Little was said about the 503 response code in RFC 2543.  It has
      since found substantial use in indicating failure or overload
      conditions in proxies.  This requires somewhat special treatment.
      Specifically, receipt of a 503 should trigger an attempt to
      contact the next element in the result of a DNS SRV lookup.  Also,
      503 response is only forwarded upstream by a proxy under certain
      conditions.

   o  RFC 2543 defined, but did no sufficiently specify, a mechanism for
      UA authentication of a server.  That has been removed.  Instead,
      the mutual authentication procedures of RFC 2617 are allowed.

   o  A UA cannot send a BYE for a call until it has received an ACK for
      the initial INVITE.  This was allowed in RFC 2543 but leads to a
      potential race condition.

   o  A UA or proxy cannot send CANCEL for a transaction until it gets a
      provisional response for the request.  This was allowed in RFC
      2543 but leads to potential race conditions.

   o  The action parameter in registrations has been deprecated.  It was
      insufficient for any useful services, and caused conflicts when
      application processing was applied in proxies.

   o  RFC 2543 had a number of special cases for multicast.  For
      example, certain responses were suppressed, timers were adjusted,
      and so on.  Multicast now plays a more limited role, and the
      protocol operation is unaffected by usage of multicast as opposed
      to unicast.  The limitations as a result of that are documented.

   o  Basic authentication has been removed entirely and its usage
      forbidden.

Rosenberg, et. al.          Standards Track                   [Page 259]
RFC 3261            SIP: Session Initiation Protocol           June 2002

   o  Proxies no longer forward a 6xx immediately on receiving it.
      Instead, they CANCEL pending branches immediately.  This avoids a
      potential race condition that would result in a UAC getting a 6xx
      followed by a 2xx.  In all cases except this race condition, the
      result will be the same - the 6xx is forwarded upstream.

   o  RFC 2543 did not address the problem of request merging.  This
      occurs when a request forks at a proxy and later rejoins at an
      element.  Handling of merging is done only at a UA, and procedures
      are defined for rejecting all but the first request.

28.2 Minor Functional Changes

   o  Added the Alert-Info, Error-Info, and Call-Info header fields for
      optional content presentation to users.

   o  Added the Content-Language, Content-Disposition and MIME-Version
      header fields.

   o  Added a "glare handling" mechanism to deal with the case where
      both parties send each other a re-INVITE simultaneously.  It uses
      the new 491 (Request Pending) error code.

   o  Added the In-Reply-To and Reply-To header fields for supporting
      the return of missed calls or messages at a later time.

   o  Added TLS and SCTP as valid SIP transports.

   o  There were a variety of mechanisms described for handling failures
      at any time during a call; those are now generally unified.  BYE
      is sent to terminate.

   o  RFC 2543 mandated retransmission of INVITE responses over TCP, but
      noted it was really only needed for 2xx.  That was an artifact of
      insufficient protocol layering.  With a more coherent transaction
      layer defined here, that is no longer needed.  Only 2xx responses
      to INVITEs are retransmitted over TCP.

   o  Client and server transaction machines are now driven based on
      timeouts rather than retransmit counts.  This allows the state
      machines to be properly specified for TCP and UDP.

   o  The Date header field is used in REGISTER responses to provide a
      simple means for auto-configuration of dates in user agents.

   o  Allowed a registrar to reject registrations with expirations that
      are too short in duration.  Defined the 423 response code and the
      Min-Expires for this purpose.

Rosenberg, et. al.          Standards Track                   [Page 260]
RFC 3261            SIP: Session Initiation Protocol           June 2002

29 Normative References

   [1]  Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.

   [4]  Rosenberg, J. and H. Schulzrinne, "SIP: Locating SIP Servers",
        RFC 3263, June 2002.

   [5]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

   [6]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
        Transport Layer Security (TLS)", RFC 3268, June 2002.

   [7]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
        2279, January 1998.

   [8]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
        HTTP/1.1", RFC 2616, June 1999.

   [9]  Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
        2000.

   [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [11] Freed, F. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part Two: Media Types", RFC 2046, November
        1996.

   [12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
        Recommendations for Security", RFC 1750, December 1994.

   [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
        SDP", RFC 3264, June 2002.

   [14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
        1980.

   [15] Postel, J., "DoD Standard Transmission Control Protocol", RFC
        761, January 1980.

Rosenberg, et. al.          Standards Track                   [Page 261]
RFC 3261            SIP: Session Initiation Protocol           June 2002

   [16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
        H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
        "Stream Control Transmission Protocol", RFC 2960, October 2000.

   [17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
        Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication:
        Basic and Digest Access Authentication", RFC 2617, June 1999.

   [18] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
        Information in Internet Messages: The Content-Disposition Header
        Field", RFC 2183, August 1997.

   [19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
        Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG
        Objects", RFC 3204, December 2001.

   [20] Braden, R., "Requirements for Internet Hosts - Application and
        Support", STD 3, RFC 1123, October 1989.

   [21] Alvestrand, H., "IETF Policy on Character Sets and Languages",
        BCP 18, RFC 2277, January 1998.

   [22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
        Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
        RFC 1847, October 1995.

   [23] Housley, R., "Cryptographic Message Syntax", RFC 2630, June
        1999.

   [24] Ramsdell B., "S/MIME Version 3 Message Specification", RFC 2633,
        June 1999.

   [25] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
        2246, January 1999.

   [26] Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

30 Informative References

   [27] R. Pandya, "Emerging mobile and personal communication systems,"
        IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995.

   [28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
        "RTP:  A Transport Protocol for Real-Time Applications", RFC
        1889, January 1996.

Rosenberg, et. al.          Standards Track                   [Page 262]
RFC 3261            SIP: Session Initiation Protocol           June 2002

   [29] Schulzrinne, H., Rao, R. and R. Lanphier, "Real Time Streaming
        Protocol (RTSP)", RFC 2326, April 1998.

   [30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and
        J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November
        2000.

   [31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
        "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   [32] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL
        scheme", RFC 2368, July 1998.

   [33] E. M. Schooler, "A multicast user directory service for
        synchronous rendezvous," Master's Thesis CS-TR-96-18, Department
        of Computer Science, California Institute of Technology,
        Pasadena, California, Aug. 1996.

   [34] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.

   [35] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
        1992.

   [36] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC
        2426, September 1998.

   [37] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical
        Specification", RFC 2849, June 2000.

   [38] Palme, J., "Common Internet Message Headers",  RFC 2076,
        February 1997.

   [39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
        Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:
        Digest Access Authentication", RFC 2069, January 1997.

   [40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis,
        D., Rosenberg, J., Summers, K. and H. Schulzrinne, "SIP Call
        Flow Examples", Work in Progress.

   [41] E. M. Schooler, "Case study: multimedia conference control in a
        packet-switched teleconferencing system," Journal of
        Internetworking:  Research and Experience, Vol. 4, pp. 99--120,
        June 1993.  ISI reprint series ISI/RS-93-359.

Rosenberg, et. al.          Standards Track                   [Page 263]
RFC 3261            SIP: Session Initiation Protocol           June 2002

   [42] H. Schulzrinne, "Personal mobility for multimedia services in
        the Internet," in European Workshop on Interactive Distributed
        Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar.
        1996.

   [43] Floyd, S., "Congestion Control Principles", RFC 2914, September
        2000.

Rosenberg, et. al.          Standards Track                   [Page 264]
RFC 3261            SIP: Session Initiation Protocol           June 2002

A Table of Timer Values

   Table 4 summarizes the meaning and defaults of the various timers
   used by this specification.

Timer    Value            Section               Meaning
----------------------------------------------------------------------
T1       500ms default    Section 17.1.1.1     RTT Estimate
T2       4s               Section 17.1.2.2     The maximum retransmit
                                               interval for non-INVITE
                                               requests and INVITE
                                               responses
T4       5s               Section 17.1.2.2     Maximum duration a
                                               message will
                                               remain in the network
Timer A  initially T1     Section 17.1.1.2     INVITE request retransmit
                                               interval, for UDP only
Timer B  64*T1            Section 17.1.1.2     INVITE transaction
                                               timeout timer
Timer C  > 3min           Section 16.6         proxy INVITE transaction
                           bullet 11            timeout
Timer D  > 32s for UDP    Section 17.1.1.2     Wait time for response
         0s for TCP/SCTP                       retransmits
Timer E  initially T1     Section 17.1.2.2     non-INVITE request
                                               retransmit interval,
                                               UDP only
Timer F  64*T1            Section 17.1.2.2     non-INVITE transaction
                                               timeout timer
Timer G  initially T1     Section 17.2.1       INVITE response
                                               retransmit interval
Timer H  64*T1            Section 17.2.1       Wait time for
                                               ACK receipt
Timer I  T4 for UDP       Section 17.2.1       Wait time for
         0s for TCP/SCTP                       ACK retransmits
Timer J  64*T1 for UDP    Section 17.2.2       Wait time for
         0s for TCP/SCTP                       non-INVITE request
                                               retransmits
Timer K  T4 for UDP       Section 17.1.2.2     Wait time for
         0s for TCP/SCTP                       response retransmits

                   Table 4: Summary of timers

Rosenberg, et. al.          Standards Track                   [Page 265]
RFC 3261            SIP: Session Initiation Protocol           June 2002

Acknowledgments

   We wish to thank the members of the IETF MMUSIC and SIP WGs for their
   comments and suggestions.  Detailed comments were provided by Ofir
   Arkin, Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan,
   Keith Drage, Bill Fenner, Cedric Fluckiger, Yaron Goland, John
   Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema,
   Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders
   Kristensen, Jonathan Lennox, Gethin Liddell, Allison Mankin, William
   Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe
   J. Sambol, Chip Sharp, Igor Slepchin, Eric Tremblay, and Rick
   Workman.

   Brian Rosen provided the compiled BNF.

   Jean Mahoney provided technical writing assistance.

   This work is based, inter alia, on [41,42].

Rosenberg, et. al.          Standards Track                   [Page 266]
RFC 3261            SIP: Session Initiation Protocol           June 2002

Authors' Addresses

   Authors addresses are listed alphabetically for the editors, the
   writers, and then the original authors of RFC 2543.  All listed
   authors actively contributed large amounts of text to this document.

   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Ave
   East Hanover, NJ 07936
   USA

   EMail:  jdrosen@dynamicsoft.com

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue
   New York, NY 10027
   USA

   EMail:  schulzrinne@cs.columbia.edu

   Gonzalo Camarillo
   Ericsson
   Advanced Signalling Research Lab.
   FIN-02420 Jorvas
   Finland

   EMail:  Gonzalo.Camarillo@ericsson.com

   Alan Johnston
   WorldCom
   100 South 4th Street
   St. Louis, MO 63102
   USA

   EMail:  alan.johnston@wcom.com

Rosenberg, et. al.          Standards Track                   [Page 267]
RFC 3261            SIP: Session Initiation Protocol           June 2002

   Jon Peterson
   NeuStar, Inc
   1800 Sutter Street, Suite 570
   Concord, CA 94520
   USA

   EMail:  jon.peterson@neustar.com

   Robert Sparks
   dynamicsoft, Inc.
   5100 Tennyson Parkway
   Suite 1200
   Plano, Texas 75024
   USA

   EMail:  rsparks@dynamicsoft.com

   Mark Handley
   International Computer Science Institute
   1947 Center St, Suite 600
   Berkeley, CA 94704
   USA

   EMail:  mjh@icir.org

   Eve Schooler
   AT&T Labs-Research
   75 Willow Road
   Menlo Park, CA 94025
   USA

   EMail: schooler@research.att.com

Rosenberg, et. al.          Standards Track                   [Page 268]
RFC 3261            SIP: Session Initiation Protocol           June 2002

Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Rosenberg, et. al.          Standards Track                   [Page 269]