--- rfc2543.txt	2003-10-09 14:45:42.000000000 +0900
+++ rfc3261.txt	2003-10-09 14:49:58.000000000 +0900
@@ -1,14 +1,26 @@
 
-Network Working Group                                          M. Handley
-Request for Comments: 2543                                          ACIRI
-Category: Standards Track                                  H. Schulzrinne
-                                                              Columbia U.
-                                                              E. Schooler
-                                                                 Cal Tech
-                                                             J. Rosenberg
-                                                                Bell Labs
-                                                               March 1999
+
+
+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
@@ -19,6885 +31,12498 @@
 
 Copyright Notice
 
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-IESG Note
-
-   The IESG intends to charter, in the near future, one or more working
-   groups to produce standards for "name lookup", where such names would
-   include electronic mail addresses and telephone numbers, and the
-   result of such a lookup would be a list of attributes and
-   characteristics of the user or terminal associated with the name.
-   Groups which are in need of a "name lookup" protocol should follow
-   the development of these new working groups rather than using SIP for
-   this function. In addition it is anticipated that SIP will migrate
-   towards using such protocols, and SIP implementors are advised to
-   monitor these efforts.
 
 Abstract
 
-   The Session Initiation Protocol (SIP) is an application-layer control
-   (signaling) protocol for creating, modifying and terminating sessions
-   with one or more participants. These sessions include Internet
-   multimedia conferences, Internet telephone calls and multimedia
-   distribution. Members in a session can communicate via multicast or
-   via a mesh of unicast relations, or a combination of these.
+   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
-   which allow participants to agree on a set of compatible media types.
-   SIP supports user mobility by proxying and redirecting requests to
-   the user's current location. Users can register their current
-   location.  SIP is not tied to any particular conference control
-   protocol. SIP is designed to be independent of the lower-layer
-   transport protocol and can be extended with additional capabilities.
+   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.
 
 Table of Contents
 
-   1          Introduction ........................................    7
-   1.1        Overview of SIP Functionality .......................    7
-   1.2        Terminology .........................................    8
-   1.3        Definitions .........................................    9
-   1.4        Overview of SIP Operation ...........................   12
-   1.4.1      SIP Addressing ......................................   12
-   1.4.2      Locating a SIP Server ...............................   13
-   1.4.3      SIP Transaction .....................................   14
-   1.4.4      SIP Invitation ......................................   15
-   1.4.5      Locating a User .....................................   17
-   1.4.6      Changing an Existing Session ........................   18
-   1.4.7      Registration Services ...............................   18
-   1.5        Protocol Properties .................................   18
-   1.5.1      Minimal State .......................................   18
-   1.5.2      Lower-Layer-Protocol Neutral ........................   18
-   1.5.3      Text-Based ..........................................   20
-   2          SIP Uniform Resource Locators .......................   20
-   3          SIP Message Overview ................................   24
-   4          Request .............................................   26
-   4.1        Request-Line ........................................   26
-   4.2        Methods .............................................   27
-   4.2.1      INVITE ..............................................   28
-   4.2.2      ACK .................................................   29
-   4.2.3      OPTIONS .............................................   29
-   4.2.4      BYE .................................................   30
-   4.2.5      CANCEL ..............................................   30
-   4.2.6      REGISTER ............................................   31
-   4.3        Request-URI .........................................   34
-   4.3.1      SIP Version .........................................   35
-   4.4        Option Tags .........................................   35
-   4.4.1      Registering New Option Tags with IANA ...............   35
-   5          Response ............................................   36
-   5.1        Status-Line .........................................   36
-   5.1.1      Status Codes and Reason Phrases .....................   37
-   6          Header Field Definitions ............................   39
-   6.1        General Header Fields ...............................   41
-   6.2        Entity Header Fields ................................   42
-   6.3        Request Header Fields ...............................   43
-
-
-   6.4        Response Header Fields ..............................   43
-   6.5        End-to-end and Hop-by-hop Headers ...................   43
-   6.6        Header Field Format .................................   43
-   6.7        Accept ..............................................   44
-   6.8        Accept-Encoding .....................................   44
-   6.9        Accept-Language .....................................   45
-   6.10       Allow ...............................................   45
-   6.11       Authorization .......................................   45
-   6.12       Call-ID .............................................   46
-   6.13       Contact .............................................   47
-   6.14       Content-Encoding ....................................   50
-   6.15       Content-Length ......................................   51
-   6.16       Content-Type ........................................   51
-   6.17       CSeq ................................................   52
-   6.18       Date ................................................   53
-   6.19       Encryption ..........................................   54
-   6.20       Expires .............................................   55
-   6.21       From ................................................   56
-   6.22       Hide ................................................   57
-   6.23       Max-Forwards ........................................   59
-   6.24       Organization ........................................   59
-   6.25       Priority ............................................   60
-   6.26       Proxy-Authenticate ..................................   60
-   6.27       Proxy-Authorization .................................   61
-   6.28       Proxy-Require .......................................   61
-   6.29       Record-Route ........................................   62
-   6.30       Require .............................................   63
-   6.31       Response-Key ........................................   63
-   6.32       Retry-After .........................................   64
-   6.33       Route ...............................................   65
-   6.34       Server ..............................................   65
-   6.35       Subject .............................................   65
-   6.36       Timestamp ...........................................   66
-   6.37       To ..................................................   66
-   6.38       Unsupported .........................................   68
-   6.39       User-Agent ..........................................   68
-   6.40       Via .................................................   68
-   6.40.1     Requests ............................................   68
-   6.40.2     Receiver-tagged Via Header Fields ...................   69
-   6.40.3     Responses ...........................................   70
-   6.40.4     User Agent and Redirect Servers .....................   70
-   6.40.5     Syntax ..............................................   71
-   6.41       Warning .............................................   72
-   6.42       WWW-Authenticate ....................................   74
-   7          Status Code Definitions .............................   75
-   7.1        Informational 1xx ...................................   75
-   7.1.1      100 Trying ..........................................   75
-   7.1.2      180 Ringing .........................................   75
-
-
-   7.1.3      181 Call Is Being Forwarded .........................   75
-   7.1.4      182 Queued ..........................................   76
-   7.2        Successful 2xx ......................................   76
-   7.2.1      200 OK ..............................................   76
-   7.3        Redirection 3xx .....................................   76
-   7.3.1      300 Multiple Choices ................................   77
-   7.3.2      301 Moved Permanently ...............................   77
-   7.3.3      302 Moved Temporarily ...............................   77
-   7.3.4      305 Use Proxy .......................................   77
-   7.3.5      380 Alternative Service .............................   78
-   7.4        Request Failure 4xx .................................   78
-   7.4.1      400 Bad Request .....................................   78
-   7.4.2      401 Unauthorized ....................................   78
-   7.4.3      402 Payment Required ................................   78
-   7.4.4      403 Forbidden .......................................   78
-   7.4.5      404 Not Found .......................................   78
-   7.4.6      405 Method Not Allowed ..............................   78
-   7.4.7      406 Not Acceptable ..................................   79
-   7.4.8      407 Proxy Authentication Required ...................   79
-   7.4.9      408 Request Timeout .................................   79
-   7.4.10     409 Conflict ........................................   79
-   7.4.11     410 Gone ............................................   79
-   7.4.12     411 Length Required .................................   79
-   7.4.13     413 Request Entity Too Large ........................   80
-   7.4.14     414 Request-URI Too Long ............................   80
-   7.4.15     415 Unsupported Media Type ..........................   80
-   7.4.16     420 Bad Extension ...................................   80
-   7.4.17     480 Temporarily Unavailable .........................   80
-   7.4.18     481 Call Leg/Transaction Does Not Exist .............   81
-   7.4.19     482 Loop Detected ...................................   81
-   7.4.20     483 Too Many Hops ...................................   81
-   7.4.21     484 Address Incomplete ..............................   81
-   7.4.22     485 Ambiguous .......................................   81
-   7.4.23     486 Busy Here .......................................   82
-   7.5        Server Failure 5xx ..................................   82
-   7.5.1      500 Server Internal Error ...........................   82
-   7.5.2      501 Not Implemented .................................   82
-   7.5.3      502 Bad Gateway .....................................   82
-   7.5.4      503 Service Unavailable .............................   83
-   7.5.5      504 Gateway Time-out ................................   83
-   7.5.6      505 Version Not Supported ...........................   83
-   7.6        Global Failures 6xx .................................   83
-   7.6.1      600 Busy Everywhere .................................   83
-   7.6.2      603 Decline .........................................   84
-   7.6.3      604 Does Not Exist Anywhere .........................   84
-   7.6.4      606 Not Acceptable ..................................   84
-   8          SIP Message Body ....................................   84
-   8.1        Body Inclusion ......................................   84
-
-
-   8.2        Message Body Type ...................................   85
-   8.3        Message Body Length .................................   85
-   9          Compact Form ........................................   85
-   10         Behavior of SIP Clients and Servers .................   86
-   10.1       General Remarks .....................................   86
-   10.1.1     Requests ............................................   86
-   10.1.2     Responses ...........................................   87
-   10.2       Source Addresses, Destination Addresses and
-              Connections .........................................   88
-   10.2.1     Unicast UDP .........................................   88
-   10.2.2     Multicast UDP .......................................   88
-   10.3       TCP .................................................   89
-   10.4       Reliability for BYE, CANCEL, OPTIONS, REGISTER
-              Requests ............................................   90
-   10.4.1     UDP .................................................   90
-   10.4.2     TCP .................................................   91
-   10.5       Reliability for INVITE Requests .....................   91
-   10.5.1     UDP .................................................   92
-   10.5.2     TCP .................................................   95
-   10.6       Reliability for ACK Requests ........................   95
-   10.7       ICMP Handling .......................................   95
-   11         Behavior of SIP User Agents .........................   95
-   11.1       Caller Issues Initial INVITE Request ................   96
-   11.2       Callee Issues Response ..............................   96
-   11.3       Caller Receives Response to Initial Request .........   96
-   11.4       Caller or Callee Generate Subsequent Requests .......   97
-   11.5       Receiving Subsequent Requests .......................   97
-   12         Behavior of SIP Proxy and Redirect Servers ..........   97
-   12.1       Redirect Server .....................................   97
-   12.2       User Agent Server ...................................   98
-   12.3       Proxy Server ........................................   98
-   12.3.1     Proxying Requests ...................................   98
-   12.3.2     Proxying Responses ..................................   99
-   12.3.3     Stateless Proxy: Proxying Responses .................   99
-   12.3.4     Stateful Proxy: Receiving Requests ..................   99
-   12.3.5     Stateful Proxy: Receiving ACKs ......................   99
-   12.3.6     Stateful Proxy: Receiving Responses .................  100
-   12.3.7     Stateless, Non-Forking Proxy ........................  100
-   12.4       Forking Proxy .......................................  100
-   13         Security Considerations .............................  104
-   13.1       Confidentiality and Privacy: Encryption .............  104
-   13.1.1     End-to-End Encryption ...............................  104
-   13.1.2     Privacy of SIP Responses ............................  107
-   13.1.3     Encryption by Proxies ...............................  108
-   13.1.4     Hop-by-Hop Encryption ...............................  108
-   13.1.5     Via field encryption ................................  108
-   13.2       Message Integrity and Access Control:
-              Authentication ......................................  109
-
-
-   13.2.1     Trusting responses ..................................  112
-   13.3       Callee Privacy ......................................  113
-   13.4       Known Security Problems .............................  113
-   14         SIP Authentication using HTTP Basic and Digest
-              Schemes .............................................  113
-   14.1       Framework ...........................................  113
-   14.2       Basic Authentication ................................  114
-   14.3       Digest Authentication ...............................  114
-   14.4       Proxy-Authentication ................................  115
-   15         SIP Security Using PGP ..............................  115
-   15.1       PGP Authentication Scheme ...........................  115
-   15.1.1     The WWW-Authenticate Response Header ................  116
-   15.1.2     The Authorization Request Header ....................  117
-   15.2       PGP Encryption Scheme ...............................  118
-   15.3       Response-Key Header Field for PGP ...................  119
-   16         Examples ............................................  119
-   16.1       Registration ........................................  119
-   16.2       Invitation to a Multicast Conference ................  121
-   16.2.1     Request .............................................  121
-   16.2.2     Response ............................................  122
-   16.3       Two-party Call ......................................  123
-   16.4       Terminating a Call ..................................  125
-   16.5       Forking Proxy .......................................  126
-   16.6       Redirects ...........................................  130
-   16.7       Negotiation .........................................  131
-   16.8       OPTIONS Request .....................................  132
-   A          Minimal Implementation ..............................  134
-   A.1        Client ..............................................  134
-   A.2        Server ..............................................  135
-   A.3        Header Processing ...................................  135
-   B          Usage of the Session Description Protocol (SDP)......  136
-   B.1        Configuring Media Streams ...........................  136
-   B.2        Setting SDP Values for Unicast ......................  138
-   B.3        Multicast Operation .................................  139
-   B.4        Delayed Media Streams ...............................  139
-   B.5        Putting Media Streams on Hold .......................  139
-   B.6        Subject and SDP "s=" Line ...........................  140
-   B.7        The SDP "o=" Line ...................................  140
-   C          Summary of Augmented BNF ............................  141
-   C.1        Basic Rules .........................................  143
-   D          Using SRV DNS Records ...............................  146
-   E          IANA Considerations .................................  148
-   F          Acknowledgments .....................................  149
-   G          Authors' Addresses ..................................  149
-   H          Bibliography ........................................  150
-   I          Full Copyright Statement ............................  153
-
+   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
+   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
+   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
+   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
+   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
+   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
+   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
 
-1.1 Overview of SIP Functionality
-
-   The Session Initiation Protocol (SIP) is an application-layer control
-   protocol that can establish, modify and terminate multimedia sessions
-   or calls. These multimedia sessions include multimedia conferences,
-   distance learning, Internet telephony and similar applications. SIP
-   can invite both persons and "robots", such as a media storage
-   service.  SIP can invite parties to both unicast and multicast
-   sessions; the initiator does not necessarily have to be a member of
-   the session to which it is inviting. Media and participants can be
-   added to an existing session.
-
-   SIP can be used to initiate sessions as well as invite members to
-   sessions that have been advertised and established by other means.
-   Sessions can be advertised using multicast protocols such as SAP,
-   electronic mail, news groups, web pages or directories (LDAP), among
-   others.
-
-   SIP transparently supports name mapping and redirection services,
-   allowing the implementation of ISDN and Intelligent Network telephony
-   subscriber services. These facilities also enable personal mobility.
-   In the parlance of telecommunications intelligent network services,
-   this is defined as: "Personal mobility is the ability of end users to
-   originate and receive calls and access subscribed telecommunication
-   services on any terminal in any location, and the ability of the
-   network to identify end users as they move. Personal mobility is
-   based on the use of a unique personal identity (i.e., personal
-   number)." [1]. Personal mobility complements terminal mobility, i.e.,
-   the ability to maintain communications when moving a single end
-   system from one subnet to another.
+   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
+   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 location: determination of the end system to be used for
+           communication;
 
-   User capabilities: determination of the media and media parameters to
-        be used;
+      User availability: determination of the willingness of the called
+           party to engage in communications;
 
-   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;
 
-   Call setup: "ringing", establishment of call parameters at both
-        called and calling party;
-
-   Call handling: including transfer and termination of calls.
-
-   SIP can also initiate multi-party calls using a multipoint control
-   unit (MCU) or fully-meshed interconnection instead of multicast.
-   Internet telephony gateways that connect Public Switched Telephone
-   Network (PSTN) parties can also use SIP to set up calls between them.
-
-   SIP is designed as part of the overall IETF multimedia data and
-   control architecture currently incorporating protocols such as RSVP
-   (RFC 2205 [2]) for reserving network resources, the real-time
-   transport protocol (RTP) (RFC 1889 [3]) for transporting real-time
-   data and providing QOS feedback, the real-time streaming protocol
-   (RTSP) (RFC 2326 [4]) for controlling delivery of streaming media,
-   the session announcement protocol (SAP) [5] for advertising
-   multimedia sessions via multicast and the session description
-   protocol (SDP) (RFC 2327 [6]) for describing multimedia sessions.
-   However, the functionality and operation of SIP does not depend on
-   any of these protocols.
-
-   SIP can also be used in conjunction with other call setup and
-   signaling protocols. In that mode, an end system uses SIP exchanges
-   to determine the appropriate end system address and protocol from a
-   given address that is protocol-independent. For example, SIP could be
-   used to determine that the party can be reached via H.323 [7], obtain
-   the H.245 [8] gateway and user address and then use H.225.0 [9] to
-   establish the call.
-
-   In another example, SIP might be used to determine that the callee is
-   reachable via the PSTN and indicate the phone number to be called,
-   possibly suggesting an Internet-to-PSTN gateway 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
+   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,
-   but SIP can be used to introduce conference control protocols. SIP
-   does not allocate multicast addresses.
-
-   SIP can invite users to sessions with and without resource
-   reservation.  SIP does not reserve resources, but can convey to the
-   invited system the information necessary to do this.
+   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.
+
-1.2 Terminology
+3 Terminology
 
    In this document, the key words "MUST", "MUST NOT", "REQUIRED",
-   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
-   and "OPTIONAL" are to be interpreted as described in RFC 2119 [10]
-   and indicate requirement levels for compliant SIP implementations.
+   "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.
-
-
-1.4 Overview of SIP Operation
+4 Overview of Operation
-
-   This section explains the basic protocol functionality and operation.
-   Callers and callees are identified by SIP addresses, described in
-   Section 1.4.1. When making a SIP call, a caller first locates the
-   appropriate server (Section 1.4.2) and then sends a SIP request
-   (Section 1.4.3). The most common SIP operation is the invitation
-   (Section 1.4.4). Instead of directly reaching the intended callee, a
-   SIP request may be redirected or may trigger a chain of new SIP
-   requests by proxies (Section 1.4.5). Users can register their
-   location(s) with SIP servers (Section 4.2.6).
+   This section introduces the basic operations of SIP using simple
+   examples.  This section is tutorial in nature and does not contain
+   any normative statements.
-
-1.4.1 SIP Addressing
-
-   The "objects" addressed by SIP are users at hosts, identified by a
-   SIP URL. The SIP URL takes a form similar to a mailto or telnet URL,
-   i.e., user@host.  The user part is a user name or a telephone number.
-   The host part is either a domain name or a numeric network address.
-   See section 2 for a detailed discussion of SIP URL's.
-
-   A user's SIP address can be obtained out-of-band, can be learned via
-   existing media agents, can be included in some mailers' message
-   headers, or can be recorded during previous invitation interactions.
-   In many cases, a user's SIP URL can be guessed from their email
-   address.
-
-   A SIP URL address can designate an individual (possibly located at
-   one of several end systems), the first available person from a group
-   of individuals or a whole group. The form of the address, for
-   example, sip:sales@example.com , is not sufficient, in general, to
-   determine the intent of the caller.
-
-   If a user or service chooses to be reachable at an address that is
-   guessable from the person's name and organizational affiliation, the
-   traditional method of ensuring privacy by having an unlisted "phone"
-   number is compromised. However, unlike traditional telephony, SIP
-   offers authentication and access control mechanisms and can avail
-   itself of lower-layer security mechanisms, so that client software
-   can reject unauthorized or undesired call attempts.
-
-1.4.2 Locating a SIP Server
-
-   When a client wishes to send a request, the client either sends it to
-   a locally configured SIP proxy server (as in HTTP), independent of
-   the Request-URI, or sends it to the IP address and port corresponding
-   to the Request-URI.
-
-   For the latter case, the client must determine the protocol, port and
-   IP address of a server to which to send the request. A client SHOULD
-   follow the steps below to obtain this information, but MAY follow the
-   alternative, optional procedure defined in Appendix D. At each step,
-   unless stated otherwise, the client SHOULD try to contact a server at
-   the port number listed in the Request-URI. If no port number is
-   present in the Request-URI, the client uses port 5060. If the
-   Request-URI specifies a protocol (TCP or UDP), the client contacts
-   the server using that protocol. If no protocol is specified, the
-   client tries UDP (if UDP is supported). If the attempt fails, or if
-   the client doesn't support UDP but supports TCP, it then tries TCP.
-
-   A client SHOULD be able to interpret explicit network notifications
-   (such as ICMP messages) which indicate that a server is not
-   reachable, rather than relying solely on timeouts. (For socket-based
-   programs: For TCP, connect() returns ECONNREFUSED if the client could
-   not connect to a server at that address. For UDP, the socket needs to
-   be bound to the destination address using connect() rather than
-   sendto() or similar so that a second write() fails with ECONNREFUSED
-   if there is no server listening) If the client finds the server is
-   not reachable at a particular address, it SHOULD behave as if it had
-   received a 400-class error response to that request.
-
-   The client tries to find one or more addresses for the SIP server by
-   querying DNS. The procedure is as follows:
-
-
-        1.   If the host portion of the Request-URI is an IP address,
-             the client contacts the server at the given address.
-             Otherwise, the client proceeds to the next step.
-
-        2.   The client queries the DNS server for address records for
-             the host portion of the Request-URI. If the DNS server
-             returns no address records, the client stops, as it has
-             been unable to locate a server. By address record, we mean
-             A RR's, AAAA RR's, or other similar address records, chosen
-             according to the client's network protocol capabilities.
-
-
-        There are no mandatory rules on how to select a host name
-        for a SIP server. Users are encouraged to name their SIP
-        servers using the sip.domainname (i.e., sip.example.com)
-        convention, as specified in RFC 2219 [16]. Users may only
-        know an email address instead of a full SIP URL for a
-        callee, however. In that case, implementations may be able
-        to increase the likelihood of reaching a SIP server for
-        that domain by constructing a SIP URL from that email
-        address by prefixing the host name with "sip.". In the
-        future, this mechanism is likely to become unnecessary as
-        better DNS techniques, such as the one in Appendix D,
-        become widely available.
-
-   A client MAY cache a successful DNS query result. A successful query
-   is one which contained records in the answer, and a server was
-   contacted at one of the addresses from the answer. When the client
-   wishes to send a request to the same host, it MUST start the search
-   as if it had just received this answer from the name server. The
-   client MUST follow the procedures in RFC1035 [15] regarding DNS cache
-   invalidation when the DNS time-to-live expires.
-
-1.4.3 SIP Transaction
-
-   Once the host part has been resolved to a SIP server, the client
-   sends one or more SIP requests to that server and receives one or
-   more responses from the server. A request (and its retransmissions)
-   together with the responses triggered by that request make up a SIP
-   transaction.  All responses to a request contain the same values in
-   the Call-ID, CSeq, To, and From fields (with the possible addition of
-   a tag in the To field (section 6.37)). This allows responses to be
-   matched with requests. The ACK request following an INVITE is not
-   part of the transaction since it may traverse a different set of
-   hosts.
-
-
-
-   If TCP is used, request and responses within a single SIP transaction
-   are carried over the same TCP connection (see Section 10). Several
-   SIP requests from the same client to the same server MAY use the same
-   TCP connection or MAY use a new connection for each request.
-
-   If the client sent the request via unicast UDP, the response is sent
-   to the address contained in the next Via header field (Section 6.40)
-   of the response. If the request is sent via multicast UDP, the
-   response is directed to the same multicast address and destination
-   port. For UDP, reliability is achieved using retransmission (Section
-   10).
-
-   The SIP message format and operation is independent of the transport
-   protocol.
-
-1.4.4 SIP Invitation
-
-   A successful SIP invitation consists of two requests, INVITE followed
-   by ACK. The INVITE (Section 4.2.1) request asks the callee to join a
-   particular conference or establish a two-party conversation. After
-   the callee has agreed to participate in the call, the caller confirms
-   that it has received that response by sending an ACK (Section 4.2.2)
-   request. If the caller no longer wants to participate in the call, it
-   sends a BYE request instead of an ACK.
-
-   The INVITE request typically contains a session description, for
-   example written in SDP (RFC 2327 [6]) format, that provides the
-   called party with enough information to join the session. For
-   multicast sessions, the session description enumerates the media
-   types and formats that are allowed to be distributed to that session.
-   For a unicast session, the session description enumerates the media
-   types and formats that the caller is willing to use and where it
-   wishes the media data to be sent. In either case, if the callee
-   wishes to accept the call, it responds to the invitation by returning
-   a similar description listing the media it wishes to use. For a
-   multicast session, the callee SHOULD only return a session
-   description if it is unable to receive the media indicated in the
-   caller's description or wants to receive data via unicast.
-
-   The protocol exchanges for the INVITE method are shown in Fig. 1 for
-   a proxy server and in Fig. 2 for a redirect server. (Note that the
-   messages shown in the figures have been abbreviated slightly.) In
-   Fig. 1, the proxy server accepts the INVITE request (step 1),
-   contacts the location service with all or parts of the address (step
-   2) and obtains a more precise location (step 3). The proxy server
-   then issues a SIP INVITE request to the address(es) returned by the
-   location service (step 4). The user agent server alerts the user
-   (step 5) and returns a success indication to the proxy server (step
-
-
-   6). The proxy server then returns the success result to the original
-   caller (step 7). The receipt of this message is confirmed by the
-   caller using an ACK request, which is forwarded to the callee (steps
-   8 and 9). Note that an ACK can also be sent directly to the callee,
-   bypassing the proxy. All requests and responses have the same Call-
-   ID.
-
-
-
-                                         +....... cs.columbia.edu .......+
-                                         :                               :
-                                         : (~~~~~~~~~~)                  :
-                                         : ( location )                  :
-                                         : ( service  )                  :
-                                         : (~~~~~~~~~~)                  :
-                                         :     ^    |                    :
-                                         :     | hgs@lab                 :
-                                         :    2|   3|                    :
-                                         :     |    |                    :
-                                         : henning  |                    : 
-+.. cs.tu-berlin.de ..+ 1: INVITE        :     |    |                    :
-:                     :    henning@cs.col:     |   \/ 4: INVITE  5: ring :
-: cz@cs.tu-berlin.de ========================>(~~~~~~)=========>(~~~~~~) :
-:                    <........................(      )<.........(      ) :
-:                     : 7: 200 OK        :    (      )6: 200 OK (      ) :
-:                     :                  :    ( work )          ( lab  ) :
-:                     : 8: ACK           :    (      )9: ACK    (      ) :
-:                    ========================>(~~~~~~)=========>(~~~~~~) :
-+.....................+                  +...............................+
-
-  ====> SIP request                                                         
-  ....> SIP response                                                       
-  
-   ^
-   |    non-SIP protocols                                                  
-   |
-  
-
-   Figure 1: Example of SIP proxy server
-
-   The redirect server shown in Fig. 2 accepts the INVITE request (step
-   1), contacts the location service as before (steps 2 and 3) and,
-   instead of contacting the newly found address itself, returns the
-   address to the caller (step 4), which is then acknowledged via an ACK
-
-
-   request (step 5). The caller issues a new request, with the same
-   call-ID but a higher CSeq, to the address returned by the first
-   server (step 6). In the example, the call succeeds (step 7). The
-   caller and callee complete the handshake with an ACK (step 8).
-
-
-   The next section discusses what happens if the location service
-   returns more than one possible alternative.
-
-1.4.5 Locating a User
-
-   A callee may move between a number of different end systems over
-   time.  These locations can be dynamically registered with the SIP
-   server (Sections 1.4.7, 4.2.6). A location server MAY also use one or
-   more other protocols, such as finger (RFC 1288 [17]), rwhois (RFC
-   2167 [18]), LDAP (RFC 1777 [19]), multicast-based protocols [20] or
-   operating-system dependent mechanisms to actively determine the end
-   system where a user might be reachable. A location server MAY return
-   several locations because the user is logged in at several hosts
-   simultaneously or because the location server has (temporarily)
-   inaccurate information. The SIP server combines the results to yield
-   a list of a zero or more locations.
-
-   The action taken on receiving a list of locations varies with the
-   type of SIP server. A SIP redirect server returns the list to the
-   client as Contact headers (Section 6.13). A SIP proxy server can
-   sequentially or in parallel try the addresses until the call is
-   successful (2xx response) or the callee has declined the call (6xx
-   response). With sequential attempts, a proxy server can implement an
-   "anycast" service.
-
-   If a proxy server forwards a SIP request, it MUST add itself to the
-   beginning of the list of forwarders noted in the Via (Section 6.40)
-   headers. The Via trace ensures that replies can take the same path
-   back, ensuring correct operation through compliant firewalls and
-   avoiding request loops. On the response path, each host MUST remove
-   its Via, so that routing internal information is hidden from the
-   callee and outside networks. A proxy server MUST check that it does
-   not generate a request to a host listed in the Via sent-by, via-
-   received or via-maddr parameters (Section 6.40). (Note: If a host has
-   several names or network addresses, this does not always work.  Thus,
-   each host also checks if it is part of the Via list.)
-
-   A SIP invitation may traverse more than one SIP proxy server. If one
-   of these "forks" the request, i.e., issues more than one request in
-   response to receiving the invitation request, it is possible that a
-   client is reached, independently, by more than one copy of the
-
-   invitation request. Each of these copies bears the same Call-ID. The
-   user agent MUST return the same status response returned in the first
-   response. Duplicate requests are not an error.
-
-1.4.6 Changing an Existing Session
-
-   In some circumstances, it is desirable to change the parameters of an
-   existing session. This is done by re-issuing the INVITE, using the
-   same Call-ID, but a new or different body or header fields to convey
-   the new information. This re INVITE MUST have a higher CSeq than any
-   previous request from the client to the server.
-
-   For example, two parties may have been conversing and then want to
-   add a third party, switching to multicast for efficiency.  One of the
-   participants invites the third party with the new multicast address
-   and simultaneously sends an INVITE to the second party, with the new
-   multicast session description, but with the old call identifier.
-
-1.4.7 Registration Services
-
-   The REGISTER request allows a client to let a proxy or redirect
-   server know at which address(es) it can be reached. A client MAY also
-   use it to install call handling features at the server.
-
-1.3 Definitions
+6 Definitions
-
-   This specification uses a number of terms to refer to the roles
-   played by participants in SIP communications. The definitions of
-   client, server and proxy are similar to those used by the Hypertext
-   Transport Protocol (HTTP) (RFC 2068 [11]). The terms and generic
-   syntax of URI and URL are defined in RFC 2396 [12]. The following
-   terms have special significance for SIP.
+   The following terms have special significance for SIP.
-
-   Call: A call consists of all participants in a conference invited by
-        a common source. A SIP call is identified by a globally unique
-        call-id (Section 6.12). Thus, if a user is, for example, invited
-        to the same multicast session by several people, each of these
-        invitations will be a unique call. A point-to-point Internet
-        telephony conversation maps into a single SIP call. In a
-        multiparty conference unit (MCU) based call-in conference, each
-        participant uses a separate call to invite himself to the MCU.

+      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.

+      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: A call leg is identified by the combination of Call-ID, To
-        and From.
+      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: An application program that sends SIP requests. Clients may
-        or may not interact directly with a human user.  User agents and
-        proxies contain clients (and servers).
+      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), identified by a common
-        session description. A conference can have zero or more members
-        and includes the cases of a multicast conference, a full-mesh
-        conference and a two-party "telephone call", as well as
-        combinations of these.  Any number of calls can be used to
-        create a conference.
+      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: Requests sent in the direction from the caller to the
-        callee (i.e., user agent client to user agent server).
+      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.
+      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
+         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 conference
-        invitation. Note that the calling party does not have to be the
-        same as the one creating the conference.
+      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: A request sent to a user (or service) requesting
-        participation in a session. A successful SIP invitation consists
-        of two transactions: an INVITE request followed by an ACK
-        request.
+      Invitation: An INVITE request.
-
-   Invitee, invited user, called party, callee: The person or service
-        that the calling party is trying to invite to a conference.
+      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.
-
-   Isomorphic request or response: Two requests or responses are defined
-        to be isomorphic for the purposes of this document if they have
-        the same values for the Call-ID, To, From and CSeq header
-        fields. In addition, isomorphic requests have to have the same
-        Request-URI.
-
-   Location server: See location service.
-
-   Location service: A location service is used by a SIP redirect or
-        proxy server to obtain information about a callee's possible
-        location(s). Location services are offered by location servers.
-        Location servers MAY be co-located with a SIP server, but the
-        manner in which a SIP server requests location services is
-        beyond the scope of this document.
+      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
+
+
+         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.
+      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.
+      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 program that acts as both a
-        server and a client for the purpose of making requests on behalf
-        of other clients. Requests are serviced internally or by passing
-        them on, possibly after translation, to other servers. A proxy
-        interprets, and, if necessary, rewrites a request message before
-        forwarding it.
+      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 server that accepts a SIP
-        request, maps the address into zero or more new addresses and
-        returns these addresses to the client. Unlike a proxy server ,
-        it does not initiate its own SIP request. Unlike a user agent
-        server , it does not accept calls.
+      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.
+

