MCL/sf/mw/qt: comparison tests/auto/qtextstream/rfc3261.txt

equal deleted inserted replaced

--1:000000000000
+:1918ee327afb
+Network Working Group                                       J. Rosenberg
+Request for Comments: 3261                                   dynamicsoft
+Obsoletes: 2543                                           H. Schulzrinne
+Category: Standards Track                                    Columbia U.
+G. Camarillo
+Ericsson
+A. Johnston
+WorldCom
+J. Peterson
+Neustar
+R. Sparks
+dynamicsoft
+M. Handley
+ICIR
+E. Schooler
+AT&T
+June 2002
+SIP: Session Initiation Protocol
+Status of this Memo
+This document specifies an Internet standards track protocol for the
+Internet community, and requests discussion and suggestions for
+improvements.  Please refer to the current edition of the "Internet
+Official Protocol Standards" (STD 1) for the standardization state
+and status of this protocol.  Distribution of this memo is unlimited.
+Copyright Notice
+Copyright (C) The Internet Society (2002).  All Rights Reserved.
+Abstract
+This document describes Session Initiation Protocol (SIP), an
+application-layer control (signaling) protocol for creating,
+modifying, and terminating sessions with one or more participants.
+These sessions include Internet telephone calls, multimedia
+distribution, and multimedia conferences.
+SIP invitations used to create sessions carry session descriptions
+that allow participants to agree on a set of compatible media types.
+SIP makes use of elements called proxy servers to help route requests
+to the user's current location, authenticate and authorize users for
+services, implement provider call-routing policies, and provide
+features to users.  SIP also provides a registration function that
+allows users to upload their current locations for use by proxy
+servers.  SIP runs on top of several different transport protocols.
+Rosenberg, et. al.          Standards Track                     [Page 1]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Table of Contents
+1          Introduction ........................................    8
+2          Overview of SIP Functionality .......................    9
+3          Terminology .........................................   10
+4          Overview of Operation ...............................   10
+5          Structure of the Protocol ...........................   18
+6          Definitions .........................................   20
+7          SIP Messages ........................................   26
+7.1        Requests ............................................   27
+7.2        Responses ...........................................   28
+7.3        Header Fields .......................................   29
+7.3.1      Header Field Format .................................   30
+7.3.2      Header Field Classification .........................   32
+7.3.3      Compact Form ........................................   32
+7.4        Bodies ..............................................   33
+7.4.1      Message Body Type ...................................   33
+7.4.2      Message Body Length .................................   33
+7.5        Framing SIP Messages ................................   34
+8          General User Agent Behavior .........................   34
+8.1        UAC Behavior ........................................   35
+8.1.1      Generating the Request ..............................   35
+8.1.1.1    Request-URI .........................................   35
+8.1.1.2    To ..................................................   36
+8.1.1.3    From ................................................   37
+8.1.1.4    Call-ID .............................................   37
+8.1.1.5    CSeq ................................................   38
+8.1.1.6    Max-Forwards ........................................   38
+8.1.1.7    Via .................................................   39
+8.1.1.8    Contact .............................................   40
+8.1.1.9    Supported and Require ...............................   40
+8.1.1.10   Additional Message Components .......................   41
+8.1.2      Sending the Request .................................   41
+8.1.3      Processing Responses ................................   42
+8.1.3.1    Transaction Layer Errors ............................   42
+8.1.3.2    Unrecognized Responses ..............................   42
+8.1.3.3    Vias ................................................   43
+8.1.3.4    Processing 3xx Responses ............................   43
+8.1.3.5    Processing 4xx Responses ............................   45
+8.2        UAS Behavior ........................................   46
+8.2.1      Method Inspection ...................................   46
+8.2.2      Header Inspection ...................................   46
+8.2.2.1    To and Request-URI ..................................   46
+8.2.2.2    Merged Requests .....................................   47
+8.2.2.3    Require .............................................   47
+8.2.3      Content Processing ..................................   48
+8.2.4      Applying Extensions .................................   49
+8.2.5      Processing the Request ..............................   49
+Rosenberg, et. al.          Standards Track                     [Page 2]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+8.2.6      Generating the Response .............................   49
+8.2.6.1    Sending a Provisional Response ......................   49
+8.2.6.2    Headers and Tags ....................................   50
+8.2.7      Stateless UAS Behavior ..............................   50
+8.3        Redirect Servers ....................................   51
+9          Canceling a Request .................................   53
+9.1        Client Behavior .....................................   53
+9.2        Server Behavior .....................................   55
+10         Registrations .......................................   56
+10.1       Overview ............................................   56
+10.2       Constructing the REGISTER Request ...................   57
+10.2.1     Adding Bindings .....................................   59
+10.2.1.1   Setting the Expiration Interval of Contact Addresses    60
+10.2.1.2   Preferences among Contact Addresses .................   61
+10.2.2     Removing Bindings ...................................   61
+10.2.3     Fetching Bindings ...................................   61
+10.2.4     Refreshing Bindings .................................   61
+10.2.5     Setting the Internal Clock ..........................   62
+10.2.6     Discovering a Registrar .............................   62
+10.2.7     Transmitting a Request ..............................   62
+10.2.8     Error Responses .....................................   63
+10.3       Processing REGISTER Requests ........................   63
+11         Querying for Capabilities ...........................   66
+11.1       Construction of OPTIONS Request .....................   67
+11.2       Processing of OPTIONS Request .......................   68
+12         Dialogs .............................................   69
+12.1       Creation of a Dialog ................................   70
+12.1.1     UAS behavior ........................................   70
+12.1.2     UAC Behavior ........................................   71
+12.2       Requests within a Dialog ............................   72
+12.2.1     UAC Behavior ........................................   73
+12.2.1.1   Generating the Request ..............................   73
+12.2.1.2   Processing the Responses ............................   75
+12.2.2     UAS Behavior ........................................   76
+12.3       Termination of a Dialog .............................   77
+13         Initiating a Session ................................   77
+13.1       Overview ............................................   77
+13.2       UAC Processing ......................................   78
+13.2.1     Creating the Initial INVITE .........................   78
+13.2.2     Processing INVITE Responses .........................   81
+13.2.2.1   1xx Responses .......................................   81
+13.2.2.2   3xx Responses .......................................   81
+13.2.2.3   4xx, 5xx and 6xx Responses ..........................   81
+13.2.2.4   2xx Responses .......................................   82
+13.3       UAS Processing ......................................   83
+13.3.1     Processing of the INVITE ............................   83
+13.3.1.1   Progress ............................................   84
+13.3.1.2   The INVITE is Redirected ............................   84
+Rosenberg, et. al.          Standards Track                     [Page 3]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+13.3.1.3   The INVITE is Rejected ..............................   85
+13.3.1.4   The INVITE is Accepted ..............................   85
+14         Modifying an Existing Session .......................   86
+14.1       UAC Behavior ........................................   86
+14.2       UAS Behavior ........................................   88
+15         Terminating a Session ...............................   89
+15.1       Terminating a Session with a BYE Request ............   90
+15.1.1     UAC Behavior ........................................   90
+15.1.2     UAS Behavior ........................................   91
+16         Proxy Behavior ......................................   91
+16.1       Overview ............................................   91
+16.2       Stateful Proxy ......................................   92
+16.3       Request Validation ..................................   94
+16.4       Route Information Preprocessing .....................   96
+16.5       Determining Request Targets .........................   97
+16.6       Request Forwarding ..................................   99
+16.7       Response Processing .................................  107
+16.8       Processing Timer C ..................................  114
+16.9       Handling Transport Errors ...........................  115
+16.10      CANCEL Processing ...................................  115
+16.11      Stateless Proxy .....................................  116
+16.12      Summary of Proxy Route Processing ...................  118
+16.12.1    Examples ............................................  118
+16.12.1.1  Basic SIP Trapezoid .................................  118
+16.12.1.2  Traversing a Strict-Routing Proxy ...................  120
+16.12.1.3  Rewriting Record-Route Header Field Values ..........  121
+17         Transactions ........................................  122
+17.1       Client Transaction ..................................  124
+17.1.1     INVITE Client Transaction ...........................  125
+17.1.1.1   Overview of INVITE Transaction ......................  125
+17.1.1.2   Formal Description ..................................  125
+17.1.1.3   Construction of the ACK Request .....................  129
+17.1.2     Non-INVITE Client Transaction .......................  130
+17.1.2.1   Overview of the non-INVITE Transaction ..............  130
+17.1.2.2   Formal Description ..................................  131
+17.1.3     Matching Responses to Client Transactions ...........  132
+17.1.4     Handling Transport Errors ...........................  133
+17.2       Server Transaction ..................................  134
+17.2.1     INVITE Server Transaction ...........................  134
+17.2.2     Non-INVITE Server Transaction .......................  137
+17.2.3     Matching Requests to Server Transactions ............  138
+17.2.4     Handling Transport Errors ...........................  141
+18         Transport ...........................................  141
+18.1       Clients .............................................  142
+18.1.1     Sending Requests ....................................  142
+18.1.2     Receiving Responses .................................  144
+18.2       Servers .............................................  145
+18.2.1     Receiving Requests ..................................  145
+Rosenberg, et. al.          Standards Track                     [Page 4]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+18.2.2     Sending Responses ...................................  146
+18.3       Framing .............................................  147
+18.4       Error Handling ......................................  147
+19         Common Message Components ...........................  147
+19.1       SIP and SIPS Uniform Resource Indicators ............  148
+19.1.1     SIP and SIPS URI Components .........................  148
+19.1.2     Character Escaping Requirements .....................  152
+19.1.3     Example SIP and SIPS URIs ...........................  153
+19.1.4     URI Comparison ......................................  153
+19.1.5     Forming Requests from a URI .........................  156
+19.1.6     Relating SIP URIs and tel URLs ......................  157
+19.2       Option Tags .........................................  158
+19.3       Tags ................................................  159
+20         Header Fields .......................................  159
+20.1       Accept ..............................................  161
+20.2       Accept-Encoding .....................................  163
+20.3       Accept-Language .....................................  164
+20.4       Alert-Info ..........................................  164
+20.5       Allow ...............................................  165
+20.6       Authentication-Info .................................  165
+20.7       Authorization .......................................  165
+20.8       Call-ID .............................................  166
+20.9       Call-Info ...........................................  166
+20.10      Contact .............................................  167
+20.11      Content-Disposition .................................  168
+20.12      Content-Encoding ....................................  169
+20.13      Content-Language ....................................  169
+20.14      Content-Length ......................................  169
+20.15      Content-Type ........................................  170
+20.16      CSeq ................................................  170
+20.17      Date ................................................  170
+20.18      Error-Info ..........................................  171
+20.19      Expires .............................................  171
+20.20      From ................................................  172
+20.21      In-Reply-To .........................................  172
+20.22      Max-Forwards ........................................  173
+20.23      Min-Expires .........................................  173
+20.24      MIME-Version ........................................  173
+20.25      Organization ........................................  174
+20.26      Priority ............................................  174
+20.27      Proxy-Authenticate ..................................  174
+20.28      Proxy-Authorization .................................  175
+20.29      Proxy-Require .......................................  175
+20.30      Record-Route ........................................  175
+20.31      Reply-To ............................................  176
+20.32      Require .............................................  176
+20.33      Retry-After .........................................  176
+20.34      Route ...............................................  177
+Rosenberg, et. al.          Standards Track                     [Page 5]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+20.35      Server ..............................................  177
+20.36      Subject .............................................  177
+20.37      Supported ...........................................  178
+20.38      Timestamp ...........................................  178
+20.39      To ..................................................  178
+20.40      Unsupported .........................................  179
+20.41      User-Agent ..........................................  179
+20.42      Via .................................................  179
+20.43      Warning .............................................  180
+20.44      WWW-Authenticate ....................................  182
+21         Response Codes ......................................  182
+21.1       Provisional 1xx .....................................  182
+21.1.1     100 Trying ..........................................  183
+21.1.2     180 Ringing .........................................  183
+21.1.3     181 Call Is Being Forwarded .........................  183
+21.1.4     182 Queued ..........................................  183
+21.1.5     183 Session Progress ................................  183
+21.2       Successful 2xx ......................................  183
+21.2.1     200 OK ..............................................  183
+21.3       Redirection 3xx .....................................  184
+21.3.1     300 Multiple Choices ................................  184
+21.3.2     301 Moved Permanently ...............................  184
+21.3.3     302 Moved Temporarily ...............................  184
+21.3.4     305 Use Proxy .......................................  185
+21.3.5     380 Alternative Service .............................  185
+21.4       Request Failure 4xx .................................  185
+21.4.1     400 Bad Request .....................................  185
+21.4.2     401 Unauthorized ....................................  185
+21.4.3     402 Payment Required ................................  186
+21.4.4     403 Forbidden .......................................  186
+21.4.5     404 Not Found .......................................  186
+21.4.6     405 Method Not Allowed ..............................  186
+21.4.7     406 Not Acceptable ..................................  186
+21.4.8     407 Proxy Authentication Required ...................  186
+21.4.9     408 Request Timeout .................................  186
+21.4.10    410 Gone ............................................  187
+21.4.11    413 Request Entity Too Large ........................  187
+21.4.12    414 Request-URI Too Long ............................  187
+21.4.13    415 Unsupported Media Type ..........................  187
+21.4.14    416 Unsupported URI Scheme ..........................  187
+21.4.15    420 Bad Extension ...................................  187
+21.4.16    421 Extension Required ..............................  188
+21.4.17    423 Interval Too Brief ..............................  188
+21.4.18    480 Temporarily Unavailable .........................  188
+21.4.19    481 Call/Transaction Does Not Exist .................  188
+21.4.20    482 Loop Detected ...................................  188
+21.4.21    483 Too Many Hops ...................................  189
+21.4.22    484 Address Incomplete ..............................  189
+Rosenberg, et. al.          Standards Track                     [Page 6]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+21.4.23    485 Ambiguous .......................................  189
+21.4.24    486 Busy Here .......................................  189
+21.4.25    487 Request Terminated ..............................  190
+21.4.26    488 Not Acceptable Here .............................  190
+21.4.27    491 Request Pending .................................  190
+21.4.28    493 Undecipherable ..................................  190
+21.5       Server Failure 5xx ..................................  190
+21.5.1     500 Server Internal Error ...........................  190
+21.5.2     501 Not Implemented .................................  191
+21.5.3     502 Bad Gateway .....................................  191
+21.5.4     503 Service Unavailable .............................  191
+21.5.5     504 Server Time-out .................................  191
+21.5.6     505 Version Not Supported ...........................  192
+21.5.7     513 Message Too Large ...............................  192
+21.6       Global Failures 6xx .................................  192
+21.6.1     600 Busy Everywhere .................................  192
+21.6.2     603 Decline .........................................  192
+21.6.3     604 Does Not Exist Anywhere .........................  192
+21.6.4     606 Not Acceptable ..................................  192
+22         Usage of HTTP Authentication ........................  193
+22.1       Framework ...........................................  193
+22.2       User-to-User Authentication .........................  195
+22.3       Proxy-to-User Authentication ........................  197
+22.4       The Digest Authentication Scheme ....................  199
+23         S/MIME ..............................................  201
+23.1       S/MIME Certificates .................................  201
+23.2       S/MIME Key Exchange .................................  202
+23.3       Securing MIME bodies ................................  205
+23.4       SIP Header Privacy and Integrity using S/MIME:
+Tunneling SIP .......................................  207
+23.4.1     Integrity and Confidentiality Properties of SIP
+Headers .............................................  207
+23.4.1.1   Integrity ...........................................  207
+23.4.1.2   Confidentiality .....................................  208
+23.4.2     Tunneling Integrity and Authentication ..............  209
+23.4.3     Tunneling Encryption ................................  211
+24         Examples ............................................  213
+24.1       Registration ........................................  213
+24.2       Session Setup .......................................  214
+25         Augmented BNF for the SIP Protocol ..................  219
+25.1       Basic Rules .........................................  219
+26         Security Considerations: Threat Model and Security
+Usage Recommendations ...............................  232
+26.1       Attacks and Threat Models ...........................  233
+26.1.1     Registration Hijacking ..............................  233
+26.1.2     Impersonating a Server ..............................  234
+26.1.3     Tampering with Message Bodies .......................  235
+26.1.4     Tearing Down Sessions ...............................  235
+Rosenberg, et. al.          Standards Track                     [Page 7]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+26.1.5     Denial of Service and Amplification .................  236
+26.2       Security Mechanisms .................................  237
+26.2.1     Transport and Network Layer Security ................  238
+26.2.2     SIPS URI Scheme .....................................  239
+26.2.3     HTTP Authentication .................................  240
+26.2.4     S/MIME ..............................................  240
+26.3       Implementing Security Mechanisms ....................  241
+26.3.1     Requirements for Implementers of SIP ................  241
+26.3.2     Security Solutions ..................................  242
+26.3.2.1   Registration ........................................  242
+26.3.2.2   Interdomain Requests ................................  243
+26.3.2.3   Peer-to-Peer Requests ...............................  245
+26.3.2.4   DoS Protection ......................................  246
+26.4       Limitations .........................................  247
+26.4.1     HTTP Digest .........................................  247
+26.4.2     S/MIME ..............................................  248
+26.4.3     TLS .................................................  249
+26.4.4     SIPS URIs ...........................................  249
+26.5       Privacy .............................................  251
+27         IANA Considerations .................................  252
+27.1       Option Tags .........................................  252
+27.2       Warn-Codes ..........................................  252
+27.3       Header Field Names ..................................  253
+27.4       Method and Response Codes ...........................  253
+27.5       The "message/sip" MIME type.  .......................  254
+27.6       New Content-Disposition Parameter Registrations .....  255
+28         Changes From RFC 2543 ...............................  255
+28.1       Major Functional Changes ............................  255
+28.2       Minor Functional Changes ............................  260
+29         Normative References ................................  261
+30         Informative References ..............................  262
+A          Table of Timer Values ...............................  265
+Acknowledgments ................................................  266
+Authors' Addresses .............................................  267
+Full Copyright Statement .......................................  269
+1 Introduction
+There are many applications of the Internet that require the creation
+and management of a session, where a session is considered an
+exchange of data between an association of participants.  The
+implementation of these applications is complicated by the practices
+of participants: users may move between endpoints, they may be
+addressable by multiple names, and they may communicate in several
+different media - sometimes simultaneously.  Numerous protocols have
+been authored that carry various forms of real-time multimedia
+session data such as voice, video, or text messages.  The Session
+Initiation Protocol (SIP) works in concert with these protocols by
+Rosenberg, et. al.          Standards Track                     [Page 8]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+enabling Internet endpoints (called user agents) to discover one
+another and to agree on a characterization of a session they would
+like to share.  For locating prospective session participants, and
+for other functions, SIP enables the creation of an infrastructure of
+network hosts (called proxy servers) to which user agents can send
+registrations, invitations to sessions, and other requests.  SIP is
+an agile, general-purpose tool for creating, modifying, and
+terminating sessions that works independently of underlying transport
+protocols and without dependency on the type of session that is being
+established.
+2 Overview of SIP Functionality
+SIP is an application-layer control protocol that can establish,
+modify, and terminate multimedia sessions (conferences) such as
+Internet telephony calls.  SIP can also invite participants to
+already existing sessions, such as multicast conferences.  Media can
+be added to (and removed from) an existing session.  SIP
+transparently supports name mapping and redirection services, which
+supports personal mobility [27] - users can maintain a single
+externally visible identifier regardless of their network location.
+SIP supports five facets of establishing and terminating multimedia
+communications:
+User location: determination of the end system to be used for
+communication;
+User availability: determination of the willingness of the called
+party to engage in communications;
+User capabilities: determination of the media and media parameters
+to be used;
+Session setup: "ringing", establishment of session parameters at
+both called and calling party;
+Session management: including transfer and termination of
+sessions, modifying session parameters, and invoking
+services.
+SIP is not a vertically integrated communications system.  SIP is
+rather a component that can be used with other IETF protocols to
+build a complete multimedia architecture.  Typically, these
+architectures will include protocols such as the Real-time Transport
+Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and
+providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC
+2326 [29]) for controlling delivery of streaming media, the Media
+Rosenberg, et. al.          Standards Track                     [Page 9]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling
+gateways to the Public Switched Telephone Network (PSTN), and the
+Session Description Protocol (SDP) (RFC 2327 [1]) for describing
+multimedia sessions.  Therefore, SIP should be used in conjunction
+with other protocols in order to provide complete services to the
+users.  However, the basic functionality and operation of SIP does
+not depend on any of these protocols.
+SIP does not provide services.  Rather, SIP provides primitives that
+can be used to implement different services.  For example, SIP can
+locate a user and deliver an opaque object to his current location.
+If this primitive is used to deliver a session description written in
+SDP, for instance, the endpoints can agree on the parameters of a
+session.  If the same primitive is used to deliver a photo of the
+caller as well as the session description, a "caller ID" service can
+be easily implemented.  As this example shows, a single primitive is
+typically used to provide several different services.
+SIP does not offer conference control services such as floor control
+or voting and does not prescribe how a conference is to be managed.
+SIP can be used to initiate a session that uses some other conference
+control protocol.  Since SIP messages and the sessions they establish
+can pass through entirely different networks, SIP cannot, and does
+not, provide any kind of network resource reservation capabilities.
+The nature of the services provided make security particularly
+important.  To that end, SIP provides a suite of security services,
+which include denial-of-service prevention, authentication (both user
+to user and proxy to user), integrity protection, and encryption and
+privacy services.
+SIP works with both IPv4 and IPv6.
+3 Terminology
+In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
+RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
+described in BCP 14, RFC 2119 [2] and indicate requirement levels for
+compliant SIP implementations.
+4 Overview of Operation
+This section introduces the basic operations of SIP using simple
+examples.  This section is tutorial in nature and does not contain
+any normative statements.
+Rosenberg, et. al.          Standards Track                    [Page 10]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The first example shows the basic functions of SIP: location of an
+end point, signal of a desire to communicate, negotiation of session
+parameters to establish the session, and teardown of the session once
+established.
+Figure 1 shows a typical example of a SIP message exchange between
+two users, Alice and Bob.  (Each message is labeled with the letter
+"F" and a number for reference by the text.)  In this example, Alice
+uses a SIP application on her PC (referred to as a softphone) to call
+Bob on his SIP phone over the Internet.  Also shown are two SIP proxy
+servers that act on behalf of Alice and Bob to facilitate the session
+establishment.  This typical arrangement is often referred to as the
+"SIP trapezoid" as shown by the geometric shape of the dotted lines
+in Figure 1.
+Alice "calls" Bob using his SIP identity, a type of Uniform Resource
+Identifier (URI) called a SIP URI. SIP URIs are defined in Section
+19.1.  It has a similar form to an email address, typically
+containing a username and a host name.  In this case, it is
+sip:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP
+service provider.  Alice has a SIP URI of sip:alice@atlanta.com.
+Alice might have typed in Bob's URI or perhaps clicked on a hyperlink
+or an entry in an address book.  SIP also provides a secure URI,
+called a SIPS URI.  An example would be sips:bob@biloxi.com.  A call
+made to a SIPS URI guarantees that secure, encrypted transport
+(namely TLS) is used to carry all SIP messages from the caller to the
+domain of the callee.  From there, the request is sent securely to
+the callee, but with security mechanisms that depend on the policy of
+the domain of the callee.
+SIP is based on an HTTP-like request/response transaction model.
+Each transaction consists of a request that invokes a particular
+method, or function, on the server and at least one response.  In
+this example, the transaction begins with Alice's softphone sending
+an INVITE request addressed to Bob's SIP URI.  INVITE is an example
+of a SIP method that specifies the action that the requestor (Alice)
+wants the server (Bob) to take.  The INVITE request contains a number
+of header fields.  Header fields are named attributes that provide
+additional information about a message.  The ones present in an
+INVITE include a unique identifier for the call, the destination
+address, Alice's address, and information about the type of session
+that Alice wishes to establish with Bob.  The INVITE (message F1 in
+Figure 1) might look like this:
+Rosenberg, et. al.          Standards Track                    [Page 11]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+atlanta.com  . . . biloxi.com
+.      proxy              proxy     .
+.                                       .
+Alice's  . . . . . . . . . . . . . . . . . . . .  Bob's
+softphone                                        SIP Phone
+|                |                |                |
+|    INVITE F1   |                |                |
+|--------------->|    INVITE F2   |                |
+|  100 Trying F3 |--------------->|    INVITE F4   |
+|<---------------|  100 Trying F5 |--------------->|
+|                |<-------------- | 180 Ringing F6 |
+|                | 180 Ringing F7 |<---------------|
+| 180 Ringing F8 |<---------------|     200 OK F9  |
+|<---------------|    200 OK F10  |<---------------|
+|    200 OK F11  |<---------------|                |
+|<---------------|                |                |
+|                       ACK F12                    |
+|------------------------------------------------->|
+|                   Media Session                  |
+|<================================================>|
+|                       BYE F13                    |
+|<-------------------------------------------------|
+|                     200 OK F14                   |
+|------------------------------------------------->|
+|                                                  |
+Figure 1: SIP session setup example with SIP trapezoid
+INVITE sip:bob@biloxi.com SIP/2.0
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
+Max-Forwards: 70
+To: Bob <sip:bob@biloxi.com>
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710@pc33.atlanta.com
+CSeq: 314159 INVITE
+Contact: <sip:alice@pc33.atlanta.com>
+Content-Type: application/sdp
+Content-Length: 142
+(Alice's SDP not shown)
+The first line of the text-encoded message contains the method name
+(INVITE).  The lines that follow are a list of header fields.  This
+example contains a minimum required set.  The header fields are
+briefly described below:
+Rosenberg, et. al.          Standards Track                    [Page 12]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Via contains the address (pc33.atlanta.com) at which Alice is
+expecting to receive responses to this request.  It also contains a
+branch parameter that identifies this transaction.
+To contains a display name (Bob) and a SIP or SIPS URI
+(sip:bob@biloxi.com) towards which the request was originally
+directed.  Display names are described in RFC 2822 [3].
+From also contains a display name (Alice) and a SIP or SIPS URI
+(sip:alice@atlanta.com) that indicate the originator of the request.
+This header field also has a tag parameter containing a random string
+(1928301774) that was added to the URI by the softphone.  It is used
+for identification purposes.
+Call-ID contains a globally unique identifier for this call,
+generated by the combination of a random string and the softphone's
+host name or IP address.  The combination of the To tag, From tag,
+and Call-ID completely defines a peer-to-peer SIP relationship
+between Alice and Bob and is referred to as a dialog.
+CSeq or Command Sequence contains an integer and a method name.  The
+CSeq number is incremented for each new request within a dialog and
+is a traditional sequence number.
+Contact contains a SIP or SIPS URI that represents a direct route to
+contact Alice, usually composed of a username at a fully qualified
+domain name (FQDN).  While an FQDN is preferred, many end systems do
+not have registered domain names, so IP addresses are permitted.
+While the Via header field tells other elements where to send the
+response, the Contact header field tells other elements where to send
+future requests.
+Max-Forwards serves to limit the number of hops a request can make on
+the way to its destination.  It consists of an integer that is
+decremented by one at each hop.
+Content-Type contains a description of the message body (not shown).
+Content-Length contains an octet (byte) count of the message body.
+The complete set of SIP header fields is defined in Section 20.
+The details of the session, such as the type of media, codec, or
+sampling rate, are not described using SIP.  Rather, the body of a
+SIP message contains a description of the session, encoded in some
+other protocol format.  One such format is the Session Description
+Protocol (SDP) (RFC 2327 [1]).  This SDP message (not shown in the
+Rosenberg, et. al.          Standards Track                    [Page 13]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+example) is carried by the SIP message in a way that is analogous to
+a document attachment being carried by an email message, or a web
+page being carried in an HTTP message.
+Since the softphone does not know the location of Bob or the SIP
+server in the biloxi.com domain, the softphone sends the INVITE to
+the SIP server that serves Alice's domain, atlanta.com.  The address
+of the atlanta.com SIP server could have been configured in Alice's
+softphone, or it could have been discovered by DHCP, for example.
+The atlanta.com SIP server is a type of SIP server known as a proxy
+server.  A proxy server receives SIP requests and forwards them on
+behalf of the requestor.  In this example, the proxy server receives
+the INVITE request and sends a 100 (Trying) response back to Alice's
+softphone.  The 100 (Trying) response indicates that the INVITE has
+been received and that the proxy is working on her behalf to route
+the INVITE to the destination.  Responses in SIP use a three-digit
+code followed by a descriptive phrase.  This response contains the
+same To, From, Call-ID, CSeq and branch parameter in the Via as the
+INVITE, which allows Alice's softphone to correlate this response to
+the sent INVITE.  The atlanta.com proxy server locates the proxy
+server at biloxi.com, possibly by performing a particular type of DNS
+(Domain Name Service) lookup to find the SIP server that serves the
+biloxi.com domain.  This is described in [4].  As a result, it
+obtains the IP address of the biloxi.com proxy server and forwards,
+or proxies, the INVITE request there.  Before forwarding the request,
+the atlanta.com proxy server adds an additional Via header field
+value that contains its own address (the INVITE already contains
+Alice's address in the first Via).  The biloxi.com proxy server
+receives the INVITE and responds with a 100 (Trying) response back to
+the atlanta.com proxy server to indicate that it has received the
+INVITE and is processing the request.  The proxy server consults a
+database, generically called a location service, that contains the
+current IP address of Bob.  (We shall see in the next section how
+this database can be populated.)  The biloxi.com proxy server adds
+another Via header field value with its own address to the INVITE and
+proxies it to Bob's SIP phone.
+Bob's SIP phone receives the INVITE and alerts Bob to the incoming
+call from Alice so that Bob can decide whether to answer the call,
+that is, Bob's phone rings.  Bob's SIP phone indicates this in a 180
+(Ringing) response, which is routed back through the two proxies in
+the reverse direction.  Each proxy uses the Via header field to
+determine where to send the response and removes its own address from
+the top.  As a result, although DNS and location service lookups were
+required to route the initial INVITE, the 180 (Ringing) response can
+be returned to the caller without lookups or without state being
+Rosenberg, et. al.          Standards Track                    [Page 14]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+maintained in the proxies.  This also has the desirable property that
+each proxy that sees the INVITE will also see all responses to the
+INVITE.
+When Alice's softphone receives the 180 (Ringing) response, it passes
+this information to Alice, perhaps using an audio ringback tone or by
+displaying a message on Alice's screen.
+In this example, Bob decides to answer the call.  When he picks up
+the handset, his SIP phone sends a 200 (OK) response to indicate that
+the call has been answered.  The 200 (OK) contains a message body
+with the SDP media description of the type of session that Bob is
+willing to establish with Alice.  As a result, there is a two-phase
+exchange of SDP messages: Alice sent one to Bob, and Bob sent one
+back to Alice.  This two-phase exchange provides basic negotiation
+capabilities and is based on a simple offer/answer model of SDP
+exchange.  If Bob did not wish to answer the call or was busy on
+another call, an error response would have been sent instead of the
+200 (OK), which would have resulted in no media session being
+established.  The complete list of SIP response codes is in Section
+21.  The 200 (OK) (message F9 in Figure 1) might look like this as
+Bob sends it out:
+SIP/2.0 200 OK
+Via: SIP/2.0/UDP server10.biloxi.com
+;branch=z9hG4bKnashds8;received=192.0.2.3
+Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
+;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
+Via: SIP/2.0/UDP pc33.atlanta.com
+;branch=z9hG4bK776asdhds ;received=192.0.2.1
+To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710@pc33.atlanta.com
+CSeq: 314159 INVITE
+Contact: <sip:bob@192.0.2.4>
+Content-Type: application/sdp
+Content-Length: 131
+(Bob's SDP not shown)
+The first line of the response contains the response code (200) and
+the reason phrase (OK).  The remaining lines contain header fields.
+The Via, To, From, Call-ID, and CSeq header fields are copied from
+the INVITE request.  (There are three Via header field values - one
+added by Alice's SIP phone, one added by the atlanta.com proxy, and
+one added by the biloxi.com proxy.)  Bob's SIP phone has added a tag
+parameter to the To header field.  This tag will be incorporated by
+both endpoints into the dialog and will be included in all future
+Rosenberg, et. al.          Standards Track                    [Page 15]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+requests and responses in this call.  The Contact header field
+contains a URI at which Bob can be directly reached at his SIP phone.
+The Content-Type and Content-Length refer to the message body (not
+shown) that contains Bob's SDP media information.
+In addition to DNS and location service lookups shown in this
+example, proxy servers can make flexible "routing decisions" to
+decide where to send a request.  For example, if Bob's SIP phone
+returned a 486 (Busy Here) response, the biloxi.com proxy server
+could proxy the INVITE to Bob's voicemail server.  A proxy server can
+also send an INVITE to a number of locations at the same time.  This
+type of parallel search is known as forking.
+In this case, the 200 (OK) is routed back through the two proxies and
+is received by Alice's softphone, which then stops the ringback tone
+and indicates that the call has been answered.  Finally, Alice's
+softphone sends an acknowledgement message, ACK, to Bob's SIP phone
+to confirm the reception of the final response (200 (OK)).  In this
+example, the ACK is sent directly from Alice's softphone to Bob's SIP
+phone, bypassing the two proxies.  This occurs because the endpoints
+have learned each other's address from the Contact header fields
+through the INVITE/200 (OK) exchange, which was not known when the
+initial INVITE was sent.  The lookups performed by the two proxies
+are no longer needed, so the proxies drop out of the call flow.  This
+completes the INVITE/200/ACK three-way handshake used to establish
+SIP sessions.  Full details on session setup are in Section 13.
+Alice and Bob's media session has now begun, and they send media
+packets using the format to which they agreed in the exchange of SDP.
+In general, the end-to-end media packets take a different path from
+the SIP signaling messages.
+During the session, either Alice or Bob may decide to change the
+characteristics of the media session.  This is accomplished by
+sending a re-INVITE containing a new media description.  This re-
+INVITE references the existing dialog so that the other party knows
+that it is to modify an existing session instead of establishing a
+new session.  The other party sends a 200 (OK) to accept the change.
+The requestor responds to the 200 (OK) with an ACK.  If the other
+party does not accept the change, he sends an error response such as
+488 (Not Acceptable Here), which also receives an ACK.  However, the
+failure of the re-INVITE does not cause the existing call to fail -
+the session continues using the previously negotiated
+characteristics.  Full details on session modification are in Section
+14.
+Rosenberg, et. al.          Standards Track                    [Page 16]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+At the end of the call, Bob disconnects (hangs up) first and
+generates a BYE message.  This BYE is routed directly to Alice's
+softphone, again bypassing the proxies.  Alice confirms receipt of
+the BYE with a 200 (OK) response, which terminates the session and
+the BYE transaction.  No ACK is sent - an ACK is only sent in
+response to a response to an INVITE request.  The reasons for this
+special handling for INVITE will be discussed later, but relate to
+the reliability mechanisms in SIP, the length of time it can take for
+a ringing phone to be answered, and forking.  For this reason,
+request handling in SIP is often classified as either INVITE or non-
+INVITE, referring to all other methods besides INVITE.  Full details
+on session termination are in Section 15.
+Section 24.2 describes the messages shown in Figure 1 in full.
+In some cases, it may be useful for proxies in the SIP signaling path
+to see all the messaging between the endpoints for the duration of
+the session.  For example, if the biloxi.com proxy server wished to
+remain in the SIP messaging path beyond the initial INVITE, it would
+add to the INVITE a required routing header field known as Record-
+Route that contained a URI resolving to the hostname or IP address of
+the proxy.  This information would be received by both Bob's SIP
+phone and (due to the Record-Route header field being passed back in
+the 200 (OK)) Alice's softphone and stored for the duration of the
+dialog.  The biloxi.com proxy server would then receive and proxy the
+ACK, BYE, and 200 (OK) to the BYE.  Each proxy can independently
+decide to receive subsequent messages, and those messages will pass
+through all proxies that elect to receive it.  This capability is
+frequently used for proxies that are providing mid-call features.
+Registration is another common operation in SIP.  Registration is one
+way that the biloxi.com server can learn the current location of Bob.
+Upon initialization, and at periodic intervals, Bob's SIP phone sends
+REGISTER messages to a server in the biloxi.com domain known as a SIP
+registrar.  The REGISTER messages associate Bob's SIP or SIPS URI
+(sip:bob@biloxi.com) with the machine into which he is currently
+logged (conveyed as a SIP or SIPS URI in the Contact header field).
+The registrar writes this association, also called a binding, to a
+database, called the location service, where it can be used by the
+proxy in the biloxi.com domain.  Often, a registrar server for a
+domain is co-located with the proxy for that domain.  It is an
+important concept that the distinction between types of SIP servers
+is logical, not physical.
+Bob is not limited to registering from a single device.  For example,
+both his SIP phone at home and the one in the office could send
+registrations.  This information is stored together in the location
+Rosenberg, et. al.          Standards Track                    [Page 17]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+service and allows a proxy to perform various types of searches to
+locate Bob.  Similarly, more than one user can be registered on a
+single device at the same time.
+The location service is just an abstract concept.  It generally
+contains information that allows a proxy to input a URI and receive a
+set of zero or more URIs that tell the proxy where to send the
+request.  Registrations are one way to create this information, but
+not the only way.  Arbitrary mapping functions can be configured at
+the discretion of the administrator.
+Finally, it is important to note that in SIP, registration is used
+for routing incoming SIP requests and has no role in authorizing
+outgoing requests.  Authorization and authentication are handled in
+SIP either on a request-by-request basis with a challenge/response
+mechanism, or by using a lower layer scheme as discussed in Section
+26.
+The complete set of SIP message details for this registration example
+is in Section 24.1.
+Additional operations in SIP, such as querying for the capabilities
+of a SIP server or client using OPTIONS, or canceling a pending
+request using CANCEL, will be introduced in later sections.
+5 Structure of the Protocol
+SIP is structured as a layered protocol, which means that its
+behavior is described in terms of a set of fairly independent
+processing stages with only a loose coupling between each stage.  The
+protocol behavior is described as layers for the purpose of
+presentation, allowing the description of functions common across
+elements in a single section.  It does not dictate an implementation
+in any way.  When we say that an element "contains" a layer, we mean
+it is compliant to the set of rules defined by that layer.
+Not every element specified by the protocol contains every layer.
+Furthermore, the elements specified by SIP are logical elements, not
+physical ones.  A physical realization can choose to act as different
+logical elements, perhaps even on a transaction-by-transaction basis.
+The lowest layer of SIP is its syntax and encoding.  Its encoding is
+specified using an augmented Backus-Naur Form grammar (BNF).  The
+complete BNF is specified in Section 25; an overview of a SIP
+message's structure can be found in Section 7.
+Rosenberg, et. al.          Standards Track                    [Page 18]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The second layer is the transport layer.  It defines how a client
+sends requests and receives responses and how a server receives
+requests and sends responses over the network.  All SIP elements
+contain a transport layer.  The transport layer is described in
+Section 18.
+The third layer is the transaction layer.  Transactions are a
+fundamental component of SIP.  A transaction is a request sent by a
+client transaction (using the transport layer) to a server
+transaction, along with all responses to that request sent from the
+server transaction back to the client.  The transaction layer handles
+application-layer retransmissions, matching of responses to requests,
+and application-layer timeouts.  Any task that a user agent client
+(UAC) accomplishes takes place using a series of transactions.
+Discussion of transactions can be found in Section 17.  User agents
+contain a transaction layer, as do stateful proxies.  Stateless
+proxies do not contain a transaction layer.  The transaction layer
+has a client component (referred to as a client transaction) and a
+server component (referred to as a server transaction), each of which
+are represented by a finite state machine that is constructed to
+process a particular request.
+The layer above the transaction layer is called the transaction user
+(TU).  Each of the SIP entities, except the stateless proxy, is a
+transaction user.  When a TU wishes to send a request, it creates a
+client transaction instance and passes it the request along with the
+destination IP address, port, and transport to which to send the
+request.  A TU that creates a client transaction can also cancel it.
+When a client cancels a transaction, it requests that the server stop
+further processing, revert to the state that existed before the
+transaction was initiated, and generate a specific error response to
+that transaction.  This is done with a CANCEL request, which
+constitutes its own transaction, but references the transaction to be
+cancelled (Section 9).
+The SIP elements, that is, user agent clients and servers, stateless
+and stateful proxies and registrars, contain a core that
+distinguishes them from each other.  Cores, except for the stateless
+proxy, are transaction users.  While the behavior of the UAC and UAS
+cores depends on the method, there are some common rules for all
+methods (Section 8).  For a UAC, these rules govern the construction
+of a request; for a UAS, they govern the processing of a request and
+generating a response.  Since registrations play an important role in
+SIP, a UAS that handles a REGISTER is given the special name
+registrar.  Section 10 describes UAC and UAS core behavior for the
+REGISTER method.  Section 11 describes UAC and UAS core behavior for
+the OPTIONS method, used for determining the capabilities of a UA.
+Rosenberg, et. al.          Standards Track                    [Page 19]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Certain other requests are sent within a dialog.  A dialog is a
+peer-to-peer SIP relationship between two user agents that persists
+for some time.  The dialog facilitates sequencing of messages and
+proper routing of requests between the user agents.  The INVITE
+method is the only way defined in this specification to establish a
+dialog.  When a UAC sends a request that is within the context of a
+dialog, it follows the common UAC rules as discussed in Section 8 but
+also the rules for mid-dialog requests.  Section 12 discusses dialogs
+and presents the procedures for their construction and maintenance,
+in addition to construction of requests within a dialog.
+The most important method in SIP is the INVITE method, which is used
+to establish a session between participants.  A session is a
+collection of participants, and streams of media between them, for
+the purposes of communication.  Section 13 discusses how sessions are
+initiated, resulting in one or more SIP dialogs.  Section 14
+discusses how characteristics of that session are modified through
+the use of an INVITE request within a dialog.  Finally, section 15
+discusses how a session is terminated.
+The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal
+entirely with the UA core (Section 9 describes cancellation, which
+applies to both UA core and proxy core).  Section 16 discusses the
+proxy element, which facilitates routing of messages between user
+agents.
+6 Definitions
+The following terms have special significance for SIP.
+Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI
+that points to a domain with a location service that can map
+the URI to another URI where the user might be available.
+Typically, the location service is populated through
+registrations.  An AOR is frequently thought of as the "public
+address" of the user.
+Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a
+logical entity that receives a request and processes it as a
+user agent server (UAS).  In order to determine how the request
+should be answered, it acts as a user agent client (UAC) and
+generates requests.  Unlike a proxy server, it maintains dialog
+state and must participate in all requests sent on the dialogs
+it has established.  Since it is a concatenation of a UAC and
+UAS, no explicit definitions are needed for its behavior.
+Rosenberg, et. al.          Standards Track                    [Page 20]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Call: A call is an informal term that refers to some communication
+between peers, generally set up for the purposes of a
+multimedia conversation.
+Call Leg: Another name for a dialog [31]; no longer used in this
+specification.
+Call Stateful: A proxy is call stateful if it retains state for a
+dialog from the initiating INVITE to the terminating BYE
+request.  A call stateful proxy is always transaction stateful,
+but the converse is not necessarily true.
+Client: A client is any network element that sends SIP requests
+and receives SIP responses.  Clients may or may not interact
+directly with a human user.  User agent clients and proxies are
+clients.
+Conference: A multimedia session (see below) that contains
+multiple participants.
+Core: Core designates the functions specific to a particular type
+of SIP entity, i.e., specific to either a stateful or stateless
+proxy, a user agent or registrar.  All cores, except those for
+the stateless proxy, are transaction users.
+Dialog: A dialog is a peer-to-peer SIP relationship between two
+UAs that persists for some time.  A dialog is established by
+SIP messages, such as a 2xx response to an INVITE request.  A
+dialog is identified by a call identifier, local tag, and a
+remote tag.  A dialog was formerly known as a call leg in RFC
+2543.
+Downstream: A direction of message forwarding within a transaction
+that refers to the direction that requests flow from the user
+agent client to user agent server.
+Final Response: A response that terminates a SIP transaction, as
+opposed to a provisional response that does not.  All 2xx, 3xx,
+4xx, 5xx and 6xx responses are final.
+Header: A header is a component of a SIP message that conveys
+information about the message.  It is structured as a sequence
+of header fields.
+Header Field: A header field is a component of the SIP message
+header.  A header field can appear as one or more header field
+rows. Header field rows consist of a header field name and zero
+or more header field values. Multiple header field values on a
+Rosenberg, et. al.          Standards Track                    [Page 21]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+given header field row are separated by commas. Some header
+fields can only have a single header field value, and as a
+result, always appear as a single header field row.
+Header Field Value: A header field value is a single value; a
+header field consists of zero or more header field values.
+Home Domain: The domain providing service to a SIP user.
+Typically, this is the domain present in the URI in the
+address-of-record of a registration.
+Informational Response: Same as a provisional response.
+Initiator, Calling Party, Caller: The party initiating a session
+(and dialog) with an INVITE request.  A caller retains this
+role from the time it sends the initial INVITE that established
+a dialog until the termination of that dialog.
+Invitation: An INVITE request.
+Invitee, Invited User, Called Party, Callee: The party that
+receives an INVITE request for the purpose of establishing a
+new session.  A callee retains this role from the time it
+receives the INVITE until the termination of the dialog
+established by that INVITE.
+Location Service: A location service is used by a SIP redirect or
+proxy server to obtain information about a callee's possible
+location(s).  It contains a list of bindings of address-of-
+record keys to zero or more contact addresses.  The bindings
+can be created and removed in many ways; this specification
+defines a REGISTER method that updates the bindings.
+Loop: A request that arrives at a proxy, is forwarded, and later
+arrives back at the same proxy.  When it arrives the second
+time, its Request-URI is identical to the first time, and other
+header fields that affect proxy operation are unchanged, so
+that the proxy would make the same processing decision on the
+request it made the first time.  Looped requests are errors,
+and the procedures for detecting them and handling them are
+described by the protocol.
+Loose Routing: A proxy is said to be loose routing if it follows
+the procedures defined in this specification for processing of
+the Route header field.  These procedures separate the
+destination of the request (present in the Request-URI) from
+Rosenberg, et. al.          Standards Track                    [Page 22]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+the set of proxies that need to be visited along the way
+(present in the Route header field).  A proxy compliant to
+these mechanisms is also known as a loose router.
+Message: Data sent between SIP elements as part of the protocol.
+SIP messages are either requests or responses.
+Method: The method is the primary function that a request is meant
+to invoke on a server.  The method is carried in the request
+message itself.  Example methods are INVITE and BYE.
+Outbound Proxy: A proxy that receives requests from a client, even
+though it may not be the server resolved by the Request-URI.
+Typically, a UA is manually configured with an outbound proxy,
+or can learn about one through auto-configuration protocols.
+Parallel Search: In a parallel search, a proxy issues several
+requests to possible user locations upon receiving an incoming
+request.  Rather than issuing one request and then waiting for
+the final response before issuing the next request as in a
+sequential search, a parallel search issues requests without
+waiting for the result of previous requests.
+Provisional Response: A response used by the server to indicate
+progress, but that does not terminate a SIP transaction.  1xx
+responses are provisional, other responses are considered
+final.
+Proxy, Proxy Server: An intermediary entity that acts as both a
+server and a client for the purpose of making requests on
+behalf of other clients.  A proxy server primarily plays the
+role of routing, which means its job is to ensure that a
+request is sent to another entity "closer" to the targeted
+user.  Proxies are also useful for enforcing policy (for
+example, making sure a user is allowed to make a call).  A
+proxy interprets, and, if necessary, rewrites specific parts of
+a request message before forwarding it.
+Recursion: A client recurses on a 3xx response when it generates a
+new request to one or more of the URIs in the Contact header
+field in the response.
+Redirect Server: A redirect server is a user agent server that
+generates 3xx responses to requests it receives, directing the
+client to contact an alternate set of URIs.
+Rosenberg, et. al.          Standards Track                    [Page 23]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Registrar: A registrar is a server that accepts REGISTER requests
+and places the information it receives in those requests into
+the location service for the domain it handles.
+Regular Transaction: A regular transaction is any transaction with
+a method other than INVITE, ACK, or CANCEL.
+Request: A SIP message sent from a client to a server, for the
+purpose of invoking a particular operation.
+Response: A SIP message sent from a server to a client, for
+indicating the status of a request sent from the client to the
+server.
+Ringback: Ringback is the signaling tone produced by the calling
+party's application indicating that a called party is being
+alerted (ringing).
+Route Set: A route set is a collection of ordered SIP or SIPS URI
+which represent a list of proxies that must be traversed when
+sending a particular request.  A route set can be learned,
+through headers like Record-Route, or it can be configured.
+Server: A server is a network element that receives requests in
+order to service them and sends back responses to those
+requests.  Examples of servers are proxies, user agent servers,
+redirect servers, and registrars.
+Sequential Search: In a sequential search, a proxy server attempts
+each contact address in sequence, proceeding to the next one
+only after the previous has generated a final response.  A 2xx
+or 6xx class final response always terminates a sequential
+search.
+Session: From the SDP specification: "A multimedia session is a
+set of multimedia senders and receivers and the data streams
+flowing from senders to receivers.  A multimedia conference is
+an example of a multimedia session." (RFC 2327 [1]) (A session
+as defined for SDP can comprise one or more RTP sessions.)  As
+defined, a callee can be invited several times, by different
+calls, to the same session.  If SDP is used, a session is
+defined by the concatenation of the SDP user name, session id,
+network type, address type, and address elements in the origin
+field.
+SIP Transaction: A SIP transaction occurs between a client and a
+server and comprises all messages from the first request sent
+from the client to the server up to a final (non-1xx) response
+Rosenberg, et. al.          Standards Track                    [Page 24]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+sent from the server to the client.  If the request is INVITE
+and the final response is a non-2xx, the transaction also
+includes an ACK to the response.  The ACK for a 2xx response to
+an INVITE request is a separate transaction.
+Spiral: A spiral is a SIP request that is routed to a proxy,
+forwarded onwards, and arrives once again at that proxy, but
+this time differs in a way that will result in a different
+processing decision than the original request.  Typically, this
+means that the request's Request-URI differs from its previous
+arrival.  A spiral is not an error condition, unlike a loop.  A
+typical cause for this is call forwarding.  A user calls
+joe@example.com.  The example.com proxy forwards it to Joe's
+PC, which in turn, forwards it to bob@example.com.  This
+request is proxied back to the example.com proxy.  However,
+this is not a loop.  Since the request is targeted at a
+different user, it is considered a spiral, and is a valid
+condition.
+Stateful Proxy: A logical entity that maintains the client and
+server transaction state machines defined by this specification
+during the processing of a request, also known as a transaction
+stateful proxy.  The behavior of a stateful proxy is further
+defined in Section 16.  A (transaction) stateful proxy is not
+the same as a call stateful proxy.
+Stateless Proxy: A logical entity that does not maintain the
+client or server transaction state machines defined in this
+specification when it processes requests.  A stateless proxy
+forwards every request it receives downstream and every
+response it receives upstream.
+Strict Routing: A proxy is said to be strict routing if it follows
+the Route processing rules of RFC 2543 and many prior work in
+progress versions of this RFC.  That rule caused proxies to
+destroy the contents of the Request-URI when a Route header
+field was present.  Strict routing behavior is not used in this
+specification, in favor of a loose routing behavior.  Proxies
+that perform strict routing are also known as strict routers.
+Target Refresh Request: A target refresh request sent within a
+dialog is defined as a request that can modify the remote
+target of the dialog.
+Transaction User (TU): The layer of protocol processing that
+resides above the transaction layer.  Transaction users include
+the UAC core, UAS core, and proxy core.
+Rosenberg, et. al.          Standards Track                    [Page 25]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Upstream: A direction of message forwarding within a transaction
+that refers to the direction that responses flow from the user
+agent server back to the user agent client.
+URL-encoded: A character string encoded according to RFC 2396,
+Section 2.4 [5].
+User Agent Client (UAC): A user agent client is a logical entity
+that creates a new request, and then uses the client
+transaction state machinery to send it.  The role of UAC lasts
+only for the duration of that transaction.  In other words, if
+a piece of software initiates a request, it acts as a UAC for
+the duration of that transaction.  If it receives a request
+later, it assumes the role of a user agent server for the
+processing of that transaction.
+UAC Core: The set of processing functions required of a UAC that
+reside above the transaction and transport layers.
+User Agent Server (UAS): A user agent server is a logical entity
+that generates a response to a SIP request.  The response
+accepts, rejects, or redirects the request.  This role lasts
+only for the duration of that transaction.  In other words, if
+a piece of software responds to a request, it acts as a UAS for
+the duration of that transaction.  If it generates a request
+later, it assumes the role of a user agent client for the
+processing of that transaction.
+UAS Core: The set of processing functions required at a UAS that
+resides above the transaction and transport layers.
+User Agent (UA): A logical entity that can act as both a user
+agent client and user agent server.
+The role of UAC and UAS, as well as proxy and redirect servers, are
+defined on a transaction-by-transaction basis.  For example, the user
+agent initiating a call acts as a UAC when sending the initial INVITE
+request and as a UAS when receiving a BYE request from the callee.
+Similarly, the same software can act as a proxy server for one
+request and as a redirect server for the next request.
+Proxy, location, and registrar servers defined above are logical
+entities; implementations MAY combine them into a single application.
+7 SIP Messages
+SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279
+[7]).
+Rosenberg, et. al.          Standards Track                    [Page 26]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+A SIP message is either a request from a client to a server, or a
+response from a server to a client.
+Both Request (section 7.1) and Response (section 7.2) messages use
+the basic format of RFC 2822 [3], even though the syntax differs in
+character set and syntax specifics.  (SIP allows header fields that
+would not be valid RFC 2822 header fields, for example.)  Both types
+of messages consist of a start-line, one or more header fields, an
+empty line indicating the end of the header fields, and an optional
+message-body.
+generic-message  =  start-line
+*message-header
+CRLF
+[ message-body ]
+start-line       =  Request-Line / Status-Line
+The start-line, each message-header line, and the empty line MUST be
+terminated by a carriage-return line-feed sequence (CRLF).  Note that
+the empty line MUST be present even if the message-body is not.
+Except for the above difference in character sets, much of SIP's
+message and header field syntax is identical to HTTP/1.1.  Rather
+than repeating the syntax and semantics here, we use [HX.Y] to refer
+to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]).
+However, SIP is not an extension of HTTP.
+7.1 Requests
+SIP requests are distinguished by having a Request-Line for a start-
+line.  A Request-Line contains a method name, a Request-URI, and the
+protocol version separated by a single space (SP) character.
+The Request-Line ends with CRLF.  No CR or LF are allowed except in
+the end-of-line CRLF sequence.  No linear whitespace (LWS) is allowed
+in any of the elements.
+Request-Line  =  Method SP Request-URI SP SIP-Version CRLF
+Method: This specification defines six methods: REGISTER for
+registering contact information, INVITE, ACK, and CANCEL for
+setting up sessions, BYE for terminating sessions, and
+OPTIONS for querying servers about their capabilities.  SIP
+extensions, documented in standards track RFCs, may define
+additional methods.
+Rosenberg, et. al.          Standards Track                    [Page 27]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Request-URI: The Request-URI is a SIP or SIPS URI as described in
+Section 19.1 or a general URI (RFC 2396 [5]).  It indicates
+the user or service to which this request is being addressed.
+The Request-URI MUST NOT contain unescaped spaces or control
+characters and MUST NOT be enclosed in "<>".
+SIP elements MAY support Request-URIs with schemes other than
+"sip" and "sips", for example the "tel" URI scheme of RFC
+2806 [9].  SIP elements MAY translate non-SIP URIs using any
+mechanism at their disposal, resulting in SIP URI, SIPS URI,
+or some other scheme.
+SIP-Version: Both request and response messages include the
+version of SIP in use, and follow [H3.1] (with HTTP replaced
+by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version
+ordering, compliance requirements, and upgrading of version
+numbers.  To be compliant with this specification,
+applications sending SIP messages MUST include a SIP-Version
+of "SIP/2.0".  The SIP-Version string is case-insensitive,
+but implementations MUST send upper-case.
+Unlike HTTP/1.1, SIP treats the version number as a literal
+string.  In practice, this should make no difference.
+7.2 Responses
+SIP responses are distinguished from requests by having a Status-Line
+as their start-line.  A Status-Line consists of the protocol version
+followed by a numeric Status-Code and its associated textual phrase,
+with each element separated by a single SP character.
+No CR or LF is allowed except in the final CRLF sequence.
+Status-Line  =  SIP-Version SP Status-Code SP Reason-Phrase CRLF
+The Status-Code is a 3-digit integer result code that indicates the
+outcome of an attempt to understand and satisfy a request.  The
+Reason-Phrase is intended to give a short textual description of the
+Status-Code.  The Status-Code is intended for use by automata,
+whereas the Reason-Phrase is intended for the human user.  A client
+is not required to examine or display the Reason-Phrase.
+While this specification suggests specific wording for the reason
+phrase, implementations MAY choose other text, for example, in the
+language indicated in the Accept-Language header field of the
+request.
+Rosenberg, et. al.          Standards Track                    [Page 28]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The first digit of the Status-Code defines the class of response.
+The last two digits do not have any categorization role.  For this
+reason, any response with a status code between 100 and 199 is
+referred to as a "1xx response", any response with a status code
+between 200 and 299 as a "2xx response", and so on.  SIP/2.0 allows
+six values for the first digit:
+1xx: Provisional -- request received, continuing to process the
+request;
+2xx: Success -- the action was successfully received, understood,
+and accepted;
+3xx: Redirection -- further action needs to be taken in order to
+complete the request;
+4xx: Client Error -- the request contains bad syntax or cannot be
+fulfilled at this server;
+5xx: Server Error -- the server failed to fulfill an apparently
+valid request;
+6xx: Global Failure -- the request cannot be fulfilled at any
+server.
+Section 21 defines these classes and describes the individual codes.
+7.3 Header Fields
+SIP header fields are similar to HTTP header fields in both syntax
+and semantics.  In particular, SIP header fields follow the [H4.2]
+definitions of syntax for the message-header and the rules for
+extending header fields over multiple lines.  However, the latter is
+specified in HTTP with implicit whitespace and folding.  This
+specification conforms to RFC 2234 [10] and uses only explicit
+whitespace and folding as an integral part of the grammar.
+[H4.2] also specifies that multiple header fields of the same field
+name whose value is a comma-separated list can be combined into one
+header field.  That applies to SIP as well, but the specific rule is
+different because of the different grammars.  Specifically, any SIP
+header whose grammar is of the form
+header  =  "header-name" HCOLON header-value *(COMMA header-value)
+allows for combining header fields of the same name into a comma-
+separated list.  The Contact header field allows a comma-separated
+list unless the header field value is "*".
+Rosenberg, et. al.          Standards Track                    [Page 29]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+7.3.1 Header Field Format
+Header fields follow the same generic header format as that given in
+Section 2.2 of RFC 2822 [3].  Each header field consists of a field
+name followed by a colon (":") and the field value.
+field-name: field-value
+The formal grammar for a message-header specified in Section 25
+allows for an arbitrary amount of whitespace on either side of the
+colon; however, implementations should avoid spaces between the field
+name and the colon and use a single space (SP) between the colon and
+the field-value.
+Subject:            lunch
+Subject      :      lunch
+Subject            :lunch
+Subject: lunch
+Thus, the above are all valid and equivalent, but the last is the
+preferred form.
+Header fields can be extended over multiple lines by preceding each
+extra line with at least one SP or horizontal tab (HT).  The line
+break and the whitespace at the beginning of the next line are
+treated as a single SP character.  Thus, the following are
+equivalent:
+Subject: I know you're there, pick up the phone and talk to me!
+Subject: I know you're there,
+pick up the phone
+and talk to me!
+The relative order of header fields with different field names is not
+significant.  However, it is RECOMMENDED that header fields which are
+needed for proxy processing (Via, Route, Record-Route, Proxy-Require,
+Max-Forwards, and Proxy-Authorization, for example) appear towards
+the top of the message to facilitate rapid parsing.  The relative
+order of header field rows with the same field name is important.
+Multiple header field rows with the same field-name MAY be present in
+a message if and only if the entire field-value for that header field
+is defined as a comma-separated list (that is, if follows the grammar
+defined in Section 7.3).  It MUST be possible to combine the multiple
+header field rows into one "field-name: field-value" pair, without
+changing the semantics of the message, by appending each subsequent
+field-value to the first, each separated by a comma.  The exceptions
+to this rule are the WWW-Authenticate, Authorization, Proxy-
+Authenticate, and Proxy-Authorization header fields.  Multiple header
+Rosenberg, et. al.          Standards Track                    [Page 30]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+field rows with these names MAY be present in a message, but since
+their grammar does not follow the general form listed in Section 7.3,
+they MUST NOT be combined into a single header field row.
+Implementations MUST be able to process multiple header field rows
+with the same name in any combination of the single-value-per-line or
+comma-separated value forms.
+The following groups of header field rows are valid and equivalent:
+Route: <sip:alice@atlanta.com>
+Subject: Lunch
+Route: <sip:bob@biloxi.com>
+Route: <sip:carol@chicago.com>
+Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
+Route: <sip:carol@chicago.com>
+Subject: Lunch
+Subject: Lunch
+Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>,
+<sip:carol@chicago.com>
+Each of the following blocks is valid but not equivalent to the
+others:
+Route: <sip:alice@atlanta.com>
+Route: <sip:bob@biloxi.com>
+Route: <sip:carol@chicago.com>
+Route: <sip:bob@biloxi.com>
+Route: <sip:alice@atlanta.com>
+Route: <sip:carol@chicago.com>
+Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>,
+<sip:bob@biloxi.com>
+The format of a header field-value is defined per header-name.  It
+will always be either an opaque sequence of TEXT-UTF8 octets, or a
+combination of whitespace, tokens, separators, and quoted strings.
+Many existing header fields will adhere to the general form of a
+value followed by a semi-colon separated sequence of parameter-name,
+parameter-value pairs:
+field-name: field-value *(;parameter-name=parameter-value)
+Rosenberg, et. al.          Standards Track                    [Page 31]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Even though an arbitrary number of parameter pairs may be attached to
+a header field value, any given parameter-name MUST NOT appear more
+than once.
+When comparing header fields, field names are always case-
+insensitive.  Unless otherwise stated in the definition of a
+particular header field, field values, parameter names, and parameter
+values are case-insensitive.  Tokens are always case-insensitive.
+Unless specified otherwise, values expressed as quoted strings are
+case-sensitive.  For example,
+Contact: <sip:alice@atlanta.com>;expires=3600
+is equivalent to
+CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
+and
+Content-Disposition: session;handling=optional
+is equivalent to
+content-disposition: Session;HANDLING=OPTIONAL
+The following two header fields are not equivalent:
+Warning: 370 devnull "Choose a bigger pipe"
+Warning: 370 devnull "CHOOSE A BIGGER PIPE"
+7.3.2 Header Field Classification
+Some header fields only make sense in requests or responses.  These
+are called request header fields and response header fields,
+respectively.  If a header field appears in a message not matching
+its category (such as a request header field in a response), it MUST
+be ignored.  Section 20 defines the classification of each header
+field.
+7.3.3 Compact Form
+SIP provides a mechanism to represent common header field names in an
+abbreviated form.  This may be useful when messages would otherwise
+become too large to be carried on the transport available to it
+(exceeding the maximum transmission unit (MTU) when using UDP, for
+example).  These compact forms are defined in Section 20.  A compact
+form MAY be substituted for the longer form of a header field name at
+any time without changing the semantics of the message.  A header
+Rosenberg, et. al.          Standards Track                    [Page 32]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+field name MAY appear in both long and short forms within the same
+message.  Implementations MUST accept both the long and short forms
+of each header name.
+7.4 Bodies
+Requests, including new requests defined in extensions to this
+specification, MAY contain message bodies unless otherwise noted.
+The interpretation of the body depends on the request method.
+For response messages, the request method and the response status
+code determine the type and interpretation of any message body.  All
+responses MAY include a body.
+7.4.1 Message Body Type
+The Internet media type of the message body MUST be given by the
+Content-Type header field.  If the body has undergone any encoding
+such as compression, then this MUST be indicated by the Content-
+Encoding header field; otherwise, Content-Encoding MUST be omitted.
+If applicable, the character set of the message body is indicated as
+part of the Content-Type header-field value.
+The "multipart" MIME type defined in RFC 2046 [11] MAY be used within
+the body of the message.  Implementations that send requests
+containing multipart message bodies MUST send a session description
+as a non-multipart message body if the remote implementation requests
+this through an Accept header field that does not contain multipart.
+SIP messages MAY contain binary bodies or body parts. When no
+explicit charset parameter is provided by the sender, media subtypes
+of the "text" type are defined to have a default charset value of
+"UTF-8".
+7.4.2 Message Body Length
+The body length in bytes is provided by the Content-Length header
+field.  Section 20.14 describes the necessary contents of this header
+field in detail.
+The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP.
+(Note: The chunked encoding modifies the body of a message in order
+to transfer it as a series of chunks, each with its own size
+indicator.)
+Rosenberg, et. al.          Standards Track                    [Page 33]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+7.5 Framing SIP Messages
+Unlike HTTP, SIP implementations can use UDP or other unreliable
+datagram protocols.  Each such datagram carries one request or
+response.  See Section 18 on constraints on usage of unreliable
+transports.
+Implementations processing SIP messages over stream-oriented
+transports MUST ignore any CRLF appearing before the start-line
+[H4.1].
+The Content-Length header field value is used to locate the end of
+each SIP message in a stream.  It will always be present when SIP
+messages are sent over stream-oriented transports.
+8 General User Agent Behavior
+A user agent represents an end system.  It contains a user agent
+client (UAC), which generates requests, and a user agent server
+(UAS), which responds to them.  A UAC is capable of generating a
+request based on some external stimulus (the user clicking a button,
+or a signal on a PSTN line) and processing a response.  A UAS is
+capable of receiving a request and generating a response based on
+user input, external stimulus, the result of a program execution, or
+some other mechanism.
+When a UAC sends a request, the request passes through some number of
+proxy servers, which forward the request towards the UAS. When the
+UAS generates a response, the response is forwarded towards the UAC.
+UAC and UAS procedures depend strongly on two factors.  First, based
+on whether the request or response is inside or outside of a dialog,
+and second, based on the method of a request.  Dialogs are discussed
+thoroughly in Section 12; they represent a peer-to-peer relationship
+between user agents and are established by specific SIP methods, such
+as INVITE.
+In this section, we discuss the method-independent rules for UAC and
+UAS behavior when processing requests that are outside of a dialog.
+This includes, of course, the requests which themselves establish a
+dialog.
+Security procedures for requests and responses outside of a dialog
+are described in Section 26.  Specifically, mechanisms exist for the
+UAS and UAC to mutually authenticate.  A limited set of privacy
+features are also supported through encryption of bodies using
+S/MIME.
+Rosenberg, et. al.          Standards Track                    [Page 34]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+8.1 UAC Behavior
+This section covers UAC behavior outside of a dialog.
+8.1.1 Generating the Request
+A valid SIP request formulated by a UAC MUST, at a minimum, contain
+the following header fields: To, From, CSeq, Call-ID, Max-Forwards,
+and Via; all of these header fields are mandatory in all SIP
+requests.  These six header fields are the fundamental building
+blocks of a SIP message, as they jointly provide for most of the
+critical message routing services including the addressing of
+messages, the routing of responses, limiting message propagation,
+ordering of messages, and the unique identification of transactions.
+These header fields are in addition to the mandatory request line,
+which contains the method, Request-URI, and SIP version.
+Examples of requests sent outside of a dialog include an INVITE to
+establish a session (Section 13) and an OPTIONS to query for
+capabilities (Section 11).
+8.1.1.1 Request-URI
+The initial Request-URI of the message SHOULD be set to the value of
+the URI in the To field.  One notable exception is the REGISTER
+method; behavior for setting the Request-URI of REGISTER is given in
+Section 10.  It may also be undesirable for privacy reasons or
+convenience to set these fields to the same value (especially if the
+originating UA expects that the Request-URI will be changed during
+transit).
+In some special circumstances, the presence of a pre-existing route
+set can affect the Request-URI of the message.  A pre-existing route
+set is an ordered set of URIs that identify a chain of servers, to
+which a UAC will send outgoing requests that are outside of a dialog.
+Commonly, they are configured on the UA by a user or service provider
+manually, or through some other non-SIP mechanism.  When a provider
+wishes to configure a UA with an outbound proxy, it is RECOMMENDED
+that this be done by providing it with a pre-existing route set with
+a single URI, that of the outbound proxy.
+When a pre-existing route set is present, the procedures for
+populating the Request-URI and Route header field detailed in Section
+12.2.1.1 MUST be followed (even though there is no dialog), using the
+desired Request-URI as the remote target URI.
+Rosenberg, et. al.          Standards Track                    [Page 35]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+8.1.1.2 To
+The To header field first and foremost specifies the desired
+"logical" recipient of the request, or the address-of-record of the
+user or resource that is the target of this request.  This may or may
+not be the ultimate recipient of the request.  The To header field
+MAY contain a SIP or SIPS URI, but it may also make use of other URI
+schemes (the tel URL (RFC 2806 [9]), for example) when appropriate.
+All SIP implementations MUST support the SIP URI scheme.  Any
+implementation that supports TLS MUST support the SIPS URI scheme.
+The To header field allows for a display name.
+A UAC may learn how to populate the To header field for a particular
+request in a number of ways.  Usually the user will suggest the To
+header field through a human interface, perhaps inputting the URI
+manually or selecting it from some sort of address book.  Frequently,
+the user will not enter a complete URI, but rather a string of digits
+or letters (for example, "bob").  It is at the discretion of the UA
+to choose how to interpret this input.  Using the string to form the
+user part of a SIP URI implies that the UA wishes the name to be
+resolved in the domain to the right-hand side (RHS) of the at-sign in
+the SIP URI (for instance, sip:bob@example.com).  Using the string to
+form the user part of a SIPS URI implies that the UA wishes to
+communicate securely, and that the name is to be resolved in the
+domain to the RHS of the at-sign.  The RHS will frequently be the
+home domain of the requestor, which allows for the home domain to
+process the outgoing request.  This is useful for features like
+"speed dial" that require interpretation of the user part in the home
+domain.  The tel URL may be used when the UA does not wish to specify
+the domain that should interpret a telephone number that has been
+input by the user.  Rather, each domain through which the request
+passes would be given that opportunity.  As an example, a user in an
+airport might log in and send requests through an outbound proxy in
+the airport.  If they enter "411" (this is the phone number for local
+directory assistance in the United States), that needs to be
+interpreted and processed by the outbound proxy in the airport, not
+the user's home domain.  In this case, tel:411 would be the right
+choice.
+A request outside of a dialog MUST NOT contain a To tag; the tag in
+the To field of a request identifies the peer of the dialog.  Since
+no dialog is established, no tag is present.
+For further information on the To header field, see Section 20.39.
+The following is an example of a valid To header field:
+To: Carol <sip:carol@chicago.com>
+Rosenberg, et. al.          Standards Track                    [Page 36]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+8.1.1.3 From
+The From header field indicates the logical identity of the initiator
+of the request, possibly the user's address-of-record.  Like the To
+header field, it contains a URI and optionally a display name.  It is
+used by SIP elements to determine which processing rules to apply to
+a request (for example, automatic call rejection).  As such, it is
+very important that the From URI not contain IP addresses or the FQDN
+of the host on which the UA is running, since these are not logical
+names.
+The From header field allows for a display name.  A UAC SHOULD use
+the display name "Anonymous", along with a syntactically correct, but
+otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the
+identity of the client is to remain hidden.
+Usually, the value that populates the From header field in requests
+generated by a particular UA is pre-provisioned by the user or by the
+administrators of the user's local domain.  If a particular UA is
+used by multiple users, it might have switchable profiles that
+include a URI corresponding to the identity of the profiled user.
+Recipients of requests can authenticate the originator of a request
+in order to ascertain that they are who their From header field
+claims they are (see Section 22 for more on authentication).
+The From field MUST contain a new "tag" parameter, chosen by the UAC.
+See Section 19.3 for details on choosing a tag.
+For further information on the From header field, see Section 20.20.
+Examples:
+From: "Bob" <sips:bob@biloxi.com> ;tag=a48s
+From: sip:+12125551212@phone2net.com;tag=887s
+From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
+8.1.1.4 Call-ID
+The Call-ID header field acts as a unique identifier to group
+together a series of messages.  It MUST be the same for all requests
+and responses sent by either UA in a dialog.  It SHOULD be the same
+in each registration from a UA.
+In a new request created by a UAC outside of any dialog, the Call-ID
+header field MUST be selected by the UAC as a globally unique
+identifier over space and time unless overridden by method-specific
+behavior.  All SIP UAs must have a means to guarantee that the Call-
+ID header fields they produce will not be inadvertently generated by
+any other UA.  Note that when requests are retried after certain
+Rosenberg, et. al.          Standards Track                    [Page 37]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+failure responses that solicit an amendment to a request (for
+example, a challenge for authentication), these retried requests are
+not considered new requests, and therefore do not need new Call-ID
+header fields; see Section 8.1.3.5.
+Use of cryptographically random identifiers (RFC 1750 [12]) in the
+generation of Call-IDs is RECOMMENDED.  Implementations MAY use the
+form "localid@host".  Call-IDs are case-sensitive and are simply
+compared byte-by-byte.
+Using cryptographically random identifiers provides some
+protection against session hijacking and reduces the likelihood of
+unintentional Call-ID collisions.
+No provisioning or human interface is required for the selection of
+the Call-ID header field value for a request.
+For further information on the Call-ID header field, see Section
+20.8.
+Example:
+Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
+8.1.1.5 CSeq
+The CSeq header field serves as a way to identify and order
+transactions.  It consists of a sequence number and a method.  The
+method MUST match that of the request.  For non-REGISTER requests
+outside of a dialog, the sequence number value is arbitrary.  The
+sequence number value MUST be expressible as a 32-bit unsigned
+integer and MUST be less than 2**31.  As long as it follows the above
+guidelines, a client may use any mechanism it would like to select
+CSeq header field values.
+Section 12.2.1.1 discusses construction of the CSeq for requests
+within a dialog.
+Example:
+CSeq: 4711 INVITE
+Rosenberg, et. al.          Standards Track                    [Page 38]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+8.1.1.6 Max-Forwards
+The Max-Forwards header field serves to limit the number of hops a
+request can transit on the way to its destination.  It consists of an
+integer that is decremented by one at each hop.  If the Max-Forwards
+value reaches 0 before the request reaches its destination, it will
+be rejected with a 483(Too Many Hops) error response.
+A UAC MUST insert a Max-Forwards header field into each request it
+originates with a value that SHOULD be 70.  This number was chosen to
+be sufficiently large to guarantee that a request would not be
+dropped in any SIP network when there were no loops, but not so large
+as to consume proxy resources when a loop does occur.  Lower values
+should be used with caution and only in networks where topologies are
+known by the UA.
+8.1.1.7 Via
+The Via header field indicates the transport used for the transaction
+and identifies the location where the response is to be sent.  A Via
+header field value is added only after the transport that will be
+used to reach the next hop has been selected (which may involve the
+usage of the procedures in [4]).
+When the UAC creates a request, it MUST insert a Via into that
+request.  The protocol name and protocol version in the header field
+MUST be SIP and 2.0, respectively.  The Via header field value MUST
+contain a branch parameter.  This parameter is used to identify the
+transaction created by that request.  This parameter is used by both
+the client and the server.
+The branch parameter value MUST be unique across space and time for
+all requests sent by the UA.  The exceptions to this rule are CANCEL
+and ACK for non-2xx responses.  As discussed below, a CANCEL request
+will have the same value of the branch parameter as the request it
+cancels.  As discussed in Section 17.1.1.3, an ACK for a non-2xx
+response will also have the same branch ID as the INVITE whose
+response it acknowledges.
+The uniqueness property of the branch ID parameter, to facilitate
+its use as a transaction ID, was not part of RFC 2543.
+The branch ID inserted by an element compliant with this
+specification MUST always begin with the characters "z9hG4bK".  These
+7 characters are used as a magic cookie (7 is deemed sufficient to
+ensure that an older RFC 2543 implementation would not pick such a
+value), so that servers receiving the request can determine that the
+branch ID was constructed in the fashion described by this
+Rosenberg, et. al.          Standards Track                    [Page 39]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+specification (that is, globally unique).  Beyond this requirement,
+the precise format of the branch token is implementation-defined.
+The Via header maddr, ttl, and sent-by components will be set when
+the request is processed by the transport layer (Section 18).
+Via processing for proxies is described in Section 16.6 Item 8 and
+Section 16.7 Item 3.
+8.1.1.8 Contact
+The Contact header field provides a SIP or SIPS URI that can be used
+to contact that specific instance of the UA for subsequent requests.
+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.  For the methods defined in this specification, that includes
+only the INVITE request.  For these requests, the scope of the
+Contact is global.  That is, the Contact header field value contains
+the URI at which the UA would like to receive requests, and this URI
+MUST be valid even if used in subsequent requests outside of any
+dialogs.
+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.
+For further information on the Contact header field, see Section
+20.10.
+8.1.1.9 Supported and Require
+If the UAC supports extensions to SIP that can be applied by the
+server to the response, the UAC SHOULD include a Supported header
+field in the request listing the option tags (Section 19.2) for those
+extensions.
+The option tags listed MUST only refer to extensions defined in
+standards-track RFCs.  This is to prevent servers from insisting that
+clients implement non-standard, vendor-defined features in order to
+receive service.  Extensions defined by experimental and
+informational RFCs are explicitly excluded from usage with the
+Supported header field in a request, since they too are often used to
+document vendor-defined extensions.
+If the UAC wishes to insist that a UAS understand an extension that
+the UAC will apply to the request in order to process the request, it
+MUST insert a Require header field into the request listing the
+option tag for that extension.  If the UAC wishes to apply an
+extension to the request and insist that any proxies that are
+Rosenberg, et. al.          Standards Track                    [Page 40]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+traversed understand that extension, it MUST insert a Proxy-Require
+header field into the request listing the option tag for that
+extension.
+As with the Supported header field, the option tags in the Require
+and Proxy-Require header fields MUST only refer to extensions defined
+in standards-track RFCs.
+8.1.1.10 Additional Message Components
+After a new request has been created, and the header fields described
+above have been properly constructed, any additional optional header
+fields are added, as are any header fields specific to the method.
+SIP requests MAY contain a MIME-encoded message-body.  Regardless of
+the type of body that a request contains, certain header fields must
+be formulated to characterize the contents of the body.  For further
+information on these header fields, see Sections 20.11 through 20.15.
+8.1.2 Sending the Request
+The destination for the request is then computed.  Unless there is
+local policy specifying otherwise, the destination MUST be determined
+by applying the DNS procedures described in [4] as follows.  If the
+first element in the route set indicated a strict router (resulting
+in forming the request as described in Section 12.2.1.1), the
+procedures MUST be applied to the Request-URI of the request.
+Otherwise, the procedures are applied to the first Route header field
+value in the request (if one exists), or to the request's Request-URI
+if there is no Route header field present.  These procedures yield an
+ordered set of address, port, and transports to attempt.  Independent
+of which URI is used as input to the procedures of [4], if the
+Request-URI specifies a SIPS resource, the UAC MUST follow the
+procedures of [4] as if the input URI were a SIPS URI.
+Local policy MAY specify an alternate set of destinations to attempt.
+If the Request-URI contains a SIPS URI, any alternate destinations
+MUST be contacted with TLS.  Beyond that, there are no restrictions
+on the alternate destinations if the request contains no Route header
+field.  This provides a simple alternative to a pre-existing route
+set as a way to specify an outbound proxy.  However, that approach
+for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing
+route set with a single URI SHOULD be used instead.  If the request
+contains a Route header field, the request SHOULD be sent to the
+locations derived from its topmost value, but MAY be sent to any
+server that the UA is certain will honor the Route and Request-URI
+policies specified in this document (as opposed to those in RFC
+2543).  In particular, a UAC configured with an outbound proxy SHOULD
+Rosenberg, et. al.          Standards Track                    [Page 41]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+attempt to send the request to the location indicated in the first
+Route header field value instead of adopting the policy of sending
+all messages to the outbound proxy.
+This ensures that outbound proxies that do not add Record-Route
+header field values will drop out of the path of subsequent
+requests.  It allows endpoints that cannot resolve the first Route
+URI to delegate that task to an outbound proxy.
+The UAC SHOULD follow the procedures defined in [4] for stateful
+elements, trying each address until a server is contacted.  Each try
+constitutes a new transaction, and therefore each carries a different
+topmost Via header field value with a new branch parameter.
+Furthermore, the transport value in the Via header field is set to
+whatever transport was determined for the target server.
+8.1.3 Processing Responses
+Responses are first processed by the transport layer and then passed
+up to the transaction layer.  The transaction layer performs its
+processing and then passes the response up to the TU.  The majority
+of response processing in the TU is method specific.  However, there
+are some general behaviors independent of the method.
+8.1.3.1 Transaction Layer Errors
+In some cases, the response returned by the transaction layer will
+not be a SIP message, but rather a transaction layer error.  When a
+timeout error is received from the transaction layer, it MUST be
+treated as if a 408 (Request Timeout) status code has been received.
+If a fatal transport error is reported by the transport layer
+(generally, due to fatal ICMP errors in UDP or connection failures in
+TCP), the condition MUST be treated as a 503 (Service Unavailable)
+status code.
+8.1.3.2 Unrecognized Responses
+A UAC MUST treat any final response it does not recognize as being
+equivalent to the x00 response code of that class, and MUST be able
+to process the x00 response code for all classes.  For example, if a
+UAC receives an unrecognized response code of 431, it can safely
+assume that there was something wrong with its request and treat the
+response as if it had received a 400 (Bad Request) response code.  A
+UAC MUST treat any provisional response different than 100 that it
+does not recognize as 183 (Session Progress).  A UAC MUST be able to
+process 100 and 183 responses.
+Rosenberg, et. al.          Standards Track                    [Page 42]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+8.1.3.3 Vias
+If more than one Via header field value is present in a response, the
+UAC SHOULD discard the message.
+The presence of additional Via header field values that precede
+the originator of the request suggests that the message was
+misrouted or possibly corrupted.
+8.1.3.4 Processing 3xx Responses
+Upon receipt of a redirection response (for example, a 301 response
+status code), clients SHOULD use the URI(s) in the Contact header
+field to formulate one or more new requests based on the redirected
+request.  This process is similar to that of a proxy recursing on a
+3xx class response as detailed in Sections 16.5 and 16.6.  A client
+starts with an initial target set containing exactly one URI, the
+Request-URI of the original request.  If a client wishes to formulate
+new requests based on a 3xx class response to that request, it places
+the URIs to try into the target set.  Subject to the restrictions in
+this specification, a client can choose which Contact URIs it places
+into the target set.  As with proxy recursion, a client processing
+3xx class responses MUST NOT add any given URI to the target set more
+than once.  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.
+Any new request may receive 3xx responses themselves containing
+the original URI as a contact.  Two locations can be configured to
+redirect to each other.  Placing any given URI in the target set
+only once prevents infinite redirection loops.
+As the target set grows, the client MAY generate new requests to the
+URIs in any order.  A common mechanism is to order the set by the "q"
+parameter value from the Contact header field value.  Requests to the
+URIs MAY be generated serially or in parallel.  One approach is to
+process groups of decreasing q-values serially and process the URIs
+in each q-value group in parallel.  Another is to perform only serial
+processing in decreasing q-value order, arbitrarily choosing between
+contacts of equal q-value.
+If contacting an address in the list results in a failure, as defined
+in the next paragraph, the element moves to the next address in the
+list, until the list is exhausted.  If the list is exhausted, then
+the request has failed.
+Rosenberg, et. al.          Standards Track                    [Page 43]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Failures SHOULD be detected through failure response codes (codes
+greater than 399); for network errors the client transaction will
+report any transport layer failures to the transaction user.  Note
+that some response codes (detailed in 8.1.3.5) indicate that the
+request can be retried; requests that are reattempted should not be
+considered failures.
+When a failure for a particular contact address is received, the
+client SHOULD try the next contact address.  This will involve
+creating a new client transaction to deliver a new request.
+In order to create a request based on a contact address in a 3xx
+response, a UAC MUST copy the entire URI from the target set into the
+Request-URI, except for the "method-param" and "header" URI
+parameters (see Section 19.1.1 for a definition of these parameters).
+It uses the "header" parameters to create header field values for the
+new request, overwriting header field values associated with the
+redirected request in accordance with the guidelines in Section
+19.1.5.
+Note that in some instances, header fields that have been
+communicated in the contact address may instead append to existing
+request header fields in the original redirected request.  As a
+general rule, if the header field can accept a comma-separated list
+of values, then the new header field value MAY be appended to any
+existing values in the original redirected request.  If the header
+field does not accept multiple values, the value in the original
+redirected request MAY be overwritten by the header field value
+communicated in the contact address.  For example, if a contact
+address is returned with the following value:
+sip:user@host?Subject=foo&Call-Info=<http://www.foo.com>
+Then any Subject header field in the original redirected request is
+overwritten, but the HTTP URL is merely appended to any existing
+Call-Info header field values.
+It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID
+used in the original redirected request, but the UAC MAY also choose
+to update the Call-ID header field value for new requests, for
+example.
+Finally, once the new request has been constructed, it is sent using
+a new client transaction, and therefore MUST have a new branch ID in
+the top Via field as discussed in Section 8.1.1.7.
+Rosenberg, et. al.          Standards Track                    [Page 44]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+In all other respects, requests sent upon receipt of a redirect
+response SHOULD re-use the header fields and bodies of the original
+request.
+In some instances, Contact header field values may be cached at UAC
+temporarily or permanently depending on the status code received and
+the presence of an expiration interval; see Sections 21.3.2 and
+21.3.3.
+8.1.3.5 Processing 4xx Responses
+Certain 4xx response codes require specific UA processing,
+independent of the method.
+If a 401 (Unauthorized) or 407 (Proxy Authentication Required)
+response is received, the UAC SHOULD follow the authorization
+procedures of Section 22.2 and Section 22.3 to retry the request with
+credentials.
+If a 413 (Request Entity Too Large) response is received (Section
+21.4.11), the request contained a body that was longer than the UAS
+was willing to accept.  If possible, the UAC SHOULD retry the
+request, either omitting the body or using one of a smaller length.
+If a 415 (Unsupported Media Type) response is received (Section
+21.4.13), the request contained media types not supported by the UAS.
+The UAC SHOULD retry sending the request, this time only using
+content with types listed in the Accept header field in the response,
+with encodings listed in the Accept-Encoding header field in the
+response, and with languages listed in the Accept-Language in the
+response.
+If a 416 (Unsupported URI Scheme) response is received (Section
+21.4.14), the Request-URI used a URI scheme not supported by the
+server.  The client SHOULD retry the request, this time, using a SIP
+URI.
+If a 420 (Bad Extension) response is received (Section 21.4.15), the
+request contained a Require or Proxy-Require header field listing an
+option-tag for a feature not supported by a proxy or UAS.  The UAC
+SHOULD retry the request, this time omitting any extensions listed in
+the Unsupported header field in the response.
+In all of the above cases, the request is retried by creating a new
+request with the appropriate modifications.  This new request
+constitutes a new transaction and SHOULD have the same value of the
+Call-ID, To, and From of the previous request, but the CSeq should
+contain a new sequence number that is one higher than the previous.
+Rosenberg, et. al.          Standards Track                    [Page 45]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+With other 4xx responses, including those yet to be defined, a retry
+may or may not be possible depending on the method and the use case.
+8.2 UAS Behavior
+When a request outside of a dialog is processed by a UAS, there is a
+set of processing rules that are followed, independent of the method.
+Section 12 gives guidance on how a UAS can tell whether a request is
+inside or outside of a dialog.
+Note that request processing is atomic.  If a request is accepted,
+all state changes associated with it MUST be performed.  If it is
+rejected, all state changes MUST NOT be performed.
+UASs SHOULD process the requests in the order of the steps that
+follow in this section (that is, starting with authentication, then
+inspecting the method, the header fields, and so on throughout the
+remainder of this section).
+8.2.1 Method Inspection
+Once a request is authenticated (or authentication is skipped), the
+UAS MUST inspect the method of the request.  If the UAS recognizes
+but does not support the method of a request, it MUST generate a 405
+(Method Not Allowed) response.  Procedures for generating responses
+are described in Section 8.2.6.  The UAS MUST also add an Allow
+header field to the 405 (Method Not Allowed) response.  The Allow
+header field MUST list the set of methods supported by the UAS
+generating the message.  The Allow header field is presented in
+Section 20.5.
+If the method is one supported by the server, processing continues.
+8.2.2 Header Inspection
+If a UAS does not understand a header field in a request (that is,
+the header field is not defined in this specification or in any
+supported extension), the server MUST ignore that header field and
+continue processing the message.  A UAS SHOULD ignore any malformed
+header fields that are not necessary for processing requests.
+8.2.2.1 To and Request-URI
+The To header field identifies the original recipient of the request
+designated by the user identified in the From field.  The original
+recipient may or may not be the UAS processing the request, due to
+call forwarding or other proxy operations.  A UAS MAY apply any
+policy it wishes to determine whether to accept requests when the To
+Rosenberg, et. al.          Standards Track                    [Page 46]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+header field is not the identity of the UAS.  However, it is
+RECOMMENDED that a UAS accept requests even if they do not recognize
+the URI scheme (for example, a tel: URI) in the To header field, or
+if the To header field does not address a known or current user of
+this UAS.  If, on the other hand, the UAS decides to reject the
+request, it SHOULD generate a response with a 403 (Forbidden) status
+code and pass it to the server transaction for transmission.
+However, the Request-URI identifies the UAS that is to process the
+request.  If the Request-URI uses a scheme not supported by the UAS,
+it SHOULD reject the request with a 416 (Unsupported URI Scheme)
+response.  If the Request-URI does not identify an address that the
+UAS is willing to accept requests for, it SHOULD reject the request
+with a 404 (Not Found) response.  Typically, a UA that uses the
+REGISTER method to bind its address-of-record to a specific contact
+address will see requests whose Request-URI equals that contact
+address.  Other potential sources of received Request-URIs include
+the Contact header fields of requests and responses sent by the UA
+that establish or refresh dialogs.
+8.2.2.2 Merged Requests
+If the request has no tag in the To header field, the UAS core MUST
+check the request against ongoing transactions.  If the From tag,
+Call-ID, and CSeq exactly match those associated with an ongoing
+transaction, but the request does not match that transaction (based
+on the matching rules in Section 17.2.3), the UAS core SHOULD
+generate a 482 (Loop Detected) response and pass it to the server
+transaction.
+The same request has arrived at the UAS more than once, following
+different paths, most likely due to forking.  The UAS processes
+the first such request received and responds with a 482 (Loop
+Detected) to the rest of them.
+8.2.2.3 Require
+Assuming the UAS decides that it is the proper element to process the
+request, it examines the Require header field, if present.
+The Require header field is used by a UAC to tell a UAS about SIP
+extensions that the UAC expects the UAS to support in order to
+process the request properly.  Its format is described in Section
+20.32.  If a UAS does not understand an option-tag listed in a
+Require header field, it MUST respond by generating a response with
+status code 420 (Bad Extension).  The UAS MUST add an Unsupported
+header field, and list in it those options it does not understand
+amongst those in the Require header field of the request.
+Rosenberg, et. al.          Standards Track                    [Page 47]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL
+request, or in an ACK request sent for a non-2xx response.  These
+header fields MUST be ignored if they are present in these requests.
+An ACK request for a 2xx response MUST contain only those Require and
+Proxy-Require values that were present in the initial request.
+Example:
+UAC->UAS:   INVITE sip:watson@bell-telephone.com SIP/2.0
+Require: 100rel
+UAS->UAC:   SIP/2.0 420 Bad Extension
+Unsupported: 100rel
+This behavior ensures that the client-server interaction will
+proceed without delay when all options are understood by both
+sides, and only slow down if options are not understood (as in the
+example above).  For a well-matched client-server pair, the
+interaction proceeds quickly, saving a round-trip often required
+by negotiation mechanisms.  In addition, it also removes ambiguity
+when the client requires features that the server does not
+understand.  Some features, such as call handling fields, are only
+of interest to end systems.
+8.2.3 Content Processing
+Assuming the UAS understands any extensions required by the client,
+the UAS examines the body of the message, and the header fields that
+describe it.  If there are any bodies whose type (indicated by the
+Content-Type), language (indicated by the Content-Language) or
+encoding (indicated by the Content-Encoding) are not understood, and
+that body part is not optional (as indicated by the Content-
+Disposition header field), the UAS MUST reject the request with a 415
+(Unsupported Media Type) response.  The response MUST contain an
+Accept header field listing the types of all bodies it understands,
+in the event the request contained bodies of types not supported by
+the UAS.  If the request contained content encodings not understood
+by the UAS, the response MUST contain an Accept-Encoding header field
+listing the encodings understood by the UAS.  If the request
+contained content with languages not understood by the UAS, the
+response MUST contain an Accept-Language header field indicating the
+languages understood by the UAS.  Beyond these checks, body handling
+depends on the method and type.  For further information on the
+processing of content-specific header fields, see Section 7.4 as well
+as Section 20.11 through 20.15.
+Rosenberg, et. al.          Standards Track                    [Page 48]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+8.2.4 Applying Extensions
+A UAS that wishes to apply some extension when generating the
+response MUST NOT do so unless support for that extension is
+indicated in the Supported header field in the request.  If the
+desired extension is not supported, the server SHOULD rely only on
+baseline SIP and any other extensions supported by the client.  In
+rare circumstances, where the server cannot process the request
+without the extension, the server MAY send a 421 (Extension Required)
+response.  This response indicates that the proper response cannot be
+generated without support of a specific extension.  The needed
+extension(s) MUST be included in a Require header field in the
+response.  This behavior is NOT RECOMMENDED, as it will generally
+break interoperability.
+Any extensions applied to a non-421 response MUST be listed in a
+Require header field included in the response.  Of course, the server
+MUST NOT apply extensions not listed in the Supported header field in
+the request.  As a result of this, the Require header field in a
+response will only ever contain option tags defined in standards-
+track RFCs.
+8.2.5 Processing the Request
+Assuming all of the checks in the previous subsections are passed,
+the UAS processing becomes method-specific.  Section 10 covers the
+REGISTER request, Section 11 covers the OPTIONS request, Section 13
+covers the INVITE request, and Section 15 covers the BYE request.
+8.2.6 Generating the Response
+When a UAS wishes to construct a response to a request, it follows
+the general procedures detailed in the following subsections.
+Additional behaviors specific to the response code in question, which
+are not detailed in this section, may also be required.
+Once all procedures associated with the creation of a response have
+been completed, the UAS hands the response back to the server
+transaction from which it received the request.
+8.2.6.1 Sending a Provisional Response
+One largely non-method-specific guideline for the generation of
+responses is that UASs SHOULD NOT issue a provisional response for a
+non-INVITE request.  Rather, UASs SHOULD generate a final response to
+a non-INVITE request as soon as possible.
+Rosenberg, et. al.          Standards Track                    [Page 49]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+When a 100 (Trying) response is generated, any Timestamp header field
+present in the request MUST be copied into this 100 (Trying)
+response.  If there is a delay in generating the response, the UAS
+SHOULD add a delay value into the Timestamp value in the response.
+This value MUST contain the difference between the time of sending of
+the response and receipt of the request, measured in seconds.
+8.2.6.2 Headers and Tags
+The From field of the response MUST equal the From header field of
+the request.  The Call-ID header field of the response MUST equal the
+Call-ID header field of the request.  The CSeq header field of the
+response MUST equal the CSeq field of the request.  The Via header
+field values in the response MUST equal the Via header field values
+in the request and MUST maintain the same ordering.
+If a request contained a To tag in the request, the To header field
+in the response MUST equal that of the request.  However, if the To
+header field in the request did not contain a tag, the URI in the To
+header field in the response MUST equal the URI in the To header
+field; additionally, the UAS MUST add a tag to the To header field in
+the response (with the exception of the 100 (Trying) response, in
+which a tag MAY be present).  This serves to identify the UAS that is
+responding, possibly resulting in a component of a dialog ID.  The
+same tag MUST be used for all responses to that request, both final
+and provisional (again excepting the 100 (Trying)).  Procedures for
+the generation of tags are defined in Section 19.3.
+8.2.7 Stateless UAS Behavior
+A stateless UAS is a UAS that does not maintain transaction state.
+It replies to requests normally, but discards any state that would
+ordinarily be retained by a UAS after a response has been sent.  If a
+stateless UAS receives a retransmission of a request, it regenerates
+the response and resends it, just as if it were replying to the first
+instance of the request. A UAS cannot be stateless unless the request
+processing for that method would always result in the same response
+if the requests are identical. This rules out stateless registrars,
+for example.  Stateless UASs do not use a transaction layer; they
+receive requests directly from the transport layer and send responses
+directly to the transport layer.
+The stateless UAS role is needed primarily to handle unauthenticated
+requests for which a challenge response is issued.  If
+unauthenticated requests were handled statefully, then malicious
+floods of unauthenticated requests could create massive amounts of
+Rosenberg, et. al.          Standards Track                    [Page 50]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+transaction state that might slow or completely halt call processing
+in a UAS, effectively creating a denial of service condition; for
+more information see Section 26.1.5.
+The most important behaviors of a stateless UAS are the following:
+o  A stateless UAS MUST NOT send provisional (1xx) responses.
+o  A stateless UAS MUST NOT retransmit responses.
+o  A stateless UAS MUST ignore ACK requests.
+o  A stateless UAS MUST ignore CANCEL requests.
+o  To header tags MUST be generated for responses in a stateless
+manner - in a manner that will generate the same tag for the
+same request consistently.  For information on tag construction
+see Section 19.3.
+In all other respects, a stateless UAS behaves in the same manner as
+a stateful UAS.  A UAS can operate in either a stateful or stateless
+mode for each new request.
+8.3 Redirect Servers
+In some architectures it may be desirable to reduce the processing
+load on proxy servers that are responsible for routing requests, and
+improve signaling path robustness, by relying on redirection.
+Redirection allows servers to push routing information for a request
+back in a response to the client, thereby taking themselves out of
+the loop of further messaging for this transaction while still aiding
+in locating the target of the request.  When the originator of the
+request receives the redirection, it will send a new request based on
+the URI(s) it has received.  By propagating URIs from the core of the
+network to its edges, redirection allows for considerable network
+scalability.
+A redirect server is logically constituted of a server transaction
+layer and a transaction user that has access to a location service of
+some kind (see Section 10 for more on registrars and location
+services).  This location service is effectively a database
+containing mappings between a single URI and a set of one or more
+alternative locations at which the target of that URI can be found.
+A redirect server does not issue any SIP requests of its own.  After
+receiving a request other than CANCEL, the server either refuses the
+request or gathers the list of alternative locations from the
+Rosenberg, et. al.          Standards Track                    [Page 51]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+location service and returns a final response of class 3xx.  For
+well-formed CANCEL requests, it SHOULD return a 2xx response.  This
+response ends the SIP transaction.  The redirect server maintains
+transaction state for an entire SIP transaction.  It is the
+responsibility of clients to detect forwarding loops between redirect
+servers.
+When a redirect server returns a 3xx response to a request, it
+populates the list of (one or more) alternative locations into the
+Contact header field.  An "expires" parameter to the Contact header
+field values may also be supplied to indicate the lifetime of the
+Contact data.
+The Contact header field contains URIs giving the new locations or
+user names to try, or may simply specify additional transport
+parameters.  A 301 (Moved Permanently) or 302 (Moved Temporarily)
+response may also give the same location and username that was
+targeted by the initial request but specify additional transport
+parameters such as a different server or multicast address to try, or
+a change of SIP transport from UDP to TCP or vice versa.
+However, redirect servers MUST NOT redirect a request to a URI equal
+to the one in the Request-URI; instead, provided that the URI does
+not point to itself, the server MAY proxy the request to the
+destination URI, or MAY reject it with a 404.
+If a client is using an outbound proxy, and that proxy actually
+redirects requests, a potential arises for infinite redirection
+loops.
+Note that a Contact header field value MAY also refer to a different
+resource than the one originally called.  For example, a SIP call
+connected to PSTN gateway may need to deliver a special informational
+announcement such as "The number you have dialed has been changed."
+A Contact response header field can contain any suitable URI
+indicating where the called party can be reached, not limited to SIP
+URIs.  For example, it could contain URIs for phones, fax, or irc (if
+they were defined) or a mailto:  (RFC 2368 [32]) URL.  Section 26.4.4
+discusses implications and limitations of redirecting a SIPS URI to a
+non-SIPS URI.
+The "expires" parameter of a Contact header field value indicates how
+long the URI is valid.  The value of the parameter is a number
+indicating seconds.  If this parameter is not provided, the value of
+the Expires header field determines how long the URI is valid.
+Malformed values SHOULD be treated as equivalent to 3600.
+Rosenberg, et. al.          Standards Track                    [Page 52]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+This provides a modest level of backwards compatibility with RFC
+2543, which allowed absolute times in this header field.  If an
+absolute time is received, it will be treated as malformed, and
+then default to 3600.
+Redirect servers MUST ignore features that are not understood
+(including unrecognized header fields, any unknown option tags in
+Require, or even method names) and proceed with the redirection of
+the request in question.
+9 Canceling a Request
+The previous section has discussed general UA behavior for generating
+requests and processing responses for requests of all methods.  In
+this section, we discuss a general purpose method, called CANCEL.
+The CANCEL request, as the name implies, is used to cancel a previous
+request sent by a client.  Specifically, it asks the UAS to cease
+processing the request and to generate an error response to that
+request.  CANCEL has no effect on a request to which a UAS has
+already given a final response.  Because of this, it is most useful
+to CANCEL requests to which it can take a server long time to
+respond.  For this reason, CANCEL is best for INVITE requests, which
+can take a long time to generate a response.  In that usage, a UAS
+that receives a CANCEL request for an INVITE, but has not yet sent a
+final response, would "stop ringing", and then respond to the INVITE
+with a specific error response (a 487).
+CANCEL requests can be constructed and sent by both proxies and user
+agent clients.  Section 15 discusses under what conditions a UAC
+would CANCEL an INVITE request, and Section 16.10 discusses proxy
+usage of CANCEL.
+A stateful proxy responds to a CANCEL, rather than simply forwarding
+a response it would receive from a downstream element.  For that
+reason, CANCEL is referred to as a "hop-by-hop" request, since it is
+responded to at each stateful proxy hop.
+9.1 Client Behavior
+A CANCEL request SHOULD NOT be sent to cancel a request other than
+INVITE.
+Since requests other than INVITE are responded to immediately,
+sending a CANCEL for a non-INVITE request would always create a
+race condition.
+Rosenberg, et. al.          Standards Track                    [Page 53]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The following procedures are used to construct a CANCEL request.  The
+Request-URI, Call-ID, To, the numeric part of CSeq, and From header
+fields in the CANCEL request MUST be identical to those in the
+request being cancelled, including tags.  A CANCEL constructed by a
+client MUST have only a single Via header field value matching the
+top Via value in the request being cancelled.  Using the same values
+for these header fields allows the CANCEL to be matched with the
+request it cancels (Section 9.2 indicates how such matching occurs).
+However, the method part of the CSeq header field MUST have a value
+of CANCEL.  This allows it to be identified and processed as a
+transaction in its own right (See Section 17).
+If the request being cancelled contains a Route header field, the
+CANCEL request MUST include that Route header field's values.
+This is needed so that stateless proxies are able to route CANCEL
+requests properly.
+The CANCEL request MUST NOT contain any Require or Proxy-Require
+header fields.
+Once the CANCEL is constructed, the client SHOULD check whether it
+has received any response (provisional or final) for the request
+being cancelled (herein referred to as the "original request").
+If no provisional response has been received, the CANCEL request MUST
+NOT be sent; rather, the client MUST wait for the arrival of a
+provisional response before sending the request.  If the original
+request has generated a final response, the CANCEL SHOULD NOT be
+sent, as it is an effective no-op, since CANCEL has no effect on
+requests that have already generated a final response.  When the
+client decides to send the CANCEL, it creates a client transaction
+for the CANCEL and passes it the CANCEL request along with the
+destination address, port, and transport.  The destination address,
+port, and transport for the CANCEL MUST be identical to those used to
+send the original request.
+If it was allowed to send the CANCEL before receiving a response
+for the previous request, the server could receive the CANCEL
+before the original request.
+Note that both the transaction corresponding to the original request
+and the CANCEL transaction will complete independently.  However, a
+UAC canceling a request cannot rely on receiving a 487 (Request
+Terminated) response for the original request, as an RFC 2543-
+compliant UAS will not generate such a response.  If there is no
+final response for the original request in 64*T1 seconds (T1 is
+Rosenberg, et. al.          Standards Track                    [Page 54]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+defined in Section 17.1.1.1), the client SHOULD then consider the
+original transaction cancelled and SHOULD destroy the client
+transaction handling the original request.
+9.2 Server Behavior
+The CANCEL method requests that the TU at the server side cancel a
+pending transaction.  The TU determines the transaction to be
+cancelled by taking the CANCEL request, and then assuming that the
+request method is anything but CANCEL or ACK and applying the
+transaction matching procedures of Section 17.2.3.  The matching
+transaction is the one to be cancelled.
+The processing of a CANCEL request at a server depends on the type of
+server.  A stateless proxy will forward it, a stateful proxy might
+respond to it and generate some CANCEL requests of its own, and a UAS
+will respond to it.  See Section 16.10 for proxy treatment of CANCEL.
+A UAS first processes the CANCEL request according to the general UAS
+processing described in Section 8.2.  However, since CANCEL requests
+are hop-by-hop and cannot be resubmitted, they cannot be challenged
+by the server in order to get proper credentials in an Authorization
+header field.  Note also that CANCEL requests do not contain a
+Require header field.
+If the UAS did not find a matching transaction for the CANCEL
+according to the procedure above, it SHOULD respond to the CANCEL
+with a 481 (Call Leg/Transaction Does Not Exist).  If the transaction
+for the original request still exists, the behavior of the UAS on
+receiving a CANCEL request depends on whether it has already sent a
+final response for the original request.  If it has, the CANCEL
+request has no effect on the processing of the original request, no
+effect on any session state, and no effect on the responses generated
+for the original request.  If the UAS has not issued a final response
+for the original request, its behavior depends on the method of the
+original request.  If the original request was an INVITE, the UAS
+SHOULD immediately respond to the INVITE with a 487 (Request
+Terminated).  A CANCEL request has no impact on the processing of
+transactions with any other method defined in this specification.
+Regardless of the method of the original request, as long as the
+CANCEL matched an existing transaction, the UAS answers the CANCEL
+request itself with a 200 (OK) response.  This response is
+constructed following the procedures described in Section 8.2.6
+noting that the To tag of the response to the CANCEL and the To tag
+in the response to the original request SHOULD be the same.  The
+response to CANCEL is passed to the server transaction for
+transmission.
+Rosenberg, et. al.          Standards Track                    [Page 55]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+10 Registrations
+10.1 Overview
+SIP offers a discovery capability.  If a user wants to initiate a
+session with another user, SIP must discover the current host(s) at
+which the destination user is reachable.  This discovery process is
+frequently accomplished by SIP network elements such as proxy servers
+and redirect servers which are responsible for receiving a request,
+determining where to send it based on knowledge of the location of
+the user, and then sending it there.  To do this, SIP network
+elements consult an abstract service known as a location service,
+which provides address bindings for a particular domain.  These
+address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com,
+for example, to one or more URIs that are somehow "closer" to the
+desired user, sip:bob@engineering.biloxi.com, for example.
+Ultimately, a proxy will consult a location service that maps a
+received URI to the user agent(s) at which the desired recipient is
+currently residing.
+Registration creates bindings in a location service for a particular
+domain that associates an address-of-record URI with one or more
+contact addresses.  Thus, when a proxy for that domain receives a
+request whose Request-URI matches the address-of-record, the proxy
+will forward the request to the contact addresses registered to that
+address-of-record.  Generally, it only makes sense to register an
+address-of-record at a domain's location service when requests for
+that address-of-record would be routed to that domain.  In most
+cases, this means that the domain of the registration will need to
+match the domain in the URI of the address-of-record.
+There are many ways by which the contents of the location service can
+be established.  One way is administratively.  In the above example,
+Bob is known to be a member of the engineering department through
+access to a corporate database.  However, SIP provides a mechanism
+for a UA to create a binding explicitly.  This mechanism is known as
+registration.
+Registration entails sending a REGISTER request to a special type of
+UAS known as a registrar.  A registrar acts as the front end to the
+location service for a domain, reading and writing mappings based on
+the contents of REGISTER requests.  This location service is then
+typically consulted by a proxy server that is responsible for routing
+requests for that domain.
+An illustration of the overall registration process is given in
+Figure 2.  Note that the registrar and proxy server are logical roles
+that can be played by a single device in a network; for purposes of
+Rosenberg, et. al.          Standards Track                    [Page 56]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+clarity the two are separated in this illustration.  Also note that
+UAs may send requests through a proxy server in order to reach a
+registrar if the two are separate elements.
+SIP does not mandate a particular mechanism for implementing the
+location service.  The only requirement is that a registrar for some
+domain MUST be able to read and write data to the location service,
+and a proxy or a redirect server for that domain MUST be capable of
+reading that same data.  A registrar MAY be co-located with a
+particular SIP proxy server for the same domain.
+10.2 Constructing the REGISTER Request
+REGISTER requests add, remove, and query bindings.  A REGISTER
+request can add a new binding between an address-of-record and one or
+more contact addresses.  Registration on behalf of a particular
+address-of-record can be performed by a suitably authorized third
+party.  A client can also remove previous bindings or query to
+determine which bindings are currently in place for an address-of-
+record.
+Except as noted, the construction of the REGISTER request and the
+behavior of clients sending a REGISTER request is identical to the
+general UAC behavior described in Section 8.1 and Section 17.1.
+A REGISTER request does not establish a dialog.  A UAC MAY include a
+Route header field in a REGISTER request based on a pre-existing
+route set as described in Section 8.1.  The Record-Route header field
+has no meaning in REGISTER requests or responses, and MUST be ignored
+if present.  In particular, the UAC MUST NOT create a new route set
+based on the presence or absence of a Record-Route header field in
+any response to a REGISTER request.
+The following header fields, except Contact, MUST be included in a
+REGISTER request.  A Contact header field MAY be included:
+Request-URI: The Request-URI names the domain of the location
+service for which the registration is meant (for example,
+"sip:chicago.com").  The "userinfo" and "@" components of the
+SIP URI MUST NOT be present.
+To: The To header field contains the address of record whose
+registration is to be created, queried, or modified.  The To
+header field and the Request-URI field typically differ, as
+the former contains a user name.  This address-of-record MUST
+be a SIP URI or SIPS URI.
+Rosenberg, et. al.          Standards Track                    [Page 57]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+From: The From header field contains the address-of-record of the
+person responsible for the registration.  The value is the
+same as the To header field unless the request is a third-
+party registration.
+Call-ID: All registrations from a UAC SHOULD use the same Call-ID
+header field value for registrations sent to a particular
+registrar.
+If the same client were to use different Call-ID values, a
+registrar could not detect whether a delayed REGISTER request
+might have arrived out of order.
+CSeq: The CSeq value guarantees proper ordering of REGISTER
+requests.  A UA MUST increment the CSeq value by one for each
+REGISTER request with the same Call-ID.
+Contact: REGISTER requests MAY contain a Contact header field with
+zero or more values containing address bindings.
+UAs MUST NOT send a new registration (that is, containing new Contact
+header field values, as opposed to a retransmission) until they have
+received a final response from the registrar for the previous one or
+the previous REGISTER request has timed out.
+Rosenberg, et. al.          Standards Track                    [Page 58]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+bob
++----+
+| UA |
+|    |
++----+
+|
+|3)INVITE
+|   carol@chicago.com
+chicago.com        +--------+            V
++---------+ 2)Store|Location|4)Query +-----+
+|Registrar|=======>| Service|<=======|Proxy|sip.chicago.com
++---------+        +--------+=======>+-----+
+A                      5)Resp      |
+|                                  |
+|                                  |
+1)REGISTER|                                  |
+|                                  |
++----+                                |
+| UA |<-------------------------------+
+cube2214a|    |                            6)INVITE
++----+                    carol@cube2214a.chicago.com
+carol
+Figure 2: REGISTER example
+The following Contact header parameters have a special meaning in
+REGISTER requests:
+action: The "action" parameter from RFC 2543 has been deprecated.
+UACs SHOULD NOT use the "action" parameter.
+expires: The "expires" parameter indicates how long the UA would
+like the binding to be valid.  The value is a number
+indicating seconds.  If this parameter is not provided, the
+value of the Expires header field is used instead.
+Implementations MAY treat values larger than 2**32-1
+(4294967295 seconds or 136 years) as equivalent to 2**32-1.
+Malformed values SHOULD be treated as equivalent to 3600.
+10.2.1 Adding Bindings
+The REGISTER request sent to a registrar includes the contact
+address(es) to which SIP requests for the address-of-record should be
+forwarded.  The address-of-record is included in the To header field
+of the REGISTER request.
+Rosenberg, et. al.          Standards Track                    [Page 59]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The Contact header field values of the request typically consist of
+SIP or SIPS URIs that identify particular SIP endpoints (for example,
+"sip:carol@cube2214a.chicago.com"), but they MAY use any URI scheme.
+A SIP UA can choose to register telephone numbers (with the tel URL,
+RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32])
+as Contacts for an address-of-record, for example.
+For example, Carol, with address-of-record "sip:carol@chicago.com",
+would register with the SIP registrar of the domain chicago.com.  Her
+registrations would then be used by a proxy server in the chicago.com
+domain to route requests for Carol's address-of-record to her SIP
+endpoint.
+Once a client has established bindings at a registrar, it MAY send
+subsequent registrations containing new bindings or modifications to
+existing bindings as necessary.  The 2xx response to the REGISTER
+request will contain, in a Contact header field, a complete list of
+bindings that have been registered for this address-of-record at this
+registrar.
+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.
+Registrations do not need to update all bindings.  Typically, a UA
+only updates its own contact addresses.
+10.2.1.1 Setting the Expiration Interval of Contact Addresses
+When a client sends a REGISTER request, it MAY suggest an expiration
+interval that indicates how long the client would like the
+registration to be valid.  (As described in Section 10.3, the
+registrar selects the actual time interval based on its local
+policy.)
+There are two ways in which a client can suggest an expiration
+interval for a binding: through an Expires header field or an
+"expires" Contact header parameter.  The latter allows expiration
+intervals to be suggested on a per-binding basis when more than one
+binding is given in a single REGISTER request, whereas the former
+suggests an expiration interval for all Contact header field values
+that do not contain the "expires" parameter.
+Rosenberg, et. al.          Standards Track                    [Page 60]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+If neither mechanism for expressing a suggested expiration time is
+present in a REGISTER, the client is indicating its desire for the
+server to choose.
+10.2.1.2 Preferences among Contact Addresses
+If more than one Contact is sent in a REGISTER request, the
+registering UA intends to associate all of the URIs in these Contact
+header field values with the address-of-record present in the To
+field.  This list can be prioritized with the "q" parameter in the
+Contact header field.  The "q" parameter indicates a relative
+preference for the particular Contact header field value compared to
+other bindings for this address-of-record.  Section 16.6 describes
+how a proxy server uses this preference indication.
+10.2.2 Removing Bindings
+Registrations are soft state and expire unless refreshed, but can
+also be explicitly removed.  A client can attempt to influence the
+expiration interval selected by the registrar as described in Section
+10.2.1.  A UA requests the immediate removal of a binding by
+specifying an expiration interval of "0" for that contact address in
+a REGISTER request.  UAs SHOULD support this mechanism so that
+bindings can be removed before their expiration interval has passed.
+The REGISTER-specific Contact header field value of "*" applies to
+all registrations, but it MUST NOT be used unless the Expires header
+field is present with a value of "0".
+Use of the "*" Contact header field value allows a registering UA
+to remove all bindings associated with an address-of-record
+without knowing their precise values.
+10.2.3 Fetching Bindings
+A success response to any REGISTER request contains the complete list
+of existing bindings, regardless of whether the request contained a
+Contact header field.  If no Contact header field is present in a
+REGISTER request, the list of bindings is left unchanged.
+10.2.4 Refreshing Bindings
+Each UA is responsible for refreshing the bindings that it has
+previously established.  A UA SHOULD NOT refresh bindings set up by
+other UAs.
+Rosenberg, et. al.          Standards Track                    [Page 61]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The 200 (OK) response from the registrar contains a list of Contact
+fields enumerating all current bindings.  The UA compares each
+contact address to see if it created the contact address, using
+comparison rules in Section 19.1.4.  If so, it updates the expiration
+time interval according to the expires parameter or, if absent, the
+Expires field value.  The UA then issues a REGISTER request for each
+of its bindings before the expiration interval has elapsed.  It MAY
+combine several updates into one REGISTER request.
+A UA SHOULD use the same Call-ID for all registrations during a
+single boot cycle.  Registration refreshes SHOULD be sent to the same
+network address as the original registration, unless redirected.
+10.2.5 Setting the Internal Clock
+If the response for a REGISTER request contains a Date header field,
+the client MAY use this header field to learn the current time in
+order to set any internal clocks.
+10.2.6 Discovering a Registrar
+UAs can use three ways to determine the address to which to send
+registrations:  by configuration, using the address-of-record, and
+multicast.  A UA can be configured, in ways beyond the scope of this
+specification, with a registrar address.  If there is no configured
+registrar address, the UA SHOULD use the host part of the address-
+of-record as the Request-URI and address the request there, using the
+normal SIP server location mechanisms [4].  For example, the UA for
+the user "sip:carol@chicago.com" addresses the REGISTER request to
+"sip:chicago.com".
+Finally, a UA can be configured to use multicast.  Multicast
+registrations are addressed to the well-known "all SIP servers"
+multicast address "sip.mcast.net" (224.0.1.75 for IPv4).  No well-
+known IPv6 multicast address has been allocated; such an allocation
+will be documented separately when needed.  SIP UAs MAY listen to
+that address and use it to become aware of the location of other
+local users (see [33]); however, they do not respond to the request.
+Multicast registration may be inappropriate in some environments,
+for example, if multiple businesses share the same local area
+network.
+10.2.7 Transmitting a Request
+Once the REGISTER method has been constructed, and the destination of
+the message identified, UACs follow the procedures described in
+Section 8.1.2 to hand off the REGISTER to the transaction layer.
+Rosenberg, et. al.          Standards Track                    [Page 62]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+If the transaction layer returns a timeout error because the REGISTER
+yielded no response, the UAC SHOULD NOT immediately re-attempt a
+registration to the same registrar.
+An immediate re-attempt is likely to also timeout.  Waiting some
+reasonable time interval for the conditions causing the timeout to
+be corrected reduces unnecessary load on the network.  No specific
+interval is mandated.
+10.2.8 Error Responses
+If a UA receives a 423 (Interval Too Brief) response, it MAY retry
+the registration after making the expiration interval of all contact
+addresses in the REGISTER request equal to or greater than the
+expiration interval within the Min-Expires header field of the 423
+(Interval Too Brief) response.
+10.3 Processing REGISTER Requests
+A registrar is a UAS that responds to REGISTER requests and maintains
+a list of bindings that are accessible to proxy servers and redirect
+servers within its administrative domain.  A registrar handles
+requests according to Section 8.2 and Section 17.2, but it accepts
+only REGISTER requests.  A registrar MUST not generate 6xx responses.
+A registrar MAY redirect REGISTER requests as appropriate.  One
+common usage would be for a registrar listening on a multicast
+interface to redirect multicast REGISTER requests to its own unicast
+interface with a 302 (Moved Temporarily) response.
+Registrars MUST ignore the Record-Route header field if it is
+included in a REGISTER request.  Registrars MUST NOT include a
+Record-Route header field in any response to a REGISTER request.
+A registrar might receive a request that traversed a proxy which
+treats REGISTER as an unknown request and which added a Record-
+Route header field value.
+A registrar has to know (for example, through configuration) the set
+of domain(s) for which it maintains bindings.  REGISTER requests MUST
+be processed by a registrar in the order that they are received.
+REGISTER requests MUST also be processed atomically, meaning that a
+particular REGISTER request is either processed completely or not at
+all.  Each REGISTER message MUST be processed independently of any
+other registration or binding changes.
+Rosenberg, et. al.          Standards Track                    [Page 63]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+When receiving a REGISTER request, a registrar follows these steps:
+1. The registrar inspects the Request-URI to determine whether it
+has access to bindings for the domain identified in the
+Request-URI.  If not, and if the server also acts as a proxy
+server, the server SHOULD forward the request to the addressed
+domain, following the general behavior for proxying messages
+described in Section 16.
+2. To guarantee that the registrar supports any necessary
+extensions, the registrar MUST process the Require header field
+values as described for UASs in Section 8.2.2.
+3. A registrar SHOULD authenticate the UAC.  Mechanisms for the
+authentication of SIP user agents are described in Section 22.
+Registration behavior in no way overrides the generic
+authentication framework for SIP.  If no authentication
+mechanism is available, the registrar MAY take the From address
+as the asserted identity of the originator of the request.
+4. The registrar SHOULD determine if the authenticated user is
+authorized to modify registrations for this address-of-record.
+For example, a registrar might consult an authorization
+database that maps user names to a list of addresses-of-record
+for which that user has authorization to modify bindings.  If
+the authenticated user is not authorized to modify bindings,
+the registrar MUST return a 403 (Forbidden) and skip the
+remaining steps.
+In architectures that support third-party registration, one
+entity may be responsible for updating the registrations
+associated with multiple addresses-of-record.
+5. The registrar extracts the address-of-record from the To header
+field of the request.  If the address-of-record is not valid
+for the domain in the Request-URI, the registrar MUST send a
+404 (Not Found) response and skip the remaining steps.  The URI
+MUST then be converted to a canonical form.  To do that, all
+URI parameters MUST be removed (including the user-param), and
+any escaped characters MUST be converted to their unescaped
+form.  The result serves as an index into the list of bindings.
+Rosenberg, et. al.          Standards Track                    [Page 64]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+6. The registrar checks whether the request contains the Contact
+header field.  If not, it skips to the last step.  If the
+Contact header field is present, the registrar checks if there
+is one Contact field value that contains the special value "*"
+and an Expires field.  If the request has additional Contact
+fields or an expiration time other than zero, the request is
+invalid, and the server MUST return a 400 (Invalid Request) and
+skip the remaining steps.  If not, the registrar checks whether
+the Call-ID agrees with the value stored for each binding.  If
+not, it MUST remove the binding.  If it does agree, it MUST
+remove the binding only if the CSeq in the request is higher
+than the value stored for that binding.  Otherwise, the update
+MUST be aborted and the request fails.
+7. The registrar now processes each contact address in the Contact
+header field in turn.  For each address, it determines the
+expiration interval as follows:
+-  If the field value has an "expires" parameter, that value
+MUST be taken as the requested expiration.
+-  If there is no such parameter, but the request has an
+Expires header field, that value MUST be taken as the
+requested expiration.
+-  If there is neither, a locally-configured default value MUST
+be taken as the requested expiration.
+The registrar MAY choose an expiration less than the requested
+expiration interval.  If and only if the requested expiration
+interval is greater than zero AND smaller than one hour AND
+less than a registrar-configured minimum, the registrar MAY
+reject the registration with a response of 423 (Interval Too
+Brief).  This response MUST contain a Min-Expires header field
+that states the minimum expiration interval the registrar is
+willing to honor.  It then skips the remaining steps.
+Allowing the registrar to set the registration interval
+protects it against excessively frequent registration refreshes
+while limiting the state that it needs to maintain and
+decreasing the likelihood of registrations going stale.  The
+expiration interval of a registration is frequently used in the
+creation of services.  An example is a follow-me service, where
+the user may only be available at a terminal for a brief
+period.  Therefore, registrars should accept brief
+registrations; a request should only be rejected if the
+interval is so short that the refreshes would degrade registrar
+performance.
+Rosenberg, et. al.          Standards Track                    [Page 65]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+For each address, the registrar then searches the list of
+current bindings using the URI comparison rules.  If the
+binding does not exist, it is tentatively added.  If the
+binding does exist, the registrar checks the Call-ID value.  If
+the Call-ID value in the existing binding differs from the
+Call-ID value in the request, the binding MUST be removed if
+the expiration time is zero and updated otherwise.  If they are
+the same, the registrar compares the CSeq value.  If the value
+is higher than that of the existing binding, it MUST update or
+remove the binding as above.  If not, the update MUST be
+aborted and the request fails.
+This algorithm ensures that out-of-order requests from the same
+UA are ignored.
+Each binding record records the Call-ID and CSeq values from
+the request.
+The binding updates MUST be committed (that is, made visible to
+the proxy or redirect server) if and only if all binding
+updates and additions succeed.  If any one of them fails (for
+example, because the back-end database commit failed), the
+request MUST fail with a 500 (Server Error) response and all
+tentative binding updates MUST be removed.
+8. The registrar returns a 200 (OK) response.  The response MUST
+contain Contact header field values enumerating all current
+bindings.  Each Contact value MUST feature an "expires"
+parameter indicating its expiration interval chosen by the
+registrar.  The response SHOULD include a Date header field.
+11 Querying for Capabilities
+The SIP method OPTIONS allows a UA to query another UA or a proxy
+server as to its capabilities.  This allows a client to discover
+information about the supported methods, content types, extensions,
+codecs, etc. without "ringing" the other party.  For example, before
+a client inserts a Require header field into an INVITE listing an
+option that it is not certain the destination UAS supports, the
+client can query the destination UAS with an OPTIONS to see if this
+option is returned in a Supported header field.  All UAs MUST support
+the OPTIONS method.
+The target of the OPTIONS request is identified by the Request-URI,
+which could identify another UA or a SIP server.  If the OPTIONS is
+addressed to a proxy server, the Request-URI is set without a user
+part, similar to the way a Request-URI is set for a REGISTER request.
+Rosenberg, et. al.          Standards Track                    [Page 66]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Alternatively, a server receiving an OPTIONS request with a Max-
+Forwards header field value of 0 MAY respond to the request
+regardless of the Request-URI.
+This behavior is common with HTTP/1.1.  This behavior can be used
+as a "traceroute" functionality to check the capabilities of
+individual hop servers by sending a series of OPTIONS requests
+with incremented Max-Forwards values.
+As is the case for general UA behavior, the transaction layer can
+return a timeout error if the OPTIONS yields no response.  This may
+indicate that the target is unreachable and hence unavailable.
+An OPTIONS request MAY be sent as part of an established dialog to
+query the peer on capabilities that may be utilized later in the
+dialog.
+11.1 Construction of OPTIONS Request
+An OPTIONS request is constructed using the standard rules for a SIP
+request as discussed in Section 8.1.1.
+A Contact header field MAY be present in an OPTIONS.
+An Accept header field SHOULD be included to indicate the type of
+message body the UAC wishes to receive in the response.  Typically,
+this is set to a format that is used to describe the media
+capabilities of a UA, such as SDP (application/sdp).
+The response to an OPTIONS request is assumed to be scoped to the
+Request-URI in the original request.  However, only when an OPTIONS
+is sent as part of an established dialog is it guaranteed that future
+requests will be received by the server that generated the OPTIONS
+response.
+Example OPTIONS request:
+OPTIONS sip:carol@chicago.com SIP/2.0
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
+Max-Forwards: 70
+To: <sip:carol@chicago.com>
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 63104 OPTIONS
+Contact: <sip:alice@pc33.atlanta.com>
+Accept: application/sdp
+Content-Length: 0
+Rosenberg, et. al.          Standards Track                    [Page 67]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+11.2 Processing of OPTIONS Request
+The response to an OPTIONS is constructed using the standard rules
+for a SIP response as discussed in Section 8.2.6.  The response code
+chosen MUST be the same that would have been chosen had the request
+been an INVITE.  That is, a 200 (OK) would be returned if the UAS is
+ready to accept a call, a 486 (Busy Here) would be returned if the
+UAS is busy, etc.  This allows an OPTIONS request to be used to
+determine the basic state of a UAS, which can be an indication of
+whether the UAS will accept an INVITE request.
+An OPTIONS request received within a dialog generates a 200 (OK)
+response that is identical to one constructed outside a dialog and
+does not have any impact on the dialog.
+This use of OPTIONS has limitations due to the differences in proxy
+handling of OPTIONS and INVITE requests.  While a forked INVITE can
+result in multiple 200 (OK) responses being returned, a forked
+OPTIONS will only result in a single 200 (OK) response, since it is
+treated by proxies using the non-INVITE handling.  See Section 16.7
+for the normative details.
+If the response to an OPTIONS is generated by a proxy server, the
+proxy returns a 200 (OK), listing the capabilities of the server.
+The response does not contain a message body.
+Allow, Accept, Accept-Encoding, Accept-Language, and Supported header
+fields SHOULD be present in a 200 (OK) response to an OPTIONS
+request.  If the response is generated by a proxy, the Allow header
+field SHOULD be omitted as it is ambiguous since a proxy is method
+agnostic.  Contact header fields MAY be present in a 200 (OK)
+response and have the same semantics as in a 3xx response.  That is,
+they may list a set of alternative names and methods of reaching the
+user.  A Warning header field MAY be present.
+A message body MAY be sent, the type of which is determined by the
+Accept header field in the OPTIONS request (application/sdp is the
+default if the Accept header field is not present).  If the types
+include one that can describe media capabilities, the UAS SHOULD
+include a body in the response for that purpose.  Details on the
+construction of such a body in the case of application/sdp are
+described in [13].
+Rosenberg, et. al.          Standards Track                    [Page 68]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Example OPTIONS response generated by a UAS (corresponding to the
+request in Section 11.1):
+SIP/2.0 200 OK
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
+;received=192.0.2.4
+To: <sip:carol@chicago.com>;tag=93810874
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 63104 OPTIONS
+Contact: <sip:carol@chicago.com>
+Contact: <mailto:carol@chicago.com>
+Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
+Accept: application/sdp
+Accept-Encoding: gzip
+Accept-Language: en
+Supported: foo
+Content-Type: application/sdp
+Content-Length: 274
+(SDP not shown)
+12 Dialogs
+A key concept for a user agent is that of a dialog.  A dialog
+represents a peer-to-peer SIP relationship between two user agents
+that persists for some time.  The dialog facilitates sequencing of
+messages between the user agents and proper routing of requests
+between both of them.  The dialog represents a context in which to
+interpret SIP messages.  Section 8 discussed method independent UA
+processing for requests and responses outside of a dialog.  This
+section discusses how those requests and responses are used to
+construct a dialog, and then how subsequent requests and responses
+are sent within a dialog.
+A dialog is identified at each UA with a dialog ID, which consists of
+a Call-ID value, a local tag and a remote tag.  The dialog ID at each
+UA involved in the dialog is not the same.  Specifically, the local
+tag at one UA is identical to the remote tag at the peer UA.  The
+tags are opaque tokens that facilitate the generation of unique
+dialog IDs.
+A dialog ID is also associated with all responses and with any
+request that contains a tag in the To field.  The rules for computing
+the dialog ID of a message depend on whether the SIP element is a UAC
+or UAS.  For a UAC, the Call-ID value of the dialog ID is set to the
+Call-ID of the message, the remote tag is set to the tag in the To
+field of the message, and the local tag is set to the tag in the From
+Rosenberg, et. al.          Standards Track                    [Page 69]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+field of the message (these rules apply to both requests and
+responses).  As one would expect for a UAS, the Call-ID value of the
+dialog ID is set to the Call-ID of the message, the remote tag is set
+to the tag in the From field of the message, and the local tag is set
+to the tag in the To field of the message.
+A dialog contains certain pieces of state needed for further message
+transmissions within the dialog.  This state consists of the dialog
+ID, a local sequence number (used to order requests from the UA to
+its peer), a remote sequence number (used to order requests from its
+peer to the UA), a local URI, a remote URI, remote target, a boolean
+flag called "secure", and a route set, which is an ordered list of
+URIs.  The route set is the list of servers that need to be traversed
+to send a request to the peer.  A dialog can also be in the "early"
+state, which occurs when it is created with a provisional response,
+and then transition to the "confirmed" state when a 2xx final
+response arrives.  For other responses, or if no response arrives at
+all on that dialog, the early dialog terminates.
+12.1 Creation of a Dialog
+Dialogs are created through the generation of non-failure responses
+to requests with specific methods.  Within this specification, only
+2xx and 101-199 responses with a To tag, where the request was
+INVITE, will establish a dialog.  A dialog established by a non-final
+response to a request is in the "early" state and it is called an
+early dialog.  Extensions MAY define other means for creating
+dialogs.  Section 13 gives more details that are specific to the
+INVITE method.  Here, we describe the process for creation of dialog
+state that is not dependent on the method.
+UAs MUST assign values to the dialog ID components as described
+below.
+12.1.1 UAS behavior
+When a UAS responds to a request with a response that establishes a
+dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
+header field values from the request into the response (including the
+URIs, URI parameters, and any Record-Route header field parameters,
+whether they are known or unknown to the UAS) and MUST maintain the
+order of those values.  The UAS MUST add a Contact header field to
+the response.  The Contact header field contains an address where the
+UAS would like to be contacted for subsequent requests in the dialog
+(which includes the ACK for a 2xx response in the case of an INVITE).
+Generally, the host portion of this URI is the IP address or FQDN of
+the host.  The URI provided in the Contact header field MUST be a SIP
+or SIPS URI.  If the request that initiated the dialog contained a
+Rosenberg, et. al.          Standards Track                    [Page 70]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+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.  The URI SHOULD have global scope (that is, the
+same URI can be used in messages outside this dialog).  The same way,
+the scope of the URI in the Contact header field of the INVITE is not
+limited to this dialog either.  It can therefore be used in messages
+to the UAC even outside this dialog.
+The UAS then constructs the state of the dialog.  This state MUST be
+maintained for the duration of the dialog.
+If the request arrived over TLS, and the Request-URI contained a SIPS
+URI, the "secure" flag is set to TRUE.
+The route set MUST be set to the list of URIs in the Record-Route
+header field from the request, taken in order and preserving all URI
+parameters.  If no Record-Route header field is present in the
+request, the route set MUST be set to the empty set.  This route set,
+even if empty, overrides any pre-existing route set for future
+requests in this dialog.  The remote target MUST be set to the URI
+from the Contact header field of the request.
+The remote sequence number MUST be set to the value of the sequence
+number in the CSeq header field of the request.  The local sequence
+number MUST be empty.  The call identifier component of the dialog ID
+MUST be set to the value of the Call-ID in the request.  The local
+tag component of the dialog ID MUST be set to the tag in the To field
+in the response to the request (which always includes a tag), and the
+remote tag component of the dialog ID MUST be set to the tag from the
+From field in the request.  A UAS MUST be prepared to receive a
+request without a tag in the From field, in which case the tag is
+considered to have a value of null.
+This is to maintain backwards compatibility with RFC 2543, which
+did not mandate From tags.
+The remote URI MUST be set to the URI in the From field, and the
+local URI MUST be set to the URI in the To field.
+12.1.2 UAC Behavior
+When a UAC sends a request that can establish a dialog (such as an
+INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e.,
+the same SIP URI can be used in messages outside this dialog) in the
+Contact header field of the request.  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.
+Rosenberg, et. al.          Standards Track                    [Page 71]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+When a UAC receives a response that establishes a dialog, it
+constructs the state of the dialog.  This state MUST be maintained
+for the duration of the dialog.
+If the request was sent over TLS, and the Request-URI contained a
+SIPS URI, the "secure" flag is set to TRUE.
+The route set MUST be set to the list of URIs in the Record-Route
+header field from the response, taken in reverse order and preserving
+all URI parameters.  If no Record-Route header field is present in
+the response, the route set MUST be set to the empty set.  This route
+set, even if empty, overrides any pre-existing route set for future
+requests in this dialog.  The remote target MUST be set to the URI
+from the Contact header field of the response.
+The local sequence number MUST be set to the value of the sequence
+number in the CSeq header field of the request.  The remote sequence
+number MUST be empty (it is established when the remote UA sends a
+request within the dialog).  The call identifier component of the
+dialog ID MUST be set to the value of the Call-ID in the request.
+The local tag component of the dialog ID MUST be set to the tag in
+the From field in the request, and the remote tag component of the
+dialog ID MUST be set to the tag in the To field of the response.  A
+UAC MUST be prepared to receive a response without a tag in the To
+field, in which case the tag is considered to have a value of null.
+This is to maintain backwards compatibility with RFC 2543, which
+did not mandate To tags.
+The remote URI MUST be set to the URI in the To field, and the local
+URI MUST be set to the URI in the From field.
+12.2 Requests within a Dialog
+Once a dialog has been established between two UAs, either of them
+MAY initiate new transactions as needed within the dialog.  The UA
+sending the request will take the UAC role for the transaction.  The
+UA receiving the request will take the UAS role.  Note that these may
+be different roles than the UAs held during the transaction that
+established the dialog.
+Requests within a dialog MAY contain Record-Route and Contact header
+fields.  However, these requests do not cause the dialog's route set
+to be modified, although they may modify the remote target URI.
+Specifically, requests that are not target refresh requests do not
+modify the dialog's remote target URI, and requests that are target
+refresh requests do.  For dialogs that have been established with an
+Rosenberg, et. al.          Standards Track                    [Page 72]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+INVITE, the only target refresh request defined is re-INVITE (see
+Section 14).  Other extensions may define different target refresh
+requests for dialogs established in other ways.
+Note that an ACK is NOT a target refresh request.
+Target refresh requests only update the dialog's remote target URI,
+and not the route set formed from the Record-Route.  Updating the
+latter would introduce severe backwards compatibility problems with
+RFC 2543-compliant systems.
+12.2.1 UAC Behavior
+12.2.1.1 Generating the Request
+A request within a dialog is constructed by using many of the
+components of the state stored as part of the dialog.
+The URI in the To field of the request MUST be set to the remote URI
+from the dialog state.  The tag in the To header field of the request
+MUST be set to the remote tag of the dialog ID.  The From URI of the
+request MUST be set to the local URI from the dialog state.  The tag
+in the From header field of the request MUST be set to the local tag
+of the dialog ID.  If the value of the remote or local tags is null,
+the tag parameter MUST be omitted from the To or From header fields,
+respectively.
+Usage of the URI from the To and From fields in the original
+request within subsequent requests is done for backwards
+compatibility with RFC 2543, which used the URI for dialog
+identification.  In this specification, only the tags are used for
+dialog identification.  It is expected that mandatory reflection
+of the original To and From URI in mid-dialog requests will be
+deprecated in a subsequent revision of this specification.
+The Call-ID of the request MUST be set to the Call-ID of the dialog.
+Requests within a dialog MUST contain strictly monotonically
+increasing and contiguous CSeq sequence numbers (increasing-by-one)
+in each direction (excepting ACK and CANCEL of course, whose numbers
+equal the requests being acknowledged or cancelled).  Therefore, if
+the local sequence number is not empty, the value of the local
+sequence number MUST be incremented by one, and this value MUST be
+placed into the CSeq header field.  If the local sequence number is
+empty, an initial value MUST be chosen using the guidelines of
+Section 8.1.1.5.  The method field in the CSeq header field value
+MUST match the method of the request.
+Rosenberg, et. al.          Standards Track                    [Page 73]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+With a length of 32 bits, a client could generate, within a single
+call, one request a second for about 136 years before needing to
+wrap around.  The initial value of the sequence number is chosen
+so that subsequent requests within the same call will not wrap
+around.  A non-zero initial value allows clients to use a time-
+based initial sequence number.  A client could, for example,
+choose the 31 most significant bits of a 32-bit second clock as an
+initial sequence number.
+The UAC uses the remote target and route set to build the Request-URI
+and Route header field of the request.
+If the route set is empty, the UAC MUST place the remote target URI
+into the Request-URI.  The UAC MUST NOT add a Route header field to
+the request.
+If the route set is not empty, and the first URI in the route set
+contains the lr parameter (see Section 19.1.1), the UAC MUST place
+the remote target URI into the Request-URI and MUST include a Route
+header field containing the route set values in order, including all
+parameters.
+If the route set is not empty, and its first URI does not contain the
+lr parameter, the UAC MUST place the first URI from the route set
+into the Request-URI, stripping any parameters that are not allowed
+in a Request-URI.  The UAC MUST add a Route header field containing
+the remainder of the route set values in order, including all
+parameters.  The UAC MUST then place the remote target URI into the
+Route header field as the last value.
+For example, if the remote target is sip:user@remoteua and the route
+set contains:
+<sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>
+The request will be formed with the following Request-URI and Route
+header field:
+METHOD sip:proxy1
+Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>
+If the first URI of the route set does not contain the lr
+parameter, the proxy indicated does not understand the routing
+mechanisms described in this document and will act as specified in
+RFC 2543, replacing the Request-URI with the first Route header
+field value it receives while forwarding the message.  Placing the
+Request-URI at the end of the Route header field preserves the
+Rosenberg, et. al.          Standards Track                    [Page 74]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+information in that Request-URI across the strict router (it will
+be returned to the Request-URI when the request reaches a loose-
+router).
+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.
+As discussed in Section 12.2.2, a Contact header field in a target
+refresh request updates the remote target URI.  This allows a UA to
+provide a new contact address, should its address change during the
+duration of the dialog.
+However, requests that are not target refresh requests do not affect
+the remote target URI for the dialog.
+The rest of the request is formed as described in Section 8.1.1.
+Once the request has been constructed, the address of the server is
+computed and the request is sent, using the same procedures for
+requests outside of a dialog (Section 8.1.2).
+The procedures in Section 8.1.2 will normally result in the
+request being sent to the address indicated by the topmost Route
+header field value or the Request-URI if no Route header field is
+present.  Subject to certain restrictions, they allow the request
+to be sent to an alternate address (such as a default outbound
+proxy not represented in the route set).
+12.2.1.2 Processing the Responses
+The UAC will receive responses to the request from the transaction
+layer.  If the client transaction returns a timeout, this is treated
+as a 408 (Request Timeout) response.
+The behavior of a UAC that receives a 3xx response for a request sent
+within a dialog is the same as if the request had been sent outside a
+dialog.  This behavior is described in Section 8.1.3.4.
+Note, however, that when the UAC tries alternative locations, it
+still uses the route set for the dialog to build the Route header
+of the request.
+When a UAC receives a 2xx response to a target refresh request, it
+MUST replace the dialog's remote target URI with the URI from the
+Contact header field in that response, if present.
+Rosenberg, et. al.          Standards Track                    [Page 75]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+If the response for a request within a dialog is a 481
+(Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC
+SHOULD terminate the dialog.  A UAC SHOULD also terminate a dialog if
+no response at all is received for the request (the client
+transaction would inform the TU about the timeout.)
+For INVITE initiated dialogs, terminating the dialog consists of
+sending a BYE.
+12.2.2 UAS Behavior
+Requests sent within a dialog, as any other requests, are atomic.  If
+a particular request is accepted by the UAS, all the state changes
+associated with it are performed.  If the request is rejected, none
+of the state changes are performed.
+Note that some requests, such as INVITEs, affect several pieces of
+state.
+The UAS will receive the request from the transaction layer.  If the
+request has a tag in the To header field, the UAS core computes the
+dialog identifier corresponding to the request and compares it with
+existing dialogs.  If there is a match, this is a mid-dialog request.
+In that case, the UAS first applies the same processing rules for
+requests outside of a dialog, discussed in Section 8.2.
+If the request has a tag in the To header field, but the dialog
+identifier does not match any existing dialogs, the UAS may have
+crashed and restarted, or it may have received a request for a
+different (possibly failed) UAS (the UASs can construct the To tags
+so that a UAS can identify that the tag was for a UAS for which it is
+providing recovery).  Another possibility is that the incoming
+request has been simply misrouted.  Based on the To tag, the UAS MAY
+either accept or reject the request.  Accepting the request for
+acceptable To tags provides robustness, so that dialogs can persist
+even through crashes.  UAs wishing to support this capability must
+take into consideration some issues such as choosing monotonically
+increasing CSeq sequence numbers even across reboots, reconstructing
+the route set, and accepting out-of-range RTP timestamps and sequence
+numbers.
+If the UAS wishes to reject the request because it does not wish to
+recreate the dialog, it MUST respond to the request with a 481
+(Call/Transaction Does Not Exist) status code and pass that to the
+server transaction.
+Rosenberg, et. al.          Standards Track                    [Page 76]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Requests that do not change in any way the state of a dialog may be
+received within a dialog (for example, an OPTIONS request).  They are
+processed as if they had been received outside the dialog.
+If the remote sequence number is empty, it MUST be set to the value
+of the sequence number in the CSeq header field value in the request.
+If the remote sequence number was not empty, but the sequence number
+of the request is lower than the remote sequence number, the request
+is out of order and MUST be rejected with a 500 (Server Internal
+Error) response.  If the remote sequence number was not empty, and
+the sequence number of the request is greater than the remote
+sequence number, the request is in order.  It is possible for the
+CSeq sequence number to be higher than the remote sequence number by
+more than one.  This is not an error condition, and a UAS SHOULD be
+prepared to receive and process requests with CSeq values more than
+one higher than the previous received request.  The UAS MUST then set
+the remote sequence number to the value of the sequence number in the
+CSeq header field value in the request.
+If a proxy challenges a request generated by the UAC, the UAC has
+to resubmit the request with credentials.  The resubmitted request
+will have a new CSeq number.  The UAS will never see the first
+request, and thus, it will notice a gap in the CSeq number space.
+Such a gap does not represent any error condition.
+When a UAS receives a target refresh request, it MUST replace the
+dialog's remote target URI with the URI from the Contact header field
+in that request, if present.
+12.3 Termination of a Dialog
+Independent of the method, if a request outside of a dialog generates
+a non-2xx final response, any early dialogs created through
+provisional responses to that request are terminated.  The mechanism
+for terminating confirmed dialogs is method specific.  In this
+specification, the BYE method terminates a session and the dialog
+associated with it.  See Section 15 for details.
+13 Initiating a Session
+13.1 Overview
+When a user agent client desires to initiate a session (for example,
+audio, video, or a game), it formulates an INVITE request.  The
+INVITE request asks a server to establish a session.  This request
+may be forwarded by proxies, eventually arriving at one or more UAS
+that can potentially accept the invitation.  These UASs will
+frequently need to query the user about whether to accept the
+Rosenberg, et. al.          Standards Track                    [Page 77]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+invitation.  After some time, those UASs can accept the invitation
+(meaning the session is to be established) by sending a 2xx response.
+If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is
+sent, depending on the reason for the rejection.  Before sending a
+final response, the UAS can also send provisional responses (1xx) to
+advise the UAC of progress in contacting the called user.
+After possibly receiving one or more provisional responses, the UAC
+will get one or more 2xx responses or one non-2xx final response.
+Because of the protracted amount of time it can take to receive final
+responses to INVITE, the reliability mechanisms for INVITE
+transactions differ from those of other requests (like OPTIONS).
+Once it receives a final response, the UAC needs to send an ACK for
+every final response it receives.  The procedure for sending this ACK
+depends on the type of response.  For final responses between 300 and
+699, the ACK processing is done in the transaction layer and follows
+one set of rules (See Section 17).  For 2xx responses, the ACK is
+generated by the UAC core.
+A 2xx response to an INVITE establishes a session, and it also
+creates a dialog between the UA that issued the INVITE and the UA
+that generated the 2xx response.  Therefore, when multiple 2xx
+responses are received from different remote UAs (because the INVITE
+forked), each 2xx establishes a different dialog.  All these dialogs
+are part of the same call.
+This section provides details on the establishment of a session using
+INVITE.  A UA that supports INVITE MUST also support ACK, CANCEL and
+BYE.
+13.2 UAC Processing
+13.2.1 Creating the Initial INVITE
+Since the initial INVITE represents a request outside of a dialog,
+its construction follows the procedures of Section 8.1.1.  Additional
+processing is required for the specific case of INVITE.
+An Allow header field (Section 20.5) SHOULD be present in the INVITE.
+It indicates what methods can be invoked within a dialog, on the UA
+sending the INVITE, for the duration of the dialog.  For example, a
+UA capable of receiving INFO requests within a dialog [34] SHOULD
+include an Allow header field listing the INFO method.
+A Supported header field (Section 20.37) SHOULD be present in the
+INVITE.  It enumerates all the extensions understood by the UAC.
+Rosenberg, et. al.          Standards Track                    [Page 78]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+An Accept (Section 20.1) header field MAY be present in the INVITE.
+It indicates which Content-Types are acceptable to the UA, in both
+the response received by it, and in any subsequent requests sent to
+it within dialogs established by the INVITE.  The Accept header field
+is especially useful for indicating support of various session
+description formats.
+The UAC MAY add an Expires header field (Section 20.19) to limit the
+validity of the invitation.  If the time indicated in the Expires
+header field is reached and no final answer for the INVITE has been
+received, the UAC core SHOULD generate a CANCEL request for the
+INVITE, as per Section 9.
+A UAC MAY also find it useful to add, among others, Subject (Section
+20.36), Organization (Section 20.25) and User-Agent (Section 20.41)
+header fields.  They all contain information related to the INVITE.
+The UAC MAY choose to add a message body to the INVITE.  Section
+8.1.1.10 deals with how to construct the header fields -- Content-
+Type among others -- needed to describe the message body.
+There are special rules for message bodies that contain a session
+description - their corresponding Content-Disposition is "session".
+SIP uses an offer/answer model where one UA sends a session
+description, called the offer, which contains a proposed description
+of the session.  The offer indicates the desired communications means
+(audio, video, games), parameters of those means (such as codec
+types) and addresses for receiving media from the answerer.  The
+other UA responds with another session description, called the
+answer, which indicates which communications means are accepted, the
+parameters that apply to those means, and addresses for receiving
+media from the offerer. An offer/answer exchange is within the
+context of a dialog, so that if a SIP INVITE results in multiple
+dialogs, each is a separate offer/answer exchange.  The offer/answer
+model defines restrictions on when offers and answers can be made
+(for example, you cannot make a new offer while one is in progress).
+This results in restrictions on where the offers and answers can
+appear in SIP messages.  In this specification, offers and answers
+can only appear in INVITE requests and responses, and ACK.  The usage
+of offers and answers is further restricted.  For the initial INVITE
+transaction, the rules are:
+o  The initial offer MUST be in either an INVITE or, if not there,
+in the first reliable non-failure message from the UAS back to
+the UAC.  In this specification, that is the final 2xx
+response.
+Rosenberg, et. al.          Standards Track                    [Page 79]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+o  If the initial offer is in an INVITE, the answer MUST be in a
+reliable non-failure message from UAS back to UAC which is
+correlated to that INVITE.  For this specification, that is
+only the final 2xx response to that INVITE.  That same exact
+answer MAY also be placed in any provisional responses sent
+prior to the answer.  The UAC MUST treat the first session
+description it receives as the answer, and MUST ignore any
+session descriptions in subsequent responses to the initial
+INVITE.
+o  If the initial offer is in the first reliable non-failure
+message from the UAS back to UAC, the answer MUST be in the
+acknowledgement for that message (in this specification, ACK
+for a 2xx response).
+o  After having sent or received an answer to the first offer, the
+UAC MAY generate subsequent offers in requests based on rules
+specified for that method, but only if it has received answers
+to any previous offers, and has not sent any offers to which it
+hasn't gotten an answer.
+o  Once the UAS has sent or received an answer to the initial
+offer, it MUST NOT generate subsequent offers in any responses
+to the initial INVITE.  This means that a UAS based on this
+specification alone can never generate subsequent offers until
+completion of the initial transaction.
+Concretely, the above rules specify two exchanges for UAs compliant
+to this specification alone - the offer is in the INVITE, and the
+answer in the 2xx (and possibly in a 1xx as well, with the same
+value), or the offer is in the 2xx, and the answer is in the ACK.
+All user agents that support INVITE MUST support these two exchanges.
+The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be
+supported by all user agents as a means to describe sessions, and its
+usage for constructing offers and answers MUST follow the procedures
+defined in [13].
+The restrictions of the offer-answer model just described only apply
+to bodies whose Content-Disposition header field value is "session".
+Therefore, it is possible that both the INVITE and the ACK contain a
+body message (for example, the INVITE carries a photo (Content-
+Disposition: render) and the ACK a session description (Content-
+Disposition: session)).
+If the Content-Disposition header field is missing, bodies of
+Content-Type application/sdp imply the disposition "session", while
+other content types imply "render".
+Rosenberg, et. al.          Standards Track                    [Page 80]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Once the INVITE has been created, the UAC follows the procedures
+defined for sending requests outside of a dialog (Section 8).  This
+results in the construction of a client transaction that will
+ultimately send the request and deliver responses to the UAC.
+13.2.2 Processing INVITE Responses
+Once the INVITE has been passed to the INVITE client transaction, the
+UAC waits for responses for the INVITE.  If the INVITE client
+transaction returns a timeout rather than a response the TU acts as
+if a 408 (Request Timeout) response had been received, as described
+in Section 8.1.3.
+13.2.2.1 1xx Responses
+Zero, one or multiple provisional responses may arrive before one or
+more final responses are received.  Provisional responses for an
+INVITE request can create "early dialogs".  If a provisional response
+has a tag in the To field, and if the dialog ID of the response does
+not match an existing dialog, one is constructed using the procedures
+defined in Section 12.1.2.
+The early dialog will only be needed if the UAC needs to send a
+request to its peer within the dialog before the initial INVITE
+transaction completes.  Header fields present in a provisional
+response are applicable as long as the dialog is in the early state
+(for example, an Allow header field in a provisional response
+contains the methods that can be used in the dialog while this is in
+the early state).
+13.2.2.2 3xx Responses
+A 3xx response may contain one or more Contact header field values
+providing new addresses where the callee might be reachable.
+Depending on the status code of the 3xx response (see Section 21.3),
+the UAC MAY choose to try those new addresses.
+13.2.2.3 4xx, 5xx and 6xx Responses
+A single non-2xx final response may be received for the INVITE.  4xx,
+5xx and 6xx responses may contain a Contact header field value
+indicating the location where additional information about the error
+can be found.  Subsequent final responses (which would only arrive
+under error conditions) MUST be ignored.
+All early dialogs are considered terminated upon reception of the
+non-2xx final response.
+Rosenberg, et. al.          Standards Track                    [Page 81]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+After having received the non-2xx final response the UAC core
+considers the INVITE transaction completed.  The INVITE client
+transaction handles the generation of ACKs for the response (see
+Section 17).
+13.2.2.4 2xx Responses
+Multiple 2xx responses may arrive at the UAC for a single INVITE
+request due to a forking proxy.  Each response is distinguished by
+the tag parameter in the To header field, and each represents a
+distinct dialog, with a distinct dialog identifier.
+If the dialog identifier in the 2xx response matches the dialog
+identifier of an existing dialog, the dialog MUST be transitioned to
+the "confirmed" state, and the route set for the dialog MUST be
+recomputed based on the 2xx response using the procedures of Section
+12.2.1.2.  Otherwise, a new dialog in the "confirmed" state MUST be
+constructed using the procedures of Section 12.1.2.
+Note that the only piece of state that is recomputed is the route
+set.  Other pieces of state such as the highest sequence numbers
+(remote and local) sent within the dialog are not recomputed.  The
+route set only is recomputed for backwards compatibility.  RFC
+2543 did not mandate mirroring of the Record-Route header field in
+a 1xx, only 2xx.  However, we cannot update the entire state of
+the dialog, since mid-dialog requests may have been sent within
+the early dialog, modifying the sequence numbers, for example.
+The UAC core MUST generate an ACK request for each 2xx received from
+the transaction layer.  The header fields of the ACK are constructed
+in the same way as for any request sent within a dialog (see Section
+12) with the exception of the CSeq and the header fields related to
+authentication.  The sequence number of the CSeq header field MUST be
+the same as the INVITE being acknowledged, but the CSeq method MUST
+be ACK.  The ACK MUST contain the same credentials as the INVITE.  If
+the 2xx contains an offer (based on the rules above), the ACK MUST
+carry an answer in its body.  If the offer in the 2xx response is not
+acceptable, the UAC core MUST generate a valid answer in the ACK and
+then send a BYE immediately.
+Once the ACK has been constructed, the procedures of [4] are used to
+determine the destination address, port and transport.  However, the
+request is passed to the transport layer directly for transmission,
+rather than a client transaction.  This is because the UAC core
+handles retransmissions of the ACK, not the transaction layer.  The
+ACK MUST be passed to the client transport every time a
+retransmission of the 2xx final response that triggered the ACK
+arrives.
+Rosenberg, et. al.          Standards Track                    [Page 82]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The UAC core considers the INVITE transaction completed 64*T1 seconds
+after the reception of the first 2xx response.  At this point all the
+early dialogs that have not transitioned to established dialogs are
+terminated.  Once the INVITE transaction is considered completed by
+the UAC core, no more new 2xx responses are expected to arrive.
+If, after acknowledging any 2xx response to an INVITE, the UAC does
+not want to continue with that dialog, then the UAC MUST terminate
+the dialog by sending a BYE request as described in Section 15.
+13.3 UAS Processing
+13.3.1 Processing of the INVITE
+The UAS core will receive INVITE requests from the transaction layer.
+It first performs the request processing procedures of Section 8.2,
+which are applied for both requests inside and outside of a dialog.
+Assuming these processing states are completed without generating a
+response, the UAS core performs the additional processing steps:
+1. If the request is an INVITE that contains an Expires header
+field, the UAS core sets a timer for the number of seconds
+indicated in the header field value.  When the timer fires, the
+invitation is considered to be expired.  If the invitation
+expires before the UAS has generated a final response, a 487
+(Request Terminated) response SHOULD be generated.
+2. If the request is a mid-dialog request, the method-independent
+processing described in Section 12.2.2 is first applied.  It
+might also modify the session; Section 14 provides details.
+3. If the request has a tag in the To header field but the dialog
+identifier does not match any of the existing dialogs, the UAS
+may have crashed and restarted, or may have received a request
+for a different (possibly failed) UAS.  Section 12.2.2 provides
+guidelines to achieve a robust behavior under such a situation.
+Processing from here forward assumes that the INVITE is outside of a
+dialog, and is thus for the purposes of establishing a new session.
+The INVITE may contain a session description, in which case the UAS
+is being presented with an offer for that session.  It is possible
+that the user is already a participant in that session, even though
+the INVITE is outside of a dialog.  This can happen when a user is
+invited to the same multicast conference by multiple other
+participants.  If desired, the UAS MAY use identifiers within the
+session description to detect this duplication.  For example, SDP
+Rosenberg, et. al.          Standards Track                    [Page 83]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+contains a session id and version number in the origin (o) field.  If
+the user is already a member of the session, and the session
+parameters contained in the session description have not changed, the
+UAS MAY silently accept the INVITE (that is, send a 2xx response
+without prompting the user).
+If the INVITE does not contain a session description, the UAS is
+being asked to participate in a session, and the UAC has asked that
+the UAS provide the offer of the session.  It MUST provide the offer
+in its first non-failure reliable message back to the UAC.  In this
+specification, that is a 2xx response to the INVITE.
+The UAS can indicate progress, accept, redirect, or reject the
+invitation.  In all of these cases, it formulates a response using
+the procedures described in Section 8.2.6.
+13.3.1.1 Progress
+If the UAS is not able to answer the invitation immediately, it can
+choose to indicate some kind of progress to the UAC (for example, an
+indication that a phone is ringing).  This is accomplished with a
+provisional response between 101 and 199.  These provisional
+responses establish early dialogs and therefore follow the procedures
+of Section 12.1.1 in addition to those of Section 8.2.6.  A UAS MAY
+send as many provisional responses as it likes.  Each of these MUST
+indicate the same dialog ID.  However, these will not be delivered
+reliably.
+If the UAS desires an extended period of time to answer the INVITE,
+it will need to ask for an "extension" in order to prevent proxies
+from canceling the transaction.  A proxy has the option of canceling
+a transaction when there is a gap of 3 minutes between responses in a
+transaction.  To prevent cancellation, the UAS MUST send a non-100
+provisional response at every minute, to handle the possibility of
+lost provisional responses.
+An INVITE transaction can go on for extended durations when the
+user is placed on hold, or when interworking with PSTN systems
+which allow communications to take place without answering the
+call.  The latter is common in Interactive Voice Response (IVR)
+systems.
+13.3.1.2 The INVITE is Redirected
+If the UAS decides to redirect the call, a 3xx response is sent.  A
+300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved
+Temporarily) response SHOULD contain a Contact header field
+Rosenberg, et. al.          Standards Track                    [Page 84]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+containing one or more URIs of new addresses to be tried.  The
+response is passed to the INVITE server transaction, which will deal
+with its retransmissions.
+13.3.1.3 The INVITE is Rejected
+A common scenario occurs when the callee is currently not willing or
+able to take additional calls at this end system.  A 486 (Busy Here)
+SHOULD be returned in such a scenario.  If the UAS knows that no
+other end system will be able to accept this call, a 600 (Busy
+Everywhere) response SHOULD be sent instead.  However, it is unlikely
+that a UAS will be able to know this in general, and thus this
+response will not usually be used.  The response is passed to the
+INVITE server transaction, which will deal with its retransmissions.
+A UAS rejecting an offer contained in an INVITE SHOULD return a 488
+(Not Acceptable Here) response.  Such a response SHOULD include a
+Warning header field value explaining why the offer was rejected.
+13.3.1.4 The INVITE is Accepted
+The UAS core generates a 2xx response.  This response establishes a
+dialog, and therefore follows the procedures of Section 12.1.1 in
+addition to those of Section 8.2.6.
+A 2xx response to an INVITE SHOULD contain the Allow header field and
+the Supported header field, and MAY contain the Accept header field.
+Including these header fields allows the UAC to determine the
+features and extensions supported by the UAS for the duration of the
+call, without probing.
+If the INVITE request contained an offer, and the UAS had not yet
+sent an answer, the 2xx MUST contain an answer.  If the INVITE did
+not contain an offer, the 2xx MUST contain an offer if the UAS had
+not yet sent an offer.
+Once the response has been constructed, it is passed to the INVITE
+server transaction.  Note, however, that the INVITE server
+transaction will be destroyed as soon as it receives this final
+response and passes it to the transport.  Therefore, it is necessary
+to periodically pass the response directly to the transport until the
+ACK arrives.  The 2xx response is passed to the transport with an
+interval that starts at T1 seconds and doubles for each
+retransmission until it reaches T2 seconds (T1 and T2 are defined in
+Section 17).  Response retransmissions cease when an ACK request for
+the response is received.  This is independent of whatever transport
+protocols are used to send the response.
+Rosenberg, et. al.          Standards Track                    [Page 85]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Since 2xx is retransmitted end-to-end, there may be hops between
+UAS and UAC that are UDP.  To ensure reliable delivery across
+these hops, the response is retransmitted periodically even if the
+transport at the UAS is reliable.
+If the server retransmits the 2xx response for 64*T1 seconds without
+receiving an ACK, the dialog is confirmed, but the session SHOULD be
+terminated.  This is accomplished with a BYE, as described in Section
+15.
+14 Modifying an Existing Session
+A successful INVITE request (see Section 13) establishes both a
+dialog between two user agents and a session using the offer-answer
+model.  Section 12 explains how to modify an existing dialog using a
+target refresh request (for example, changing the remote target URI
+of the dialog).  This section describes how to modify the actual
+session.  This modification can involve changing addresses or ports,
+adding a media stream, deleting a media stream, and so on.  This is
+accomplished by sending a new INVITE request within the same dialog
+that established the session.  An INVITE request sent within an
+existing dialog is known as a re-INVITE.
+Note that a single re-INVITE can modify the dialog and the
+parameters of the session at the same time.
+Either the caller or callee can modify an existing session.
+The behavior of a UA on detection of media failure is a matter of
+local policy.  However, automated generation of re-INVITE or BYE is
+NOT RECOMMENDED to avoid flooding the network with traffic when there
+is congestion.  In any case, if these messages are sent
+automatically, they SHOULD be sent after some randomized interval.
+Note that the paragraph above refers to automatically generated
+BYEs and re-INVITEs.  If the user hangs up upon media failure, the
+UA would send a BYE request as usual.
+14.1 UAC Behavior
+The same offer-answer model that applies to session descriptions in
+INVITEs (Section 13.2.1) applies to re-INVITEs.  As a result, a UAC
+that wants to add a media stream, for example, will create a new
+offer that contains this media stream, and send that in an INVITE
+request to its peer.  It is important to note that the full
+description of the session, not just the change, is sent.  This
+supports stateless session processing in various elements, and
+supports failover and recovery capabilities.  Of course, a UAC MAY
+Rosenberg, et. al.          Standards Track                    [Page 86]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+send a re-INVITE with no session description, in which case the first
+reliable non-failure response to the re-INVITE will contain the offer
+(in this specification, that is a 2xx response).
+If the session description format has the capability for version
+numbers, the offerer SHOULD indicate that the version of the session
+description has changed.
+The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set
+following the same rules as for regular requests within an existing
+dialog, described in Section 12.
+A UAC MAY choose not to add an Alert-Info header field or a body with
+Content-Disposition "alert" to re-INVITEs because UASs do not
+typically alert the user upon reception of a re-INVITE.
+Unlike an INVITE, which can fork, a re-INVITE will never fork, and
+therefore, only ever generate a single final response.  The reason a
+re-INVITE will never fork is that the Request-URI identifies the
+target as the UA instance it established the dialog with, rather than
+identifying an address-of-record for the user.
+Note that a UAC MUST NOT initiate a new INVITE transaction within a
+dialog while another INVITE transaction is in progress in either
+direction.
+1. If there is an ongoing INVITE client transaction, the TU MUST
+wait until the transaction reaches the completed or terminated
+state before initiating the new INVITE.
+2. If there is an ongoing INVITE server transaction, the TU MUST
+wait until the transaction reaches the confirmed or terminated
+state before initiating the new INVITE.
+However, a UA MAY initiate a regular transaction while an INVITE
+transaction is in progress.  A UA MAY also initiate an INVITE
+transaction while a regular transaction is in progress.
+If a UA receives a non-2xx final response to a re-INVITE, the session
+parameters MUST remain unchanged, as if no re-INVITE had been issued.
+Note that, as stated in Section 12.2.1.2, if the non-2xx final
+response is a 481 (Call/Transaction Does Not Exist), or a 408
+(Request Timeout), or no response at all is received for the re-
+INVITE (that is, a timeout is returned by the INVITE client
+transaction), the UAC will terminate the dialog.
+Rosenberg, et. al.          Standards Track                    [Page 87]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+If a UAC receives a 491 response to a re-INVITE, it SHOULD start a
+timer with a value T chosen as follows:
+1. If the UAC is the owner of the Call-ID of the dialog ID
+(meaning it generated the value), T has a randomly chosen value
+between 2.1 and 4 seconds in units of 10 ms.
+2. If the UAC is not the owner of the Call-ID of the dialog ID, T
+has a randomly chosen value of between 0 and 2 seconds in units
+of 10 ms.
+When the timer fires, the UAC SHOULD attempt the re-INVITE once more,
+if it still desires for that session modification to take place.  For
+example, if the call was already hung up with a BYE, the re-INVITE
+would not take place.
+The rules for transmitting a re-INVITE and for generating an ACK for
+a 2xx response to re-INVITE are the same as for the initial INVITE
+(Section 13.2.1).
+14.2 UAS Behavior
+Section 13.3.1 describes the procedure for distinguishing incoming
+re-INVITEs from incoming initial INVITEs and handling a re-INVITE for
+an existing dialog.
+A UAS that receives a second INVITE before it sends the final
+response to a first INVITE with a lower CSeq sequence number on the
+same dialog MUST return a 500 (Server Internal Error) response to the
+second INVITE and MUST include a Retry-After header field with a
+randomly chosen value of between 0 and 10 seconds.
+A UAS that receives an INVITE on a dialog while an INVITE it had sent
+on that dialog is in progress MUST return a 491 (Request Pending)
+response to the received INVITE.
+If a UA receives a re-INVITE for an existing dialog, it MUST check
+any version identifiers in the session description or, if there are
+no version identifiers, the content of the session description to see
+if it has changed.  If the session description has changed, the UAS
+MUST adjust the session parameters accordingly, possibly after asking
+the user for confirmation.
+Versioning of the session description can be used to accommodate
+the capabilities of new arrivals to a conference, add or delete
+media, or change from a unicast to a multicast conference.
+Rosenberg, et. al.          Standards Track                    [Page 88]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+If the new session description is not acceptable, the UAS can reject
+it by returning a 488 (Not Acceptable Here) response for the re-
+INVITE.  This response SHOULD include a Warning header field.
+If a UAS generates a 2xx response and never receives an ACK, it
+SHOULD generate a BYE to terminate the dialog.
+A UAS MAY choose not to generate 180 (Ringing) responses for a re-
+INVITE because UACs do not typically render this information to the
+user.  For the same reason, UASs MAY choose not to use an Alert-Info
+header field or a body with Content-Disposition "alert" in responses
+to a re-INVITE.
+A UAS providing an offer in a 2xx (because the INVITE did not contain
+an offer) SHOULD construct the offer as if the UAS were making a
+brand new call, subject to the constraints of sending an offer that
+updates an existing session, as described in [13] in the case of SDP.
+Specifically, this means that it SHOULD include as many media formats
+and media types that the UA is willing to support.  The UAS MUST
+ensure that the session description overlaps with its previous
+session description in media formats, transports, or other parameters
+that require support from the peer.  This is to avoid the need for
+the peer to reject the session description.  If, however, it is
+unacceptable to the UAC, the UAC SHOULD generate an answer with a
+valid session description, and then send a BYE to terminate the
+session.
+15 Terminating a Session
+This section describes the procedures for terminating a session
+established by SIP.  The state of the session and the state of the
+dialog are very closely related.  When a session is initiated with an
+INVITE, each 1xx or 2xx response from a distinct UAS creates a
+dialog, and if that response completes the offer/answer exchange, it
+also creates a session.  As a result, each session is "associated"
+with a single dialog - the one which resulted in its creation.  If an
+initial INVITE generates a non-2xx final response, that terminates
+all sessions (if any) and all dialogs (if any) that were created
+through responses to the request.  By virtue of completing the
+transaction, a non-2xx final response also prevents further sessions
+from being created as a result of the INVITE.  The BYE request is
+used to terminate a specific session or attempted session.  In this
+case, the specific session is the one with the peer UA on the other
+side of the dialog.  When a BYE is received on a dialog, any session
+associated with that dialog SHOULD terminate.  A UA MUST NOT send a
+BYE outside of a dialog.  The caller's UA MAY send a BYE for either
+confirmed or early dialogs, and the callee's UA MAY send a BYE on
+confirmed dialogs, but MUST NOT send a BYE on early dialogs.
+Rosenberg, et. al.          Standards Track                    [Page 89]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+However, the callee's UA MUST NOT send a BYE on a confirmed dialog
+until it has received an ACK for its 2xx response or until the server
+transaction times out.  If no SIP extensions have defined other
+application layer states associated with the dialog, the BYE also
+terminates the dialog.
+The impact of a non-2xx final response to INVITE on dialogs and
+sessions makes the use of CANCEL attractive.  The CANCEL attempts to
+force a non-2xx response to the INVITE (in particular, a 487).
+Therefore, if a UAC wishes to give up on its call attempt entirely,
+it can send a CANCEL.  If the INVITE results in 2xx final response(s)
+to the INVITE, this means that a UAS accepted the invitation while
+the CANCEL was in progress.  The UAC MAY continue with the sessions
+established by any 2xx responses, or MAY terminate them with BYE.
+The notion of "hanging up" is not well defined within SIP.  It is
+specific to a particular, albeit common, user interface.
+Typically, when the user hangs up, it indicates a desire to
+terminate the attempt to establish a session, and to terminate any
+sessions already created.  For the caller's UA, this would imply a
+CANCEL request if the initial INVITE has not generated a final
+response, and a BYE to all confirmed dialogs after a final
+response.  For the callee's UA, it would typically imply a BYE;
+presumably, when the user picked up the phone, a 2xx was
+generated, and so hanging up would result in a BYE after the ACK
+is received.  This does not mean a user cannot hang up before
+receipt of the ACK, it just means that the software in his phone
+needs to maintain state for a short while in order to clean up
+properly.  If the particular UI allows for the user to reject a
+call before its answered, a 403 (Forbidden) is a good way to
+express that.  As per the rules above, a BYE can't be sent.
+15.1 Terminating a Session with a BYE Request
+15.1.1 UAC Behavior
+A BYE request is constructed as would any other request within a
+dialog, as described in Section 12.
+Once the BYE is constructed, the UAC core creates a new non-INVITE
+client transaction, and passes it the BYE request.  The UAC MUST
+consider the session terminated (and therefore stop sending or
+listening for media) as soon as the BYE request is passed to the
+client transaction.  If the response for the BYE is a 481
+(Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no
+Rosenberg, et. al.          Standards Track                    [Page 90]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+response at all is received for the BYE (that is, a timeout is
+returned by the client transaction), the UAC MUST consider the
+session and the dialog terminated.
+15.1.2 UAS Behavior
+A UAS first processes the BYE request according to the general UAS
+processing described in Section 8.2.  A UAS core receiving a BYE
+request checks if it matches an existing dialog.  If the BYE does not
+match an existing dialog, the UAS core SHOULD generate a 481
+(Call/Transaction Does Not Exist) response and pass that to the
+server transaction.
+This rule means that a BYE sent without tags by a UAC will be
+rejected.  This is a change from RFC 2543, which allowed BYE
+without tags.
+A UAS core receiving a BYE request for an existing dialog MUST follow
+the procedures of Section 12.2.2 to process the request.  Once done,
+the UAS SHOULD terminate the session (and therefore stop sending and
+listening for media).  The only case where it can elect not to are
+multicast sessions, where participation is possible even if the other
+participant in the dialog has terminated its involvement in the
+session.  Whether or not it ends its participation on the session,
+the UAS core MUST generate a 2xx response to the BYE, and MUST pass
+that to the server transaction for transmission.
+The UAS MUST still respond to any pending requests received for that
+dialog.  It is RECOMMENDED that a 487 (Request Terminated) response
+be generated to those pending requests.
+16 Proxy Behavior
+16.1 Overview
+SIP proxies are elements that route SIP requests to user agent
+servers and SIP responses to user agent clients.  A request may
+traverse several proxies on its way to a UAS.  Each will make routing
+decisions, modifying the request before forwarding it to the next
+element.  Responses will route through the same set of proxies
+traversed by the request in the reverse order.
+Being a proxy is a logical role for a SIP element.  When a request
+arrives, an element that can play the role of a proxy first decides
+if it needs to respond to the request on its own.  For instance, the
+request may be malformed or the element may need credentials from the
+client before acting as a proxy.  The element MAY respond with any
+Rosenberg, et. al.          Standards Track                    [Page 91]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+appropriate error code.  When responding directly to a request, the
+element is playing the role of a UAS and MUST behave as described in
+Section 8.2.
+A proxy can operate in either a stateful or stateless mode for each
+new request.  When stateless, a proxy acts as a simple forwarding
+element.  It forwards each request downstream to a single element
+determined by making a targeting and routing decision based on the
+request.  It simply forwards every response it receives upstream.  A
+stateless proxy discards information about a message once the message
+has been forwarded.  A stateful proxy remembers information
+(specifically, transaction state) about each incoming request and any
+requests it sends as a result of processing the incoming request.  It
+uses this information to affect the processing of future messages
+associated with that request.  A stateful proxy MAY choose to "fork"
+a request, routing it to multiple destinations.  Any request that is
+forwarded to more than one location MUST be handled statefully.
+In some circumstances, a proxy MAY forward requests using stateful
+transports (such as TCP) without being transaction-stateful.  For
+instance, a proxy MAY forward a request from one TCP connection to
+another transaction statelessly as long as it places enough
+information in the message to be able to forward the response down
+the same connection the request arrived on.  Requests forwarded
+between different types of transports where the proxy's TU must take
+an active role in ensuring reliable delivery on one of the transports
+MUST be forwarded transaction statefully.
+A stateful proxy MAY transition to stateless operation at any time
+during the processing of a request, so long as it did not do anything
+that would otherwise prevent it from being stateless initially
+(forking, for example, or generation of a 100 response).  When
+performing such a transition, all state is simply discarded.  The
+proxy SHOULD NOT initiate a CANCEL request.
+Much of the processing involved when acting statelessly or statefully
+for a request is identical.  The next several subsections are written
+from the point of view of a stateful proxy.  The last section calls
+out those places where a stateless proxy behaves differently.
+16.2 Stateful Proxy
+When stateful, a proxy is purely a SIP transaction processing engine.
+Its behavior is modeled here in terms of the server and client
+transactions defined in Section 17.  A stateful proxy has a server
+transaction associated with one or more client transactions by a
+higher layer proxy processing component (see figure 3), known as a
+proxy core.  An incoming request is processed by a server
+Rosenberg, et. al.          Standards Track                    [Page 92]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+transaction.  Requests from the server transaction are passed to a
+proxy core.  The proxy core determines where to route the request,
+choosing one or more next-hop locations.  An outgoing request for
+each next-hop location is processed by its own associated client
+transaction.  The proxy core collects the responses from the client
+transactions and uses them to send responses to the server
+transaction.
+A stateful proxy creates a new server transaction for each new
+request received.  Any retransmissions of the request will then be
+handled by that server transaction per Section 17.  The proxy core
+MUST behave as a UAS with respect to sending an immediate provisional
+on that server transaction (such as 100 Trying) as described in
+Section 8.2.6.  Thus, a stateful proxy SHOULD NOT generate 100
+(Trying) responses to non-INVITE requests.
+This is a model of proxy behavior, not of software.  An
+implementation is free to take any approach that replicates the
+external behavior this model defines.
+For all new requests, including any with unknown methods, an element
+intending to proxy the request MUST:
+1. Validate the request (Section 16.3)
+2. Preprocess routing information (Section 16.4)
+3. Determine target(s) for the request (Section 16.5)
++--------------------+
+|                    | +---+
+|                    | | C |
+|                    | | T |
+|                    | +---+
++---+ |       Proxy        | +---+   CT = Client Transaction
+| S | |  "Higher" Layer    | | C |
+| T | |                    | | T |   ST = Server Transaction
++---+ |                    | +---+
+|                    | +---+
+|                    | | C |
+|                    | | T |
+|                    | +---+
++--------------------+
+Figure 3: Stateful Proxy Model
+Rosenberg, et. al.          Standards Track                    [Page 93]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+4. Forward the request to each target (Section 16.6)
+5. Process all responses (Section 16.7)
+16.3 Request Validation
+Before an element can proxy a request, it MUST verify the message's
+validity.  A valid message must pass the following checks:
+1. Reasonable Syntax
+2. URI scheme
+3. Max-Forwards
+4. (Optional) Loop Detection
+5. Proxy-Require
+6. Proxy-Authorization
+If any of these checks fail, the element MUST behave as a user agent
+server (see Section 8.2) and respond with an error code.
+Notice that a proxy is not required to detect merged requests and
+MUST NOT treat merged requests as an error condition.  The endpoints
+receiving the requests will resolve the merge as described in Section
+8.2.2.2.
+1. Reasonable syntax check
+The request MUST be well-formed enough to be handled with a server
+transaction.  Any components involved in the remainder of these
+Request Validation steps or the Request Forwarding section MUST be
+well-formed.  Any other components, well-formed or not, SHOULD be
+ignored and remain unchanged when the message is forwarded.  For
+instance, an element would not reject a request because of a
+malformed Date header field.  Likewise, a proxy would not remove a
+malformed Date header field before forwarding a request.
+This protocol is designed to be extended.  Future extensions may
+define new methods and header fields at any time.  An element MUST
+NOT refuse to proxy a request because it contains a method or
+header field it does not know about.
+Rosenberg, et. al.          Standards Track                    [Page 94]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+2. URI scheme check
+If the Request-URI has a URI whose scheme is not understood by the
+proxy, the proxy SHOULD reject the request with a 416 (Unsupported
+URI Scheme) response.
+3. Max-Forwards check
+The Max-Forwards header field (Section 20.22) is used to limit the
+number of elements a SIP request can traverse.
+If the request does not contain a Max-Forwards header field, this
+check is passed.
+If the request contains a Max-Forwards header field with a field
+value greater than zero, the check is passed.
+If the request contains a Max-Forwards header field with a field
+value of zero (0), the element MUST NOT forward the request.  If
+the request was for OPTIONS, the element MAY act as the final
+recipient and respond per Section 11.  Otherwise, the element MUST
+return a 483 (Too many hops) response.
+4. Optional Loop Detection check
+An element MAY check for forwarding loops before forwarding a
+request.  If the request contains a Via header field with a sent-
+by value that equals a value placed into previous requests by the
+proxy, the request has been forwarded by this element before.  The
+request has either looped or is legitimately spiraling through the
+element.  To determine if the request has looped, the element MAY
+perform the branch parameter calculation described in Step 8 of
+Section 16.6 on this message and compare it to the parameter
+received in that Via header field.  If the parameters match, the
+request has looped.  If they differ, the request is spiraling, and
+processing continues.  If a loop is detected, the element MAY
+return a 482 (Loop Detected) response.
+5. Proxy-Require check
+Future extensions to this protocol may introduce features that
+require special handling by proxies.  Endpoints will include a
+Proxy-Require header field in requests that use these features,
+telling the proxy not to process the request unless the feature is
+understood.
+Rosenberg, et. al.          Standards Track                    [Page 95]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+If the request contains a Proxy-Require header field (Section
+20.29) with one or more option-tags this element does not
+understand, the element MUST return a 420 (Bad Extension)
+response.  The response MUST include an Unsupported (Section
+20.40) header field listing those option-tags the element did not
+understand.
+6. Proxy-Authorization check
+If an element requires credentials before forwarding a request,
+the request MUST be inspected as described in Section 22.3.  That
+section also defines what the element must do if the inspection
+fails.
+16.4 Route Information Preprocessing
+The proxy MUST inspect the Request-URI of the request.  If the
+Request-URI of the request contains a value this proxy previously
+placed into a Record-Route header field (see Section 16.6 item 4),
+the proxy MUST replace the Request-URI in the request with the last
+value from the Route header field, and remove that value from the
+Route header field.  The proxy MUST then proceed as if it received
+this modified request.
+This will only happen when the element sending the request to the
+proxy (which may have been an endpoint) is a strict router.  This
+rewrite on receive is necessary to enable backwards compatibility
+with those elements.  It also allows elements following this
+specification to preserve the Request-URI through strict-routing
+proxies (see Section 12.2.1.1).
+This requirement does not obligate a proxy to keep state in order
+to detect URIs it previously placed in Record-Route header fields.
+Instead, a proxy need only place enough information in those URIs
+to recognize them as values it provided when they later appear.
+If the Request-URI contains a maddr parameter, the proxy MUST check
+to see if its value is in the set of addresses or domains the proxy
+is configured to be responsible for.  If the Request-URI has a maddr
+parameter with a value the proxy is responsible for, and the request
+was received using the port and transport indicated (explicitly or by
+default) in the Request-URI, the proxy MUST strip the maddr and any
+non-default port or transport parameter and continue processing as if
+those values had not been present in the request.
+Rosenberg, et. al.          Standards Track                    [Page 96]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+A request may arrive with a maddr matching the proxy, but on a
+port or transport different from that indicated in the URI.  Such
+a request needs to be forwarded to the proxy using the indicated
+port and transport.
+If the first value in the Route header field indicates this proxy,
+the proxy MUST remove that value from the request.
+16.5 Determining Request Targets
+Next, the proxy calculates the target(s) of the request.  The set of
+targets will either be predetermined by the contents of the request
+or will be obtained from an abstract location service.  Each target
+in the set is represented as a URI.
+If the Request-URI of the request contains an maddr parameter, the
+Request-URI MUST be placed into the target set as the only target
+URI, and the proxy MUST proceed to Section 16.6.
+If the domain of the Request-URI indicates a domain this element is
+not responsible for, the Request-URI MUST be placed into the target
+set as the only target, and the element MUST proceed to the task of
+Request Forwarding (Section 16.6).
+There are many circumstances in which a proxy might receive a
+request for a domain it is not responsible for.  A firewall proxy
+handling outgoing calls (the way HTTP proxies handle outgoing
+requests) is an example of where this is likely to occur.
+If the target set for the request has not been predetermined as
+described above, this implies that the element is responsible for the
+domain in the Request-URI, and the element MAY use whatever mechanism
+it desires to determine where to send the request.  Any of these
+mechanisms can be modeled as accessing an abstract Location Service.
+This may consist of obtaining information from a location service
+created by a SIP Registrar, reading a database, consulting a presence
+server, utilizing other protocols, or simply performing an
+algorithmic substitution on the Request-URI.  When accessing the
+location service constructed by a registrar, the Request-URI MUST
+first be canonicalized as described in Section 10.3 before being used
+as an index.  The output of these mechanisms is used to construct the
+target set.
+If the Request-URI does not provide sufficient information for the
+proxy to determine the target set, it SHOULD return a 485 (Ambiguous)
+response.  This response SHOULD contain a Contact header field
+containing URIs of new addresses to be tried.  For example, an INVITE
+Rosenberg, et. al.          Standards Track                    [Page 97]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+to sip:John.Smith@company.com may be ambiguous at a proxy whose
+location service has multiple John Smiths listed.  See Section
+21.4.23 for details.
+Any information in or about the request or the current environment of
+the element MAY be used in the construction of the target set.  For
+instance, different sets may be constructed depending on contents or
+the presence of header fields and bodies, the time of day of the
+request's arrival, the interface on which the request arrived,
+failure of previous requests, or even the element's current level of
+utilization.
+As potential targets are located through these services, their URIs
+are added to the target set.  Targets can only be placed in the
+target set once.  If a target URI is already present in the set
+(based on the definition of equality for the URI type), it MUST NOT
+be added again.
+A proxy MUST NOT add additional targets to the target set if the
+Request-URI of the original request does not indicate a resource this
+proxy is responsible for.
+A proxy can only change the Request-URI of a request during
+forwarding if it is responsible for that URI.  If the proxy is not
+responsible for that URI, it will not recurse on 3xx or 416
+responses as described below.
+If the Request-URI of the original request indicates a resource this
+proxy is responsible for, the proxy MAY continue to add targets to
+the set after beginning Request Forwarding.  It MAY use any
+information obtained during that processing to determine new targets.
+For instance, a proxy may choose to incorporate contacts obtained in
+a redirect response (3xx) into the target set.  If a proxy uses a
+dynamic source of information while building the target set (for
+instance, if it consults a SIP Registrar), it SHOULD monitor that
+source for the duration of processing the request.  New locations
+SHOULD be added to the target set as they become available.  As
+above, any given URI MUST NOT be added to the set more than once.
+Allowing a URI to be added to the set only once reduces
+unnecessary network traffic, and in the case of incorporating
+contacts from redirect requests prevents infinite recursion.
+For example, a trivial location service is a "no-op", where the
+target URI is equal to the incoming request URI.  The request is sent
+to a specific next hop proxy for further processing.  During request
+Rosenberg, et. al.          Standards Track                    [Page 98]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+forwarding of Section 16.6, Item 6, the identity of that next hop,
+expressed as a SIP or SIPS URI, is inserted as the top-most Route
+header field value into the request.
+If the Request-URI indicates a resource at this proxy that does not
+exist, the proxy MUST return a 404 (Not Found) response.
+If the target set remains empty after applying all of the above, the
+proxy MUST return an error response, which SHOULD be the 480
+(Temporarily Unavailable) response.
+16.6 Request Forwarding
+As soon as the target set is non-empty, a proxy MAY begin forwarding
+the request.  A stateful proxy MAY process the set in any order.  It
+MAY process multiple targets serially, allowing each client
+transaction to complete before starting the next.  It MAY start
+client transactions with every target in parallel.  It also MAY
+arbitrarily divide the set into groups, processing the groups
+serially and processing the targets in each group in parallel.
+A common ordering mechanism is to use the qvalue parameter of targets
+obtained from Contact header fields (see Section 20.10).  Targets are
+processed from highest qvalue to lowest.  Targets with equal qvalues
+may be processed in parallel.
+A stateful proxy must have a mechanism to maintain the target set as
+responses are received and associate the responses to each forwarded
+request with the original request.  For the purposes of this model,
+this mechanism is a "response context" created by the proxy layer
+before forwarding the first request.
+For each target, the proxy forwards the request following these
+steps:
+1.  Make a copy of the received request
+2.  Update the Request-URI
+3.  Update the Max-Forwards header field
+4.  Optionally add a Record-route header field value
+5.  Optionally add additional header fields
+6.  Postprocess routing information
+7.  Determine the next-hop address, port, and transport
+Rosenberg, et. al.          Standards Track                    [Page 99]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+8.  Add a Via header field value
+9.  Add a Content-Length header field if necessary
+10. Forward the new request
+11. Set timer C
+Each of these steps is detailed below:
+1. Copy request
+The proxy starts with a copy of the received request.  The copy
+MUST initially contain all of the header fields from the
+received request.  Fields not detailed in the processing
+described below MUST NOT be removed.  The copy SHOULD maintain
+the ordering of the header fields as in the received request.
+The proxy MUST NOT reorder field values with a common field
+name (See Section 7.3.1).  The proxy MUST NOT add to, modify,
+or remove the message body.
+An actual implementation need not perform a copy; the primary
+requirement is that the processing for each next hop begin with
+the same request.
+2. Request-URI
+The Request-URI in the copy's start line MUST be replaced with
+the URI for this target.  If the URI contains any parameters
+not allowed in a Request-URI, they MUST be removed.
+This is the essence of a proxy's role.  This is the mechanism
+through which a proxy routes a request toward its destination.
+In some circumstances, the received Request-URI is placed into
+the target set without being modified.  For that target, the
+replacement above is effectively a no-op.
+3. Max-Forwards
+If the copy contains a Max-Forwards header field, the proxy
+MUST decrement its value by one (1).
+If the copy does not contain a Max-Forwards header field, the
+proxy MUST add one with a field value, which SHOULD be 70.
+Some existing UAs will not provide a Max-Forwards header field
+in a request.
+Rosenberg, et. al.          Standards Track                   [Page 100]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+4. Record-Route
+If this proxy wishes to remain on the path of future requests
+in a dialog created by this request (assuming the request
+creates a dialog), it MUST insert a Record-Route header field
+value into the copy before any existing Record-Route header
+field values, even if a Route header field is already present.
+Requests establishing a dialog may contain a preloaded Route
+header field.
+If this request is already part of a dialog, the proxy SHOULD
+insert a Record-Route header field value if it wishes to remain
+on the path of future requests in the dialog.  In normal
+endpoint operation as described in Section 12, these Record-
+Route header field values will not have any effect on the route
+sets used by the endpoints.
+The proxy will remain on the path if it chooses to not insert a
+Record-Route header field value into requests that are already
+part of a dialog.  However, it would be removed from the path
+when an endpoint that has failed reconstitutes the dialog.
+A proxy MAY insert a Record-Route header field value into any
+request.  If the request does not initiate a dialog, the
+endpoints will ignore the value.  See Section 12 for details on
+how endpoints use the Record-Route header field values to
+construct Route header fields.
+Each proxy in the path of a request chooses whether to add a
+Record-Route header field value independently - the presence of
+a Record-Route header field in a request does not obligate this
+proxy to add a value.
+The URI placed in the Record-Route header field value MUST be a
+SIP or SIPS URI.  This URI MUST contain an lr parameter (see
+Section 19.1.1).  This URI MAY be different for each
+destination the request is forwarded to.  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 that
+transport.
+The URI this proxy provides will be used by some other element
+to make a routing decision.  This proxy, in general, has no way
+of knowing the capabilities of that element, so it must
+restrict itself to the mandatory elements of a SIP
+implementation: SIP URIs and either the TCP or UDP transports.
+Rosenberg, et. al.          Standards Track                   [Page 101]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The URI placed in the Record-Route header field MUST resolve to
+the element inserting it (or a suitable stand-in) when the
+server location procedures of [4] are applied to it, so that
+subsequent requests reach the same SIP element.  If the
+Request-URI contains a SIPS URI, or the topmost Route header
+field value (after the post processing of bullet 6) 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 (after the post
+processing of bullet 6), MUST insert a Record-Route header
+field that is not a SIPS URI.
+A proxy at a security perimeter must remain on the perimeter
+throughout the dialog.
+If the URI placed in the Record-Route header field needs to be
+rewritten when it passes back through in a response, the URI
+MUST be distinct enough to locate at that time.  (The request
+may spiral through this proxy, resulting in more than one
+Record-Route header field value being added).  Item 8 of
+Section 16.7 recommends a mechanism to make the URI
+sufficiently distinct.
+The proxy MAY include parameters in the Record-Route header
+field value.  These will be echoed in some responses to the
+request such as the 200 (OK) responses to INVITE.  Such
+parameters may be useful for keeping state in the message
+rather than the proxy.
+If a proxy needs to be in the path of any type of dialog (such
+as one straddling a firewall), it SHOULD add a Record-Route
+header field value to every request with a method it does not
+understand since that method may have dialog semantics.
+The URI a proxy places into a Record-Route header field is only
+valid for the lifetime of any dialog created by the transaction
+in which it occurs.  A dialog-stateful proxy, for example, MAY
+refuse to accept future requests with that value in the
+Request-URI after the dialog has terminated.  Non-dialog-
+stateful proxies, of course, have no concept of when the dialog
+has terminated, but they MAY encode enough information in the
+value to compare it against the dialog identifier of future
+requests and MAY reject requests not matching that information.
+Endpoints MUST NOT use a URI obtained from a Record-Route
+header field outside the dialog in which it was provided.  See
+Rosenberg, et. al.          Standards Track                   [Page 102]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Section 12 for more information on an endpoint's use of
+Record-Route header fields.
+Record-routing may be required by certain services where the
+proxy needs to observe all messages in a dialog.  However, it
+slows down processing and impairs scalability and thus proxies
+should only record-route if required for a particular service.
+The Record-Route process is designed to work for any SIP
+request that initiates a dialog.  INVITE is the only such
+request in this specification, but extensions to the protocol
+MAY define others.
+5. Add Additional Header Fields
+The proxy MAY add any other appropriate header fields to the
+copy at this point.
+6. Postprocess routing information
+A proxy MAY have a local policy that mandates that a request
+visit a specific set of proxies before being delivered to the
+destination.  A proxy MUST ensure that all such proxies are
+loose routers.  Generally, this can only be known with
+certainty if the proxies are within the same administrative
+domain.  This set of proxies is represented by a set of URIs
+(each of which contains the lr parameter).  This set MUST be
+pushed into the Route header field of the copy ahead of any
+existing values, if present.  If the Route header field is
+absent, it MUST be added, containing that list of URIs.
+If the proxy has a local policy that mandates that the request
+visit one specific proxy, an alternative to pushing a Route
+value into the Route header field is to bypass the forwarding
+logic of item 10 below, and instead just send the request to
+the address, port, and transport for that specific proxy.  If
+the request has a Route header field, this alternative MUST NOT
+be used unless it is known that next hop proxy is a loose
+router.  Otherwise, this approach MAY be used, but the Route
+insertion mechanism above is preferred for its robustness,
+flexibility, generality and consistency of operation.
+Furthermore, if the Request-URI contains a SIPS URI, TLS MUST
+be used to communicate with that proxy.
+If the copy contains a Route header field, the proxy MUST
+inspect the URI in its first value.  If that URI does not
+contain an lr parameter, the proxy MUST modify the copy as
+follows:
+Rosenberg, et. al.          Standards Track                   [Page 103]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+-  The proxy MUST place the Request-URI into the Route header
+field as the last value.
+-  The proxy MUST then place the first Route header field value
+into the Request-URI and remove that value from the Route
+header field.
+Appending the Request-URI to the Route header field is part of
+a mechanism used to pass the information in that Request-URI
+through strict-routing elements.  "Popping" the first Route
+header field value into the Request-URI formats the message the
+way a strict-routing element expects to receive it (with its
+own URI in the Request-URI and the next location to visit in
+the first Route header field value).
+7. Determine Next-Hop Address, Port, and Transport
+The proxy MAY have a local policy to send the request to a
+specific IP address, port, and transport, independent of the
+values of the Route and Request-URI.  Such a policy MUST NOT be
+used if the proxy is not certain that the IP address, port, and
+transport correspond to a server that is a loose router.
+However, this mechanism for sending the request through a
+specific next hop is NOT RECOMMENDED; instead a Route header
+field should be used for that purpose as described above.
+In the absence of such an overriding mechanism, the proxy
+applies the procedures listed in [4] as follows to determine
+where to send the request.  If the proxy has reformatted the
+request to send to a strict-routing element as described in
+step 6 above, the proxy MUST apply those procedures to the
+Request-URI of the request.  Otherwise, the proxy MUST apply
+the procedures to the first value in the Route header field, if
+present, else the Request-URI.  The procedures will produce an
+ordered set of (address, port, transport) tuples.
+Independently of which URI is being used as input to the
+procedures of [4], if the Request-URI specifies a SIPS
+resource, the proxy MUST follow the procedures of [4] as if the
+input URI were a SIPS URI.
+As described in [4], the proxy MUST attempt to deliver the
+message to the first tuple in that set, and proceed through the
+set in order until the delivery attempt succeeds.
+For each tuple attempted, the proxy MUST format the message as
+appropriate for the tuple and send the request using a new
+client transaction as detailed in steps 8 through 10.
+Rosenberg, et. al.          Standards Track                   [Page 104]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Since each attempt uses a new client transaction, it represents
+a new branch.  Thus, the branch parameter provided with the Via
+header field inserted in step 8 MUST be different for each
+attempt.
+If the client transaction reports failure to send the request
+or a timeout from its state machine, the proxy continues to the
+next address in that ordered set.  If the ordered set is
+exhausted, the request cannot be forwarded to this element in
+the target set.  The proxy does not need to place anything in
+the response context, but otherwise acts as if this element of
+the target set returned a 408 (Request Timeout) final response.
+8. Add a Via header field value
+The proxy MUST insert a Via header field value into the copy
+before the existing Via header field values.  The construction
+of this value follows the same guidelines of Section 8.1.1.7.
+This implies that the proxy will compute its own branch
+parameter, which will be globally unique for that branch, and
+contain the requisite magic cookie. Note that this implies that
+the branch parameter will be different for different instances
+of a spiraled or looped request through a proxy.
+Proxies choosing to detect loops have an additional constraint
+in the value they use for construction of the branch parameter.
+A proxy choosing to detect loops SHOULD create a branch
+parameter separable into two parts by the implementation.  The
+first part MUST satisfy the constraints of Section 8.1.1.7 as
+described above.  The second is used to perform loop detection
+and distinguish loops from spirals.
+Loop detection is performed by verifying that, when a request
+returns to a proxy, those fields having an impact on the
+processing of the request have not changed.  The value placed
+in this part of the branch parameter SHOULD reflect all of
+those fields (including any Route, Proxy-Require and Proxy-
+Authorization header fields).  This is to ensure that if the
+request is routed back to the proxy and one of those fields
+changes, it is treated as a spiral and not a loop (see Section
+16.3).  A common way to create this value is to compute a
+cryptographic hash of the To tag, From tag, Call-ID header
+field, the Request-URI of the request received (before
+translation), the topmost Via header, and the sequence number
+from the CSeq header field, in addition to any Proxy-Require
+and Proxy-Authorization header fields that may be present.  The
+Rosenberg, et. al.          Standards Track                   [Page 105]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+algorithm used to compute the hash is implementation-dependent,
+but MD5 (RFC 1321 [35]), expressed in hexadecimal, is a
+reasonable choice.  (Base64 is not permissible for a token.)
+If a proxy wishes to detect loops, the "branch" parameter it
+supplies MUST depend on all information affecting processing of
+a request, including the incoming Request-URI and any header
+fields affecting the request's admission or routing.  This is
+necessary to distinguish looped requests from requests whose
+routing parameters have changed before returning to this
+server.
+The request method MUST NOT be included in the calculation of
+the branch parameter.  In particular, CANCEL and ACK requests
+(for non-2xx responses) MUST have the same branch value as the
+corresponding request they cancel or acknowledge.  The branch
+parameter is used in correlating those requests at the server
+handling them (see Sections 17.2.3 and 9.2).
+9. Add a Content-Length header field if necessary
+If the request will be sent to the next hop using a stream-
+based transport and the copy contains no Content-Length header
+field, the proxy MUST insert one with the correct value for the
+body of the request (see Section 20.14).
+10. Forward Request
+A stateful proxy MUST create a new client transaction for this
+request as described in Section 17.1 and instructs the
+transaction to send the request using the address, port and
+transport determined in step 7.
+11. Set timer C
+In order to handle the case where an INVITE request never
+generates a final response, the TU uses a timer which is called
+timer C.  Timer C MUST be set for each client transaction when
+an INVITE request is proxied.  The timer MUST be larger than 3
+minutes.  Section 16.7 bullet 2 discusses how this timer is
+updated with provisional responses, and Section 16.8 discusses
+processing when it fires.
+Rosenberg, et. al.          Standards Track                   [Page 106]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+16.7 Response Processing
+When a response is received by an element, it first tries to locate a
+client transaction (Section 17.1.3) matching the response.  If none
+is found, the element MUST process the response (even if it is an
+informational response) as a stateless proxy (described below).  If a
+match is found, the response is handed to the client transaction.
+Forwarding responses for which a client transaction (or more
+generally any knowledge of having sent an associated request) is
+not found improves robustness.  In particular, it ensures that
+"late" 2xx responses to INVITE requests are forwarded properly.
+As client transactions pass responses to the proxy layer, the
+following processing MUST take place:
+1.  Find the appropriate response context
+2.  Update timer C for provisional responses
+3.  Remove the topmost Via
+4.  Add the response to the response context
+5.  Check to see if this response should be forwarded immediately
+6.  When necessary, choose the best final response from the
+response context
+If no final response has been forwarded after every client
+transaction associated with the response context has been terminated,
+the proxy must choose and forward the "best" response from those it
+has seen so far.
+The following processing MUST be performed on each response that is
+forwarded.  It is likely that more than one response to each request
+will be forwarded: at least each provisional and one final response.
+7.  Aggregate authorization header field values if necessary
+8.  Optionally rewrite Record-Route header field values
+9.  Forward the response
+10. Generate any necessary CANCEL requests
+Rosenberg, et. al.          Standards Track                   [Page 107]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Each of the above steps are detailed below:
+1.  Find Context
+The proxy locates the "response context" it created before
+forwarding the original request using the key described in
+Section 16.6.  The remaining processing steps take place in
+this context.
+2.  Update timer C for provisional responses
+For an INVITE transaction, if the response is a provisional
+response with status codes 101 to 199 inclusive (i.e., anything
+but 100), the proxy MUST reset timer C for that client
+transaction.  The timer MAY be reset to a different value, but
+this value MUST be greater than 3 minutes.
+3.  Via
+The proxy removes the topmost Via header field value from the
+response.
+If no Via header field values remain in the response, the
+response was meant for this element and MUST NOT be forwarded.
+The remainder of the processing described in this section is
+not performed on this message, the UAC processing rules
+described in Section 8.1.3 are followed instead (transport
+layer processing has already occurred).
+This will happen, for instance, when the element generates
+CANCEL requests as described in Section 10.
+4.  Add response to context
+Final responses received are stored in the response context
+until a final response is generated on the server transaction
+associated with this context.  The response may be a candidate
+for the best final response to be returned on that server
+transaction.  Information from this response may be needed in
+forming the best response, even if this response is not chosen.
+If the proxy chooses to recurse on any contacts in a 3xx
+response by adding them to the target set, it MUST remove them
+from the response before adding the response to the response
+context.  However, a proxy SHOULD NOT recurse to a non-SIPS URI
+if the Request-URI of the original request was a SIPS URI.  If
+Rosenberg, et. al.          Standards Track                   [Page 108]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+the proxy recurses on all of the contacts in a 3xx response,
+the proxy SHOULD NOT add the resulting contactless response to
+the response context.
+Removing the contact before adding the response to the response
+context prevents the next element upstream from retrying a
+location this proxy has already attempted.
+3xx responses may contain a mixture of SIP, SIPS, and non-SIP
+URIs.  A proxy may choose to recurse on the SIP and SIPS URIs
+and place the remainder into the response context to be
+returned, potentially in the final response.
+If a proxy receives a 416 (Unsupported URI Scheme) response to
+a request whose Request-URI scheme was not SIP, but the scheme
+in the original received request was SIP or SIPS (that is, the
+proxy changed the scheme from SIP or SIPS to something else
+when it proxied a request), the proxy SHOULD add a new URI to
+the target set.  This URI SHOULD be a SIP URI version of the
+non-SIP URI that was just tried.  In the case of the tel URL,
+this is accomplished by placing the telephone-subscriber part
+of the tel URL into the user part of the SIP URI, and setting
+the hostpart to the domain where the prior request was sent.
+See Section 19.1.6 for more detail on forming SIP URIs from tel
+URLs.
+As with a 3xx response, if a proxy "recurses" on the 416 by
+trying a SIP or SIPS URI instead, the 416 response SHOULD NOT
+be added to the response context.
+5.  Check response for forwarding
+Until a final response has been sent on the server transaction,
+the following responses MUST be forwarded immediately:
+-  Any provisional response other than 100 (Trying)
+-  Any 2xx response
+If a 6xx response is received, it is not immediately forwarded,
+but the stateful proxy SHOULD cancel all client pending
+transactions as described in Section 10, and it MUST NOT create
+any new branches in this context.
+This is a change from RFC 2543, which mandated that the proxy
+was to forward the 6xx response immediately.  For an INVITE
+transaction, this approach had the problem that a 2xx response
+could arrive on another branch, in which case the proxy would
+Rosenberg, et. al.          Standards Track                   [Page 109]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+have to forward the 2xx.  The result was that the UAC could
+receive a 6xx response followed by a 2xx response, which should
+never be allowed to happen.  Under the new rules, upon
+receiving a 6xx, a proxy will issue a CANCEL request, which
+will generally result in 487 responses from all outstanding
+client transactions, and then at that point the 6xx is
+forwarded upstream.
+After a final response has been sent on the server transaction,
+the following responses MUST be forwarded immediately:
+-  Any 2xx response to an INVITE request
+A stateful proxy MUST NOT immediately forward any other
+responses.  In particular, a stateful proxy MUST NOT forward
+any 100 (Trying) response.  Those responses that are candidates
+for forwarding later as the "best" response have been gathered
+as described in step "Add Response to Context".
+Any response chosen for immediate forwarding MUST be processed
+as described in steps "Aggregate Authorization Header Field
+Values" through "Record-Route".
+This step, combined with the next, ensures that a stateful
+proxy will forward exactly one final response to a non-INVITE
+request, and either exactly one non-2xx response or one or more
+2xx responses to an INVITE request.
+6.  Choosing the best response
+A stateful proxy MUST send a final response to a response
+context's server transaction if no final responses have been
+immediately forwarded by the above rules and all client
+transactions in this response context have been terminated.
+The stateful proxy MUST choose the "best" final response among
+those received and stored in the response context.
+If there are no final responses in the context, the proxy MUST
+send a 408 (Request Timeout) response to the server
+transaction.
+Otherwise, the proxy MUST forward a response from the responses
+stored in the response context.  It MUST choose from the 6xx
+class responses if any exist in the context.  If no 6xx class
+responses are present, the proxy SHOULD choose from the lowest
+response class stored in the response context.  The proxy MAY
+select any response within that chosen class.  The proxy SHOULD
+Rosenberg, et. al.          Standards Track                   [Page 110]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+give preference to responses that provide information affecting
+resubmission of this request, such as 401, 407, 415, 420, and
+484 if the 4xx class is chosen.
+A proxy which receives a 503 (Service Unavailable) response
+SHOULD NOT forward it upstream unless it can determine that any
+subsequent requests it might proxy will also generate a 503.
+In other words, forwarding a 503 means that the proxy knows it
+cannot service any requests, not just the one for the Request-
+URI in the request which generated the 503.  If the only
+response that was received is a 503, the proxy SHOULD generate
+a 500 response and forward that upstream.
+The forwarded response MUST be processed as described in steps
+"Aggregate Authorization Header Field Values" through "Record-
+Route".
+For example, if a proxy forwarded a request to 4 locations, and
+received 503, 407, 501, and 404 responses, it may choose to
+forward the 407 (Proxy Authentication Required) response.
+1xx and 2xx responses may be involved in the establishment of
+dialogs.  When a request does not contain a To tag, the To tag
+in the response is used by the UAC to distinguish multiple
+responses to a dialog creating request.  A proxy MUST NOT
+insert a tag into the To header field of a 1xx or 2xx response
+if the request did not contain one.  A proxy MUST NOT modify
+the tag in the To header field of a 1xx or 2xx response.
+Since a proxy may not insert a tag into the To header field of
+a 1xx response to a request that did not contain one, it cannot
+issue non-100 provisional responses on its own.  However, it
+can branch the request to a UAS sharing the same element as the
+proxy.  This UAS can return its own provisional responses,
+entering into an early dialog with the initiator of the
+request.  The UAS does not have to be a discreet process from
+the proxy.  It could be a virtual UAS implemented in the same
+code space as the proxy.
+3-6xx responses are delivered hop-by-hop.  When issuing a 3-6xx
+response, the element is effectively acting as a UAS, issuing
+its own response, usually based on the responses received from
+downstream elements.  An element SHOULD preserve the To tag
+when simply forwarding a 3-6xx response to a request that did
+not contain a To tag.
+A proxy MUST NOT modify the To tag in any forwarded response to
+a request that contains a To tag.
+Rosenberg, et. al.          Standards Track                   [Page 111]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+While it makes no difference to the upstream elements if the
+proxy replaced the To tag in a forwarded 3-6xx response,
+preserving the original tag may assist with debugging.
+When the proxy is aggregating information from several
+responses, choosing a To tag from among them is arbitrary, and
+generating a new To tag may make debugging easier.  This
+happens, for instance, when combining 401 (Unauthorized) and
+407 (Proxy Authentication Required) challenges, or combining
+Contact values from unencrypted and unauthenticated 3xx
+responses.
+7.  Aggregate Authorization Header Field Values
+If the selected response is a 401 (Unauthorized) or 407 (Proxy
+Authentication Required), the proxy MUST collect any WWW-
+Authenticate and Proxy-Authenticate header field values from
+all other 401 (Unauthorized) and 407 (Proxy Authentication
+Required) responses received so far in this response context
+and add them to this response without modification before
+forwarding.  The resulting 401 (Unauthorized) or 407 (Proxy
+Authentication Required) response could have several WWW-
+Authenticate AND Proxy-Authenticate header field values.
+This is necessary because any or all of the destinations the
+request was forwarded to may have requested credentials.  The
+client needs to receive all of those challenges and supply
+credentials for each of them when it retries the request.
+Motivation for this behavior is provided in Section 26.
+8.  Record-Route
+If the selected response contains a Record-Route header field
+value originally provided by this proxy, the proxy MAY choose
+to rewrite the value before forwarding the response.  This
+allows the proxy to provide different URIs for itself to the
+next upstream and downstream elements.  A proxy may choose to
+use this mechanism for any reason.  For instance, it is useful
+for multi-homed hosts.
+If the proxy received the request over TLS, and sent it out
+over 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 out
+over TLS, the proxy MUST rewrite the URI in the Record-Route
+header field to be a SIP URI.
+Rosenberg, et. al.          Standards Track                   [Page 112]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The new URI provided by the proxy MUST satisfy the same
+constraints on URIs placed in Record-Route header fields in
+requests (see Step 4 of Section 16.6) with the following
+modifications:
+The URI SHOULD NOT contain the transport parameter unless the
+proxy has knowledge that the next upstream (as opposed to
+downstream) element that will be in the path of subsequent
+requests supports that transport.
+When a proxy does decide to modify the Record-Route header
+field in the response, one of the operations it performs is
+locating the Record-Route value that it had inserted.  If the
+request spiraled, and the proxy inserted a Record-Route value
+in each iteration of the spiral, locating the correct value in
+the response (which must be the proper iteration in the reverse
+direction) is tricky.  The rules above recommend that a proxy
+wishing to rewrite Record-Route header field values insert
+sufficiently distinct URIs into the Record-Route header field
+so that the right one may be selected for rewriting.  A
+RECOMMENDED mechanism to achieve this is for the proxy to
+append a unique identifier for the proxy instance to the user
+portion of the URI.
+When the response arrives, the proxy modifies the first
+Record-Route whose identifier matches the proxy instance.  The
+modification results in a URI without this piece of data
+appended to the user portion of the URI.  Upon the next
+iteration, the same algorithm (find the topmost Record-Route
+header field value with the parameter) will correctly extract
+the next Record-Route header field value inserted by that
+proxy.
+Not every response to a request to which a proxy adds a
+Record-Route header field value will contain a Record-Route
+header field.  If the response does contain a Record-Route
+header field, it will contain the value the proxy added.
+9.  Forward response
+After performing the processing described in steps "Aggregate
+Authorization Header Field Values" through "Record-Route", the
+proxy MAY perform any feature specific manipulations on the
+selected response.  The proxy MUST NOT add to, modify, or
+remove the message body.  Unless otherwise specified, the proxy
+MUST NOT remove any header field values other than the Via
+header field value discussed in Section 16.7 Item 3.  In
+particular, the proxy MUST NOT remove any "received" parameter
+Rosenberg, et. al.          Standards Track                   [Page 113]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+it may have added to the next Via header field value while
+processing the request associated with this response.  The
+proxy MUST pass the response to the server transaction
+associated with the response context.  This will result in the
+response being sent to the location now indicated in the
+topmost Via header field value.  If the server transaction is
+no longer available to handle the transmission, the element
+MUST forward the response statelessly by sending it to the
+server transport.  The server transaction might indicate
+failure to send the response or signal a timeout in its state
+machine.  These errors would be logged for diagnostic purposes
+as appropriate, but the protocol requires no remedial action
+from the proxy.
+The proxy MUST maintain the response context until all of its
+associated transactions have been terminated, even after
+forwarding a final response.
+10. Generate CANCELs
+If the forwarded response was a final response, the proxy MUST
+generate a CANCEL request for all pending client transactions
+associated with this response context.  A proxy SHOULD also
+generate a CANCEL request for all pending client transactions
+associated with this response context when it receives a 6xx
+response.  A pending client transaction is one that has
+received a provisional response, but no final response (it is
+in the proceeding state) and has not had an associated CANCEL
+generated for it.  Generating CANCEL requests is described in
+Section 9.1.
+The requirement to CANCEL pending client transactions upon
+forwarding a final response does not guarantee that an endpoint
+will not receive multiple 200 (OK) responses to an INVITE.  200
+(OK) responses on more than one branch may be generated before
+the CANCEL requests can be sent and processed.  Further, it is
+reasonable to expect that a future extension may override this
+requirement to issue CANCEL requests.
+16.8 Processing Timer C
+If timer C should fire, the proxy MUST either reset the timer with
+any value it chooses, or terminate the client transaction.  If the
+client transaction has received a provisional response, the proxy
+MUST generate a CANCEL request matching that transaction.  If the
+client transaction has not received a provisional response, the proxy
+MUST behave as if the transaction received a 408 (Request Timeout)
+response.
+Rosenberg, et. al.          Standards Track                   [Page 114]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Allowing the proxy to reset the timer allows the proxy to dynamically
+extend the transaction's lifetime based on current conditions (such
+as utilization) when the timer fires.
+16.9 Handling Transport Errors
+If the transport layer notifies a proxy of an error when it tries to
+forward a request (see Section 18.4), the proxy MUST behave as if the
+forwarded request received a 503 (Service Unavailable) response.
+If the proxy is notified of an error when forwarding a response, it
+drops the response.  The proxy SHOULD NOT cancel any outstanding
+client transactions associated with this response context due to this
+notification.
+If a proxy cancels its outstanding client transactions, a single
+malicious or misbehaving client can cause all transactions to fail
+through its Via header field.
+16.10 CANCEL Processing
+A stateful proxy MAY generate a CANCEL to any other request it has
+generated at any time (subject to receiving a provisional response to
+that request as described in section 9.1).  A proxy MUST cancel any
+pending client transactions associated with a response context when
+it receives a matching CANCEL request.
+A stateful proxy MAY generate CANCEL requests for pending INVITE
+client transactions based on the period specified in the INVITE's
+Expires header field elapsing.  However, this is generally
+unnecessary since the endpoints involved will take care of signaling
+the end of the transaction.
+While a CANCEL request is handled in a stateful proxy by its own
+server transaction, a new response context is not created for it.
+Instead, the proxy layer searches its existing response contexts for
+the server transaction handling the request associated with this
+CANCEL.  If a matching response context is found, the element MUST
+immediately return a 200 (OK) response to the CANCEL request.  In
+this case, the element is acting as a user agent server as defined in
+Section 8.2.  Furthermore, the element MUST generate CANCEL requests
+for all pending client transactions in the context as described in
+Section 16.7 step 10.
+If a response context is not found, the element does not have any
+knowledge of the request to apply the CANCEL to.  It MUST statelessly
+forward the CANCEL request (it may have statelessly forwarded the
+associated request previously).
+Rosenberg, et. al.          Standards Track                   [Page 115]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+16.11 Stateless Proxy
+When acting statelessly, a proxy is a simple message forwarder.  Much
+of the processing performed when acting statelessly is the same as
+when behaving statefully.  The differences are detailed here.
+A stateless proxy does not have any notion of a transaction, or of
+the response context used to describe stateful proxy behavior.
+Instead, the stateless proxy takes messages, both requests and
+responses, directly from the transport layer (See section 18).  As a
+result, stateless proxies do not retransmit messages on their own.
+They do, however, forward all retransmissions they receive (they do
+not have the ability to distinguish a retransmission from the
+original message).  Furthermore, when handling a request statelessly,
+an element MUST NOT generate its own 100 (Trying) or any other
+provisional response.
+A stateless proxy MUST validate a request as described in Section
+16.3
+A stateless proxy MUST follow the request processing steps described
+in Sections 16.4 through 16.5 with the following exception:
+o  A stateless proxy MUST choose one and only one target from the
+target set.  This choice MUST only rely on fields in the
+message and time-invariant properties of the server.  In
+particular, a retransmitted request MUST be forwarded to the
+same destination each time it is processed.  Furthermore,
+CANCEL and non-Routed ACK requests MUST generate the same
+choice as their associated INVITE.
+A stateless proxy MUST follow the request processing steps described
+in Section 16.6 with the following exceptions:
+o  The requirement for unique branch IDs across space and time
+applies to stateless proxies as well.  However, a stateless
+proxy cannot simply use a random number generator to compute
+the first component of the branch ID, as described in Section
+16.6 bullet 8.  This is because retransmissions of a request
+need to have the same value, and a stateless proxy cannot tell
+a retransmission from the original request.  Therefore, the
+component of the branch parameter that makes it unique MUST be
+the same each time a retransmitted request is forwarded.  Thus
+for a stateless proxy, the branch parameter MUST be computed as
+a combinatoric function of message parameters which are
+invariant on retransmission.
+Rosenberg, et. al.          Standards Track                   [Page 116]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The stateless proxy MAY use any technique it likes to guarantee
+uniqueness of its branch IDs across transactions.  However, the
+following procedure is RECOMMENDED.  The proxy examines the
+branch ID in the topmost Via header field of the received
+request.  If it begins with the magic cookie, the first
+component of the branch ID of the outgoing request is computed
+as a hash of the received branch ID.  Otherwise, the first
+component of the branch ID is computed as a hash of the topmost
+Via, the tag in the To header field, the tag in the From header
+field, the Call-ID header field, the CSeq number (but not
+method), and the Request-URI from the received request.  One of
+these fields will always vary across two different
+transactions.
+o  All other message transformations specified in Section 16.6
+MUST result in the same transformation of a retransmitted
+request.  In particular, if the proxy inserts a Record-Route
+value or pushes URIs into the Route header field, it MUST place
+the same values in retransmissions of the request.  As for the
+Via branch parameter, this implies that the transformations
+MUST be based on time-invariant configuration or
+retransmission-invariant properties of the request.
+o  A stateless proxy determines where to forward the request as
+described for stateful proxies in Section 16.6 Item 10.  The
+request is sent directly to the transport layer instead of
+through a client transaction.
+Since a stateless proxy must forward retransmitted requests to
+the same destination and add identical branch parameters to
+each of them, it can only use information from the message
+itself and time-invariant configuration data for those
+calculations.  If the configuration state is not time-invariant
+(for example, if a routing table is updated) any requests that
+could be affected by the change may not be forwarded
+statelessly during an interval equal to the transaction timeout
+window before or after the change.  The method of processing
+the affected requests in that interval is an implementation
+decision.  A common solution is to forward them transaction
+statefully.
+Stateless proxies MUST NOT perform special processing for CANCEL
+requests.  They are processed by the above rules as any other
+requests.  In particular, a stateless proxy applies the same Route
+header field processing to CANCEL requests that it applies to any
+other request.
+Rosenberg, et. al.          Standards Track                   [Page 117]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Response processing as described in Section 16.7 does not apply to a
+proxy behaving statelessly.  When a response arrives at a stateless
+proxy, the proxy MUST inspect the sent-by value in the first
+(topmost) Via header field value.  If that address matches the proxy,
+(it equals a value this proxy has inserted into previous requests)
+the proxy MUST remove that header field value from the response and
+forward the result to the location indicated in the next Via header
+field value.  The proxy MUST NOT add to, modify, or remove the
+message body.  Unless specified otherwise, the proxy MUST NOT remove
+any other header field values.  If the address does not match the
+proxy, the message MUST be silently discarded.
+16.12 Summary of Proxy Route Processing
+In the absence of local policy to the contrary, the processing a
+proxy performs on a request containing a Route header field can be
+summarized in the following steps.
+1.  The proxy will inspect the Request-URI.  If it indicates a
+resource owned by this proxy, the proxy will replace it with
+the results of running a location service.  Otherwise, the
+proxy will not change the Request-URI.
+2.  The proxy will inspect the URI in the topmost Route header
+field value.  If it indicates this proxy, the proxy removes it
+from the Route header field (this route node has been
+reached).
+3.  The proxy will forward the request to the resource indicated
+by the URI in the topmost Route header field value or in the
+Request-URI if no Route header field is present.  The proxy
+determines the address, port and transport to use when
+forwarding the request by applying the procedures in [4] to
+that URI.
+If no strict-routing elements are encountered on the path of the
+request, the Request-URI will always indicate the target of the
+request.
+16.12.1 Examples
+16.12.1.1 Basic SIP Trapezoid
+This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with
+both proxies record-routing.  Here is the flow.
+Rosenberg, et. al.          Standards Track                   [Page 118]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+U1 sends:
+INVITE sip:callee@domain.com SIP/2.0
+Contact: sip:caller@u1.example.com
+to P1.  P1 is an outbound proxy.  P1 is not responsible for
+domain.com, so it looks it up in DNS and sends it there.  It also
+adds a Record-Route header field value:
+INVITE sip:callee@domain.com SIP/2.0
+Contact: sip:caller@u1.example.com
+Record-Route: <sip:p1.example.com;lr>
+P2 gets this.  It is responsible for domain.com so it runs a location
+service and rewrites the Request-URI.  It also adds a Record-Route
+header field value.  There is no Route header field, so it resolves
+the new Request-URI to determine where to send the request:
+INVITE sip:callee@u2.domain.com SIP/2.0
+Contact: sip:caller@u1.example.com
+Record-Route: <sip:p2.domain.com;lr>
+Record-Route: <sip:p1.example.com;lr>
+The callee at u2.domain.com gets this and responds with a 200 OK:
+SIP/2.0 200 OK
+Contact: sip:callee@u2.domain.com
+Record-Route: <sip:p2.domain.com;lr>
+Record-Route: <sip:p1.example.com;lr>
+The callee at u2 also sets its dialog state's remote target URI to
+sip:caller@u1.example.com and its route set to:
+(<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)
+This is forwarded by P2 to P1 to U1 as normal.  Now, U1 sets its
+dialog state's remote target URI to sip:callee@u2.domain.com and its
+route set to:
+(<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>)
+Since all the route set elements contain the lr parameter, U1
+constructs the following BYE request:
+BYE sip:callee@u2.domain.com SIP/2.0
+Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>
+Rosenberg, et. al.          Standards Track                   [Page 119]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+As any other element (including proxies) would do, it resolves the
+URI in the topmost Route header field value using DNS to determine
+where to send the request.  This goes to P1.  P1 notices that it is
+not responsible for the resource indicated in the Request-URI so it
+doesn't change it.  It does see that it is the first value in the
+Route header field, so it removes that value, and forwards the
+request to P2:
+BYE sip:callee@u2.domain.com SIP/2.0
+Route: <sip:p2.domain.com;lr>
+P2 also notices it is not responsible for the resource indicated by
+the Request-URI (it is responsible for domain.com, not
+u2.domain.com), so it doesn't change it.  It does see itself in the
+first Route header field value, so it removes it and forwards the
+following to u2.domain.com based on a DNS lookup against the
+Request-URI:
+BYE sip:callee@u2.domain.com SIP/2.0
+16.12.1.2 Traversing a Strict-Routing Proxy
+In this scenario, a dialog is established across four proxies, each
+of which adds Record-Route header field values.  The third proxy
+implements the strict-routing procedures specified in RFC 2543 and
+many works in progress.
+U1->P1->P2->P3->P4->U2
+The INVITE arriving at U2 contains:
+INVITE sip:callee@u2.domain.com SIP/2.0
+Contact: sip:caller@u1.example.com
+Record-Route: <sip:p4.domain.com;lr>
+Record-Route: <sip:p3.middle.com>
+Record-Route: <sip:p2.example.com;lr>
+Record-Route: <sip:p1.example.com;lr>
+Which U2 responds to with a 200 OK.  Later, U2 sends the following
+BYE request to P4 based on the first Route header field value.
+BYE sip:caller@u1.example.com SIP/2.0
+Route: <sip:p4.domain.com;lr>
+Route: <sip:p3.middle.com>
+Route: <sip:p2.example.com;lr>
+Route: <sip:p1.example.com;lr>
+Rosenberg, et. al.          Standards Track                   [Page 120]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+P4 is not responsible for the resource indicated in the Request-URI
+so it will leave it alone.  It notices that it is the element in the
+first Route header field value so it removes it.  It then prepares to
+send the request based on the now first Route header field value of
+sip:p3.middle.com, but it notices that this URI does not contain the
+lr parameter, so before sending, it reformats the request to be:
+BYE sip:p3.middle.com SIP/2.0
+Route: <sip:p2.example.com;lr>
+Route: <sip:p1.example.com;lr>
+Route: <sip:caller@u1.example.com>
+P3 is a strict router, so it forwards the following to P2:
+BYE sip:p2.example.com;lr SIP/2.0
+Route: <sip:p1.example.com;lr>
+Route: <sip:caller@u1.example.com>
+P2 sees the request-URI is a value it placed into a Record-Route
+header field, so before further processing, it rewrites the request
+to be:
+BYE sip:caller@u1.example.com SIP/2.0
+Route: <sip:p1.example.com;lr>
+P2 is not responsible for u1.example.com, so it sends the request to
+P1 based on the resolution of the Route header field value.
+P1 notices itself in the topmost Route header field value, so it
+removes it, resulting in:
+BYE sip:caller@u1.example.com SIP/2.0
+Since P1 is not responsible for u1.example.com and there is no Route
+header field, P1 will forward the request to u1.example.com based on
+the Request-URI.
+16.12.1.3 Rewriting Record-Route Header Field Values
+In this scenario, U1 and U2 are in different private namespaces and
+they enter a dialog through a proxy P1, which acts as a gateway
+between the namespaces.
+U1->P1->U2
+Rosenberg, et. al.          Standards Track                   [Page 121]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+U1 sends:
+INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0
+Contact: <sip:caller@u1.leftprivatespace.com>
+P1 uses its location service and sends the following to U2:
+INVITE sip:callee@rightprivatespace.com SIP/2.0
+Contact: <sip:caller@u1.leftprivatespace.com>
+Record-Route: <sip:gateway.rightprivatespace.com;lr>
+U2 sends this 200 (OK) back to P1:
+SIP/2.0 200 OK
+Contact: <sip:callee@u2.rightprivatespace.com>
+Record-Route: <sip:gateway.rightprivatespace.com;lr>
+P1 rewrites its Record-Route header parameter to provide a value that
+U1 will find useful, and sends the following to U1:
+SIP/2.0 200 OK
+Contact: <sip:callee@u2.rightprivatespace.com>
+Record-Route: <sip:gateway.leftprivatespace.com;lr>
+Later, U1 sends the following BYE request to P1:
+BYE sip:callee@u2.rightprivatespace.com SIP/2.0
+Route: <sip:gateway.leftprivatespace.com;lr>
+which P1 forwards to U2 as:
+BYE sip:callee@u2.rightprivatespace.com SIP/2.0
+17 Transactions
+SIP is a transactional protocol: interactions between components take
+place in a series of independent message exchanges.  Specifically, a
+SIP transaction consists of a single request and any responses to
+that request, which include zero or more provisional responses and
+one or more final responses.  In the case of a transaction where the
+request was an INVITE (known as an INVITE transaction), the
+transaction also includes the ACK only if the final response was not
+a 2xx response.  If the response was a 2xx, the ACK is not considered
+part of the transaction.
+The reason for this separation is rooted in the importance of
+delivering all 200 (OK) responses to an INVITE to the UAC.  To
+deliver them all to the UAC, the UAS alone takes responsibility
+Rosenberg, et. al.          Standards Track                   [Page 122]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+for retransmitting them (see Section 13.3.1.4), and the UAC alone
+takes responsibility for acknowledging them with ACK (see Section
+13.2.2.4).  Since this ACK is retransmitted only by the UAC, it is
+effectively considered its own transaction.
+Transactions have a client side and a server side.  The client side
+is known as a client transaction and the server side as a server
+transaction.  The client transaction sends the request, and the
+server transaction sends the response.  The client and server
+transactions are logical functions that are embedded in any number of
+elements.  Specifically, they exist within user agents and stateful
+proxy servers.  Consider the example in Section 4.  In this example,
+the UAC executes the client transaction, and its outbound proxy
+executes the server transaction.  The outbound proxy also executes a
+client transaction, which sends the request to a server transaction
+in the inbound proxy.  That proxy also executes a client transaction,
+which in turn sends the request to a server transaction in the UAS.
+This is shown in Figure 4.
++---------+        +---------+        +---------+        +---------+
+|      +-+|Request |+-+   +-+|Request |+-+   +-+|Request |+-+      |
+|      |C||------->||S|   |C||------->||S|   |C||------->||S|      |
+|      |l||        ||e|   |l||        ||e|   |l||        ||e|      |
+|      |i||        ||r|   |i||        ||r|   |i||        ||r|      |
+|      |e||        ||v|   |e||        ||v|   |e||        ||v|      |
+|      |n||        ||e|   |n||        ||e|   |n||        ||e|      |
+|      |t||        ||r|   |t||        ||r|   |t||        ||r|      |
+|      | ||        || |   | ||        || |   | ||        || |      |
+|      |T||        ||T|   |T||        ||T|   |T||        ||T|      |
+|      |r||        ||r|   |r||        ||r|   |r||        ||r|      |
+|      |a||        ||a|   |a||        ||a|   |a||        ||a|      |
+|      |n||        ||n|   |n||        ||n|   |n||        ||n|      |
+|      |s||Response||s|   |s||Response||s|   |s||Response||s|      |
+|      +-+|<-------|+-+   +-+|<-------|+-+   +-+|<-------|+-+      |
++---------+        +---------+        +---------+        +---------+
+UAC               Outbound           Inbound              UAS
+Proxy               Proxy
+Figure 4: Transaction relationships
+A stateless proxy does not contain a client or server transaction.
+The transaction exists between the UA or stateful proxy on one side,
+and the UA or stateful proxy on the other side.  As far as SIP
+transactions are concerned, stateless proxies are effectively
+transparent.  The purpose of the client transaction is to receive a
+request from the element in which the client is embedded (call this
+element the "Transaction User" or TU; it can be a UA or a stateful
+proxy), and reliably deliver the request to a server transaction.
+Rosenberg, et. al.          Standards Track                   [Page 123]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The client transaction is also responsible for receiving responses
+and delivering them to the TU, filtering out any response
+retransmissions or disallowed responses (such as a response to ACK).
+Additionally, in the case of an INVITE request, the client
+transaction is responsible for generating the ACK request for any
+final response accepting a 2xx response.
+Similarly, the purpose of the server transaction is to receive
+requests from the transport layer and deliver them to the TU.  The
+server transaction filters any request retransmissions from the
+network.  The server transaction accepts responses from the TU and
+delivers them to the transport layer for transmission over the
+network.  In the case of an INVITE transaction, it absorbs the ACK
+request for any final response excepting a 2xx response.
+The 2xx response and its ACK receive special treatment.  This
+response is retransmitted only by a UAS, and its ACK generated only
+by the UAC.  This end-to-end treatment is needed so that a caller
+knows the entire set of users that have accepted the call.  Because
+of this special handling, retransmissions of the 2xx response are
+handled by the UA core, not the transaction layer.  Similarly,
+generation of the ACK for the 2xx is handled by the UA core.  Each
+proxy along the path merely forwards each 2xx response to INVITE and
+its corresponding ACK.
+17.1 Client Transaction
+The client transaction provides its functionality through the
+maintenance of a state machine.
+The TU communicates with the client transaction through a simple
+interface.  When the TU wishes to initiate a new transaction, it
+creates a client transaction and passes it the SIP request to send
+and an IP address, port, and transport to which to send it.  The
+client transaction begins execution of its state machine.  Valid
+responses are passed up to the TU from the client transaction.
+There are two types of client transaction state machines, depending
+on the method of the request passed by the TU.  One handles client
+transactions for INVITE requests.  This type of machine is referred
+to as an INVITE client transaction.  Another type handles client
+transactions for all requests except INVITE and ACK.  This is
+referred to as a non-INVITE client transaction.  There is no client
+transaction for ACK.  If the TU wishes to send an ACK, it passes one
+directly to the transport layer for transmission.
+Rosenberg, et. al.          Standards Track                   [Page 124]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The INVITE transaction is different from those of other methods
+because of its extended duration.  Normally, human input is required
+in order to respond to an INVITE.  The long delays expected for
+sending a response argue for a three-way handshake.  On the other
+hand, requests of other methods are expected to complete rapidly.
+Because of the non-INVITE transaction's reliance on a two-way
+handshake, TUs SHOULD respond immediately to non-INVITE requests.
+17.1.1 INVITE Client Transaction
+17.1.1.1 Overview of INVITE Transaction
+The INVITE transaction consists of a three-way handshake.  The client
+transaction sends an INVITE, the server transaction sends responses,
+and the client transaction sends an ACK.  For unreliable transports
+(such as UDP), the client transaction retransmits requests at an
+interval that starts at T1 seconds and doubles after every
+retransmission.  T1 is an estimate of the round-trip time (RTT), and
+it defaults to 500 ms.  Nearly all of the transaction timers
+described here scale with T1, and changing T1 adjusts their values.
+The request is not retransmitted over reliable transports.  After
+receiving a 1xx response, any retransmissions cease altogether, and
+the client waits for further responses.  The server transaction can
+send additional 1xx responses, which are not transmitted reliably by
+the server transaction.  Eventually, the server transaction decides
+to send a final response.  For unreliable transports, that response
+is retransmitted periodically, and for reliable transports, it is
+sent once.  For each final response that is received at the client
+transaction, the client transaction sends an ACK, the purpose of
+which is to quench retransmissions of the response.
+17.1.1.2 Formal Description
+The state machine for the INVITE client transaction is shown in
+Figure 5.  The initial state, "calling", MUST be entered when the TU
+initiates a new client transaction with an INVITE request.  The
+client transaction MUST pass the request to the transport layer for
+transmission (see Section 18).  If an unreliable transport is being
+used, the client transaction MUST start timer A with a value of T1.
+If a reliable transport is being used, the client transaction SHOULD
+NOT start timer A (Timer A controls request retransmissions).  For
+any transport, the client transaction MUST start timer B with a value
+of 64*T1 seconds (Timer B controls transaction timeouts).
+When timer A fires, the client transaction MUST retransmit the
+request by passing it to the transport layer, and MUST reset the
+timer with a value of 2*T1.  The formal definition of retransmit
+Rosenberg, et. al.          Standards Track                   [Page 125]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+within the context of the transaction layer is to take the message
+previously sent to the transport layer and pass it to the transport
+layer once more.
+When timer A fires 2*T1 seconds later, the request MUST be
+retransmitted again (assuming the client transaction is still in this
+state).  This process MUST continue so that the request is
+retransmitted with intervals that double after each transmission.
+These retransmissions SHOULD only be done while the client
+transaction is in the "calling" state.
+The default value for T1 is 500 ms.  T1 is an estimate of the RTT
+between the client and server transactions.  Elements MAY (though it
+is NOT RECOMMENDED) use smaller values of T1 within closed, private
+networks that do not permit general Internet connection.  T1 MAY be
+chosen larger, and this is RECOMMENDED if it is known in advance
+(such as on high latency access links) that the RTT is larger.
+Whatever the value of T1, the exponential backoffs on retransmissions
+described in this section MUST be used.
+If the client transaction is still in the "Calling" state when timer
+B fires, the client transaction SHOULD inform the TU that a timeout
+has occurred.  The client transaction MUST NOT generate an ACK.  The
+value of 64*T1 is equal to the amount of time required to send seven
+requests in the case of an unreliable transport.
+If the client transaction receives a provisional response while in
+the "Calling" state, it transitions to the "Proceeding" state. In the
+"Proceeding" state, the client transaction SHOULD NOT retransmit the
+request any longer. Furthermore, the provisional response MUST be
+passed to the TU.  Any further provisional responses MUST be passed
+up to the TU while in the "Proceeding" state.
+When in either the "Calling" or "Proceeding" states, reception of a
+response with status code from 300-699 MUST cause the client
+transaction to transition to "Completed".  The client transaction
+MUST pass the received response up to the TU, and the client
+transaction MUST generate an ACK request, even if the transport is
+reliable (guidelines for constructing the ACK from the response are
+given in Section 17.1.1.3) and then pass the ACK to the transport
+layer for transmission.  The ACK MUST be sent to the same address,
+port, and transport to which the original request was sent.  The
+client transaction SHOULD start timer D when it enters the
+"Completed" state, with a value of at least 32 seconds for unreliable
+transports, and a value of zero seconds for reliable transports.
+Timer D reflects the amount of time that the server transaction can
+remain in the "Completed" state when unreliable transports are used.
+This is equal to Timer H in the INVITE server transaction, whose
+Rosenberg, et. al.          Standards Track                   [Page 126]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+default is 64*T1.  However, the client transaction does not know the
+value of T1 in use by the server transaction, so an absolute minimum
+of 32s is used instead of basing Timer D on T1.
+Any retransmissions of the final response that are received while in
+the "Completed" state MUST cause the ACK to be re-passed to the
+transport layer for retransmission, but the newly received response
+MUST NOT be passed up to the TU.  A retransmission of the response is
+defined as any response which would match the same client transaction
+based on the rules of Section 17.1.3.
+Rosenberg, et. al.          Standards Track                   [Page 127]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+|INVITE from TU
+Timer A fires     |INVITE sent
+Reset A,          V                      Timer B fires
+INVITE sent +-----------+                or Transport Err.
++---------|           |---------------+inform TU
+|         |  Calling  |               |
++-------->|           |-------------->|
++-----------+ 2xx           |
+|  |       2xx to TU     |
+|  |1xx                  |
+300-699 +---------------+  |1xx to TU            |
+ACK sent |                  |                     |
+resp. to TU |  1xx             V                     |
+|  1xx to TU  -----------+               |
+|  +---------|           |               |
+|  |         |Proceeding |-------------->|
+|  +-------->|           | 2xx           |
+|            +-----------+ 2xx to TU     |
+|       300-699    |                     |
+|       ACK sent,  |                     |
+|       resp. to TU|                     |
+|                  |                     |      NOTE:
+|  300-699         V                     |
+|  ACK sent  +-----------+Transport Err. |  transitions
+|  +---------|           |Inform TU      |  labeled with
+|  |         | Completed |-------------->|  the event
+|  +-------->|           |               |  over the action
+|            +-----------+               |  to take
+|              ^   |                     |
+|              |   | Timer D fires       |
++--------------+   | -                   |
+|                     |
+V                     |
++-----------+               |
+|           |               |
+| Terminated|<--------------+
+|           |
++-----------+
+Figure 5: INVITE client transaction
+If timer D fires while the client transaction is in the "Completed"
+state, the client transaction MUST move to the terminated state.
+When in either the "Calling" or "Proceeding" states, reception of a
+2xx response MUST cause the client transaction to enter the
+"Terminated" state, and the response MUST be passed up to the TU.
+The handling of this response depends on whether the TU is a proxy
+Rosenberg, et. al.          Standards Track                   [Page 128]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+core or a UAC core.  A UAC core will handle generation of the ACK for
+this response, while a proxy core will always forward the 200 (OK)
+upstream.  The differing treatment of 200 (OK) between proxy and UAC
+is the reason that handling of it does not take place in the
+transaction layer.
+The client transaction MUST be destroyed the instant it enters the
+"Terminated" state.  This is actually necessary to guarantee correct
+operation.  The reason is that 2xx responses to an INVITE are treated
+differently; each one is forwarded by proxies, and the ACK handling
+in a UAC is different.  Thus, each 2xx needs to be passed to a proxy
+core (so that it can be forwarded) and to a UAC core (so it can be
+acknowledged).  No transaction layer processing takes place.
+Whenever a response is received by the transport, if the transport
+layer finds no matching client transaction (using the rules of
+Section 17.1.3), the response is passed directly to the core.  Since
+the matching client transaction is destroyed by the first 2xx,
+subsequent 2xx will find no match and therefore be passed to the
+core.
+17.1.1.3 Construction of the ACK Request
+This section specifies the construction of ACK requests sent within
+the client transaction.  A UAC core that generates an ACK for 2xx
+MUST instead follow the rules described in Section 13.
+The ACK request constructed by the client transaction MUST contain
+values for the Call-ID, From, and Request-URI that are equal to the
+values of those header fields in the request passed to the transport
+by the client transaction (call this the "original request").  The To
+header field in the ACK MUST equal the To header field in the
+response being acknowledged, and therefore will usually differ from
+the To header field in the original request by the addition of the
+tag parameter.  The ACK MUST contain a single Via header field, and
+this MUST be equal to the top Via header field of the original
+request.  The CSeq header field in the ACK MUST contain the same
+value for the sequence number as was present in the original request,
+but the method parameter MUST be equal to "ACK".
+Rosenberg, et. al.          Standards Track                   [Page 129]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+If the INVITE request whose response is being acknowledged had Route
+header fields, those header fields MUST appear in the ACK.  This is
+to ensure that the ACK can be routed properly through any downstream
+stateless proxies.
+Although any request MAY contain a body, a body in an ACK is special
+since the request cannot be rejected if the body is not understood.
+Therefore, placement of bodies in ACK for non-2xx is NOT RECOMMENDED,
+but if done, the body types are restricted to any that appeared in
+the INVITE, assuming that the response to the INVITE was not 415.  If
+it was, the body in the ACK MAY be any type listed in the Accept
+header field in the 415.
+For example, consider the following request:
+INVITE sip:bob@biloxi.com SIP/2.0
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
+To: Bob <sip:bob@biloxi.com>
+From: Alice <sip:alice@atlanta.com>;tag=88sja8x
+Max-Forwards: 70
+Call-ID: 987asjd97y7atg
+CSeq: 986759 INVITE
+The ACK request for a non-2xx final response to this request would
+look like this:
+ACK sip:bob@biloxi.com SIP/2.0
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
+To: Bob <sip:bob@biloxi.com>;tag=99sa0xk
+From: Alice <sip:alice@atlanta.com>;tag=88sja8x
+Max-Forwards: 70
+Call-ID: 987asjd97y7atg
+CSeq: 986759 ACK
+17.1.2 Non-INVITE Client Transaction
+17.1.2.1 Overview of the non-INVITE Transaction
+Non-INVITE transactions do not make use of ACK.  They are simple
+request-response interactions.  For unreliable transports, requests
+are retransmitted at an interval which starts at T1 and doubles until
+it hits T2.  If a provisional response is received, retransmissions
+continue for unreliable transports, but at an interval of T2.  The
+server transaction retransmits the last response it sent, which can
+be a provisional or final response, only when a retransmission of the
+request is received.  This is why request retransmissions need to
+continue even after a provisional response; they are to ensure
+reliable delivery of the final response.
+Rosenberg, et. al.          Standards Track                   [Page 130]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Unlike an INVITE transaction, a non-INVITE transaction has no special
+handling for the 2xx response.  The result is that only a single 2xx
+response to a non-INVITE is ever delivered to a UAC.
+17.1.2.2 Formal Description
+The state machine for the non-INVITE client transaction is shown in
+Figure 6.  It is very similar to the state machine for INVITE.
+The "Trying" state is entered when the TU initiates a new client
+transaction with a request.  When entering this state, the client
+transaction SHOULD set timer F to fire in 64*T1 seconds.  The request
+MUST be passed to the transport layer for transmission.  If an
+unreliable transport is in use, the client transaction MUST set timer
+E to fire in T1 seconds.  If timer E fires while still in this state,
+the timer is reset, but this time with a value of MIN(2*T1, T2).
+When the timer fires again, it is reset to a MIN(4*T1, T2).  This
+process continues so that retransmissions occur with an exponentially
+increasing interval that caps at T2.  The default value of T2 is 4s,
+and it represents the amount of time a non-INVITE server transaction
+will take to respond to a request, if it does not respond
+immediately.  For the default values of T1 and T2, this results in
+intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc.
+If Timer F fires while the client transaction is still in the
+"Trying" state, the client transaction SHOULD inform the TU about the
+timeout, and then it SHOULD enter the "Terminated" state.  If a
+provisional response is received while in the "Trying" state, the
+response MUST be passed to the TU, and then the client transaction
+SHOULD move to the "Proceeding" state.  If a final response (status
+codes 200-699) is received while in the "Trying" state, the response
+MUST be passed to the TU, and the client transaction MUST transition
+to the "Completed" state.
+If Timer E fires while in the "Proceeding" state, the request MUST be
+passed to the transport layer for retransmission, and Timer E MUST be
+reset with a value of T2 seconds.  If timer F fires while in the
+"Proceeding" state, the TU MUST be informed of a timeout, and the
+client transaction MUST transition to the terminated state.  If a
+final response (status codes 200-699) is received while in the
+"Proceeding" state, the response MUST be passed to the TU, and the
+client transaction MUST transition to the "Completed" state.
+Once the client transaction enters the "Completed" state, it MUST set
+Timer K to fire in T4 seconds for unreliable transports, and zero
+seconds for reliable transports.  The "Completed" state exists to
+buffer any additional response retransmissions that may be received
+(which is why the client transaction remains there only for
+Rosenberg, et. al.          Standards Track                   [Page 131]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+unreliable transports).  T4 represents the amount of time the network
+will take to clear messages between client and server transactions.
+The default value of T4 is 5s.  A response is a retransmission when
+it matches the same transaction, using the rules specified in Section
+17.1.3.  If Timer K fires while in this state, the client transaction
+MUST transition to the "Terminated" state.
+Once the transaction is in the terminated state, it MUST be destroyed
+immediately.
+17.1.3 Matching Responses to Client Transactions
+When the transport layer in the client receives a response, it has to
+determine which client transaction will handle the response, so that
+the processing of Sections 17.1.1 and 17.1.2 can take place.  The
+branch parameter in the top Via header field is used for this
+purpose.  A response matches a client transaction under two
+conditions:
+1.  If the response has the same value of the branch parameter in
+the top Via header field as the branch parameter in the top
+Via header field of the request that created the transaction.
+2.  If the method parameter in the CSeq header field matches the
+method of the request that created the transaction.  The
+method is needed since a CANCEL request constitutes a
+different transaction, but shares the same value of the branch
+parameter.
+If a request is sent via multicast, it is possible that it will
+generate multiple responses from different servers.  These responses
+will all have the same branch parameter in the topmost Via, but vary
+in the To tag.  The first response received, based on the rules
+above, will be used, and others will be viewed as retransmissions.
+That is not an error; multicast SIP provides only a rudimentary
+"single-hop-discovery-like" service that is limited to processing a
+single response.  See Section 18.1.1 for details.
+Rosenberg, et. al.          Standards Track                   [Page 132]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+17.1.4 Handling Transport Errors
+|Request from TU
+|send request
+Timer E             V
+send request  +-----------+
++---------|           |-------------------+
+|         |  Trying   |  Timer F          |
++-------->|           |  or Transport Err.|
++-----------+  inform TU        |
+200-699         |  |                         |
+resp. to TU     |  |1xx                      |
++---------------+  |resp. to TU              |
+|                  |                         |
+|   Timer E        V       Timer F           |
+|   send req +-----------+ or Transport Err. |
+|  +---------|           | inform TU         |
+|  |         |Proceeding |------------------>|
+|  +-------->|           |-----+             |
+|            +-----------+     |1xx          |
+|              |      ^        |resp to TU   |
+| 200-699      |      +--------+             |
+| resp. to TU  |                             |
+|              |                             |
+|              V                             |
+|            +-----------+                   |
+|            |           |                   |
+|            | Completed |                   |
+|            |           |                   |
+|            +-----------+                   |
+|              ^   |                         |
+|              |   | Timer K                 |
++--------------+   | -                       |
+|                         |
+V                         |
+NOTE:           +-----------+                   |
+|           |                   |
+transitions         | Terminated|<------------------+
+labeled with        |           |
+the event           +-----------+
+over the action
+to take
+Figure 6: non-INVITE client transaction
+When the client transaction sends a request to the transport layer to
+be sent, the following procedures are followed if the transport layer
+indicates a failure.
+Rosenberg, et. al.          Standards Track                   [Page 133]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The client transaction SHOULD inform the TU that a transport failure
+has occurred, and the client transaction SHOULD transition directly
+to the "Terminated" state.  The TU will handle the failover
+mechanisms described in [4].
+17.2 Server Transaction
+The server transaction is responsible for the delivery of requests to
+the TU and the reliable transmission of responses.  It accomplishes
+this through a state machine.  Server transactions are created by the
+core when a request is received, and transaction handling is desired
+for that request (this is not always the case).
+As with the client transactions, the state machine depends on whether
+the received request is an INVITE request.
+17.2.1 INVITE Server Transaction
+The state diagram for the INVITE server transaction is shown in
+Figure 7.
+When a server transaction is constructed for a request, it enters the
+"Proceeding" state.  The server transaction MUST generate a 100
+(Trying) response unless it knows that the TU will generate a
+provisional or final response within 200 ms, in which case it MAY
+generate a 100 (Trying) response.  This provisional response is
+needed to quench request retransmissions rapidly in order to avoid
+network congestion.  The 100 (Trying) response is constructed
+according to the procedures in Section 8.2.6, except that the
+insertion of tags in the To header field of the response (when none
+was present in the request) is downgraded from MAY to SHOULD NOT.
+The request MUST be passed to the TU.
+The TU passes any number of provisional responses to the server
+transaction.  So long as the server transaction is in the
+"Proceeding" state, each of these MUST be passed to the transport
+layer for transmission.  They are not sent reliably by the
+transaction layer (they are not retransmitted by it) and do not cause
+a change in the state of the server transaction.  If a request
+retransmission is received while in the "Proceeding" state, the most
+recent provisional response that was received from the TU MUST be
+passed to the transport layer for retransmission.  A request is a
+retransmission if it matches the same server transaction based on the
+rules of Section 17.2.3.
+If, while in the "Proceeding" state, the TU passes a 2xx response to
+the server transaction, the server transaction MUST pass this
+response to the transport layer for transmission.  It is not
+Rosenberg, et. al.          Standards Track                   [Page 134]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+retransmitted by the server transaction; retransmissions of 2xx
+responses are handled by the TU.  The server transaction MUST then
+transition to the "Terminated" state.
+While in the "Proceeding" state, if the TU passes a response with
+status code from 300 to 699 to the server transaction, the response
+MUST be passed to the transport layer for transmission, and the state
+machine MUST enter the "Completed" state.  For unreliable transports,
+timer G is set to fire in T1 seconds, and is not set to fire for
+reliable transports.
+This is a change from RFC 2543, where responses were always
+retransmitted, even over reliable transports.
+When the "Completed" state is entered, timer H MUST be set to fire in
+64*T1 seconds for all transports.  Timer H determines when the server
+transaction abandons retransmitting the response.  Its value is
+chosen to equal Timer B, the amount of time a client transaction will
+continue to retry sending a request.  If timer G fires, the response
+is passed to the transport layer once more for retransmission, and
+timer G is set to fire in MIN(2*T1, T2) seconds.  From then on, when
+timer G fires, the response is passed to the transport again for
+transmission, and timer G is reset with a value that doubles, unless
+that value exceeds T2, in which case it is reset with the value of
+T2.  This is identical to the retransmit behavior for requests in the
+"Trying" state of the non-INVITE client transaction.  Furthermore,
+while in the "Completed" state, if a request retransmission is
+received, the server SHOULD pass the response to the transport for
+retransmission.
+If an ACK is received while the server transaction is in the
+"Completed" state, the server transaction MUST transition to the
+"Confirmed" state.  As Timer G is ignored in this state, any
+retransmissions of the response will cease.
+If timer H fires while in the "Completed" state, it implies that the
+ACK was never received.  In this case, the server transaction MUST
+transition to the "Terminated" state, and MUST indicate to the TU
+that a transaction failure has occurred.
+Rosenberg, et. al.          Standards Track                   [Page 135]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+|INVITE
+|pass INV to TU
+INVITE             V send 100 if TU won't in 200ms
+send response+-----------+
++--------|           |--------+101-199 from TU
+|        | Proceeding|        |send response
++------->|           |<-------+
+|           |          Transport Err.
+|           |          Inform TU
+|           |--------------->+
++-----------+                |
+300-699 from TU |     |2xx from TU        |
+send response   |     |send response      |
+|     +------------------>+
+|                         |
+INVITE          V          Timer G fires  |
+send response+-----------+ send response  |
++--------|           |--------+       |
+|        | Completed |        |       |
++------->|           |<-------+       |
++-----------+                |
+|     |                   |
+ACK |     |                   |
+-   |     +------------------>+
+|        Timer H fires    |
+V        or Transport Err.|
++-----------+  Inform TU     |
+|           |                |
+| Confirmed |                |
+|           |                |
++-----------+                |
+|                      |
+|Timer I fires         |
+|-                     |
+|                      |
+V                      |
++-----------+                |
+|           |                |
+| Terminated|<---------------+
+|           |
++-----------+
+Figure 7: INVITE server transaction
+Rosenberg, et. al.          Standards Track                   [Page 136]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The purpose of the "Confirmed" state is to absorb any additional ACK
+messages that arrive, triggered from retransmissions of the final
+response.  When this state is entered, timer I is set to fire in T4
+seconds for unreliable transports, and zero seconds for reliable
+transports.  Once timer I fires, the server MUST transition to the
+"Terminated" state.
+Once the transaction is in the "Terminated" state, it MUST be
+destroyed immediately.  As with client transactions, this is needed
+to ensure reliability of the 2xx responses to INVITE.
+17.2.2 Non-INVITE Server Transaction
+The state machine for the non-INVITE server transaction is shown in
+Figure 8.
+The state machine is initialized in the "Trying" state and is passed
+a request other than INVITE or ACK when initialized.  This request is
+passed up to the TU.  Once in the "Trying" state, any further request
+retransmissions are discarded.  A request is a retransmission if it
+matches the same server transaction, using the rules specified in
+Section 17.2.3.
+While in the "Trying" state, if the TU passes a provisional response
+to the server transaction, the server transaction MUST enter the
+"Proceeding" state.  The response MUST be passed to the transport
+layer for transmission.  Any further provisional responses that are
+received from the TU while in the "Proceeding" state MUST be passed
+to the transport layer for transmission.  If a retransmission of the
+request is received while in the "Proceeding" state, the most
+recently sent provisional response MUST be passed to the transport
+layer for retransmission.  If the TU passes a final response (status
+codes 200-699) to the server while in the "Proceeding" state, the
+transaction MUST enter the "Completed" state, and the response MUST
+be passed to the transport layer for transmission.
+When the server transaction enters the "Completed" state, it MUST set
+Timer J to fire in 64*T1 seconds for unreliable transports, and zero
+seconds for reliable transports.  While in the "Completed" state, the
+server transaction MUST pass the final response to the transport
+layer for retransmission whenever a retransmission of the request is
+received.  Any other final responses passed by the TU to the server
+transaction MUST be discarded while in the "Completed" state.  The
+server transaction remains in this state until Timer J fires, at
+which point it MUST transition to the "Terminated" state.
+The server transaction MUST be destroyed the instant it enters the
+"Terminated" state.
+Rosenberg, et. al.          Standards Track                   [Page 137]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+17.2.3 Matching Requests to Server Transactions
+When a request is received from the network by the server, it has to
+be matched to an existing transaction.  This is accomplished in the
+following manner.
+The branch parameter in the topmost Via header field of the request
+is examined.  If it is present and begins with the magic cookie
+"z9hG4bK", the request was generated by a client transaction
+compliant to this specification.  Therefore, the branch parameter
+will be unique across all transactions sent by that client.  The
+request matches a transaction if:
+1. the branch parameter in the request is equal to the one in the
+top Via header field of the request that created the
+transaction, and
+2. the sent-by value in the top Via of the request is equal to the
+one in the request that created the transaction, and
+3. the method of the request matches the one that created the
+transaction, except for ACK, where the method of the request
+that created the transaction is INVITE.
+This matching rule applies to both INVITE and non-INVITE transactions
+alike.
+The sent-by value is used as part of the matching process because
+there could be accidental or malicious duplication of branch
+parameters from different clients.
+If the branch parameter in the top Via header field is not present,
+or does not contain the magic cookie, the following procedures are
+used.  These exist to handle backwards compatibility with RFC 2543
+compliant implementations.
+The INVITE request matches a transaction if the Request-URI, To tag,
+From tag, Call-ID, CSeq, and top Via header field match those of the
+INVITE request which created the transaction.  In this case, the
+INVITE is a retransmission of the original one that created the
+transaction.  The ACK request matches a transaction if the Request-
+URI, From tag, Call-ID, CSeq number (not the method), and top Via
+header field match those of the INVITE request which created the
+transaction, and the To tag of the ACK matches the To tag of the
+response sent by the server transaction.  Matching is done based on
+the matching rules defined for each of those header fields.
+Inclusion of the tag in the To header field in the ACK matching
+process helps disambiguate ACK for 2xx from ACK for other responses
+Rosenberg, et. al.          Standards Track                   [Page 138]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+at a proxy, which may have forwarded both responses (This can occur
+in unusual conditions.  Specifically, when a proxy forked a request,
+and then crashes, the responses may be delivered to another proxy,
+which might end up forwarding multiple responses upstream).  An ACK
+request that matches an INVITE transaction matched by a previous ACK
+is considered a retransmission of that previous ACK.
+Rosenberg, et. al.          Standards Track                   [Page 139]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+|Request received
+|pass to TU
+V
++-----------+
+|           |
+| Trying    |-------------+
+|           |             |
++-----------+             |200-699 from TU
+|                   |send response
+|1xx from TU        |
+|send response      |
+|                   |
+Request            V      1xx from TU  |
+send response+-----------+send response|
++--------|           |--------+    |
+|        | Proceeding|        |    |
++------->|           |<-------+    |
++<--------------|           |             |
+|Trnsprt Err    +-----------+             |
+|Inform TU            |                   |
+|                     |                   |
+|                     |200-699 from TU    |
+|                     |send response      |
+|  Request            V                   |
+|  send response+-----------+             |
+|      +--------|           |             |
+|      |        | Completed |<------------+
+|      +------->|           |
++<--------------|           |
+|Trnsprt Err    +-----------+
+|Inform TU            |
+|                     |Timer J fires
+|                     |-
+|                     |
+|                     V
+|               +-----------+
+|               |           |
++-------------->| Terminated|
+|           |
++-----------+
+Figure 8: non-INVITE server transaction
+For all other request methods, a request is matched to a transaction
+if the Request-URI, To tag, From tag, Call-ID, CSeq (including the
+method), and top Via header field match those of the request that
+created the transaction.  Matching is done based on the matching
+Rosenberg, et. al.          Standards Track                   [Page 140]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+rules defined for each of those header fields.  When a non-INVITE
+request matches an existing transaction, it is a retransmission of
+the request that created that transaction.
+Because the matching rules include the Request-URI, the server cannot
+match a response to a transaction.  When the TU passes a response to
+the server transaction, it must pass it to the specific server
+transaction for which the response is targeted.
+17.2.4 Handling Transport Errors
+When the server transaction sends a response to the transport layer
+to be sent, the following procedures are followed if the transport
+layer indicates a failure.
+First, the procedures in [4] are followed, which attempt to deliver
+the response to a backup.  If those should all fail, based on the
+definition of failure in [4], the server transaction SHOULD inform
+the TU that a failure has occurred, and SHOULD transition to the
+terminated state.
+18 Transport
+The transport layer is responsible for the actual transmission of
+requests and responses over network transports.  This includes
+determination of the connection to use for a request or response in
+the case of connection-oriented transports.
+The transport layer is responsible for managing persistent
+connections for transport protocols like TCP and SCTP, or TLS over
+those, including ones opened to the transport layer.  This includes
+connections opened by the client or server transports, so that
+connections are shared between client and server transport functions.
+These connections are indexed by the tuple formed from the address,
+port, and transport protocol at the far end of the connection.  When
+a connection is opened by the transport layer, this index is set to
+the destination IP, port and transport.  When the connection is
+accepted by the transport layer, this index is set to the source IP
+address, port number, and transport.  Note that, because the source
+port is often ephemeral, but it cannot be known whether it is
+ephemeral or selected through procedures in [4], connections accepted
+by the transport layer will frequently not be reused.  The result is
+that two proxies in a "peering" relationship using a connection-
+oriented transport frequently will have two connections in use, one
+for transactions initiated in each direction.
+Rosenberg, et. al.          Standards Track                   [Page 141]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+It is RECOMMENDED that connections be kept open for some
+implementation-defined duration after the last message was sent or
+received over that connection.  This duration SHOULD at least equal
+the longest amount of time the element would need in order to bring a
+transaction from instantiation to the terminated state.  This is to
+make it likely that transactions are completed over the same
+connection on which they are initiated (for example, request,
+response, and in the case of INVITE, ACK for non-2xx responses).
+This usually means at least 64*T1 (see Section 17.1.1.1 for a
+definition of T1).  However, it could be larger in an element that
+has a TU using a large value for timer C (bullet 11 of Section 16.6),
+for example.
+All SIP elements MUST implement UDP and TCP.  SIP elements MAY
+implement other protocols.
+Making TCP mandatory for the UA is a substantial change from RFC
+2543.  It has arisen out of the need to handle larger messages,
+which MUST use TCP, as discussed below.  Thus, even if an element
+never sends large messages, it may receive one and needs to be
+able to handle them.
+18.1 Clients
+18.1.1 Sending Requests
+The client side of the transport layer is responsible for sending the
+request and receiving responses.  The user of the transport layer
+passes the client transport the request, an IP address, port,
+transport, and possibly TTL for multicast destinations.
+If a request is within 200 bytes of the path MTU, or if it is larger
+than 1300 bytes and the path MTU is unknown, the request MUST be sent
+using an RFC 2914 [43] congestion controlled transport protocol, such
+as TCP. If this causes a change in the transport protocol from the
+one indicated in the top Via, the value in the top Via MUST be
+changed.  This prevents fragmentation of messages over UDP and
+provides congestion control for larger messages.  However,
+implementations MUST be able to handle messages up to the maximum
+datagram packet size.  For UDP, this size is 65,535 bytes, including
+IP and UDP headers.
+The 200 byte "buffer" between the message size and the MTU
+accommodates the fact that the response in SIP can be larger than
+the request.  This happens due to the addition of Record-Route
+header field values to the responses to INVITE, for example.  With
+the extra buffer, the response can be about 170 bytes larger than
+the request, and still not be fragmented on IPv4 (about 30 bytes
+Rosenberg, et. al.          Standards Track                   [Page 142]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+is consumed by IP/UDP, assuming no IPSec).  1300 is chosen when
+path MTU is not known, based on the assumption of a 1500 byte
+Ethernet MTU.
+If an element sends a request over TCP because of these message size
+constraints, and that request would have otherwise been sent over
+UDP, if the attempt to establish the connection generates either an
+ICMP Protocol Not Supported, or results in a TCP reset, the element
+SHOULD retry the request, using UDP.  This is only to provide
+backwards compatibility with RFC 2543 compliant implementations that
+do not support TCP.  It is anticipated that this behavior will be
+deprecated in a future revision of this specification.
+A client that sends a request to a multicast address MUST add the
+"maddr" parameter to its Via header field value containing the
+destination multicast address, and for IPv4, SHOULD add the "ttl"
+parameter with a value of 1.  Usage of IPv6 multicast is not defined
+in this specification, and will be a subject of future
+standardization when the need arises.
+These rules result in a purposeful limitation of multicast in SIP.
+Its primary function is to provide a "single-hop-discovery-like"
+service, delivering a request to a group of homogeneous servers,
+where it is only required to process the response from any one of
+them.  This functionality is most useful for registrations.  In fact,
+based on the transaction processing rules in Section 17.1.3, the
+client transaction will accept the first response, and view any
+others as retransmissions because they all contain the same Via
+branch identifier.
+Before a request is sent, the client transport MUST insert a value of
+the "sent-by" field into the Via header field.  This field contains
+an IP address or host name, and port.  The usage of an FQDN is
+RECOMMENDED.  This field is used for sending responses under certain
+conditions, described below.  If the port is absent, the default
+value depends on the transport.  It is 5060 for UDP, TCP and SCTP,
+5061 for TLS.
+For reliable transports, the response is normally sent on the
+connection on which the request was received.  Therefore, the client
+transport MUST be prepared to receive the response on the same
+connection used to send the request.  Under error conditions, the
+server may attempt to open a new connection to send the response.  To
+handle this case, the transport layer MUST also be prepared to
+receive an incoming connection on the source IP address from which
+the request was sent and port number in the "sent-by" field.  It also
+Rosenberg, et. al.          Standards Track                   [Page 143]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+MUST be prepared to receive incoming connections on any address and
+port that would be selected by a server based on the procedures
+described in Section 5 of [4].
+For unreliable unicast transports, the client transport MUST be
+prepared to receive responses on the source IP address from which the
+request is sent (as responses are sent back to the source address)
+and the port number in the "sent-by" field.  Furthermore, as with
+reliable transports, in certain cases the response will be sent
+elsewhere.  The client MUST be prepared to receive responses on any
+address and port that would be selected by a server based on the
+procedures described in Section 5 of [4].
+For multicast, the client transport MUST be prepared to receive
+responses on the same multicast group and port to which the request
+is sent (that is, it needs to be a member of the multicast group it
+sent the request to.)
+If a request is destined to an IP address, port, and transport to
+which an existing connection is open, it is RECOMMENDED that this
+connection be used to send the request, but another connection MAY be
+opened and used.
+If a request is sent using multicast, it is sent to the group
+address, port, and TTL provided by the transport user.  If a request
+is sent using unicast unreliable transports, it is sent to the IP
+address and port provided by the transport user.
+18.1.2 Receiving Responses
+When a response is received, the client transport examines the top
+Via header field value.  If the value of the "sent-by" parameter in
+that header field value does not correspond to a value that the
+client transport is configured to insert into requests, the response
+MUST be silently discarded.
+If there are any client transactions in existence, the client
+transport uses the matching procedures of Section 17.1.3 to attempt
+to match the response to an existing transaction.  If there is a
+match, the response MUST be passed to that transaction.  Otherwise,
+the response MUST be passed to the core (whether it be stateless
+proxy, stateful proxy, or UA) for further processing.  Handling of
+these "stray" responses is dependent on the core (a proxy will
+forward them, while a UA will discard, for example).
+Rosenberg, et. al.          Standards Track                   [Page 144]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+18.2 Servers
+18.2.1 Receiving Requests
+A server SHOULD be prepared to receive requests on any IP address,
+port and transport combination that can be the result of a DNS lookup
+on a SIP or SIPS URI [4] that is handed out for the purposes of
+communicating with that server.  In this context, "handing out"
+includes placing a URI in a Contact header field in a REGISTER
+request or a redirect response, or in a Record-Route header field in
+a request or response.  A URI can also be "handed out" by placing it
+on a web page or business card.  It is also RECOMMENDED that a server
+listen for requests on the default SIP ports (5060 for TCP and UDP,
+5061 for TLS over TCP) on all public interfaces.  The typical
+exception would be private networks, or when multiple server
+instances are running on the same host.  For any port and interface
+that a server listens on for UDP, it MUST listen on that same port
+and interface for TCP.  This is because a message may need to be sent
+using TCP, rather than UDP, if it is too large.  As a result, the
+converse is not true.  A server need not listen for UDP on a
+particular address and port just because it is listening on that same
+address and port for TCP.  There may, of course, be other reasons why
+a server needs to listen for UDP on a particular address and port.
+When the server transport receives a request over any transport, it
+MUST examine the value of the "sent-by" parameter in the top Via
+header field value.  If the host portion of the "sent-by" parameter
+contains a domain name, or if it contains an IP address that differs
+from the packet source address, the server MUST add a "received"
+parameter to that Via header field value.  This parameter MUST
+contain the source address from which the packet was received.  This
+is to assist the server transport layer in sending the response,
+since it must be sent to the source IP address from which the request
+came.
+Consider a request received by the server transport which looks like,
+in part:
+INVITE sip:bob@Biloxi.com SIP/2.0
+Via: SIP/2.0/UDP bobspc.biloxi.com:5060
+The request is received with a source IP address of 192.0.2.4.
+Before passing the request up, the transport adds a "received"
+parameter, so that the request would look like, in part:
+INVITE sip:bob@Biloxi.com SIP/2.0
+Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4
+Rosenberg, et. al.          Standards Track                   [Page 145]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Next, the server transport attempts to match the request to a server
+transaction.  It does so using the matching rules described in
+Section 17.2.3.  If a matching server transaction is found, the
+request is passed to that transaction for processing.  If no match is
+found, the request is passed to the core, which may decide to
+construct a new server transaction for that request.  Note that when
+a UAS core sends a 2xx response to INVITE, the server transaction is
+destroyed.  This means that when the ACK arrives, there will be no
+matching server transaction, and based on this rule, the ACK is
+passed to the UAS core, where it is processed.
+18.2.2 Sending Responses
+The server transport uses the value of the top Via header field in
+order to determine where to send a response.  It MUST follow the
+following process:
+o  If the "sent-protocol" is a reliable transport protocol such as
+TCP or SCTP, or TLS over those, the response MUST be sent using
+the existing connection to the source of the original request
+that created the transaction, if that connection is still open.
+This requires the server transport to maintain an association
+between server transactions and transport connections.  If that
+connection is no longer open, the server SHOULD open a
+connection to the IP address in the "received" parameter, if
+present, using the port in the "sent-by" value, or the default
+port for that transport, if no port is specified.  If that
+connection attempt fails, the server SHOULD use the procedures
+in [4] for servers in order to determine the IP address and
+port to open the connection and send the response to.
+o  Otherwise, if the Via header field value contains a "maddr"
+parameter, the response MUST be forwarded to the address listed
+there, using the port indicated in "sent-by", or port 5060 if
+none is present.  If the address is a multicast address, the
+response SHOULD be sent using the TTL indicated in the "ttl"
+parameter, or with a TTL of 1 if that parameter is not present.
+o  Otherwise (for unreliable unicast transports), if the top Via
+has a "received" parameter, the response MUST be sent to the
+address in the "received" parameter, using the port indicated
+in the "sent-by" value, or using port 5060 if none is specified
+explicitly.  If this fails, for example, elicits an ICMP "port
+unreachable" response, the procedures of Section 5 of [4]
+SHOULD be used to determine where to send the response.
+Rosenberg, et. al.          Standards Track                   [Page 146]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+o  Otherwise, if it is not receiver-tagged, the response MUST be
+sent to the address indicated by the "sent-by" value, using the
+procedures in Section 5 of [4].
+18.3 Framing
+In the case of message-oriented transports (such as UDP), if the
+message has a Content-Length header field, the message body is
+assumed to contain that many bytes.  If there are additional bytes in
+the transport packet beyond the end of the body, they MUST be
+discarded.  If the transport packet ends before the end of the
+message body, this is considered an error.  If the message is a
+response, it MUST be discarded.  If the message is a request, the
+element SHOULD generate a 400 (Bad Request) response.  If the message
+has no Content-Length header field, the message body is assumed to
+end at the end of the transport packet.
+In the case of stream-oriented transports such as TCP, the Content-
+Length header field indicates the size of the body.  The Content-
+Length header field MUST be used with stream oriented transports.
+18.4 Error Handling
+Error handling is independent of whether the message was a request or
+response.
+If the transport user asks for a message to be sent over an
+unreliable transport, and the result is an ICMP error, the behavior
+depends on the type of ICMP error.  Host, network, port or protocol
+unreachable errors, or parameter problem errors SHOULD cause the
+transport layer to inform the transport user of a failure in sending.
+Source quench and TTL exceeded ICMP errors SHOULD be ignored.
+If the transport user asks for a request to be sent over a reliable
+transport, and the result is a connection failure, the transport
+layer SHOULD inform the transport user of a failure in sending.
+19 Common Message Components
+There are certain components of SIP messages that appear in various
+places within SIP messages (and sometimes, outside of them) that
+merit separate discussion.
+Rosenberg, et. al.          Standards Track                   [Page 147]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+19.1 SIP and SIPS Uniform Resource Indicators
+A SIP or SIPS URI identifies a communications resource.  Like all
+URIs, SIP and SIPS URIs may be placed in web pages, email messages,
+or printed literature.  They contain sufficient information to
+initiate and maintain a communication session with the resource.
+Examples of communications resources include the following:
+o  a user of an online service
+o  an appearance on a multi-line phone
+o  a mailbox on a messaging system
+o  a PSTN number at a gateway service
+o  a group (such as "sales" or "helpdesk") in an organization
+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.1 SIP and SIPS URI Components
+The "sip:" and "sips:" schemes follow the guidelines in RFC 2396 [5].
+They use a form similar to the mailto URL, allowing the specification
+of SIP request-header fields and the SIP message-body.  This makes it
+possible to specify the subject, media type, or urgency of sessions
+initiated by using a URI on a web page or in an email message.  The
+formal syntax for a SIP or SIPS URI is presented in Section 25.  Its
+general form, in the case of a SIP URI, is:
+sip:user:password@host:port;uri-parameters?headers
+The format for a SIPS URI is the same, except that the scheme is
+"sips" instead of sip.  These tokens, and some of the tokens in their
+expansions, have the following meanings:
+user: The identifier of a particular resource at the host being
+addressed.  The term "host" in this context frequently refers
+to a domain.  The "userinfo" of a URI consists of this user
+field, the password field, and the @ sign following them.  The
+userinfo part of a URI is optional and MAY be absent when the
+Rosenberg, et. al.          Standards Track                   [Page 148]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+destination host does not have a notion of users or when the
+host itself is the resource being identified.  If the @ sign is
+present in a SIP or SIPS URI, the user field MUST NOT be empty.
+If the host being addressed can process telephone numbers, for
+instance, an Internet telephony gateway, a telephone-
+subscriber field defined in RFC 2806 [9] MAY be used to
+populate the user field.  There are special escaping rules for
+encoding telephone-subscriber fields in SIP and SIPS URIs
+described in Section 19.1.2.
+password: A password associated with the user.  While the SIP and
+SIPS URI syntax allows this field to be present, its use is NOT
+RECOMMENDED, because the passing of authentication information
+in clear text (such as URIs) has proven to be a security risk
+in almost every case where it has been used.  For instance,
+transporting a PIN number in this field exposes the PIN.
+Note that the password field is just an extension of the user
+portion.  Implementations not wishing to give special
+significance to the password portion of the field MAY simply
+treat "user:password" as a single string.
+host: The host providing the SIP resource.  The host part contains
+either a fully-qualified domain name or numeric IPv4 or IPv6
+address.  Using the fully-qualified domain name form is
+RECOMMENDED whenever possible.
+port: The port number where the request is to be sent.
+URI parameters: Parameters affecting a request constructed from
+the URI.
+URI parameters are added after the hostport component and are
+separated by semi-colons.
+URI parameters take the form:
+parameter-name "=" parameter-value
+Even though an arbitrary number of URI parameters may be
+included in a URI, any given parameter-name MUST NOT appear
+more than once.
+This extensible mechanism includes the transport, maddr, ttl,
+user, method and lr parameters.
+Rosenberg, et. al.          Standards Track                   [Page 149]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The transport parameter determines the transport mechanism to
+be used for sending SIP messages, as specified in [4].  SIP can
+use any network transport protocol.  Parameter names are
+defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP
+(RFC 2960 [16]).  For a SIPS URI, the transport parameter MUST
+indicate a reliable transport.
+The maddr parameter indicates the server address to be
+contacted for this user, overriding any address derived from
+the host field.  When an maddr parameter is present, the port
+and transport components of the URI apply to the address
+indicated in the maddr parameter value.  [4] describes the
+proper interpretation of the transport, maddr, and hostport in
+order to obtain the destination address, port, and transport
+for sending a request.
+The maddr field has been used as a simple form of loose source
+routing.  It allows a URI to specify a proxy that must be
+traversed en-route to the destination.  Continuing to use the
+maddr parameter this way is strongly discouraged (the
+mechanisms that enable it are deprecated).  Implementations
+should instead use the Route mechanism described in this
+document, establishing a pre-existing route set if necessary
+(see Section 8.1.1.1).  This provides a full URI to describe
+the node to be traversed.
+The ttl parameter determines the time-to-live value of the UDP
+multicast packet and MUST only be used if maddr is a multicast
+address and the transport protocol is UDP.  For example, to
+specify a call to alice@atlanta.com using multicast to
+239.255.255.1 with a ttl of 15, the following URI would be
+used:
+sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15
+The set of valid telephone-subscriber strings is a subset of
+valid user strings.  The user URI parameter exists to
+distinguish telephone numbers from user names that happen to
+look like telephone numbers.  If the user string contains a
+telephone number formatted as a telephone-subscriber, the user
+parameter value "phone" SHOULD be present.  Even without this
+parameter, recipients of SIP and SIPS URIs MAY interpret the
+pre-@ part as a telephone number if local restrictions on the
+name space for user name allow it.
+The method of the SIP request constructed from the URI can be
+specified with the method parameter.
+Rosenberg, et. al.          Standards Track                   [Page 150]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The lr parameter, when present, indicates that the element
+responsible for this resource implements the routing mechanisms
+specified in this document.  This parameter will be used in the
+URIs proxies place into Record-Route header field values, and
+may appear in the URIs in a pre-existing route set.
+This parameter is used to achieve backwards compatibility with
+systems implementing the strict-routing mechanisms of RFC 2543
+and the rfc2543bis drafts up to bis-05.  An element preparing
+to send a request based on a URI not containing this parameter
+can assume the receiving element implements strict-routing and
+reformat the message to preserve the information in the
+Request-URI.
+Since the uri-parameter mechanism is extensible, SIP elements
+MUST silently ignore any uri-parameters that they do not
+understand.
+Headers: Header fields to be included in a request constructed
+from the URI.
+Headers fields in the SIP request can be specified with the "?"
+mechanism within a URI.  The header names and values are
+encoded in ampersand separated hname = hvalue pairs.  The
+special hname "body" indicates that the associated hvalue is
+the message-body of the SIP request.
+Table 1 summarizes the use of SIP and SIPS URI components based on
+the context in which the URI appears.  The external column describes
+URIs appearing anywhere outside of a SIP message, for instance on a
+web page or business card.  Entries marked "m" are mandatory, those
+marked "o" are optional, and those marked "-" are not allowed.
+Elements processing URIs SHOULD ignore any disallowed components if
+they are present.  The second column indicates the default value of
+an optional element if it is not present.  "--" indicates that the
+element is either not optional, or has no default value.
+URIs in Contact header fields have different restrictions depending
+on the context in which the header field appears.  One set applies to
+messages that establish and maintain dialogs (INVITE and its 200 (OK)
+response).  The other applies to registration and redirection
+messages (REGISTER, its 200 (OK) response, and 3xx class responses to
+any method).
+Rosenberg, et. al.          Standards Track                   [Page 151]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+19.1.2 Character Escaping Requirements
+dialog
+reg./redir. Contact/
+default  Req.-URI  To  From  Contact   R-R/Route  external
+user          --          o      o    o       o          o         o
+password      --          o      o    o       o          o         o
+host          --          m      m    m       m          m         m
+port          (1)         o      -    -       o          o         o
+user-param    ip          o      o    o       o          o         o
+method        INVITE      -      -    -       -          -         o
+maddr-param   --          o      -    -       o          o         o
+ttl-param     1           o      -    -       o          -         o
+transp.-param (2)         o      -    -       o          o         o
+lr-param      --          o      -    -       -          o         o
+other-param   --          o      o    o       o          o         o
+headers       --          -      -    -       o          -         o
+(1): The default port value is transport and scheme dependent.  The
+default  is  5060  for  sip: using UDP, TCP, or SCTP.  The default is
+5061 for sip: using TLS over TCP and sips: over TCP.
+(2): The default transport is scheme dependent.  For sip:, it is UDP.
+For sips:, it is TCP.
+Table 1: Use and default values of URI components for SIP header
+field values, Request-URI and references
+SIP follows the requirements and guidelines of RFC 2396 [5] when
+defining the set of characters that must be escaped in a SIP URI, and
+uses its ""%" HEX HEX" mechanism for escaping.  From RFC 2396 [5]:
+The set of characters actually reserved within any given URI
+component is defined by that component.  In general, a character
+is reserved if the semantics of the URI changes if the character
+is replaced with its escaped US-ASCII encoding [5].  Excluded US-
+ASCII characters (RFC 2396 [5]), such as space and control
+characters and characters used as URI delimiters, also MUST be
+escaped.  URIs MUST NOT contain unescaped space and control
+characters.
+For each component, the set of valid BNF expansions defines exactly
+which characters may appear unescaped.  All other characters MUST be
+escaped.
+For example, "@" is not in the set of characters in the user
+component, so the user "j@s0n" must have at least the @ sign encoded,
+as in "j%40s0n".
+Rosenberg, et. al.          Standards Track                   [Page 152]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Expanding the hname and hvalue tokens in Section 25 show that all URI
+reserved characters in header field names and values MUST be escaped.
+The telephone-subscriber subset of the user component has special
+escaping considerations.  The set of characters not reserved in the
+RFC 2806 [9] description of telephone-subscriber contains a number of
+characters in various syntax elements that need to be escaped when
+used in SIP URIs.  Any characters occurring in a telephone-subscriber
+that do not appear in an expansion of the BNF for the user rule MUST
+be escaped.
+Note that character escaping is not allowed in the host component of
+a SIP or SIPS URI (the % character is not valid in its expansion).
+This is likely to change in the future as requirements for
+Internationalized Domain Names are finalized.  Current
+implementations MUST NOT attempt to improve robustness by treating
+received escaped characters in the host component as literally
+equivalent to their unescaped counterpart.  The behavior required to
+meet the requirements of IDN may be significantly different.
+19.1.3 Example SIP and SIPS URIs
+sip:alice@atlanta.com
+sip:alice:secretword@atlanta.com;transport=tcp
+sips:alice@atlanta.com?subject=project%20x&priority=urgent
+sip:+1-212-555-1212:1234@gateway.com;user=phone
+sips:1212@gateway.com
+sip:alice@192.0.2.4
+sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
+sip:alice;day=tuesday@atlanta.com
+The last sample URI above has a user field value of
+"alice;day=tuesday".  The escaping rules defined above allow a
+semicolon to appear unescaped in this field.  For the purposes of
+this protocol, the field is opaque.  The structure of that value is
+only useful to the SIP element responsible for the resource.
+19.1.4 URI Comparison
+Some operations in this specification require determining whether two
+SIP or SIPS URIs are equivalent.  In this specification, registrars
+need to compare bindings in Contact URIs in REGISTER requests (see
+Section 10.3.).  SIP and SIPS URIs are compared for equality
+according to the following rules:
+o  A SIP and SIPS URI are never equivalent.
+Rosenberg, et. al.          Standards Track                   [Page 153]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+o  Comparison of the userinfo of SIP and SIPS URIs is case-
+sensitive.  This includes userinfo containing passwords or
+formatted as telephone-subscribers.  Comparison of all other
+components of the URI is case-insensitive unless explicitly
+defined otherwise.
+o  The ordering of parameters and header fields is not significant
+in comparing SIP and SIPS URIs.
+o  Characters other than those in the "reserved" set (see RFC 2396
+[5]) are equivalent to their ""%" HEX HEX" encoding.
+o  An IP address that is the result of a DNS lookup of a host name
+does not match that host name.
+o  For two URIs to be equal, the user, password, host, and port
+components must match.
+A URI omitting the user component will not match a URI that
+includes one.  A URI omitting the password component will not
+match a URI that includes one.
+A URI omitting any component with a default value will not
+match a URI explicitly containing that component with its
+default value.  For instance, a URI omitting the optional port
+component will not match a URI explicitly declaring port 5060.
+The same is true for the transport-parameter, ttl-parameter,
+user-parameter, and method components.
+Defining sip:user@host to not be equivalent to
+sip:user@host:5060 is a change from RFC 2543.  When deriving
+addresses from URIs, equivalent addresses are expected from
+equivalent URIs.  The URI sip:user@host:5060 will always
+resolve to port 5060.  The URI sip:user@host may resolve to
+other ports through the DNS SRV mechanisms detailed in [4].
+o  URI uri-parameter components are compared as follows:
+-  Any uri-parameter appearing in both URIs must match.
+-  A user, ttl, or method uri-parameter appearing in only one
+URI never matches, even if it contains the default value.
+-  A URI that includes an maddr parameter will not match a URI
+that contains no maddr parameter.
+-  All other uri-parameters appearing in only one URI are
+ignored when comparing the URIs.
+Rosenberg, et. al.          Standards Track                   [Page 154]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+o  URI header components are never ignored.  Any present header
+component MUST be present in both URIs and match for the URIs
+to match.  The matching rules are defined for each header field
+in Section 20.
+The URIs within each of the following sets are equivalent:
+sip:%61lice@atlanta.com;transport=TCP
+sip:alice@AtLanTa.CoM;Transport=tcp
+sip:carol@chicago.com
+sip:carol@chicago.com;newparam=5
+sip:carol@chicago.com;security=on
+sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com
+sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com
+sip:alice@atlanta.com?subject=project%20x&priority=urgent
+sip:alice@atlanta.com?priority=urgent&subject=project%20x
+The URIs within each of the following sets are not equivalent:
+SIP:ALICE@AtLanTa.CoM;Transport=udp             (different usernames)
+sip:alice@AtLanTa.CoM;Transport=UDP
+sip:bob@biloxi.com                   (can resolve to different ports)
+sip:bob@biloxi.com:5060
+sip:bob@biloxi.com              (can resolve to different transports)
+sip:bob@biloxi.com;transport=udp
+sip:bob@biloxi.com     (can resolve to different port and transports)
+sip:bob@biloxi.com:6000;transport=tcp
+sip:carol@chicago.com                    (different header component)
+sip:carol@chicago.com?Subject=next%20meeting
+sip:bob@phone21.boxesbybob.com   (even though that's what
+sip:bob@192.0.2.4                 phone21.boxesbybob.com resolves to)
+Note that equality is not transitive:
+o  sip:carol@chicago.com and sip:carol@chicago.com;security=on are
+equivalent
+o  sip:carol@chicago.com and sip:carol@chicago.com;security=off
+are equivalent
+Rosenberg, et. al.          Standards Track                   [Page 155]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+o  sip:carol@chicago.com;security=on and
+sip:carol@chicago.com;security=off are not equivalent
+19.1.5 Forming Requests from a URI
+An implementation needs to take care when forming requests directly
+from a URI.  URIs from business cards, web pages, and even from
+sources inside the protocol such as registered contacts may contain
+inappropriate header fields or body parts.
+An implementation MUST include any provided transport, maddr, ttl, or
+user parameter in the Request-URI of the formed request.  If the URI
+contains a method parameter, its value MUST be used as the method of
+the request.  The method parameter MUST NOT be placed in the
+Request-URI.  Unknown URI parameters MUST be placed in the message's
+Request-URI.
+An implementation SHOULD treat the presence of any headers or body
+parts in the URI as a desire to include them in the message, and
+choose to honor the request on a per-component basis.
+An implementation SHOULD NOT honor these obviously dangerous header
+fields: From, Call-ID, CSeq, Via, and Record-Route.
+An implementation SHOULD NOT honor any requested Route header field
+values in order to not be used as an unwitting agent in malicious
+attacks.
+An implementation SHOULD NOT honor requests to include header fields
+that may cause it to falsely advertise its location or capabilities.
+These include: Accept, Accept-Encoding, Accept-Language, Allow,
+Contact (in its dialog usage), Organization, Supported, and User-
+Agent.
+An implementation SHOULD verify the accuracy of any requested
+descriptive header fields, including: Content-Disposition, Content-
+Encoding, Content-Language, Content-Length, Content-Type, Date,
+Mime-Version, and Timestamp.
+If the request formed from constructing a message from a given URI is
+not a valid SIP request, the URI is invalid.  An implementation MUST
+NOT proceed with transmitting the request.  It should instead pursue
+the course of action due an invalid URI in the context it occurs.
+The constructed request can be invalid in many ways.  These
+include, but are not limited to, syntax error in header fields,
+invalid combinations of URI parameters, or an incorrect
+description of the message body.
+Rosenberg, et. al.          Standards Track                   [Page 156]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Sending a request formed from a given URI may require capabilities
+unavailable to the implementation.  The URI might indicate use of an
+unimplemented transport or extension, for example.  An implementation
+SHOULD refuse to send these requests rather than modifying them to
+match their capabilities.  An implementation MUST NOT send a request
+requiring an extension that it does not support.
+For example, such a request can be formed through the presence of
+a Require header parameter or a method URI parameter with an
+unknown or explicitly unsupported value.
+19.1.6 Relating SIP URIs and tel URLs
+When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the
+entire telephone-subscriber portion of the tel URL, including any
+parameters, is placed into the userinfo part of the SIP or SIPS URI.
+Thus, tel:+358-555-1234567;postd=pp22 becomes
+sip:+358-555-1234567;postd=pp22@foo.com;user=phone
+or
+sips:+358-555-1234567;postd=pp22@foo.com;user=phone
+not
+sip:+358-555-1234567@foo.com;postd=pp22;user=phone
+or
+sips:+358-555-1234567@foo.com;postd=pp22;user=phone
+In general, equivalent "tel" URLs converted to SIP or SIPS URIs in
+this fashion may not produce equivalent SIP or SIPS URIs.  The
+userinfo of SIP and SIPS URIs are compared as a case-sensitive
+string.  Variance in case-insensitive portions of tel URLs and
+reordering of tel URL parameters does not affect tel URL equivalence,
+but does affect the equivalence of SIP URIs formed from them.
+For example,
+tel:+358-555-1234567;postd=pp22
+tel:+358-555-1234567;POSTD=PP22
+are equivalent, while
+sip:+358-555-1234567;postd=pp22@foo.com;user=phone
+sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone
+Rosenberg, et. al.          Standards Track                   [Page 157]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+are not.
+Likewise,
+tel:+358-555-1234567;postd=pp22;isub=1411
+tel:+358-555-1234567;isub=1411;postd=pp22
+are equivalent, while
+sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone
+sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone
+are not.
+To mitigate this problem, elements constructing telephone-subscriber
+fields to place in the userinfo part of a SIP or SIPS URI SHOULD fold
+any case-insensitive portion of telephone-subscriber to lower case,
+and order the telephone-subscriber parameters lexically by parameter
+name, excepting isdn-subaddress and post-dial, which occur first and
+in that order.  (All components of a tel URL except for future-
+extension parameters are defined to be compared case-insensitive.)
+Following this suggestion, both
+tel:+358-555-1234567;postd=pp22
+tel:+358-555-1234567;POSTD=PP22
+become
+sip:+358-555-1234567;postd=pp22@foo.com;user=phone
+and both
+tel:+358-555-1234567;tsp=a.b;phone-context=5
+tel:+358-555-1234567;phone-context=5;tsp=a.b
+become
+sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone
+19.2 Option Tags
+Option tags are unique identifiers used to designate new options
+(extensions) in SIP.  These tags are used in Require (Section 20.32),
+Proxy-Require (Section 20.29), Supported (Section 20.37) and
+Unsupported (Section 20.40) header fields.  Note that these options
+appear as parameters in those header fields in an option-tag = token
+form (see Section 25 for the definition of token).
+Rosenberg, et. al.          Standards Track                   [Page 158]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Option tags are defined in standards track RFCs.  This is a change
+from past practice, and is instituted to ensure continuing multi-
+vendor interoperability (see discussion in Section 20.32 and Section
+20.37).  An IANA registry of option tags is used to ensure easy
+reference.
+19.3 Tags
+The "tag" parameter is used in the To and From header fields of SIP
+messages.  It serves as a general mechanism to identify a dialog,
+which is the combination of the Call-ID along with two tags, one from
+each participant in the dialog.  When a UA sends a request outside of
+a dialog, it contains a From tag only, providing "half" of the dialog
+ID.  The dialog is completed from the response(s), each of which
+contributes the second half in the To header field.  The forking of
+SIP requests means that multiple dialogs can be established from a
+single request.  This also explains the need for the two-sided dialog
+identifier; without a contribution from the recipients, the
+originator could not disambiguate the multiple dialogs established
+from a single request.
+When a tag is generated by a UA for insertion into a request or
+response, it MUST be globally unique and cryptographically random
+with at least 32 bits of randomness.  A property of this selection
+requirement is that a UA will place a different tag into the From
+header of an INVITE than it would place into the To header of the
+response to the same INVITE.  This is needed in order for a UA to
+invite itself to a session, a common case for "hairpinning" of calls
+in PSTN gateways.  Similarly, two INVITEs for different calls will
+have different From tags, and two responses for different calls will
+have different To tags.
+Besides the requirement for global uniqueness, the algorithm for
+generating a tag is implementation-specific.  Tags are helpful in
+fault tolerant systems, where a dialog is to be recovered on an
+alternate server after a failure.  A UAS can select the tag in such a
+way that a backup can recognize a request as part of a dialog on the
+failed server, and therefore determine that it should attempt to
+recover the dialog and any other state associated with it.
+20 Header Fields
+The general syntax for header fields is covered in Section 7.3.  This
+section lists the full set of header fields along with notes on
+syntax, meaning, and usage.  Throughout this section, we use [HX.Y]
+to refer to Section X.Y of the current HTTP/1.1 specification RFC
+2616 [8].  Examples of each header field are given.
+Rosenberg, et. al.          Standards Track                   [Page 159]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Information about header fields in relation to methods and proxy
+processing is summarized in Tables 2 and 3.
+The "where" column describes the request and response types in which
+the header field can be used.  Values in this column are:
+R: header field may only appear in requests;
+r: header field may only appear in responses;
+2xx, 4xx, etc.: A numerical value or range indicates response
+codes with which the header field can be used;
+c: header field is copied from the request to the response.
+An empty entry in the "where" column indicates that the header
+field may be present in all requests and responses.
+The "proxy" column describes the operations a proxy may perform on a
+header field:
+a: A proxy can add or concatenate the header field if not present.
+m: A proxy can modify an existing header field value.
+d: A proxy can delete a header field value.
+r: A proxy must be able to read the header field, and thus this
+header field cannot be encrypted.
+The next six columns relate to the presence of a header field in a
+method:
+c: Conditional; requirements on the header field depend on the
+context of the message.
+m: The header field is mandatory.
+m*: The header field SHOULD be sent, but clients/servers need to
+be prepared to receive messages without that header field.
+o: The header field is optional.
+t: The header field SHOULD be sent, but clients/servers need to be
+prepared to receive messages without that header field.
+If a stream-based protocol (such as TCP) is used as a
+transport, then the header field MUST be sent.
+Rosenberg, et. al.          Standards Track                   [Page 160]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+*: The header field is required if the message body is not empty.
+See Sections 20.14, 20.15 and 7.4 for details.
+-: The header field is not applicable.
+"Optional" means that an element MAY include the header field in a
+request or response, and a UA MAY ignore the header field if present
+in the request or response (The exception to this rule is the Require
+header field discussed in 20.32).  A "mandatory" header field MUST be
+present in a request, and MUST be understood by the UAS receiving the
+request.  A mandatory response header field MUST be present in the
+response, and the header field MUST be understood by the UAC
+processing the response.  "Not applicable" means that the header
+field MUST NOT be present in a request.  If one is placed in a
+request by mistake, it MUST be ignored by the UAS receiving the
+request.  Similarly, a header field labeled "not applicable" for a
+response means that the UAS MUST NOT place the header field in the
+response, and the UAC MUST ignore the header field in the response.
+A UA SHOULD ignore extension header parameters that are not
+understood.
+A compact form of some common header field names is also defined for
+use when overall message size is an issue.
+The Contact, From, and To header fields contain a URI.  If the URI
+contains a comma, question mark or semicolon, the URI MUST be
+enclosed in angle brackets (< and >).  Any URI parameters are
+contained within these brackets.  If the URI is not enclosed in angle
+brackets, any semicolon-delimited parameters are header-parameters,
+not URI parameters.
+20.1 Accept
+The Accept header field follows the syntax defined in [H14.1].  The
+semantics are also identical, with the exception that if no Accept
+header field is present, the server SHOULD assume a default value of
+application/sdp.
+An empty Accept header field means that no formats are acceptable.
+Rosenberg, et. al.          Standards Track                   [Page 161]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Example:
+Header field          where   proxy ACK BYE CAN INV OPT REG
+___________________________________________________________
+Accept                  R            -   o   -   o   m*  o
+Accept                 2xx           -   -   -   o   m*  o
+Accept                 415           -   c   -   c   c   c
+Accept-Encoding         R            -   o   -   o   o   o
+Accept-Encoding        2xx           -   -   -   o   m*  o
+Accept-Encoding        415           -   c   -   c   c   c
+Accept-Language         R            -   o   -   o   o   o
+Accept-Language        2xx           -   -   -   o   m*  o
+Accept-Language        415           -   c   -   c   c   c
+Alert-Info              R      ar    -   -   -   o   -   -
+Alert-Info             180     ar    -   -   -   o   -   -
+Allow                   R            -   o   -   o   o   o
+Allow                  2xx           -   o   -   m*  m*  o
+Allow                   r            -   o   -   o   o   o
+Allow                  405           -   m   -   m   m   m
+Authentication-Info    2xx           -   o   -   o   o   o
+Authorization           R            o   o   o   o   o   o
+Call-ID                 c       r    m   m   m   m   m   m
+Call-Info                      ar    -   -   -   o   o   o
+Contact                 R            o   -   -   m   o   o
+Contact                1xx           -   -   -   o   -   -
+Contact                2xx           -   -   -   m   o   o
+Contact                3xx      d    -   o   -   o   o   o
+Contact                485           -   o   -   o   o   o
+Content-Disposition                  o   o   -   o   o   o
+Content-Encoding                     o   o   -   o   o   o
+Content-Language                     o   o   -   o   o   o
+Content-Length                 ar    t   t   t   t   t   t
+Content-Type                         *   *   -   *   *   *
+CSeq                    c       r    m   m   m   m   m   m
+Date                            a    o   o   o   o   o   o
+Error-Info           300-699    a    -   o   o   o   o   o
+Expires                              -   -   -   o   -   o
+From                    c       r    m   m   m   m   m   m
+In-Reply-To             R            -   -   -   o   -   -
+Max-Forwards            R      amr   m   m   m   m   m   m
+Min-Expires            423           -   -   -   -   -   m
+MIME-Version                         o   o   -   o   o   o
+Organization                   ar    -   -   -   o   o   o
+Table 2: Summary of header fields, A--O
+Rosenberg, et. al.          Standards Track                   [Page 162]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Header field              where       proxy ACK BYE CAN INV OPT REG
+___________________________________________________________________
+Priority                    R          ar    -   -   -   o   -   -
+Proxy-Authenticate         407         ar    -   m   -   m   m   m
+Proxy-Authenticate         401         ar    -   o   o   o   o   o
+Proxy-Authorization         R          dr    o   o   -   o   o   o
+Proxy-Require               R          ar    -   o   -   o   o   o
+Record-Route                R          ar    o   o   o   o   o   -
+Record-Route             2xx,18x       mr    -   o   o   o   o   -
+Reply-To                                     -   -   -   o   -   -
+Require                                ar    -   c   -   c   c   c
+Retry-After          404,413,480,486         -   o   o   o   o   o
+500,503             -   o   o   o   o   o
+600,603             -   o   o   o   o   o
+Route                       R          adr   c   c   c   c   c   c
+Server                      r                -   o   o   o   o   o
+Subject                     R                -   -   -   o   -   -
+Supported                   R                -   o   o   m*  o   o
+Supported                  2xx               -   o   o   m*  m*  o
+Timestamp                                    o   o   o   o   o   o
+To                        c(1)          r    m   m   m   m   m   m
+Unsupported                420               -   m   -   m   m   m
+User-Agent                                   o   o   o   o   o   o
+Via                         R          amr   m   m   m   m   m   m
+Via                        rc          dr    m   m   m   m   m   m
+Warning                     r                -   o   o   o   o   o
+WWW-Authenticate           401         ar    -   m   -   m   m   m
+WWW-Authenticate           407         ar    -   o   -   o   o   o
+Table 3: Summary of header fields, P--Z; (1): copied with possible
+addition of tag
+Accept: application/sdp;level=1, application/x-private, text/html
+20.2 Accept-Encoding
+The Accept-Encoding header field is similar to Accept, but restricts
+the content-codings [H3.5] that are acceptable in the response.  See
+[H14.3].  The semantics in SIP are identical to those defined in
+[H14.3].
+An empty Accept-Encoding header field is permissible.  It is
+equivalent to Accept-Encoding: identity, that is, only the identity
+encoding, meaning no encoding, is permissible.
+If no Accept-Encoding header field is present, the server SHOULD
+assume a default value of identity.
+Rosenberg, et. al.          Standards Track                   [Page 163]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+This differs slightly from the HTTP definition, which indicates that
+when not present, any encoding can be used, but the identity encoding
+is preferred.
+Example:
+Accept-Encoding: gzip
+20.3 Accept-Language
+The Accept-Language header field is used in requests to indicate the
+preferred languages for reason phrases, session descriptions, or
+status responses carried as message bodies in the response.  If no
+Accept-Language header field is present, the server SHOULD assume all
+languages are acceptable to the client.
+The Accept-Language header field follows the syntax defined in
+[H14.4].  The rules for ordering the languages based on the "q"
+parameter apply to SIP as well.
+Example:
+Accept-Language: da, en-gb;q=0.8, en;q=0.7
+20.4 Alert-Info
+When present in an INVITE request, the Alert-Info header field
+specifies an alternative ring tone to the UAS.  When present in a 180
+(Ringing) response, the Alert-Info header field specifies an
+alternative ringback tone to the UAC.  A typical usage is for a proxy
+to insert this header field to provide a distinctive ring feature.
+The Alert-Info header field can introduce security risks.  These
+risks and the ways to handle them are discussed in Section 20.9,
+which discusses the Call-Info header field since the risks are
+identical.
+In addition, a user SHOULD be able to disable this feature
+selectively.
+This helps prevent disruptions that could result from the use of
+this header field by untrusted elements.
+Example:
+Alert-Info: <http://www.example.com/sounds/moo.wav>
+Rosenberg, et. al.          Standards Track                   [Page 164]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+20.5 Allow
+The Allow header field lists the set of methods supported by the UA
+generating the message.
+All methods, including ACK and CANCEL, understood by the UA MUST be
+included in the list of methods in the Allow header field, when
+present.  The absence of an Allow header field MUST NOT be
+interpreted to mean that the UA sending the message supports no
+methods.   Rather, it implies that the UA is not providing any
+information on what methods it supports.
+Supplying an Allow header field in responses to methods other than
+OPTIONS reduces the number of messages needed.
+Example:
+Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
+20.6 Authentication-Info
+The Authentication-Info header field provides for mutual
+authentication with HTTP Digest.  A UAS MAY include this header field
+in a 2xx response to a request that was successfully authenticated
+using digest based on the Authorization header field.
+Syntax and semantics follow those specified in RFC 2617 [17].
+Example:
+Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"
+20.7 Authorization
+The Authorization header field contains authentication credentials of
+a UA.  Section 22.2 overviews the use of the Authorization header
+field, and Section 22.4 describes the syntax and semantics when used
+with HTTP authentication.
+This header field, along with Proxy-Authorization, breaks the general
+rules about multiple header field values.  Although not a comma-
+separated list, this header field name may be present multiple times,
+and MUST NOT be combined into a single header line using the usual
+rules described in Section 7.3.
+Rosenberg, et. al.          Standards Track                   [Page 165]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+In the example below, there are no quotes around the Digest
+parameter:
+Authorization: Digest username="Alice", realm="atlanta.com",
+nonce="84a4cc6f3082121f32b42a2187831a9e",
+response="7587245234b3434cc3412213e5f113a5432"
+20.8 Call-ID
+The Call-ID header field uniquely identifies a particular invitation
+or all registrations of a particular client.  A single multimedia
+conference can give rise to several calls with different Call-IDs,
+for example, if a user invites a single individual several times to
+the same (long-running) conference.  Call-IDs are case-sensitive and
+are simply compared byte-by-byte.
+The compact form of the Call-ID header field is i.
+Examples:
+Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
+i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4
+20.9 Call-Info
+The Call-Info header field provides additional information about the
+caller or callee, depending on whether it is found in a request or
+response.  The purpose of the URI is described by the "purpose"
+parameter.  The "icon" parameter designates an image suitable as an
+iconic representation of the caller or callee.  The "info" parameter
+describes the caller or callee in general, for example, through a web
+page.  The "card" parameter provides a business card, for example, in
+vCard [36] or LDIF [37] formats.  Additional tokens can be registered
+using IANA and the procedures in Section 27.
+Use of the Call-Info header field can pose a security risk.  If a
+callee fetches the URIs provided by a malicious caller, the callee
+may be at risk for displaying inappropriate or offensive content,
+dangerous or illegal content, and so on.  Therefore, it is
+RECOMMENDED that a UA only render the information in the Call-Info
+header field if it can verify the authenticity of the element that
+originated the header field and trusts that element.  This need not
+be the peer UA; a proxy can insert this header field into requests.
+Example:
+Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
+<http://www.example.com/alice/> ;purpose=info
+Rosenberg, et. al.          Standards Track                   [Page 166]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+20.10 Contact
+A Contact header field value provides a URI whose meaning depends on
+the type of request or response it is in.
+A Contact header field value can contain a display name, a URI with
+URI parameters, and header parameters.
+This document defines the Contact parameters "q" and "expires".
+These parameters are only used when the Contact is present in a
+REGISTER request or response, or in a 3xx response.  Additional
+parameters may be defined in other specifications.
+When the header field value contains a display name, the URI
+including all URI parameters is enclosed in "<" and ">".  If no "<"
+and ">" are present, all parameters after the URI are header
+parameters, not URI parameters.  The display name can be tokens, or a
+quoted string, if a larger character set is desired.
+Even if the "display-name" is empty, the "name-addr" form MUST be
+used if the "addr-spec" contains a comma, semicolon, or question
+mark.  There may or may not be LWS between the display-name and the
+"<".
+These rules for parsing a display name, URI and URI parameters, and
+header parameters also apply for the header fields To and From.
+The Contact header field has a role similar to the Location header
+field in HTTP.  However, the HTTP header field only allows one
+address, unquoted.  Since URIs can contain commas and semicolons
+as reserved characters, they can be mistaken for header or
+parameter delimiters, respectively.
+The compact form of the Contact header field is m (for "moved").
+Examples:
+Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
+;q=0.7; expires=3600,
+"Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
+m: <sips:bob@192.0.2.4>;expires=60
+Rosenberg, et. al.          Standards Track                   [Page 167]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+20.11 Content-Disposition
+The Content-Disposition header field describes how the message body
+or, for multipart messages, a message body part is to be interpreted
+by the UAC or UAS.  This SIP header field extends the MIME Content-
+Type (RFC 2183 [18]).
+Several new "disposition-types" of the Content-Disposition header are
+defined by SIP.  The value "session" indicates that the body part
+describes a session, for either calls or early (pre-call) media.  The
+value "render" indicates that the body part should be displayed or
+otherwise rendered to the user.  Note that the value "render" is used
+rather than "inline" to avoid the connotation that the MIME body is
+displayed as a part of the rendering of the entire message (since the
+MIME bodies of SIP messages oftentimes are not displayed to users).
+For backward-compatibility, if the Content-Disposition header field
+is missing, the server SHOULD assume bodies of Content-Type
+application/sdp are the disposition "session", while other content
+types are "render".
+The disposition type "icon" indicates that the body part contains an
+image suitable as an iconic representation of the caller or callee
+that could be rendered informationally by a user agent when a message
+has been received, or persistently while a dialog takes place.  The
+value "alert" indicates that the body part contains information, such
+as an audio clip, that should be rendered by the user agent in an
+attempt to alert the user to the receipt of a request, generally a
+request that initiates a dialog; this alerting body could for example
+be rendered as a ring tone for a phone call after a 180 Ringing
+provisional response has been sent.
+Any MIME body with a "disposition-type" that renders content to the
+user should only be processed when a message has been properly
+authenticated.
+The handling parameter, handling-param, describes how the UAS should
+react if it receives a message body whose content type or disposition
+type it does not understand.  The parameter has defined values of
+"optional" and "required".  If the handling parameter is missing, the
+value "required" SHOULD be assumed.  The handling parameter is
+described in RFC 3204 [19].
+If this header field is missing, the MIME type determines the default
+content disposition.  If there is none, "render" is assumed.
+Example:
+Content-Disposition: session
+Rosenberg, et. al.          Standards Track                   [Page 168]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+20.12 Content-Encoding
+The Content-Encoding header field is used as a modifier to the
+"media-type".  When present, its value indicates what additional
+content codings have been applied to the entity-body, and thus what
+decoding mechanisms MUST be applied in order to obtain the media-type
+referenced by the Content-Type header field.  Content-Encoding is
+primarily used to allow a body to be compressed without losing the
+identity of its underlying media type.
+If multiple encodings have been applied to an entity-body, the
+content codings MUST be listed in the order in which they were
+applied.
+All content-coding values are case-insensitive.  IANA acts as a
+registry for content-coding value tokens.  See [H3.5] for a
+definition of the syntax for content-coding.
+Clients MAY apply content encodings to the body in requests.  A
+server MAY apply content encodings to the bodies in responses.  The
+server MUST only use encodings listed in the Accept-Encoding header
+field in the request.
+The compact form of the Content-Encoding header field is e.
+Examples:
+Content-Encoding: gzip
+e: tar
+20.13 Content-Language
+See [H14.12]. Example:
+Content-Language: fr
+20.14 Content-Length
+The Content-Length header field indicates the size of the message-
+body, in decimal number of octets, sent to the recipient.
+Applications SHOULD use this field to indicate the size of the
+message-body to be transferred, regardless of the media type of the
+entity.  If a stream-based protocol (such as TCP) is used as
+transport, the header field MUST be used.
+The size of the message-body does not include the CRLF separating
+header fields and body.  Any Content-Length greater than or equal to
+zero is a valid value.  If no body is present in a message, then the
+Content-Length header field value MUST be set to zero.
+Rosenberg, et. al.          Standards Track                   [Page 169]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The ability to omit Content-Length simplifies the creation of
+cgi-like scripts that dynamically generate responses.
+The compact form of the header field is l.
+Examples:
+Content-Length: 349
+l: 173
+20.15 Content-Type
+The Content-Type header field indicates the media type of the
+message-body sent to the recipient.  The "media-type" element is
+defined in [H3.7].  The Content-Type header field MUST be present if
+the body is not empty.  If the body is empty, and a Content-Type
+header field is present, it indicates that the body of the specific
+type has zero length (for example, an empty audio file).
+The compact form of the header field is c.
+Examples:
+Content-Type: application/sdp
+c: text/html; charset=ISO-8859-4
+20.16 CSeq
+A CSeq header field in a request contains a single decimal sequence
+number and the request method.  The sequence number MUST be
+expressible as a 32-bit unsigned integer.  The method part of CSeq is
+case-sensitive.  The CSeq header field serves to order transactions
+within a dialog, to provide a means to uniquely identify
+transactions, and to differentiate between new requests and request
+retransmissions.  Two CSeq header fields are considered equal if the
+sequence number and the request method are identical.  Example:
+CSeq: 4711 INVITE
+20.17 Date
+The Date header field contains the date and time.  Unlike HTTP/1.1,
+SIP only supports the most recent RFC 1123 [20] format for dates.  As
+in [H3.3], SIP restricts the time zone in SIP-date to "GMT", while
+RFC 1123 allows any time zone.  An RFC 1123 date is case-sensitive.
+The Date header field reflects the time when the request or response
+is first sent.
+Rosenberg, et. al.          Standards Track                   [Page 170]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The Date header field can be used by simple end systems without a
+battery-backed clock to acquire a notion of current time.
+However, in its GMT form, it requires clients to know their offset
+from GMT.
+Example:
+Date: Sat, 13 Nov 2010 23:29:00 GMT
+20.18 Error-Info
+The Error-Info header field provides a pointer to additional
+information about the error status response.
+SIP UACs have user interface capabilities ranging from pop-up
+windows and audio on PC softclients to audio-only on "black"
+phones or endpoints connected via gateways.  Rather than forcing a
+server generating an error to choose between sending an error
+status code with a detailed reason phrase and playing an audio
+recording, the Error-Info header field allows both to be sent.
+The UAC then has the choice of which error indicator to render to
+the caller.
+A UAC MAY treat a SIP or SIPS URI in an Error-Info header field as if
+it were a Contact in a redirect and generate a new INVITE, resulting
+in a recorded announcement session being established.  A non-SIP URI
+MAY be rendered to the user.
+Examples:
+SIP/2.0 404 The number you have dialed is not in service
+Error-Info: <sip:not-in-service-recording@atlanta.com>
+20.19 Expires
+The Expires header field gives the relative time after which the
+message (or content) expires.
+The precise meaning of this is method dependent.
+The expiration time in an INVITE does not affect the duration of the
+actual session that may result from the invitation.  Session
+description protocols may offer the ability to express time limits on
+the session duration, however.
+The value of this field is an integral number of seconds (in decimal)
+between 0 and (2**32)-1, measured from the receipt of the request.
+Rosenberg, et. al.          Standards Track                   [Page 171]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Example:
+Expires: 5
+20.20 From
+The From header field indicates the initiator of the request.  This
+may be different from the initiator of the dialog.  Requests sent by
+the callee to the caller use the callee's address in the From header
+field.
+The optional "display-name" is meant to be rendered by a human user
+interface.  A system SHOULD use the display name "Anonymous" if the
+identity of the client is to remain hidden.  Even if the "display-
+name" is empty, the "name-addr" form MUST be used if the "addr-spec"
+contains a comma, question mark, or semicolon.  Syntax issues are
+discussed in Section 7.3.1.
+Two From header fields are equivalent if their URIs match, and their
+parameters match. Extension parameters in one header field, not
+present in the other are ignored for the purposes of comparison. This
+means that the display name and presence or absence of angle brackets
+do not affect matching.
+See Section 20.10 for the rules for parsing a display name, URI and
+URI parameters, and header field parameters.
+The compact form of the From header field is f.
+Examples:
+From: "A. G. Bell" <sip:agb@bell-telephone.com> ;tag=a48s
+From: sip:+12125551212@server.phone2net.com;tag=887s
+f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8
+20.21 In-Reply-To
+The In-Reply-To header field enumerates the Call-IDs that this call
+references or returns.  These Call-IDs may have been cached by the
+client then included in this header field in a return call.
+This allows automatic call distribution systems to route return
+calls to the originator of the first call.  This also allows
+callees to filter calls, so that only return calls for calls they
+originated will be accepted.  This field is not a substitute for
+request authentication.
+Rosenberg, et. al.          Standards Track                   [Page 172]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Example:
+In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com
+20.22 Max-Forwards
+The Max-Forwards header field must be used with any SIP method to
+limit the number of proxies or gateways that can forward the request
+to the next downstream server.  This can also be useful when the
+client is attempting to trace a request chain that appears to be
+failing or looping in mid-chain.
+The Max-Forwards value is an integer in the range 0-255 indicating
+the remaining number of times this request message is allowed to be
+forwarded.  This count is decremented by each server that forwards
+the request.  The recommended initial value is 70.
+This header field should be inserted by elements that can not
+otherwise guarantee loop detection.  For example, a B2BUA should
+insert a Max-Forwards header field.
+Example:
+Max-Forwards: 6
+20.23 Min-Expires
+The Min-Expires header field conveys the minimum refresh interval
+supported for soft-state elements managed by that server.  This
+includes Contact header fields that are stored by a registrar.  The
+header field contains a decimal integer number of seconds from 0 to
+(2**32)-1.  The use of the header field in a 423 (Interval Too Brief)
+response is described in Sections 10.2.8, 10.3, and 21.4.17.
+Example:
+Min-Expires: 60
+20.24 MIME-Version
+See [H19.4.1].
+Example:
+MIME-Version: 1.0
+Rosenberg, et. al.          Standards Track                   [Page 173]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+20.25 Organization
+The Organization header field conveys the name of the organization to
+which the SIP element issuing the request or response belongs.
+The field MAY be used by client software to filter calls.
+Example:
+Organization: Boxes by Bob
+20.26 Priority
+The Priority header field indicates the urgency of the request as
+perceived by the client.  The Priority header field describes the
+priority that the SIP request should have to the receiving human or
+its agent.  For example, it may be factored into decisions about call
+routing and acceptance.  For these decisions, a message containing no
+Priority header field SHOULD be treated as if it specified a Priority
+of "normal".  The Priority header field does not influence the use of
+communications resources such as packet forwarding priority in
+routers or access to circuits in PSTN gateways.  The header field can
+have the values "non-urgent", "normal", "urgent", and "emergency",
+but additional values can be defined elsewhere.  It is RECOMMENDED
+that the value of "emergency" only be used when life, limb, or
+property are in imminent danger.  Otherwise, there are no semantics
+defined for this header field.
+These are the values of RFC 2076 [38], with the addition of
+"emergency".
+Examples:
+Subject: A tornado is heading our way!
+Priority: emergency
+or
+Subject: Weekend plans
+Priority: non-urgent
+20.27 Proxy-Authenticate
+A Proxy-Authenticate header field value contains an authentication
+challenge.
+The use of this header field is defined in [H14.33].  See Section
+22.3 for further details on its usage.
+Rosenberg, et. al.          Standards Track                   [Page 174]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Example:
+Proxy-Authenticate: Digest realm="atlanta.com",
+domain="sip:ss1.carrier.com", qop="auth",
+nonce="f84f1cec41e6cbe5aea9c8e88d359",
+opaque="", stale=FALSE, algorithm=MD5
+20.28 Proxy-Authorization
+The Proxy-Authorization header field allows the client to identify
+itself (or its user) to a proxy that requires authentication.  A
+Proxy-Authorization field value consists of credentials containing
+the authentication information of the user agent for the proxy and/or
+realm of the resource being requested.
+See Section 22.3 for a definition of the usage of this header field.
+This header field, along with Authorization, breaks the general rules
+about multiple header field names.  Although not a comma-separated
+list, this header field name may be present multiple times, and MUST
+NOT be combined into a single header line using the usual rules
+described in Section 7.3.1.
+Example:
+Proxy-Authorization: Digest username="Alice", realm="atlanta.com",
+nonce="c60f3082ee1212b402a21831ae",
+response="245f23415f11432b3434341c022"
+20.29 Proxy-Require
+The Proxy-Require header field is used to indicate proxy-sensitive
+features that must be supported by the proxy.  See Section 20.32 for
+more details on the mechanics of this message and a usage example.
+Example:
+Proxy-Require: foo
+20.30 Record-Route
+The Record-Route header field is inserted by proxies in a request to
+force future requests in the dialog to be routed through the proxy.
+Examples of its use with the Route header field are described in
+Sections 16.12.1.
+Rosenberg, et. al.          Standards Track                   [Page 175]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Example:
+Record-Route: <sip:server10.biloxi.com;lr>,
+<sip:bigbox3.site3.atlanta.com;lr>
+20.31 Reply-To
+The Reply-To header field contains a logical return URI that may be
+different from the From header field.  For example, the URI MAY be
+used to return missed calls or unestablished sessions.  If the user
+wished to remain anonymous, the header field SHOULD either be omitted
+from the request or populated in such a way that does not reveal any
+private information.
+Even if the "display-name" is empty, the "name-addr" form MUST be
+used if the "addr-spec" contains a comma, question mark, or
+semicolon.  Syntax issues are discussed in Section 7.3.1.
+Example:
+Reply-To: Bob <sip:bob@biloxi.com>
+20.32 Require
+The Require header field is used by UACs to tell UASs about options
+that the UAC expects the UAS to support in order to process the
+request.  Although an optional header field, the Require MUST NOT be
+ignored if it is present.
+The Require header field contains a list of option tags, described in
+Section 19.2.  Each option tag defines a SIP extension that MUST be
+understood to process the request.  Frequently, this is used to
+indicate that a specific set of extension header fields need to be
+understood.  A UAC compliant to this specification MUST only include
+option tags corresponding to standards-track RFCs.
+Example:
+Require: 100rel
+20.33 Retry-After
+The Retry-After header field can be used with a 500 (Server Internal
+Error) or 503 (Service Unavailable) response to indicate how long the
+service is expected to be unavailable to the requesting client and
+with a 404 (Not Found), 413 (Request Entity Too Large), 480
+(Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603
+Rosenberg, et. al.          Standards Track                   [Page 176]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+(Decline) response to indicate when the called party anticipates
+being available again.  The value of this field is a positive integer
+number of seconds (in decimal) after the time of the response.
+An optional comment can be used to indicate additional information
+about the time of callback.  An optional "duration" parameter
+indicates how long the called party will be reachable starting at the
+initial time of availability.  If no duration parameter is given, the
+service is assumed to be available indefinitely.
+Examples:
+Retry-After: 18000;duration=3600
+Retry-After: 120 (I'm in a meeting)
+20.34 Route
+The Route header field is used to force routing for a request through
+the listed set of proxies.  Examples of the use of the Route header
+field are in Section 16.12.1.
+Example:
+Route: <sip:bigbox3.site3.atlanta.com;lr>,
+<sip:server10.biloxi.com;lr>
+20.35 Server
+The Server header field contains information about the software used
+by the UAS to handle the request.
+Revealing the specific software version of the server might allow the
+server to become more vulnerable to attacks against software that is
+known to contain security holes.  Implementers SHOULD make the Server
+header field a configurable option.
+Example:
+Server: HomeServer v2
+20.36 Subject
+The Subject header field provides a summary or indicates the nature
+of the call, allowing call filtering without having to parse the
+session description.  The session description does not have to use
+the same subject indication as the invitation.
+The compact form of the Subject header field is s.
+Rosenberg, et. al.          Standards Track                   [Page 177]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Example:
+Subject: Need more boxes
+s: Tech Support
+20.37 Supported
+The Supported header field enumerates all the extensions supported by
+the UAC or UAS.
+The Supported header field contains a list of option tags, described
+in Section 19.2, that are understood by the UAC or UAS.  A UA
+compliant to this specification MUST only include option tags
+corresponding to standards-track RFCs.  If empty, it means that no
+extensions are supported.
+The compact form of the Supported header field is k.
+Example:
+Supported: 100rel
+20.38 Timestamp
+The Timestamp header field describes when the UAC sent the request to
+the UAS.
+See Section 8.2.6 for details on how to generate a response to a
+request that contains the header field.  Although there is no
+normative behavior defined here that makes use of the header, it
+allows for extensions or SIP applications to obtain RTT estimates.
+Example:
+Timestamp: 54
+20.39 To
+The To header field specifies the logical recipient of the request.
+The optional "display-name" is meant to be rendered by a human-user
+interface.  The "tag" parameter serves as a general mechanism for
+dialog identification.
+See Section 19.3 for details of the "tag" parameter.
+Rosenberg, et. al.          Standards Track                   [Page 178]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Comparison of To header fields for equality is identical to
+comparison of From header fields.  See Section 20.10 for the rules
+for parsing a display name, URI and URI parameters, and header field
+parameters.
+The compact form of the To header field is t.
+The following are examples of valid To header fields:
+To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
+t: sip:+12125551212@server.phone2net.com
+20.40 Unsupported
+The Unsupported header field lists the features not supported by the
+UAS.  See Section 20.32 for motivation.
+Example:
+Unsupported: foo
+20.41 User-Agent
+The User-Agent header field contains information about the UAC
+originating the request.  The semantics of this header field are
+defined in [H14.43].
+Revealing the specific software version of the user agent might allow
+the user agent to become more vulnerable to attacks against software
+that is known to contain security holes.  Implementers SHOULD make
+the User-Agent header field a configurable option.
+Example:
+User-Agent: Softphone Beta1.5
+20.42 Via
+The Via header field indicates the path taken by the request so far
+and indicates the path that should be followed in routing responses.
+The branch ID parameter in the Via header field values serves as a
+transaction identifier, and is used by proxies to detect loops.
+A Via header field value contains the transport protocol used to send
+the message, the client's host name or network address, and possibly
+the port number at which it wishes to receive responses.  A Via
+header field value can also contain parameters such as "maddr",
+"ttl", "received", and "branch", whose meaning and use are described
+Rosenberg, et. al.          Standards Track                   [Page 179]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+in other sections.  For implementations compliant to this
+specification, the value of the branch parameter MUST start with the
+magic cookie "z9hG4bK", as discussed in Section 8.1.1.7.
+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.
+Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
+Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207
+;branch=z9hG4bK77asjd
+The compact form of the Via header field is v.
+In this example, the message originated from a multi-homed host with
+two addresses, 192.0.2.1 and 192.0.2.207.  The sender guessed wrong
+as to which network interface would be used.  Erlang.bell-
+telephone.com noticed the mismatch and added a parameter to the
+previous hop's Via header field value, containing the address that
+the packet actually came from.
+The host or network address and port number are not required to
+follow the SIP URI syntax.  Specifically, LWS on either side of the
+":" or "/" is allowed, as shown here:
+Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16
+;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1
+Even though this specification mandates that the branch parameter be
+present in all requests, the BNF for the header field indicates that
+it is optional.  This allows interoperation with RFC 2543 elements,
+which did not have to insert the branch parameter.
+Two Via header fields are equal if their sent-protocol and sent-by
+fields are equal, both have the same set of parameters, and the
+values of all parameters are equal.
+20.43 Warning
+The Warning header field is used to carry additional information
+about the status of a response.  Warning header field values are sent
+with responses and contain a three-digit warning code, host name, and
+warning text.
+The "warn-text" should be in a natural language that is most likely
+to be intelligible to the human user receiving the response.  This
+decision can be based on any available knowledge, such as the
+location of the user, the Accept-Language field in a request, or the
+Rosenberg, et. al.          Standards Track                   [Page 180]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Content-Language field in a response.  The default language is i-
+default [21].
+The currently-defined "warn-code"s are listed below, with a
+recommended warn-text in English and a description of their meaning.
+These warnings describe failures induced by the session description.
+The first digit of warning codes beginning with "3" indicates
+warnings specific to SIP.  Warnings 300 through 329 are reserved for
+indicating problems with keywords in the session description, 330
+through 339 are warnings related to basic network services requested
+in the session description, 370 through 379 are warnings related to
+quantitative QoS parameters requested in the session description, and
+390 through 399 are miscellaneous warnings that do not fall into one
+of the above categories.
+300 Incompatible network protocol: One or more network protocols
+contained in the session description are not available.
+301 Incompatible network address formats: One or more network
+address formats contained in the session description are not
+available.
+302 Incompatible transport protocol: One or more transport
+protocols described in the session description are not
+available.
+303 Incompatible bandwidth units: One or more bandwidth
+measurement units contained in the session description were
+not understood.
+304 Media type not available: One or more media types contained in
+the session description are not available.
+305 Incompatible media format: One or more media formats contained
+in the session description are not available.
+306 Attribute not understood: One or more of the media attributes
+in the session description are not supported.
+307 Session description parameter not understood: A parameter
+other than those listed above was not understood.
+330 Multicast not available: The site where the user is located
+does not support multicast.
+331 Unicast not available: The site where the user is located does
+not support unicast communication (usually due to the presence
+of a firewall).
+Rosenberg, et. al.          Standards Track                   [Page 181]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+370 Insufficient bandwidth: The bandwidth specified in the session
+description or defined by the media exceeds that known to be
+available.
+399 Miscellaneous warning: The warning text can include arbitrary
+information to be presented to a human user or logged.  A
+system receiving this warning MUST NOT take any automated
+action.
+1xx and 2xx have been taken by HTTP/1.1.
+Additional "warn-code"s can be defined through IANA, as defined in
+Section 27.2.
+Examples:
+Warning: 307 isi.edu "Session parameter 'foo' not understood"
+Warning: 301 isi.edu "Incompatible network address type 'E.164'"
+20.44 WWW-Authenticate
+A WWW-Authenticate header field value contains an authentication
+challenge.  See Section 22.2 for further details on its usage.
+Example:
+WWW-Authenticate: Digest realm="atlanta.com",
+domain="sip:boxesbybob.com", qop="auth",
+nonce="f84f1cec41e6cbe5aea9c8e88d359",
+opaque="", stale=FALSE, algorithm=MD5
+21 Response Codes
+The response codes are consistent with, and extend, HTTP/1.1 response
+codes.  Not all HTTP/1.1 response codes are appropriate, and only
+those that are appropriate are given here.  Other HTTP/1.1 response
+codes SHOULD NOT be used.  Also, SIP defines a new class, 6xx.
+21.1 Provisional 1xx
+Provisional responses, also known as informational responses,
+indicate that the server contacted is performing some further action
+and does not yet have a definitive response.  A server sends a 1xx
+response if it expects to take more than 200 ms to obtain a final
+response.  Note that 1xx responses are not transmitted reliably.
+They never cause the client to send an ACK.  Provisional (1xx)
+responses MAY contain message bodies, including session descriptions.
+Rosenberg, et. al.          Standards Track                   [Page 182]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+21.1.1 100 Trying
+This response indicates that the request has been received by the
+next-hop server and that some unspecified action is being taken on
+behalf of this call (for example, a database is being consulted).
+This response, like all other provisional responses, stops
+retransmissions of an INVITE by a UAC.  The 100 (Trying) response is
+different from other provisional responses, in that it is never
+forwarded upstream by a stateful proxy.
+21.1.2 180 Ringing
+The UA receiving the INVITE is trying to alert the user.  This
+response MAY be used to initiate local ringback.
+21.1.3 181 Call Is Being Forwarded
+A server MAY use this status code to indicate that the call is being
+forwarded to a different set of destinations.
+21.1.4 182 Queued
+The called party is temporarily unavailable, but the server has
+decided to queue the call rather than reject it.  When the callee
+becomes available, it will return the appropriate final status
+response.  The reason phrase MAY give further details about the
+status of the call, for example, "5 calls queued; expected waiting
+time is 15 minutes".  The server MAY issue several 182 (Queued)
+responses to update the caller about the status of the queued call.
+21.1.5 183 Session Progress
+The 183 (Session Progress) response is used to convey information
+about the progress of the call that is not otherwise classified.  The
+Reason-Phrase, header fields, or message body MAY be used to convey
+more details about the call progress.
+21.2 Successful 2xx
+The request was successful.
+21.2.1 200 OK
+The request has succeeded.  The information returned with the
+response depends on the method used in the request.
+Rosenberg, et. al.          Standards Track                   [Page 183]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+21.3 Redirection 3xx
+3xx responses give information about the user's new location, or
+about alternative services that might be able to satisfy the call.
+21.3.1 300 Multiple Choices
+The address in the request resolved to several choices, each with its
+own specific location, and the user (or UA) can select a preferred
+communication end point and redirect its request to that location.
+The response MAY include a message body containing a list of resource
+characteristics and location(s) from which the user or UA can choose
+the one most appropriate, if allowed by the Accept request header
+field.  However, no MIME types have been defined for this message
+body.
+The choices SHOULD also be listed as Contact fields (Section 20.10).
+Unlike HTTP, the SIP response MAY contain several Contact fields or a
+list of addresses in a Contact field.  UAs MAY use the Contact header
+field value for automatic redirection or MAY ask the user to confirm
+a choice.  However, this specification does not define any standard
+for such automatic selection.
+This status response is appropriate if the callee can be reached
+at several different locations and the server cannot or prefers
+not to proxy the request.
+21.3.2 301 Moved Permanently
+The user can no longer be found at the address in the Request-URI,
+and the requesting client SHOULD retry at the new address given by
+the Contact header field (Section 20.10).  The requestor SHOULD
+update any local directories, address books, and user location caches
+with this new value and redirect future requests to the address(es)
+listed.
+21.3.3 302 Moved Temporarily
+The requesting client SHOULD retry the request at the new address(es)
+given by the Contact header field (Section 20.10).  The Request-URI
+of the new request uses the value of the Contact header field in the
+response.
+Rosenberg, et. al.          Standards Track                   [Page 184]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The duration of the validity of the Contact URI can be indicated
+through an Expires (Section 20.19) header field or an expires
+parameter in the Contact header field.  Both proxies and UAs MAY
+cache this URI for the duration of the expiration time.  If there is
+no explicit expiration time, the address is only valid once for
+recursing, and MUST NOT be cached for future transactions.
+If the URI cached from the Contact header field fails, the Request-
+URI from the redirected request MAY be tried again a single time.
+The temporary URI may have become out-of-date sooner than the
+expiration time, and a new temporary URI may be available.
+21.3.4 305 Use Proxy
+The requested resource MUST be accessed through the proxy given by
+the Contact field.  The Contact field gives the URI of the proxy.
+The recipient is expected to repeat this single request via the
+proxy.  305 (Use Proxy) responses MUST only be generated by UASs.
+21.3.5 380 Alternative Service
+The call was not successful, but alternative services are possible.
+The alternative services are described in the message body of the
+response.  Formats for such bodies are not defined here, and may be
+the subject of future standardization.
+21.4 Request Failure 4xx
+4xx responses are definite failure responses from a particular
+server.  The client SHOULD NOT retry the same request without
+modification (for example, adding appropriate authorization).
+However, the same request to a different server might be successful.
+21.4.1 400 Bad Request
+The request could not be understood due to malformed syntax.  The
+Reason-Phrase SHOULD identify the syntax problem in more detail, for
+example, "Missing Call-ID header field".
+21.4.2 401 Unauthorized
+The request requires user authentication.  This response is issued by
+UASs and registrars, while 407 (Proxy Authentication Required) is
+used by proxy servers.
+Rosenberg, et. al.          Standards Track                   [Page 185]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+21.4.3 402 Payment Required
+Reserved for future use.
+21.4.4 403 Forbidden
+The server understood the request, but is refusing to fulfill it.
+Authorization will not help, and the request SHOULD NOT be repeated.
+21.4.5 404 Not Found
+The server has definitive information that the user does not exist at
+the domain specified in the Request-URI.  This status is also
+returned if the domain in the Request-URI does not match any of the
+domains handled by the recipient of the request.
+21.4.6 405 Method Not Allowed
+The method specified in the Request-Line is understood, but not
+allowed for the address identified by the Request-URI.
+The response MUST include an Allow header field containing a list of
+valid methods for the indicated address.
+21.4.7 406 Not Acceptable
+The resource identified by the request is only capable of generating
+response entities that have content characteristics not acceptable
+according to the Accept header field sent in the request.
+21.4.8 407 Proxy Authentication Required
+This code is similar to 401 (Unauthorized), but indicates that the
+client MUST first authenticate itself with the proxy.  SIP access
+authentication is explained in Sections 26 and 22.3.
+This status code can be used for applications where access to the
+communication channel (for example, a telephony gateway) rather than
+the callee requires authentication.
+21.4.9 408 Request Timeout
+The server could not produce a response within a suitable amount of
+time, for example, if it could not determine the location of the user
+in time.  The client MAY repeat the request without modifications at
+any later time.
+Rosenberg, et. al.          Standards Track                   [Page 186]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+21.4.10 410 Gone
+The requested resource is no longer available at the server and no
+forwarding address is known.  This condition is expected to be
+considered permanent.  If the server does not know, or has no
+facility to determine, whether or not the condition is permanent, the
+status code 404 (Not Found) SHOULD be used instead.
+21.4.11 413 Request Entity Too Large
+The server is refusing to process a request because the request
+entity-body is larger than the server is willing or able to process.
+The server MAY close the connection to prevent the client from
+continuing the request.
+If the condition is temporary, the server SHOULD include a Retry-
+After header field to indicate that it is temporary and after what
+time the client MAY try again.
+21.4.12 414 Request-URI Too Long
+The server is refusing to service the request because the Request-URI
+is longer than the server is willing to interpret.
+21.4.13 415 Unsupported Media Type
+The server is refusing to service the request because the message
+body of the request is in a format not supported by the server for
+the requested method.  The server MUST return a list of acceptable
+formats using the Accept, Accept-Encoding, or Accept-Language header
+field, depending on the specific problem with the content.  UAC
+processing of this response is described in Section 8.1.3.5.
+21.4.14 416 Unsupported URI Scheme
+The server cannot process the request because the scheme of the URI
+in the Request-URI is unknown to the server.  Client processing of
+this response is described in Section 8.1.3.5.
+21.4.15 420 Bad Extension
+The server did not understand the protocol extension specified in a
+Proxy-Require (Section 20.29) or Require (Section 20.32) header
+field.  The server MUST include a list of the unsupported extensions
+in an Unsupported header field in the response.  UAC processing of
+this response is described in Section 8.1.3.5.
+Rosenberg, et. al.          Standards Track                   [Page 187]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+21.4.16 421 Extension Required
+The UAS needs a particular extension to process the request, but this
+extension is not listed in a Supported header field in the request.
+Responses with this status code MUST contain a Require header field
+listing the required extensions.
+A UAS SHOULD NOT use this response unless it truly cannot provide any
+useful service to the client.  Instead, if a desirable extension is
+not listed in the Supported header field, servers SHOULD process the
+request using baseline SIP capabilities and any extensions supported
+by the client.
+21.4.17 423 Interval Too Brief
+The server is rejecting the request because the expiration time of
+the resource refreshed by the request is too short.  This response
+can be used by a registrar to reject a registration whose Contact
+header field expiration time was too small.  The use of this response
+and the related Min-Expires header field are described in Sections
+10.2.8, 10.3, and 20.23.
+21.4.18 480 Temporarily Unavailable
+The callee's end system was contacted successfully but the callee is
+currently unavailable (for example, is not logged in, logged in but
+in a state that precludes communication with the callee, or has
+activated the "do not disturb" feature).  The response MAY indicate a
+better time to call in the Retry-After header field.  The user could
+also be available elsewhere (unbeknownst to this server).  The reason
+phrase SHOULD indicate a more precise cause as to why the callee is
+unavailable.  This value SHOULD be settable by the UA.  Status 486
+(Busy Here) MAY be used to more precisely indicate a particular
+reason for the call failure.
+This status is also returned by a redirect or proxy server that
+recognizes the user identified by the Request-URI, but does not
+currently have a valid forwarding location for that user.
+21.4.19 481 Call/Transaction Does Not Exist
+This status indicates that the UAS received a request that does not
+match any existing dialog or transaction.
+21.4.20 482 Loop Detected
+The server has detected a loop (Section 16.3 Item 4).
+Rosenberg, et. al.          Standards Track                   [Page 188]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+21.4.21 483 Too Many Hops
+The server received a request that contains a Max-Forwards (Section
+20.22) header field with the value zero.
+21.4.22 484 Address Incomplete
+The server received a request with a Request-URI that was incomplete.
+Additional information SHOULD be provided in the reason phrase.
+This status code allows overlapped dialing.  With overlapped
+dialing, the client does not know the length of the dialing
+string.  It sends strings of increasing lengths, prompting the
+user for more input, until it no longer receives a 484 (Address
+Incomplete) status response.
+21.4.23 485 Ambiguous
+The Request-URI was ambiguous.  The response MAY contain a listing of
+possible unambiguous addresses in Contact header fields.  Revealing
+alternatives can infringe on privacy of the user or the organization.
+It MUST be possible to configure a server to respond with status 404
+(Not Found) or to suppress the listing of possible choices for
+ambiguous Request-URIs.
+Example response to a request with the Request-URI
+sip:lee@example.com:
+SIP/2.0 485 Ambiguous
+Contact: Carol Lee <sip:carol.lee@example.com>
+Contact: Ping Lee <sip:p.lee@example.com>
+Contact: Lee M. Foote <sips:lee.foote@example.com>
+Some email and voice mail systems provide this functionality.  A
+status code separate from 3xx is used since the semantics are
+different: for 300, it is assumed that the same person or service
+will be reached by the choices provided.  While an automated
+choice or sequential search makes sense for a 3xx response, user
+intervention is required for a 485 (Ambiguous) response.
+21.4.24 486 Busy Here
+The callee's end system was contacted successfully, but the callee is
+currently not willing or able to take additional calls at this end
+system.  The response MAY indicate a better time to call in the
+Retry-After header field.  The user could also be available
+Rosenberg, et. al.          Standards Track                   [Page 189]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+elsewhere, such as through a voice mail service.  Status 600 (Busy
+Everywhere) SHOULD be used if the client knows that no other end
+system will be able to accept this call.
+21.4.25 487 Request Terminated
+The request was terminated by a BYE or CANCEL request.  This response
+is never returned for a CANCEL request itself.
+21.4.26 488 Not Acceptable Here
+The response has the same meaning as 606 (Not Acceptable), but only
+applies to the specific resource addressed by the Request-URI and the
+request may succeed elsewhere.
+A message body containing a description of media capabilities MAY be
+present in the response, which is formatted according to the Accept
+header field in the INVITE (or application/sdp if not present), the
+same as a message body in a 200 (OK) response to an OPTIONS request.
+21.4.27 491 Request Pending
+The request was received by a UAS that had a pending request within
+the same dialog.  Section 14.2 describes how such "glare" situations
+are resolved.
+21.4.28 493 Undecipherable
+The request was received by a UAS that contained an encrypted MIME
+body for which the recipient does not possess or will not provide an
+appropriate decryption key.  This response MAY have a single body
+containing an appropriate public key that should be used to encrypt
+MIME bodies sent to this UA.  Details of the usage of this response
+code can be found in Section 23.2.
+21.5 Server Failure 5xx
+5xx responses are failure responses given when a server itself has
+erred.
+21.5.1 500 Server Internal Error
+The server encountered an unexpected condition that prevented it from
+fulfilling the request.  The client MAY display the specific error
+condition and MAY retry the request after several seconds.
+If the condition is temporary, the server MAY indicate when the
+client may retry the request using the Retry-After header field.
+Rosenberg, et. al.          Standards Track                   [Page 190]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+21.5.2 501 Not Implemented
+The server does not support the functionality required to fulfill the
+request.  This is the appropriate response when a UAS does not
+recognize the request method and is not capable of supporting it for
+any user.  (Proxies forward all requests regardless of method.)
+Note that a 405 (Method Not Allowed) is sent when the server
+recognizes the request method, but that method is not allowed or
+supported.
+21.5.3 502 Bad Gateway
+The server, while acting as a gateway or proxy, received an invalid
+response from the downstream server it accessed in attempting to
+fulfill the request.
+21.5.4 503 Service Unavailable
+The server is temporarily unable to process the request due to a
+temporary overloading or maintenance of the server.  The server MAY
+indicate when the client should retry the request in a Retry-After
+header field.  If no Retry-After is given, the client MUST act as if
+it had received a 500 (Server Internal Error) response.
+A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD
+attempt to forward the request to an alternate server.  It SHOULD NOT
+forward any other requests to that server for the duration specified
+in the Retry-After header field, if present.
+Servers MAY refuse the connection or drop the request instead of
+responding with 503 (Service Unavailable).
+21.5.5 504 Server Time-out
+The server did not receive a timely response from an external server
+it accessed in attempting to process the request.  408 (Request
+Timeout) should be used instead if there was no response within the
+period specified in the Expires header field from the upstream
+server.
+21.5.6 505 Version Not Supported
+The server does not support, or refuses to support, the SIP protocol
+version that was used in the request.  The server is indicating that
+it is unable or unwilling to complete the request using the same
+major version as the client, other than with this error message.
+Rosenberg, et. al.          Standards Track                   [Page 191]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+21.5.7 513 Message Too Large
+The server was unable to process the request since the message length
+exceeded its capabilities.
+21.6 Global Failures 6xx
+6xx responses indicate that a server has definitive information about
+a particular user, not just the particular instance indicated in the
+Request-URI.
+21.6.1 600 Busy Everywhere
+The callee's end system was contacted successfully but the callee is
+busy and does not wish to take the call at this time.  The response
+MAY indicate a better time to call in the Retry-After header field.
+If the callee does not wish to reveal the reason for declining the
+call, the callee uses status code 603 (Decline) instead.  This status
+response is returned only if the client knows that no other end point
+(such as a voice mail system) will answer the request.  Otherwise,
+486 (Busy Here) should be returned.
+21.6.2 603 Decline
+The callee's machine was successfully contacted but the user
+explicitly does not wish to or cannot participate.  The response MAY
+indicate a better time to call in the Retry-After header field.  This
+status response is returned only if the client knows that no other
+end point will answer the request.
+21.6.3 604 Does Not Exist Anywhere
+The server has authoritative information that the user indicated in
+the Request-URI does not exist anywhere.
+21.6.4 606 Not Acceptable
+The user's agent was contacted successfully but some aspects of the
+session description such as the requested media, bandwidth, or
+addressing style were not acceptable.
+A 606 (Not Acceptable) response means that the user wishes to
+communicate, but cannot adequately support the session described.
+The 606 (Not Acceptable) response MAY contain a list of reasons in a
+Warning header field describing why the session described cannot be
+supported.  Warning reason codes are listed in Section 20.43.
+Rosenberg, et. al.          Standards Track                   [Page 192]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+A message body containing a description of media capabilities MAY be
+present in the response, which is formatted according to the Accept
+header field in the INVITE (or application/sdp if not present), the
+same as a message body in a 200 (OK) response to an OPTIONS request.
+It is hoped that negotiation will not frequently be needed, and when
+a new user is being invited to join an already existing conference,
+negotiation may not be possible.  It is up to the invitation
+initiator to decide whether or not to act on a 606 (Not Acceptable)
+response.
+This status response is returned only if the client knows that no
+other end point will answer the request.
+22 Usage of HTTP Authentication
+SIP provides a stateless, challenge-based mechanism for
+authentication that is based on authentication in HTTP.  Any time
+that a proxy server or UA receives a request (with the exceptions
+given in Section 22.1), it MAY challenge the initiator of the request
+to provide assurance of its identity.  Once the originator has been
+identified, the recipient of the request SHOULD ascertain whether or
+not this user is authorized to make the request in question.  No
+authorization systems are recommended or discussed in this document.
+The "Digest" authentication mechanism described in this section
+provides message authentication and replay protection only, without
+message integrity or confidentiality.  Protective measures above and
+beyond those provided by Digest need to be taken to prevent active
+attackers from modifying SIP requests and responses.
+Note that due to its weak security, the usage of "Basic"
+authentication has been deprecated.  Servers MUST NOT accept
+credentials using the "Basic" authorization scheme, and servers also
+MUST NOT challenge with "Basic".  This is a change from RFC 2543.
+22.1 Framework
+The framework for SIP authentication closely parallels that of HTTP
+(RFC 2617 [17]).  In particular, the BNF for auth-scheme, auth-param,
+challenge, realm, realm-value, and credentials is identical (although
+the usage of "Basic" as a scheme is not permitted).  In SIP, a UAS
+uses the 401 (Unauthorized) response to challenge the identity of a
+UAC.  Additionally, registrars and redirect servers MAY make use of
+401 (Unauthorized) responses for authentication, but proxies MUST
+NOT, and instead MAY use the 407 (Proxy Authentication Required)
+Rosenberg, et. al.          Standards Track                   [Page 193]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+response.  The requirements for inclusion of the Proxy-Authenticate,
+Proxy-Authorization, WWW-Authenticate, and Authorization in the
+various messages are identical to those described in RFC 2617 [17].
+Since SIP does not have the concept of a canonical root URL, the
+notion of protection spaces is interpreted differently in SIP.  The
+realm string alone defines the protection domain.  This is a change
+from RFC 2543, in which the Request-URI and the realm together
+defined the protection domain.
+This previous definition of protection domain caused some amount
+of confusion since the Request-URI sent by the UAC and the
+Request-URI received by the challenging server might be different,
+and indeed the final form of the Request-URI might not be known to
+the UAC.  Also, the previous definition depended on the presence
+of a SIP URI in the Request-URI and seemed to rule out alternative
+URI schemes (for example, the tel URL).
+Operators of user agents or proxy servers that will authenticate
+received requests MUST adhere to the following guidelines for
+creation of a realm string for their server:
+o  Realm strings MUST be globally unique.  It is RECOMMENDED that
+a realm string contain a hostname or domain name, following the
+recommendation in Section 3.2.1 of RFC 2617 [17].
+o  Realm strings SHOULD present a human-readable identifier that
+can be rendered to a user.
+For example:
+INVITE sip:bob@biloxi.com SIP/2.0
+Authorization: Digest realm="biloxi.com", <...>
+Generally, SIP authentication is meaningful for a specific realm, a
+protection domain.  Thus, for Digest authentication, each such
+protection domain has its own set of usernames and passwords.  If a
+server does not require authentication for a particular request, it
+MAY accept a default username, "anonymous", which has no password
+(password of "").  Similarly, UACs representing many users, such as
+PSTN gateways, MAY have their own device-specific username and
+password, rather than accounts for particular users, for their realm.
+While a server can legitimately challenge most SIP requests, there
+are two requests defined by this document that require special
+handling for authentication: ACK and CANCEL.
+Rosenberg, et. al.          Standards Track                   [Page 194]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Under an authentication scheme that uses responses to carry values
+used to compute nonces (such as Digest), some problems come up for
+any requests that take no response, including ACK.  For this reason,
+any credentials in the INVITE that were accepted by a server MUST be
+accepted by that server for the ACK.  UACs creating an ACK message
+will duplicate all of the Authorization and Proxy-Authorization
+header field values that appeared in the INVITE to which the ACK
+corresponds.  Servers MUST NOT attempt to challenge an ACK.
+Although the CANCEL method does take a response (a 2xx), servers MUST
+NOT attempt to challenge CANCEL requests since these requests cannot
+be resubmitted.  Generally, a CANCEL request SHOULD be accepted by a
+server if it comes from the same hop that sent the request being
+canceled (provided that some sort of transport or network layer
+security association, as described in Section 26.2.1, is in place).
+When a UAC receives a challenge, it SHOULD render to the user the
+contents of the "realm" parameter in the challenge (which appears in
+either a WWW-Authenticate header field or Proxy-Authenticate header
+field) if the UAC device does not already know of a credential for
+the realm in question.  A service provider that pre-configures UAs
+with credentials for its realm should be aware that users will not
+have the opportunity to present their own credentials for this realm
+when challenged at a pre-configured device.
+Finally, note that even if a UAC can locate credentials that are
+associated with the proper realm, the potential exists that these
+credentials may no longer be valid or that the challenging server
+will not accept these credentials for whatever reason (especially
+when "anonymous" with no password is submitted).  In this instance a
+server may repeat its challenge, or it may respond with a 403
+Forbidden.  A UAC MUST NOT re-attempt requests with the credentials
+that have just been rejected (though the request may be retried if
+the nonce was stale).
+22.2 User-to-User Authentication
+When a UAS receives a request from a UAC, the UAS MAY authenticate
+the originator before the request is processed.  If no credentials
+(in the Authorization header field) are provided in the request, the
+UAS can challenge the originator to provide credentials by rejecting
+the request with a 401 (Unauthorized) status code.
+The WWW-Authenticate response-header field MUST be included in 401
+(Unauthorized) response messages.  The field value consists of at
+least one challenge that indicates the authentication scheme(s) and
+parameters applicable to the realm.
+Rosenberg, et. al.          Standards Track                   [Page 195]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+An example of the WWW-Authenticate header field in a 401 challenge
+is:
+WWW-Authenticate: Digest
+realm="biloxi.com",
+qop="auth,auth-int",
+nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
+opaque="5ccc069c403ebaf9f0171e9517f40e41"
+When the originating UAC receives the 401 (Unauthorized), it SHOULD,
+if it is able, re-originate the request with the proper credentials.
+The UAC may require input from the originating user before
+proceeding.  Once authentication credentials have been supplied
+(either directly by the user, or discovered in an internal keyring),
+UAs SHOULD cache the credentials for a given value of the To header
+field and "realm" and attempt to re-use these values on the next
+request for that destination.  UAs MAY cache credentials in any way
+they would like.
+If no credentials for a realm can be located, UACs MAY attempt to
+retry the request with a username of "anonymous" and no password (a
+password of "").
+Once credentials have been located, any UA that wishes to
+authenticate itself with a UAS or registrar -- usually, but not
+necessarily, after receiving a 401 (Unauthorized) response -- MAY do
+so by including an Authorization header field with the request.  The
+Authorization field value consists of credentials containing the
+authentication information of the UA for the realm of the resource
+being requested as well as parameters required in support of
+authentication and replay protection.
+An example of the Authorization header field is:
+Authorization: Digest username="bob",
+realm="biloxi.com",
+nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
+uri="sip:bob@biloxi.com",
+qop=auth,
+nc=00000001,
+cnonce="0a4f113b",
+response="6629fae49393a05397450978507c4ef1",
+opaque="5ccc069c403ebaf9f0171e9517f40e41"
+When a UAC resubmits a request with its credentials after receiving a
+401 (Unauthorized) or 407 (Proxy Authentication Required) response,
+it MUST increment the CSeq header field value as it would normally
+when sending an updated request.
+Rosenberg, et. al.          Standards Track                   [Page 196]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+22.3 Proxy-to-User Authentication
+Similarly, when a UAC sends a request to a proxy server, the proxy
+server MAY authenticate the originator before the request is
+processed.  If no credentials (in the Proxy-Authorization header
+field) are provided in the request, the proxy can challenge the
+originator to provide credentials by rejecting the request with a 407
+(Proxy Authentication Required) status code.  The proxy MUST populate
+the 407 (Proxy Authentication Required) message with a Proxy-
+Authenticate header field value applicable to the proxy for the
+requested resource.
+The use of Proxy-Authenticate and Proxy-Authorization parallel that
+described in [17], with one difference.  Proxies MUST NOT add values
+to the Proxy-Authorization header field.  All 407 (Proxy
+Authentication Required) responses MUST be forwarded upstream toward
+the UAC following the procedures for any other response.  It is the
+UAC's responsibility to add the Proxy-Authorization header field
+value containing credentials for the realm of the proxy that has
+asked for authentication.
+If a proxy were to resubmit a request adding a Proxy-Authorization
+header field value, it would need to increment the CSeq in the new
+request.  However, this would cause the UAC that submitted the
+original request to discard a response from the UAS, as the CSeq
+value would be different.
+When the originating UAC receives the 407 (Proxy Authentication
+Required) it SHOULD, if it is able, re-originate the request with the
+proper credentials.  It should follow the same procedures for the
+display of the "realm" parameter that are given above for responding
+to 401.
+If no credentials for a realm can be located, UACs MAY attempt to
+retry the request with a username of "anonymous" and no password (a
+password of "").
+The UAC SHOULD also cache the credentials used in the re-originated
+request.
+The following rule is RECOMMENDED for proxy credential caching:
+If a UA receives a Proxy-Authenticate header field value in a 401/407
+response to a request with a particular Call-ID, it should
+incorporate credentials for that realm in all subsequent requests
+that contain the same Call-ID.  These credentials MUST NOT be cached
+across dialogs; however, if a UA is configured with the realm of its
+local outbound proxy, when one exists, then the UA MAY cache
+Rosenberg, et. al.          Standards Track                   [Page 197]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+credentials for that realm across dialogs.  Note that this does mean
+a future request in a dialog could contain credentials that are not
+needed by any proxy along the Route header path.
+Any UA that wishes to authenticate itself to a proxy server --
+usually, but not necessarily, after receiving a 407 (Proxy
+Authentication Required) response -- MAY do so by including a Proxy-
+Authorization header field value with the request.  The Proxy-
+Authorization request-header field allows the client to identify
+itself (or its user) to a proxy that requires authentication.  The
+Proxy-Authorization header field value consists of credentials
+containing the authentication information of the UA for the proxy
+and/or realm of the resource being requested.
+A Proxy-Authorization header field value applies only to the proxy
+whose realm is identified in the "realm" parameter (this proxy may
+previously have demanded authentication using the Proxy-Authenticate
+field).  When multiple proxies are used in a chain, a Proxy-
+Authorization header field value MUST NOT be consumed by any proxy
+whose realm does not match the "realm" parameter specified in that
+value.
+Note that if an authentication scheme that does not support realms is
+used in the Proxy-Authorization header field, a proxy server MUST
+attempt to parse all Proxy-Authorization header field values to
+determine whether one of them has what the proxy server considers to
+be valid credentials.  Because this is potentially very time-
+consuming in large networks, proxy servers SHOULD use an
+authentication scheme that supports realms in the Proxy-Authorization
+header field.
+If a request is forked (as described in Section 16.7), various proxy
+servers and/or UAs may wish to challenge the UAC.  In this case, the
+forking proxy server is responsible for aggregating these challenges
+into a single response.  Each WWW-Authenticate and Proxy-Authenticate
+value received in responses to the forked request MUST be placed into
+the single response that is sent by the forking proxy to the UA; the
+ordering of these header field values is not significant.
+When a proxy server issues a challenge in response to a request,
+it will not proxy the request until the UAC has retried the
+request with valid credentials.  A forking proxy may forward a
+request simultaneously to multiple proxy servers that require
+authentication, each of which in turn will not forward the request
+until the originating UAC has authenticated itself in their
+respective realm.  If the UAC does not provide credentials for
+Rosenberg, et. al.          Standards Track                   [Page 198]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+each challenge, the proxy servers that issued the challenges will
+not forward requests to the UA where the destination user might be
+located, and therefore, the virtues of forking are largely lost.
+When resubmitting its request in response to a 401 (Unauthorized) or
+407 (Proxy Authentication Required) that contains multiple
+challenges, a UAC MAY include an Authorization value for each WWW-
+Authenticate value and a Proxy-Authorization value for each Proxy-
+Authenticate value for which the UAC wishes to supply a credential.
+As noted above, multiple credentials in a request SHOULD be
+differentiated by the "realm" parameter.
+It is possible for multiple challenges associated with the same realm
+to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication
+Required).  This can occur, for example, when multiple proxies within
+the same administrative domain, which use a common realm, are reached
+by a forking request.  When it retries a request, a UAC MAY therefore
+supply multiple credentials in Authorization or Proxy-Authorization
+header fields with the same "realm" parameter value.  The same
+credentials SHOULD be used for the same realm.
+22.4 The Digest Authentication Scheme
+This section describes the modifications and clarifications required
+to apply the HTTP Digest authentication scheme to SIP.  The SIP
+scheme usage is almost completely identical to that for HTTP [17].
+Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [39],
+SIP servers supporting RFC 2617 MUST ensure they are backwards
+compatible with RFC 2069.  Procedures for this backwards
+compatibility are specified in RFC 2617.  Note, however, that SIP
+servers MUST NOT accept or request Basic authentication.
+The rules for Digest authentication follow those defined in [17],
+with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following
+differences:
+1.  The URI included in the challenge has the following BNF:
+URI  =  SIP-URI / SIPS-URI
+2.  The BNF in RFC 2617 has an error in that the 'uri' parameter
+of the Authorization header field for HTTP Digest
+Rosenberg, et. al.          Standards Track                   [Page 199]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+authentication is not enclosed in quotation marks.  (The
+example in Section 3.5 of RFC 2617 is correct.)  For SIP, the
+'uri' MUST be enclosed in quotation marks.
+3.  The BNF for digest-uri-value is:
+digest-uri-value  =  Request-URI ; as defined in Section 25
+4.  The example procedure for choosing a nonce based on Etag does
+not work for SIP.
+5.  The text in RFC 2617 [17] regarding cache operation does not
+apply to SIP.
+6.  RFC 2617 [17] requires that a server check that the URI in the
+request line and the URI included in the Authorization header
+field point to the same resource.  In a SIP context, these two
+URIs may refer to different users, due to forwarding at some
+proxy.  Therefore, in SIP, a server MAY check that the
+Request-URI in the Authorization header field value
+corresponds to a user for whom the server is willing to accept
+forwarded or direct requests, but it is not necessarily a
+failure if the two fields are not equivalent.
+7.  As a clarification to the calculation of the A2 value for
+message integrity assurance in the Digest authentication
+scheme, implementers should assume, when the entity-body is
+empty (that is, when SIP messages have no body) that the hash
+of the entity-body resolves to the MD5 hash of an empty
+string, or:
+H(entity-body) = MD5("") =
+"d41d8cd98f00b204e9800998ecf8427e"
+8.  RFC 2617 notes that a cnonce value MUST NOT be sent in an
+Authorization (and by extension Proxy-Authorization) header
+field if no qop directive has been sent.  Therefore, any
+algorithms that have a dependency on the cnonce (including
+"MD5-Sess") require that the qop directive be sent.  Use of
+the "qop" parameter is optional in RFC 2617 for the purposes
+of backwards compatibility with RFC 2069; since RFC 2543 was
+based on RFC 2069, the "qop" parameter must unfortunately
+remain optional for clients and servers to receive.  However,
+servers MUST always send a "qop" parameter in WWW-Authenticate
+and Proxy-Authenticate header field values.  If a client
+receives a "qop" parameter in a challenge header field, it
+MUST send the "qop" parameter in any resulting authorization
+header field.
+Rosenberg, et. al.          Standards Track                   [Page 200]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+RFC 2543 did not allow usage of the Authentication-Info header field
+(it effectively used RFC 2069).  However, we now allow usage of this
+header field, since it provides integrity checks over the bodies and
+provides mutual authentication.  RFC 2617 [17] defines mechanisms for
+backwards compatibility using the qop attribute in the request.
+These mechanisms MUST be used by a server to determine if the client
+supports the new mechanisms in RFC 2617 that were not specified in
+RFC 2069.
+23 S/MIME
+SIP messages carry MIME bodies and the MIME standard includes
+mechanisms for securing MIME contents to ensure both integrity and
+confidentiality (including the 'multipart/signed' and
+'application/pkcs7-mime' MIME types, see RFC 1847 [22], RFC 2630 [23]
+and RFC 2633 [24]).  Implementers should note, however, that there
+may be rare network intermediaries (not typical proxy servers) that
+rely on viewing or modifying the bodies of SIP messages (especially
+SDP), and that secure MIME may prevent these sorts of intermediaries
+from functioning.
+This applies particularly to certain types of firewalls.
+The PGP mechanism for encrypting the header fields and bodies of
+SIP messages described in RFC 2543 has been deprecated.
+23.1 S/MIME Certificates
+The certificates that are used to identify an end-user for the
+purposes of S/MIME differ from those used by servers in one important
+respect - rather than asserting that the identity of the holder
+corresponds to a particular hostname, these certificates assert that
+the holder is identified by an end-user address.  This address is
+composed of the concatenation of the "userinfo" "@" and "domainname"
+portions of a SIP or SIPS URI (in other words, an email address of
+the form "bob@biloxi.com"), most commonly corresponding to a user's
+address-of-record.
+These certificates are also associated with keys that are used to
+sign or encrypt bodies of SIP messages.  Bodies are signed with the
+private key of the sender (who may include their public key with the
+message as appropriate), but bodies are encrypted with the public key
+of the intended recipient.  Obviously, senders must have
+foreknowledge of the public key of recipients in order to encrypt
+message bodies.  Public keys can be stored within a UA on a virtual
+keyring.
+Rosenberg, et. al.          Standards Track                   [Page 201]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Each user agent that supports S/MIME MUST contain a keyring
+specifically for end-users' certificates.  This keyring should map
+between addresses of record and corresponding certificates.  Over
+time, users SHOULD use the same certificate when they populate the
+originating URI of signaling (the From header field) with the same
+address-of-record.
+Any mechanisms depending on the existence of end-user certificates
+are seriously limited in that there is virtually no consolidated
+authority today that provides certificates for end-user applications.
+However, users SHOULD acquire certificates from known public
+certificate authorities.  As an alternative, users MAY create self-
+signed certificates.  The implications of self-signed certificates
+are explored further in Section 26.4.2.  Implementations may also use
+pre-configured certificates in deployments in which a previous trust
+relationship exists between all SIP entities.
+Above and beyond the problem of acquiring an end-user certificate,
+there are few well-known centralized directories that distribute
+end-user certificates.  However, the holder of a certificate SHOULD
+publish their certificate in any public directories as appropriate.
+Similarly, UACs SHOULD support a mechanism for importing (manually or
+automatically) certificates discovered in public directories
+corresponding to the target URIs of SIP requests.
+23.2 S/MIME Key Exchange
+SIP itself can also be used as a means to distribute public keys in
+the following manner.
+Whenever the CMS SignedData message is used in S/MIME for SIP, it
+MUST contain the certificate bearing the public key necessary to
+verify the signature.
+When a UAC sends a request containing an S/MIME body that initiates a
+dialog, or sends a non-INVITE request outside the context of a
+dialog, the UAC SHOULD structure the body as an S/MIME
+'multipart/signed' CMS SignedData body.  If the desired CMS service
+is EnvelopedData (and the public key of the target user is known),
+the UAC SHOULD send the EnvelopedData message encapsulated within a
+SignedData message.
+When a UAS receives a request containing an S/MIME CMS body that
+includes a certificate, the UAS SHOULD first validate the
+certificate, if possible, with any available root certificates for
+certificate authorities.  The UAS SHOULD also determine the subject
+of the certificate (for S/MIME, the SubjectAltName will contain the
+appropriate identity) and compare this value to the From header field
+Rosenberg, et. al.          Standards Track                   [Page 202]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+of the request.  If the certificate cannot be verified, because it is
+self-signed, or signed by no known authority, or if it is verifiable
+but its subject does not correspond to the From header field of
+request, the UAS MUST notify its user of the status of the
+certificate (including the subject of the certificate, its signer,
+and any key fingerprint information) and request explicit permission
+before proceeding.  If the certificate was successfully verified and
+the subject of the certificate corresponds to the From header field
+of the SIP request, or if the user (after notification) explicitly
+authorizes the use of the certificate, the UAS SHOULD add this
+certificate to a local keyring, indexed by the address-of-record of
+the holder of the certificate.
+When a UAS sends a response containing an S/MIME body that answers
+the first request in a dialog, or a response to a non-INVITE request
+outside the context of a dialog, the UAS SHOULD structure the body as
+an S/MIME 'multipart/signed' CMS SignedData body.  If the desired CMS
+service is EnvelopedData, the UAS SHOULD send the EnvelopedData
+message encapsulated within a SignedData message.
+When a UAC receives a response containing an S/MIME CMS body that
+includes a certificate, the UAC SHOULD first validate the
+certificate, if possible, with any appropriate root certificate.  The
+UAC SHOULD also determine the subject of the certificate and compare
+this value to the To field of the response; although the two may very
+well be different, and this is not necessarily indicative of a
+security breach.  If the certificate cannot be verified because it is
+self-signed, or signed by no known authority, the UAC MUST notify its
+user of the status of the certificate (including the subject of the
+certificate, its signator, and any key fingerprint information) and
+request explicit permission before proceeding.  If the certificate
+was successfully verified, and the subject of the certificate
+corresponds to the To header field in the response, or if the user
+(after notification) explicitly authorizes the use of the
+certificate, the UAC SHOULD add this certificate to a local keyring,
+indexed by the address-of-record of the holder of the certificate.
+If the UAC had not transmitted its own certificate to the UAS in any
+previous transaction, it SHOULD use a CMS SignedData body for its
+next request or response.
+On future occasions, when the UA receives requests or responses that
+contain a From header field corresponding to a value in its keyring,
+the UA SHOULD compare the certificate offered in these messages with
+the existing certificate in its keyring.  If there is a discrepancy,
+the UA MUST notify its user of a change of the certificate
+(preferably in terms that indicate that this is a potential security
+breach) and acquire the user's permission before continuing to
+Rosenberg, et. al.          Standards Track                   [Page 203]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+process the signaling.  If the user authorizes this certificate, it
+SHOULD be added to the keyring alongside any previous value(s) for
+this address-of-record.
+Note well however, that this key exchange mechanism does not
+guarantee the secure exchange of keys when self-signed certificates,
+or certificates signed by an obscure authority, are used - it is
+vulnerable to well-known attacks.  In the opinion of the authors,
+however, the security it provides is proverbially better than
+nothing; it is in fact comparable to the widely used SSH application.
+These limitations are explored in greater detail in Section 26.4.2.
+If a UA receives an S/MIME body that has been encrypted with a public
+key unknown to the recipient, it MUST reject the request with a 493
+(Undecipherable) response.  This response SHOULD contain a valid
+certificate for the respondent (corresponding, if possible, to any
+address of record given in the To header field of the rejected
+request) within a MIME body with a 'certs-only' "smime-type"
+parameter.
+A 493 (Undecipherable) sent without any certificate indicates that
+the respondent cannot or will not utilize S/MIME encrypted messages,
+though they may still support S/MIME signatures.
+Note that a user agent that receives a request containing an S/MIME
+body that is not optional (with a Content-Disposition header
+"handling" parameter of "required") MUST reject the request with a
+415 Unsupported Media Type response if the MIME type is not
+understood.  A user agent that receives such a response when S/MIME
+is sent SHOULD notify its user that the remote device does not
+support S/MIME, and it MAY subsequently resend the request without
+S/MIME, if appropriate; however, this 415 response may constitute a
+downgrade attack.
+If a user agent sends an S/MIME body in a request, but receives a
+response that contains a MIME body that is not secured, the UAC
+SHOULD notify its user that the session could not be secured.
+However, if a user agent that supports S/MIME receives a request with
+an unsecured body, it SHOULD NOT respond with a secured body, but if
+it expects S/MIME from the sender (for example, because the sender's
+From header field value corresponds to an identity on its keychain),
+the UAS SHOULD notify its user that the session could not be secured.
+A number of conditions that arise in the previous text call for the
+notification of the user when an anomalous certificate-management
+event occurs.  Users might well ask what they should do under these
+circumstances.  First and foremost, an unexpected change in a
+certificate, or an absence of security when security is expected, are
+Rosenberg, et. al.          Standards Track                   [Page 204]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+causes for caution but not necessarily indications that an attack is
+in progress.  Users might abort any connection attempt or refuse a
+connection request they have received; in telephony parlance, they
+could hang up and call back.  Users may wish to find an alternate
+means to contact the other party and confirm that their key has
+legitimately changed.  Note that users are sometimes compelled to
+change their certificates, for example when they suspect that the
+secrecy of their private key has been compromised.  When their
+private key is no longer private, users must legitimately generate a
+new key and re-establish trust with any users that held their old
+key.
+Finally, if during the course of a dialog a UA receives a certificate
+in a CMS SignedData message that does not correspond with the
+certificates previously exchanged during a dialog, the UA MUST notify
+its user of the change, preferably in terms that indicate that this
+is a potential security breach.
+23.3 Securing MIME bodies
+There are two types of secure MIME bodies that are of interest to
+SIP: use of these bodies should follow the S/MIME specification [24]
+with a few variations.
+o  "multipart/signed" MUST be used only with CMS detached
+signatures.
+This allows backwards compatibility with non-S/MIME-
+compliant recipients.
+o  S/MIME bodies SHOULD have a Content-Disposition header field,
+and the value of the "handling" parameter SHOULD be "required."
+o  If a UAC has no certificate on its keyring associated with the
+address-of-record to which it wants to send a request, it
+cannot send an encrypted "application/pkcs7-mime" MIME message.
+UACs MAY send an initial request such as an OPTIONS message
+with a CMS detached signature in order to solicit the
+certificate of the remote side (the signature SHOULD be over a
+"message/sip" body of the type described in Section 23.4).
+Note that future standardization work on S/MIME may define
+non-certificate based keys.
+o  Senders of S/MIME bodies SHOULD use the "SMIMECapabilities"
+(see Section 2.5.2 of [24]) attribute to express their
+capabilities and preferences for further communications.  Note
+especially that senders MAY use the "preferSignedData"
+Rosenberg, et. al.          Standards Track                   [Page 205]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+capability to encourage receivers to respond with CMS
+SignedData messages (for example, when sending an OPTIONS
+request as described above).
+o  S/MIME implementations MUST at a minimum support SHA1 as a
+digital signature algorithm, and 3DES as an encryption
+algorithm.  All other signature and encryption algorithms MAY
+be supported.  Implementations can negotiate support for these
+algorithms with the "SMIMECapabilities" attribute.
+o  Each S/MIME body in a SIP message SHOULD be signed with only
+one certificate.  If a UA receives a message with multiple
+signatures, the outermost signature should be treated as the
+single certificate for this body.  Parallel signatures SHOULD
+NOT be used.
+The following is an example of an encrypted S/MIME SDP body
+within a SIP message:
+INVITE sip:bob@biloxi.com SIP/2.0
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+To: Bob <sip:bob@biloxi.com>
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Max-Forwards: 70
+Contact: <sip:alice@pc33.atlanta.com>
+Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
+name=smime.p7m
+Content-Disposition: attachment; filename=smime.p7m
+handling=required
+*******************************************************
+* Content-Type: application/sdp                       *
+*                                                     *
+* v=0                                                 *
+* o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com *
+* s=-                                                 *
+* t=0 0                                               *
+* c=IN IP4 pc33.atlanta.com                           *
+* m=audio 3456 RTP/AVP 0 1 3 99                       *
+* a=rtpmap:0 PCMU/8000                                *
+*******************************************************
+Rosenberg, et. al.          Standards Track                   [Page 206]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP
+As a means of providing some degree of end-to-end authentication,
+integrity or confidentiality for SIP header fields, S/MIME can
+encapsulate entire SIP messages within MIME bodies of type
+"message/sip" and then apply MIME security to these bodies in the
+same manner as typical SIP bodies.  These encapsulated SIP requests
+and responses do not constitute a separate dialog or transaction,
+they are a copy of the "outer" message that is used to verify
+integrity or to supply additional information.
+If a UAS receives a request that contains a tunneled "message/sip"
+S/MIME body, it SHOULD include a tunneled "message/sip" body in the
+response with the same smime-type.
+Any traditional MIME bodies (such as SDP) SHOULD be attached to the
+"inner" message so that they can also benefit from S/MIME security.
+Note that "message/sip" bodies can be sent as a part of a MIME
+"multipart/mixed" body if any unsecured MIME types should also be
+transmitted in a request.
+23.4.1 Integrity and Confidentiality Properties of SIP Headers
+When the S/MIME integrity or confidentiality mechanisms are used,
+there may be discrepancies between the values in the "inner" message
+and values in the "outer" message.  The rules for handling any such
+differences for all of the header fields described in this document
+are given in this section.
+Note that for the purposes of loose timestamping, all SIP messages
+that tunnel "message/sip" SHOULD contain a Date header in both the
+"inner" and "outer" headers.
+23.4.1.1 Integrity
+Whenever integrity checks are performed, the integrity of a header
+field should be determined by matching the value of the header field
+in the signed body with that in the "outer" messages using the
+comparison rules of SIP as described in 20.
+Header fields that can be legitimately modified by proxy servers are:
+Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy-
+Authorization.  If these header fields are not intact end-to-end,
+implementations SHOULD NOT consider this a breach of security.
+Changes to any other header fields defined in this document
+constitute an integrity violation; users MUST be notified of a
+discrepancy.
+Rosenberg, et. al.          Standards Track                   [Page 207]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+23.4.1.2 Confidentiality
+When messages are encrypted, header fields may be included in the
+encrypted body that are not present in the "outer" message.
+Some header fields must always have a plaintext version because they
+are required header fields in requests and responses - these include:
+To, From, Call-ID, CSeq, Contact.  While it is probably not useful to
+provide an encrypted alternative for the Call-ID, CSeq, or Contact,
+providing an alternative to the information in the "outer" To or From
+is permitted.  Note that the values in an encrypted body are not used
+for the purposes of identifying transactions or dialogs - they are
+merely informational.  If the From header field in an encrypted body
+differs from the value in the "outer" message, the value within the
+encrypted body SHOULD be displayed to the user, but MUST NOT be used
+in the "outer" header fields of any future messages.
+Primarily, a user agent will want to encrypt header fields that have
+an end-to-end semantic, including: Subject, Reply-To, Organization,
+Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info,
+Authentication-Info, Expires, In-Reply-To, Require, Supported,
+Unsupported, Retry-After, User-Agent, Server, and Warning.  If any of
+these header fields are present in an encrypted body, they should be
+used instead of any "outer" header fields, whether this entails
+displaying the header field values to users or setting internal
+states in the UA.  They SHOULD NOT however be used in the "outer"
+headers of any future messages.
+If present, the Date header field MUST always be the same in the
+"inner" and "outer" headers.
+Since MIME bodies are attached to the "inner" message,
+implementations will usually encrypt MIME-specific header fields,
+including: MIME-Version, Content-Type, Content-Length, Content-
+Language, Content-Encoding and Content-Disposition.  The "outer"
+message will have the proper MIME header fields for S/MIME bodies.
+These header fields (and any MIME bodies they preface) should be
+treated as normal MIME header fields and bodies received in a SIP
+message.
+It is not particularly useful to encrypt the following header fields:
+Min-Expires, Timestamp, Authorization, Priority, and WWW-
+Authenticate.  This category also includes those header fields that
+can be changed by proxy servers (described in the preceding section).
+UAs SHOULD never include these in an "inner" message if they are not
+Rosenberg, et. al.          Standards Track                   [Page 208]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+included in the "outer" message.  UAs that receive any of these
+header fields in an encrypted body SHOULD ignore the encrypted
+values.
+Note that extensions to SIP may define additional header fields; the
+authors of these extensions should describe the integrity and
+confidentiality properties of such header fields.  If a SIP UA
+encounters an unknown header field with an integrity violation, it
+MUST ignore the header field.
+23.4.2 Tunneling Integrity and Authentication
+Tunneling SIP messages within S/MIME bodies can provide integrity for
+SIP header fields if the header fields that the sender wishes to
+secure are replicated in a "message/sip" MIME body signed with a CMS
+detached signature.
+Provided that the "message/sip" body contains at least the
+fundamental dialog identifiers (To, From, Call-ID, CSeq), then a
+signed MIME body can provide limited authentication.  At the very
+least, if the certificate used to sign the body is unknown to the
+recipient and cannot be verified, the signature can be used to
+ascertain that a later request in a dialog was transmitted by the
+same certificate-holder that initiated the dialog.  If the recipient
+of the signed MIME body has some stronger incentive to trust the
+certificate (they were able to validate it, they acquired it from a
+trusted repository, or they have used it frequently) then the
+signature can be taken as a stronger assertion of the identity of the
+subject of the certificate.
+In order to eliminate possible confusions about the addition or
+subtraction of entire header fields, senders SHOULD replicate all
+header fields from the request within the signed body.  Any message
+bodies that require integrity protection MUST be attached to the
+"inner" message.
+If a Date header is present in a message with a signed body, the
+recipient SHOULD compare the header field value with its own internal
+clock, if applicable.  If a significant time discrepancy is detected
+(on the order of an hour or more), the user agent SHOULD alert the
+user to the anomaly, and note that it is a potential security breach.
+If an integrity violation in a message is detected by its recipient,
+the message MAY be rejected with a 403 (Forbidden) response if it is
+a request, or any existing dialog MAY be terminated.  UAs SHOULD
+notify users of this circumstance and request explicit guidance on
+how to proceed.
+Rosenberg, et. al.          Standards Track                   [Page 209]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The following is an example of the use of a tunneled "message/sip"
+body:
+INVITE sip:bob@biloxi.com SIP/2.0
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+To: Bob <sip:bob@biloxi.com>
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Max-Forwards: 70
+Date: Thu, 21 Feb 2002 13:02:03 GMT
+Contact: <sip:alice@pc33.atlanta.com>
+Content-Type: multipart/signed;
+protocol="application/pkcs7-signature";
+micalg=sha1; boundary=boundary42
+Content-Length: 568
+--boundary42
+Content-Type: message/sip
+INVITE sip:bob@biloxi.com SIP/2.0
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+To: Bob <bob@biloxi.com>
+From: Alice <alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Max-Forwards: 70
+Date: Thu, 21 Feb 2002 13:02:03 GMT
+Contact: <sip:alice@pc33.atlanta.com>
+Content-Type: application/sdp
+Content-Length: 147
+v=0
+o=UserA 2890844526 2890844526 IN IP4 here.com
+s=Session SDP
+c=IN IP4 pc33.atlanta.com
+t=0 0
+m=audio 49172 RTP/AVP 0
+a=rtpmap:0 PCMU/8000
+--boundary42
+Content-Type: application/pkcs7-signature; name=smime.p7s
+Content-Transfer-Encoding: base64
+Content-Disposition: attachment; filename=smime.p7s;
+handling=required
+Rosenberg, et. al.          Standards Track                   [Page 210]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
+4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
+n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
+7GhIGfHfYT64VQbnj756
+--boundary42-
+23.4.3 Tunneling Encryption
+It may also be desirable to use this mechanism to encrypt a
+"message/sip" MIME body within a CMS EnvelopedData message S/MIME
+body, but in practice, most header fields are of at least some use to
+the network; the general use of encryption with S/MIME is to secure
+message bodies like SDP rather than message headers.  Some
+informational header fields, such as the Subject or Organization
+could perhaps warrant end-to-end security.  Headers defined by future
+SIP applications might also require obfuscation.
+Another possible application of encrypting header fields is selective
+anonymity.  A request could be constructed with a From header field
+that contains no personal information (for example,
+sip:anonymous@anonymizer.invalid).  However, a second From header
+field containing the genuine address-of-record of the originator
+could be encrypted within a "message/sip" MIME body where it will
+only be visible to the endpoints of a dialog.
+Note that if this mechanism is used for anonymity, the From header
+field will no longer be usable by the recipient of a message as an
+index to their certificate keychain for retrieving the proper
+S/MIME key to associated with the sender.  The message must first
+be decrypted, and the "inner" From header field MUST be used as an
+index.
+In order to provide end-to-end integrity, encrypted "message/sip"
+MIME bodies SHOULD be signed by the sender.  This creates a
+"multipart/signed" MIME body that contains an encrypted body and a
+signature, both of type "application/pkcs7-mime".
+Rosenberg, et. al.          Standards Track                   [Page 211]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+In the following example, of an encrypted and signed message, the
+text boxed in asterisks ("*") is encrypted:
+INVITE sip:bob@biloxi.com SIP/2.0
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+To: Bob <sip:bob@biloxi.com>
+From: Anonymous <sip:anonymous@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Max-Forwards: 70
+Date: Thu, 21 Feb 2002 13:02:03 GMT
+Contact: <sip:pc33.atlanta.com>
+Content-Type: multipart/signed;
+protocol="application/pkcs7-signature";
+micalg=sha1; boundary=boundary42
+Content-Length: 568
+--boundary42
+Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
+name=smime.p7m
+Content-Transfer-Encoding: base64
+Content-Disposition: attachment; filename=smime.p7m
+handling=required
+Content-Length: 231
+***********************************************************
+* Content-Type: message/sip                               *
+*                                                         *
+* INVITE sip:bob@biloxi.com SIP/2.0                       *
+* Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 *
+* To: Bob <bob@biloxi.com>                                *
+* From: Alice <alice@atlanta.com>;tag=1928301774          *
+* Call-ID: a84b4c76e66710                                 *
+* CSeq: 314159 INVITE                                     *
+* Max-Forwards: 70                                        *
+* Date: Thu, 21 Feb 2002 13:02:03 GMT                     *
+* Contact: <sip:alice@pc33.atlanta.com>                   *
+*                                                         *
+* Content-Type: application/sdp                           *
+*                                                         *
+* v=0                                                     *
+* o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com     *
+* s=Session SDP                                           *
+* t=0 0                                                   *
+* c=IN IP4 pc33.atlanta.com                               *
+* m=audio 3456 RTP/AVP 0 1 3 99                           *
+* a=rtpmap:0 PCMU/8000                                    *
+***********************************************************
+Rosenberg, et. al.          Standards Track                   [Page 212]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+--boundary42
+Content-Type: application/pkcs7-signature; name=smime.p7s
+Content-Transfer-Encoding: base64
+Content-Disposition: attachment; filename=smime.p7s;
+handling=required
+ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
+4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
+n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
+7GhIGfHfYT64VQbnj756
+--boundary42-
+24 Examples
+In the following examples, we often omit the message body and the
+corresponding Content-Length and Content-Type header fields for
+brevity.
+24.1 Registration
+Bob registers on start-up.  The message flow is shown in Figure 9.
+Note that the authentication usually required for registration is not
+shown for simplicity.
+biloxi.com         Bob's
+registrar       softphone
+|                |
+|   REGISTER F1  |
+|<---------------|
+|    200 OK F2   |
+|--------------->|
+Figure 9: SIP Registration Example
+F1 REGISTER Bob -> Registrar
+REGISTER sip:registrar.biloxi.com SIP/2.0
+Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
+Max-Forwards: 70
+To: Bob <sip:bob@biloxi.com>
+From: Bob <sip:bob@biloxi.com>;tag=456248
+Call-ID: 843817637684230@998sdasdh09
+CSeq: 1826 REGISTER
+Contact: <sip:bob@192.0.2.4>
+Expires: 7200
+Content-Length: 0
+Rosenberg, et. al.          Standards Track                   [Page 213]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The registration expires after two hours.  The registrar responds
+with a 200 OK:
+F2 200 OK Registrar -> Bob
+SIP/2.0 200 OK
+Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
+;received=192.0.2.4
+To: Bob <sip:bob@biloxi.com>;tag=2493k59kd
+From: Bob <sip:bob@biloxi.com>;tag=456248
+Call-ID: 843817637684230@998sdasdh09
+CSeq: 1826 REGISTER
+Contact: <sip:bob@192.0.2.4>
+Expires: 7200
+Content-Length: 0
+24.2 Session Setup
+This example contains the full details of the example session setup
+in Section 4.  The message flow is shown in Figure 1.  Note that
+these flows show the minimum required set of header fields - some
+other header fields such as Allow and Supported would normally be
+present.
+F1 INVITE Alice -> atlanta.com proxy
+INVITE sip:bob@biloxi.com SIP/2.0
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+Max-Forwards: 70
+To: Bob <sip:bob@biloxi.com>
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Contact: <sip:alice@pc33.atlanta.com>
+Content-Type: application/sdp
+Content-Length: 142
+(Alice's SDP not shown)
+Rosenberg, et. al.          Standards Track                   [Page 214]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+F2 100 Trying atlanta.com proxy -> Alice
+SIP/2.0 100 Trying
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+;received=192.0.2.1
+To: Bob <sip:bob@biloxi.com>
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Content-Length: 0
+F3 INVITE atlanta.com proxy -> biloxi.com proxy
+INVITE sip:bob@biloxi.com SIP/2.0
+Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+;received=192.0.2.1
+Max-Forwards: 69
+To: Bob <sip:bob@biloxi.com>
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Contact: <sip:alice@pc33.atlanta.com>
+Content-Type: application/sdp
+Content-Length: 142
+(Alice's SDP not shown)
+F4 100 Trying biloxi.com proxy -> atlanta.com proxy
+SIP/2.0 100 Trying
+Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
+;received=192.0.2.2
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+;received=192.0.2.1
+To: Bob <sip:bob@biloxi.com>
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Content-Length: 0
+Rosenberg, et. al.          Standards Track                   [Page 215]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+F5 INVITE biloxi.com proxy -> Bob
+INVITE sip:bob@192.0.2.4 SIP/2.0
+Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
+Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
+;received=192.0.2.2
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+;received=192.0.2.1
+Max-Forwards: 68
+To: Bob <sip:bob@biloxi.com>
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Contact: <sip:alice@pc33.atlanta.com>
+Content-Type: application/sdp
+Content-Length: 142
+(Alice's SDP not shown)
+F6 180 Ringing Bob -> biloxi.com proxy
+SIP/2.0 180 Ringing
+Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
+;received=192.0.2.3
+Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
+;received=192.0.2.2
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+;received=192.0.2.1
+To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+Contact: <sip:bob@192.0.2.4>
+CSeq: 314159 INVITE
+Content-Length: 0
+F7 180 Ringing biloxi.com proxy -> atlanta.com proxy
+SIP/2.0 180 Ringing
+Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
+;received=192.0.2.2
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+;received=192.0.2.1
+To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+Contact: <sip:bob@192.0.2.4>
+CSeq: 314159 INVITE
+Content-Length: 0
+Rosenberg, et. al.          Standards Track                   [Page 216]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+F8 180 Ringing atlanta.com proxy -> Alice
+SIP/2.0 180 Ringing
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+;received=192.0.2.1
+To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+Contact: <sip:bob@192.0.2.4>
+CSeq: 314159 INVITE
+Content-Length: 0
+F9 200 OK Bob -> biloxi.com proxy
+SIP/2.0 200 OK
+Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
+;received=192.0.2.3
+Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
+;received=192.0.2.2
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+;received=192.0.2.1
+To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Contact: <sip:bob@192.0.2.4>
+Content-Type: application/sdp
+Content-Length: 131
+(Bob's SDP not shown)
+F10 200 OK biloxi.com proxy -> atlanta.com proxy
+SIP/2.0 200 OK
+Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
+;received=192.0.2.2
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+;received=192.0.2.1
+To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Contact: <sip:bob@192.0.2.4>
+Content-Type: application/sdp
+Content-Length: 131
+(Bob's SDP not shown)
+Rosenberg, et. al.          Standards Track                   [Page 217]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+F11 200 OK atlanta.com proxy -> Alice
+SIP/2.0 200 OK
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
+;received=192.0.2.1
+To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 INVITE
+Contact: <sip:bob@192.0.2.4>
+Content-Type: application/sdp
+Content-Length: 131
+(Bob's SDP not shown)
+F12 ACK Alice -> Bob
+ACK sip:bob@192.0.2.4 SIP/2.0
+Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
+Max-Forwards: 70
+To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+From: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 314159 ACK
+Content-Length: 0
+The media session between Alice and Bob is now established.
+Bob hangs up first.  Note that Bob's SIP phone maintains its own CSeq
+numbering space, which, in this example, begins with 231.  Since Bob
+is making the request, the To and From URIs and tags have been
+swapped.
+F13 BYE Bob -> Alice
+BYE sip:alice@pc33.atlanta.com SIP/2.0
+Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
+Max-Forwards: 70
+From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+To: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 231 BYE
+Content-Length: 0
+Rosenberg, et. al.          Standards Track                   [Page 218]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+F14 200 OK Alice -> Bob
+SIP/2.0 200 OK
+Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
+From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
+To: Alice <sip:alice@atlanta.com>;tag=1928301774
+Call-ID: a84b4c76e66710
+CSeq: 231 BYE
+Content-Length: 0
+The SIP Call Flows document [40] contains further examples of SIP
+messages.
+25  Augmented BNF for the SIP Protocol
+All of the mechanisms specified in this document are described in
+both prose and an augmented Backus-Naur Form (BNF) defined in RFC
+2234 [10].  Section 6.1 of RFC 2234 defines a set of core rules that
+are used by this specification, and not repeated here.  Implementers
+need to be familiar with the notation and content of RFC 2234 in
+order to understand this specification.  Certain basic rules are in
+uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc.  Angle
+brackets are used within definitions to clarify the use of rule
+names.
+The use of square brackets is redundant syntactically.  It is used as
+a semantic hint that the specific parameter is optional to use.
+25.1 Basic Rules
+The following rules are used throughout this specification to
+describe basic parsing constructs.  The US-ASCII coded character set
+is defined by ANSI X3.4-1986.
+alphanum  =  ALPHA / DIGIT
+Rosenberg, et. al.          Standards Track                   [Page 219]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Several rules are incorporated from RFC 2396 [5] but are updated to
+make them compliant with RFC 2234 [10].  These include:
+reserved    =  ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+"
+/ "$" / ","
+unreserved  =  alphanum / mark
+mark        =  "-" / "_" / "." / "!" / "~" / "*" / "'"
+/ "(" / ")"
+escaped     =  "%" HEXDIG HEXDIG
+SIP header field values can be folded onto multiple lines if the
+continuation line begins with a space or horizontal tab.  All linear
+white space, including folding, has the same semantics as SP.  A
+recipient MAY replace any linear white space with a single SP before
+interpreting the field value or forwarding the message downstream.
+This is intended to behave exactly as HTTP/1.1 as described in RFC
+2616 [8].  The SWS construct is used when linear white space is
+optional, generally between tokens and separators.
+LWS  =  [*WSP CRLF] 1*WSP ; linear whitespace
+SWS  =  [LWS] ; sep whitespace
+To separate the header name from the rest of value, a colon is used,
+which, by the above rule, allows whitespace before, but no line
+break, and whitespace after, including a linebreak.  The HCOLON
+defines this construct.
+HCOLON  =  *( SP / HTAB ) ":" SWS
+The TEXT-UTF8 rule is only used for descriptive field contents and
+values that are not intended to be interpreted by the message parser.
+Words of *TEXT-UTF8 contain characters from the UTF-8 charset (RFC
+2279 [7]).  The TEXT-UTF8-TRIM rule is used for descriptive field
+contents that are n t quoted strings, where leading and trailing LWS
+is not meaningful.  In this regard, SIP differs from HTTP, which uses
+the ISO 8859-1 character set.
+TEXT-UTF8-TRIM  =  1*TEXT-UTF8char *(*LWS TEXT-UTF8char)
+TEXT-UTF8char   =  %x21-7E / UTF8-NONASCII
+UTF8-NONASCII   =  %xC0-DF 1UTF8-CONT
+/  %xE0-EF 2UTF8-CONT
+/  %xF0-F7 3UTF8-CONT
+/  %xF8-Fb 4UTF8-CONT
+/  %xFC-FD 5UTF8-CONT
+UTF8-CONT       =  %x80-BF
+Rosenberg, et. al.          Standards Track                   [Page 220]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+A CRLF is allowed in the definition of TEXT-UTF8-TRIM only as part of
+a header field continuation.  It is expected that the folding LWS
+will be replaced with a single SP before interpretation of the TEXT-
+UTF8-TRIM value.
+Hexadecimal numeric characters are used in several protocol elements.
+Some elements (authentication) force hex alphas to be lower case.
+LHEX  =  DIGIT / %x61-66 ;lowercase a-f
+Many SIP header field values consist of words separated by LWS or
+special characters.  Unless otherwise stated, tokens are case-
+insensitive.  These special characters MUST be in a quoted string to
+be used within a parameter value.  The word construct is used in
+Call-ID to allow most separators to be used.
+token       =  1*(alphanum / "-" / "." / "!" / "%" / "*"
+/ "_" / "+" / "`" / "'" / "~" )
+separators  =  "(" / ")" / "<" / ">" / "@" /
+"," / ";" / ":" / "\" / DQUOTE /
+"/" / "[" / "]" / "?" / "=" /
+"{" / "}" / SP / HTAB
+word        =  1*(alphanum / "-" / "." / "!" / "%" / "*" /
+"_" / "+" / "`" / "'" / "~" /
+"(" / ")" / "<" / ">" /
+":" / "\" / DQUOTE /
+"/" / "[" / "]" / "?" /
+"{" / "}" )
+When tokens are used or separators are used between elements,
+whitespace is often allowed before or after these characters:
+STAR    =  SWS "*" SWS ; asterisk
+SLASH   =  SWS "/" SWS ; slash
+EQUAL   =  SWS "=" SWS ; equal
+LPAREN  =  SWS "(" SWS ; left parenthesis
+RPAREN  =  SWS ")" SWS ; right parenthesis
+RAQUOT  =  ">" SWS ; right angle quote
+LAQUOT  =  SWS "<"; left angle quote
+COMMA   =  SWS "," SWS ; comma
+SEMI    =  SWS ";" SWS ; semicolon
+COLON   =  SWS ":" SWS ; colon
+LDQUOT  =  SWS DQUOTE; open double quotation mark
+RDQUOT  =  DQUOTE SWS ; close double quotation mark
+Rosenberg, et. al.          Standards Track                   [Page 221]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Comments can be included in some SIP header fields by surrounding the
+comment text with parentheses.  Comments are only allowed in fields
+containing "comment" as part of their field value definition.  In all
+other fields, parentheses are considered part of the field value.
+comment  =  LPAREN *(ctext / quoted-pair / comment) RPAREN
+ctext    =  %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII
+/ LWS
+ctext includes all chars except left and right parens and backslash.
+A string of text is parsed as a single word if it is quoted using
+double-quote marks.  In quoted strings, quotation marks (") and
+backslashes (\) need to be escaped.
+quoted-string  =  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
+qdtext         =  LWS / %x21 / %x23-5B / %x5D-7E
+/ UTF8-NONASCII
+The backslash character ("\") MAY be used as a single-character
+quoting mechanism only within quoted-string and comment constructs.
+Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this
+mechanism to avoid conflict with line folding and header separation.
+quoted-pair  =  "\" (%x00-09 / %x0B-0C
+/ %x0E-7F)
+SIP-URI          =  "sip:" [ userinfo ] hostport
+uri-parameters [ headers ]
+SIPS-URI         =  "sips:" [ userinfo ] hostport
+uri-parameters [ headers ]
+userinfo         =  ( user / telephone-subscriber ) [ ":" password ] "@"
+user             =  1*( unreserved / escaped / user-unreserved )
+user-unreserved  =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
+password         =  *( unreserved / escaped /
+"&" / "=" / "+" / "$" / "," )
+hostport         =  host [ ":" port ]
+host             =  hostname / IPv4address / IPv6reference
+hostname         =  *( domainlabel "." ) toplabel [ "." ]
+domainlabel      =  alphanum
+/ alphanum *( alphanum / "-" ) alphanum
+toplabel         =  ALPHA / ALPHA *( alphanum / "-" ) alphanum
+Rosenberg, et. al.          Standards Track                   [Page 222]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+IPv4address    =  1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
+IPv6reference  =  "[" IPv6address "]"
+IPv6address    =  hexpart [ ":" IPv4address ]
+hexpart        =  hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]
+hexseq         =  hex4 *( ":" hex4)
+hex4           =  1*4HEXDIG
+port           =  1*DIGIT
+The BNF for telephone-subscriber can be found in RFC 2806 [9].  Note,
+however, that any characters allowed there that are not allowed in
+the user part of the SIP URI MUST be escaped.
+uri-parameters    =  *( ";" uri-parameter)
+uri-parameter     =  transport-param / user-param / method-param
+/ ttl-param / maddr-param / lr-param / other-param
+transport-param   =  "transport="
+( "udp" / "tcp" / "sctp" / "tls"
+/ other-transport)
+other-transport   =  token
+user-param        =  "user=" ( "phone" / "ip" / other-user)
+other-user        =  token
+method-param      =  "method=" Method
+ttl-param         =  "ttl=" ttl
+maddr-param       =  "maddr=" host
+lr-param          =  "lr"
+other-param       =  pname [ "=" pvalue ]
+pname             =  1*paramchar
+pvalue            =  1*paramchar
+paramchar         =  param-unreserved / unreserved / escaped
+param-unreserved  =  "[" / "]" / "/" / ":" / "&" / "+" / "$"
+headers         =  "?" header *( "&" header )
+header          =  hname "=" hvalue
+hname           =  1*( hnv-unreserved / unreserved / escaped )
+hvalue          =  *( hnv-unreserved / unreserved / escaped )
+hnv-unreserved  =  "[" / "]" / "/" / "?" / ":" / "+" / "$"
+SIP-message    =  Request / Response
+Request        =  Request-Line
+*( message-header )
+CRLF
+[ message-body ]
+Request-Line   =  Method SP Request-URI SP SIP-Version CRLF
+Request-URI    =  SIP-URI / SIPS-URI / absoluteURI
+absoluteURI    =  scheme ":" ( hier-part / opaque-part )
+hier-part      =  ( net-path / abs-path ) [ "?" query ]
+net-path       =  "//" authority [ abs-path ]
+abs-path       =  "/" path-segments
+Rosenberg, et. al.          Standards Track                   [Page 223]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+opaque-part    =  uric-no-slash *uric
+uric           =  reserved / unreserved / escaped
+uric-no-slash  =  unreserved / escaped / ";" / "?" / ":" / "@"
+/ "&" / "=" / "+" / "$" / ","
+path-segments  =  segment *( "/" segment )
+segment        =  *pchar *( ";" param )
+param          =  *pchar
+pchar          =  unreserved / escaped /
+":" / "@" / "&" / "=" / "+" / "$" / ","
+scheme         =  ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
+authority      =  srvr / reg-name
+srvr           =  [ [ userinfo "@" ] hostport ]
+reg-name       =  1*( unreserved / escaped / "$" / ","
+/ ";" / ":" / "@" / "&" / "=" / "+" )
+query          =  *uric
+SIP-Version    =  "SIP" "/" 1*DIGIT "." 1*DIGIT
+message-header  =  (Accept
+/  Accept-Encoding
+/  Accept-Language
+/  Alert-Info
+/  Allow
+/  Authentication-Info
+/  Authorization
+/  Call-ID
+/  Call-Info
+/  Contact
+/  Content-Disposition
+/  Content-Encoding
+/  Content-Language
+/  Content-Length
+/  Content-Type
+/  CSeq
+/  Date
+/  Error-Info
+/  Expires
+/  From
+/  In-Reply-To
+/  Max-Forwards
+/  MIME-Version
+/  Min-Expires
+/  Organization
+/  Priority
+/  Proxy-Authenticate
+/  Proxy-Authorization
+/  Proxy-Require
+/  Record-Route
+/  Reply-To
+Rosenberg, et. al.          Standards Track                   [Page 224]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+/  Require
+/  Retry-After
+/  Route
+/  Server
+/  Subject
+/  Supported
+/  Timestamp
+/  To
+/  Unsupported
+/  User-Agent
+/  Via
+/  Warning
+/  WWW-Authenticate
+/  extension-header) CRLF
+INVITEm           =  %x49.4E.56.49.54.45 ; INVITE in caps
+ACKm              =  %x41.43.4B ; ACK in caps
+OPTIONSm          =  %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps
+BYEm              =  %x42.59.45 ; BYE in caps
+CANCELm           =  %x43.41.4E.43.45.4C ; CANCEL in caps
+REGISTERm         =  %x52.45.47.49.53.54.45.52 ; REGISTER in caps
+Method            =  INVITEm / ACKm / OPTIONSm / BYEm
+/ CANCELm / REGISTERm
+/ extension-method
+extension-method  =  token
+Response          =  Status-Line
+*( message-header )
+CRLF
+[ message-body ]
+Status-Line     =  SIP-Version SP Status-Code SP Reason-Phrase CRLF
+Status-Code     =  Informational
+/   Redirection
+/   Success
+/   Client-Error
+/   Server-Error
+/   Global-Failure
+/   extension-code
+extension-code  =  3DIGIT
+Reason-Phrase   =  *(reserved / unreserved / escaped
+/ UTF8-NONASCII / UTF8-CONT / SP / HTAB)
+Informational  =  "100"  ;  Trying
+/   "180"  ;  Ringing
+/   "181"  ;  Call Is Being Forwarded
+/   "182"  ;  Queued
+/   "183"  ;  Session Progress
+Rosenberg, et. al.          Standards Track                   [Page 225]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Success  =  "200"  ;  OK
+Redirection  =  "300"  ;  Multiple Choices
+/   "301"  ;  Moved Permanently
+/   "302"  ;  Moved Temporarily
+/   "305"  ;  Use Proxy
+/   "380"  ;  Alternative Service
+Client-Error  =  "400"  ;  Bad Request
+/   "401"  ;  Unauthorized
+/   "402"  ;  Payment Required
+/   "403"  ;  Forbidden
+/   "404"  ;  Not Found
+/   "405"  ;  Method Not Allowed
+/   "406"  ;  Not Acceptable
+/   "407"  ;  Proxy Authentication Required
+/   "408"  ;  Request Timeout
+/   "410"  ;  Gone
+/   "413"  ;  Request Entity Too Large
+/   "414"  ;  Request-URI Too Large
+/   "415"  ;  Unsupported Media Type
+/   "416"  ;  Unsupported URI Scheme
+/   "420"  ;  Bad Extension
+/   "421"  ;  Extension Required
+/   "423"  ;  Interval Too Brief
+/   "480"  ;  Temporarily not available
+/   "481"  ;  Call Leg/Transaction Does Not Exist
+/   "482"  ;  Loop Detected
+/   "483"  ;  Too Many Hops
+/   "484"  ;  Address Incomplete
+/   "485"  ;  Ambiguous
+/   "486"  ;  Busy Here
+/   "487"  ;  Request Terminated
+/   "488"  ;  Not Acceptable Here
+/   "491"  ;  Request Pending
+/   "493"  ;  Undecipherable
+Server-Error  =  "500"  ;  Internal Server Error
+/   "501"  ;  Not Implemented
+/   "502"  ;  Bad Gateway
+/   "503"  ;  Service Unavailable
+/   "504"  ;  Server Time-out
+/   "505"  ;  SIP Version not supported
+/   "513"  ;  Message Too Large
+Rosenberg, et. al.          Standards Track                   [Page 226]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Global-Failure  =  "600"  ;  Busy Everywhere
+/   "603"  ;  Decline
+/   "604"  ;  Does not exist anywhere
+/   "606"  ;  Not Acceptable
+Accept         =  "Accept" HCOLON
+[ accept-range *(COMMA accept-range) ]
+accept-range   =  media-range *(SEMI accept-param)
+media-range    =  ( "*/*"
+/ ( m-type SLASH "*" )
+/ ( m-type SLASH m-subtype )
+) *( SEMI m-parameter )
+accept-param   =  ("q" EQUAL qvalue) / generic-param
+qvalue         =  ( "0" [ "." 0*3DIGIT ] )
+/ ( "1" [ "." 0*3("0") ] )
+generic-param  =  token [ EQUAL gen-value ]
+gen-value      =  token / host / quoted-string
+Accept-Encoding  =  "Accept-Encoding" HCOLON
+[ encoding *(COMMA encoding) ]
+encoding         =  codings *(SEMI accept-param)
+codings          =  content-coding / "*"
+content-coding   =  token
+Accept-Language  =  "Accept-Language" HCOLON
+[ language *(COMMA language) ]
+language         =  language-range *(SEMI accept-param)
+language-range   =  ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" )
+Alert-Info   =  "Alert-Info" HCOLON alert-param *(COMMA alert-param)
+alert-param  =  LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
+Allow  =  "Allow" HCOLON [Method *(COMMA Method)]
+Authorization     =  "Authorization" HCOLON credentials
+credentials       =  ("Digest" LWS digest-response)
+/ other-response
+digest-response   =  dig-resp *(COMMA dig-resp)
+dig-resp          =  username / realm / nonce / digest-uri
+/ dresponse / algorithm / cnonce
+/ opaque / message-qop
+/ nonce-count / auth-param
+username          =  "username" EQUAL username-value
+username-value    =  quoted-string
+digest-uri        =  "uri" EQUAL LDQUOT digest-uri-value RDQUOT
+digest-uri-value  =  rquest-uri ; Equal to request-uri as specified
+by HTTP/1.1
+message-qop       =  "qop" EQUAL qop-value
+Rosenberg, et. al.          Standards Track                   [Page 227]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+cnonce            =  "cnonce" EQUAL cnonce-value
+cnonce-value      =  nonce-value
+nonce-count       =  "nc" EQUAL nc-value
+nc-value          =  8LHEX
+dresponse         =  "response" EQUAL request-digest
+request-digest    =  LDQUOT 32LHEX RDQUOT
+auth-param        =  auth-param-name EQUAL
+( token / quoted-string )
+auth-param-name   =  token
+other-response    =  auth-scheme LWS auth-param
+*(COMMA auth-param)
+auth-scheme       =  token
+Authentication-Info  =  "Authentication-Info" HCOLON ainfo
+*(COMMA ainfo)
+ainfo                =  nextnonce / message-qop
+/ response-auth / cnonce
+/ nonce-count
+nextnonce            =  "nextnonce" EQUAL nonce-value
+response-auth        =  "rspauth" EQUAL response-digest
+response-digest      =  LDQUOT *LHEX RDQUOT
+Call-ID  =  ( "Call-ID" / "i" ) HCOLON callid
+callid   =  word [ "@" word ]
+Call-Info   =  "Call-Info" HCOLON info *(COMMA info)
+info        =  LAQUOT absoluteURI RAQUOT *( SEMI info-param)
+info-param  =  ( "purpose" EQUAL ( "icon" / "info"
+/ "card" / token ) ) / generic-param
+Contact        =  ("Contact" / "m" ) HCOLON
+( STAR / (contact-param *(COMMA contact-param)))
+contact-param  =  (name-addr / addr-spec) *(SEMI contact-params)
+name-addr      =  [ display-name ] LAQUOT addr-spec RAQUOT
+addr-spec      =  SIP-URI / SIPS-URI / absoluteURI
+display-name   =  *(token LWS)/ quoted-string
+contact-params     =  c-p-q / c-p-expires
+/ contact-extension
+c-p-q              =  "q" EQUAL qvalue
+c-p-expires        =  "expires" EQUAL delta-seconds
+contact-extension  =  generic-param
+delta-seconds      =  1*DIGIT
+Content-Disposition   =  "Content-Disposition" HCOLON
+disp-type *( SEMI disp-param )
+disp-type             =  "render" / "session" / "icon" / "alert"
+/ disp-extension-token
+Rosenberg, et. al.          Standards Track                   [Page 228]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+disp-param            =  handling-param / generic-param
+handling-param        =  "handling" EQUAL
+( "optional" / "required"
+/ other-handling )
+other-handling        =  token
+disp-extension-token  =  token
+Content-Encoding  =  ( "Content-Encoding" / "e" ) HCOLON
+content-coding *(COMMA content-coding)
+Content-Language  =  "Content-Language" HCOLON
+language-tag *(COMMA language-tag)
+language-tag      =  primary-tag *( "-" subtag )
+primary-tag       =  1*8ALPHA
+subtag            =  1*8ALPHA
+Content-Length  =  ( "Content-Length" / "l" ) HCOLON 1*DIGIT
+Content-Type     =  ( "Content-Type" / "c" ) HCOLON media-type
+media-type       =  m-type SLASH m-subtype *(SEMI m-parameter)
+m-type           =  discrete-type / composite-type
+discrete-type    =  "text" / "image" / "audio" / "video"
+/ "application" / extension-token
+composite-type   =  "message" / "multipart" / extension-token
+extension-token  =  ietf-token / x-token
+ietf-token       =  token
+x-token          =  "x-" token
+m-subtype        =  extension-token / iana-token
+iana-token       =  token
+m-parameter      =  m-attribute EQUAL m-value
+m-attribute      =  token
+m-value          =  token / quoted-string
+CSeq  =  "CSeq" HCOLON 1*DIGIT LWS Method
+Date          =  "Date" HCOLON SIP-date
+SIP-date      =  rfc1123-date
+rfc1123-date  =  wkday "," SP date1 SP time SP "GMT"
+date1         =  2DIGIT SP month SP 4DIGIT
+; day month year (e.g., 02 Jun 1982)
+time          =  2DIGIT ":" 2DIGIT ":" 2DIGIT
+; 00:00:00 - 23:59:59
+wkday         =  "Mon" / "Tue" / "Wed"
+/ "Thu" / "Fri" / "Sat" / "Sun"
+month         =  "Jan" / "Feb" / "Mar" / "Apr"
+/ "May" / "Jun" / "Jul" / "Aug"
+/ "Sep" / "Oct" / "Nov" / "Dec"
+Error-Info  =  "Error-Info" HCOLON error-uri *(COMMA error-uri)
+Rosenberg, et. al.          Standards Track                   [Page 229]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+error-uri   =  LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
+Expires     =  "Expires" HCOLON delta-seconds
+From        =  ( "From" / "f" ) HCOLON from-spec
+from-spec   =  ( name-addr / addr-spec )
+*( SEMI from-param )
+from-param  =  tag-param / generic-param
+tag-param   =  "tag" EQUAL token
+In-Reply-To  =  "In-Reply-To" HCOLON callid *(COMMA callid)
+Max-Forwards  =  "Max-Forwards" HCOLON 1*DIGIT
+MIME-Version  =  "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT
+Min-Expires  =  "Min-Expires" HCOLON delta-seconds
+Organization  =  "Organization" HCOLON [TEXT-UTF8-TRIM]
+Priority        =  "Priority" HCOLON priority-value
+priority-value  =  "emergency" / "urgent" / "normal"
+/ "non-urgent" / other-priority
+other-priority  =  token
+Proxy-Authenticate  =  "Proxy-Authenticate" HCOLON challenge
+challenge           =  ("Digest" LWS digest-cln *(COMMA digest-cln))
+/ other-challenge
+other-challenge     =  auth-scheme LWS auth-param
+*(COMMA auth-param)
+digest-cln          =  realm / domain / nonce
+/ opaque / stale / algorithm
+/ qop-options / auth-param
+realm               =  "realm" EQUAL realm-value
+realm-value         =  quoted-string
+domain              =  "domain" EQUAL LDQUOT URI
+*( 1*SP URI ) RDQUOT
+URI                 =  absoluteURI / abs-path
+nonce               =  "nonce" EQUAL nonce-value
+nonce-value         =  quoted-string
+opaque              =  "opaque" EQUAL quoted-string
+stale               =  "stale" EQUAL ( "true" / "false" )
+algorithm           =  "algorithm" EQUAL ( "MD5" / "MD5-sess"
+/ token )
+qop-options         =  "qop" EQUAL LDQUOT qop-value
+*("," qop-value) RDQUOT
+qop-value           =  "auth" / "auth-int" / token
+Proxy-Authorization  =  "Proxy-Authorization" HCOLON credentials
+Rosenberg, et. al.          Standards Track                   [Page 230]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Proxy-Require  =  "Proxy-Require" HCOLON option-tag
+*(COMMA option-tag)
+option-tag     =  token
+Record-Route  =  "Record-Route" HCOLON rec-route *(COMMA rec-route)
+rec-route     =  name-addr *( SEMI rr-param )
+rr-param      =  generic-param
+Reply-To      =  "Reply-To" HCOLON rplyto-spec
+rplyto-spec   =  ( name-addr / addr-spec )
+*( SEMI rplyto-param )
+rplyto-param  =  generic-param
+Require       =  "Require" HCOLON option-tag *(COMMA option-tag)
+Retry-After  =  "Retry-After" HCOLON delta-seconds
+[ comment ] *( SEMI retry-param )
+retry-param  =  ("duration" EQUAL delta-seconds)
+/ generic-param
+Route        =  "Route" HCOLON route-param *(COMMA route-param)
+route-param  =  name-addr *( SEMI rr-param )
+Server           =  "Server" HCOLON server-val *(LWS server-val)
+server-val       =  product / comment
+product          =  token [SLASH product-version]
+product-version  =  token
+Subject  =  ( "Subject" / "s" ) HCOLON [TEXT-UTF8-TRIM]
+Supported  =  ( "Supported" / "k" ) HCOLON
+[option-tag *(COMMA option-tag)]
+Timestamp  =  "Timestamp" HCOLON 1*(DIGIT)
+[ "." *(DIGIT) ] [ LWS delay ]
+delay      =  *(DIGIT) [ "." *(DIGIT) ]
+To        =  ( "To" / "t" ) HCOLON ( name-addr
+/ addr-spec ) *( SEMI to-param )
+to-param  =  tag-param / generic-param
+Unsupported  =  "Unsupported" HCOLON option-tag *(COMMA option-tag)
+User-Agent  =  "User-Agent" HCOLON server-val *(LWS server-val)
+Rosenberg, et. al.          Standards Track                   [Page 231]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Via               =  ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm)
+via-parm          =  sent-protocol LWS sent-by *( SEMI via-params )
+via-params        =  via-ttl / via-maddr
+/ via-received / via-branch
+/ via-extension
+via-ttl           =  "ttl" EQUAL ttl
+via-maddr         =  "maddr" EQUAL host
+via-received      =  "received" EQUAL (IPv4address / IPv6address)
+via-branch        =  "branch" EQUAL token
+via-extension     =  generic-param
+sent-protocol     =  protocol-name SLASH protocol-version
+SLASH transport
+protocol-name     =  "SIP" / token
+protocol-version  =  token
+transport         =  "UDP" / "TCP" / "TLS" / "SCTP"
+/ other-transport
+sent-by           =  host [ COLON port ]
+ttl               =  1*3DIGIT ; 0 to 255
+Warning        =  "Warning" HCOLON warning-value *(COMMA warning-value)
+warning-value  =  warn-code SP warn-agent SP warn-text
+warn-code      =  3DIGIT
+warn-agent     =  hostport / pseudonym
+;  the name or pseudonym of the server adding
+;  the Warning header, for use in debugging
+warn-text      =  quoted-string
+pseudonym      =  token
+WWW-Authenticate  =  "WWW-Authenticate" HCOLON challenge
+extension-header  =  header-name HCOLON header-value
+header-name       =  token
+header-value      =  *(TEXT-UTF8char / UTF8-CONT / LWS)
+message-body  =  *OCTET
+26 Security Considerations: Threat Model and Security Usage
+Recommendations
+SIP is not an easy protocol to secure.  Its use of intermediaries,
+its multi-faceted trust relationships, its expected usage between
+elements with no trust at all, and its user-to-user operation make
+security far from trivial.  Security solutions are needed that are
+deployable today, without extensive coordination, in a wide variety
+of environments and usages.  In order to meet these diverse needs,
+several distinct mechanisms applicable to different aspects and
+usages of SIP will be required.
+Rosenberg, et. al.          Standards Track                   [Page 232]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Note that the security of SIP signaling itself has no bearing on the
+security of protocols used in concert with SIP such as RTP, or with
+the security implications of any specific bodies SIP might carry
+(although MIME security plays a substantial role in securing SIP).
+Any media associated with a session can be encrypted end-to-end
+independently of any associated SIP signaling.  Media encryption is
+outside the scope of this document.
+The considerations that follow first examine a set of classic threat
+models that broadly identify the security needs of SIP.  The set of
+security services required to address these threats is then detailed,
+followed by an explanation of several security mechanisms that can be
+used to provide these services.  Next, the requirements for
+implementers of SIP are enumerated, along with exemplary deployments
+in which these security mechanisms could be used to improve the
+security of SIP.  Some notes on privacy conclude this section.
+26.1 Attacks and Threat Models
+This section details some threats that should be common to most
+deployments of SIP.  These threats have been chosen specifically to
+illustrate each of the security services that SIP requires.
+The following examples by no means provide an exhaustive list of the
+threats against SIP; rather, these are "classic" threats that
+demonstrate the need for particular security services that can
+potentially prevent whole categories of threats.
+These attacks assume an environment in which attackers can
+potentially read any packet on the network - it is anticipated that
+SIP will frequently be used on the public Internet.  Attackers on the
+network may be able to modify packets (perhaps at some compromised
+intermediary).  Attackers may wish to steal services, eavesdrop on
+communications, or disrupt sessions.
+26.1.1 Registration Hijacking
+The SIP registration mechanism allows a user agent to identify itself
+to a registrar as a device at which a user (designated by an address
+of record) is located.  A registrar assesses the identity asserted in
+the From header field of a REGISTER message to determine whether this
+request can modify the contact addresses associated with the
+address-of-record in the To header field.  While these two fields are
+frequently the same, there are many valid deployments in which a
+third-party may register contacts on a user's behalf.
+Rosenberg, et. al.          Standards Track                   [Page 233]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The From header field of a SIP request, however, can be modified
+arbitrarily by the owner of a UA, and this opens the door to
+malicious registrations.  An attacker that successfully impersonates
+a party authorized to change contacts associated with an address-of-
+record could, for example, de-register all existing contacts for a
+URI and then register their own device as the appropriate contact
+address, thereby directing all requests for the affected user to the
+attacker's device.
+This threat belongs to a family of threats that rely on the absence
+of cryptographic assurance of a request's originator.  Any SIP UAS
+that represents a valuable service (a gateway that interworks SIP
+requests with traditional telephone calls, for example) might want to
+control access to its resources by authenticating requests that it
+receives.  Even end-user UAs, for example SIP phones, have an
+interest in ascertaining the identities of originators of requests.
+This threat demonstrates the need for security services that enable
+SIP entities to authenticate the originators of requests.
+26.1.2 Impersonating a Server
+The domain to which a request is destined is generally specified in
+the Request-URI.  UAs commonly contact a server in this domain
+directly in order to deliver a request.  However, there is always a
+possibility that an attacker could impersonate the remote server, and
+that the UA's request could be intercepted by some other party.
+For example, consider a case in which a redirect server at one
+domain, chicago.com, impersonates a redirect server at another
+domain, biloxi.com.  A user agent sends a request to biloxi.com, but
+the redirect server at chicago.com answers with a forged response
+that has appropriate SIP header fields for a response from
+biloxi.com.  The forged contact addresses in the redirection response
+could direct the originating UA to inappropriate or insecure
+resources, or simply prevent requests for biloxi.com from succeeding.
+This family of threats has a vast membership, many of which are
+critical.  As a converse to the registration hijacking threat,
+consider the case in which a registration sent to biloxi.com is
+intercepted by chicago.com, which replies to the intercepted
+registration with a forged 301 (Moved Permanently) response.  This
+response might seem to come from biloxi.com yet designate chicago.com
+as the appropriate registrar.  All future REGISTER requests from the
+originating UA would then go to chicago.com.
+Prevention of this threat requires a means by which UAs can
+authenticate the servers to whom they send requests.
+Rosenberg, et. al.          Standards Track                   [Page 234]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+26.1.3 Tampering with Message Bodies
+As a matter of course, SIP UAs route requests through trusted proxy
+servers.  Regardless of how that trust is established (authentication
+of proxies is discussed elsewhere in this section), a UA may trust a
+proxy server to route a request, but not to inspect or possibly
+modify the bodies contained in that request.
+Consider a UA that is using SIP message bodies to communicate session
+encryption keys for a media session.  Although it trusts the proxy
+server of the domain it is contacting to deliver signaling properly,
+it may not want the administrators of that domain to be capable of
+decrypting any subsequent media session.  Worse yet, if the proxy
+server were actively malicious, it could modify the session key,
+either acting as a man-in-the-middle, or perhaps changing the
+security characteristics requested by the originating UA.
+This family of threats applies not only to session keys, but to most
+conceivable forms of content carried end-to-end in SIP.  These might
+include MIME bodies that should be rendered to the user, SDP, or
+encapsulated telephony signals, among others.  Attackers might
+attempt to modify SDP bodies, for example, in order to point RTP
+media streams to a wiretapping device in order to eavesdrop on
+subsequent voice communications.
+Also note that some header fields in SIP are meaningful end-to-end,
+for example, Subject.  UAs might be protective of these header fields
+as well as bodies (a malicious intermediary changing the Subject
+header field might make an important request appear to be spam, for
+example).  However, since many header fields are legitimately
+inspected or altered by proxy servers as a request is routed, not all
+header fields should be secured end-to-end.
+For these reasons, the UA might want to secure SIP message bodies,
+and in some limited cases header fields, end-to-end.  The security
+services required for bodies include confidentiality, integrity, and
+authentication.  These end-to-end services should be independent of
+the means used to secure interactions with intermediaries such as
+proxy servers.
+26.1.4 Tearing Down Sessions
+Once a dialog has been established by initial messaging, subsequent
+requests can be sent that modify the state of the dialog and/or
+session.  It is critical that principals in a session can be certain
+that such requests are not forged by attackers.
+Rosenberg, et. al.          Standards Track                   [Page 235]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Consider a case in which a third-party attacker captures some initial
+messages in a dialog shared by two parties in order to learn the
+parameters of the session (To tag, From tag, and so forth) and then
+inserts a BYE request into the session.  The attacker could opt to
+forge the request such that it seemed to come from either
+participant.  Once the BYE is received by its target, the session
+will be torn down prematurely.
+Similar mid-session threats include the transmission of forged re-
+INVITEs that alter the session (possibly to reduce session security
+or redirect media streams as part of a wiretapping attack).
+The most effective countermeasure to this threat is the
+authentication of the sender of the BYE.  In this instance, the
+recipient needs only know that the BYE came from the same party with
+whom the corresponding dialog was established (as opposed to
+ascertaining the absolute identity of the sender).  Also, if the
+attacker is unable to learn the parameters of the session due to
+confidentiality, it would not be possible to forge the BYE.  However,
+some intermediaries (like proxy servers) will need to inspect those
+parameters as the session is established.
+26.1.5 Denial of Service and Amplification
+Denial-of-service attacks focus on rendering a particular network
+element unavailable, usually by directing an excessive amount of
+network traffic at its interfaces.  A distributed denial-of-service
+attack allows one network user to cause multiple network hosts to
+flood a target host with a large amount of network traffic.
+In many architectures, SIP proxy servers face the public Internet in
+order to accept requests from worldwide IP endpoints.  SIP creates a
+number of potential opportunities for distributed denial-of-service
+attacks that must be recognized and addressed by the implementers and
+operators of SIP systems.
+Attackers can create bogus requests that contain a falsified source
+IP address and a corresponding Via header field that identify a
+targeted host as the originator of the request and then send this
+request to a large number of SIP network elements, thereby using
+hapless SIP UAs or proxies to generate denial-of-service traffic
+aimed at the target.
+Similarly, attackers might use falsified Route header field values in
+a request that identify the target host and then send such messages
+to forking proxies that will amplify messaging sent to the target.
+Rosenberg, et. al.          Standards Track                   [Page 236]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Record-Route could be used to similar effect when the attacker is
+certain that the SIP dialog initiated by the request will result in
+numerous transactions originating in the backwards direction.
+A number of denial-of-service attacks open up if REGISTER requests
+are not properly authenticated and authorized by registrars.
+Attackers could de-register some or all users in an administrative
+domain, thereby preventing these users from being invited to new
+sessions.  An attacker could also register a large number of contacts
+designating the same host for a given address-of-record in order to
+use the registrar and any associated proxy servers as amplifiers in a
+denial-of-service attack.  Attackers might also attempt to deplete
+available memory and disk resources of a registrar by registering
+huge numbers of bindings.
+The use of multicast to transmit SIP requests can greatly increase
+the potential for denial-of-service attacks.
+These problems demonstrate a general need to define architectures
+that minimize the risks of denial-of-service, and the need to be
+mindful in recommendations for security mechanisms of this class of
+attacks.
+26.2 Security Mechanisms
+From the threats described above, we gather that the fundamental
+security services required for the SIP protocol are: preserving the
+confidentiality and integrity of messaging, preventing replay attacks
+or message spoofing, providing for the authentication and privacy of
+the participants in a session, and preventing denial-of-service
+attacks.  Bodies within SIP messages separately require the security
+services of confidentiality, integrity, and authentication.
+Rather than defining new security mechanisms specific to SIP, SIP
+reuses wherever possible existing security models derived from the
+HTTP and SMTP space.
+Full encryption of messages provides the best means to preserve the
+confidentiality of signaling - it can also guarantee that messages
+are not modified by any malicious intermediaries.  However, SIP
+requests and responses cannot be naively encrypted end-to-end in
+their entirety because message fields such as the Request-URI, Route,
+and Via need to be visible to proxies in most network architectures
+so that SIP requests are routed correctly.  Note that proxy servers
+need to modify some features of messages as well (such as adding Via
+header field values) in order for SIP to function.  Proxy servers
+must therefore be trusted, to some degree, by SIP UAs.  To this
+purpose, low-layer security mechanisms for SIP are recommended, which
+Rosenberg, et. al.          Standards Track                   [Page 237]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+encrypt the entire SIP requests or responses on the wire on a hop-
+by-hop basis, and that allow endpoints to verify the identity of
+proxy servers to whom they send requests.
+SIP entities also have a need to identify one another in a secure
+fashion.  When a SIP endpoint asserts the identity of its user to a
+peer UA or to a proxy server, that identity should in some way be
+verifiable.  A cryptographic authentication mechanism is provided in
+SIP to address this requirement.
+An independent security mechanism for SIP message bodies supplies an
+alternative means of end-to-end mutual authentication, as well as
+providing a limit on the degree to which user agents must trust
+intermediaries.
+26.2.1 Transport and Network Layer Security
+Transport or network layer security encrypts signaling traffic,
+guaranteeing message confidentiality and integrity.
+Oftentimes, certificates are used in the establishment of lower-layer
+security, and these certificates can also be used to provide a means
+of authentication in many architectures.
+Two popular alternatives for providing security at the transport and
+network layer are, respectively, TLS [25] and IPSec [26].
+IPSec is a set of network-layer protocol tools that collectively can
+be used as a secure replacement for traditional IP (Internet
+Protocol).  IPSec is most commonly used in architectures in which a
+set of hosts or administrative domains have an existing trust
+relationship with one another.  IPSec is usually implemented at the
+operating system level in a host, or on a security gateway that
+provides confidentiality and integrity for all traffic it receives
+from a particular interface (as in a VPN architecture).  IPSec can
+also be used on a hop-by-hop basis.
+In many architectures IPSec does not require integration with SIP
+applications; IPSec is perhaps best suited to deployments in which
+adding security directly to SIP hosts would be arduous.  UAs that
+have a pre-shared keying relationship with their first-hop proxy
+server are also good candidates to use IPSec.  Any deployment of
+IPSec for SIP would require an IPSec profile describing the protocol
+tools that would be required to secure SIP.  No such profile is given
+in this document.
+Rosenberg, et. al.          Standards Track                   [Page 238]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+TLS provides transport-layer security over connection-oriented
+protocols (for the purposes of this document, TCP); "tls" (signifying
+TLS over TCP) can be specified as the desired transport protocol
+within a Via header field value or a SIP-URI.  TLS is most suited to
+architectures in which hop-by-hop security is required between hosts
+with no pre-existing trust association.  For example, Alice trusts
+her local proxy server, which after a certificate exchange decides to
+trust Bob's local proxy server, which Bob trusts, hence Bob and Alice
+can communicate securely.
+TLS must be tightly coupled with a SIP application.  Note that
+transport mechanisms are specified on a hop-by-hop basis in SIP, thus
+a UA that sends requests over TLS to a proxy server has no assurance
+that TLS will be used end-to-end.
+The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at
+a minimum by implementers when TLS is used in a SIP application.  For
+purposes of backwards compatibility, proxy servers, redirect servers,
+and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA.
+Implementers MAY also support any other ciphersuite.
+26.2.2 SIPS URI Scheme
+The SIPS URI scheme adheres to the syntax of the SIP URI (described
+in 19), although the scheme string is "sips" rather than "sip".  The
+semantics of SIPS are very different from the SIP URI, however.  SIPS
+allows resources to specify that they should be reached securely.
+A SIPS URI can be used as an address-of-record for a particular user
+- the URI by which the user is canonically known (on their business
+cards, in the From header field of their requests, in the To header
+field of REGISTER requests).  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.
+The SIPS scheme is applicable to many of the other ways in which SIP
+URIs are used in SIP today in addition to the Request-URI, including
+in addresses-of-record, contact addresses (the contents of Contact
+headers, including those of REGISTER methods), and Route headers.  In
+each instance, the SIPS URI scheme allows these existing fields to
+Rosenberg, et. al.          Standards Track                   [Page 239]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+designate secure resources.  The manner in which a SIPS URI is
+dereferenced in any of these contexts has its own security properties
+which are detailed in [4].
+The use of SIPS in particular entails that mutual TLS authentication
+SHOULD be employed, as SHOULD the ciphersuite
+TLS_RSA_WITH_AES_128_CBC_SHA.  Certificates received in the
+authentication process SHOULD be validated with root certificates
+held by the client; failure to validate a certificate SHOULD result
+in the failure of the request.
+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.2.3 HTTP Authentication
+SIP provides a challenge capability, based on HTTP authentication,
+that relies on the 401 and 407 response codes as well as header
+fields for carrying challenges and credentials.  Without significant
+modification, the reuse of the HTTP Digest authentication scheme in
+SIP allows for replay protection and one-way authentication.
+The usage of Digest authentication in SIP is detailed in Section 22.
+26.2.4 S/MIME
+As is discussed above, encrypting entire SIP messages end-to-end for
+the purpose of confidentiality is not appropriate because network
+intermediaries (like proxy servers) need to view certain header
+fields in order to route messages correctly, and if these
+intermediaries are excluded from security associations, then SIP
+messages will essentially be non-routable.
+However, S/MIME allows SIP UAs to encrypt MIME bodies within SIP,
+securing these bodies end-to-end without affecting message headers.
+S/MIME can provide end-to-end confidentiality and integrity for
+message bodies, as well as mutual authentication.  It is also
+possible to use S/MIME to provide a form of integrity and
+confidentiality for SIP header fields through SIP message tunneling.
+Rosenberg, et. al.          Standards Track                   [Page 240]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The usage of S/MIME in SIP is detailed in Section 23.
+26.3 Implementing Security Mechanisms
+26.3.1 Requirements for Implementers of SIP
+Proxy servers, redirect servers, and registrars MUST implement TLS,
+and MUST support both mutual and one-way authentication.  It is
+strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also
+be capable of acting as a TLS server.  Proxy servers, redirect
+servers, and registrars SHOULD possess a site certificate whose
+subject corresponds to their canonical hostname.  UAs MAY have
+certificates of their own for mutual authentication with TLS, but no
+provisions are set forth in this document for their use.  All SIP
+elements that support TLS MUST have a mechanism for validating
+certificates received during TLS negotiation; this entails possession
+of one or more root certificates issued by certificate authorities
+(preferably well-known distributors of site certificates comparable
+to those that issue root certificates for web browsers).
+All SIP elements that support TLS MUST also support the SIPS URI
+scheme.
+Proxy servers, redirect servers, registrars, and UAs MAY also
+implement IPSec or other lower-layer security protocols.
+When a UA attempts to contact a proxy server, redirect server, or
+registrar, the UAC SHOULD initiate a TLS connection over which it
+will send SIP messages.  In some architectures, UASs MAY receive
+requests over such TLS connections as well.
+Proxy servers, redirect servers, registrars, and UAs MUST implement
+Digest Authorization, encompassing all of the aspects required in 22.
+Proxy servers, redirect servers, and registrars SHOULD be configured
+with at least one Digest realm, and at least one "realm" string
+supported by a given server SHOULD correspond to the server's
+hostname or domainname.
+UAs MAY support the signing and encrypting of MIME bodies, and
+transference of credentials with S/MIME as described in Section 23.
+If a UA holds one or more root certificates of certificate
+authorities in order to validate certificates for TLS or IPSec, it
+SHOULD be capable of reusing these to verify S/MIME certificates, as
+appropriate.  A UA MAY hold root certificates specifically for
+validating S/MIME certificates.
+Rosenberg, et. al.          Standards Track                   [Page 241]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Note that is it anticipated that future security extensions may
+upgrade the normative strength associated with S/MIME as S/MIME
+implementations appear and the problem space becomes better
+understood.
+26.3.2 Security Solutions
+The operation of these security mechanisms in concert can follow the
+existing web and email security models to some degree.  At a high
+level, UAs authenticate themselves to servers (proxy servers,
+redirect servers, and registrars) with a Digest username and
+password; servers authenticate themselves to UAs one hop away, or to
+another server one hop away (and vice versa), with a site certificate
+delivered by TLS.
+On a peer-to-peer level, UAs trust the network to authenticate one
+another ordinarily; however, S/MIME can also be used to provide
+direct authentication when the network does not, or if the network
+itself is not trusted.
+The following is an illustrative example in which these security
+mechanisms are used by various UAs and servers to prevent the sorts
+of threats described in Section 26.1.  While implementers and network
+administrators MAY follow the normative guidelines given in the
+remainder of this section, these are provided only as example
+implementations.
+26.3.2.1 Registration
+When a UA comes online and registers with its local administrative
+domain, it SHOULD establish a TLS connection with its registrar
+(Section 10 describes how the UA reaches its registrar).  The
+registrar SHOULD offer a certificate to the UA, and the site
+identified by the certificate MUST correspond with the domain in
+which the UA intends to register; for example, if the UA intends to
+register the address-of-record 'alice@atlanta.com', the site
+certificate must identify a host within the atlanta.com domain (such
+as sip.atlanta.com).  When it receives the TLS Certificate message,
+the UA SHOULD verify the certificate and inspect the site identified
+by the certificate.  If the certificate is invalid, revoked, or if it
+does not identify the appropriate party, the UA MUST NOT send the
+REGISTER message and otherwise proceed with the registration.
+When a valid certificate has been provided by the registrar, the
+UA knows that the registrar is not an attacker who might redirect
+the UA, steal passwords, or attempt any similar attacks.
+Rosenberg, et. al.          Standards Track                   [Page 242]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The UA then creates a REGISTER request that SHOULD be addressed to a
+Request-URI corresponding to the site certificate received from the
+registrar.  When the UA sends the REGISTER request over the existing
+TLS connection, the registrar SHOULD challenge the request with a 401
+(Proxy Authentication Required) response.  The "realm" parameter
+within the Proxy-Authenticate header field of the response SHOULD
+correspond to the domain previously given by the site certificate.
+When the UAC receives the challenge, it SHOULD either prompt the user
+for credentials or take an appropriate credential from a keyring
+corresponding to the "realm" parameter in the challenge.  The
+username of this credential SHOULD correspond with the "userinfo"
+portion of the URI in the To header field of the REGISTER request.
+Once the Digest credentials have been inserted into an appropriate
+Proxy-Authorization header field, the REGISTER should be resubmitted
+to the registrar.
+Since the registrar requires the user agent to authenticate
+itself, it would be difficult for an attacker to forge REGISTER
+requests for the user's address-of-record.  Also note that since
+the REGISTER is sent over a confidential TLS connection, attackers
+will not be able to intercept the REGISTER to record credentials
+for any possible replay attack.
+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 has just completed
+registration.
+Because the UA has already authenticated the server on the other
+side of the TLS connection, all requests that come over this
+connection are known to have passed through the proxy server -
+attackers cannot create spoofed requests that appear to have been
+sent through that proxy server.
+26.3.2.2 Interdomain Requests
+Now let's say that Alice's UA would like to initiate a session with a
+user in a remote administrative domain, namely "bob@biloxi.com".  We
+will also say that the local administrative domain (atlanta.com) has
+a local outbound proxy.
+The proxy server that handles inbound requests for an administrative
+domain MAY also act as a local outbound proxy; for simplicity's sake
+we'll assume this to be the case for atlanta.com (otherwise the user
+agent would initiate a new TLS connection to a separate server at
+this point).  Assuming that the client has completed the registration
+Rosenberg, et. al.          Standards Track                   [Page 243]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+process described in the preceding section, it SHOULD reuse the TLS
+connection to the local proxy server when it sends an INVITE request
+to another user.  The UA SHOULD reuse cached credentials in the
+INVITE to avoid prompting the user unnecessarily.
+When the local outbound proxy server has validated the credentials
+presented by the UA in the INVITE, it SHOULD inspect the Request-URI
+to determine how the message should be routed (see [4]).  If the
+"domainname" portion of the Request-URI had corresponded to the local
+domain (atlanta.com) rather than biloxi.com, then the proxy server
+would have consulted its location service to determine how best to
+reach the requested user.
+Had "alice@atlanta.com" been attempting to contact, say,
+"alex@atlanta.com", the local proxy would have proxied to the
+request to the TLS connection Alex had established with the
+registrar when he registered.  Since Alex would receive this
+request over his authenticated channel, he would be assured that
+Alice's request had been authorized by the proxy server of the
+local administrative domain.
+However, in this instance the Request-URI designates a remote domain.
+The local outbound proxy server at atlanta.com SHOULD therefore
+establish a TLS connection with the remote proxy server at
+biloxi.com.  Since both of the participants in this TLS connection
+are servers that possess site certificates, mutual TLS authentication
+SHOULD occur.  Each side of the connection SHOULD verify and inspect
+the certificate of the other, noting the domain name that appears in
+the certificate for comparison with the header fields of SIP
+messages.  The atlanta.com proxy server, for example, SHOULD verify
+at this stage that the certificate received from the remote side
+corresponds with the biloxi.com domain.  Once it has done so, and TLS
+negotiation has completed, resulting in a secure channel between the
+two proxies, the atlanta.com proxy can forward the INVITE request to
+biloxi.com.
+The proxy server at biloxi.com SHOULD inspect the certificate of the
+proxy server at atlanta.com in turn and compare the domain asserted
+by the certificate with the "domainname" portion of the From header
+field in the INVITE request.  The biloxi proxy MAY have a strict
+security policy that requires it to reject requests that do not match
+the administrative domain from which they have been proxied.
+Such security policies could be instituted to prevent the SIP
+equivalent of SMTP 'open relays' that are frequently exploited to
+generate spam.
+Rosenberg, et. al.          Standards Track                   [Page 244]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+This policy, however, only guarantees that the request came from the
+domain it ascribes to itself; it does not allow biloxi.com to
+ascertain how atlanta.com authenticated Alice.  Only if biloxi.com
+has some other way of knowing atlanta.com's authentication policies
+could it possibly ascertain how Alice proved her identity.
+biloxi.com might then institute an even stricter policy that forbids
+requests that come from domains that are not known administratively
+to share a common authentication policy with biloxi.com.
+Once the INVITE has been approved by the biloxi proxy, the proxy
+server SHOULD identify the existing TLS channel, if any, associated
+with the user targeted by this request (in this case
+"bob@biloxi.com").  The INVITE should be proxied through this channel
+to Bob.  Since the request is received over a TLS connection that had
+previously been authenticated as the biloxi proxy, Bob knows that the
+From header field was not tampered with and that atlanta.com has
+validated Alice, although not necessarily whether or not to trust
+Alice's identity.
+Before they forward the request, both proxy servers SHOULD add a
+Record-Route header field to the request so that all future requests
+in this dialog will pass through the proxy servers.  The proxy
+servers can thereby continue to provide security services for the
+lifetime of this dialog.  If the proxy servers do not add themselves
+to the Record-Route, future messages will pass directly end-to-end
+between Alice and Bob without any security services (unless the two
+parties agree on some independent end-to-end security such as
+S/MIME).  In this respect the SIP trapezoid model can provide a nice
+structure where conventions of agreement between the site proxies can
+provide a reasonably secure channel between Alice and Bob.
+An attacker preying on this architecture would, for example, be
+unable to forge a BYE request and insert it into the signaling
+stream between Bob and Alice because the attacker has no way of
+ascertaining the parameters of the session and also because the
+integrity mechanism transitively protects the traffic between
+Alice and Bob.
+26.3.2.3 Peer-to-Peer Requests
+Alternatively, consider a UA asserting the identity
+"carol@chicago.com" that has no local outbound proxy.  When Carol
+wishes to send an INVITE to "bob@biloxi.com", her UA SHOULD initiate
+a TLS connection with the biloxi proxy directly (using the mechanism
+described in [4] to determine how to best to reach the given
+Request-URI).  When her UA receives a certificate from the biloxi
+proxy, it SHOULD be verified normally before she passes her INVITE
+across the TLS connection.  However, Carol has no means of proving
+Rosenberg, et. al.          Standards Track                   [Page 245]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+her identity to the biloxi proxy, but she does have a CMS-detached
+signature over a "message/sip" body in the INVITE.  It is unlikely in
+this instance that Carol would have any credentials in the biloxi.com
+realm, since she has no formal association with biloxi.com.  The
+biloxi proxy MAY also have a strict policy that precludes it from
+even bothering to challenge requests that do not have biloxi.com in
+the "domainname" portion of the From header field - it treats these
+users as unauthenticated.
+The biloxi proxy has a policy for Bob that all non-authenticated
+requests should be redirected to the appropriate contact address
+registered against 'bob@biloxi.com', namely <sip:bob@192.0.2.4>.
+Carol receives the redirection response over the TLS connection she
+established with the biloxi proxy, so she trusts the veracity of the
+contact address.
+Carol SHOULD then establish a TCP connection with the designated
+address and send a new INVITE with a Request-URI containing the
+received contact address (recomputing the signature in the body as
+the request is readied).  Bob receives this INVITE on an insecure
+interface, but his UA inspects and, in this instance, recognizes the
+From header field of the request and subsequently matches a locally
+cached certificate with the one presented in the signature of the
+body of the INVITE.  He replies in similar fashion, authenticating
+himself to Carol, and a secure dialog begins.
+Sometimes firewalls or NATs in an administrative domain could
+preclude the establishment of a direct TCP connection to a UA.  In
+these cases, proxy servers could also potentially relay requests
+to UAs in a way that has no trust implications (for example,
+forgoing an existing TLS connection and forwarding the request
+over cleartext TCP) as local policy dictates.
+26.3.2.4 DoS Protection
+In order to minimize the risk of a denial-of-service attack against
+architectures using these security solutions, implementers should
+take note of the following guidelines.
+When the host on which a SIP proxy server is operating is routable
+from the public Internet, it SHOULD be deployed in an administrative
+domain with defensive operational policies (blocking source-routed
+traffic, preferably filtering ping traffic).  Both TLS and IPSec can
+also make use of bastion hosts at the edges of administrative domains
+that participate in the security associations to aggregate secure
+tunnels and sockets.  These bastion hosts can also take the brunt of
+denial-of-service attacks, ensuring that SIP hosts within the
+administrative domain are not encumbered with superfluous messaging.
+Rosenberg, et. al.          Standards Track                   [Page 246]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+No matter what security solutions are deployed, floods of messages
+directed at proxy servers can lock up proxy server resources and
+prevent desirable traffic from reaching its destination.  There is a
+computational expense associated with processing a SIP transaction at
+a proxy server, and that expense is greater for stateful proxy
+servers than it is for stateless proxy servers.  Therefore, stateful
+proxies are more susceptible to flooding than stateless proxy
+servers.
+UAs and proxy servers SHOULD challenge questionable requests with
+only a single 401 (Unauthorized) or 407 (Proxy Authentication
+Required), forgoing the normal response retransmission algorithm, and
+thus behaving statelessly towards unauthenticated requests.
+Retransmitting the 401 (Unauthorized) or 407 (Proxy Authentication
+Required) status response amplifies the problem of an attacker
+using a falsified header field value (such as Via) to direct
+traffic to a third party.
+In summary, the mutual authentication of proxy servers through
+mechanisms such as TLS significantly reduces the potential for rogue
+intermediaries to introduce falsified requests or responses that can
+deny service.  This commensurately makes it harder for attackers to
+make innocent SIP nodes into agents of amplification.
+26.4 Limitations
+Although these security mechanisms, when applied in a judicious
+manner, can thwart many threats, there are limitations in the scope
+of the mechanisms that must be understood by implementers and network
+operators.
+26.4.1 HTTP Digest
+One of the primary limitations of using HTTP Digest in SIP is that
+the integrity mechanisms in Digest do not work very well for SIP.
+Specifically, they offer protection of the Request-URI and the method
+of a message, but not for any of the header fields that UAs would
+most likely wish to secure.
+The existing replay protection mechanisms described in RFC 2617 also
+have some limitations for SIP.  The next-nonce mechanism, for
+example, does not support pipelined requests.  The nonce-count
+mechanism should be used for replay protection.
+Another limitation of HTTP Digest is the scope of realms.  Digest is
+valuable when a user wants to authenticate themselves to a resource
+with which they have a pre-existing association, like a service
+Rosenberg, et. al.          Standards Track                   [Page 247]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+provider of which the user is a customer (which is quite a common
+scenario and thus Digest provides an extremely useful function).  By
+way of contrast, the scope of TLS is interdomain or multirealm, since
+certificates are often globally verifiable, so that the UA can
+authenticate the server with no pre-existing association.
+26.4.2 S/MIME
+The largest outstanding defect with the S/MIME mechanism is the lack
+of a prevalent public key infrastructure for end users.  If self-
+signed certificates (or certificates that cannot be verified by one
+of the participants in a dialog) are used, the SIP-based key exchange
+mechanism described in Section 23.2 is susceptible to a man-in-the-
+middle attack with which an attacker can potentially inspect and
+modify S/MIME bodies.  The attacker needs to intercept the first
+exchange of keys between the two parties in a dialog, remove the
+existing CMS-detached signatures from the request and response, and
+insert a different CMS-detached signature containing a certificate
+supplied by the attacker (but which seems to be a certificate for the
+proper address-of-record).  Each party will think they have exchanged
+keys with the other, when in fact each has the public key of the
+attacker.
+It is important to note that the attacker can only leverage this
+vulnerability on the first exchange of keys between two parties - on
+subsequent occasions, the alteration of the key would be noticeable
+to the UAs.  It would also be difficult for the attacker to remain in
+the path of all future dialogs between the two parties over time (as
+potentially days, weeks, or years pass).
+SSH is susceptible to the same man-in-the-middle attack on the first
+exchange of keys; however, it is widely acknowledged that while SSH
+is not perfect, it does improve the security of connections.  The use
+of key fingerprints could provide some assistance to SIP, just as it
+does for SSH.  For example, if two parties use SIP to establish a
+voice communications session, each could read off the fingerprint of
+the key they received from the other, which could be compared against
+the original.  It would certainly be more difficult for the man-in-
+the-middle to emulate the voices of the participants than their
+signaling (a practice that was used with the Clipper chip-based
+secure telephone).
+The S/MIME mechanism allows UAs to send encrypted requests without
+preamble if they possess a certificate for the destination address-
+of-record on their keyring.  However, it is possible that any
+particular device registered for an address-of-record will not hold
+the certificate that has been previously employed by the device's
+current user, and that it will therefore be unable to process an
+Rosenberg, et. al.          Standards Track                   [Page 248]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+encrypted request properly, which could lead to some avoidable error
+signaling.  This is especially likely when an encrypted request is
+forked.
+The keys associated with S/MIME are most useful when associated with
+a particular user (an address-of-record) rather than a device (a UA).
+When users move between devices, it may be difficult to transport
+private keys securely between UAs; how such keys might be acquired by
+a device is outside the scope of this document.
+Another, more prosaic difficulty with the S/MIME mechanism is that it
+can result in very large messages, especially when the SIP tunneling
+mechanism described in Section 23.4 is used.  For that reason, it is
+RECOMMENDED that TCP should be used as a transport protocol when
+S/MIME tunneling is employed.
+26.4.3 TLS
+The most commonly voiced concern about TLS is that it cannot run over
+UDP; TLS requires a connection-oriented underlying transport
+protocol, which for the purposes of this document means TCP.
+It may also be arduous for a local outbound proxy server and/or
+registrar to maintain many simultaneous long-lived TLS connections
+with numerous UAs.  This introduces some valid scalability concerns,
+especially for intensive ciphersuites.  Maintaining redundancy of
+long-lived TLS connections, especially when a UA is solely
+responsible for their establishment, could also be cumbersome.
+TLS only allows SIP entities to authenticate servers to which they
+are adjacent; TLS offers strictly hop-by-hop security.  Neither TLS,
+nor any other mechanism specified in this document, allows clients to
+authenticate proxy servers to whom they cannot form a direct TCP
+connection.
+26.4.4 SIPS URIs
+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.  Note that since many UAs will not accept
+incoming TLS connections, even those UAs that do support TLS may be
+required to maintain persistent TLS connections as described in the
+TLS limitations section above in order to receive requests over TLS
+as a UAS.
+Rosenberg, et. al.          Standards Track                   [Page 249]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Location services are not required to provide a SIPS binding for a
+SIPS Request-URI.  Although location services are commonly populated
+by user registrations (as described in Section 10.2.1), various other
+protocols and interfaces could conceivably supply contact addresses
+for an AOR, and these tools are free to map SIPS URIs to SIP URIs as
+appropriate.  When queried for bindings, a location service returns
+its contact addresses without regard for whether it received a
+request with a SIPS Request-URI.  If a redirect server is accessing
+the location service, it is up to the entity that processes the
+Contact header field of a redirection to determine the propriety of
+the contact addresses.
+Ensuring that TLS will be used for all of the request segments up to
+the target domain is somewhat complex.  It is possible that
+cryptographically authenticated proxy servers along the way that are
+non-compliant or compromised may choose to disregard the forwarding
+rules associated with SIPS (and the general forwarding rules in
+Section 16.6).  Such malicious intermediaries could, for example,
+retarget a request from a SIPS URI to a SIP URI in an attempt to
+downgrade security.
+Alternatively, an intermediary might legitimately retarget a request
+from a SIP to a SIPS URI.  Recipients of a request whose Request-URI
+uses the SIPS URI scheme thus cannot assume on the basis of the
+Request-URI alone that SIPS was used for the entire request path
+(from the client onwards).
+To address these concerns, it is RECOMMENDED that recipients of a
+request whose Request-URI contains a SIP or SIPS URI inspect the To
+header field value to see if it contains a SIPS URI (though note that
+it does not constitute a breach of security if this URI has the same
+scheme but is not equivalent to the URI in the To header field).
+Although clients may choose to populate the Request-URI and To header
+field of a request differently, when SIPS is used this disparity
+could be interpreted as a possible security violation, and the
+request could consequently be rejected by its recipient.  Recipients
+MAY also inspect the Via header chain in order to double-check
+whether or not TLS was used for the entire request path until the
+local administrative domain was reached.  S/MIME may also be used by
+the originating UAC to help ensure that the original form of the To
+header field is carried end-to-end.
+If the UAS has reason to believe that the scheme of the Request-URI
+has been improperly modified in transit, the UA SHOULD notify its
+user of a potential security breach.
+Rosenberg, et. al.          Standards Track                   [Page 250]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+As a further measure to prevent downgrade attacks, entities that
+accept only SIPS requests MAY also refuse connections on insecure
+ports.
+End users will undoubtedly discern the difference between SIPS and
+SIP URIs, and they may manually edit them in response to stimuli.
+This can either benefit or degrade security.  For example, if an
+attacker corrupts a DNS cache, inserting a fake record set that
+effectively removes all SIPS records for a proxy server, then any
+SIPS requests that traverse this proxy server may fail.  When a user,
+however, sees that repeated calls to a SIPS AOR are failing, they
+could on some devices manually convert the scheme from SIPS to SIP
+and retry.  Of course, there are some safeguards against this (if the
+destination UA is truly paranoid it could refuse all non-SIPS
+requests), but it is a limitation worth noting.  On the bright side,
+users might also divine that 'SIPS' would be valid even when they are
+presented only with a SIP URI.
+26.5 Privacy
+SIP messages frequently contain sensitive information about their
+senders - not just what they have to say, but with whom they
+communicate, when they communicate and for how long, and from where
+they participate in sessions.  Many applications and their users
+require that this sort of private information be hidden from any
+parties that do not need to know it.
+Note that there are also less direct ways in which private
+information can be divulged.  If a user or service chooses to be
+reachable at an address that is guessable from the person's name and
+organizational affiliation (which describes most addresses-of-
+record), the traditional method of ensuring privacy by having an
+unlisted "phone number" is compromised.  A user location service can
+infringe on the privacy of the recipient of a session invitation by
+divulging their specific whereabouts to the caller; an implementation
+consequently SHOULD be able to restrict, on a per-user basis, what
+kind of location and availability information is given out to certain
+classes of callers.  This is a whole class of problem that is
+expected to be studied further in ongoing SIP work.
+In some cases, users may want to conceal personal information in
+header fields that convey identity.  This can apply not only to the
+From and related headers representing the originator of the request,
+but also the To - it may not be appropriate to convey to the final
+destination a speed-dialing nickname, or an unexpanded identifier for
+a group of targets, either of which would be removed from the
+Request-URI as the request is routed, but not changed in the To
+Rosenberg, et. al.          Standards Track                   [Page 251]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+header field if the two were initially identical.  Thus it MAY be
+desirable for privacy reasons to create a To header field that
+differs from the Request-URI.
+27 IANA Considerations
+All method names, header field names, status codes, and option tags
+used in SIP applications are registered with IANA through
+instructions in an IANA Considerations section in an RFC.
+The specification instructs the IANA to create four new sub-
+registries under http://www.iana.org/assignments/sip-parameters:
+Option Tags, Warning Codes (warn-codes), Methods and Response Codes,
+added to the sub-registry of Header Fields that is already present
+there.
+27.1 Option Tags
+This specification establishes the Option Tags sub-registry under
+http://www.iana.org/assignments/sip-parameters.
+Option tags are used in header fields such as Require, Supported,
+Proxy-Require, and Unsupported in support of SIP compatibility
+mechanisms for extensions (Section 19.2).  The option tag itself is a
+string that is associated with a particular SIP option (that is, an
+extension).  It identifies the option to SIP endpoints.
+Option tags are registered by the IANA when they are published in
+standards track RFCs.  The IANA Considerations section of the RFC
+must include the following information, which appears in the IANA
+registry along with the RFC number of the publication.
+o  Name of the option tag.  The name MAY be of any length, but
+SHOULD be no more than twenty characters long.  The name MUST
+consist of alphanum (Section 25) characters only.
+o  Descriptive text that describes the extension.
+27.2 Warn-Codes
+This specification establishes the Warn-codes sub-registry under
+http://www.iana.org/assignments/sip-parameters and initiates its
+population with the warn-codes listed in Section 20.43.  Additional
+warn-codes are registered by RFC publication.
+Rosenberg, et. al.          Standards Track                   [Page 252]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+The descriptive text for the table of warn-codes is:
+Warning codes provide information supplemental to the status code in
+SIP response messages when the failure of the transaction results
+from a Session Description Protocol (SDP) (RFC 2327 [1]) problem.
+The "warn-code" consists of three digits.  A first digit of "3"
+indicates warnings specific to SIP.  Until a future specification
+describes uses of warn-codes other than 3xx, only 3xx warn-codes may
+be registered.
+Warnings 300 through 329 are reserved for indicating problems with
+keywords in the session description, 330 through 339 are warnings
+related to basic network services requested in the session
+description, 370 through 379 are warnings related to quantitative QoS
+parameters requested in the session description, and 390 through 399
+are miscellaneous warnings that do not fall into one of the above
+categories.
+27.3 Header Field Names
+This obsoletes the IANA instructions about the header sub-registry
+under http://www.iana.org/assignments/sip-parameters.
+The following information needs to be provided in an RFC publication
+in order to register a new header field name:
+o  The RFC number in which the header is registered;
+o  the name of the header field being registered;
+o  a compact form version for that header field, if one is
+defined;
+Some common and widely used header fields MAY be assigned one-letter
+compact forms (Section 7.3.3).  Compact forms can only be assigned
+after SIP working group review, followed by RFC publication.
+27.4 Method and Response Codes
+This specification establishes the Method and Response-Code sub-
+registries under http://www.iana.org/assignments/sip-parameters and
+initiates their population as follows.  The initial Methods table is:
+Rosenberg, et. al.          Standards Track                   [Page 253]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+INVITE                   [RFC3261]
+ACK                      [RFC3261]
+BYE                      [RFC3261]
+CANCEL                   [RFC3261]
+REGISTER                 [RFC3261]
+OPTIONS                  [RFC3261]
+INFO                     [RFC2976]
+The response code table is initially populated from Section 21, the
+portions labeled Informational, Success, Redirection, Client-Error,
+Server-Error, and Global-Failure.  The table has the following
+format:
+Type (e.g., Informational)
+Number    Default Reason Phrase         [RFC3261]
+The following information needs to be provided in an RFC publication
+in order to register a new response code or method:
+o  The RFC number in which the method or response code is
+registered;
+o  the number of the response code or name of the method being
+registered;
+o  the default reason phrase for that response code, if
+applicable;
+27.5 The "message/sip" MIME type.
+This document registers the "message/sip" MIME media type in order to
+allow SIP messages to be tunneled as bodies within SIP, primarily for
+end-to-end security purposes.  This media type is defined by the
+following information:
+Media type name: message
+Media subtype name: sip
+Required parameters: none
+Optional parameters: version
+version: The SIP-Version number of the enclosed message (e.g.,
+"2.0").  If not present, the version defaults to "2.0".
+Encoding scheme: SIP messages consist of an 8-bit header
+optionally followed by a binary MIME data object.  As such, SIP
+messages must be treated as binary.  Under normal circumstances
+SIP messages are transported over binary-capable transports, no
+special encodings are needed.
+Rosenberg, et. al.          Standards Track                   [Page 254]
+RFC 3261            SIP: Session Initiation Protocol           June 2002
+Security considerations: see below
+Motivation and examples of this usage as a security mechanism
+in concert with S/MIME are given in 23.4.
+27.6 New Content-Disposition Parameter Registrations
+This document also registers four new Content-Disposition header
+"disposition-types": alert, icon, session and render.  The authors
+request that these values be recorded in the IANA registry for
+Content-Dispositions.
+Descriptions of these "disposition-types", including motivation and
+examples, are given in Section 20.11.
+Short descriptions suitable for the IANA registry are:
+alert     the body is a custom ring tone to alert the user
+icon      the body is displayed as an icon to the user
+render    the body should be displayed to the user
+session   the body describes a communications session, for
+example, as RFC 2327 SDP body
+28 Changes From RFC 2543
+This RFC revises RFC 2543.  It is mostly backwards compatible with
+RFC 2543.  The changes described here fix many errors discovered in
+RFC 2543 and provide information on scenarios not detailed in RFC
+2543.  The protocol has been presented in a more cleanly layered
+model here.
+We break the differences into functional behavior that is a
+substantial change from RFC 2543, which has impact on
+interoperability or correct operation in some cases, and functional
+behavior that is different from RFC 2543 but not a potential source
+of interoperability problems.  There have been countless
+clarifications as well, which are not documented here.
+28.1 Major Functional Changes
+o  When a UAC wishes to terminate a call before it has been answered,
+it sends CANCEL.  If the original INVITE still returns a 2xx, the
+UAC then sends BYE.  BYE can only be sent on an existing call leg
+(now called a dialog in this RFC), whereas it could be sent at any
+time in RFC 2543.
+o  The SIP BNF was converted to be RFC 2234 compliant.
+Rosenberg, et. al.          Standards Track                   [Page 255]
+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]

changeset 0	1918ee327afb
child 7	3f74d0d4af4c