-   Registrar: A registrar is a server that accepts REGISTER requests. A
-        registrar is typically co-located with a proxy or redirect
-        server and MAY offer location services.
+      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
-        client's application indicating that a called party is being
-        alerted (ringing).
+      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 an application program that accepts requests in
-        order to service requests and sends back responses to those
-        requests.  Servers are either proxy, redirect or user agent
-        servers or registrars.
+      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 [6]) (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 user name , session id , network type ,
-        address type and address elements in the origin field.
+      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
-        sent from the server to the client. A transaction is identified
-        by the CSeq sequence number (Section 6.17) within a single call
-        leg.  The ACK request has the same CSeq number as the
-        corresponding INVITE request, but comprises a transaction of its
-        own.
+      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
+         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.
-
-   Upstream: Responses sent in the direction from the user agent server
-        to the user agent client.
+      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 1738,
-        Section 2.2 [13].
+      URL-encoded: A character string encoded according to RFC 2396,
+         Section 2.4 [5].
+
-
-   User agent client (UAC), calling user agent: A user agent client is a
-        client application that initiates the SIP request.
+      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), called user agent: A user agent server is a
-        server application that contacts the user when a SIP request is
-        received and that returns a response on behalf of the user. The
-        response accepts, rejects or redirects the request.
+      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): An application which contains both a user agent
-        client and user agent server.
-
+      User Agent (UA): A logical entity that can act as both a user
+         agent client and user agent server.
+
-   An application program MAY be capable of acting both as a client and
-   a server. For example, a typical multimedia conference control
-   application would act as a user agent client to initiate calls or to
-   invite others to conferences and as a user agent server to accept
-   invitations. The properties of the different SIP server types are
-   summarized in Table 1.
-
+   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.
-
-    property                   redirect  proxy   user agent  registrar
-                                server   server    server
-    __________________________________________________________________
-    also acts as a SIP client     no      yes        no         no
-    returns 1xx status           yes      yes       yes         yes
-    returns 2xx status            no      yes       yes         yes
-    returns 3xx status           yes      yes       yes         yes
-    returns 4xx status           yes      yes       yes         yes
-    returns 5xx status           yes      yes       yes         yes
-    returns 6xx status            no      yes       yes         yes
-    inserts Via header            no      yes        no         no
-    accepts ACK                  yes      yes       yes         no
-
-
-   Table 1: Properties of the different SIP server types
-
-
-1.5 Protocol Properties
-
-1.5.1 Minimal State
-
-   A single conference session or call involves one or more SIP
-   request-response transactions. Proxy servers do not have to keep
-   state for a particular call, however, they MAY maintain state for a
-   single SIP transaction, as discussed in Section 12. For efficiency, a
-   server MAY cache the results of location service requests.
-
-1.5.2 Lower-Layer-Protocol Neutral
-
-   SIP makes minimal assumptions about the underlying transport and
-   network-layer protocols. The lower-layer can provide either a packet
-   or a byte stream service, with reliable or unreliable service.
-
-   In an Internet context, SIP is able to utilize both UDP and TCP as
-   transport protocols, among others. UDP allows the application to more
-   carefully control the timing of messages and their retransmission, to
-   perform parallel searches without requiring TCP connection state for
-   each outstanding request, and to use multicast. Routers can more
-   readily snoop SIP UDP packets. TCP allows easier passage through
-   existing firewalls.
-
-
-
-                                         +....... cs.columbia.edu .......+
-                                         :                               :
-                                         : (~~~~~~~~~~)                  :
-                                         : ( location )                  :
-                                         : ( service  )                  :
-                                         : (~~~~~~~~~~)                  :
-                                         :    ^   |                      :
-                                         :    | hgs@lab                  :
-                                         :   2|  3|                      :
-                                         :    |   |                      :
-                                         : henning|                      : 
-+.. cs.tu-berlin.de ..+ 1: INVITE        :    |   |                      :
-:                     :    henning@cs.col:    |   \/                     : 
-: cz@cs.tu-berlin.de =======================>(~~~~~~)                    : 
-:       | ^ |        <.......................(      )                    :
-:       | . |         : 4: 302 Moved     :   (      )                    :
-:       | . |         :    hgs@lab       :   ( work )                    :
-:       | . |         :                  :   (      )                    :
-:       | . |         : 5: ACK           :   (      )                    :
-:       | . |        =======================>(~~~~~~)                    :
-:       | . |         :                  :                               :
-+.......|...|.........+                  :                               :
-        | . |                            :                               :
-        | . |                            :                               :
-        | . |                            :                               :
-        | . |                            :                               :
-        | . | 6: INVITE hgs@lab.cs.columbia.edu                 (~~~~~~) : 
-        | . ==================================================> (      ) :
-        | ..................................................... (      ) :
-        |     7: 200 OK                  :                      ( lab  ) : 
-        |                                :                      (      ) :
-        |     8: ACK                     :                      (      ) :
-        ======================================================> (~~~~~~) :
-                                         +...............................+ 
-                                                                          
-  ====> SIP request                                                        
-  ....> SIP response                                                       
-    
-    ^
-    |   non-SIP protocols                                                  
-    |
-
-
-
-
-   Figure 2: Example of SIP redirect server
-
-   When TCP is used, SIP can use one or more connections to attempt to
-   contact a user or to modify parameters of an existing conference.
-   Different SIP requests for the same SIP call MAY use different TCP
-   connections or a single persistent connection, as appropriate.
-
-   For concreteness, this document will only refer to Internet
-   protocols.  However, SIP MAY also be used directly with protocols
-   such as ATM AAL5, IPX, frame relay or X.25. The necessary naming
-   conventions are beyond the scope of this document. User agents SHOULD
-   implement both UDP and TCP transport. Proxy, registrar, and redirect
-   servers MUST implement both UDP and TCP transport.
-
-1.5.3 Text-Based
-
-   SIP is text-based, using ISO 10646 in UTF-8 encoding throughout. This
-   allows easy implementation in languages such as Java, Tcl and Perl,
-   allows easy debugging, and most importantly, makes SIP flexible and
-   extensible. As SIP is used for initiating multimedia conferences
-   rather than delivering media data, it is believed that the additional
-   overhead of using a text-based protocol is not significant.
-
-2 SIP Uniform Resource Locators
-
-   SIP URLs are used within SIP messages to indicate the originator
-   (From), current destination (Request-URI) and final recipient (To) of
-   a SIP request, and to specify redirection addresses (Contact). A SIP
-   URL can also be embedded in web pages or other hyperlinks to indicate
-   that a particular user or service can be called via SIP. When used as
-   a hyperlink, the SIP URL indicates the use of the INVITE method.
-
-   The SIP URL scheme is defined to allow setting SIP request-header
-   fields and the SIP message-body.
-
-
-        This corresponds to the use of mailto: URLs. It makes it
-        possible, for example, to specify the subject, urgency or
-        media types of calls initiated through a web page or as
-        part of an email message.
-
-   A SIP URL follows the guidelines of RFC 2396 [12] and has the syntax
-   shown in Fig. 3. The syntax is described using Augmented Backus-Naur
-   Form (See Section C). Note that reserved characters have to be
-   escaped and that the "set of characters 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" [12].
-
-
-
-
-  SIP-URL         = "sip:" [ userinfo "@" ] hostport
-                    url-parameters [ headers ]
-  userinfo        = user [ ":" password ]
-  user            = *( unreserved | escaped
-                  | "&" | "=" | "+" | "$" | "," )
-  password        = *( unreserved | escaped
-                  | "&" | "=" | "+" | "$" | "," )
-  hostport        = host [ ":" port ]
-  host            = hostname | IPv4address
-  hostname        = *( domainlabel "." ) toplabel [ "." ]
-  domainlabel     = alphanum | alphanum *( alphanum | "-" ) alphanum
-  toplabel        = alpha | alpha *( alphanum | "-" ) alphanum
-  IPv4address     = 1*digit "." 1*digit "." 1*digit "." 1*digit
-  port            = *digit
-  url-parameters  = *( ";" url-parameter )
-  url-parameter   = transport-param | user-param | method-param
-                  | ttl-param | maddr-param | other-param
-  transport-param = "transport=" ( "udp" | "tcp" )
-  ttl-param       = "ttl=" ttl
-  ttl             = 1*3DIGIT       ; 0 to 255
-  maddr-param     = "maddr=" host
-  user-param      = "user=" ( "phone" | "ip" )
-  method-param    = "method=" Method
-  tag-param       = "tag=" UUID
-  UUID            = 1*( hex | "-" )
-  other-param     = ( token | ( token "=" ( token | quoted-string )))
-  headers         = "?" header *( "&" header )
-  header          = hname "=" hvalue
-  hname           = 1*uric
-  hvalue          = *uric
-  uric            = reserved | unreserved | escaped
-  reserved        = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
-                    "$" | ","
-  digits          = 1*DIGIT
-
-
-   Figure 3: SIP URL syntax
-
-   The URI character classes referenced above are described in Appendix
-   C.
-
-   The components of the SIP URI have the following meanings.
-
-
-
-
-telephone-subscriber  = global-phone-number | local-phone-number
-   global-phone-number   = "+" 1*phonedigit [isdn-subaddress]
-                             [post-dial]
-   local-phone-number    = 1*(phonedigit | dtmf-digit | 
-                             pause-character) [isdn-subaddress] 
-                             [post-dial]
-   isdn-subaddress       = ";isub=" 1*phonedigit
-   post-dial             = ";postd=" 1*(phonedigit | dtmf-digit
-                         |  pause-character)
-   phonedigit            = DIGIT | visual-separator
-   visual-separator      = "-" | "."
-   pause-character       = one-second-pause | wait-for-dial-tone
-   one-second-pause      = "p"
-   wait-for-dial-tone    = "w"
-   dtmf-digit            = "*" | "#" | "A" | "B" | "C" | "D"
-
-   Figure 4: SIP URL syntax; telephone subscriber
-
-   user: If the host is an Internet telephony gateway, the user field
-        MAY also encode a telephone number using the notation of
-        telephone-subscriber (Fig. 4). The telephone number is a special
-        case of a user name and cannot be distinguished by a BNF. Thus,
-        a URL parameter, user, is added to distinguish telephone numbers
-        from user names. The phone identifier is to be used when
-        connecting to a telephony gateway. Even without this parameter,
-        recipients of SIP URLs MAY interpret the pre-@ part as a phone
-        number if local restrictions on the name space for user name
-        allow it.
-
-   password: The SIP scheme MAY use the format "user:password" in the
-        userinfo field. The use of passwords in the userinfo 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.
-
-   host: The mailto: URL and RFC 822 email addresses require that
-        numeric host addresses ("host numbers") are enclosed in square
-        brackets (presumably, since host names might be numeric), while
-        host numbers without brackets are used for all other URLs. The
-        SIP URL requires the latter form, without brackets.
-
-   The issue of IPv6 literal addresses in URLs is being looked at
-   elsewhere in the IETF. SIP implementers are advised to keep up to
-   date on that activity.
-
-   port: The port number to send a request to. If not present, the
-        procedures outlined in Section 1.4.2 are used to determine the
-        port number to send a request to.
-
-   URL parameters: SIP URLs can define specific parameters of the
-        request. URL parameters are added after the host component and
-        are separated by semi-colons. The transport parameter determines
-        the the transport mechanism (UDP or TCP). UDP is to be assumed
-        when no explicit transport parameter is included. The maddr
-        parameter provides the server address to be contacted for this
-        user, overriding the address supplied in the host field.  This
-        address is typically a multicast address, but could also be the
-        address of a backup server. 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. The user parameter was described above. For example, to
-        specify to call j.doe@big.com using multicast to 239.255.255.1
-        with a ttl of 15, the following URL would be used:
+
+
+
+
+   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:
+
+
+                     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:
+
+
+
+   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
+
+   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
+
+   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
+   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.
+
+
+
+   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
+
+   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.
+
+
+
+   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.
+
+   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.

-     sip:j.doe@big.com;maddr=239.255.255.1;ttl=15
 
-   The transport, maddr, and ttl parameters MUST NOT be used in the From
-   and To header fields and the Request-URI; they are ignored if
-   present.
 
-   Headers: Headers of the SIP request can be defined with the "?"
-        mechanism within a SIP URL. The special hname "body" indicates
-        that the associated hvalue is the message-body of the SIP INVITE
-        request. Headers MUST NOT be used in the From and To header
-        fields and the Request-URI; they are ignored if present.  hname
-        and hvalue are encodings of a SIP header name and value,
-        respectively. All URL reserved characters in the header names
-        and values MUST be escaped.
-
-   Method: The method of the SIP request can be specified with the
-        method parameter.  This parameter MUST NOT be used in the From
-        and To header fields and the Request-URI; they are ignored if
-        present.
-
-   Table 2 summarizes where the components of the SIP URL can be used
-   and what default values they assume if not present.
-
-
-   Examples of SIP URLs are:
-
-
-                     default    Req.-URI  To  From  Contact  external
-      user           --         x         x   x     x        x
-      password       --         x         x         x        x
-      host           mandatory  x         x   x     x        x
-      port           5060       x         x   x     x        x
-      user-param     ip         x         x   x     x        x
-      method         INVITE                         x        x
-      maddr-param    --                             x        x
-      ttl-param      1                              x        x
-      transp.-param  --                             x        x
-      headers        --                             x        x
-
-
-   Table 2: Use and default values of URL components  for  SIP  headers,
-   Request-URI and references
-
-     sip:j.doe@big.com
-     sip:j.doe:secret@big.com;transport=tcp
-     sip:j.doe@big.com?subject=project
-     sip:+1-212-555-1212:1234@gateway.com;user=phone
-     sip:1212@gateway.com
-     sip:alice@10.1.2.3
-     sip:alice@example.com
-     sip:alice%40example.com@gateway.com
-     sip:alice@registrar.com;method=REGISTER
-
-   Within a SIP message, URLs are used to indicate the source and
-   intended destination of a request, redirection addresses and the
-   current destination of a request. Normally all these fields will
-   contain SIP URLs.
-
-   SIP URLs are case-insensitive, so that for example the two URLs
-   sip:j.doe@example.com and SIP:J.Doe@Example.com are equivalent.  All
-   URL parameters are included when comparing SIP URLs for equality.
-
-   SIP header fields MAY contain non-SIP URLs. As an example, if a call
-   from a telephone is relayed to the Internet via SIP, the SIP From
-   header field might contain a phone URL.
-
-3 SIP Message Overview
+7 SIP Messages

-   SIP is a text-based protocol and uses the ISO 10646 character set in
+   SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279 [7]).
-   UTF-8 encoding (RFC 2279 [21]). Senders MUST terminate lines with a
-   CRLF, but receivers MUST also interpret CR and LF by themselves as
-   line terminators.

-   Except for the above difference in character sets, much of the
-   message syntax is and header fields are 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 2068 [11]).
-   In addition, we describe SIP in both prose and an augmented Backus-
-   Naur form (ABNF). See section C for an overview of ABNF.
-
-   Note, however, that SIP is not an extension of HTTP.
-
-   Unlike HTTP, SIP MAY use UDP. When sent over TCP or UDP, multiple SIP
-   transactions can be carried in a single TCP connection or UDP
-   datagram. UDP datagrams, including all headers, SHOULD NOT be larger
-   than the path maximum transmission unit (MTU) if the MTU is known, or
-   1500 bytes if the MTU is unknown.
-
-
-        The 1500 bytes accommodates encapsulation within the
-        "typical" ethernet MTU without IP fragmentation. Recent
-        studies [22] indicate that an MTU of 1500 bytes is a
-        reasonable assumption. The next lower common MTU values are
-        1006 bytes for SLIP and 296 for low-delay PPP (RFC 1191
-        [23]). Thus, another reasonable value would be a message
-        size of 950 bytes, to accommodate packet headers within the
-        SLIP MTU without fragmentation.
 
    A SIP message is either a request from a client to a server, or a
    response from a server to a client.
 
-        SIP-message  =  Request | Response

-   Both Request (section 4) and Response (section 5) messages use the
+   Both Request (section 7.1) and Response (section 7.2) messages use the
-   generic-message format of RFC 822 [24] for transferring entities (the body of the message).
+   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
+   Both types of messages consist of a start-line, one or more header fields, an empty line
-   (also known as "headers"), an empty line
-   (i.e., a line with nothing preceding the carriage-return line-feed (CRLF))
indicating the end of the header fields, and an optional message-body.
-   To avoid confusion with similar-named headers in HTTP, we refer to the headers describing the message body as entity
-   headers. These components are described in detail in the upcoming
-   sections.
+
generic-message  =  start-line
                    *message-header
                    CRLF
                    [ message-body ]
-        start-line       =  Request-Line |     ;Section 4.1
-                            Status-Line        ;Section 5.1
+         start-line       =  Request-Line / Status-Line
+
-        message-header  =  ( general-header
-                           | request-header
-                           | response-header
-                           | entity-header )

-   In the interest of robustness, any leading empty line(s) MUST be
-   ignored. In other words, if the Request or Response message begins
-   with one or more CRLF, CR, or LFs, these characters MUST be ignored.
+   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.
+
-4 Request
+7.1 Requests
-   The Request message format is shown below:
-
-        Request  =  Request-Line       ;  Section 4.1
-                    *( general-header
-                    | request-header
-                    | entity-header )
-                    CRLF
-                    [ message-body ]   ;  Section 8
+
-4.1 Request-Line

+   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 begins with a method token, followed by the
-   Request-URI and the protocol version, and ending with CRLF. The elements are separated by SP characters.
+   The Request-Line ends with CRLF. 
-    No CR or LF are allowed except in the final CRLF sequence.
+   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
-
-        general-header   =  Accept               ; Section 6.7
-                         |  Accept-Encoding      ; Section 6.8
-                         |  Accept-Language      ; Section 6.9
-                         |  Call-ID              ; Section 6.12
-                         |  Contact              ; Section 6.13
-                         |  CSeq                 ; Section 6.17
-                         |  Date                 ; Section 6.18
-                         |  Encryption           ; Section 6.19
-                         |  Expires              ; Section 6.20
-                         |  From                 ; Section 6.21
-                         |  Record-Route         ; Section 6.29
-                         |  Timestamp            ; Section 6.36
-                         |  To                   ; Section 6.37
-                         |  Via                  ; Section 6.40
-        entity-header    =  Content-Encoding     ; Section 6.14
-                         |  Content-Length       ; Section 6.15
-                         |  Content-Type         ; Section 6.16
-        request-header   =  Authorization        ; Section 6.11
-                         |  Contact              ; Section 6.13
-                         |  Hide                 ; Section 6.22
-                         |  Max-Forwards         ; Section 6.23
-                         |  Organization         ; Section 6.24
-                         |  Priority             ; Section 6.25
-                         |  Proxy-Authorization  ; Section 6.27
-                         |  Proxy-Require        ; Section 6.28
-                         |  Route                ; Section 6.33
-                         |  Require              ; Section 6.30
-                         |  Response-Key         ; Section 6.31
-                         |  Subject              ; Section 6.35
-                         |  User-Agent           ; Section 6.39
-        response-header  =  Allow                ; Section 6.10
-                         |  Proxy-Authenticate   ; Section 6.26
-                         |  Retry-After          ; Section 6.32
-                         |  Server               ; Section 6.34
-                         |  Unsupported          ; Section 6.38
-                         |  Warning              ; Section 6.41
-                         |  WWW-Authenticate     ; Section 6.42
-
-
-   Table 3: SIP headers

-4.2 Methods
-
-   The methods are defined below. Methods that are not supported by a
-   proxy or redirect server are treated by that server as if they were
-   an OPTIONS method and forwarded accordingly. Methods that are not
-   supported by a user agent server or registrar cause a 501 (Not
-   Implemented) response to be returned (Section 7). As in HTTP, the
-   Method token is case-sensitive.
-
-        Method  =  "INVITE" | "ACK" | "OPTIONS" | "BYE"
-                   | "CANCEL" | "REGISTER"

+      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.
+
+
+      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.

-4.2.1 INVITE
-
-   The INVITE method indicates that the user or service is being invited
-   to participate in a session. The message body contains a description
-   of the session to which the callee is being invited. For two-party
-   calls, the caller indicates the type of media it is able to receive
-   and possibly the media it is willing to send as well as their
-   parameters such as network destination. A success response MUST
-   indicate in its message body which media the callee wishes to receive
-   and MAY indicate the media the callee is going to send.
-
-
-        Not all session description formats have the ability to
-        indicate sending media.
-
-   A server MAY automatically respond to an invitation for a conference
-   the user is already participating in, identified either by the SIP
-   Call-ID or a globally unique identifier within the session
-   description, with a 200 (OK) response.
-
-   If a user agent receives an INVITE request for an existing call leg
-   with a higher CSeq sequence number than any previous INVITE for the
-   same Call-ID, 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. It MUST also
-   inspect any other header fields for changes. If there is a change,
-   the user agent MUST update any internal state or information
-   generated as a result of that header. If the session description has
-   changed, the user agent server 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.)
-
-   This method MUST be supported by SIP proxy, redirect and user agent
-   servers as well as clients.
-
-
-4.2.2 ACK
-
-   The ACK request confirms that the client has received a final
-   response to an INVITE request. (ACK is used only with INVITE
-   requests.) 2xx responses are acknowledged by client user agents, all
-   other final responses by the first proxy or client user agent to
-   receive the response. The Via is always initialized to the host that
-   originates the ACK request, i.e., the client user agent after a 2xx
-   response or the first proxy to receive a non-2xx final response. The
-   ACK request is forwarded as the corresponding INVITE request, based
-   on its Request-URI. See Section 10 for details.
-
-   The ACK request MAY contain a message body with the final session
-   description to be used by the callee. If the ACK message body is
-   empty, the callee uses the session description in the INVITE request.
-
-   A proxy server receiving an ACK request after having sent a 3xx, 4xx,
-   5xx, or 6xx response must make a determination about whether the ACK
-   is for it, or for some user agent or proxy server further downstream.
-   This determination is made by examining the tag in the To field. If
-   the tag in the ACK To header field matches the tag in the To header
-   field of the response, and the From, CSeq and Call-ID header fields
-   in the response match those in the ACK, the ACK is meant for the
-   proxy server. Otherwise, the ACK SHOULD be proxied downstream as any
-   other request.
-
-
-        It is possible for a user agent client or proxy server to
-        receive multiple 3xx, 4xx, 5xx, and 6xx responses to a
-        request along a single branch. This can happen under
-        various error conditions, typically when a forking proxy
-        transitions from stateful to stateless before receiving all
-        responses. The various responses will all be identical,
-        except for the tag in the To field, which is different for
-        each one. It can therefore be used as a means to
-        disambiguate them.
-
-   This method MUST be supported by SIP proxy, redirect and user agent
-   servers as well as clients.
-
-4.2.3 OPTIONS
-
-   The server is being queried as to its capabilities. A server that
-   believes it can contact the user, such as a user agent where the user
-   is logged in and has been recently active, MAY respond to this
-   request with a capability set. A called user agent MAY return a
-   status reflecting how it would have responded to an invitation, e.g.,
-
-   600 (Busy). Such a server SHOULD return an Allow header field
-   indicating the methods that it supports. Proxy and redirect servers
-   simply forward the request without indicating their capabilities.
-
-   This method MUST be supported by SIP proxy, redirect and user agent
-   servers, registrars and clients.
-
-4.2.4 BYE
-
-   The user agent client uses BYE to indicate to the server that it
-   wishes to release the call. A BYE request is forwarded like an INVITE
-   request and MAY be issued by either caller or callee. A party to a
-   call SHOULD issue a BYE request before releasing a call ("hanging
-   up"). A party receiving a BYE request MUST cease transmitting media
-   streams specifically directed at the party issuing the BYE request.
-
-   If the INVITE request contained a Contact header, the callee SHOULD
-   send a BYE request to that address rather than the From address.
-
-   This method MUST be supported by proxy servers and SHOULD be
-   supported by redirect and user agent SIP servers.
-
-4.2.5 CANCEL
-
-   The CANCEL request cancels a pending request with the same Call-ID,
-   To, From and CSeq (sequence number only) header field values, but
-   does not affect a completed request. (A request is considered
-   completed if the server has returned a final status response.)
-
-   A user agent client or proxy client MAY issue a CANCEL request at any
-   time. A proxy, in particular, MAY choose to send a CANCEL to
-   destinations that have not yet returned a final response after it has
-   received a 2xx or 6xx response for one or more of the parallel-search
-   requests. A proxy that receives a CANCEL request forwards the request
-   to all destinations with pending requests.
-
-   The Call-ID, To, the numeric part of CSeq and From headers in the
-   CANCEL request are identical to those in the original request. This
-   allows a CANCEL request to be matched with the request it cancels.
-   However, to allow the client to distinguish responses to the CANCEL
-   from those to the original request, the CSeq Method component is set
-   to CANCEL. The Via header field is initialized to the proxy issuing
-   the CANCEL request. (Thus, responses to this CANCEL request only
-   reach the issuing proxy.)
-
-   Once a user agent server has received a CANCEL, it MUST NOT issue a
-   2xx response for the cancelled original request.
-
-   A redirect or user agent server receiving a CANCEL request responds
-   with a status of 200 (OK) if the transaction exists and a status of
-   481 (Transaction Does Not Exist) if not, but takes no further action.
-   In particular, any existing call is unaffected.
-
-
-        The BYE request cannot be used to cancel branches of a
-        parallel search, since several branches may, through
-        intermediate proxies, find the same user agent server and
-        then terminate the call.  To terminate a call instead of
-        just pending searches, the UAC must use BYE instead of or
-        in addition to CANCEL. While CANCEL can terminate any
-        pending request other than ACK or CANCEL, it is typically
-        useful only for INVITE. 200 responses to INVITE and 200
-        responses to CANCEL are distinguished by the method in the
-        Cseq header field, so there is no ambiguity.
-
-   This method MUST be supported by proxy servers and SHOULD be
-   supported by all other SIP server types.
-
-4.2.6 REGISTER
-
-   A client uses the REGISTER method to register the address listed in
-   the To header field with a SIP server.
-
-   A user agent MAY register with a local server on startup by sending a
-   REGISTER request to the well-known "all SIP servers" multicast
-   address "sip.mcast.net" (224.0.1.75). This request SHOULD be scoped
-   to ensure it is not forwarded beyond the boundaries of the
-   administrative system. This MAY be done with either TTL or
-   administrative scopes [25], depending on what is implemented in the
-   network. SIP user agents MAY listen to that address and use it to
-   become aware of the location of other local users [20]; however, they
-   do not respond to the request.  A user agent MAY also be configured
-   with the address of a registrar server to which it sends a REGISTER
-   request upon startup.
-
-   Requests are processed in the order received. Clients SHOULD avoid
-   sending a new registration (as opposed to a retransmission) until
-   they have received the response from the server for the previous one.
-
-
-        Clients may register from different locations, by necessity
-        using different Call-ID values. Thus, the CSeq value cannot
-        be used to enforce ordering. Since registrations are
-        additive, ordering is less of a problem than if each
-        REGISTER request completely replaced all earlier ones.
-
-   The meaning of the REGISTER request-header fields is defined as
-   follows. We define "address-of-record" as the SIP address that the
-   registry knows the registrand, typically of the form "user@domain"
-   rather than "user@host". In third-party registration, the entity
-   issuing the request is different from the entity being registered.
-
-   To: The To header field contains the address-of-record whose
-        registration is to be created or updated.
-
-   From: The From header field contains the address-of-record of the
-        person responsible for the registration. For first-party
-        registration, it is identical to the To header field value.
-
-   Request-URI: The Request-URI names the destination of the
-        registration request, i.e., the domain of the registrar. The
-        user name MUST be empty. Generally, the domains in the Request-
-        URI and the To header field have the same value; however, it is
-        possible to register as a "visitor", while maintaining one's
-        name. For example, a traveler sip:alice@acme.com (To) might
-        register under the Request-URI sip:atlanta.hiayh.org , with the
-        former as the To header field and the latter as the Request-URI.
-        The REGISTER request is no longer forwarded once it has reached
-        the server whose authoritative domain is the one listed in the
-        Request-URI.
-
-   Call-ID: All registrations from a client SHOULD use the same Call-ID
-        header value, at least within the same reboot cycle.
-
-   Cseq: Registrations with the same Call-ID MUST have increasing CSeq
-        header values. However, the server does not reject out-of-order
-        requests.
-
-   Contact: The request MAY contain a Contact header field; future non-
-        REGISTER requests for the URI given in the To header field
-        SHOULD be directed to the address(es) given in the Contact
-        header.
-
-   If the request does not contain a Contact header, the registration
-   remains unchanged.
-
-        This is useful to obtain the current list of registrations
-        in the response.  Registrations using SIP URIs that differ
-        in one or more of host, port, transport-param or maddr-
-        param (see Figure 3) from an existing registration are
-        added to the list of registrations. Other URI types are
-        compared according to the standard URI equivalency rules
-        for the URI schema. If the URIs are equivalent to that of
-        an existing registration, the new registration replaces the
-
-
-        old one if it has a higher q value or, for the same value
-        of q, if the ttl value is higher. All current registrations
-        MUST share the same action value.  Registrations that have
-        a different action than current registrations for the same
-        user MUST be rejected with status of 409 (Conflict).
-
-   A proxy server ignores the q parameter when processing non-REGISTER
-   requests, while a redirect server simply returns that parameter in
-   its Contact response header field.
-
-
-        Having the proxy server interpret the q parameter is not
-        sufficient to guide proxy behavior, as it is not clear, for
-        example, how long it is supposed to wait between trying
-        addresses.
-
-   If the registration is changed while a user agent or proxy server
-   processes an invitation, the new information SHOULD be used.
-
-
-        This allows a service known as "directed pick-up". In the
-        telephone network, directed pickup permits a user at a
-        remote station who hears his own phone ringing to pick up
-        at that station, dial an access code, and be connected to
-        the calling user as if he had answered his own phone.
-
-   A server MAY choose any duration for the registration lifetime.
-   Registrations not refreshed after this amount of time SHOULD be
-   silently discarded. Responses to a registration SHOULD include an
-   Expires header (Section 6.20) or expires Contact parameters (Section
-   6.13), indicating the time at which the server will drop the
-   registration. If none is present, one hour is assumed. Clients MAY
-   request a registration lifetime by indicating the time in an Expires
-   header in the request. A server SHOULD NOT use a higher lifetime than
-   the one requested, but MAY use a lower one. A single address (if
-   host-independent) MAY be registered from several different clients.
-
-   A client cancels an existing registration by sending a REGISTER
-   request with an expiration time (Expires) of zero seconds for a
-   particular Contact or the wildcard Contact designated by a "*" for
-   all registrations. Registrations are matched based on the user, host,
-   port and maddr parameters.
-
-   The server SHOULD return the current list of registrations in the 200
-   response as Contact header fields.
-
-   It is particularly important that REGISTER requests are authenticated
-   since they allow to redirect future requests (see Section 13.2).
-
-
-        Beyond its use as a simple location service, this method is
-        needed if there are several SIP servers on a single host.
-        In that case, only one of the servers can use the default
-        port number.
-
-
-   Support of this method is RECOMMENDED.
-
-4.3 Request-URI
-
-   The Request-URI is a SIP URL as described in Section 2 or a general
-   URI. It indicates the user or service to which this request is being
-   addressed. Unlike the To field, the Request-URI MAY be re-written by
-   proxies.
-
-   When used as a Request-URI, a SIP-URL MUST NOT contain the
-   transport-param, maddr-param, ttl-param, or headers elements. A
-   server that receives a SIP-URL with these elements removes them
-   before further processing.
-
-
-        Typically, the UAC sets the Request-URI and To to the same
-        SIP URL, presumed to remain unchanged over long time
-        periods. However, if the UAC has cached a more direct path
-        to the callee, e.g., from the Contact header field of a
-        response to a previous request, the To would still contain
-        the long-term, "public" address, while the Request-URI
-        would be set to the cached address.
-
-   Proxy and redirect servers MAY use the information in the Request-URI
-   and request header fields to handle the request and possibly rewrite
-   the Request-URI. For example, a request addressed to the generic
-   address sip:sales@acme.com is proxied to the particular person, e.g.,
-   sip:bob@ny.acme.com , with the To field remaining as
-   sip:sales@acme.com.  At ny.acme.com , Bob then designates Alice as
-   the temporary substitute.
-
-   The host part of the Request-URI typically agrees with one of the
-   host names of the receiving server. If it does not, the server SHOULD
-   proxy the request to the address indicated or return a 404 (Not
-   Found) response if it is unwilling or unable to do so. For example,
-   the Request-URI and server host name can disagree in the case of a
-   firewall proxy that handles outgoing calls. This mode of operation is
-   similar to that of HTTP proxies.
-
-   If a SIP server receives a request with a URI indicating a scheme
-   other than SIP which that server does not understand, the server MUST
-   return a 400 (Bad Request) response. It MUST do this even if the To
-
-
-   header field contains a scheme it does understand.  This is because
-   proxies are responsible for processing the Request-URI; the To field
-   is of end-to-end significance.
-
-4.3.1 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".
-
-4.4 Option Tags
-
-   Option tags are unique identifiers used to designate new options in
-   SIP.  These tags are used in Require (Section 6.30) and Unsupported
-   (Section 6.38) fields.
-
-   Syntax:
-
-
-        option-tag  =  token
-
-
-   See Section C for a definition of token. The creator of a new SIP
-   option MUST either prefix the option with their reverse domain name
-   or register the new option with the Internet Assigned Numbers
-   Authority (IANA). For example, "com.foo.mynewfeature" is an apt name
-   for a feature whose inventor can be reached at "foo.com".  Individual
-   organizations are then responsible for ensuring that option names
-   don't collide. Options registered with IANA have the prefix
-   "org.iana.sip.", options described in RFCs have the prefix
-   "org.ietf.rfc.N", where N is the RFC number. Option tags are case-
-   insensitive.
-
-4.4.1 Registering New Option Tags with IANA
-
-   When registering a new SIP option, the following information MUST be
-   provided:
-
-        o  Name and description of option. The name MAY be of any
-          length, but SHOULD be no more than twenty characters long. The
-          name MUST consist of alphanum (See Figure 3) characters only;
-
-
-
-
-        o  Indication of who has change control over the option (for
-          example, IETF, ISO, ITU-T, other international standardization
-          bodies, a consortium or a particular company or group of
-          companies);
-
-        o  A reference to a further description, if available, for
-          example (in order of preference) an RFC, a published paper, a
-          patent filing, a technical report, documented source code or a
-          computer manual;
-
-        o  Contact information (postal and email address);
-
-   Registrations should be sent to iana@iana.org
-
-
-        This procedure has been borrowed from RTSP [4] and the RTP
-        AVP [26].
-
-5 Response
+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.
-
-   After receiving and interpreting a request message, the recipient
-   responds with a SIP response message. The response message format is
-   shown below:
-
-        Response  =  Status-Line        ;  Section 5.1
-                     *( general-header
-                     | response-header
-                     | entity-header )
-                     CRLF
-                     [ message-body ]   ;  Section 8
-
-
-   SIP's structure of responses is similar to [H6], but is defined
-   explicitly here.
-
-5.1 Status-Line
-
-   The first line of a Response message is the Status-Line, consisting
-   of the protocol version (Section 4.3.1) followed by a numeric
-   Status-Code and its associated textual phrase, with each element
-   separated by SP characters. No CR or LF is allowed except in the
-   final CRLF sequence.

Status-Line  =  SIP-Version SP Status-Code SP Reason-Phrase CRLF

-5.1.1 Status Codes and Reason Phrases
 
    The Status-Code is a 3-digit integer result code that indicates the
-   outcome of the attempt to understand and satisfy the request. 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. 
-   The
+   A
client is not required to examine or display the Reason-Phrase.
-
-        Status-Code     =  Informational                     ;Fig. 5
-                       |   Success                           ;Fig. 5
-                       |   Redirection                       ;Fig. 6
-                       |   Client-Error                      ;Fig. 7
-                       |   Server-Error                      ;Fig. 8
-                       |   Global-Failure                    ;Fig. 9
-                       |   extension-code
-        extension-code  =  3DIGIT
-        Reason-Phrase   =  *<TEXT-UTF8,  excluding CR, LF>
-
-
-   We provide an overview of the Status-Code below, and provide full
-   definitions in Section 7. The first digit of the Status-Code defines
-   the class of response. The last two digits do not have any
-   categorization role. SIP/2.0 allows 6 values for the first digit:
+   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.
 
+   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: Informational
+      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.
 
-   Figures 5 through 9 present the individual values of the numeric
-   response codes, and an example set of corresponding reason phrases
-   for SIP/2.0. These reason phrases are only recommended; they may be
-   replaced by local equivalents without affecting the protocol. Note
-   that SIP adopts many HTTP/1.1 response codes. SIP/2.0 adds response
-   codes in the range starting at x80 to avoid conflicts with newly
-   defined HTTP response codes, and adds a new class, 6xx, of response
-   codes.
+   Section 21 defines these classes and describes the individual codes.
 
-   SIP response codes are extensible. SIP applications are not required
-   to understand the meaning of all registered response codes, though
-   such understanding is obviously desirable. However, applications MUST
-   understand the class of any response code, as indicated by the first
-   digit, and treat any unrecognized response as being equivalent to the
-   x00 response code of that class, with the exception that an
-   unrecognized response MUST NOT be cached. For example, if a client
-   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. In
-   such cases, user agents SHOULD present to the user the message body
-   returned with the response, since that message body is likely to
-   include human-readable information which will explain the unusual
-   status.
 
-        Informational  =  "100"  ;  Trying
-                      |   "180"  ;  Ringing
-                      |   "181"  ;  Call Is Being Forwarded
-                      |   "182"  ;  Queued
-        Success        =  "200"  ;  OK
-
-
-   Figure 5: Informational and success status codes
-
-
-
-        Redirection  =  "300"  ;  Multiple Choices
-                    |   "301"  ;  Moved Permanently
-                    |   "302"  ;  Moved Temporarily
-                    |   "303"  ;  See Other
-                    |   "305"  ;  Use Proxy
-                    |   "380"  ;  Alternative Service
-
-
-   Figure 6: Redirection status codes
 
-        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
-                     |   "409"  ;  Conflict
-                     |   "410"  ;  Gone
-                     |   "411"  ;  Length Required
-                     |   "413"  ;  Request Entity Too Large
-                     |   "414"  ;  Request-URI Too Large
-                     |   "415"  ;  Unsupported Media Type
-                     |   "420"  ;  Bad Extension
-                     |   "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
-   Figure 7: Client error status codes
 
 
-        Server-Error  =  "500"  ;  Internal Server Error
-                     |   "501"  ;  Not Implemented
-                     |   "502"  ;  Bad Gateway
-                     |   "503"  ;  Service Unavailable
-                     |   "504"  ;  Gateway Time-out
-                     |   "505"  ;  SIP Version not supported
-   Figure 8: Server error status codes

-        Global-Failure |  "600"  ;  Busy Everywhere
-                       |  "603"  ;  Decline
-                       |  "604"  ;  Does not exist anywhere
-                       |  "606"  ;  Not Acceptable
-
-   Figure 9: Global failure status codes

-6 Header Field Definitions
+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
-   syntax for message-header as described in [H4.2]. The
+   [H4.2] definitions of syntax for the message-header and the
rules for extending header fields over multiple lines
-  , and use of multiple message-header fields with the same field-name, described in [H4.2] also apply to SIP.
+  .  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.
-   The rules in [H4.2] regarding ordering of header fields apply to SIP,
-   with the exception of Via fields, see below, whose order matters.
-   Additionally, header fields which are hop-by-hop MUST appear before
-   any header fields which are end-to-end. Proxies SHOULD NOT reorder
-   header fields. Proxies add Via header fields and MAY add other hop-
-   by-hop header fields. They can modify certain header fields, such as
-   Max-Forwards (Section 6.23) and "fix up" the Via header fields with
-   "received" parameters as described in Section 6.40.1. Proxies MUST
-   NOT alter any fields that are authenticated (see Section 13.2).

+   [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 "*".
 

-   The header fields required, optional and not applicable for each
-   method are listed in Table 4 and Table 5. The table uses "o" to
-   indicate optional, "m" mandatory and "-" for not applicable. A "*"
-   indicates that the header fields are needed only if message body is
-   not empty. See sections 6.15, 6.16 and 8 for details.
-
-   The "where" column describes the request and response types with
-   which the header field can be used. "R" refers to header fields that
-   can be used in requests (that is, request and general header fields).
-   "r" designates a response or general-header field as applicable to
-   all responses, while a list of numeric values indicates the status
-   codes with which the header field can be used. "g" and "e" designate
-   general (Section 6.1) and entity header (Section 6.2) fields,
-   respectively. If a header field is marked "c", it is copied from the
-   request to the response.
-
-   The "enc." column describes whether this message header field MAY be
-   encrypted end-to-end. A "n" designates fields that MUST NOT be
-   encrypted, while "c" designates fields that SHOULD be encrypted if
-   encryption is used.
-
-   The "e-e" column has a value of "e" for end-to-end and a value of "h"
-   for hop-by-hop header fields.
-
-
-
-                          where  enc.  e-e ACK BYE CAN INV OPT REG
-        __________________________________________________________
-        Accept              R           e   -   -   -   o   o   o
-        Accept             415          e   -   -   -   o   o   o
-        Accept-Encoding     R           e   -   -   -   o   o   o
-        Accept-Encoding    415          e   -   -   -   o   o   o
-        Accept-Language     R           e   -   o   o   o   o   o
-        Accept-Language    415          e   -   o   o   o   o   o
-        Allow              200          e   -   -   -   -   m   -
-        Allow              405          e   o   o   o   o   o   o
-        Authorization       R           e   o   o   o   o   o   o
-        Call-ID            gc     n     e   m   m   m   m   m   m
-        Contact             R           e   o   -   -   o   o   o
-        Contact            1xx          e   -   -   -   o   o   -
-        Contact            2xx          e   -   -   -   o   o   o
-        Contact            3xx          e   -   o   -   o   o   o
-        Contact            485          e   -   o   -   o   o   o
-        Content-Encoding    e           e   o   -   -   o   o   o
-        Content-Length      e           e   o   -   -   o   o   o
-        Content-Type        e           e   *   -   -   *   *   *
-        CSeq               gc     n     e   m   m   m   m   m   m
-        Date                g           e   o   o   o   o   o   o
-        Encryption          g     n     e   o   o   o   o   o   o
-        Expires             g           e   -   -   -   o   -   o
-        From               gc     n     e   m   m   m   m   m   m
-        Hide                R     n     h   o   o   o   o   o   o
-        Max-Forwards        R     n     e   o   o   o   o   o   o
-        Organization        g     c     h   -   -   -   o   o   o
-
-
-   Table 4: Summary of header fields, A--O
-
-   Other header fields can be added as required; a server MUST ignore
-   header fields not defined in this specification that it does not
-   understand. A proxy MUST NOT remove or modify header fields not
-   defined in this specification that it does not understand. A compact
-   form of these header fields is also defined in Section 9 for use over
-   UDP when the request has to fit into a single packet and size is an
-   issue.
-
-   Table 6 in Appendix A lists those header fields that different client
-   and server types MUST be able to parse.
-
-6.1 General Header Fields
-   General header fields apply to both request and response messages.
-   The "general-header" field names can be extended reliably only in
-   combination with a change in the protocol version. However, new or
-
-
-                            where     enc.  e-e ACK BYE CAN INV OPT REG
-    ___________________________________________________________________
-    Proxy-Authenticate       407       n     h   o   o   o   o   o   o
-    Proxy-Authorization       R        n     h   o   o   o   o   o   o
-    Proxy-Require             R        n     h   o   o   o   o   o   o
-    Priority                  R        c     e   -   -   -   o   -   -
-    Require                   R              e   o   o   o   o   o   o
-    Retry-After               R        c     e   -   -   -   -   -   o
-    Retry-After          404,480,486   c     e   o   o   o   o   o   o
-                             503       c     e   o   o   o   o   o   o
-                           600,603     c     e   o   o   o   o   o   o
-    Response-Key              R        c     e   -   o   o   o   o   o
-    Record-Route              R              h   o   o   o   o   o   o
-    Record-Route             2xx             h   o   o   o   o   o   o
-    Route                     R              h   o   o   o   o   o   o
-    Server                    r        c     e   o   o   o   o   o   o
-    Subject                   R        c     e   -   -   -   o   -   -
-    Timestamp                 g              e   o   o   o   o   o   o
-    To                      gc(1)      n     e   m   m   m   m   m   m
-    Unsupported              420             e   o   o   o   o   o   o
-    User-Agent                g        c     e   o   o   o   o   o   o
-    Via                     gc(2)      n     e   m   m   m   m   m   m
-    Warning                   r              e   o   o   o   o   o   o
-    WWW-Authenticate         401       c     e   o   o   o   o   o   o
-
-
-   Table 5: Summary of header fields, P--Z; (1):  copied  with  possible
-   addition of tag; (2): UAS removes first Via header field
-
-   experimental header fields MAY be given the semantics of general
-   header fields if all parties in the communication recognize them to
-   be "general-header" fields. Unrecognized header fields are treated as
-   "entity-header" fields.
-
-6.2 Entity Header Fields
-
-   The "entity-header" fields define meta-information about the
-   message-body or, if no body is present, about the resource identified
-   by the request. The term "entity header" is an HTTP 1.1 term where
-   the response body can contain a transformed version of the message
-   body.  The original message body is referred to as the "entity". We
-   retain the same terminology for header fields but usually refer to
-   the "message body" rather then the entity as the two are the same in
-   SIP.

-6.3 Request Header Fields
-
-   The "request-header" fields allow the client to pass additional
-   information about the request, and about the client itself, to the
-   server. These fields act as request modifiers, with semantics
-   equivalent to the parameters of a programming language method
-   invocation.
-
-   The "request-header" field names can be extended reliably only in
-   combination with a change in the protocol version. However, new or
-   experimental header fields MAY be given the semantics of "request-
-   header" fields if all parties in the communication recognize them to
-   be request-header fields. Unrecognized header fields are treated as
-   "entity-header" fields.
-
-6.4 Response Header Fields
-
-   The "response-header" fields allow the server to pass additional
-   information about the response which cannot be placed in the Status-
-   Line. These header fields give information about the server and about
-   further access to the resource identified by the Request-URI.
-
-   Response-header field names can be extended reliably only in
-   combination with a change in the protocol version. However, new or
-   experimental header fields MAY be given the semantics of "response-
-   header" fields if all parties in the communication recognize them to
-   be "response-header" fields. Unrecognized header fields are treated
-   as "entity-header" fields.
-
-6.5 End-to-end and Hop-by-hop Headers
-
-   End-to-end headers MUST be transmitted unmodified across all proxies,
-   while hop-by-hop headers MAY be modified or added by proxies.
-
-6.6 Header Field Format
+7.3.1 Header Field Format
 
Header fields
-   ("general-header", "request-header", "response-header", and "entity-header")
follow the same generic header format as that given in Section
-   3.1 of RFC 822 [24].
+   2.2 of RFC 2822 [3].  
Each header field consists of a field
name followed by a colon (":") and the field value.
-   Field names are case-insensitive. The field value MAY be preceded by any amount of
-   leading white space (LWS), though a single space (SP) is preferred.
 
+      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). 
-   Applications MUST follow HTTP "common form" when generating these constructs,
-   since there might exist some implementations that fail to accept
-   anything beyond the common forms.
+   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!
-
-        message-header  =  field-name ":" [ field-value ] CRLF
-        field-name      =  token
-        field-value     =  *( field-content | LWS )
-        field-content   =  < the OCTETs  making up the field-value
-                            and consisting of either *TEXT-UTF8
-                            or combinations of token,
-                            separators, and quoted-string>
 
    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 fields with the same field-name may
+   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
-   (i.e., #(values)). change the order of these field values when a message is forwarded.
+   (that is, if follows the grammar defined in Section 7.3). 
It MUST be possible to combine the multiple header
-   fields
+   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 order in which header fields with the same field-name are received is therefore significant to the
-   interpretation of the combined field value, and thus a proxy MUST NOT
+   The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy-Authenticate, and Proxy-Authorization header fields.  Multiple header
+   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)

+   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.
+
-   Field names are not case-sensitive, although their values may be.
+   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
+   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.)
+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.
+
+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.
+
+
+
+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>
+
+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
+   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
+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
+   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
+   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
+   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.
+
+
+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.
+
+
+
+   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.
+
+
+
+   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.
+   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
+   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.
+   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.
+
+
+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.
+
+
+   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
+
+
+   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
+   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.
+
+      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.
+
+
+   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
+
+   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.
+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
+   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.
+
+
+      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.
+
+
+
+
+
+
+                                                 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.
+
+
+
+   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.
+
+
+   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.
+
+
+
+   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.
+   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.
+
+
+
+   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.
+
+
+
+
+      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.
+         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.
+
+   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
+
+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].
+
+
+
+   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
+   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
+   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.
+   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
+
+   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.
+
+
+      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
+
+      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.
+
+
+   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.
+
+
+
+   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
+   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.
+
+
+   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.
+
+
+      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".
+   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.
+
+   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.
+   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
+   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
+
+   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.
+
+      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
+   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.
+
+
+
+   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.
+
+
+   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.
+   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
+
+
+
+   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
+
+   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
+   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
+
+
+
+      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.
+
+   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.
+
+
+
+      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.
+
+      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
+
+   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
+
+
+   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
+      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.
+      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.
+         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
+         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:
+         -  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.
+
+         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
+
+
+         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.
+
+
+
+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
+
+
+
+   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
+
+
+         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
+         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
+         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.
+         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.
+
+
+         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
+         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.
+   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).
+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.
+
+
+         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.
 
 
-   header. A server MAY apply content encodings to the bodies in
-   responses. The server MUST only use encodings listed in the Accept-
-   Encoding header in the request.
+   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.
+
+
+
+   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>
+
+
+   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>
+
+
+   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
+
+   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
+      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.
+   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.
+
+
+
+   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
+
+   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
+   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.
+
+
+
+
+
+
+
+
+
+
+
+                               |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
+   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".
+
+
+
+
+   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.
+   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
+   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.
+
+
+
+
+
+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.
+   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
+   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.
+
+
+
+                               |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
+
+
+   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.
+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
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+                                  |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
+
+   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.
+
+
+
+   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
+      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
+
+
+   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).
+
+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
+
+   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.
+
+
+
+      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.
+
+
+
+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
+         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.
+
+
+         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.
+
+         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).
+
+
+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".
+   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.
+      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.
+      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
+      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.
+   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
+   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).
+   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.
+   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.
+      *: 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.
 
+      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
+
+
+
+   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

-6.7 Accept
+20.1 Accept
-   The Accept header follows the syntax defined in [H14.1]. The
-   semantics are also identical, with the exception that if no Accept
-   header is present, the server SHOULD assume a default value of
-   application/sdp.
+   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.
    Example:
 
-   This request-header field is used only with the INVITE, OPTIONS and
-   REGISTER request methods to indicate what media types are acceptable
-   in the response.
 
-   Example:

-     Accept: application/sdp;level=1, application/x-private, text/html
+
+      Accept: application/sdp;level=1, application/x-private, text/html
+
-6.8 Accept-Encoding
+20.2 Accept-Encoding

-   The Accept-Encoding request-header field is similar to Accept, but
+   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].
-   restricts the content-codings [H3.4.1] that are acceptable in the
-   response. See [H14.3]. The syntax of this header is defined in
-   [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.
+
+   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
 
-6.9 Accept-Language
+20.3 Accept-Language

-   The Accept-Language header follows the syntax defined in [H14.4]. The
-   rules for ordering the languages based on the q parameter apply to
-   SIP as well. When used in SIP, the Accept-Language request-header
-   field can be used to allow the client to indicate to the server in
-   which language it would prefer to receive reason phrases, session
+   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.
-   descriptions or status responses carried as message bodies. A proxy
-   MAY use this field to help select the destination for the call, for
-   example, a human operator conversant in a language spoken by the
-   caller.
+
+   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>
-6.10 Allow
+20.5 Allow
-   The Allow entity-header field lists the set of methods supported by
-   the resource identified by the Request-URI. The purpose of this field
-   is strictly to inform the recipient of valid methods associated with
-   the resource. An Allow header field MUST be present in a 405 (Method
-   Not Allowed) response and SHOULD be present in an OPTIONS response.
+   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
-        Allow  =  "Allow" ":" 1#Method
 
 +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"
 
-6.11 Authorization
+20.7 Authorization
-   A user agent that wishes to authenticate itself with a server --
-   usually, but not necessarily, after receiving a 401 response -- MAY
-   do so by including an Authorization request-header field with the
-   request. The Authorization field value consists of credentials
-   containing the authentication information of the user agent for the
-   realm of the resource being requested.
 +   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.

-   Section 13.2 overviews the use of the Authorization header, and
-   section 15 describes the syntax and semantics when used with PGP
-   based authentication.
+
+
+   In the example below, there are no quotes around the Digest
+   parameter:
+
+      Authorization: Digest username="Alice", realm="atlanta.com",
+       nonce="84a4cc6f3082121f32b42a2187831a9e",
+       response="7587245234b3434cc3412213e5f113a5432"

-6.12 Call-ID
+20.8 Call-ID

-   The Call-ID general-header field uniquely identifies a particular
-   invitation or all registrations of a particular client. Note that a
-   single multimedia conference can give rise to several calls with
-   different Call-IDs, e.g., if a user invites a single individual
-   several times to the same (long-running) conference.
+   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.
 
-   For an INVITE request, a callee user agent server SHOULD NOT alert
-   the user if the user has responded previously to the Call-ID in the
-   INVITE request. If the user is already a member of the conference and
-   the conference parameters contained in the session description have
-   not changed, a callee user agent server MAY silently accept the call,
-   regardless of the Call-ID. An invitation for an existing Call-ID or
-   session can change the parameters of the conference. A client
-   application MAY decide to simply indicate to the user that the
-   conference parameters have been changed and accept the invitation
-   automatically or it MAY require user confirmation.
 
+   The compact form of the Call-ID header field is i.
-   A user may be invited to the same conference or call using several
-   different Call-IDs. If desired, the client MAY use identifiers within
-   the session description to detect this duplication. For example, SDP
-   contains a session id and version number in the origin (o) field.
 +   Examples:
 
+      Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
+      i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4

-   The REGISTER and OPTIONS methods use the Call-ID value to
-   unambiguously match requests and responses. All REGISTER requests
-   issued by a single client SHOULD use the same Call-ID, at least
-   within the same boot cycle.
 
-        Since the Call-ID is generated by and for SIP, there is no
-        reason to deal with the complexity of URL-encoding and
-        case-ignoring string comparison.
 
-        Call-ID   =  ( "Call-ID" | "i" ) ":" local-id "@" host
-        local-id  =  1*uric
 
 
-   "host" SHOULD be either a fully qualified domain name or a globally
-   routable IP address. If this is the case, the "local-id" SHOULD be an
-   identifier consisting of URI characters that is unique within "host".
-   Use of cryptographically random identifiers [27] is RECOMMENDED.  If,
-   however, host is not an FQDN or globally routable IP address (such as
-   a net 10 address), the local-id MUST be globally unique, as opposed
 
 
-   to unique within host. These rules guarantee overall global
-   uniqueness of the Call-ID. The value for Call-ID MUST NOT be reused
-   for a different call.  Call-IDs are case-sensitive.
 
-        Using cryptographically random identifiers provides some
-        protection against session hijacking. Call-ID, To and From
-        are needed to identify a call leg.  The distinction between
-        call and call leg matters in calls with third-party
-        control.
 
-   For systems which have tight bandwidth constraints, many of the
-   mandatory SIP headers have a compact form, as discussed in Section 9.
-   These are alternate names for the headers which occupy less space in
-   the message. In the case of Call-ID, the compact form is i.
 
-   For example, both of the following are valid:
 
-     Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
 
-   or
 
-     i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com
+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

-6.13 Contact
-   The Contact general-header field can appear in INVITE, ACK, and
-   REGISTER requests, and in 1xx, 2xx, 3xx, and 485 responses. In
-   general, it provides a URL where the user can be reached for further
-   communications.
-
-   INVITE and ACK requests: INVITE and ACK requests MAY contain Contact
-        headers indicating from which location the request is
-        originating.
-
-
-        This allows the callee to send future requests, such as
-        BYE, directly to the caller instead of through a series of
-        proxies.  The Via header is not sufficient since the
-        desired address may be that of a proxy.
-
-   INVITE 2xx responses: A user agent server sending a definitive,
-        positive response (2xx) MAY insert a Contact response header
-        field indicating the SIP address under which it is reachable
-        most directly for future SIP requests, such as ACK, within the
-
-
-        same Call-ID. The Contact header field contains the address of
-        the server itself or that of a proxy, e.g., if the host is
-        behind a firewall. The value of this Contact header is copied
-        into the Request-URI of subsequent requests for this call if the
-        response did not also contain a Record-Route header. If the
-        response also contains a Record-Route header field, the address
-        in the Contact header field is added as the last item in the
-        Route header field. See Section 6.29 for details.
-
-
-        The Contact value SHOULD NOT be cached across calls, as it
-        may not represent the most desirable location for a
-        particular destination address.
-
-   INVITE 1xx responses: A UAS sending a provisional response (1xx) MAY
-        insert a Contact response header. It has the same semantics in a
-        1xx response as a 2xx INVITE response. Note that CANCEL requests
-        MUST NOT be sent to that address, but rather follow the same
-        path as the original request.
-
-   REGISTER requests: REGISTER requests MAY contain a Contact header
-        field indicating at which locations the user is reachable. The
-        REGISTER request defines a wildcard Contact field, "*", which
-        MUST only be used with Expires: 0 to remove all registrations
-        for a particular user. An optional "expires" parameter indicates
-        the desired expiration time of the registration. If a Contact
-        entry does not have an "expires" parameter, the Expires header
-        field is used as the default value. If neither of these
-        mechanisms is used, SIP URIs are assumed to expire after one
-        hour. Other URI schemes have no expiration times.
-
-   REGISTER 2xx responses: A REGISTER response MAY return all locations
-        at which the user is currently reachable.  An optional "expires"
-        parameter indicates the expiration time of the registration. If
-        a Contact entry does not have an "expires" parameter, the value
-        of the Expires header field indicates the expiration time. If
-        neither mechanism is used, the expiration time specified in the
-        request, explicitly or by default, is used.
-
-   3xx and 485 responses: The Contact response-header field can be used
-        with a 3xx or 485 (Ambiguous) response codes to indicate one or
-        more alternate addresses to try. It can appear in responses to
-        BYE, INVITE and OPTIONS methods. The Contact header field
-        contains URIs giving the new locations or user names to try, or
-        may simply specify additional transport parameters. A 300
-        (Multiple Choices), 301 (Moved Permanently), 302 (Moved
-        Temporarily) or 485 (Ambiguous) response SHOULD contain a
-        Contact field containing URIs of new addresses to be tried. A
-
-
-        301 or 302 response may also give the same location and username
-        that was being tried 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. The
-        client copies the "user", "password", "host", "port" and "user-
-        param" elements of the Contact URI into the Request-URI of the
-        redirected request and directs the request to the address
-        specified by the "maddr" and "port" parameters, using the
-        transport protocol given in the "transport" parameter. If
-        "maddr" is a multicast address, the value of "ttl" is used as
-        the time-to-live value.
-
-   Note that the Contact header field MAY also refer to a different
-   entity than the one originally called. For example, a SIP call
-   connected to GSTN gateway may need to deliver a special information
    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
-   URLs. For example, it could contain URL's for phones, fax, or irc (if
-   they were defined) or a mailto: (RFC 2368, [28]) URL.
-
-   The following parameters are defined. Additional parameters may be
-   defined in other specifications.
-
-   q: The "qvalue" indicates the relative preference among the locations
-        given. "qvalue" values are decimal numbers from 0 to 1, with
-        higher values indicating higher preference.
-
-   action: The "action" parameter is used only when registering with the
-        REGISTER request. It indicates whether the client wishes that
-        the server proxy or redirect future requests intended for the
-        client. If this parameter is not specified the action taken
-        depends on server configuration. In its response, the registrar
-        SHOULD indicate the mode used. This parameter is ignored for
-        other requests.
-
-   expires: The "expires" parameter indicates how long the URI is valid.
-        The parameter is either a number indicating seconds or a quoted
-        string containing a SIP-date. If this parameter is not provided,
-        the value of the Expires header field determines how long the
-        URI is valid. Implementations MAY treat values larger than
-        2**32-1 (4294967295 seconds or 136 years) as equivalent to
-        2**32-1.
-
-   Contact = ( "Contact" | "m" ) ":" 
-             ("*" | (1# (( name-addr | addr-spec )
-             [ *( ";" contact-params ) ] [ comment ] )))
-
-   name-addr      = [ display-name ] "<" addr-spec ">"
-   addr-spec      = SIP-URL | URI
-   display-name   = *token | quoted-string
-
-   contact-params = "q"       "=" qvalue
-                  | "action"  "=" "proxy" | "redirect"
-                  | "expires" "=" delta-seconds | <"> SIP-date <">
-                  | extension-attribute
-
-   extension-attribute = extension-name [ "=" extension-value ]
-
-        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 current syntax corresponds to that for the To and From
-        header, which also allows the use of display names.
-
-   Example:
-
-     Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
-        ;q=0.7; expires=3600,
-        "Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
 
-6.14 Content-Encoding
 
-        Content-Encoding  =  ( "Content-Encoding" | "e" ) ":"
-                             1#content-coding
 
-   The Content-Encoding entity-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, the content
-   codings MUST be listed in the order in which they were applied.
-
-   All content-coding values are case-insensitive. The Internet Assigned
-   Numbers Authority (IANA) acts as a registry for content-coding value
-   tokens. See [3.5] for a definition of the syntax for content-coding.
 
-   Clients MAY apply content encodings to the body in requests. If the
-   server is not capable of decoding the body, or does not recognize any
-   of the content-coding values, it MUST send a 415 "Unsupported Media
-   Type" response, listing acceptable encodings in the Accept-Encoding
-6.15 Content-Length
 
-   The Content-Length entity-header field indicates the size of the
-   message-body, in decimal number of octets, sent to the recipient.
 
-        Content-Length  =  ( "Content-Length" | "l" ) ":" 1*DIGIT
 
-   An example is
 
-     Content-Length: 3495
 
-   Applications SHOULD use this field to indicate the size of the
-   message-body to be transferred, regardless of the media type of the
-   entity. 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 MUST be set to zero. If a server receives a UDP request
-   without Content-Length, it MUST assume that the request encompasses
-   the remainder of the packet.  If a server receives a UDP request with
-   a Content-Length, but the value is larger than the size of the body
-   sent in the request, the client SHOULD generate a 400 class response.
-   If there is additional data in the UDP packet after the last byte of
-   the body has been read, the server MUST treat the remaining data as a
-   separate message. This allows several messages to be placed in a
-   single UDP packet.
-
-   If a response does not contain a Content-Length, the client assumes
-   that it encompasses the remainder of the UDP packet or the data until
-   the TCP connection is closed, as applicable.  Section 8 describes how
-   to determine the length of the message body.
-
-6.16 Content-Type
-
-   The Content-Type entity-header field indicates the media type of the
-   message-body sent to the recipient. The "media-type" element is
-   defined in [H3.7].
-
-        Content-Type  =  ( "Content-Type" | "c" ) ":" media-type
-
-
-   Examples of this header field are
-
-     Content-Type: application/sdp
-     Content-Type: text/html; charset=ISO-8859-4
-
-6.17 CSeq
-
-   Clients MUST add the CSeq (command sequence) general-header field to
-   every request. A CSeq header field in a request contains the request
-   method and a single decimal sequence number chosen by the requesting
-   client, unique within a single value of Call-ID. The sequence number
-   MUST be expressible as a 32-bit unsigned integer. The initial value
-   of the sequence number is arbitrary, but MUST be less than 2**31.
-   Consecutive requests that differ in request method, headers or body,
-   but have the same Call-ID MUST contain strictly monotonically
-   increasing and contiguous sequence numbers; sequence numbers do not
-   wrap around.  Retransmissions of the same request carry the same
-   sequence number, but an INVITE with a different message body or
-   different header fields (a "re-invitation") acquires a new, higher
-   sequence number. A server MUST echo the CSeq value from the request
-   in its response.  If the Method value is missing in the received CSeq
-   header field, the server fills it in appropriately.
-
-   The ACK and CANCEL requests MUST contain the same CSeq value as the
-   INVITE request that it refers to, while a BYE request cancelling an
-   invitation MUST have a higher sequence number. A BYE request with a
-   CSeq that is not higher should cause a 400 response to be generated.
-
-   A user agent server MUST remember the highest sequence number for any
-   INVITE request with the same Call-ID value. The server MUST respond
-   to, and then discard, any INVITE request with a lower sequence
-   number.
-
-   All requests spawned in a parallel search have the same CSeq value as
-   the request triggering the parallel search.
-
-        CSeq  =  "CSeq" ":" 1*DIGIT Method
-
-        Strictly speaking, CSeq header fields are needed for any
-        SIP request that can be cancelled by a BYE or CANCEL
-        request or where a client can issue several requests for
-        the same Call-ID in close succession. Without a sequence
-
-
-        number, the response to an INVITE could be mistaken for the
-        response to the cancellation (BYE or CANCEL). Also, if the
-        network duplicates packets or if an ACK is delayed until
-        the server has sent an additional response, the client
-        could interpret an old response as the response to a re-
-        invitation issued shortly thereafter. Using CSeq also makes
-        it easy for the server to distinguish different versions of
-        an invitation, without comparing the message body.
-
-   The Method value allows the client to distinguish the response to an
-   INVITE request from that of a CANCEL response. CANCEL requests can be
-   generated by proxies; if they were to increase the sequence number,
-   it might conflict with a later request issued by the user agent for
-   the same call.
-
-   With a length of 32 bits, a server 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 to use a time-based initial sequence
-   number, if the client desires. A client could, for example, choose
-   the 31 most significant bits of a 32-bit second clock as an initial
-   sequence number.
-
-   Forked requests MUST have the same CSeq as there would be ambiguity
-   otherwise between these forked requests and later BYE issued by the
-   client user agent.
 
-   Example:
 
-     CSeq: 4711 INVITE
 
-6.18 Date
 
-   Date is a general-header field. Its syntax is:
 
-        SIP-date  =  rfc1123-date
 
-   See [H14.19] for a definition of rfc1123-date. Note that unlike
-   HTTP/1.1, SIP only supports the most recent RFC1123 [29] formatting
-   for dates.
 
-   The Date header field reflects the time when the request or response
-   is first sent. Thus, retransmissions have the same Date header field
-   value as the original.
 
-        The Date header field can be used by simple end systems
-        without a battery-backed clock to acquire a notion of
-        current time.
-
-6.19 Encryption
-
-   The Encryption general-header field specifies that the content has
-   been encrypted. Section 13 describes the overall SIP security
-   architecture and algorithms. This header field is intended for end-
-   to-end encryption of requests and responses. Requests are encrypted
-   based on the public key belonging to the entity named in the To
-   header field. Responses are encrypted based on the public key
-   conveyed in the Response-Key header field. Note that the public keys
-   themselves may not be used for the encryption. This depends on the
-   particular algorithms used.
-
-   For any encrypted message, at least the message body and possibly
-   other message header fields are encrypted. An application receiving a
-   request or response containing an Encryption header field decrypts
-   the body and then concatenates the plaintext to the request line and
-   headers of the original message. Message headers in the decrypted
-   part completely replace those with the same field name in the
-   plaintext part.  (Note: If only the body of the message is to be
-   encrypted, the body has to be prefixed with CRLF to allow proper
-   concatenation.) Note that the request method and Request-URI cannot
-   be encrypted.
-
-
-        Encryption only provides privacy; the recipient has no
-        guarantee that the request or response came from the party
-        listed in the From message header, only that the sender
-        used the recipient's public key. However, proxies will not
-        be able to modify the request or response.
-
-        Encryption         =  "Encryption" ":" encryption-scheme 1*SP
-                              #encryption-params
-        encryption-scheme  =  token
-        encryption-params  =  token "=" ( token | quoted-string )
-
-        The token indicates the form of encryption used; it is
-        described in section 13.
-
-
-   The example in Figure 10 shows a message encrypted with ASCII-armored
-   PGP that was generated by applying "pgp -ea" to the payload to be
-   encrypted.
-
-
-   INVITE sip:watson@boston.bell-telephone.com SIP/2.0
-   Via: SIP/2.0/UDP 169.130.12.5
-   From: <sip:a.g.bell@bell-telephone.com>
-   To: T. A. Watson <sip:watson@bell-telephone.com>
-   Call-ID: 187602141351@worcester.bell-telephone.com
-   Content-Length: 885
-   Encryption: PGP version=2.6.2,encoding=ascii
-
-   hQEMAxkp5GPd+j5xAQf/ZDIfGD/PDOM1wayvwdQAKgGgjmZWe+MTy9NEX8O25Red
-   h0/pyrd/+DV5C2BYs7yzSOSXaj1C/tTK/4do6rtjhP8QA3vbDdVdaFciwEVAcuXs
-   ODxlNAVqyDi1RqFC28BJIvQ5KfEkPuACKTK7WlRSBc7vNPEA3nyqZGBTwhxRSbIR
-   RuFEsHSVojdCam4htcqxGnFwD9sksqs6LIyCFaiTAhWtwcCaN437G7mUYzy2KLcA
-   zPVGq1VQg83b99zPzIxRdlZ+K7+bAnu8Rtu+ohOCMLV3TPXbyp+err1YiThCZHIu
-   X9dOVj3CMjCP66RSHa/ea0wYTRRNYA/G+kdP8DSUcqYAAAE/hZPX6nFIqk7AVnf6
-   IpWHUPTelNUJpzUp5Ou+q/5P7ZAsn+cSAuF2YWtVjCf+SQmBR13p2EYYWHoxlA2/
-   GgKADYe4M3JSwOtqwU8zUJF3FIfk7vsxmSqtUQrRQaiIhqNyG7KxJt4YjWnEjF5E
-   WUIPhvyGFMJaeQXIyGRYZAYvKKklyAJcm29zLACxU5alX4M25lHQd9FR9Zmq6Jed
-   wbWvia6cAIfsvlZ9JGocmQYF7pcuz5pnczqP+/yvRqFJtDGD/v3s++G2R+ViVYJO
-   z/lxGUZaM4IWBCf+4DUjNanZM0oxAE28NjaIZ0rrldDQmO8V9FtPKdHxkqA5iJP+
-   6vGOFti1Ak4kmEz0vM/Nsv7kkubTFhRl05OiJIGr9S1UhenlZv9l6RuXsOY/EwH2
-   z8X9N4MhMyXEVuC9rt8/AUhmVQ==
-   =bOW+
-
-   Figure 10: PGP Encryption Example
-
-   Since proxies can base their forwarding decision on any combination
-   of SIP header fields, there is no guarantee that an encrypted request
-   "hiding" header fields will reach the same destination as an
-   otherwise identical un-encrypted request.
-
-6.20 Expires
-
-   The Expires entity-header field gives the date and time after which
-   the message content expires.
-
-   This header field is currently defined only for the REGISTER and
-   INVITE methods. For REGISTER, it is a request and response-header
-   field. In a REGISTER request, the client indicates how long it wishes
-   the registration to be valid. In the response, the server indicates
-
-
-   the earliest expiration time of all registrations. The server MAY
-   choose a shorter time interval than that requested by the client, but
-   SHOULD NOT choose a longer one.
-
-   For INVITE requests, it is a request and response-header field. In a
-   request, the caller can limit the validity of an invitation, for
-   example, if a client wants to limit the time duration of a search or
-   a conference invitation. A user interface MAY take this as a hint to
-   leave the invitation window on the screen even if the user is not
-   currently at the workstation. This also limits the duration of a
-   search. If the request expires before the search completes, the proxy
-   returns a 408 (Request Timeout) status. In a 302 (Moved Temporarily)
-   response, a server can advise the client of the maximal duration of
-   the redirection.
-
-   The value of this field can be either a SIP-date or an integer number
-   of seconds (in decimal), measured from the receipt of the request.
-   The latter approach is preferable for short durations, as it does not
-   depend on clients and servers sharing a synchronized clock.
-   Implementations MAY treat values larger than 2**32-1 (4294967295 or
-   136 years) as equivalent to 2**32-1.
-
-        Expires  =  "Expires" ":" ( SIP-date | delta-seconds )
-
-
-   Two examples of its use are
-
-     Expires: Thu, 01 Dec 1994 16:00:00 GMT
-     Expires: 5
-
-6.21 From
-
-   Requests and responses MUST contain a From general-header field,
-   indicating the initiator of the request. The From field MAY contain
-   the "tag" parameter. The server copies the From header field from the
-   request to the response. 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.
-
-   The SIP-URL MUST NOT contain the "transport-param", "maddr-param",
-   "ttl-param", or "headers" elements. A server that receives a SIP-URL
-   with these elements removes them before further processing.
 
-   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.
 
-        From         =  ( "From" | "f" ) ":" ( name-addr | addr-spec )
-                        *( ";" addr-params )
-        addr-params  =  tag-param
-        tag-param    =  "tag=" UUID
-        UUID         =  1*( hex | "-" )
 
-   Examples:
 
-     From: "A. G. Bell" <sip:agb@bell-telephone.com>
-     From: sip:+12125551212@server.phone2net.com
-     From: Anonymous <sip:c8oqz84zk7z@privacy.org>
 
-   The "tag" MAY appear in the From field of a request. It MUST be
-   present when it is possible that two instances of a user sharing a
-   SIP address can make call invitations with the same Call-ID.
 
-   The "tag" value MUST be globally unique and cryptographically random
-   with at least 32 bits of randomness. A single user maintains the same
-   tag throughout the call identified by the Call-ID.
-        Call-ID, To and From are needed to identify a call leg.
-        The distinction between call and call leg matters in calls
-        with multiple responses to a forked request. The format is
-        similar to the equivalent RFC 822 [24] header, but with a
-        URI instead of just an email address.
 
-6.22 Hide
 
-   A client uses the Hide request header field to indicate that it wants
-   the path comprised of the Via header fields (Section 6.40) to be
-   hidden from subsequent proxies and user agents. It can take two
-   forms: Hide: route and Hide:  hop. Hide header fields are typically
-   added by the client user agent, but MAY be added by any proxy along
-   the path.
 
-   If a request contains the "Hide: route" header field, all following
-   proxies SHOULD hide their previous hop. If a request contains the
-   "Hide: hop" header field, only the next proxy SHOULD hide the
-   previous hop and then remove the Hide option unless it also wants to
-   remain anonymous.
 
-   A server hides the previous hop by encrypting the "host" and "port"
-   parts of the top-most Via header field with an algorithm of its
-   choice. Servers SHOULD add additional "salt" to the "host" and "port"
-   information prior to encryption to prevent malicious downstream
-   proxies from guessing earlier parts of the path based on seeing
-   identical encrypted Via headers. Hidden Via fields are marked with
-   the "hidden" Via option, as described in Section 6.40.
 
-   A server that is capable of hiding Via headers MUST attempt to
-   decrypt all Via headers marked as "hidden" to perform loop detection.
-   Servers that are not capable of hiding can ignore hidden Via fields
-   in their loop detection algorithm.
 
-        If hidden headers were not marked, a proxy would have to
-        decrypt all headers to detect loops, just in case one was
-        encrypted, as the Hide: Hop option may have been removed
-        along the way.
 
-   A host MUST NOT add such a "Hide: hop" header field unless it can
-   guarantee it will only send a request for this destination to the
-   same next hop. The reason for this is that it is possible that the
-   request will loop back through this same hop from a downstream proxy.
-   The loop will be detected by the next hop if the choice of next hop
-   is fixed, but could loop an arbitrary number of times otherwise.
 
-   A client requesting "Hide: route" can only rely on keeping the
-   request path private if it sends the request to a trusted proxy.
-   Hiding the route of a SIP request is of limited value if the request
-   results in data packets being exchanged directly between the calling
-   and called user agent.
 
-   The use of Hide header fields is discouraged unless path privacy is
-   truly needed; Hide fields impose extra processing costs and
-   restrictions for proxies and can cause requests to generate 482 (Loop
-   Detected) responses that could otherwise be avoided.
 
-   The encryption of Via header fields is described in more detail in
-   Section 13.
 
-   The Hide header field has the following syntax:
 
-        Hide  =  "Hide" ":" ( "route" | "hop" )
-6.23 Max-Forwards
 
-   The Max-Forwards request-header field may 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 which appears to be
-   failing or looping in mid-chain.
 
-        Max-Forwards  =  "Max-Forwards" ":" 1*DIGIT
 
-   The Max-Forwards value is a decimal integer indicating the remaining
-   number of times this request message is allowed to be forwarded.
 
-   Each proxy or gateway recipient of a request containing a Max-
-   Forwards header field MUST check and update its value prior to
-   forwarding the request. If the received value is zero (0), the
-   recipient MUST NOT forward the request. Instead, for the OPTIONS and
-   REGISTER methods, it MUST respond as the final recipient. For all
-   other methods, the server returns 483 (Too many hops).
-
-   If the received Max-Forwards value is greater than zero, then the
-   forwarded message MUST contain an updated Max-Forwards field with a
-   value decremented by one (1).
 
-   Example:
 
-     Max-Forwards: 6
 
-6.24 Organization
 
-   The Organization general-header field conveys the name of the
-   organization to which the entity issuing the request or response
-   belongs. It MAY also be inserted by proxies at the boundary of an
-   organization.
 
-        The field MAY be used by client software to filter calls.
 
 
-        Organization  =  "Organization" ":" *TEXT-UTF8
 
-6.25 Priority
 
-   The Priority request-header field indicates the urgency of the
-   request as perceived by the client.
 
-        Priority        =  "Priority" ":" priority-value
-        priority-value  =  "emergency" | "urgent" | "normal"
-                        |  "non-urgent"
-   It is RECOMMENDED that the value of "emergency" only be used when
-   life, limb or property are in imminent danger.
 
-   Examples:
 
-     Subject: A tornado is heading our way!
-     Priority: emergency
 
-     Subject: Weekend plans
-     Priority: non-urgent
 
-        These are the values of RFC 2076 [30], with the addition of
-        "emergency".
 
-6.26 Proxy-Authenticate
 
-   The Proxy-Authenticate response-header field MUST be included as part
-   of a 407 (Proxy Authentication Required) response. The field value
-   consists of a challenge that indicates the authentication scheme and
-   parameters applicable to the proxy for this Request-URI.
 
-   Unlike its usage within HTTP, the Proxy-Authenticate header MUST be
-   passed upstream in the response to the UAC. In SIP, only UAC's can
-   authenticate themselves to proxies.
 
-   The syntax for this header is defined in [H14.33]. See 14 for further
-   details on its usage.
-   A client SHOULD cache the credentials used for a particular proxy
-   server and realm for the next request to that server. Credentials
-   are, in general, valid for a specific value of the Request-URI at a
-   particular proxy server. If a client contacts a proxy server that has
-   required authentication in the past, but the client does not have
-   credentials for the particular Request-URI, it MAY attempt to use the
-   most-recently used credential. The server responds with 401
-   (Unauthorized) if the client guessed wrong.

-        This suggested caching behavior is motivated by proxies
-        restricting phone calls to authenticated users. It seems
-        likely that in most cases, all destinations require the
-        same password. Note that end-to-end authentication is
-        likely to be destination-specific.
 
-6.27 Proxy-Authorization
 
-   The Proxy-Authorization request-header field allows the client to
-   identify itself (or its user) to a proxy which requires
-   authentication. The 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.
 
-   Unlike Authorization, the Proxy-Authorization header field applies
-   only to the next outbound proxy that demanded authentication using
-   the Proxy- Authenticate field. When multiple proxies are used in a
-   chain, the Proxy-Authorization header field is consumed by the first
-   outbound proxy that was expecting to receive credentials. A proxy MAY
-   relay the credentials from the client request to the next proxy if
-   that is the mechanism by which the proxies cooperatively authenticate
-   a given request.
 
-   See [H14.34] for a definition of the syntax, and section 14 for a
-   discussion of its usage.
 
-6.28 Proxy-Require
 
-   The Proxy-Require header field is used to indicate proxy-sensitive
-   features that MUST be supported by the proxy. Any Proxy-Require
-   header field features that are not supported by the proxy MUST be
-   negatively acknowledged by the proxy to the client if not supported.
-   Proxy servers treat this field identically to the Require field.
 
-   See Section 6.30 for more details on the mechanics of this message
-   and a usage example.
 
-6.29 Record-Route
 
-   The Record-Route request and response header field is added to a
-   request by any proxy that insists on being in the path of subsequent
-   requests for the same call leg. It contains a globally reachable
-   Request-URI that identifies the proxy server. Each proxy server adds
-   its Request-URI to the beginning of the list.
 
-   The server copies the Record-Route header field unchanged into the
-   response. (Record-Route is only relevant for 2xx responses.)
 
-   The calling user agent client copies the Record-Route header into a
-   Route header field of subsequent requests within the same call leg,
-   reversing the order of requests, so that the first entry is closest
-   to the user agent client. If the response contained a Contact header
-   field, the calling user agent adds its content as the last Route
-   header. Unless this would cause a loop, any client MUST send any
-   subsequent requests for this call leg to the first Request-URI in the
-   Route request header field and remove that entry.
 
-   The calling user agent MUST NOT use the Record-Route header field in
-   requests that contain Route header fields.
 
-        Some proxies, such as those controlling firewalls or in an
-        automatic call distribution (ACD) system, need to maintain
-        call state and thus need to receive any BYE and ACK packets
-        for the call.
 
-   The Record-Route header field has the following syntax:
 
-        Record-Route  =  "Record-Route" ":" 1# name-addr
 
-   Proxy servers SHOULD use the "maddr" URL parameter containing their
-   address to ensure that subsequent requests are guaranteed to reach
-   exactly the same server.
 
-   Example for a request that has traversed the hosts ieee.org and
-   bell-telephone.com , in that order:
 
-     Record-Route: <sip:a.g.bell@bell-telephone.com>,
-       <sip:a.bell@ieee.org>
-6.30 Require
 
-   The Require request-header field is used by clients to tell user
-   agent servers about options that the client expects the server to
-   support in order to properly process the request. If a server does
-   not understand the option, it MUST respond by returning status code
-   420 (Bad Extension) and list those options it does not understand in
-   the Unsupported header.
 
-        Require  =  "Require" ":" 1#option-tag
 
 
-   Example:
 
-   C->S:   INVITE sip:watson@bell-telephone.com SIP/2.0
-           Require: com.example.billing
-           Payment: sheep_skins, conch_shells
-
-   S->C:   SIP/2.0 420 Bad Extension
-           Unsupported: com.example.billing
-
-        This is to make sure 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.
-
-   Proxy and redirect servers MUST ignore features that are not
-   understood. If a particular extension requires that intermediate
-   devices support it, the extension MUST be tagged in the Proxy-Require
-   field as well (see Section 6.28).
-
-6.31 Response-Key
-
-   The Response-Key request-header field can be used by a client to
-   request the key that the called user agent SHOULD use to encrypt the
-   response with. The syntax is:
-
-
-        Response-Key  =  "Response-Key" ":" key-scheme 1*SP #key-param
-        key-scheme    =  token
-        key-param     =  token "=" ( token | quoted-string )
-
-
-   The "key-scheme" gives the type of encryption to be used for the
-   response. Section 13 describes security schemes.
-
-   If the client insists that the server return an encrypted response,
-   it includes a
-
-                  Require: org.ietf.sip.encrypt-response
-
-   header field in its request. If the server cannot encrypt for
-   whatever reason, it MUST follow normal Require header field
-   procedures and return a 420 (Bad Extension) response. If this Require
-   header field is not present, a server SHOULD still encrypt if it can.
-
-6.32 Retry-After
-
-   The Retry-After general-header field can be used with a 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),
-   600 (Busy), or 603 (Decline) response to indicate when the called
-   party anticipates being available again. The value of this field can
-   be either an SIP-date or an integer number of seconds (in decimal)
-   after the time of the response.
-
-   A REGISTER request MAY include this header field when deleting
-   registrations with "Contact: * ;expires: 0". The Retry-After value
-   then indicates when the user might again be reachable. The registrar
-   MAY then include this information in responses to future calls.
-
-   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.
-
-        Retry-After  =  "Retry-After" ":" ( SIP-date | delta-seconds )
-                        [ comment ] [ ";" "duration" "=" delta-seconds ]
-
-
-   Examples of its use are
-
-     Retry-After: Mon, 21 Jul 1997 18:48:34 GMT (I'm in a meeting)
-
-
-     Retry-After: Mon, 01 Jan 9999 00:00:00 GMT
-       (Dear John: Don't call me back, ever)
-     Retry-After: Fri, 26 Sep 1997 21:00:00 GMT;duration=3600
-     Retry-After: 120
-
-   In the third example, the callee is reachable for one hour starting
-   at 21:00 GMT. In the last example, the delay is 2 minutes.
-
-6.33 Route
 
-   The Route request-header field determines the route taken by a
-   request. Each host removes the first entry and then proxies the
-   request to the host listed in that entry, also using it as the
-   Request-URI. The operation is further described in Section 6.29.
 
-   The Route header field has the following syntax:
 
 
-        Route  =  "Route" ":" 1# name-addr
 
 
-6.34 Server
 
-   The Server response-header field contains information about the
-   software used by the user agent server to handle the request. The
-   syntax for this field is defined in [H14.39].
 
-6.35 Subject
 
-   This is intended to provide a summary, or to indicate the nature, of
-   the call, allowing call filtering without having to parse the session
-   description. (Also, the session description does not have to use the
-   same subject indication as the invitation.)
 
-        Subject  =  ( "Subject" | "s" ) ":" *TEXT-UTF8
 
    Example:
 
 
-     Subject: Tune in - they are talking about your work!
 
 
 
-6.36 Timestamp
 
-   The timestamp general-header field describes when the client sent the
-   request to the server. The value of the timestamp is of significance
-   only to the client and it MAY use any timescale. The server MUST echo
-   the exact same value and MAY, if it has accurate information about
-   this, add a floating point number indicating the number of seconds
-   that have elapsed since it has received the request. The timestamp is
-   used by the client to compute the round-trip time to the server so
-   that it can adjust the timeout value for retransmissions.
 
-        Timestamp  =  "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
-        delay      =  *(DIGIT) [ "." *(DIGIT) ]
 
-   Note that there MUST NOT be any LWS between a DIGIT and the decimal
-   point.
 
-6.37 To
 
-   The To general-header field specifies recipient of the request, with
-   the same SIP URL syntax as the From field.
 
-        To  =  ( "To" | "t" ) ":" ( name-addr | addr-spec )
-               *( ";" addr-params )
 
-   Requests and responses MUST contain a To general-header field,
-   indicating the desired recipient of the request. The optional
-   "display-name" is meant to be rendered by a human-user interface.
-   The UAS or redirect server copies the To header field into its
-   response, and MUST add a "tag" parameter if the request contained
-   more than one Via header field.
 
+
+
 
-        If there was more than one Via header field, the request
-        was handled by at least one proxy server. Since the
-        receiver cannot know whether any of the proxy servers
-        forked the request, it is safest to assume that they might
-        have.
 
-   The SIP-URL MUST NOT contain the "transport-param", "maddr-param",
-   "ttl-param", or "headers" elements. A server that receives a SIP-URL
-   with these elements removes them before further processing.
 
-   The "tag" parameter serves as a general mechanism to distinguish
-   multiple instances of a user identified by a single SIP URL. As
-   proxies can fork requests, the same request can reach multiple
-   instances of a user (mobile and home phones, for example). As each
-   can respond, there needs to be a means to distinguish the responses
-   from each at the caller. The situation also arises with multicast
-   requests. The tag in the To header field serves to distinguish
-   responses at the UAC. It MUST be placed in the To field of the
-   response by each instance when there is a possibility that the
-   request was forked at an intermediate proxy. The "tag" MUST be added
-   by UAS, registrars and redirect servers, but MUST NOT be inserted
-   into responses forwarded upstream by proxies. The "tag" is added for
-   all definitive responses for all methods, and MAY be added for
-   informational responses from a UAS or redirect server. All subsequent
-   transactions between two entities MUST include the "tag" parameter,
-   as described in Section 11.
 
-   See Section 6.21 for details of the "tag" parameter.
-   The "tag" parameter in To headers is ignored when matching responses
-   to requests that did not contain a "tag" in their To header.
 
-   A SIP server returns a 400 (Bad Request) response if it receives a
-   request with a To header field containing a URI with a scheme it does
-   not recognize.
+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, question mark, or
-   semicolon.
-
-   The following are examples of valid To headers:
-
-     To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
-     To: sip:+12125551212@server.phone2net.com
-
-
-        Call-ID, To and From are needed to identify a call leg.
-        The distinction between call and call leg matters in calls
-        with multiple responses from a forked request. The "tag" is
-        added to the To header field in the response to allow
-        forking of future requests for the same call by proxies,
-        while addressing only one of the possibly several
-        responding user agent servers. It also allows several
-        instances of the callee to send requests that can be
-        distinguished.
-
-6.38 Unsupported
-
-   The Unsupported response-header field lists the features not
-   supported by the server. See Section 6.30 for a usage example and
-   motivation.
-
-   Syntax:
-
-        Unsupported  =  "Unsupported" ":" 1#option-tag
-
-
-6.39 User-Agent
-
-   The User-Agent general-header field contains information about the
-   client user agent originating the request. The syntax and semantics
-   are defined in [H14.42].
-
-6.40 Via
-
-   The Via field indicates the path taken by the request so far.  This
-   prevents request looping and ensures replies take the same path as
-   the requests, which assists in firewall traversal and other unusual
-   routing situations.
-
-6.40.1 Requests
-
-   The client originating the request MUST insert into the request a Via
-   field containing its host name or network address and, if not the
-   default port number, the port number at which it wishes to receive
-   responses. (Note that this port number can differ from the UDP source
-   port number of the request.) A fully-qualified domain name is
-   RECOMMENDED. Each subsequent proxy server that sends the request
-   onwards MUST add its own additional Via field before any existing Via
-   fields. A proxy that receives a redirection (3xx) response and then
-   searches recursively, MUST use the same Via headers as on the
-   original proxied request.
-
-   A proxy SHOULD check the top-most Via header field to ensure that it
-   contains the sender's correct network address, as seen from that
-   proxy. If the sender's address is incorrect, the proxy MUST add an
-   additional "received" attribute, as described 6.40.2.
-
-
-        A host behind a network address translator (NAT) or
-        firewall may not be able to insert a network address into
-        the Via header that can be reached by the next hop beyond
-
-
-        the NAT. Use of the received attribute allows SIP requests
-        to traverse NAT's which only modify the source IP address.
-        NAT's which modify port numbers, called Network Address
-        Port Translator's (NAPT) will not properly pass SIP when
-        transported on UDP, in which case an application layer
-        gateway is required. When run over TCP, SIP stands a better
-        chance of traversing NAT's, since its behavior is similar
-        to HTTP in this case (but of course on different ports).
-
-   A proxy sending a request to a multicast address MUST add the "maddr"
-   parameter to its Via header field, and SHOULD add the "ttl"
-   parameter. If a server receives a request which contained an "maddr"
-   parameter in the topmost Via field, it SHOULD send the response to
-   the multicast address listed in the "maddr" parameter.
-
-   If a proxy server receives a request which contains its own address
-   in the Via header value, it MUST respond with a 482 (Loop Detected)
-   status code.
-
-   A proxy server MUST NOT forward a request to a multicast group which
-   already appears in any of the Via headers.
-
-
-        This prevents a malfunctioning proxy server from causing
-        loops. Also, it cannot be guaranteed that a proxy server
-        can always detect that the address returned by a location
-        service refers to a host listed in the Via list, as a
-        single host may have aliases or several network interfaces.
-
-6.40.2 Receiver-tagged Via Header Fields
-
-   Normally, every host that sends or forwards a SIP message adds a Via
-   field indicating the path traversed. However, it is possible that
-   Network Address Translators (NATs) changes the source address and
-   port of the request (e.g., from net-10 to a globally routable
-   address), in which case the Via header field cannot be relied on to
-   route replies. To prevent this, a proxy SHOULD check the top-most Via
-   header field to ensure that it contains the sender's correct network
-   address, as seen from that proxy. If the sender's address is
-   incorrect, the proxy MUST add a "received" parameter to the Via
-   header field inserted by the previous hop. Such a modified Via header
-   field is known as a receiver-tagged Via header field. An example is:
+   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").
 
-     Via: SIP/2.0/UDP erlang.bell-telephone.com:5060
-     Via: SIP/2.0/UDP 10.0.0.1:5060 ;received=199.172.136.3
-
-
-   In this example, the message originated from 10.0.0.1 and traversed a
-   NAT with the external address border.ieee.org (199.172.136.3) to
-   reach erlang.bell-telephone.com.  The latter noticed the mismatch,
-   and added a parameter to the previous hop's Via header field,
-   containing the address that the packet actually came from. (Note that
-   the NAT border.ieee.org is not a SIP server.)
-
-6.40.3 Responses
-
-   Via header fields in responses are processed by a proxy or UAC
-   according to the following rules:
-
-        1.   The first Via header field should indicate the proxy or
-             client processing this response. If it does not, discard
-             the message.  Otherwise, remove this Via field.
-
-        2.   If there is no second Via header field, this response is
-             destined for this client. Otherwise, the processing depends
-             on whether the Via field contains a "maddr" parameter or is
-             a receiver-tagged field:
-
-             - If the second Via header field contains a "maddr"
-               parameter, send the response to the multicast address
-               listed there, using the port indicated in "sent-by", or
-               port 5060 if none is present. 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. For
-               robustness, responses MUST be sent to the address
-               indicated in the "maddr" parameter even if it is not a
-               multicast address.
-
-             - If the second Via header field does not contain a "maddr"
-               parameter and is a receiver-tagged field (Section
-               6.40.2), send the message to the address in the
-               "received" parameter, using the port indicated in the
-               "sent-by" value, or using port 5060 if none is present.
-
-             - If neither of the previous cases apply, send the message
-               to the address indicated by the "sent-by" value in the
-               second Via header field.
-
-6.40.4 User Agent and Redirect Servers
-
-   A UAS or redirect server sends a response based on one of the
-   following rules:
-
-        o  If the first Via header field in the request contains a
-          "maddr" parameter, send the response to the multicast address
-
-
-          listed there, using the port indicated in "sent-by", or port
-          5060 if none is present. 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. For robustness, responses MUST
-          be sent to the address indicated in the "maddr" parameter even
-          if it is not a multicast address.
-
-        o  If the address in the "sent-by" value of the first Via field
-          differs from the source address of the packet, send the
-          response to the actual packet source address, similar to the
-          treatment for receiver-tagged Via header fields (Section
-          6.40.2).
-
-        o  If neither of these conditions is true, send the response to
-          the address contained in the "sent-by" value. If the request
-          was sent using TCP, use the existing TCP connection if
-          available.
-
-6.40.5 Syntax
-
-   The format for a Via header field is shown in Fig. 11. The defaults
-   for "protocol-name" and "transport" are "SIP" and "UDP",
-   respectively. The "maddr" parameter, designating the multicast
-   address, and the "ttl" parameter, designating the time-to-live (TTL)
-   value, are included only if the request was sent via multicast. The
-   "received" parameter is added only for receiver-added Via fields
-   (Section 6.40.2). For reasons of privacy, a client or proxy may wish
-   to hide its Via information by encrypting it (see Section 6.22). The
-   "hidden" parameter is included if this header field was hidden by the
-   upstream proxy (see 6.22). Note that privacy of the proxy relies on
-   the cooperation of the next hop, as the next-hop proxy will, by
-   necessity, know the IP address and port number of the source host.
-
-
-   The "branch" parameter is included by every forking proxy.  The token
-   MUST be unique for each distinct request generated when a proxy
-   forks. CANCEL requests MUST have the same branch value as the
-   corresponding forked request. When a response arrives at the proxy it
-   can use the branch value to figure out which branch the response
-   corresponds to. A proxy which generates a single request (non-
-   forking) MAY also insert the "branch" parameter. The identifier has
-   to be unique only within a set of isomorphic requests.
-
-
-     Via: SIP/2.0/UDP first.example.com:4000;ttl=16
-       ;maddr=224.2.0.1 ;branch=a7c6a8dlze (Example)
-     Via: SIP/2.0/UDP adk8
-
-
-
-  Via              = ( "Via" | "v") ":" 1#( sent-protocol sent-by
-                     *( ";" via-params ) [ comment ] )
-  via-params       = via-hidden | via-ttl | via-maddr 
-                   | via-received | via-branch
-  via-hidden       = "hidden"
-  via-ttl          = "ttl" "=" ttl
-  via-maddr        = "maddr" "=" maddr
-  via-received	   = "received" "=" host
-  via-branch       = "branch" "=" token
-  sent-protocol    = protocol-name "/" protocol-version "/" transport
-  protocol-name    = "SIP" | token
-  protocol-version = token
-  transport        = "UDP" | "TCP" | token
-  sent-by          = ( host [ ":" port ] ) | ( concealed-host )
-  concealed-host   = token
-  ttl              = 1*3DIGIT     ; 0 to 255
-
-
-   Figure 11: Syntax of Via header field
-
-
-6.41 Warning
-
-   The Warning response-header field is used to carry additional
-   information about the status of a response. Warning headers are sent
-   with responses and have the following format:
-
-        Warning        =  "Warning" ":" 1#warning-value
-        warning-value  =  warn-code SP warn-agent SP warn-text
-        warn-code      =  3DIGIT
-        warn-agent     =  ( host [ ":" port ] ) | pseudonym
-                          ;  the name or pseudonym of the server adding
-                          ;  the Warning header, for use in debugging
-        warn-text      =  quoted-string
-
-
-   A response MAY carry more than one Warning header.
-
-   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 cache or user, the Accept-Language field in a
-   request, or the Content-Language field in a response. The default
-   language is i-default [31].
-
+   Examples:
 
-   Any server MAY add Warning headers to a response. Proxy servers MUST
-   place additional Warning headers before any Authorization headers.
-   Within that constraint, Warning headers MUST be added after any
-   existing Warning headers not covered by a signature. A proxy server
-   MUST NOT delete any Warning header field that it received with a
-   response.
+      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
 
-   When multiple Warning headers are attached to a response, the user
-   agent SHOULD display as many of them as possible, in the order that
-   they appear in the response. If it is not possible to display all of
-   the warnings, the user agent first displays warnings that appear
-   early in the response.
-
-   The warn-code consists of three digits. A first digit of "3"
-   indicates warnings specific to SIP.
-
-   This is a list of the currently-defined "warn-code"s, each with a
-   recommended warn-text in English, and a description of its meaning.
-   Note that these warnings describe failures induced by the session
-   description.
 
-   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.
+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].
 
-   302 Incompatible transport protocol: One or more transport protocols
-        described in the session description are not available.
+   If this header field is missing, the MIME type determines the default
+   content disposition.  If there is none, "render" is assumed.
 
-   303 Incompatible bandwidth units: One or more bandwidth measurement
-        units contained in the session description were not understood.
+   Example:
 
-   304 Media type not available: One or more media types contained in
-        the session description are not available.
+      Content-Disposition: session
+20.12 Content-Encoding
 
-   305 Incompatible media format: One or more media formats contained in
-        the session description are not available.
+   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.
 
-   306 Attribute not understood: One or more of the media attributes in
-        the session description are not supported.
+   The compact form of the Content-Encoding header field is e.
+   Examples:
 
-   307 Session description parameter not understood: A parameter other
-        than those listed above was not understood.
+      Content-Encoding: gzip
+      e: tar
 
-   330 Multicast not available: The site where the user is located does
-        not support multicast.
+20.13 Content-Language
 
-   331 Unicast not available: The site where the user is located does
-        not support unicast communication (usually due to the presence
-        of a firewall).
+   See [H14.12]. Example:
 
-   370 Insufficient bandwidth: The bandwidth specified in the session
-        description or defined by the media exceeds that known to be
-        available.
+      Content-Language: fr
 
-   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.
+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.
 
-        1xx and 2xx have been taken by HTTP/1.1.
+   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.
+      The ability to omit Content-Length simplifies the creation of
+      cgi-like scripts that dynamically generate responses.
 
-   Additional "warn-code"s, as in the example below, can be defined
-   through IANA.
+   The compact form of the header field is l.
 
    Examples:
 
+      Content-Length: 349
+      l: 173
 
-     Warning: 307 isi.edu "Session parameter 'foo' not understood"
-     Warning: 301 isi.edu "Incompatible network address type 'E.164'"
-
-6.42 WWW-Authenticate
+20.15 Content-Type
 
-   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 Request-URI. See [H14.46] for a
-   definition of the syntax, and section 14 for an overview of usage.
+   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 content of the "realm" parameter SHOULD be displayed to the user.
-   A user agent SHOULD cache the authorization credentials for a given
-   value of the destination (To header) and "realm" and attempt to re-
-   use these values on the next request for that destination.
-
-   In addition to the "basic" and "digest" authentication schemes
-   defined in the specifications cited above, SIP defines a new scheme,
-   PGP (RFC 2015, [32]), Section 15. Other schemes, such as S/MIME, are
-   for further study.
+   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.
+      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.
 
+   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.
 
 
+   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
 
+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.
+   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.
 
+   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
+
+   (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.
+   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.
 
 
+   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
+   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
+   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).
+      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

-7 Status Code Definitions
+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. 
-   Response codes not defined by HTTP/1.1 have codes x80 upwards to avoid clashes with future HTTP response codes.
Also, SIP defines a new class, 6xx.
-   The default behavior for unknown response codes is given for each category of codes.
-7.1 Informational 1xx
+21.1 Provisional 1xx
-   Informational responses
+   Provisional responses, also known as informational responses,
indicate that the server 
-   or proxy
contacted is performing some further action and does not yet have a definitive response.
-   The client SHOULD wait for a further response from the server, and the server SHOULD send such a response without further prompting.
-   A server SHOULD send
+    A server sends
a 1xx response if it expects to take more than 200 ms to obtain a final response.
-   A server MAY issue zero or more 1xx responses, with no restriction on their ordering or uniqueness.
-   Note that 1xx responses are not transmitted reliably
+    Note that 1xx responses are not transmitted reliably
-  , that is, they do not
+  . They never
cause the client to send an ACK.
-   Servers are free to retransmit informational responses and clients can inquire
-   about the current state of call processing by re-sending the request.
+ Provisional (1xx) responses MAY contain message bodies, including session descriptions.
-7.1.1 100 Trying
+21.1.1 100 Trying
-   Some unspecified action is being taken on behalf of this call (e.g.,
-   a database is being consulted), but the user has not yet been
-   located.
+   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.
 
-7.1.2 180 Ringing
+21.1.2 180 Ringing
 
-   The called user agent has located a possible location where the user
-   has registered recently and is trying to alert the user.
+   The UA receiving the INVITE is trying to alert the user.  This
+   response MAY be used to initiate local ringback.
-7.1.3 181 Call Is Being Forwarded
+21.1.3 181 Call Is Being Forwarded
 A
-    proxy
server MAY use this status code to indicate that the call is being
forwarded to a different set of destinations.
-7.1.4 182 Queued
+21.1.4 182 Queued
-   The called party is temporarily unavailable, but the callee has
+   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, e.g., "5 calls queued; expected waiting
+   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.
 
-7.2 Successful 2xx
+21.2 Successful 2xx
 
-   The request was successful and MUST terminate a search.
+   The request was successful.
-7.2.1 200 OK
+21.2.1 200 OK
The request has succeeded.  The information returned with the response
 depends on the method used in the request
-  , for example:
+  .
-   BYE: The call has been terminated. The message body is empty.
-   CANCEL: The search has been cancelled. The message body is empty.
-   INVITE: The callee has agreed to participate; the message body
-        indicates the callee's capabilities.
-   OPTIONS: The callee has agreed to share its capabilities, included in
-        the message body.
-   REGISTER: The registration has succeeded. The client treats the
-        message body according to its Content-Type.
-7.3 Redirection 3xx
+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.
-   They SHOULD terminate an existing search, and MAY cause the initiator
-   to begin a new search if appropriate.
-   Any redirection (3xx) response MUST NOT suggest any of the addresses
-   in the Via (Section 6.40) path of the request in the Contact header
-   field. (Addresses match if their host and port number match.)
-   To avoid forwarding loops, a user agent client or proxy MUST check
-   whether the address returned by a redirect server equals an address
-   tried earlier.
-7.3.1 300 Multiple Choices
+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
-   user agent)
+   UA)
can select a preferred communication end point and redirect its request to that location.
-
-   The response SHOULD include an entity containing a list of resource
+   The response MAY include a message body containing a list of resource
characteristics and location(s) from which the user or
-   user agent
+   UA
can choose the one most appropriate, if allowed by the Accept
-   request header.
+   request header field. 
-   The entity format is specified by the media type given in the Content-Type header field. The choices SHOULD also be listed as
-   Contact fields (Section 6.13).  Unlike HTTP, the SIP response MAY
-   contain several Contact fields or a list of addresses in a Contact
-   field. User agents 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.
+   However, no MIME types have been defined for this message body.
-
-        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.
-
+   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.
-7.3.2 301 Moved Permanently
+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
-   6.13). The caller
+   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.
-7.3.3 302 Moved Temporarily
+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
-   6.13). 
+   20.10).
+    The Request-URI of the new request uses the value of the Contact header field in the response.

The duration of the 
-   redirection
+   validity of the Contact URI
can be indicated through an Expires (Section 
-   6.20) header.
+   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
- for this call 
+   once for recursing,
and MUST NOT be cached for future
- calls.
+    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.
-7.3.4 305 Use Proxy
+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
- user agent servers.
+ UASs.
-7.3.5 380 Alternative Service
+21.3.5 380 Alternative Service
-   The call was not successful, but alternative services are possible.
+   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.
-
-7.4 Request Failure 4xx
+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
-   (e.g.,
+    (for example, 
adding appropriate authorization).
However, the same request to a different server might be successful.
-7.4.1 400 Bad Request
+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".
-7.4.2 401 Unauthorized
+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.
-7.4.3 402 Payment Required
+21.4.3 402 Payment Required
-   Reserved for future use.
+   Reserved for future use.
 
-7.4.4 403 Forbidden
+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.
-7.4.5 404 Not Found
+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.
-7.4.6 405 Method Not Allowed
+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.

-7.4.7 406 Not Acceptable
+21.4.7 406 Not Acceptable
The resource identified by the request is only capable of generating response entities
-   which
+   that
have content characteristics not acceptable according to the
-   accept headers
+   Accept header field
sent in the request.
-7.4.8 407 Proxy Authentication Required
+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.
-   The proxy MUST return a Proxy-Authenticate header field (section 6.26) containing a
-   challenge applicable to the proxy for the requested resource. The
-   client MAY repeat the request with a suitable Proxy-Authorization
-   header field (section 6.27). SIP access authentication is explained
-   in section 13.2 and 14.

This status code 
-  is
+   can be
used for applications where access to the communication channel
-   (e.g.
+   (for example
, a telephony gateway) rather than the callee requires authentication.
-
-7.4.9 408 Request Timeout
+21.4.9 408 Request Timeout

The server could not produce a response
-   , e.g., a user location,
-   within the time indicated in the Expires request-header field.
+   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.

-7.4.10 409 Conflict
-
-   The request could not be completed due to a conflict with the current
-   state of the resource. This response is returned if the action
-   parameter in a REGISTER request conflicts with existing
-   registrations.
-7.4.11 410 Gone
+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.
-7.4.12 411 Length Required
-   The server refuses to accept the request without a defined Content-
-   Length. The client MAY repeat the request if it adds a valid
-   Content-Length header field containing the length of the message-body
-   in the request message.
-7.4.13 413 Request Entity Too Large
+21.4.11 413 Request Entity Too Large
The server is refusing to process a request because the request
-   entity
+   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.
-7.4.14 414 Request-URI Too Long
+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.
-7.4.15 415 Unsupported Media Type
+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
-   requested resource for the requested method. The server SHOULD
+   server for the requested method.  The server MUST
-   return a list of acceptable formats using the Accept, Accept-Encoding
+   return a list of acceptable formats using the Accept, Accept-Encoding
-    and Accept-Language header fields.
+  , 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.
-7.4.16 420 Bad Extension
+21.4.15 420 Bad Extension
The server did not understand the protocol extension specified in a
-   Require (Section 6.30) header field.
+   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.
+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.
-7.4.17 480 Temporarily Unavailable
+21.4.18 480 Temporarily Unavailable
The callee's end system was contacted successfully but the callee is currently unavailable
-   (e.g., not logged in or logged in in such a manner as to preclude
+   (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
-   host), thus, this response does not terminate any searches.
+   server). 
The reason phrase SHOULD indicate a more precise cause as to why the callee is
unavailable. This value SHOULD be
-    setable by the user agent.
+    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.
-7.4.18 481 Call Leg/Transaction Does Not Exist
+21.4.19 481 Call/Transaction Does Not Exist
-   This status is returned under two conditions: The server received a
-   BYE request that does not match any existing call leg or the server
-   received a CANCEL request that does not match any existing
-   transaction. (A server simply discards an ACK referring to an unknown
-   transaction.)
+   This status indicates that the UAS received a request that does not
+   match any existing dialog or transaction.
-7.4.19 482 Loop Detected
+21.4.20 482 Loop Detected
-   The server received a request with a Via (Section 6.40) path
-   containing itself.
+   The server has detected a loop (Section 16.3 Item 4).
-7.4.20 483 Too Many Hops
+21.4.21 483 Too Many Hops
-   The server received a request that contains more Via entries (hops)
-   (Section 6.40) than allowed by the Max-Forwards (Section 6.23) header
-   field.
+   The server received a request that contains a Max-Forwards (Section
+   20.22) header field with the value zero.
-7.4.21 484 Address Incomplete
+21.4.22 484 Address Incomplete
-   The server received a request with a To (Section 6.37) address or
+   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.
-7.4.22 485 Ambiguous
+21.4.23 485 Ambiguous
-   The callee address provided in the request was 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
-  concerns
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 
-   if the request address was ambiguous.
+  for ambiguous Request-URIs.

-   Example response to a request with the URL lee@example.com :
+   Example response to a request with the Request-URI
+   sip:lee@example.com:

-   485 Ambiguous SIP/2.0
+      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 <sip: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.
-7.4.23 486 Busy Here
+21.4.24 486 Busy Here
-   The callee's end system was contacted successfully but the callee is
+   The callee's end system was contacted successfully, but the callee is
-   currently not willing or able to take additional calls.
+   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.
+   The response MAY indicate a better time to call in the Retry-After header field. 
The user could also be available elsewhere, such as through a voice mail
-   service, thus, this response does not terminate any searches.
+   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.
-7.5 Server Failure 5xx
+21.5 Server Failure 5xx
5xx responses are failure responses given when a server itself has erred.
-   They are not definitive failures, and MUST NOT terminate a
-   search if other possible locations remain untried.

-7.5.1 500 Server Internal Error
+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.
-7.5.2 501 Not Implemented
+21.5.2 501 Not Implemented
The server does not support the functionality required to fulfill the request. This is the appropriate response when
-   the server
+   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.
-7.5.3 502 Bad Gateway
+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.
 
-7.5.4 503 Service Unavailable
+21.5.4 503 Service Unavailable
 
-   The server is currently unable to handle
+   The server is temporarily unable to process
the request due to a temporary overloading or maintenance of the server.  The
-   implication is that this is a temporary condition which will be alleviated after
-   some delay. If known, the length of the delay MAY be indicated in a
-   Retry-After header.
+   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
- handle the response as it would for a 500 response.
+   act as if it had received a 500 (Server Internal Error) response.

-   Note: The existence of the 503 status code does not imply that a
-   server has to use it when becoming overloaded. Some servers MAY wish
-   to simply refuse the connection.
+   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).
-
-7.5.5 504 Gateway Time-out
+21.5.5 504 Server Time-out
-
-   The server, while acting as a gateway, did not receive a timely
-   response from the server (e.g., a location server) it accessed in
-   attempting to complete the request.
+   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.
-7.5.6 505 Version Not Supported
+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.
-   The response MAY contain an entity describing why that
-   version is not supported and what other protocols are supported by
-   that server. The format for such an entity is not defined here and
-   may be the subject of future standardization.
+21.5.7 513 Message Too Large
 
+   The server was unable to process the request since the message length
+   exceeded its capabilities.
-7.6 Global Failures 6xx
+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.
-   All further searches for this user are doomed to failure and pending searches SHOULD be terminated.
-7.6.1 600 Busy Everywhere
+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.
+   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.
-7.6.2 603 Decline
+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.
+   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.
-7.6.3 604 Does Not Exist Anywhere
+21.6.3 604 Does Not Exist Anywhere
The server has authoritative information that the user indicated in
-   the To request field does not exist anywhere. Searching for the user
+   the Request-URI does not exist anywhere.
-   elsewhere will not yield any results.
-7.6.4 606 Not Acceptable
+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
+   Warning header field describing why the session described cannot be
+   supported.  Warning reason codes are listed in Section 20.43.
-   supported. Reasons are listed in Section 6.41.

+   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.
-
-8 SIP Message Body
-
-8.1 Body Inclusion
-
-   Requests MAY contain message bodies unless otherwise noted. Within
-   this specification, the BYE request MUST NOT contain a message body.
-   For ACK, INVITE and OPTIONS, the message body is always a session
-   description. The use of message bodies for REGISTER requests is for
-   further study.
 
-   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. Message bodies for 1xx responses
-   contain advisory information about the progress of the request. 2xx
-   responses to INVITE requests contain session descriptions. In 3xx
-   responses, the message body MAY contain the description of
-   alternative destinations or services, as described in Section 7.3.
-   For responses with status 400 or greater, the message body MAY
-   contain additional, human-readable information about the reasons for
-   failure. It is RECOMMENDED that information in 1xx and 300 and
-   greater responses be of type text/plain or text/html
-8.2 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.
-8.3 Message Body Length
-   The body length in bytes SHOULD be given by the Content-Length header
-   field. Section 6.15 describes the behavior 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.)
-9 Compact Form
-   When SIP is carried over UDP with authentication and a complex
-   session description, it may be possible that the size of a request or
-   response is larger than the MTU. To address this problem, a more
-   compact form of SIP is also defined by using abbreviations for the
-   common header fields listed below:
-
-
-   short field name  long field name   note
-   c                 Content-Type
-   e                 Content-Encoding
-   f                 From
-   i                 Call-ID
-   m                 Contact           from "moved"
-   l                 Content-Length
-   s                 Subject
-   t                 To
-   v                 Via
-
-
-   Thus, the message in section 16.2 could also be written:
-
-
-
-     INVITE sip:schooler@vlsi.caltech.edu SIP/2.0
-     v:SIP/2.0/UDP 131.215.131.131;maddr=239.128.16.254;ttl=16
-     v:SIP/2.0/UDP 128.16.64.19
-     f:sip:mjh@isi.edu
-     t:sip:schooler@cs.caltech.edu
-     i:62729-27@128.16.64.19
-     c:application/sdp
-     CSeq: 4711 INVITE
-     l:187
-
-     v=0
-     o=user1 53655765 2353687637 IN IP4 128.3.4.5
-     s=Mbone Audio
-     i=Discussion of Mbone Engineering Issues
-     e=mbone@somewhere.com
-     c=IN IP4 224.2.0.1/127
-     t=0 0
-     m=audio 3456 RTP/AVP 0
-
-   Clients MAY mix short field names and long field names within the
-   same request. Servers MUST accept both short and long field names for
-   requests. Proxies MAY change header fields between their long and
-   short forms, but this MUST NOT be done to fields following an
-   Authorization header.
-
-10 Behavior of SIP Clients and Servers
-
-10.1 General Remarks
-
-   SIP is defined so it can use either UDP (unicast or multicast) or TCP
-   as a transport protocol; it provides its own reliability mechanism.
-
-10.1.1 Requests
-
-   Servers discard isomorphic requests, but first retransmit the
-   appropriate response. (SIP requests are said to be idempotent , i.e.,
-   receiving more than one copy of a request does not change the server
-   state.)
-
-   After receiving a CANCEL request from an upstream client, a stateful
-   proxy server MAY send a CANCEL on all branches where it has not yet
-   received a final response.
-
-   When a user agent receives a request, it checks the Call-ID against
-   those of in-progress calls. If the Call-ID was found, it compares the
-   tag value of To with the user's tag and rejects the request if the
-
-
-   two do not match. If the From header, including any tag value,
-   matches the value for an existing call leg, the server compares the
-   CSeq header field value. If less than or equal to the current
-   sequence number, the request is a retransmission.  Otherwise, it is a
-   new request. If the From header does not match an existing call leg,
-   a new call leg is created.
-
-   If the Call-ID was not found, a new call leg is created, with entries
-   for the To, From and Call-ID headers.  In this case, the To header
-   field should not have contained a tag. The server returns a response
-   containing the same To value, but with a unique tag added. The tag
-   MAY be omitted if the request contained only one Via header field.
-
-10.1.2 Responses
-
-   A server MAY issue one or more provisional responses at any time
-   before sending a final response. If a stateful proxy, user agent
-   server, redirect server or registrar cannot respond to a request with
-   a final response within 200 ms, it SHOULD issue a provisional (1xx)
-   response as soon as possible. Stateless proxies MUST NOT issue
-   provisional responses on their own.
-
-   Responses are mapped to requests by the matching To, From, Call-ID,
-   CSeq headers and the branch parameter of the first Via header.
-   Responses terminate request retransmissions even if they have Via
-   headers that cause them to be delivered to an upstream client.
-
-   A stateful proxy may receive a response that it does not have state
-   for, that is, where it has no a record of an associated request. If
-   the Via header field indicates that the upstream server used TCP, the
-   proxy actively opens a TCP connection to that address. Thus, proxies
-   have to be prepared to receive responses on the incoming side of
-   passive TCP connections, even though most responses will arrive on
-   the incoming side of an active connection. (An active connection is a
-   TCP connection initiated by the proxy, a passive connection is one
-   accepted by the proxy, but initiated by another entity.)
-
-   100 responses SHOULD NOT be forwarded, other 1xx responses MAY be
-   forwarded, possibly after the server eliminates responses with status
-   codes that had already been sent earlier. 2xx responses are forwarded
-   according to the Via header. Once a stateful proxy has received a 2xx
-   response, it MUST NOT forward non-2xx final responses.  Responses
-   with status 300 and higher are retransmitted by each stateful proxy
-   until the next upstream proxy sends an ACK (see below for timing
-   details) or CANCEL.
-
-
-
-   A stateful proxy SHOULD maintain state for at least 32 seconds after
-   the receipt of the first definitive non-200 response, in order to
-   handle retransmissions of the response.
-
-
-        The 32 second window is given by the maximum retransmission
-        duration of 200-class responses using the default timers,
-        in case the ACK is lost somewhere on the way to the called
-        user agent or the next stateful proxy.
-
-10.2 Source Addresses, Destination Addresses and Connections
-
-10.2.1 Unicast UDP
-
-   Responses are returned to the address listed in the Via header field
-   (Section 6.40), not the source address of the request.
-
-
-        Recall that responses are not generated by the next-hop
-        stateless server, but generated by either a proxy server or
-        the user agent server. Thus, the stateless proxy can only
-        use the Via header field to forward the response.
-
-10.2.2 Multicast UDP
-
-   Requests MAY be multicast; multicast requests likely feature a host-
-   independent Request-URI. This request SHOULD be scoped to ensure it
-   is not forwarded beyond the boundaries of the administrative system.
-   This MAY be done with either TTL or administrative scopes[25],
-   depending on what is implemented in the network.
-
-   A client receiving a multicast query does not have to check whether
-   the host part of the Request-URI matches its own host or domain name.
-   If the request was received via multicast, the response is also
-   returned via multicast. Responses to multicast requests are multicast
-   with the same TTL as the request, where the TTL is derived from the
-   ttl parameter in the Via header (Section 6.40).
-
-   To avoid response implosion, servers MUST NOT answer multicast
-   requests with a status code other than 2xx or 6xx. The server delays
-   its response by a random interval uniformly distributed between zero
-   and one second. Servers MAY suppress responses if they hear a lower-
-   numbered or 6xx response from another group member prior to sending.
-   Servers do not respond to CANCEL requests received via multicast to
-   avoid request implosion. A proxy or UAC SHOULD send a CANCEL on
-   receiving the first 2xx or 6xx response to a multicast request.
-
-
-        Server response suppression is a MAY since it requires a
-        server to violate some basic message processing rules. Lets
-        say A sends a multicast request, and it is received by B,C,
-        and D. B sends a 200 response. The topmost Via field in the
-        response will contain the address of A. C will also receive
-        this response, and could use it to suppress its own
-        response. However, C would normally not examine this
-        response, as the topmost Via is not its own. Normally, a
-        response received with an incorrect topmost Via MUST be
-        dropped, but not in this case. To distinguish this packet
-        from a misrouted or multicast looped packet is fairly
-        complex, and for this reason the procedure is a MAY. The
-        CANCEL, instead, provides a simpler and more standard way
-        to perform response suppression. It is for this reason that
-        the use of CANCEL here is a SHOULD
-
-10.3 TCP
-
-   A single TCP connection can serve one or more SIP transactions. A
-   transaction contains zero or more provisional responses followed by
-   one or more final responses. (Typically, transactions contain exactly
-   one final response, but there are exceptional circumstances, where,
-   for example, multiple 200 responses can be generated.)
-
-   The client SHOULD keep the connection open at least until the first
-   final response arrives. If the client closes or resets the TCP
-   connection prior to receiving the first final response, the server
-   treats this action as equivalent to a CANCEL request.
-
-
-        This behavior makes it less likely that malfunctioning
-        clients cause a proxy server to keep connection state
-        indefinitely.
-
-   The server SHOULD NOT close the TCP connection until it has sent its
-   final response, at which point it MAY close the TCP connection if it
-   wishes to. However, normally it is the client's responsibility to
-   close the connection.
-
-   If the server leaves the connection open, and if the client so
-   desires it MAY re-use the connection for further SIP requests or for
-   requests from the same family of protocols (such as HTTP or stream
-   control commands).
-
-
-
-   If a server needs to return a response to a client and no longer has
-   a connection open to that client, it MAY open a connection to the
-   address listed in the Via header. Thus, a proxy or user agent MUST be
-   prepared to receive both requests and responses on a "passive"
-   connection.
-10.4 Reliability for BYE, CANCEL, OPTIONS, REGISTER Requests
-10.4.1 UDP
 
-   A SIP client using UDP SHOULD retransmit a BYE, CANCEL, OPTIONS, or
-   REGISTER request with an exponential backoff, starting at a T1 second
-   interval, doubling the interval for each packet, and capping off at a
-   T2 second interval. This means that after the first packet is sent,
-   the second is sent T1 seconds later, the next 2*T1 seconds after
-   that, the next 4*T1 seconds after that, and so on, until the interval
-   hits T2. Subsequent retransmissions are spaced by T2 seconds. If the
-   client receives a provisional response, it continues to retransmit
-   the request, but with an interval of T2 seconds.  Retransmissions
-   cease when the client has sent a total of eleven packets, or receives
-   a definitive response. Default values for T1 and T2 are 500 ms and 4
-   s, respectively. Clients MAY use larger values, but SHOULD NOT use
-   smaller ones. Servers retransmit the response upon receipt of a
-   request retransmission. After the server sends a final response, it
-   cannot be sure the client has received the response, and thus SHOULD
-   cache the results for at least 10*T2 seconds to avoid having to, for
-   example, contact the user or location server again upon receiving a
-   request retransmission.
-
-
-        Use of the exponential backoff is for congestion control
-        purposes. However, the back-off must cap off, since request
-        retransmissions are used to trigger response
-        retransmissions at the server. Without a cap, the loss of a
-        single response could significantly increase transaction
-        latencies.
-
-   The value of the initial retransmission timer is smaller than that
-   that for TCP since it is expected that network paths suitable for
-   interactive communications have round-trip times smaller than 500 ms.
-   For congestion control purposes, the retransmission count has to be
-   bounded.  Given that most transactions are expected to consist of one
-   request and a few responses, round-trip time estimation is not likely
-   to be very useful. If RTT estimation is desired to more quickly
-   discover a missing final response, each request retransmission needs
-   to be labeled with its own Timestamp (Section 6.36), returned in the
-   response. The server caches the result until it can be sure that the
-   client will not retransmit the same request again.
-
-
-   Each server in a proxy chain generates its own final response to a
-   CANCEL request. The server responds immediately upon receipt of the
-   CANCEL request rather than waiting until it has received final
-   responses from the CANCEL requests it generates.
-
-   BYE and OPTIONS final responses are generated by redirect and user
-   agent servers; REGISTER final responses are generated by registrars.
-   Note that in contrast to the reliability mechanism described in
-   Section 10.5, responses to these requests are not retransmitted
-   periodically and not acknowledged via ACK.
-
-10.4.2 TCP
-
-   Clients using TCP do not need to retransmit requests.
-
-10.5 Reliability for INVITE Requests
-
-   Special considerations apply for the INVITE method.
-
-        1.   After receiving an invitation, considerable time can elapse
-             before the server can determine the outcome. For example,
-             if the called party is "rung" or extensive searches are
-             performed, delays between the request and a definitive
-             response can reach several tens of seconds. If either
-             caller or callee are automated servers not directly
-             controlled by a human being, a call attempt could be
-             unbounded in time.
-
-        2.   If a telephony user interface is modeled or if we need to
-             interface to the PSTN, the caller's user interface will
-             provide "ringback", a signal that the callee is being
-             alerted. (The status response 180 (Ringing) MAY be used to
-             initiate ringback.) Once the callee picks up, the caller
-             needs to know so that it can enable the voice path and stop
-             ringback. The callee's response to the invitation could get
-             lost. Unless the response is transmitted reliably, the
-             caller will continue to hear ringback while the callee
-             assumes that the call exists.
-
-        3.   The client has to be able to terminate an on-going request,
-             e.g., because it is no longer willing to wait for the
-             connection or search to succeed. The server will have to
-             wait several retransmission intervals to interpret the lack
-             of request retransmissions as the end of a call. If the
-             call succeeds shortly after the caller has given up, the
-             callee will "pick up the phone" and not be "connected".
-
-
-10.5.1 UDP
-
-   For UDP, A SIP client SHOULD retransmit a SIP INVITE request with an
-   interval that starts at T1 seconds, and doubles after each packet
-   transmission. The client ceases retransmissions if it receives a
-   provisional or definitive response, or once it has sent a total of 7
-   request packets.
-
-   A server which transmits a provisional response should retransmit it
-   upon reception of a duplicate request. A server which transmits a
-   final response should retransmit it with an interval that starts at
-   T1 seconds, and doubles for each subsequent packet. Response
-   retransmissions cease when any one of the following occurs:
-
-        1.   An ACK request for the same transaction is received;
-
-        2.   a BYE request for the same call leg is received;
-
-        3.   a CANCEL request for the same call leg is received and the
-             final response status was equal or greater to 300;
-
-        4.   the response has been transmitted 7 times.
-
-   Only the user agent client generates an ACK for 2xx final responses,
-   If the response contained a Contact header field, the ACK MAY be sent
-   to the address listed in that Contact header field. If the response
-   did not contain a Contact header, the client uses the same To header
-   field and Request-URI as for the INVITE request and sends the ACK to
-   the same destination as the original INVITE request. ACKs for final
-   responses other than 2xx are sent to the same server that the
-   original request was sent to, using the same Request-URI as the
-   original request. Note, however, that the To header field in the ACK
-   is copied from the response being acknowledged, not the request, and
-   thus MAY additionally contain the tag parameter. Also note than
-   unlike 2xx final responses, a proxy generates an ACK for non-2xx
-   final responses.
-
-   The ACK request MUST NOT be acknowledged to prevent a response-ACK
-   feedback loop. Fig. 12 and 13 show the client and server state
-   diagram for invitations.
-
-
-        The mechanism in Sec. 10.4 would not work well for INVITE
-        because of the long delays between INVITE and a final
-        response. If the 200 response were to get lost, the callee
-        would believe the call to exist, but the voice path would
-
-
-              +===========+
-              *           *
-  ...........>*  Initial  *<;;;;;;;;;;
-  : 7 INVITE  *           *          ;
-  :   sent    +===========+          ;
-  :                 |                ;
-  :                 |    -           ;
-  :                 |  INVITE        ;
-  :                 |                ;
-  :                 v                ;
-  :           *************          ;
-  : T1*2^n <--*           *          ;
-  : INVITE -->*  Calling  *--------+ ;
-  :           *           *        | ;
-  :           *************        | ;
-  :             :   |              | ;
-  :.............:   | 1xx      xxx | ;
-                    |  -       ACK | ;
-                    |              | ;
-                    v              | ; 
-              *************        | ;
-              *           *        | ;
-              *  Ringing  *<->1xx  | ; 
-              *           *        | ;
-              *************        | ;
-                    |              | ;
-                    |<-------------+ ; 
-                    |                ;
-                    v                ;
-              *************          ;
-      xxx  <--*           *          ;
-      ACK  -->* Completed *          ;
-              *           *          ;
-              *************          ;
-                    ; 32s (for proxy);
-                    ;;;;;;;;;;;;;;;;;;
-
- event (xxx=status)
-     message                                          
-
-
-   Figure 12: State transition diagram of client for INVITE method
-
-
-
-
-   7 pkts sent  +===============+                   
-+-------------->*               *
-|               *   Initial     *<...............
-|;;;;;;;;;;;;;;>*               *               :
-|;              +===============+               :
-|; CANCEL               !                       :
-|;  200                 !  INVITE               :
-|;                      !   1xx                 :
-|;                      !                       :
-|;                      v                       :
-|;              *****************          BYE  :
-|;    INVITE -->*               *          200  :
-|;      1xx  <--* Call proceed. *..............>:
-|;              *               *               :
-|;;;;;;;;;;;;;;;*****************               :
-|;                    !   !                     :
-|:                    !   !                     :
-|;         failure    !   !  picks up           :
-|;         >= 300     !   !    200              :
-|;            +-------+   +-------+             :
-|;            v                   v             :
-|;       ***********         ***********        :
-|;INVITE<*         *<T1*2^n->*         *>INVITE :
-|;status>* failure *>status<-* success *<status :
-|;       *         *         *         *        :
-|;;;;;;;;***********         ***********        :
-|             ! : |            |  !  :          :
-|             ! : |            |  !  :          :
-+-------------!-:-+------------+  !  :          :
-              ! :.................!..:.........>:
-              !                   !         BYE : 
-              +---------+---------+         200 :
-  event                 ! ACK                   :
-message sent            v                       :
-                *****************               :
-            V---*               *               :
-           ACK  *   Confirmed   *               :
-            |-->*               *               :
-                *****************               . 
-                        :......................>:
-
-
-   Figure 13: State transition diagram of server for INVITE method
-
-
-        be dead since the caller does not know that the callee has
-        picked up. Thus, the INVITE retransmission interval would
-        have to be on the order of a second or two to limit the
-        duration of this state confusion. Retransmitting the
-        response with an exponential back-off helps ensure that the
-        response is received, without placing an undue burden on
-        the network.
-
-10.5.2 TCP
-
-   A user agent using TCP MUST NOT retransmit requests, but uses the
-   same algorithm as for UDP (Section 10.5.1) to retransmit responses
-   until it receives an ACK.
-
-
-        It is necessary to retransmit 2xx responses as their
-        reliability is assured end-to-end only. If the chain of
-        proxies has a UDP link in the middle, it could lose the
-        response, with no possibility of recovery. For simplicity,
-        we also retransmit non-2xx responses, although that is not
-        strictly necessary.
-
-10.6 Reliability for ACK Requests
-
-   The ACK request does not generate responses. It is only generated
-   when a response to an INVITE request arrives (see Section 10.5). This
-   behavior is independent of the transport protocol. Note that the ACK
-   request MAY take a different path than the original INVITE request,
-   and MAY even cause a new TCP connection to be opened in order to send
-   it.
-
-10.7 ICMP Handling
-
-   Handling of ICMP messages in the case of UDP messages is
-   straightforward. For requests, a host, network, port, or protocol
-   unreachable error SHOULD be treated as if a 400-class response was
-   received. For responses, these errors SHOULD cause the server to
-   cease retransmitting the response.
-
-   Source quench ICMP messages SHOULD be ignored. TTL exceeded errors
-   SHOULD be ignored. Parameter problem errors SHOULD be treated as if a
-   400-class response was received.
-
-11 Behavior of SIP User Agents
-
-   This section describes the rules for user agent client and servers
-   for generating and processing requests and responses.
-
-11.1 Caller Issues Initial INVITE Request
-
-   When a user agent client desires to initiate a call, it formulates an
-   INVITE request. The To field in the request contains the address of
-   the callee. The Request-URI contains the same address. The From field
-   contains the address of the caller.  If the From address can appear
-   in requests generated by other user agent clients for the same call,
-   the caller MUST insert the tag parameter in the From field. A UAC MAY
-   optionally add a Contact header containing an address where it would
-   like to be contacted for transactions from the callee back to the
-   caller.
-
-11.2 Callee Issues Response
-
-   When the initial INVITE request is received at the callee, the callee
-   can accept, redirect, or reject the call. In all of these cases, it
-   formulates a response. The response MUST copy the To, From, Call-ID,
-   CSeq and Via fields from the request. Additionally, the responding
-   UAS MUST add the tag parameter to the To field in the response if the
-   request contained more than one Via header field. Since a request
-   from a UAC may fork and arrive at multiple hosts, the tag parameter
-   serves to distinguish, at the UAC, multiple responses from different
-   UAS's. The UAS MAY add a Contact header field in the response. It
-   contains an address where the callee would like to be contacted for
-   subsequent transactions, including the ACK for the current INVITE.
-   The UAS stores the values of the To and From field, including any
-   tags. These become the local and remote addresses of the call leg,
-   respectively.
-11.3 Caller Receives Response to Initial Request
-   Multiple 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 call
-   leg. The caller MAY choose to acknowledge or terminate the call with
-   each responding UAS. To acknowledge, it sends an ACK request, and to
-   terminate it sends a BYE request.  The To header field in the ACK or
-   BYE MUST be the same as the To field in the 200 response, including
-   any tag. The From header field MUST be the same as the From header
-   field in the 200 (OK) response, including any tag. The Request-URI of
-   the ACK or BYE request MAY be set to whatever address was found in
-   the Contact header field in the 200 (OK) response, if present.
-   Alternately, a UAC may copy the address from the To header field into
-   the Request-URI. The UAC also notes the value of the To and From
-   header fields in each response. For each call leg, the To header
-   field becomes the remote address, and the From header field becomes
-   the local address.
-
-11.4 Caller or Callee Generate Subsequent Requests
-
-   Once the call has been established, either the caller or callee MAY
-   generate INVITE or BYE requests to change or terminate the call.
-   Regardless of whether the caller or callee is generating the new
-   request, the header fields in the request are set as follows. For the
-   desired call leg, the To header field is set to the remote address,
-   and the From header field is set to the local address (both including
-   any tags). The Contact header field MAY be different than the Contact
-   header field sent in a previous response or request. The Request-URI
-   MAY be set to the value of the Contact header field received in a
-   previous request or response from the remote party, or to the value
-   of the remote address.
-
-11.5 Receiving Subsequent Requests
-
-   When a request is received subsequently, the following checks are
-   made:
-
-        1.   If the Call-ID is new, the request is for a new call,
-             regardless of the values of the To and From header fields.
-
-        2.   If the Call-ID exists, the request is for an existing call.
-             If the To, From, Call-ID, and CSeq values exactly match
-             (including tags) those of any requests received previously,
-             the request is a retransmission.
-
-        3.   If there was no match to the previous step, the To and From
-             fields are compared against existing call leg local and
-             remote addresses. If there is a match, and the CSeq in the
-             request is higher than the last CSeq received on that leg,
-             the request is a new transaction for an existing call leg.
-
-12 Behavior of SIP Proxy and Redirect Servers
-
-   This section describes behavior of SIP redirect and proxy servers in
-   detail. Proxy servers can "fork" connections, i.e., a single incoming
-   request spawns several outgoing (client) requests.
-
-12.1 Redirect Server
-
-   A redirect server does not issue any SIP requests of its own. After
-   receiving a request other than CANCEL, the server gathers the list of
-   alternative locations and returns a final response of class 3xx or it
-   refuses the request. For well-formed CANCEL requests, it SHOULD
-   return a 2xx response. This response ends the SIP transaction. The
-
-
-   redirect server maintains transaction state for the whole SIP
-   transaction. It is up to the client to detect forwarding loops
-   between redirect servers.
-
-12.2 User Agent Server
-
-   User agent servers behave similarly to redirect servers, except that
-   they also accept requests and can return a response of class 2xx.
-
-12.3 Proxy Server
-
-   This section outlines processing rules for proxy servers. A proxy
-   server can either be stateful or stateless. When stateful, a proxy
-   remembers the incoming request which generated outgoing requests, and
-   the outgoing requests. A stateless proxy forgets all information once
-   an outgoing request is generated. A forking proxy SHOULD be stateful.
-   Proxies that accept TCP connections MUST be stateful.
-
-
-        Otherwise, if the proxy were to lose a request, the TCP
-        client would never retransmit it.
-
-   A stateful proxy SHOULD NOT become stateless until after it sends a
-   definitive response upstream, and at least 32 seconds after it
-   received a definitive response.
-
-   A stateful proxy acts as a virtual UAS/UAC. It implements the server
-   state machine when receiving requests, and the client state machine
-   for generating outgoing requests, with the exception of receiving a
-   2xx response to an INVITE. Instead of generating an ACK, the 2xx
-   response is always forwarded upstream towards the caller.
-   Furthermore, ACK's for 200 responses to INVITE's are always proxied
-   downstream towards the UAS, as they would be for a stateless proxy.
-
-   A stateless proxy does not act as a virtual UAS/UAC (as this would
-   require state). Rather, a stateless proxy forwards every request it
-   receives downstream, and every response it receives upstream.
-
-12.3.1 Proxying Requests
-
-   To prevent loops, a server MUST check if its own address is already
-   contained in the Via header field of the incoming request.
-
-   The To, From, Call-ID, and Contact tags are copied exactly from the
-   original request. The proxy SHOULD change the Request-URI to indicate
-   the server where it intends to send the request.
-
-
-   A proxy server always inserts a Via header field containing its own
-   address into those requests that are caused by an incoming request.
-   Each proxy MUST insert a "branch" parameter (Section 6.40).
-
-12.3.2 Proxying Responses
-
-   A proxy only processes a response if the topmost Via field matches
-   one of its addresses. A response with a non-matching top Via field
-   MUST be dropped.
-
-12.3.3 Stateless Proxy: Proxying Responses
-
-   A stateless proxy removes its own Via field, and checks the address
-   in the next Via field. In the case of UDP, the response is sent to
-   the address listed in the "maddr" tag if present, otherwise to the
-   "received" tag if present, and finally to the address in the "sent-
-   by" field. A proxy MUST remain stateful when handling requests
-   received via TCP.
-
-   A stateless proxy MUST NOT generate its own provisional responses.
-
-12.3.4 Stateful Proxy: Receiving Requests
-
-   When a stateful proxy receives a request, it checks the To, From
-   (including tags), Call-ID and CSeq against existing request records.
-   If the tuple exists, the request is a retransmission. The provisional
-   or final response sent previously is retransmitted, as per the server
-   state machine. If the tuple does not exist, the request corresponds
-   to a new transaction, and the request should be proxied.
-
-   A stateful proxy server MAY generate its own provisional (1xx)
-   responses.
-
-12.3.5 Stateful Proxy: Receiving ACKs
-
-   When an ACK request is received, it is either processed locally or
-   proxied. To make this determination, the To, From, CSeq and Call-ID
-   fields are compared against those in previous requests. If there is
-   no match, the ACK request is proxied as if it were an INVITE request.
-   If there is a match, and if the server had ever sent a 200 response
-   upstream, the ACK is proxied.  If the server had never sent any
-   responses upstream, the ACK is also proxied. If the server had sent a
-   3xx, 4xx, 5xx or 6xx response, but no 2xx response, the ACK is
-   processed locally if the tag in the To field of the ACK matches the
-   tag sent by the proxy in the response.
-
-
-
-12.3.6 Stateful Proxy: Receiving Responses
-
-   When a proxy server receives a response that has passed the Via
-   checks, the proxy server checks the To (without the tag), From
-   (including the tag), Call-ID and CSeq against values seen in previous
-   requests. If there is no match, the response is forwarded upstream to
-   the address listed in the Via field. If there is a match, the
-   "branch" tag in the Via field is examined. If it matches a known
-   branch identifier, the response is for the given branch, and
-   processed by the virtual client for the given branch. Otherwise, the
-   response is dropped.
-
-   A stateful proxy should obey the rules in Section 12.4 to determine
-   if the response should be proxied upstream. If it is to be proxied,
-   the same rules for stateless proxies above are followed, with the
-   following addition for TCP. If a request was received via TCP
-   (indicated by the protocol in the top Via header), the proxy checks
-   to see if it has a connection currently open to that address. If so,
-   the response is sent on that connection.  Otherwise, a new TCP
-   connection is opened to the address and port in the Via field, and
-   the response is sent there. Note that this implies that a UAC or
-   proxy MUST be prepared to receive responses on the incoming side of a
-   TCP connection. Definitive non 200-class responses MUST be
-   retransmitted by the proxy, even over a TCP connection.
-
-12.3.7 Stateless, Non-Forking Proxy
-
-   Proxies in this category issue at most a single unicast request for
-   each incoming SIP request, that is, they do not "fork" requests.
-   However, servers MAY choose to always operate in a mode that allows
-   issuing of several requests, as described in Section 12.4.
-
-   The server can forward the request and any responses. It does not
-   have to maintain any state for the SIP transaction. Reliability is
-   assured by the next redirect or stateful proxy server in the server
-   chain.
-
-   A proxy server SHOULD cache the result of any address translations
-   and the response to speed forwarding of retransmissions. After the
-   cache entry has been expired, the server cannot tell whether an
-   incoming request is actually a retransmission of an older request.
-   The server will treat it as a new request and commence another
-   search.
-
-12.4 Forking Proxy
-
-   The server MUST respond to the request immediately with a 100
-   (Trying) response.
-
-
-   Successful responses to an INVITE request MAY contain a Contact
-   header field so that the following ACK or BYE bypasses the proxy
-   search mechanism. If the proxy requires future requests to be routed
-   through it, it adds a Record-Route header to the request (Section
-   6.29).
-
-   The following C-code describes the behavior of a proxy server issuing
-   several requests in response to an incoming INVITE request.  The
-   function request(r, a, b) sends a SIP request of type r to address a,
-   with branch id b. await_response() waits until a response is received
-   and returns the response. close(a) closes the TCP connection to
-   client with address a. response(r) sends a response to the client.
-   ismulticast() returns 1 if the location is a multicast address and
-   zero otherwise.  The variable timeleft indicates the amount of time
-   left until the maximum response time has expired. The variable
-   recurse indicates whether the server will recursively try addresses
-   returned through a 3xx response. A server MAY decide to recursively
-   try only certain addresses, e.g., those which are within the same
-   domain as the proxy server. Thus, an initial multicast request can
-   trigger additional unicast requests.
-
-
-     /* request type */
-     typedef enum {INVITE, ACK, BYE, OPTIONS, CANCEL, REGISTER} Method;
-
-     process_request(Method R, int N, address_t address[])
-     {
-       struct {
-         int branch;         /* branch id */
-         int done;           /* has responded */
-       } outgoing[];
-       int done[];           /* address has responded */
-       char *location[];     /* list of locations */
-       int heard = 0;        /* number of sites heard from */
-       int class;            /* class of status code */
-       int timeleft = 120;   /* sample timeout value */
-       int loc = 0;          /* number of locations */
-       struct {              /* response */
-         int status;         /* response: CANCEL=-1 */
-         int locations;      /* number of redirect locations */
-         char *location[];   /* redirect locations */
-         address_t a;        /* address of respondent */
-         int branch;         /* branch identifier */
-       } r, best;            /* response, best response */
-       int i;
-
-       best.status = 1000;
-       for (i = 0; i < N; i++) {
-
-
-         request(R, address[i], i);
-         outgoing[i].done = 0;
-         outgoing[i].branch = i;
-       }
-
-       while (timeleft > 0 && heard < N) {
-         r = await_response();
-         class = r.status / 100;
-
-         /* If final response, mark branch as done. */
-         if (class >= 2) {
-           heard++;
-           for (i = 0; i < N; i++) {
-             if (r.branch == outgoing[i].branch) {
-               outgoing[i].done = 1;
-               break;
-             }
-           }
-         }
-         /* CANCEL: respond, fork and wait for responses */
-         else if (class < 0) {
-           best.status = 200;
-           response(best);
-           for (i = 0; i < N; i++) {
-             if (!outgoing[i].done)
-               request(CANCEL, address[i], outgoing[i].branch);
-           }
-           best.status = -1;
-         }
-
-         /* Send an ACK */
-
-         if (class != 2) {
-           if (R == INVITE) request(ACK, r.a, r.branch);
-         }
-
-
-         if (class == 2) {
-           if (r.status < best.status) best = r;
-           break;
-         }
-         else if (class == 3) {
-           /* A server MAY optionally recurse.  The server MUST check
-            * whether it has tried this location before and whether
-            * the location is part of the Via path of the incoming
-            * request.  This check is omitted here for brevity.
-            * Multicast locations MUST NOT be returned to the client if
-            * the server is not recursing.
-
-
-            */
-           if (recurse) {
-             multicast = 0;
-             N += r.locations;
-             for (i = 0; i < r.locations; i++) {
-               request(R, r.location[i]);
-             }
-           } else if (!ismulticast(r.location)) {
-             best = r;
-           }
-         }
-         else if (class == 4) {
-           if (best.status >= 400) best = r;
-         }
-         else if (class == 5) {
-           if (best.status >= 500) best = r;
-         }
-         else if (class == 6) {
-           best = r;
-           break;
-         }
-       }
-
-       /* We haven't heard anything useful from anybody. */
-       if (best.status == 1000) {
-         best.status = 404;
-       }
-       if (best.status/100 != 3) loc = 0;
-       response(best);
-     }
-
-
-   Responses are processed as follows. The process completes (and state
-   can be freed) when all requests have been answered by final status
-   responses (for unicast) or 60 seconds have elapsed (for multicast). A
-   proxy MAY send a CANCEL to all branches and return a 408 (Timeout) to
-   the client after 60 seconds or more.
-
-   1xx: The proxy MAY forward the response upstream towards the client.
-
-   2xx: The proxy MUST forward the response upstream towards the client,
-        without sending an ACK downstream. After receiving a 2xx, the
-        server MAY terminate all other pending requests by sending a
-        CANCEL request and closing the TCP connection, if applicable.
-        (Terminating pending requests is advisable as searches consume
-        resources. Also, INVITE requests could "ring" on a number of
-        workstations if the callee is currently logged in more than
-        once.)
-
-
-   3xx: The proxy MUST send an ACK and MAY recurse on the listed Contact
-        addresses. Otherwise, the lowest-numbered response is returned
-        if there were no 2xx responses.
-
-        Location lists are not merged as that would prevent
-        forwarding of authenticated responses. Also, responses can
-        have message bodies, so that merging is not feasible.
-
-   4xx, 5xx: The proxy MUST send an ACK and remember the response if it
-        has a lower status code than any previous 4xx and 5xx responses.
-        On completion, the lowest-numbered response is returned if there
-        were no 2xx or 3xx responses.
-
-   6xx: The proxy MUST forward the response to the client and send an
-        ACK. Other pending requests MAY be terminated with CANCEL as
-        described for 2xx responses.
-
-   A proxy server forwards any response for Call-IDs for which it does
-   not have a pending transaction according to the response's Via
-   header. User agent servers respond to BYE requests for unknown call
-   legs with status code 481 (Transaction Does Not Exist); they drop ACK
-   requests with unknown call legs silently.
-
-   Special considerations apply for choosing forwarding destinations for
-   ACK and BYE requests. In most cases, these requests will bypass
-   proxies and reach the desired party directly, keeping proxies from
-   having to make forwarding decisions.
-
-   A proxy MAY maintain call state for a period of its choosing. If a
-   proxy still has list of destinations that it forwarded the last
-   INVITE to, it SHOULD direct ACK requests only to those downstream
-   servers.
-13 Security Considerations
-13.1 Confidentiality and Privacy: Encryption
-13.1.1 End-to-End Encryption
-   SIP requests and responses can contain sensitive information about
-   the communication patterns and communication content of individuals.
-   The SIP message body MAY also contain encryption keys for the session
-   itself. SIP supports three complementary forms of encryption to
-   protect privacy:
-
-        o  End-to-end encryption of the SIP message body and certain
-          sensitive header fields;
-
-        o  hop-by-hop encryption to prevent eavesdropping that tracks
-          who is calling whom;
-
-        o  hop-by-hop encryption of Via fields to hide the route a
-          request has taken.
-
-   Not all of the SIP request or response can be encrypted end-to-end
-   because header fields such as To and Via need to be visible to
-   proxies so that the SIP request can be routed correctly.  Hop-by-hop
-   encryption encrypts the entire SIP request or response on the wire so
-   that packet sniffers or other eavesdroppers cannot see who is calling
-   whom. Hop-by-hop encryption can also encrypt requests and responses
-   that have been end-to-end encrypted. Note that proxies can still see
-   who is calling whom, and this information is also deducible by
-   performing a network traffic analysis, so this provides a very
-   limited but still worthwhile degree of protection.
-
-   SIP Via fields are used to route a response back along the path taken
-   by the request and to prevent infinite request loops. However, the
-   information given by them can also provide useful information to an
-   attacker. Section 6.22 describes how a sender can request that Via
-   fields be encrypted by cooperating proxies without compromising the
-   purpose of the Via field.
-
-   End-to-end encryption relies on keys shared by the two user agents
-   involved in the request. Typically, the message is sent encrypted
-   with the public key of the recipient, so that only that recipient can
-   read the message. All implementations SHOULD support PGP-based
-   encryption [33] and MAY implement other schemes.
-
-   A SIP request (or response) is end-to-end encrypted by splitting the
-   message to be sent into a part to be encrypted and a short header
-   that will remain in the clear. Some parts of the SIP message, namely
-   the request line, the response line and certain header fields marked
-   with "n" in the "enc." column in Table 4 and 5 need to be read and
-   returned by proxies and thus MUST NOT be encrypted end-to-end.
-   Possibly sensitive information that needs to be made available as
-   plaintext include destination address (To) and the forwarding path
-   (Via) of the call. The Authorization header field MUST remain in the
-   clear if it contains a digital signature as the signature is
-   generated after encryption, but MAY be encrypted if it contains
-   "basic" or "digest" authentication. The From header field SHOULD
-   normally remain in the clear, but MAY be encrypted if required, in
-   which case some proxies MAY return a 401 (Unauthorized) status if
-   they require a From field.
-
-
-
-   Other header fields MAY be encrypted or MAY travel in the clear as
-   desired by the sender. The Subject, Allow and Content-Type header
-   fields will typically be encrypted. The Accept, Accept-Language,
-   Date, Expires, Priority, Require, Call-ID, Cseq, and Timestamp header
-   fields will remain in the clear.
-
-   All fields that will remain in the clear MUST precede those that will
-   be encrypted. The message is encrypted starting with the first
-   character of the first header field that will be encrypted and
-   continuing through to the end of the message body. If no header
-   fields are to be encrypted, encrypting starts with the second CRLF
-   pair after the last header field, as shown below. Carriage return and
-   line feed characters have been made visible as "$", and the encrypted
-   part of the message is outlined.
-
-
-     INVITE sip:watson@boston.bell-telephone.com SIP/2.0$
-     Via: SIP/2.0/UDP 169.130.12.5$
-     To: T. A. Watson <sip:watson@bell-telephone.com>$
-     From: A. Bell <sip:a.g.bell@bell-telephone.com>$
-     Encryption: PGP version=5.0$
-     Content-Length: 224$
-     Call-ID: 187602141351@worcester.bell-telephone.com$
-     CSeq: 488$
-     $
-   *******************************************************
-   * Subject: Mr. Watson, come here.$                    *
-   * Content-Type: application/sdp$                      *
-   * $                                                   *
-   * v=0$                                                *
-   * o=bell 53655765 2353687637 IN IP4 128.3.4.5$        *
-   * c=IN IP4 135.180.144.94$                            *
-   * m=audio 3456 RTP/AVP 0 3 4 5$                       *
-   *******************************************************
-
-   An Encryption header field MUST be added to indicate the encryption
-   mechanism used. A Content-Length field is added that indicates the
-   length of the encrypted body. The encrypted body is preceded by a
-   blank line as a normal SIP message body would be.
-
-   Upon receipt by the called user agent possessing the correct
-   decryption key, the message body as indicated by the Content-Length
-   field is decrypted, and the now-decrypted body is appended to the
-   clear-text header fields. There is no need for an additional
-   Content-Length header field within the encrypted body because the
-   length of the actual message body is unambiguous after decryption.
-
-
-   Had no SIP header fields required encryption, the message would have
-   been as below. Note that the encrypted body MUST then include a blank
-   line (start with CRLF) to disambiguate between any possible SIP
-   header fields that might have been present and the SIP message body.
-
-
-     INVITE sip:watson@boston.bell-telephone.com SIP/2.0$
-     Via: SIP/2.0/UDP 169.130.12.5$
-     To: T. A. Watson <sip:watson@bell-telephone.com>$
-     From: A. Bell <a.g.bell@bell-telephone.com>$
-     Encryption: PGP version=5.0$
-     Content-Type: application/sdp$
-     Content-Length: 107$
-     $
-   *************************************************
-   * $                                             *
-   * v=0$                                          *
-   * o=bell 53655765 2353687637 IN IP4 128.3.4.5$  *
-   * c=IN IP4 135.180.144.94$                      *
-   * m=audio 3456 RTP/AVP 0 3 4 5$                 *
-   *************************************************
-
-13.1.2 Privacy of SIP Responses
-
-   SIP requests can be sent securely using end-to-end encryption and
-   authentication to a called user agent that sends an insecure
-   response.  This is allowed by the SIP security model, but is not a
-   good idea.  However, unless the correct behavior is explicit, it
-   would not always be possible for the called user agent to infer what
-   a reasonable behavior was. Thus when end-to-end encryption is used by
-   the request originator, the encryption key to be used for the
-   response SHOULD be specified in the request. If this were not done,
-   it might be possible for the called user agent to incorrectly infer
-   an appropriate key to use in the response. Thus, to prevent key-
-   guessing becoming an acceptable strategy, we specify that a called
-   user agent receiving a request that does not specify a key to be used
-   for the response SHOULD send that response unencrypted.
-
-   Any SIP header fields that were encrypted in a request SHOULD also be
-   encrypted in an encrypted response. Contact response fields MAY be
-   encrypted if the information they contain is sensitive, or MAY be
-   left in the clear to permit proxies more scope for localized
-   searches.
-
-
-
-13.1.3 Encryption by Proxies
-
-   Normally, proxies are not allowed to alter end-to-end header fields
-   and message bodies. Proxies MAY, however, encrypt an unsigned request
-   or response with the key of the call recipient.
-
-
-        Proxies need to encrypt a SIP request if the end system
-        cannot perform encryption or to enforce organizational
-        security policies.
-
-13.1.4 Hop-by-Hop Encryption
-
-   SIP requests and responses MAY also be protected by security
-   mechanisms at the transport or network layer. No particular mechanism
-   is defined or recommended here. Two possibilities are IPSEC [34] or
-   TLS [35]. The use of a particular mechanism will generally need to be
-   specified out of band, through manual configuration, for example.
-
-13.1.5 Via field encryption
-
-   When Via header fields are to be hidden, a proxy that receives a
-   request containing an appropriate "Hide: hop" header field (as
-   specified in section 6.22) SHOULD encrypt the header field. As only
-   the proxy that encrypts the field will decrypt it, the algorithm
-   chosen is entirely up to the proxy implementor. Two methods satisfy
-   these requirements:
-
-        o  The server keeps a cache of Via header fields and the
-          associated To header field, and replaces the Via header field
-          with an index into the cache. On the reverse path, take the
-          Via header field from the cache rather than the message.
-
-        This is insufficient to prevent message looping, and so an
-        additional ID MUST be added so that the proxy can detect loops.
-        This SHOULD NOT normally be the address of the proxy as the goal
-        is to hide the route, so instead a sufficiently large random
-        number SHOULD be used by the proxy and maintained in the cache.
-
-        It is possible for replies to get directed to the wrong
-        originator if the cache entry gets reused, so great care needs
-        to be taken to ensure this does not happen.
-
-        o  The server MAY use a secret key to encrypt the Via field, a
-          timestamp and an appropriate checksum in any such message with
-          the same secret key. The checksum is needed to detect whether
-          successful decoding has occurred, and the timestamp is
-
-          required to prevent possible replay attacks and to ensure that
-          no two requests from the same previous hop have the same
-          encrypted Via field.  This is the preferred solution.
-
-13.2 Message Integrity and Access Control: Authentication
-
-   Protective measures need to be taken to prevent an active attacker
-   from modifying and replaying SIP requests and responses. The same
-   cryptographic measures that are used to ensure the authenticity of
-   the SIP message also serve to authenticate the originator of the
-   message.  However, the "basic" and "digest" authentication mechanism
-   offer authentication only, without message integrity.
-
-   Transport-layer or network-layer authentication MAY be used for hop-
-   by-hop authentication. SIP also extends the HTTP WWW-Authenticate
-   (Section 6.42) and Authorization (Section 6.11) header field and
-   their Proxy counterparts to include cryptographically strong
-   signatures. SIP also supports the HTTP "basic" and "digest" schemes
-   (see Section 14) and other HTTP authentication schemes to be defined
-   that offer a rudimentary mechanism of ascertaining the identity of
-   the caller.
-
-
-        Since SIP requests are often sent to parties with which no
-        prior communication relationship has existed, we do not
-        specify authentication based on shared secrets.
-
-   SIP requests MAY be authenticated using the Authorization header
-   field to include a digital signature of certain header fields, the
-   request method and version number and the payload, none of which are
-   modified between client and called user agent. The Authorization
-   header field is used in requests to authenticate the request
-   originator end-to-end to proxies and the called user agent, and in
-   responses to authenticate the called user agent or proxies returning
-   their own failure codes. If required, hop-by-hop authentication can
-   be provided, for example, by the IPSEC Authentication Header.
-
-   SIP does not dictate which digital signature scheme is used for
-   authentication, but does define how to provide authentication using
-   PGP in Section 15. As indicated above, SIP implementations MAY also
-   use "basic" and "digest" authentication and other authentication
-   mechanisms defined for HTTP. Note that "basic" authentication has
-   severe security limitations. The following does not apply to these
-   schemes.
-
-   To cryptographically sign a SIP request, the order of the SIP header
-   fields is important. When an Authorization header field is present,
-   it indicates that all header fields following the Authorization
-
-
-   header field have been included in the signature.  Therefore, hop-
-   by-hop header fields which MUST or SHOULD be modified by proxies MUST
-   precede the Authorization header field as they will generally be
-   modified or added-to by proxy servers.  Hop-by-hop header fields
-   which MAY be modified by a proxy MAY appear before or after the
-   Authorization header. When they appear before, they MAY be modified
-   by a proxy. When they appear after, they MUST NOT be modified by a
-   proxy. To sign a request, a client constructs a message from the
-   request method (in upper case) followed, without LWS, by the SIP
-   version number, followed, again without LWS, by the request headers
-   to be signed and the message body.  The message thus constructed is
-   then signed.
-
-   For example, if the SIP request is to be:
-
-   INVITE sip:watson@boston.bell-telephone.com SIP/2.0
-   Via: SIP/2.0/UDP 169.130.12.5
-   Authorization: PGP version=5.0, signature=...
-   From: A. Bell <sip:a.g.bell@bell-telephone.com>
-   To: T. A. Watson <sip:watson@bell-telephone.com>
-   Call-ID: 187602141351@worcester.bell-telephone.com
-   Subject: Mr. Watson, come here.
-   Content-Type: application/sdp
-   Content-Length: ...
-
-   v=0
-   o=bell 53655765 2353687637 IN IP4 128.3.4.5
-   c=IN IP4 135.180.144.94
-   m=audio 3456 RTP/AVP 0 3 4 5
-
-   Then the data block that is signed is:
-
-   INVITESIP/2.0From: A. Bell <sip:a.g.bell@bell-telephone.com>
-   To: T. A. Watson <sip:watson@bell-telephone.com>
-   Call-ID: 187602141351@worcester.bell-telephone.com
-   Subject: Mr. Watson, come here.
-   Content-Type: application/sdp
-   Content-Length: ...
-
-   v=0
-   o=bell 53655765 2353687637 IN IP4 128.3.4.5
-   c=IN IP4 135.180.144.94
-   m=audio 3456 RTP/AVP 0 3 4 5
-
-
-
-   Clients wishing to authenticate requests MUST construct the portion
-   of the message below the Authorization header using a canonical form.
-   This allows a proxy to parse the message, take it apart, and
-   reconstruct it, without causing an authentication failure due to
-   extra white space, for example. Canonical form consists of the
-   following rules:
-
-        o  No short form header fields
-
-        o  Header field names are capitalized as shown in this document
-
-        o  No white space between the header name and the colon
-
-        o  A single space after the colon
-
-        o  Line termination with a CRLF
-
-        o  No line folding
-
-        o  No comma separated lists of header values; each must appear
-          as a separate header
-
-        o  Only a single SP between tokens, between tokens and quoted
-          strings, and between quoted strings; no SP after last token or
-          quoted string
-
-        o  No LWS between tokens and separators, except as described
-          above for after the colon in header fields
-
-   Note that if a message is encrypted and authenticated using a digital
-   signature, when the message is generated encryption is performed
-   before the digital signature is generated. On receipt, the digital
-   signature is checked before decryption.
-
-   A client MAY require that a server sign its response by including a
-   Require: org.ietf.sip.signed-response request header field. The
-   client indicates the desired authentication method via the WWW-
-   Authenticate header.
-
-   The correct behavior in handling unauthenticated responses to a
-   request that requires authenticated responses is described in section
-   13.2.1.
-
-
-
-
-13.2.1 Trusting responses
-
-   There is the possibility that an eavesdropper listens to requests and
-   then injects unauthenticated responses that terminate, redirect or
-   otherwise interfere with a call. (Even encrypted requests contain
-   enough information to fake a response.)
-
-   Clients need to be particularly careful with 3xx redirection
-   responses.  Thus a client receiving, for example, a 301 (Moved
-   Permanently) which was not authenticated when the public key of the
-   called user agent is known to the client, and authentication was
-   requested in the request SHOULD be treated as suspicious. The correct
-   behavior in such a case would be for the called-user to form a dated
-   response containing the Contact field to be used, to sign it, and
-   give this signed stub response to the proxy that will provide the
-   redirection. Thus the response can be authenticated correctly. A
-   client SHOULD NOT automatically redirect such a request to the new
-   location without alerting the user to the authentication failure
-   before doing so.
-
-   Another problem might be responses such as 6xx failure responses
-   which would simply terminate a search, or "4xx" and "5xx" response
-   failures.
-
-   If TCP is being used, a proxy SHOULD treat 4xx and 5xx responses as
-   valid, as they will not terminate a search. However, fake 6xx
-   responses from a rogue proxy terminate a search incorrectly. 6xx
-   responses SHOULD be authenticated if requested by the client, and
-   failure to do so SHOULD cause such a client to ignore the 6xx
-   response and continue a search.
-
-   With UDP, the same problem with 6xx responses exists, but also an
-   active eavesdropper can generate 4xx and 5xx responses that might
-   cause a proxy or client to believe a failure occurred when in fact it
-   did not. Typically 4xx and 5xx responses will not be signed by the
-   called user agent, and so there is no simple way to detect these
-   rogue responses. This problem is best prevented by using hop-by-hop
-   encryption of the SIP request, which removes any additional problems
-   that UDP might have over TCP.
-
-   These attacks are prevented by having the client require response
-   authentication and dropping unauthenticated responses. A server user
-   agent that cannot perform response authentication responds using the
-   normal Require response of 420 (Bad Extension).
-
-
-
-
-13.3 Callee Privacy
-
-   User location and SIP-initiated calls can violate a callee's privacy.
-   An implementation 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.
-
-13.4 Known Security Problems
-
-   With either TCP or UDP, a denial of service attack exists by a rogue
-   proxy sending 6xx responses. Although a client SHOULD choose to
-   ignore such responses if it requested authentication, a proxy cannot
-   do so. It is obliged to forward the 6xx response back to the client.
-   The client can then ignore the response, but if it repeats the
-   request it will probably reach the same rogue proxy again, and the
-   process will repeat.
-
-14 SIP Authentication using HTTP Basic and Digest Schemes
-
-   SIP implementations MAY use HTTP's basic and digest authentication
-   mechanisms to provide a rudimentary form of security. This section
-   overviews usage of these mechanisms in SIP. The basic operation is
-   almost completely identical to that for HTTP [36]. This section
-   outlines this operation, pointing to [36] for details, and noting the
-   differences when used in SIP.
-
-14.1 Framework
-
-   The framework for SIP authentication parallels that for HTTP [36]. In
-   particular, the BNF for auth-scheme, auth-param, challenge, realm,
-   realm-value, and credentials is identical. The 401 response is used
-   by user agent servers in SIP to challenge the authorization of a user
-   agent client. Additionally, registrars and redirect servers MAY make
-   use of 401 responses for authorization, but proxies MUST NOT, and
-   instead MAY use the 407 response. The requirements for inclusion of
-   the Proxy-Authenticate, Proxy-Authorization, WWW-Authenticate, and
-   Authorization in the various messages is identical to [36].
-   Since SIP does not have the concept of a canonical root URL, the
-   notion of protections spaces are interpreted differently for SIP. The
-   realm is a protection domain for all SIP URIs with the same value for
-   the userinfo, host and port part of the SIP Request-URI. For example:
-      INVITE sip:alice.wonderland@example.com SIP/2.0
-      WWW-Authenticate:  Basic realm="business"
-   and
-      INVITE sip:aw@example.com SIP/2.0
-      WWW-Authenticate: Basic realm="business"
-   define different protection realms according to this rule.
-   When a UAC resubmits a request with its credentials after receiving a
-   401 or 407 response, it MUST increment the CSeq header field as it
-   would normally do when sending an updated request.
-14.2 Basic Authentication
-   The rules for basic authentication follow those defined in [36], but
-   with the words "origin server" replaced with "user agent server,
-   redirect server , or registrar".
-
-   Since SIP URIs are not hierarchical, the paragraph in [36] that
-   states that "all paths at or deeper than the depth of the last
-   symbolic element in the path field of the Request-URI also are within
-   the protection space specified by the Basic realm value of the
-   current challenge" does not apply for SIP. SIP clients MAY
-   preemptively send the corresponding Authorization header with
-   requests for SIP URIs within the same protection realm (as defined
-   above) without receipt of another challenge from the server.
-14.3 Digest Authentication
-   The rules for digest authentication follow those defined in [36],
-   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-URL
-        2.   The BNF for digest-uri-value is:
-             digest-uri-value  =  Request-URI ; a defined in Section
-             4.3
-        3.   The example procedure for choosing a nonce based on Etag
-             does not work for SIP.
-        4.   The Authentication-Info and Proxy-Authentication-Info
-             fields are not used in SIP.
-        5.   The text in [36] regarding cache operation does not apply
-             to SIP.
-        6.   [36] requires that a server check that the URI in the
-             request line, and the URI included in the Authorization
-             header, point to the same resource. In a SIP context, these
-             two URI's may actually 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
-             corresponds to a user that the server is willing to accept
-             forwarded or direct calls for.
-14.4 Proxy-Authentication
-   The use of the Proxy-Authentication and Proxy-Authorization parallel
-   that as described in [36], with one difference. Proxies MUST NOT add
-   the Proxy-Authorization header. 407 responses MUST be forwarded
-   upstream towards the client following the procedures for any other
-   response. It is the client's responsibility to add the Proxy-
-   Authorization header containing credentials for the proxy which has
-   asked for authentication.
-        If a proxy were to resubmit a request with a Proxy-
-        Authorization header field, it would need to increment the
-        CSeq in the new request. However, this would mean that the
-        UAC which submitted the original request would discard a
-        response from the UAS, as the CSeq value would be
-        different.
-
-   See sections 6.26 and 6.27 for additional information on usage of
-   these fields as they apply to SIP.
 
-15 SIP Security Using PGP
-
-15.1 PGP Authentication Scheme
-
-   The "pgp" authentication scheme is based on the model that the client
-   authenticates itself with a request signed with the client's private
-   key. The server can then ascertain the origin of the request if it
-   has access to the public key, preferably signed by a trusted third
-   party.
-
-
-15.1.1 The WWW-Authenticate Response Header
-
-        WWW-Authenticate =  "WWW-Authenticate" ":" "pgp" pgp-challenge
-        pgp-challenge    =  * (";" pgp-params )
-        pgp-params       =  realm | pgp-version | pgp-algorithm | nonce
-        realm            =  "realm" "=" realm-value
-        realm-value      =  quoted-string
-        pgp-version      =  "version" "="
-                             <"> digit *( "." digit ) *letter <">
-        pgp-algorithm    =  "algorithm" "=" ( "md5" | "sha1" | token )
-        nonce            =  "nonce" "=" nonce-value
-        nonce-value      =  quoted-string
-
-   The meanings of the values of the parameters used above are as
-   follows:
-
-   realm: A string to be displayed to users so they know which identity
-        to use. This string SHOULD contain at least the name of the host
-        performing the authentication and MAY additionally indicate the
-        collection of users who might have access. An example might be "
-        Users with call-out privileges ".
-
-   pgp-algorithm: The value of this parameter indicates the PGP message
-        integrity check (MIC) to be used to produce the signature. If
-        this not present it is assumed to be "md5". The currently
-        defined values are "md5" for the MD5 checksum, and "sha1" for
-        the SHA.1 algorithm.
-
-   pgp-version: The version of PGP that the client MUST use. Common
-        values are "2.6.2" and "5.0". The default is 5.0.
-
-   nonce: A server-specified data string which should be uniquely
-        generated each time a 401 response is made. It is RECOMMENDED
-        that this string be base64 or hexadecimal data.  Specifically,
-        since the string is passed in the header lines as a quoted
-        string, the double-quote character is not allowed. The contents
-        of the nonce are implementation dependent. The quality of the
-        implementation depends on a good choice. Since the nonce is used
-        only to prevent replay attacks and is signed, a time stamp in
-        units convenient to the server is sufficient.
-
-
-
-
-        Replay attacks within the duration of the call setup are of
-        limited interest, so that timestamps with a resolution of a
-        few seconds are often should be sufficient. In that case,
-        the server does not have to keep a record of the nonces.
 
-   Example:
 
-   WWW-Authenticate: pgp ;version="5.0"
-     ;realm="Your Startrek identity, please" ;algorithm=md5
-     ;nonce="913082051"
-
-15.1.2 The Authorization Request Header
-
-   The client is expected to retry the request, passing an Authorization
-   header line, which is defined as follows.
-
-        Authorization  =  "Authorization" ":" "pgp" *( ";" pgp-response )
-        pgp-response   =  realm | pgp-version | pgp-signature
-                          | signed-by | nonce
-        pgp-signature  =  "signature" "=" quoted-string
-        signed-by      =  "signed-by" "=" <"> URI <">
-
-
-   The client MUST increment the CSeq header before resubmitting the
-   request. The signature MUST correspond to the From header of the
-   request unless the signed-by parameter is provided.
-
-   pgp-signature: The PGP ASCII-armored signature [33], as it appears
-        between the "BEGIN PGP MESSAGE" and "END PGP MESSAGE"
-        delimiters, without the version indication. The signature is
-        included without any linebreaks.
-
-   The signature is computed across the nonce (if present), request
-   method, request version and header fields following the Authorization
-   header and the message body, in the same order as they appear in the
-   message. The request method and version are prepended to the header
-   fields without any white space. The signature is computed across the
-   headers as sent, and the terminating CRLF. The CRLF following the
-   Authorization header is NOT included in the signature.
-
-   A server MAY be configured not to generate nonces only if replay
-   attacks are not a concern.
-
-
-        Not generating nonces avoids the additional set of request,
-        401 response and possibly ACK messages and reduces delay by
-        one round-trip time.
-
-
-        Using the ASCII-armored version is about 25% less space-
-        efficient than including the binary signature, but it is
-        significantly easier for the receiver to piece together.
-        Versions of the PGP program always include the full
-        (compressed) signed text in their output unless ASCII-
-        armored mode ( -sta ) is specified.  Typical signatures are
-        about 200 bytes long. -- The PGP signature mechanism allows
-        the client to simply pass the request to an external PGP
-        program. This relies on the requirement that proxy servers
-        are not allowed to reorder or change header fields.
-
-   realm: The realm is copied from the corresponding WWW-Authenticate
-        header field parameter.
-
-   signed-by: If and only if the request was not signed by the entity
-        listed in the From header, the signed-by header indicates the
-        name of the signing entity, expressed as a URI.
-
-   Receivers of signed SIP messages SHOULD discard any end-to-end header
-   fields above the Authorization header, as they may have been
-   maliciously added en route by a proxy.
 
-   Example:
 
-   Authorization: pgp version="5.0"
-     ;realm="Your Startrek identity, please"
-     ;nonce="913082051"
-     ;signature="iQB1AwUBNNJiUaYBnHmiiQh1AQFYsgL/Wt3dk6TWK81/b0gcNDf
-     VAUGU4rhEBW972IPxFSOZ94L1qhCLInTPaqhHFw1cb3lB01rA0RhpV4t5yCdUt
-     SRYBSkOK29o5e1KlFeW23EzYPVUm2TlDAhbcjbMdfC+KLFX
-     =aIrx"
-
-15.2 PGP Encryption Scheme
-
-   The PGP encryption scheme uses the following syntax:
-
-        Encryption    =  "Encryption" ":" "pgp" pgp-eparams
-        pgp-eparams   =  1# ( pgp-version | pgp-encoding )
-        pgp-encoding  =  "encoding" "=" "ascii" | token
-
-
-   encoding: Describes the encoding or "armor" used by PGP. The value
-        "ascii" refers to the standard PGP ASCII armor, without the
-        lines containing "BEGIN PGP MESSAGE" and "END PGP MESSAGE" and
-        without the version identifier. By default, the encrypted part
-        is included as binary.
 
-   Example:
 
-   Encryption: pgp version="2.6.2", encoding="ascii"
+
+
+
 
-15.3 Response-Key Header Field for PGP
 
-        Response-Key  =  "Response-Key" ":" "pgp" pgp-eparams
-        pgp-eparams   =  1# ( pgp-version | pgp-encoding | pgp-key)
-        pgp-key       =  "key" "=" quoted-string
 
 
-   If ASCII encoding has been requested via the encoding parameter, the
-   key parameter contains the user's public key as extracted from the
-   pgp key ring with the "pgp -kxa user ".
 
-   Example:
 
-   Response-Key: pgp version="2.6.2", encoding="ascii",
-     key="mQBtAzNWHNYAAAEDAL7QvAdK2utY05wuUG+ItYK5tCF8HNJM60sU4rLaV+eUnkMk
-     mOmJWtc2wXcZx1XaXb2lkydTQOesrUR75IwNXBuZXPEIMThEa5WLsT7VLme7njnx
-     sE86SgWmAZx5ookIdQAFEbQxSGVubmluZyBTY2h1bHpyaW5uZSA8c2NodWx6cmlu
-     bmVAY3MuY29sdW1iaWEuZWR1Pg==
-     =+y19"
 
-16 Examples
 
-   In the following examples, we often omit the message body and the
-   corresponding Content-Length and Content-Type headers for brevity.
 
-16.1 Registration
 
-   A user at host saturn.bell-tel.com registers on start-up, via
-   multicast, with the local SIP server named bell-tel.com. In the
-   example, the user agent on saturn expects to receive SIP requests on
-   UDP port 3890.
 
-   C->S: REGISTER sip:bell-tel.com SIP/2.0
-         Via: SIP/2.0/UDP saturn.bell-tel.com
-         From: sip:watson@bell-tel.com
-         To: sip:watson@bell-tel.com
-         Call-ID: 70710@saturn.bell-tel.com
-         CSeq: 1 REGISTER
-         Contact: <sip:watson@saturn.bell-tel.com:3890;transport=udp>
-         Expires: 7200
+   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.
 
-   The registration expires after two hours. Any future invitations for
-   watson@bell-tel.com arriving at sip.bell-tel.com will now be
-   redirected to watson@saturn.bell-tel.com, UDP port 3890.
 
-   If Watson wants to be reached elsewhere, say, an on-line service he
-   uses while traveling, he updates his reservation after first
-   cancelling any existing locations:
 
 
-   C->S: REGISTER sip:bell-tel.com SIP/2.0
-         Via: SIP/2.0/UDP saturn.bell-tel.com
-         From: sip:watson@bell-tel.com
-         To: sip:watson@bell-tel.com
-         Call-ID: 70710@saturn.bell-tel.com
-         CSeq: 2 REGISTER
-         Contact: *
-         Expires: 0
 
-   C->S: REGISTER sip:bell-tel.com SIP/2.0
-         Via: SIP/2.0/UDP saturn.bell-tel.com
-         From: sip:watson@bell-tel.com
-         To: sip:watson@bell-tel.com
-         Call-ID: 70710@saturn.bell-tel.com
-         CSeq: 3 REGISTER
-         Contact: sip:tawatson@example.com
 
-   Now, the server will forward any request for Watson to the server at
-   example.com, using the Request-URI tawatson@example.com. For the
-   server at example.com to reach Watson, he will need to send a
-   REGISTER there, or inform the server of his current location through
-   some other means.
 
-   It is possible to use third-party registration. Here, the secretary
-   jon.diligent registers his boss, T. Watson:
 
-   C->S: REGISTER sip:bell-tel.com SIP/2.0
-         Via: SIP/2.0/UDP pluto.bell-tel.com
-         From: sip:jon.diligent@bell-tel.com
-         To: sip:watson@bell-tel.com
-         Call-ID: 17320@pluto.bell-tel.com
-         CSeq: 1 REGISTER
-         Contact: sip:tawatson@example.com
 
-   The request could be sent to either the registrar at bell-tel.com or
-   the server at example.com. In the latter case, the server at
-   example.com would proxy the request to the address indicated in the
-   Request-URI. Then, Max-Forwards header could be used to restrict the
-   registration to that server.
 
-16.2 Invitation to a Multicast Conference
 
-   The first example invites schooler@vlsi.cs.caltech.edu to a multicast
-   session. All examples use the Session Description Protocol (SDP) (RFC
-   2327 [6]) as the session description format.
 
-16.2.1 Request
 
 
-   C->S: INVITE sip:schooler@cs.caltech.edu SIP/2.0
-         Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348
-           ;maddr=239.128.16.254;ttl=16
-         Via: SIP/2.0/UDP north.east.isi.edu
-         From: Mark Handley <sip:mjh@isi.edu>
-         To: Eve Schooler <sip:schooler@caltech.edu>
-         Call-ID: 2963313058@north.east.isi.edu
-         CSeq: 1 INVITE
-         Subject: SIP will be discussed, too
-         Content-Type: application/sdp
-         Content-Length: 187
 
-         v=0
-         o=user1 53655765 2353687637 IN IP4 128.3.4.5
-         s=Mbone Audio
-         i=Discussion of Mbone Engineering Issues
-         e=mbone@somewhere.com
-         c=IN IP4 224.2.0.1/127
-         t=0 0
-         m=audio 3456 RTP/AVP 0
 
 
-   The From request header above states that the request was initiated
-   by mjh@isi.edu and addressed to schooler@caltech.edu (From header
-   fields). The Via fields list the hosts along the path from invitation
-   initiator (the last element of the list) towards the callee. In the
-   example above, the message was last multicast to the administratively
-   scoped group 239.128.16.254 with a ttl of 16 from the host
-   csvax.cs.caltech.edu. The second Via header field indicates that it
-   was originally sent from the host north.east.isi.edu. The Request-URI
-   indicates that the request is currently being being addressed to
-   schooler@cs.caltech.edu, the local address that csvax looked up for
-   the callee.
 
-   In this case, the session description is using the Session
-   Description Protocol (SDP), as stated in the Content-Type header.
 
-   The header is terminated by an empty line and is followed by a
-   message body containing the session description.
 
-16.2.2 Response
 
-   The called user agent, directly or indirectly through proxy servers,
-   indicates that it is alerting ("ringing") the called party:
 
 
-   S->C: SIP/2.0 180 Ringing
-         Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348
-           ;maddr=239.128.16.254;ttl=16
-         Via: SIP/2.0/UDP north.east.isi.edu
-         From: Mark Handley <sip:mjh@isi.edu>
-         To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472
-         Call-ID: 2963313058@north.east.isi.edu
-         CSeq: 1 INVITE
 
-   A sample response to the invitation is given below. The first line of
-   the response states the SIP version number, that it is a 200 (OK)
-   response, which means the request was successful. The Via headers are
-   taken from the request, and entries are removed hop by hop as the
-   response retraces the path of the request. A new authentication field
-   MAY be added by the invited user's agent if required. The Call-ID is
-   taken directly from the original request, along with the remaining
-   fields of the request message. The original sense of From field is
-   preserved (i.e., it is the session initiator).
 
-   In addition, the Contact header gives details of the host where the
-   user was located, or alternatively the relevant proxy contact point
-   which should be reachable from the caller's host.
 
 
-   S->C: SIP/2.0 200 OK
-         Via: SIP/2.0/UDP csvax.cs.caltech.edu;branch=8348
-           ;maddr=239.128.16.254;ttl=16
-         Via: SIP/2.0/UDP north.east.isi.edu
-         From: Mark Handley <sip:mjh@isi.edu>
-         To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472
-         Call-ID: 2963313058@north.east.isi.edu
-         CSeq: 1 INVITE
-         Contact: sip:es@jove.cs.caltech.edu
 
-   The caller confirms the invitation by sending an ACK request to the
-   location named in the Contact header:
 
 
-   C->S: ACK sip:es@jove.cs.caltech.edu SIP/2.0
-         Via: SIP/2.0/UDP north.east.isi.edu
-         From: Mark Handley <sip:mjh@isi.edu>
-         To: Eve Schooler <sip:schooler@caltech.edu> ;tag=9883472
-         Call-ID: 2963313058@north.east.isi.edu
-         CSeq: 1 ACK
 
-16.3 Two-party Call
 
-   For two-party Internet phone calls, the response must contain a
-   description of where to send the data. In the example below, Bell
-   calls Watson. Bell indicates that he can receive RTP audio codings 0
-   (PCMU), 3 (GSM), 4 (G.723) and 5 (DVI4).
+
 
 
-   C->S: INVITE sip:watson@boston.bell-tel.com SIP/2.0
-         Via: SIP/2.0/UDP kton.bell-tel.com
-         From: A. Bell <sip:a.g.bell@bell-tel.com>
-         To: T. Watson <sip:watson@bell-tel.com>
-         Call-ID: 3298420296@kton.bell-tel.com
-         CSeq: 1 INVITE
-         Subject: Mr. Watson, come here.
-         Content-Type: application/sdp
-         Content-Length: ...
+
+
 
-         v=0
-         o=bell 53655765 2353687637 IN IP4 128.3.4.5
-         s=Mr. Watson, come here.
-         c=IN IP4 kton.bell-tel.com
-         m=audio 3456 RTP/AVP 0 3 4 5
 
 
-   S->C: SIP/2.0 100 Trying
-         Via: SIP/2.0/UDP kton.bell-tel.com
-         From: A. Bell <sip:a.g.bell@bell-tel.com>
-         To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
-         Call-ID: 3298420296@kton.bell-tel.com
-         CSeq: 1 INVITE
-         Content-Length: 0
 
-   S->C: SIP/2.0 180 Ringing
-         Via: SIP/2.0/UDP kton.bell-tel.com
-         From: A. Bell <sip:a.g.bell@bell-tel.com>
-         To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
-         Call-ID: 3298420296@kton.bell-tel.com
-         CSeq: 1 INVITE
-         Content-Length: 0
 
-   S->C: SIP/2.0 182 Queued, 2 callers ahead
-         Via: SIP/2.0/UDP kton.bell-tel.com
-         From: A. Bell <sip:a.g.bell@bell-tel.com>
-         To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
-         Call-ID: 3298420296@kton.bell-tel.com
-         CSeq: 1 INVITE
-         Content-Length: 0
 
-   S->C: SIP/2.0 182 Queued, 1 caller ahead
-         Via: SIP/2.0/UDP kton.bell-tel.com
-         From: A. Bell <sip:a.g.bell@bell-tel.com>
-         To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
-         Call-ID: 3298420296@kton.bell-tel.com
-         CSeq: 1 INVITE
-         Content-Length: 0
 
-   S->C: SIP/2.0 200 OK
-         Via: SIP/2.0/UDP kton.bell-tel.com
-         From: A. Bell <sip:a.g.bell@bell-tel.com>
-         To: <sip:watson@bell-tel.com> ;tag=37462311
-         Call-ID: 3298420296@kton.bell-tel.com
-         CSeq: 1 INVITE
-         Contact: sip:watson@boston.bell-tel.com
-         Content-Type: application/sdp
-         Content-Length: ...
 
-         v=0
-         o=watson 4858949 4858949 IN IP4 192.1.2.3
-         s=I'm on my way
-         c=IN IP4 boston.bell-tel.com
-         m=audio 5004 RTP/AVP 0 3
 
-   The example illustrates the use of informational status responses.
-   Here, the reception of the call is confirmed immediately (100), then,
-   possibly after some database mapping delay, the call rings (180) and
-   is then queued, with periodic status updates.
 
-   Watson can only receive PCMU and GSM. Note that Watson's list of
-   codecs may or may not be a subset of the one offered by Bell, as each
-   party indicates the data types it is willing to receive. Watson will
-   send audio data to port 3456 at c.bell-tel.com, Bell will send to
-   port 5004 at boston.bell-tel.com.
 
-   By default, the media session is one RTP session. Watson will receive
-   RTCP packets on port 5005, while Bell will receive them on port 3457.
 
-   Since the two sides have agreed on the set of media, Bell confirms
-   the call without enclosing another session description:
 
 
-   C->S: ACK sip:watson@boston.bell-tel.com SIP/2.0
-         Via: SIP/2.0/UDP kton.bell-tel.com
-         From: A. Bell <sip:a.g.bell@bell-tel.com>
-         To: T. Watson <sip:watson@bell-tel.com> ;tag=37462311
-         Call-ID: 3298420296@kton.bell-tel.com
-         CSeq: 1 ACK
 
-16.4 Terminating a Call
 
-   To terminate a call, caller or callee can send a BYE request:
 
 
-   C->S: BYE sip:watson@boston.bell-tel.com SIP/2.0
-         Via: SIP/2.0/UDP kton.bell-tel.com
-         From: A. Bell <sip:a.g.bell@bell-tel.com>
-         To: T. A. Watson <sip:watson@bell-tel.com> ;tag=37462311
-         Call-ID: 3298420296@kton.bell-tel.com
-         CSeq: 2 BYE
 
-   If the callee wants to abort the call, it simply reverses the To and
-   From fields. Note that it is unlikely that a BYE from the callee will
-   traverse the same proxies as the original INVITE.
 
 
 
 
-16.5 Forking Proxy
 
-   In this example, Bell (a.g.bell@bell-tel.com) (C), currently seated
-   at host c.bell-tel.com wants to call Watson (t.watson@ieee.org). At
-   the time of the call, Watson is logged in at two workstations,
-   t.watson@x.bell-tel.com (X) and watson@y.bell-tel.com (Y), and has
-   registered with the IEEE proxy server (P) called sip.ieee.org. The
-   IEEE server also has a registration for the home machine of Watson,
-   at watson@h.bell-tel.com (H), as well as a permanent registration at
-   watson@acm.org (A). For brevity, the examples omit the session
-   description and Via header fields.
 
-   Bell's user agent sends the invitation to the SIP server for the
-   ieee.org domain:
+   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.
 
-   C->P: INVITE sip:t.watson@ieee.org SIP/2.0
-         Via:     SIP/2.0/UDP c.bell-tel.com
-         From:    A. Bell <sip:a.g.bell@bell-tel.com>
-         To:      T. Watson <sip:t.watson@ieee.org>
-         Call-ID: 31415@c.bell-tel.com
-         CSeq:    1 INVITE
 
-   The SIP server at ieee.org tries the four addresses in parallel.  It
-   sends the following message to the home machine:
-   P->H: INVITE sip:watson@h.bell-tel.com SIP/2.0
-         Via:     SIP/2.0/UDP sip.ieee.org ;branch=1
-         Via:     SIP/2.0/UDP c.bell-tel.com
-         From:    A. Bell <sip:a.g.bell@bell-tel.com>
-         To:      T. Watson <sip:t.watson@ieee.org>
-         Call-ID: 31415@c.bell-tel.com
-         CSeq:    1 INVITE
 
-   This request immediately yields a 404 (Not Found) response, since
-   Watson is not currently logged in at home:
 
 
-   H->P: SIP/2.0 404 Not Found
-         Via:     SIP/2.0/UDP sip.ieee.org ;branch=1
-         Via:     SIP/2.0/UDP c.bell-tel.com
-         From:    A. Bell <sip:a.g.bell@bell-tel.com>
-         To:      T. Watson <sip:t.watson@ieee.org>;tag=87454273
 
-         Call-ID: 31415@c.bell-tel.com
-         CSeq:    1 INVITE
 
-   The proxy ACKs the response so that host H can stop retransmitting
-   it:
 
-   P->H: ACK sip:watson@h.bell-tel.com SIP/2.0
-         Via:     SIP/2.0/UDP sip.ieee.org ;branch=1
-         From:    A. Bell <sip:a.g.bell@bell-tel.com>
-         To:      T. Watson <sip:t.watson@ieee.org>;tag=87454273
-         Call-ID: 31415@c.bell-tel.com
-         CSeq:    1 ACK
 
-   Also, P attempts to reach Watson through the ACM server:
 
-   P->A: INVITE sip:watson@acm.org SIP/2.0
-         Via:     SIP/2.0/UDP sip.ieee.org ;branch=2
-         Via:     SIP/2.0/UDP c.bell-tel.com
-         From:    A. Bell <sip:a.g.bell@bell-tel.com>
-         To:      T. Watson <sip:t.watson@ieee.org>
-         Call-ID: 31415@c.bell-tel.com
-         CSeq:    1 INVITE
 
-   In parallel, the next attempt proceeds, with an INVITE to X and Y:
+
+
+
 
-   P->X: INVITE sip:t.watson@x.bell-tel.com SIP/2.0
-         Via:     SIP/2.0/UDP sip.ieee.org ;branch=3
-         Via:     SIP/2.0/UDP c.bell-tel.com
-         From:    A. Bell <sip:a.g.bell@bell-tel.com>
-         To:      T. Watson <sip:t.watson@ieee.org>
-         Call-ID: 31415@c.bell-tel.com
-         CSeq:    1 INVITE
 
-   P->Y: INVITE sip:watson@y.bell-tel.com SIP/2.0
-         Via:     SIP/2.0/UDP sip.ieee.org ;branch=4
-         Via:     SIP/2.0/UDP c.bell-tel.com
-         From:    A. Bell <sip:a.g.bell@bell-tel.com>
-         To:      T. Watson <sip:t.watson@ieee.org>
-         Call-ID: 31415@c.bell-tel.com
-         CSeq:    1 INVITE
 
-   As it happens, both Watson at X and a colleague in the other lab at
-   host Y hear the phones ringing and pick up. Both X and Y return 200s
-   via the proxy to Bell.
 
-   X->P: SIP/2.0 200 OK
-         Via:      SIP/2.0/UDP sip.ieee.org ;branch=3
-         Via:      SIP/2.0/UDP c.bell-tel.com
-         From:     A. Bell <sip:a.g.bell@bell-tel.com>
-         To:       T. Watson <sip:t.watson@ieee.org> ;tag=192137601
-         Call-ID:  31415@c.bell-tel.com
-         CSeq:     1 INVITE
-         Contact:  sip:t.watson@x.bell-tel.com
 
-   Y->P: SIP/2.0 200 OK
-         Via:      SIP/2.0/UDP sip.ieee.org ;branch=4
-         Via:      SIP/2.0/UDP c.bell-tel.com
-         Contact:  sip:t.watson@y.bell-tel.com
-         From:     A. Bell <sip:a.g.bell@bell-tel.com>
-         To:       T. Watson <sip:t.watson@ieee.org> ;tag=35253448
-         Call-ID:  31415@c.bell-tel.com
-         CSeq:     1 INVITE
 
-   Both responses are forwarded to Bell, using the Via information.  At
-   this point, the ACM server is still searching its database. P can now
-   cancel this attempt:
 
 
-   P->A: CANCEL sip:watson@acm.org SIP/2.0
-         Via:     SIP/2.0/UDP sip.ieee.org ;branch=2
-         From:    A. Bell <sip:a.g.bell@bell-tel.com>
-         To:      T. Watson <sip:t.watson@ieee.org>
-         Call-ID: 31415@c.bell-tel.com
-         CSeq:    1 CANCEL
 
-   The ACM server gladly stops its neural-network database search and
-   responds with a 200. The 200 will not travel any further, since P is
-   the last Via stop.
 
 
-   A->P: SIP/2.0 200 OK
-         Via:     SIP/2.0/UDP sip.ieee.org ;branch=2
-         From:    A. Bell <sip:a.g.bell@bell-tel.com>
-         To:      T. Watson <sip:t.watson@ieee.org>
 
 
-         Call-ID: 31415@c.bell-tel.com
-         CSeq:    1 CANCEL
 
-   Bell gets the two 200 responses from X and Y in short order. Bell's
-   reaction now depends on his software. He can either send an ACK to
-   both if human intelligence is needed to determine who he wants to
-   talk to or he can automatically reject one of the two calls. Here, he
-   acknowledges both, separately and directly to the final destination:
 
 
-   C->X: ACK sip:t.watson@x.bell-tel.com SIP/2.0
-         Via:      SIP/2.0/UDP c.bell-tel.com
-         From:     A. Bell <sip:a.g.bell@bell-tel.com>
-         To:       T. Watson <sip:t.watson@ieee.org>;tag=192137601
-         Call-ID:  31415@c.bell-tel.com
-         CSeq:     1 ACK
+
 
-   C->Y: ACK sip:watson@y.bell-tel.com SIP/2.0
-         Via:      SIP/2.0/UDP c.bell-tel.com
-         From:     A. Bell <sip:a.g.bell@bell-tel.com>
-         To:       T. Watson <sip:t.watson@ieee.org>;tag=35253448
-         Call-ID:  31415@c.bell-tel.com
-         CSeq:     1 ACK
 
-   After a brief discussion between Bell with X and Y, it becomes clear
-   that Watson is at X. (Note that this is not a three-way call; only
-   Bell can talk to X and Y, but X and Y cannot talk to each other.)
-   Thus, Bell sends a BYE to Y, which is replied to:
+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)
+
+
+   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].
 
-   C->Y: BYE sip:watson@y.bell-tel.com SIP/2.0
-         Via:      SIP/2.0/UDP c.bell-tel.com
-         From:     A. Bell <sip:a.g.bell@bell-tel.com>
-         To:       T. Watson <sip:t.watson@ieee.org>;tag=35253448
-         Call-ID:  31415@c.bell-tel.com
-         CSeq:     2 BYE
+   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.
+
+
+   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.
 
-   Y->C: SIP/2.0 200 OK
-         Via:      SIP/2.0/UDP c.bell-tel.com
-         From:     A. Bell <sip:a.g.bell@bell-tel.com>
-         To:       T. Watson <sip:t.watson@ieee.org>;tag=35253448
-         Call-ID:  31415@c.bell-tel.com
-         CSeq:     2 BYE
+   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.
 
-16.6 Redirects
+   An example of the WWW-Authenticate header field in a 401 challenge
+   is:
 
-   Replies with status codes 301 (Moved Permanently) or 302 (Moved
-   Temporarily) specify another location using the Contact field.
-   Continuing our earlier example, the server P at ieee.org decides to
-   redirect rather than proxy the request:
+      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.
+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.
 
-   P->C: SIP/2.0 302 Moved temporarily
-         Via:     SIP/2.0/UDP c.bell-tel.com
-         From:    A. Bell <sip:a.g.bell@bell-tel.com>
-         To:      T. Watson <sip:t.watson@ieee.org>;tag=72538263
-         Call-ID: 31415@c.bell-tel.com
-         CSeq:    1 INVITE
-         Contact: sip:watson@h.bell-tel.com,
-                   sip:watson@acm.org, sip:t.watson@x.bell-tel.com,
-                   sip:watson@y.bell-tel.com
-         CSeq: 1 INVITE
+      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
+   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.
 
-   As another example, assume Alice (A) wants to delegate her calls to
-   Bob (B) while she is on vacation until July 29th, 1998. Any calls
-   meant for her will reach Bob with Alice's To field, indicating to him
-   what role he is to play. Charlie (C) calls Alice (A), whose server
-   returns:
+   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
+
+
+      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:
 
-   A->C: SIP/2.0 302 Moved temporarily
-         From: Charlie <sip:charlie@caller.com>
-         To: Alice <sip:alice@anywhere.com> ;tag=2332462
-         Call-ID: 27182@caller.com
-         Contact: sip:bob@anywhere.com
-         Expires: Wed, 29 Jul 1998 9:00:00 GMT
-         CSeq: 1 INVITE
+      1.  The URI included in the challenge has the following BNF:
 
-   Charlie then sends the following request to the SIP server of the
-   anywhere.com domain. Note that the server at anywhere.com forwards
-   the request to Bob based on the Request-URI.
+          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
 
-   C->B: INVITE sip:bob@anywhere.com SIP/2.0
-         From: sip:charlie@caller.com
-         To: sip:alice@anywhere.com
-         Call-ID: 27182@caller.com
-         CSeq: 2 INVITE
 
+          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.
+   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.
+
+
+   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
+   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
+
+   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
+   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"
+         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                                *
+      *******************************************************
+
+
+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.
+
+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
+
+
+   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.
+
+   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
+
+
+
+      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".
+
+
+
+
+
+   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                                    *
+      ***********************************************************
+        --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
 
-   In the third redirection example, we assume that all outgoing
-   requests are directed through a local firewall F at caller.com, with
-   Charlie again inviting Alice:
+        --boundary42-
 
+24 Examples
 
-   C->F: INVITE sip:alice@anywhere.com SIP/2.0
-         From: sip:charlie@caller.com
-         To: Alice <sip:alice@anywhere.com>
-         Call-ID: 27182@caller.com
-         CSeq: 1 INVITE
+   In the following examples, we often omit the message body and the
+   corresponding Content-Length and Content-Type header fields for
+   brevity.
 
-   The local firewall at caller.com happens to be overloaded and thus
-   redirects the call from Charlie to a secondary server S:
+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
+
+   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.
 
-   F->C: SIP/2.0 302 Moved temporarily
-         From: sip:charlie@caller.com
-         To: Alice <sip:alice@anywhere.com>
-         Call-ID: 27182@caller.com
-         CSeq: 1 INVITE
-         Contact: <sip:alice@anywhere.com:5080;maddr=spare.caller.com>
+F1 INVITE Alice -> atlanta.com proxy
 
-   Based on this response, Charlie directs the same invitation to the
-   secondary server spare.caller.com at port 5080, but maintains the
-   same Request-URI as before:
+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)
+
+
+
+
+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
+
+
+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
+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)
+
+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
+
+
+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.
 
-   C->S: INVITE sip:alice@anywhere.com SIP/2.0
-         From: sip:charlie@caller.com
-         To: Alice <sip:alice@anywhere.com>
-         Call-ID: 27182@caller.com
-         CSeq: 2 INVITE
-16.7 Negotiation
-   An example of a 606 (Not Acceptable) response is:
 
-   S->C: SIP/2.0 606 Not Acceptable
-         From: sip:mjh@isi.edu
-         To: <sip:schooler@cs.caltech.edu> ;tag=7434264
-         Call-ID: 14142@north.east.isi.edu
 
-         CSeq: 1 INVITE
-         Contact: sip:mjh@north.east.isi.edu
-         Warning: 370 "Insufficient bandwidth (only have ISDN)",
-           305 "Incompatible media format",
-           330 "Multicast not available"
-         Content-Type: application/sdp
-         Content-Length: 50
 
-         v=0
-         s=Let's talk
-         b=CT:128
-         c=IN IP4 north.east.isi.edu
-         m=audio 3456 RTP/AVP 5 0 7
-         m=video 2232 RTP/AVP 31
 
-   In this example, the original request specified a bandwidth that was
-   higher than the access link could support, requested multicast, and
-   requested a set of media encodings. The response states that only 128
-   kb/s is available and that (only) DVI, PCM or LPC audio could be
-   supported in order of preference.
 
-   The response also states that multicast is not available.  In such a
-   case, it might be appropriate to set up a transcoding gateway and
-   re-invite the user.
-16.8 OPTIONS Request
 
-   A caller Alice can use an OPTIONS request to find out the
-   capabilities of a potential callee Bob, without "ringing" the
-   designated address. Bob returns a description indicating that he is
-   capable of receiving audio encodings PCM Ulaw (payload type 0), 1016
-   (payload type 1), GSM (payload type 3), and SX7300/8000 (dynamic
-   payload type 99), and video encodings H.261 (payload type 31) and
-   H.263 (payload type 34).
 
-   C->S: OPTIONS sip:bob@example.com SIP/2.0
-         From: Alice <sip:alice@anywhere.org>
-         To: Bob <sip:bob@example.com>
-         Call-ID: 6378@host.anywhere.org
-         CSeq: 1 OPTIONS
-         Accept: application/sdp
 
-   S->C: SIP/2.0 200 OK
-         From: Alice <sip:alice@anywhere.org>
-         To: Bob <sip:bob@example.com> ;tag=376364382
 
-         Call-ID: 6378@host.anywhere.org
-         Content-Length: 81
-         Content-Type: application/sdp
 
-         v=0
-         m=audio 0 RTP/AVP 0 1 3 99
-         m=video 0 RTP/AVP 31 34
-         a=rtpmap:99 SX7300/8000
+25  Augmented BNF for the SIP Protocol
-C Summary of Augmented BNF

All of the mechanisms specified in this document are described in
both prose and an augmented Backus-Naur Form (BNF) defined
-   to that used by RFC 822 [9]. Implementors will
+   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 in order to understand this specification.
+   need to be familiar with the notation and content of RFC 2234 in order to understand this specification.
-   The augmented BNF includes the following constructs:
+    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.
 
-        name  =  definition
 
-   The name of a rule is simply the name itself (without any enclosing
-   "<" and ">") and is separated from its definition by the equal "="
-   character. White space is only significant in that indentation of
-   continuation lines is used to indicate a rule definition that spans
-   more than one line. Certain basic rules are in uppercase, such as SP,
-   LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within
-   definitions whenever their presence will facilitate discerning the
-   use of rule names.
 
-   "literal"
 
-   Quotation marks surround literal text. Unless stated otherwise, the
-   text is case-insensitive.
 
-   rule1 | rule2
 
-   Elements separated by a bar ("|") are alternatives, e.g., "yes | no"
-   will accept yes or no.
 
-   (rule1 rule2)
 
-   Elements enclosed in parentheses are treated as a single element.
-   Thus, "(elem (foo | bar) elem)" allows the token sequences "elem foo
-   elem" and "elem bar elem".
 
-   *rule
 
-   The character "*" preceding an element indicates repetition. The full
-   form is "<n>*<m>element" indicating at least <n> and at most <m>
-   occurrences of element. Default values are 0 and infinity so that
-   "*(element)" allows any number, including zero; "1*element" requires
-   at least one; and "1*2element" allows one or two.
 
-   [rule]
 
 
-   Square brackets enclose optional elements; "[foo bar]" is equivalent
-   to "*1(foo bar)".
 
-   N rule
 
-   Specific repetition: "<n>(element)" is equivalent to
-   "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
-   Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
-   alphabetic characters.
 
-   #rule
 
-   A construct "#" is defined, similar to "*", for defining lists of
-   elements. The full form is "<n>#<m> element" indicating at least <n>
-   and at most <m> elements, each separated by one or more commas (",")
-   and OPTIONAL linear white space (LWS). This makes the usual form of
-   lists very easy; a rule such as
 
-           ( *LWS element *( *LWS "," *LWS element ))
 
-   can be shown as 1# element. Wherever this construct is used, null
-   elements are allowed, but do not contribute to the count of elements
-   present. That is, "(element), , (element)" is permitted, but counts
-   as only two elements. Therefore, where at least one element is
-   required, at least one non-null element MUST be present. Default
-   values are 0 and infinity so that "#element" allows any number,
-   including zero; "1#element" requires at least one; and "1#2element"
-   allows one or two.
 
-   ; comment
 
 
-   A semi-colon, set off some distance to the right of rule text, starts
-   a comment that continues to the end of line. This is a simple way of
-   including useful notes in parallel with the specifications.
 
 
-   implied *LWS
 
 
-   The grammar described by this specification is word-based. Except
-   where noted otherwise, linear white space (LWS) can be included
-   between any two adjacent words (token or quoted-string), and between
-   adjacent tokens and separators, without changing the interpretation
-   of a field. At least one delimiter (LWS and/or separators) MUST exist
-   between any two tokens (for the definition of "token" below), since
-   they would otherwise be interpreted as a single token.

+   The use of square brackets is redundant syntactically.  It is used as
+   a semantic hint that the specific parameter is optional to use.
 
-C.1 Basic Rules
+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.
 
 
-        OCTET     =  <any 8-bit sequence of data>
-        CHAR      =  <any US-ASCII character (octets 0 - 127)>
-        upalpha   =  "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
-                     "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
-                     "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
-        lowalpha  =  "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
-                     "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
-                     "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
-        alpha     =  lowalpha | upalpha
-        digit     =  "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
-                     "8" | "9"
-        alphanum  =  alpha | digit
+      alphanum  =  ALPHA / DIGIT
-        CTL       =  <any US-ASCII control character
-                     (octets 0 -- 31) and DEL (127)>
-        CR        =  %d13 ; US-ASCII CR, carriage return character
-        LF        =  %d10 ; US-ASCII LF, line feed character
-        SP        =  %d32 ; US-ASCII SP, space character
-        HT        =  %d09 ; US-ASCII HT, horizontal tab character
-        CRLF      =  CR LF ; typically the end of a line
-
-   The following are defined in RFC 2396 [12] for the SIP URI:
+   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
-        unreserved  =  alphanum | mark
-mark        =  "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
+mark        =  "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")"
-        escaped     =  "%" hex hex
+      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  =  [CRLF] 1*( SP | HT ) ; linear whitespace
+      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 character set (RFC 2279 [21]).
+   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  =  <any UTF-8 character encoding, except CTLs,
-                      but including LWS>
+      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
 
 
-   A CRLF is allowed in the definition of TEXT-UTF8
+   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 value.
+   TEXT-UTF8-TRIM value.

Hexadecimal numeric characters are used in several protocol elements.
+   Some elements (authentication) force hex alphas to be lower case.
 
-        hex  =  "A" | "B" | "C" | "D" | "E" | "F"
-                | "a" | "b" | "c" | "d" | "e" | "f" | digit
+      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*< any CHAR  except CTL's  or separators>
+      token       =  1*(alphanum / "-" / "." / "!" / "%" / "*"
+                     / "_" / "+" / "`" / "'" / "~" )
-        separators  =  "(" | ")" | "<" | ">" | "@" |
-                       "," | ";" | ":" | "\" | <"> |
-                       "/" | "[" | "]" | "?" | "=" |
-                       "{" | "}" | SP | HT
+      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

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  =  "(" *(ctext | quoted-pair | comment) ")"
+      comment  =  LPAREN *(ctext / quoted-pair / comment) RPAREN
-        ctext    =  < any TEXT-UTF8  excluding "("  and ")">
+      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  =  ( <"> *(qdtext | quoted-pair ) <"> )
+      quoted-string  =  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
-        qdtext         =  <any TEXT-UTF8 except <">>
+      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  =  " \ " CHAR
+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
+
+
+
+
+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
+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
+                /  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
+
+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
+
+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
+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
+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)
+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
+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)
+
+
+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.
+
+
+   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.
+
+
+
+   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.
+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.
+
+
+   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.
+
+
+   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
+   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.
+
+
+
+   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
+
+   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.
+
+   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.
+
+
+
+      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.
+
+
+   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
+   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.
+
+
+   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
+   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.
+   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
+   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
+   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.
+   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.
+
+
+
+   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
+
+   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.
-A Minimal Implementation
 
-A.1 Client
-   All clients MUST be able to generate the INVITE and ACK requests.
-   Clients MUST generate and parse the Call-ID, Content-Length,
-   Content-Type, CSeq, From and To headers. Clients MUST also parse the
-   Require header. A minimal implementation MUST understand SDP (RFC
-   2327, [6]). It MUST be able to recognize the status code classes 1
-   through 6 and act accordingly.
 
-   The following capability sets build on top of the minimal
-   implementation described in the previous paragraph. In general, each
-   capability listed below builds on the ones above it:
 
-   Basic: A basic implementation adds support for the BYE method to
-        allow the interruption of a pending call attempt. It includes a
-        User-Agent header in its requests and indicates its preferred
-        language in the Accept-Language header.
-   Redirection: To support call forwarding, a client needs to be able to
-        understand the Contact header, but only the SIP-URL part, not
-        the parameters.
 
-   Firewall-friendly: A firewall-friendly client understands the Route
-        and Record-Route header fields and can be configured to use a
-        local proxy for all outgoing requests.
 
-   Negotiation: A client MUST be able to request the OPTIONS method and
-        understand the 380 (Alternative Service) status and the Contact
-        parameters to participate in terminal and media negotiation. It
-        SHOULD be able to parse the Warning response header to provide
-        useful feedback to the caller.
-   Authentication: If a client wishes to invite callees that require
-        caller authentication, it MUST be able to recognize the 401
-        (Unauthorized) status code, MUST be able to generate the
-        Authorization request header and MUST understand the WWW-
-        Authenticate response header.
-   If a client wishes to use proxies that require caller authentication,
-   it MUST be able to recognize the 407 (Proxy Authentication Required)
-   status code, MUST be able to generate the Proxy-Authorization request
-   header and understand the Proxy-Authenticate response header.
-A.2 Server
-   A minimally compliant server implementation MUST understand the
-   INVITE, ACK, OPTIONS and BYE requests. A proxy server MUST also
-   understand CANCEL. It MUST parse and generate, as appropriate, the
-   Call-ID, Content-Length, Content-Type, CSeq, Expires, From, Max-
-   Forwards, Require, To and Via headers. It MUST echo the CSeq and
-   Timestamp headers in the response. It SHOULD include the Server
-   header in its responses.
-A.3 Header Processing
-   Table 6 lists the headers that different implementations support. UAC
-   refers to a user-agent client (calling user agent), UAS to a user-
-   agent server (called user-agent).
-   The fields in the table have the following meaning. Type is as in
-   Table 4 and 5. "-" indicates the field is not meaningful to this
-   system (although it might be generated by it). "m" indicates the
-   field MUST be understood. "b" indicates the field SHOULD be
-   understood by a Basic implementation.  "r" indicates the field SHOULD
-   be understood if the system claims to understand redirection. "a"
-   indicates the field SHOULD be understood if the system claims to
-   support authentication. "e" indicates the field SHOULD be understood
-   if the system claims to support encryption. "o" indicates support of
-   the field is purely optional. Headers whose support is optional for
-   all implementations are not shown.
-                        type  UAC  proxy  UAS  registrar
-   _____________________________________________________
-   Accept                R     -     o     m      m
-   Accept-Encoding       R     -     -     m      m
-   Accept-Language       R     -     b     b      b
-   Allow                405    o     -     -      -
-   Authorization         R     a     o     a      a
-   Call-ID               g     m     m     m      m
-   Content-Encoding      g     m     -     m      m
-   Content-Length        g     m     m     m      m
-   Content-Type          g     m     -     m      m
-   CSeq                  g     m     m     m      m
-   Encryption            g     e     -     e      e
-   Expires               g     -     o     o      m
-   From                  g     m     o     m      m
-   Hide                  R     -     m     -      -
-   Contact               R     -     -     -      m
-   Contact               r     r     r     -      -
-   Max-Forwards          R     -     b     -      -
-   Proxy-Authenticate   407    a     -     -      -
-   Proxy-Authorization   R     -     a     -      -
-   Proxy-Require         R     -     m     -      -
-   Require               R     m     -     m      m
-   Response-Key          R     -     -     e      e
-   Route                 R     -     m     -      -
-   Timestamp             g     o     o     m      m
-   To                    g     m     m     m      m
-   Unsupported           r     b     b     -      -
-   User-Agent            g     b     -     b      -
-   Via                   g     m     m     m      m
-   WWW-Authenticate     401    a     -     -      -
-   Table 6: Header Field Processing Requirements
-B Usage of the Session Description Protocol (SDP)
-   This section describes the use of the Session Description Protocol
-   (SDP) (RFC 2327 [6]).
-B.1 Configuring Media Streams
-   The caller and callee align their media descriptions so that the nth
-   media stream ("m=" line) in the caller's session description
-   corresponds to the nth media stream in the callee's description.
 
-   All media descriptions SHOULD contain "a=rtpmap" mappings from RTP
-   payload types to encodings.
 
-        This allows easier migration away from static payload
-        types.
 
-   If the callee wants to neither send nor receive a stream offered by
-   the caller, the callee sets the port number of that stream to zero in
-   its media description.
-        There currently is no other way than port zero for the
-        callee to refuse a bidirectional stream offered by the
-        caller. Both caller and callee need to be aware what media
-        tools are to be started.
-   For example, assume that the caller Alice has included the following
-   description in her INVITE request. It includes an audio stream and
-   two bidirectional video streams, using H.261 (payload type 31) and
-   MPEG (payload type 32).
-   v=0
-   o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
-   c=IN IP4 host.anywhere.com
-   m=audio 49170 RTP/AVP 0
-   a=rtpmap:0 PCMU/8000
-   m=video 51372 RTP/AVP 31
-   a=rtpmap:31 H261/90000
-   m=video 53000 RTP/AVP 32
-   a=rtpmap:32 MPV/90000
-   The callee, Bob, does not want to receive or send the first video
-   stream, so it returns the media description below:
 
-   v=0
-   o=bob 2890844730 2890844730 IN IP4 host.example.com
-   c=IN IP4 host.example.com
-   m=audio 47920 RTP/AVP 0 1
-   a=rtpmap:0 PCMU/8000
-   a=rtpmap:1 1016/8000
-   m=video 0 RTP/AVP 31
-   m=video 53000 RTP/AVP 32
-   a=rtpmap:32 MPV/90000
-B.2 Setting SDP Values for Unicast
-   If a session description from a caller contains a media stream which
-   is listed as send (receive) only, it means that the caller is only
-   willing to send (receive) this stream, not receive (send). The same
-   is true for the callee.
 
-   For receive-only and send-or-receive streams, the port number and
-   address in the session description indicate where the media stream
-   should be sent to by the recipient of the session description, either
-   caller or callee. For send-only streams, the address and port number
-   have no significance and SHOULD be set to zero.
-   The list of payload types for each media stream conveys two pieces of
-   information, namely the set of codecs that the caller or callee is
-   capable of sending or receiving, and the RTP payload type numbers
-   used to identify those codecs. For receive-only or send-and-receive
-   media streams, a caller SHOULD list all of the codecs it is capable
-   of supporting in the session description in an INVITE or ACK. For
-   send-only streams, the caller SHOULD indicate only those it wishes to
-   send for this session. For receive-only streams, the payload type
-   numbers indicate the value of the payload type field in RTP packets
-   the caller is expecting to receive for that codec type. For send-only
-   streams, the payload type numbers indicate the value of the payload
-   type field in RTP packets the caller is planning to send for that
-   codec type.  For send-and-receive streams, the payload type numbers
-   indicate the value of the payload type field the caller expects to
-   both send and receive.
 
-   If a media stream is listed as receive-only by the caller, the callee
-   lists, in the response, those codecs it intends to use from among the
-   ones listed in the request. If a media stream is listed as send-only
-   by the caller, the callee lists, in the response, those codecs it is
-   willing to receive among the ones listed in the the request. If the
-   media stream is listed as both send and receive, the callee lists
-   those codecs it is capable of sending or receiving among the ones
-   listed by the caller in the INVITE. The actual payload type numbers
-   in the callee's session description corresponding to a particular
-   codec MUST be the same as the caller's session description.
-   If caller and callee have no media formats in common for a particular
-   stream, the callee MUST return a session description containing the
-   particular "m=" line, but with the port number set to zero, and no
-   payload types listed.
 
-   If there are no media formats in common for all streams, the callee
-   SHOULD return a 400 response, with a 304 Warning header field.
-B.3 Multicast Operation
 
-   The interpretation of send-only and receive-only for multicast media
-   sessions differs from that for unicast sessions. For multicast,
-   send-only means that the recipient of the session description (caller
-   or callee) SHOULD only send media streams to the address and port
-   indicated. Receive-only means that the recipient of the session
-   description SHOULD only receive media on the address and port
-   indicated.
 
-   For multicast, receive and send multicast addresses are the same and
-   all parties use the same port numbers to receive media data. If the
-   session description provided by the caller is acceptable to the
-   callee, the callee can choose not to include a session description or
-   MAY echo the description in the response.
 
-   A callee MAY, in the response, return a session description with some
-   of the payload types removed, or port numbers set to zero (but no
-   other value). This indicates to the caller that the callee does not
-   support the given stream or media types which were removed. A callee
-   MUST NOT change whether a given stream is send-only, receive-only, or
-   send-and-receive.
-   If a callee does not support multicast at all, it SHOULD return a 400
-   status response and include a 330 Warning.
-B.4 Delayed Media Streams
 
-   In some cases, a caller may not know the set of media formats which
-   it can support at the time it would like to issue an invitation. This
-   is the case when the caller is actually a gateway to another protocol
-   which performs media format negotiation after call setup. When this
-   occurs, a caller MAY issue an INVITE with a session description that
-   contains no media lines. The callee SHOULD interpret this to mean
-   that the caller wishes to participate in a multimedia session
-   described by the session description, but that the media streams are
-   not yet known. The callee SHOULD return a session description
-   indicating the streams and media formats it is willing to support,
-   however. The caller MAY update the session description either in the
-   ACK request or in a re-INVITE at a later time, once the streams are
-   known.
-B.5 Putting Media Streams on Hold
-   If a party in a call wants to put the other party "on hold", i.e.,
-   request that it temporarily stops sending one or more media streams,
-   a party re-invites the other by sending an INVITE request with a
-   modified session description. The session description is the same as
-   in the original invitation (or response), but the "c" destination
-   addresses for the media streams to be put on hold are set to zero
-   (0.0.0.0).
-B.6 Subject and SDP "s=" Line
-   The SDP "s=" line and the SIP Subject header field have different
-   meanings when inviting to a multicast session. The session
-   description line describes the subject of the multicast session,
-   while the SIP Subject header field describes the reason for the
-   invitation. The example in Section 16.2 illustrates this point. For
-   invitations to two-party sessions, the SDP "s=" line MAY be left
-   empty.
 
-B.7 The SDP "o=" Line
 
-   The "o=" line is not strictly necessary for two-party sessions, but
-   MUST be present to allow re-use of SDP-based tools.
 

+27 IANA Considerations
-
-   Section 4.4 describes a name space and mechanism for registering SIP
-   options.
-
-   Section 6.41 describes the name space for registering SIP warn-codes.

+   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.
+
+   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:
+         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.
 
+      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.
 
 
+   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.
 
+   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.
 
 
+   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.
+   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.
 
+   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.

-D Using SRV DNS Records
 
-   The following procedure is experimental and relies on DNS SRV records
-   (RFC 2052 [14]). The steps listed below are used in place of the two
-   steps in section 1.4.2.
-
-   If a step elicits no addresses, the client continues to the next
-   step.  However if a step elicits one or more addresses, but no SIP
-   server at any of those addresses responds, then the client concludes
-   the server is down and doesn't continue on to the next step.
-
-   When SRV records are to be used, the protocol to use when querying
-   for the SRV record is "sip". SRV records contain port numbers for
-   servers, in addition to IP addresses; the client always uses this
-   port number when contacting the SIP server. Otherwise, the port
-   number in the SIP URI is used, if present. If there is no port number
-   in the URI, the default port, 5060, is used.
-
-        1.   If the host portion of the Request-URI is an IP address,
-             the client contacts the server at the given address. If the
-             host portion of the Request-URI is not an IP address, the
-             client proceeds to the next step.
-
-        2.   The Request-URI is examined. If it contains an explicit
-             port number, the next two steps are skipped.
-
-        3.   The Request-URI is examined. If it does not specify a
-             protocol (TCP or UDP), the client queries the name server
-             for SRV records for both UDP (if supported by the client)
-             and TCP (if supported by the client) SIP servers. The
-             format of these queries is defined in RFC 2052 [14]. The
-             results of the query or queries are merged together and
-             ordered based on priority. Then, the searching technique
-             outlined in RFC 2052 [14] is used to select servers in
-             order.  If DNS doesn't return any records, the user goes to
-             the last step.  Otherwise, the user attempts to contact
-             each server in the order listed.  If no server is
-             contacted, the user gives up.
-
-        4.   If the Request-URI specifies a protocol (TCP or UDP) that
-             is supported by the client, the client queries the name
-             server for SRV records for SIP servers of that protocol
-             type only. If the client does not support the protocol
-             specified in the Request-URI, it gives up. The searching
-             technique outlined in RFC 2052 [14] is used to select
-             servers from the DNS response in order. If DNS doesn't
-             return any records, the user goes to the last step.
-             Otherwise, the user attempts to contact each server in the
-             order listed. If no server is contacted, the user gives up.
-
-        5.   The client queries the name server for address records for
-             the host portion of the Request-URI. If there were no
-             address records, the client stops, as it has been unable to
-             locate a server. By address record, we mean A RR's, AAAA
-             RR's, or their most modern equivalent.
-
-   A client MAY cache a successful DNS query result. A successful query
-   is one which contained records in the answer, and a server was
-   contacted at one of the addresses from the answer. When the client
-   wishes to send a request to the same host, it starts the search as if
-   it had just received this answer from the name server. The server
-   uses the procedures specified in RFC1035 [15] regarding cache
-   invalidation when the time-to-live of the DNS result expires. If the
-   client does not find a SIP server among the addresses listed in the
-   cached answer, it starts the search at the beginning of the sequence
-   described above.
-
-   For example, consider a client that wishes to send a SIP request. The
-   Request-URI for the destination is sip:user@company.com.  The client
-   only supports UDP. It would follow these steps:
-
-        1.   The host portion is not an IP address, so the client goes
-             to step 2 above.
-
-        2.   The client does a DNS query of QNAME="sip.udp.company.com",
-             QCLASS=IN, QTYPE=SRV. Since it doesn't support TCP, it
-             omits the TCP query. There were no addresses in the DNS
-             response, so the client goes to the next step.
-
-        3.   The client does a DNS query for A records for
-             "company.com". An address is found, so that client attempts
-             to contact a server at that address at port 5060.

-H Bibliography
+29 Normative References

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

-   [2] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
-       "Resource ReSerVation protocol (RSVP) -- version 1 functional
-       specification", RFC 2205, October 1997.
-
-   [3] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
-       a transport protocol for real-time applications", RFC 1889,
-       Internet Engineering Task Force, Jan. 1996.
+   [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.
-
-   [5] Handley, M., "SAP: Session announcement protocol," Internet
-       Draft, Internet Engineering Task Force, Nov. 1996.  Work in
-       progress.
-
-   [6] Handley, M. and V. Jacobson, "SDP: session description protocol",
-       RFC 2327, April 1998.
-
-   [7] International Telecommunication Union, "Visual telephone systems
-       and equipment for local area networks which provide a non-
-       guaranteed quality of service," Recommendation H.323,
-       Telecommunication Standardization Sector of ITU, Geneva,
-       Switzerland, May 1996.
 
-   [8] International Telecommunication Union, "Control protocol for
-       multimedia communication," Recommendation H.245,
-       Telecommunication Standardization Sector of ITU, Geneva,
-       Switzerland, Feb. 1998.
 
-   [9] International Telecommunication Union, "Media stream
-       packetization and synchronization on non-guaranteed quality of
-       service LANs," Recommendation H.225.0, Telecommunication
-       Standardization Sector of ITU, Geneva, Switzerland, Nov. 1996.
-   [24] Crocker, D., "Standard for the format of ARPA internet text
-        messages", RFC STD 11, RFC 822, August 1982.
+   [3]  Resnick, P., "Internet Message Format", RFC 2822, April 2001.
+   [4]  Rosenberg, J. and H. Schulzrinne, "SIP: Locating SIP Servers",
+        RFC 3263, June 2002.

-   [10] Bradner, S., "Key words for use in RFCs to indicate requirement
-        levels", BCP 14,  RFC 2119, Mardch 1997.
-   [12] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform resource
-        identifiers (URI): generic syntax", RFC 2396, August 1998.
+   [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.

-   [21] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
-        2279, January 1998.
+   [7]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
+        2279, January 1998.
 
-   [11] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T.
-        Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1", RFC
-        2068, January 1997.
+   [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.

-   [13] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform resource
-        locators (URL)", RFC 1738, December 1994.
 
-   [14] Gulbrandsen, A.  and P. Vixie, "A DNS RR for specifying the
-        location of services (DNS SRV)", RFC 2052, October 1996.
-
-   [15] Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, Noveberm 1997.
-
-   [16] Hamilton, M. and R. Wright, "Use of DNS aliases for network
-        services", RFC 2219, October 1997.
-
-   [17] Zimmerman, D., "The finger user information protocol", RFC 1288,
-        December 1991.
-
-   [18] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K.
-        Zeilstra, "Referral whois (rwhois) protocol V1.5", RFC 2167,
-        June 1997.
-
-   [19] Yeong, W., Howes, T. and S. Kille, "Lightweight directory access
-        protocol", RFC 1777, March 1995.
-
-   [22] Stevens, W., TCP/IP illustrated: the protocols , vol. 1.
-        Reading, Massachusetts: Addison-Wesley, 1994.
 
-   [23] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
-        November 1990.

 
+   [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.
-   [25] Meyer, D., "Administratively scoped IP multicast", RFC 2365,
-        July 1998.
+   [11] Freed, F. and N. Borenstein, "Multipurpose Internet Mail
+        Extensions (MIME) Part Two: Media Types", RFC 2046, November
+        1996.
 

-   [27] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-        recommendations for security", RFC 1750, December 1994.
+   [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.
 
+   [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.

-   [36] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
-        Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication:
-        Basic and digest access authentication," Internet Draft,
-        Internet Engineering Task Force, Sept.  1998.  Work in progress.
+   [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.

-   [26] Schulzrinne, H., "RTP profile for audio and video conferences
-        with minimal control", RFC 1890, January 1996
+   [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.
 
-   [29] Braden, B., "Requirements for internet hosts - application and
-        support", STD 3, RFC 1123, October 1989.
+   [20] Braden, R., "Requirements for Internet Hosts - Application and
+        Support", STD 3, RFC 1123, October 1989.
 
-   [31] Alvestrand, H., "IETF policy on character sets and languages",
-        RFC 2277, January 1998.
+   [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.
 
-   [35] Allen, C. and T. Dierks, "The TLS protocol version 1.0," RFC
-        2246, January 1999.
+   [25] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+        2246, January 1999.
-   [34] Atkinson, R., "Security architecture for the internet protocol",
-        RFC 2401, November 1998.
+   [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.

-   [4] Schulzrinne, H., Lanphier, R. and A. Rao, "Real time streaming
-       protocol (RTSP)", RFC 2326, April 1998.
+   [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.
 
-   [28] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL
-        scheme", RFC 2368, July 1998.
+   [32] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL
+        scheme", RFC 2368, July 1998.
 
-
-   [20] Schooler, E., "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.
+   [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.
 
-   [30] Palme, J., "Common internet message headers", RFC 2076, February
-        1997.
+   [38] Palme, J., "Common Internet Message Headers",  RFC 2076,
+        February 1997.

 
 
-   [32] Elkins, M., "MIME security with pretty good privacy (PGP)", RFC
-        2015, October 1996.
 
-   [33] Atkins, D., Stallings, W. and P. Zimmermann, "PGP message
-        exchange formats", RFC 1991, August 1996.

+   [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.

-   [37] Schooler, E., "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.
+   [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.

-   [38] Schulzrinne, H., "Personal mobility for multimedia services in
-        the Internet," in European Workshop on Interactive Distributed
-        Multimedia Systems and Services (IDMS) , (Berlin, Germany), Mar.
-        1996.
+   [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.

+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
-F Acknowledgments
+Acknowledgments
-
-   We wish to thank the members of the IETF MMUSIC WG for their comments
+   We wish to thank the members of the IETF MMUSIC and SIP WGs for their comments
and suggestions.  Detailed comments were provided by
-   Anders Kristensen, Jim Buller, Dave Devanathan, Yaron Goland, Christian
-   Huitema, Gadi Karmi, Jonathan Lennox, Keith Moore, Vern Paxson, Moshe
-   J. Sambol, and Eric Tremblay.
+   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 [37,38].
+   This work is based, inter alia, on [41,42].
-
 
-G Authors' Addresses
+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
 
-   Mark Handley
-   AT&T Center for Internet Research at ISCI (ACIRI)
-   1947 Center St., Suite 600
-   Berkeley, CA 94704-119
-   USA
-   Email: mjh@aciri.org
 
    Henning Schulzrinne
    Dept. of Computer Science
@@ -6905,162 +12530,72 @@
    1214 Amsterdam Avenue
    New York, NY 10027
    USA
-   Email:  schulzrinne@cs.columbia.edu
-
-   Eve Schooler
-   Computer Science Department 256-80
-   California Institute of Technology
-   Pasadena, CA 91125
-   USA
-   Email:  schooler@cs.caltech.edu
-
-   Jonathan Rosenberg
-   Lucent Technologies, Bell Laboratories
-   Rm. 4C-526
-   101 Crawfords Corner Road
-   Holmdel, NJ 07733
-   USA
-   Email:  jdrosen@bell-labs.com
+   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
+   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
 
 Full Copyright Statement
 
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+   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
@@ -7085,3 +12620,9 @@
    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.
+
