











Network Working Group                                       J. Rosenberg

Request for Comments: 3261                                   dynamicsoft

Obsoletes: 2543                                           H. Schulzrinne

Category: Standards Track                                    Columbia U.

                                                            G. Camarillo

                                                                Ericsson

                                                             A. Johnston

                                                                WorldCom

                                                             J. Peterson

                                                                 Neustar

                                                               R. Sparks

                                                             dynamicsoft

                                                              M. Handley

                                                                    ICIR

                                                             E. Schooler

                                                                    AT&T

                                                               June 2002



                    SIP: Session Initiation Protocol



Status of this Memo



   This document specifies an Internet standards track protocol for the

   Internet community, and requests discussion and suggestions for

   improvements.  Please refer to the current edition of the "Internet

   Official Protocol Standards" (STD 1) for the standardization state

   and status of this protocol.  Distribution of this memo is unlimited.



Copyright Notice



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



Abstract



   This document describes Session Initiation Protocol (SIP), an

   application-layer control (signaling) protocol for creating,

   modifying, and terminating sessions with one or more participants.

   These sessions include Internet telephone calls, multimedia

   distribution, and multimedia conferences.



   SIP invitations used to create sessions carry session descriptions

   that allow participants to agree on a set of compatible media types.

   SIP makes use of elements called proxy servers to help route requests

   to the user's current location, authenticate and authorize users for

   services, implement provider call-routing policies, and provide

   features to users.  SIP also provides a registration function that

   allows users to upload their current locations for use by proxy

   servers.  SIP runs on top of several different transport protocols.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





Table of Contents



   1          Introduction ........................................    8

   2          Overview of SIP Functionality .......................    9

   3          Terminology .........................................   10

   4          Overview of Operation ...............................   10

   5          Structure of the Protocol ...........................   18

   6          Definitions .........................................   20

   7          SIP Messages ........................................   26

   7.1        Requests ............................................   27

   7.2        Responses ...........................................   28

   7.3        Header Fields .......................................   29

   7.3.1      Header Field Format .................................   30

   7.3.2      Header Field Classification .........................   32

   7.3.3      Compact Form ........................................   32

   7.4        Bodies ..............................................   33

   7.4.1      Message Body Type ...................................   33

   7.4.2      Message Body Length .................................   33

   7.5        Framing SIP Messages ................................   34

   8          General User Agent Behavior .........................   34

   8.1        UAC Behavior ........................................   35

   8.1.1      Generating the Request ..............................   35

   8.1.1.1    Request-URI .........................................   35

   8.1.1.2    To ..................................................   36

   8.1.1.3    From ................................................   37

   8.1.1.4    Call-ID .............................................   37

   8.1.1.5    CSeq ................................................   38

   8.1.1.6    Max-Forwards ........................................   38

   8.1.1.7    Via .................................................   39

   8.1.1.8    Contact .............................................   40

   8.1.1.9    Supported and Require ...............................   40

   8.1.1.10   Additional Message Components .......................   41

   8.1.2      Sending the Request .................................   41

   8.1.3      Processing Responses ................................   42

   8.1.3.1    Transaction Layer Errors ............................   42

   8.1.3.2    Unrecognized Responses ..............................   42

   8.1.3.3    Vias ................................................   43

   8.1.3.4    Processing 3xx Responses ............................   43

   8.1.3.5    Processing 4xx Responses ............................   45

   8.2        UAS Behavior ........................................   46

   8.2.1      Method Inspection ...................................   46

   8.2.2      Header Inspection ...................................   46

   8.2.2.1    To and Request-URI ..................................   46

   8.2.2.2    Merged Requests .....................................   47

   8.2.2.3    Require .............................................   47

   8.2.3      Content Processing ..................................   48

   8.2.4      Applying Extensions .................................   49

   8.2.5      Processing the Request ..............................   49







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   8.2.6      Generating the Response .............................   49

   8.2.6.1    Sending a Provisional Response ......................   49

   8.2.6.2    Headers and Tags ....................................   50

   8.2.7      Stateless UAS Behavior ..............................   50

   8.3        Redirect Servers ....................................   51

   9          Canceling a Request .................................   53

   9.1        Client Behavior .....................................   53

   9.2        Server Behavior .....................................   55

   10         Registrations .......................................   56

   10.1       Overview ............................................   56

   10.2       Constructing the REGISTER Request ...................   57

   10.2.1     Adding Bindings .....................................   59

   10.2.1.1   Setting the Expiration Interval of Contact Addresses    60

   10.2.1.2   Preferences among Contact Addresses .................   61

   10.2.2     Removing Bindings ...................................   61

   10.2.3     Fetching Bindings ...................................   61

   10.2.4     Refreshing Bindings .................................   61

   10.2.5     Setting the Internal Clock ..........................   62

   10.2.6     Discovering a Registrar .............................   62

   10.2.7     Transmitting a Request ..............................   62

   10.2.8     Error Responses .....................................   63

   10.3       Processing REGISTER Requests ........................   63

   11         Querying for Capabilities ...........................   66

   11.1       Construction of OPTIONS Request .....................   67

   11.2       Processing of OPTIONS Request .......................   68

   12         Dialogs .............................................   69

   12.1       Creation of a Dialog ................................   70

   12.1.1     UAS behavior ........................................   70

   12.1.2     UAC Behavior ........................................   71

   12.2       Requests within a Dialog ............................   72

   12.2.1     UAC Behavior ........................................   73

   12.2.1.1   Generating the Request ..............................   73

   12.2.1.2   Processing the Responses ............................   75

   12.2.2     UAS Behavior ........................................   76

   12.3       Termination of a Dialog .............................   77

   13         Initiating a Session ................................   77

   13.1       Overview ............................................   77

   13.2       UAC Processing ......................................   78

   13.2.1     Creating the Initial INVITE .........................   78

   13.2.2     Processing INVITE Responses .........................   81

   13.2.2.1   1xx Responses .......................................   81

   13.2.2.2   3xx Responses .......................................   81

   13.2.2.3   4xx, 5xx and 6xx Responses ..........................   81

   13.2.2.4   2xx Responses .......................................   82

   13.3       UAS Processing ......................................   83

   13.3.1     Processing of the INVITE ............................   83

   13.3.1.1   Progress ............................................   84

   13.3.1.2   The INVITE is Redirected ............................   84







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   13.3.1.3   The INVITE is Rejected ..............................   85

   13.3.1.4   The INVITE is Accepted ..............................   85

   14         Modifying an Existing Session .......................   86

   14.1       UAC Behavior ........................................   86

   14.2       UAS Behavior ........................................   88

   15         Terminating a Session ...............................   89

   15.1       Terminating a Session with a BYE Request ............   90

   15.1.1     UAC Behavior ........................................   90

   15.1.2     UAS Behavior ........................................   91

   16         Proxy Behavior ......................................   91

   16.1       Overview ............................................   91

   16.2       Stateful Proxy ......................................   92

   16.3       Request Validation ..................................   94

   16.4       Route Information Preprocessing .....................   96

   16.5       Determining Request Targets .........................   97

   16.6       Request Forwarding ..................................   99

   16.7       Response Processing .................................  107

   16.8       Processing Timer C ..................................  114

   16.9       Handling Transport Errors ...........................  115

   16.10      CANCEL Processing ...................................  115

   16.11      Stateless Proxy .....................................  116

   16.12      Summary of Proxy Route Processing ...................  118

   16.12.1    Examples ............................................  118

   16.12.1.1  Basic SIP Trapezoid .................................  118

   16.12.1.2  Traversing a Strict-Routing Proxy ...................  120

   16.12.1.3  Rewriting Record-Route Header Field Values ..........  121

   17         Transactions ........................................  122

   17.1       Client Transaction ..................................  124

   17.1.1     INVITE Client Transaction ...........................  125

   17.1.1.1   Overview of INVITE Transaction ......................  125

   17.1.1.2   Formal Description ..................................  125

   17.1.1.3   Construction of the ACK Request .....................  129

   17.1.2     Non-INVITE Client Transaction .......................  130

   17.1.2.1   Overview of the non-INVITE Transaction ..............  130

   17.1.2.2   Formal Description ..................................  131

   17.1.3     Matching Responses to Client Transactions ...........  132

   17.1.4     Handling Transport Errors ...........................  133

   17.2       Server Transaction ..................................  134

   17.2.1     INVITE Server Transaction ...........................  134

   17.2.2     Non-INVITE Server Transaction .......................  137

   17.2.3     Matching Requests to Server Transactions ............  138

   17.2.4     Handling Transport Errors ...........................  141

   18         Transport ...........................................  141

   18.1       Clients .............................................  142

   18.1.1     Sending Requests ....................................  142

   18.1.2     Receiving Responses .................................  144

   18.2       Servers .............................................  145

   18.2.1     Receiving Requests ..................................  145







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   18.2.2     Sending Responses ...................................  146

   18.3       Framing .............................................  147

   18.4       Error Handling ......................................  147

   19         Common Message Components ...........................  147

   19.1       SIP and SIPS Uniform Resource Indicators ............  148

   19.1.1     SIP and SIPS URI Components .........................  148

   19.1.2     Character Escaping Requirements .....................  152

   19.1.3     Example SIP and SIPS URIs ...........................  153

   19.1.4     URI Comparison ......................................  153

   19.1.5     Forming Requests from a URI .........................  156

   19.1.6     Relating SIP URIs and tel URLs ......................  157

   19.2       Option Tags .........................................  158

   19.3       Tags ................................................  159

   20         Header Fields .......................................  159

   20.1       Accept ..............................................  161

   20.2       Accept-Encoding .....................................  163

   20.3       Accept-Language .....................................  164

   20.4       Alert-Info ..........................................  164

   20.5       Allow ...............................................  165

   20.6       Authentication-Info .................................  165

   20.7       Authorization .......................................  165

   20.8       Call-ID .............................................  166

   20.9       Call-Info ...........................................  166

   20.10      Contact .............................................  167

   20.11      Content-Disposition .................................  168

   20.12      Content-Encoding ....................................  169

   20.13      Content-Language ....................................  169

   20.14      Content-Length ......................................  169

   20.15      Content-Type ........................................  170

   20.16      CSeq ................................................  170

   20.17      Date ................................................  170

   20.18      Error-Info ..........................................  171

   20.19      Expires .............................................  171

   20.20      From ................................................  172

   20.21      In-Reply-To .........................................  172

   20.22      Max-Forwards ........................................  173

   20.23      Min-Expires .........................................  173

   20.24      MIME-Version ........................................  173

   20.25      Organization ........................................  174

   20.26      Priority ............................................  174

   20.27      Proxy-Authenticate ..................................  174

   20.28      Proxy-Authorization .................................  175

   20.29      Proxy-Require .......................................  175

   20.30      Record-Route ........................................  175

   20.31      Reply-To ............................................  176

   20.32      Require .............................................  176

   20.33      Retry-After .........................................  176

   20.34      Route ...............................................  177







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   20.35      Server ..............................................  177

   20.36      Subject .............................................  177

   20.37      Supported ...........................................  178

   20.38      Timestamp ...........................................  178

   20.39      To ..................................................  178

   20.40      Unsupported .........................................  179

   20.41      User-Agent ..........................................  179

   20.42      Via .................................................  179

   20.43      Warning .............................................  180

   20.44      WWW-Authenticate ....................................  182

   21         Response Codes ......................................  182

   21.1       Provisional 1xx .....................................  182

   21.1.1     100 Trying ..........................................  183

   21.1.2     180 Ringing .........................................  183

   21.1.3     181 Call Is Being Forwarded .........................  183

   21.1.4     182 Queued ..........................................  183

   21.1.5     183 Session Progress ................................  183

   21.2       Successful 2xx ......................................  183

   21.2.1     200 OK ..............................................  183

   21.3       Redirection 3xx .....................................  184

   21.3.1     300 Multiple Choices ................................  184

   21.3.2     301 Moved Permanently ...............................  184

   21.3.3     302 Moved Temporarily ...............................  184

   21.3.4     305 Use Proxy .......................................  185

   21.3.5     380 Alternative Service .............................  185

   21.4       Request Failure 4xx .................................  185

   21.4.1     400 Bad Request .....................................  185

   21.4.2     401 Unauthorized ....................................  185

   21.4.3     402 Payment Required ................................  186

   21.4.4     403 Forbidden .......................................  186

   21.4.5     404 Not Found .......................................  186

   21.4.6     405 Method Not Allowed ..............................  186

   21.4.7     406 Not Acceptable ..................................  186

   21.4.8     407 Proxy Authentication Required ...................  186

   21.4.9     408 Request Timeout .................................  186

   21.4.10    410 Gone ............................................  187

   21.4.11    413 Request Entity Too Large ........................  187

   21.4.12    414 Request-URI Too Long ............................  187

   21.4.13    415 Unsupported Media Type ..........................  187

   21.4.14    416 Unsupported URI Scheme ..........................  187

   21.4.15    420 Bad Extension ...................................  187

   21.4.16    421 Extension Required ..............................  188

   21.4.17    423 Interval Too Brief ..............................  188

   21.4.18    480 Temporarily Unavailable .........................  188

   21.4.19    481 Call/Transaction Does Not Exist .................  188

   21.4.20    482 Loop Detected ...................................  188

   21.4.21    483 Too Many Hops ...................................  189

   21.4.22    484 Address Incomplete ..............................  189







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   21.4.23    485 Ambiguous .......................................  189

   21.4.24    486 Busy Here .......................................  189

   21.4.25    487 Request Terminated ..............................  190

   21.4.26    488 Not Acceptable Here .............................  190

   21.4.27    491 Request Pending .................................  190

   21.4.28    493 Undecipherable ..................................  190

   21.5       Server Failure 5xx ..................................  190

   21.5.1     500 Server Internal Error ...........................  190

   21.5.2     501 Not Implemented .................................  191

   21.5.3     502 Bad Gateway .....................................  191

   21.5.4     503 Service Unavailable .............................  191

   21.5.5     504 Server Time-out .................................  191

   21.5.6     505 Version Not Supported ...........................  192

   21.5.7     513 Message Too Large ...............................  192

   21.6       Global Failures 6xx .................................  192

   21.6.1     600 Busy Everywhere .................................  192

   21.6.2     603 Decline .........................................  192

   21.6.3     604 Does Not Exist Anywhere .........................  192

   21.6.4     606 Not Acceptable ..................................  192

   22         Usage of HTTP Authentication ........................  193

   22.1       Framework ...........................................  193

   22.2       User-to-User Authentication .........................  195

   22.3       Proxy-to-User Authentication ........................  197

   22.4       The Digest Authentication Scheme ....................  199

   23         S/MIME ..............................................  201

   23.1       S/MIME Certificates .................................  201

   23.2       S/MIME Key Exchange .................................  202

   23.3       Securing MIME bodies ................................  205

   23.4       SIP Header Privacy and Integrity using S/MIME:

              Tunneling SIP .......................................  207

   23.4.1     Integrity and Confidentiality Properties of SIP

              Headers .............................................  207

   23.4.1.1   Integrity ...........................................  207

   23.4.1.2   Confidentiality .....................................  208

   23.4.2     Tunneling Integrity and Authentication ..............  209

   23.4.3     Tunneling Encryption ................................  211

   24         Examples ............................................  213

   24.1       Registration ........................................  213

   24.2       Session Setup .......................................  214

   25         Augmented BNF for the SIP Protocol ..................  219

   25.1       Basic Rules .........................................  219

   26         Security Considerations: Threat Model and Security

              Usage Recommendations ...............................  232

   26.1       Attacks and Threat Models ...........................  233

   26.1.1     Registration Hijacking ..............................  233

   26.1.2     Impersonating a Server ..............................  234

   26.1.3     Tampering with Message Bodies .......................  235

   26.1.4     Tearing Down Sessions ...............................  235







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   26.1.5     Denial of Service and Amplification .................  236

   26.2       Security Mechanisms .................................  237

   26.2.1     Transport and Network Layer Security ................  238

   26.2.2     SIPS URI Scheme .....................................  239

   26.2.3     HTTP Authentication .................................  240

   26.2.4     S/MIME ..............................................  240

   26.3       Implementing Security Mechanisms ....................  241

   26.3.1     Requirements for Implementers of SIP ................  241

   26.3.2     Security Solutions ..................................  242

   26.3.2.1   Registration ........................................  242

   26.3.2.2   Interdomain Requests ................................  243

   26.3.2.3   Peer-to-Peer Requests ...............................  245

   26.3.2.4   DoS Protection ......................................  246

   26.4       Limitations .........................................  247

   26.4.1     HTTP Digest .........................................  247

   26.4.2     S/MIME ..............................................  248

   26.4.3     TLS .................................................  249

   26.4.4     SIPS URIs ...........................................  249

   26.5       Privacy .............................................  251

   27         IANA Considerations .................................  252

   27.1       Option Tags .........................................  252

   27.2       Warn-Codes ..........................................  252

   27.3       Header Field Names ..................................  253

   27.4       Method and Response Codes ...........................  253

   27.5       The "message/sip" MIME type.  .......................  254

   27.6       New Content-Disposition Parameter Registrations .....  255

   28         Changes From RFC 2543 ...............................  255

   28.1       Major Functional Changes ............................  255

   28.2       Minor Functional Changes ............................  260

   29         Normative References ................................  261

   30         Informative References ..............................  262

   A          Table of Timer Values ...............................  265

   Acknowledgments ................................................  266

   Authors' Addresses .............................................  267

   Full Copyright Statement .......................................  269



1 Introduction



   There are many applications of the Internet that require the creation

   and management of a session, where a session is considered an

   exchange of data between an association of participants.  The

   implementation of these applications is complicated by the practices

   of participants: users may move between endpoints, they may be

   addressable by multiple names, and they may communicate in several

   different media - sometimes simultaneously.  Numerous protocols have

   been authored that carry various forms of real-time multimedia

   session data such as voice, video, or text messages.  The Session

   Initiation Protocol (SIP) works in concert with these protocols by







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   enabling Internet endpoints (called user agents) to discover one

   another and to agree on a characterization of a session they would

   like to share.  For locating prospective session participants, and

   for other functions, SIP enables the creation of an infrastructure of

   network hosts (called proxy servers) to which user agents can send

   registrations, invitations to sessions, and other requests.  SIP is

   an agile, general-purpose tool for creating, modifying, and

   terminating sessions that works independently of underlying transport

   protocols and without dependency on the type of session that is being

   established.



2 Overview of SIP Functionality



   SIP is an application-layer control protocol that can establish,

   modify, and terminate multimedia sessions (conferences) such as

   Internet telephony calls.  SIP can also invite participants to

   already existing sessions, such as multicast conferences.  Media can

   be added to (and removed from) an existing session.  SIP

   transparently supports name mapping and redirection services, which

   supports personal mobility [27] - users can maintain a single

   externally visible identifier regardless of their network location.



   SIP supports five facets of establishing and terminating multimedia

   communications:



      User location: determination of the end system to be used for

           communication;



      User availability: determination of the willingness of the called

           party to engage in communications;



      User capabilities: determination of the media and media parameters

           to be used;



      Session setup: "ringing", establishment of session parameters at

           both called and calling party;



      Session management: including transfer and termination of

           sessions, modifying session parameters, and invoking

           services.



   SIP is not a vertically integrated communications system.  SIP is

   rather a component that can be used with other IETF protocols to

   build a complete multimedia architecture.  Typically, these

   architectures will include protocols such as the Real-time Transport

   Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and

   providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC

   2326 [29]) for controlling delivery of streaming media, the Media







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling

   gateways to the Public Switched Telephone Network (PSTN), and the

   Session Description Protocol (SDP) (RFC 2327 [1]) for describing

   multimedia sessions.  Therefore, SIP should be used in conjunction

   with other protocols in order to provide complete services to the

   users.  However, the basic functionality and operation of SIP does

   not depend on any of these protocols.



   SIP does not provide services.  Rather, SIP provides primitives that

   can be used to implement different services.  For example, SIP can

   locate a user and deliver an opaque object to his current location.

   If this primitive is used to deliver a session description written in

   SDP, for instance, the endpoints can agree on the parameters of a

   session.  If the same primitive is used to deliver a photo of the

   caller as well as the session description, a "caller ID" service can

   be easily implemented.  As this example shows, a single primitive is

   typically used to provide several different services.



   SIP does not offer conference control services such as floor control

   or voting and does not prescribe how a conference is to be managed.

   SIP can be used to initiate a session that uses some other conference

   control protocol.  Since SIP messages and the sessions they establish

   can pass through entirely different networks, SIP cannot, and does

   not, provide any kind of network resource reservation capabilities.



   The nature of the services provided make security particularly

   important.  To that end, SIP provides a suite of security services,

   which include denial-of-service prevention, authentication (both user

   to user and proxy to user), integrity protection, and encryption and

   privacy services.



   SIP works with both IPv4 and IPv6.



3 Terminology



   In this document, the key words "MUST", "MUST NOT", "REQUIRED",

   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT

   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as

   described in BCP 14, RFC 2119 [2] and indicate requirement levels for

   compliant SIP implementations.



4 Overview of Operation



   This section introduces the basic operations of SIP using simple

   examples.  This section is tutorial in nature and does not contain

   any normative statements.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The first example shows the basic functions of SIP: location of an

   end point, signal of a desire to communicate, negotiation of session

   parameters to establish the session, and teardown of the session once

   established.



   Figure 1 shows a typical example of a SIP message exchange between

   two users, Alice and Bob.  (Each message is labeled with the letter

   "F" and a number for reference by the text.)  In this example, Alice

   uses a SIP application on her PC (referred to as a softphone) to call

   Bob on his SIP phone over the Internet.  Also shown are two SIP proxy

   servers that act on behalf of Alice and Bob to facilitate the session

   establishment.  This typical arrangement is often referred to as the

   "SIP trapezoid" as shown by the geometric shape of the dotted lines

   in Figure 1.



   Alice "calls" Bob using his SIP identity, a type of Uniform Resource

   Identifier (URI) called a SIP URI. SIP URIs are defined in Section

   19.1.  It has a similar form to an email address, typically

   containing a username and a host name.  In this case, it is

   sip:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP

   service provider.  Alice has a SIP URI of sip:alice@atlanta.com.

   Alice might have typed in Bob's URI or perhaps clicked on a hyperlink

   or an entry in an address book.  SIP also provides a secure URI,

   called a SIPS URI.  An example would be sips:bob@biloxi.com.  A call

   made to a SIPS URI guarantees that secure, encrypted transport

   (namely TLS) is used to carry all SIP messages from the caller to the

   domain of the callee.  From there, the request is sent securely to

   the callee, but with security mechanisms that depend on the policy of

   the domain of the callee.



   SIP is based on an HTTP-like request/response transaction model.

   Each transaction consists of a request that invokes a particular

   method, or function, on the server and at least one response.  In

   this example, the transaction begins with Alice's softphone sending

   an INVITE request addressed to Bob's SIP URI.  INVITE is an example

   of a SIP method that specifies the action that the requestor (Alice)

   wants the server (Bob) to take.  The INVITE request contains a number

   of header fields.  Header fields are named attributes that provide

   additional information about a message.  The ones present in an

   INVITE include a unique identifier for the call, the destination

   address, Alice's address, and information about the type of session

   that Alice wishes to establish with Bob.  The INVITE (message F1 in

   Figure 1) might look like this:

















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





                     atlanta.com  . . . biloxi.com

                 .      proxy              proxy     .

               .                                       .

       Alice's  . . . . . . . . . . . . . . . . . . . .  Bob's

      softphone                                        SIP Phone

         |                |                |                |

         |    INVITE F1   |                |                |

         |--------------->|    INVITE F2   |                |

         |  100 Trying F3 |--------------->|    INVITE F4   |

         |<---------------|  100 Trying F5 |--------------->|

         |                |<-------------- | 180 Ringing F6 |

         |                | 180 Ringing F7 |<---------------|

         | 180 Ringing F8 |<---------------|     200 OK F9  |

         |<---------------|    200 OK F10  |<---------------|

         |    200 OK F11  |<---------------|                |

         |<---------------|                |                |

         |                       ACK F12                    |

         |------------------------------------------------->|

         |                   Media Session                  |

         |<================================================>|

         |                       BYE F13                    |

         |<-------------------------------------------------|

         |                     200 OK F14                   |

         |------------------------------------------------->|

         |                                                  |



         Figure 1: SIP session setup example with SIP trapezoid



      INVITE sip:bob@biloxi.com SIP/2.0

      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds

      Max-Forwards: 70

      To: Bob <sip:bob@biloxi.com>

      From: Alice <sip:alice@atlanta.com>;tag=1928301774

      Call-ID: a84b4c76e66710@pc33.atlanta.com

      CSeq: 314159 INVITE

      Contact: <sip:alice@pc33.atlanta.com>

      Content-Type: application/sdp

      Content-Length: 142



      (Alice's SDP not shown)



   The first line of the text-encoded message contains the method name

   (INVITE).  The lines that follow are a list of header fields.  This

   example contains a minimum required set.  The header fields are

   briefly described below:













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Via contains the address (pc33.atlanta.com) at which Alice is

   expecting to receive responses to this request.  It also contains a

   branch parameter that identifies this transaction.



   To contains a display name (Bob) and a SIP or SIPS URI

   (sip:bob@biloxi.com) towards which the request was originally

   directed.  Display names are described in RFC 2822 [3].



   From also contains a display name (Alice) and a SIP or SIPS URI

   (sip:alice@atlanta.com) that indicate the originator of the request.

   This header field also has a tag parameter containing a random string

   (1928301774) that was added to the URI by the softphone.  It is used

   for identification purposes.



   Call-ID contains a globally unique identifier for this call,

   generated by the combination of a random string and the softphone's

   host name or IP address.  The combination of the To tag, From tag,

   and Call-ID completely defines a peer-to-peer SIP relationship

   between Alice and Bob and is referred to as a dialog.



   CSeq or Command Sequence contains an integer and a method name.  The

   CSeq number is incremented for each new request within a dialog and

   is a traditional sequence number.



   Contact contains a SIP or SIPS URI that represents a direct route to

   contact Alice, usually composed of a username at a fully qualified

   domain name (FQDN).  While an FQDN is preferred, many end systems do

   not have registered domain names, so IP addresses are permitted.

   While the Via header field tells other elements where to send the

   response, the Contact header field tells other elements where to send

   future requests.



   Max-Forwards serves to limit the number of hops a request can make on

   the way to its destination.  It consists of an integer that is

   decremented by one at each hop.



   Content-Type contains a description of the message body (not shown).



   Content-Length contains an octet (byte) count of the message body.



   The complete set of SIP header fields is defined in Section 20.



   The details of the session, such as the type of media, codec, or

   sampling rate, are not described using SIP.  Rather, the body of a

   SIP message contains a description of the session, encoded in some

   other protocol format.  One such format is the Session Description

   Protocol (SDP) (RFC 2327 [1]).  This SDP message (not shown in the









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   example) is carried by the SIP message in a way that is analogous to

   a document attachment being carried by an email message, or a web

   page being carried in an HTTP message.



   Since the softphone does not know the location of Bob or the SIP

   server in the biloxi.com domain, the softphone sends the INVITE to

   the SIP server that serves Alice's domain, atlanta.com.  The address

   of the atlanta.com SIP server could have been configured in Alice's

   softphone, or it could have been discovered by DHCP, for example.



   The atlanta.com SIP server is a type of SIP server known as a proxy

   server.  A proxy server receives SIP requests and forwards them on

   behalf of the requestor.  In this example, the proxy server receives

   the INVITE request and sends a 100 (Trying) response back to Alice's

   softphone.  The 100 (Trying) response indicates that the INVITE has

   been received and that the proxy is working on her behalf to route

   the INVITE to the destination.  Responses in SIP use a three-digit

   code followed by a descriptive phrase.  This response contains the

   same To, From, Call-ID, CSeq and branch parameter in the Via as the

   INVITE, which allows Alice's softphone to correlate this response to

   the sent INVITE.  The atlanta.com proxy server locates the proxy

   server at biloxi.com, possibly by performing a particular type of DNS

   (Domain Name Service) lookup to find the SIP server that serves the

   biloxi.com domain.  This is described in [4].  As a result, it

   obtains the IP address of the biloxi.com proxy server and forwards,

   or proxies, the INVITE request there.  Before forwarding the request,

   the atlanta.com proxy server adds an additional Via header field

   value that contains its own address (the INVITE already contains

   Alice's address in the first Via).  The biloxi.com proxy server

   receives the INVITE and responds with a 100 (Trying) response back to

   the atlanta.com proxy server to indicate that it has received the

   INVITE and is processing the request.  The proxy server consults a

   database, generically called a location service, that contains the

   current IP address of Bob.  (We shall see in the next section how

   this database can be populated.)  The biloxi.com proxy server adds

   another Via header field value with its own address to the INVITE and

   proxies it to Bob's SIP phone.



   Bob's SIP phone receives the INVITE and alerts Bob to the incoming

   call from Alice so that Bob can decide whether to answer the call,

   that is, Bob's phone rings.  Bob's SIP phone indicates this in a 180

   (Ringing) response, which is routed back through the two proxies in

   the reverse direction.  Each proxy uses the Via header field to

   determine where to send the response and removes its own address from

   the top.  As a result, although DNS and location service lookups were

   required to route the initial INVITE, the 180 (Ringing) response can

   be returned to the caller without lookups or without state being









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   maintained in the proxies.  This also has the desirable property that

   each proxy that sees the INVITE will also see all responses to the

   INVITE.



   When Alice's softphone receives the 180 (Ringing) response, it passes

   this information to Alice, perhaps using an audio ringback tone or by

   displaying a message on Alice's screen.



   In this example, Bob decides to answer the call.  When he picks up

   the handset, his SIP phone sends a 200 (OK) response to indicate that

   the call has been answered.  The 200 (OK) contains a message body

   with the SDP media description of the type of session that Bob is

   willing to establish with Alice.  As a result, there is a two-phase

   exchange of SDP messages: Alice sent one to Bob, and Bob sent one

   back to Alice.  This two-phase exchange provides basic negotiation

   capabilities and is based on a simple offer/answer model of SDP

   exchange.  If Bob did not wish to answer the call or was busy on

   another call, an error response would have been sent instead of the

   200 (OK), which would have resulted in no media session being

   established.  The complete list of SIP response codes is in Section

   21.  The 200 (OK) (message F9 in Figure 1) might look like this as

   Bob sends it out:



      SIP/2.0 200 OK

      Via: SIP/2.0/UDP server10.biloxi.com

         ;branch=z9hG4bKnashds8;received=192.0.2.3

      Via: SIP/2.0/UDP bigbox3.site3.atlanta.com

         ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2

      Via: SIP/2.0/UDP pc33.atlanta.com

         ;branch=z9hG4bK776asdhds ;received=192.0.2.1

      To: Bob <sip:bob@biloxi.com>;tag=a6c85cf

      From: Alice <sip:alice@atlanta.com>;tag=1928301774

      Call-ID: a84b4c76e66710@pc33.atlanta.com

      CSeq: 314159 INVITE

      Contact: <sip:bob@192.0.2.4>

      Content-Type: application/sdp

      Content-Length: 131



      (Bob's SDP not shown)



   The first line of the response contains the response code (200) and

   the reason phrase (OK).  The remaining lines contain header fields.

   The Via, To, From, Call-ID, and CSeq header fields are copied from

   the INVITE request.  (There are three Via header field values - one

   added by Alice's SIP phone, one added by the atlanta.com proxy, and

   one added by the biloxi.com proxy.)  Bob's SIP phone has added a tag

   parameter to the To header field.  This tag will be incorporated by

   both endpoints into the dialog and will be included in all future







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   requests and responses in this call.  The Contact header field

   contains a URI at which Bob can be directly reached at his SIP phone.

   The Content-Type and Content-Length refer to the message body (not

   shown) that contains Bob's SDP media information.



   In addition to DNS and location service lookups shown in this

   example, proxy servers can make flexible "routing decisions" to

   decide where to send a request.  For example, if Bob's SIP phone

   returned a 486 (Busy Here) response, the biloxi.com proxy server

   could proxy the INVITE to Bob's voicemail server.  A proxy server can

   also send an INVITE to a number of locations at the same time.  This

   type of parallel search is known as forking.



   In this case, the 200 (OK) is routed back through the two proxies and

   is received by Alice's softphone, which then stops the ringback tone

   and indicates that the call has been answered.  Finally, Alice's

   softphone sends an acknowledgement message, ACK, to Bob's SIP phone

   to confirm the reception of the final response (200 (OK)).  In this

   example, the ACK is sent directly from Alice's softphone to Bob's SIP

   phone, bypassing the two proxies.  This occurs because the endpoints

   have learned each other's address from the Contact header fields

   through the INVITE/200 (OK) exchange, which was not known when the

   initial INVITE was sent.  The lookups performed by the two proxies

   are no longer needed, so the proxies drop out of the call flow.  This

   completes the INVITE/200/ACK three-way handshake used to establish

   SIP sessions.  Full details on session setup are in Section 13.



   Alice and Bob's media session has now begun, and they send media

   packets using the format to which they agreed in the exchange of SDP.

   In general, the end-to-end media packets take a different path from

   the SIP signaling messages.



   During the session, either Alice or Bob may decide to change the

   characteristics of the media session.  This is accomplished by

   sending a re-INVITE containing a new media description.  This re-

   INVITE references the existing dialog so that the other party knows

   that it is to modify an existing session instead of establishing a

   new session.  The other party sends a 200 (OK) to accept the change.

   The requestor responds to the 200 (OK) with an ACK.  If the other

   party does not accept the change, he sends an error response such as

   488 (Not Acceptable Here), which also receives an ACK.  However, the

   failure of the re-INVITE does not cause the existing call to fail -

   the session continues using the previously negotiated

   characteristics.  Full details on session modification are in Section

   14.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   At the end of the call, Bob disconnects (hangs up) first and

   generates a BYE message.  This BYE is routed directly to Alice's

   softphone, again bypassing the proxies.  Alice confirms receipt of

   the BYE with a 200 (OK) response, which terminates the session and

   the BYE transaction.  No ACK is sent - an ACK is only sent in

   response to a response to an INVITE request.  The reasons for this

   special handling for INVITE will be discussed later, but relate to

   the reliability mechanisms in SIP, the length of time it can take for

   a ringing phone to be answered, and forking.  For this reason,

   request handling in SIP is often classified as either INVITE or non-

   INVITE, referring to all other methods besides INVITE.  Full details

   on session termination are in Section 15.



   Section 24.2 describes the messages shown in Figure 1 in full.



   In some cases, it may be useful for proxies in the SIP signaling path

   to see all the messaging between the endpoints for the duration of

   the session.  For example, if the biloxi.com proxy server wished to

   remain in the SIP messaging path beyond the initial INVITE, it would

   add to the INVITE a required routing header field known as Record-

   Route that contained a URI resolving to the hostname or IP address of

   the proxy.  This information would be received by both Bob's SIP

   phone and (due to the Record-Route header field being passed back in

   the 200 (OK)) Alice's softphone and stored for the duration of the

   dialog.  The biloxi.com proxy server would then receive and proxy the

   ACK, BYE, and 200 (OK) to the BYE.  Each proxy can independently

   decide to receive subsequent messages, and those messages will pass

   through all proxies that elect to receive it.  This capability is

   frequently used for proxies that are providing mid-call features.



   Registration is another common operation in SIP.  Registration is one

   way that the biloxi.com server can learn the current location of Bob.

   Upon initialization, and at periodic intervals, Bob's SIP phone sends

   REGISTER messages to a server in the biloxi.com domain known as a SIP

   registrar.  The REGISTER messages associate Bob's SIP or SIPS URI

   (sip:bob@biloxi.com) with the machine into which he is currently

   logged (conveyed as a SIP or SIPS URI in the Contact header field).

   The registrar writes this association, also called a binding, to a

   database, called the location service, where it can be used by the

   proxy in the biloxi.com domain.  Often, a registrar server for a

   domain is co-located with the proxy for that domain.  It is an

   important concept that the distinction between types of SIP servers

   is logical, not physical.



   Bob is not limited to registering from a single device.  For example,

   both his SIP phone at home and the one in the office could send

   registrations.  This information is stored together in the location









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   service and allows a proxy to perform various types of searches to

   locate Bob.  Similarly, more than one user can be registered on a

   single device at the same time.



   The location service is just an abstract concept.  It generally

   contains information that allows a proxy to input a URI and receive a

   set of zero or more URIs that tell the proxy where to send the

   request.  Registrations are one way to create this information, but

   not the only way.  Arbitrary mapping functions can be configured at

   the discretion of the administrator.



   Finally, it is important to note that in SIP, registration is used

   for routing incoming SIP requests and has no role in authorizing

   outgoing requests.  Authorization and authentication are handled in

   SIP either on a request-by-request basis with a challenge/response

   mechanism, or by using a lower layer scheme as discussed in Section

   26.



   The complete set of SIP message details for this registration example

   is in Section 24.1.



   Additional operations in SIP, such as querying for the capabilities

   of a SIP server or client using OPTIONS, or canceling a pending

   request using CANCEL, will be introduced in later sections.



5 Structure of the Protocol



   SIP is structured as a layered protocol, which means that its

   behavior is described in terms of a set of fairly independent

   processing stages with only a loose coupling between each stage.  The

   protocol behavior is described as layers for the purpose of

   presentation, allowing the description of functions common across

   elements in a single section.  It does not dictate an implementation

   in any way.  When we say that an element "contains" a layer, we mean

   it is compliant to the set of rules defined by that layer.



   Not every element specified by the protocol contains every layer.

   Furthermore, the elements specified by SIP are logical elements, not

   physical ones.  A physical realization can choose to act as different

   logical elements, perhaps even on a transaction-by-transaction basis.



   The lowest layer of SIP is its syntax and encoding.  Its encoding is

   specified using an augmented Backus-Naur Form grammar (BNF).  The

   complete BNF is specified in Section 25; an overview of a SIP

   message's structure can be found in Section 7.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The second layer is the transport layer.  It defines how a client

   sends requests and receives responses and how a server receives

   requests and sends responses over the network.  All SIP elements

   contain a transport layer.  The transport layer is described in

   Section 18.



   The third layer is the transaction layer.  Transactions are a

   fundamental component of SIP.  A transaction is a request sent by a

   client transaction (using the transport layer) to a server

   transaction, along with all responses to that request sent from the

   server transaction back to the client.  The transaction layer handles

   application-layer retransmissions, matching of responses to requests,

   and application-layer timeouts.  Any task that a user agent client

   (UAC) accomplishes takes place using a series of transactions.

   Discussion of transactions can be found in Section 17.  User agents

   contain a transaction layer, as do stateful proxies.  Stateless

   proxies do not contain a transaction layer.  The transaction layer

   has a client component (referred to as a client transaction) and a

   server component (referred to as a server transaction), each of which

   are represented by a finite state machine that is constructed to

   process a particular request.



   The layer above the transaction layer is called the transaction user

   (TU).  Each of the SIP entities, except the stateless proxy, is a

   transaction user.  When a TU wishes to send a request, it creates a

   client transaction instance and passes it the request along with the

   destination IP address, port, and transport to which to send the

   request.  A TU that creates a client transaction can also cancel it.

   When a client cancels a transaction, it requests that the server stop

   further processing, revert to the state that existed before the

   transaction was initiated, and generate a specific error response to

   that transaction.  This is done with a CANCEL request, which

   constitutes its own transaction, but references the transaction to be

   cancelled (Section 9).



   The SIP elements, that is, user agent clients and servers, stateless

   and stateful proxies and registrars, contain a core that

   distinguishes them from each other.  Cores, except for the stateless

   proxy, are transaction users.  While the behavior of the UAC and UAS

   cores depends on the method, there are some common rules for all

   methods (Section 8).  For a UAC, these rules govern the construction

   of a request; for a UAS, they govern the processing of a request and

   generating a response.  Since registrations play an important role in

   SIP, a UAS that handles a REGISTER is given the special name

   registrar.  Section 10 describes UAC and UAS core behavior for the

   REGISTER method.  Section 11 describes UAC and UAS core behavior for

   the OPTIONS method, used for determining the capabilities of a UA.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Certain other requests are sent within a dialog.  A dialog is a

   peer-to-peer SIP relationship between two user agents that persists

   for some time.  The dialog facilitates sequencing of messages and

   proper routing of requests between the user agents.  The INVITE

   method is the only way defined in this specification to establish a

   dialog.  When a UAC sends a request that is within the context of a

   dialog, it follows the common UAC rules as discussed in Section 8 but

   also the rules for mid-dialog requests.  Section 12 discusses dialogs

   and presents the procedures for their construction and maintenance,

   in addition to construction of requests within a dialog.



   The most important method in SIP is the INVITE method, which is used

   to establish a session between participants.  A session is a

   collection of participants, and streams of media between them, for

   the purposes of communication.  Section 13 discusses how sessions are

   initiated, resulting in one or more SIP dialogs.  Section 14

   discusses how characteristics of that session are modified through

   the use of an INVITE request within a dialog.  Finally, section 15

   discusses how a session is terminated.



   The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal

   entirely with the UA core (Section 9 describes cancellation, which

   applies to both UA core and proxy core).  Section 16 discusses the

   proxy element, which facilitates routing of messages between user

   agents.



6 Definitions



   The following terms have special significance for SIP.



      Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI

         that points to a domain with a location service that can map

         the URI to another URI where the user might be available.

         Typically, the location service is populated through

         registrations.  An AOR is frequently thought of as the "public

         address" of the user.



      Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a

         logical entity that receives a request and processes it as a

         user agent server (UAS).  In order to determine how the request

         should be answered, it acts as a user agent client (UAC) and

         generates requests.  Unlike a proxy server, it maintains dialog

         state and must participate in all requests sent on the dialogs

         it has established.  Since it is a concatenation of a UAC and

         UAS, no explicit definitions are needed for its behavior.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      Call: A call is an informal term that refers to some communication

         between peers, generally set up for the purposes of a

         multimedia conversation.



      Call Leg: Another name for a dialog [31]; no longer used in this

         specification.



      Call Stateful: A proxy is call stateful if it retains state for a

         dialog from the initiating INVITE to the terminating BYE

         request.  A call stateful proxy is always transaction stateful,

         but the converse is not necessarily true.



      Client: A client is any network element that sends SIP requests

         and receives SIP responses.  Clients may or may not interact

         directly with a human user.  User agent clients and proxies are

         clients.



      Conference: A multimedia session (see below) that contains

         multiple participants.



      Core: Core designates the functions specific to a particular type

         of SIP entity, i.e., specific to either a stateful or stateless

         proxy, a user agent or registrar.  All cores, except those for

         the stateless proxy, are transaction users.



      Dialog: A dialog is a peer-to-peer SIP relationship between two

         UAs that persists for some time.  A dialog is established by

         SIP messages, such as a 2xx response to an INVITE request.  A

         dialog is identified by a call identifier, local tag, and a

         remote tag.  A dialog was formerly known as a call leg in RFC

         2543.



      Downstream: A direction of message forwarding within a transaction

         that refers to the direction that requests flow from the user

         agent client to user agent server.



      Final Response: A response that terminates a SIP transaction, as

         opposed to a provisional response that does not.  All 2xx, 3xx,

         4xx, 5xx and 6xx responses are final.



      Header: A header is a component of a SIP message that conveys

         information about the message.  It is structured as a sequence

         of header fields.



      Header Field: A header field is a component of the SIP message

         header.  A header field can appear as one or more header field

         rows. Header field rows consist of a header field name and zero

         or more header field values. Multiple header field values on a







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         given header field row are separated by commas. Some header

         fields can only have a single header field value, and as a

         result, always appear as a single header field row.



      Header Field Value: A header field value is a single value; a

         header field consists of zero or more header field values.



      Home Domain: The domain providing service to a SIP user.

         Typically, this is the domain present in the URI in the

         address-of-record of a registration.



      Informational Response: Same as a provisional response.



      Initiator, Calling Party, Caller: The party initiating a session

         (and dialog) with an INVITE request.  A caller retains this

         role from the time it sends the initial INVITE that established

         a dialog until the termination of that dialog.



      Invitation: An INVITE request.



      Invitee, Invited User, Called Party, Callee: The party that

         receives an INVITE request for the purpose of establishing a

         new session.  A callee retains this role from the time it

         receives the INVITE until the termination of the dialog

         established by that INVITE.



      Location Service: A location service is used by a SIP redirect or

         proxy server to obtain information about a callee's possible

         location(s).  It contains a list of bindings of address-of-

         record keys to zero or more contact addresses.  The bindings

         can be created and removed in many ways; this specification

         defines a REGISTER method that updates the bindings.



      Loop: A request that arrives at a proxy, is forwarded, and later

         arrives back at the same proxy.  When it arrives the second

         time, its Request-URI is identical to the first time, and other

         header fields that affect proxy operation are unchanged, so

         that the proxy would make the same processing decision on the

         request it made the first time.  Looped requests are errors,

         and the procedures for detecting them and handling them are

         described by the protocol.



      Loose Routing: A proxy is said to be loose routing if it follows

         the procedures defined in this specification for processing of

         the Route header field.  These procedures separate the

         destination of the request (present in the Request-URI) from











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         the set of proxies that need to be visited along the way

         (present in the Route header field).  A proxy compliant to

         these mechanisms is also known as a loose router.



      Message: Data sent between SIP elements as part of the protocol.

         SIP messages are either requests or responses.



      Method: The method is the primary function that a request is meant

         to invoke on a server.  The method is carried in the request

         message itself.  Example methods are INVITE and BYE.



      Outbound Proxy: A proxy that receives requests from a client, even

         though it may not be the server resolved by the Request-URI.

         Typically, a UA is manually configured with an outbound proxy,

         or can learn about one through auto-configuration protocols.



      Parallel Search: In a parallel search, a proxy issues several

         requests to possible user locations upon receiving an incoming

         request.  Rather than issuing one request and then waiting for

         the final response before issuing the next request as in a

         sequential search, a parallel search issues requests without

         waiting for the result of previous requests.



      Provisional Response: A response used by the server to indicate

         progress, but that does not terminate a SIP transaction.  1xx

         responses are provisional, other responses are considered

         final.



      Proxy, Proxy Server: An intermediary entity that acts as both a

         server and a client for the purpose of making requests on

         behalf of other clients.  A proxy server primarily plays the

         role of routing, which means its job is to ensure that a

         request is sent to another entity "closer" to the targeted

         user.  Proxies are also useful for enforcing policy (for

         example, making sure a user is allowed to make a call).  A

         proxy interprets, and, if necessary, rewrites specific parts of

         a request message before forwarding it.



      Recursion: A client recurses on a 3xx response when it generates a

         new request to one or more of the URIs in the Contact header

         field in the response.



      Redirect Server: A redirect server is a user agent server that

         generates 3xx responses to requests it receives, directing the

         client to contact an alternate set of URIs.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      Registrar: A registrar is a server that accepts REGISTER requests

         and places the information it receives in those requests into

         the location service for the domain it handles.



      Regular Transaction: A regular transaction is any transaction with

         a method other than INVITE, ACK, or CANCEL.



      Request: A SIP message sent from a client to a server, for the

         purpose of invoking a particular operation.



      Response: A SIP message sent from a server to a client, for

         indicating the status of a request sent from the client to the

         server.



      Ringback: Ringback is the signaling tone produced by the calling

         party's application indicating that a called party is being

         alerted (ringing).



      Route Set: A route set is a collection of ordered SIP or SIPS URI

         which represent a list of proxies that must be traversed when

         sending a particular request.  A route set can be learned,

         through headers like Record-Route, or it can be configured.



      Server: A server is a network element that receives requests in

         order to service them and sends back responses to those

         requests.  Examples of servers are proxies, user agent servers,

         redirect servers, and registrars.



      Sequential Search: In a sequential search, a proxy server attempts

         each contact address in sequence, proceeding to the next one

         only after the previous has generated a final response.  A 2xx

         or 6xx class final response always terminates a sequential

         search.



      Session: From the SDP specification: "A multimedia session is a

         set of multimedia senders and receivers and the data streams

         flowing from senders to receivers.  A multimedia conference is

         an example of a multimedia session." (RFC 2327 [1]) (A session

         as defined for SDP can comprise one or more RTP sessions.)  As

         defined, a callee can be invited several times, by different

         calls, to the same session.  If SDP is used, a session is

         defined by the concatenation of the SDP user name, session id,

         network type, address type, and address elements in the origin

         field.



      SIP Transaction: A SIP transaction occurs between a client and a

         server and comprises all messages from the first request sent

         from the client to the server up to a final (non-1xx) response







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         sent from the server to the client.  If the request is INVITE

         and the final response is a non-2xx, the transaction also

         includes an ACK to the response.  The ACK for a 2xx response to

         an INVITE request is a separate transaction.



      Spiral: A spiral is a SIP request that is routed to a proxy,

         forwarded onwards, and arrives once again at that proxy, but

         this time differs in a way that will result in a different

         processing decision than the original request.  Typically, this

         means that the request's Request-URI differs from its previous

         arrival.  A spiral is not an error condition, unlike a loop.  A

         typical cause for this is call forwarding.  A user calls

         joe@example.com.  The example.com proxy forwards it to Joe's

         PC, which in turn, forwards it to bob@example.com.  This

         request is proxied back to the example.com proxy.  However,

         this is not a loop.  Since the request is targeted at a

         different user, it is considered a spiral, and is a valid

         condition.



      Stateful Proxy: A logical entity that maintains the client and

         server transaction state machines defined by this specification

         during the processing of a request, also known as a transaction

         stateful proxy.  The behavior of a stateful proxy is further

         defined in Section 16.  A (transaction) stateful proxy is not

         the same as a call stateful proxy.



      Stateless Proxy: A logical entity that does not maintain the

         client or server transaction state machines defined in this

         specification when it processes requests.  A stateless proxy

         forwards every request it receives downstream and every

         response it receives upstream.



      Strict Routing: A proxy is said to be strict routing if it follows

         the Route processing rules of RFC 2543 and many prior work in

         progress versions of this RFC.  That rule caused proxies to

         destroy the contents of the Request-URI when a Route header

         field was present.  Strict routing behavior is not used in this

         specification, in favor of a loose routing behavior.  Proxies

         that perform strict routing are also known as strict routers.



      Target Refresh Request: A target refresh request sent within a

         dialog is defined as a request that can modify the remote

         target of the dialog.



      Transaction User (TU): The layer of protocol processing that

         resides above the transaction layer.  Transaction users include

         the UAC core, UAS core, and proxy core.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      Upstream: A direction of message forwarding within a transaction

         that refers to the direction that responses flow from the user

         agent server back to the user agent client.



      URL-encoded: A character string encoded according to RFC 2396,

         Section 2.4 [5].



      User Agent Client (UAC): A user agent client is a logical entity

         that creates a new request, and then uses the client

         transaction state machinery to send it.  The role of UAC lasts

         only for the duration of that transaction.  In other words, if

         a piece of software initiates a request, it acts as a UAC for

         the duration of that transaction.  If it receives a request

         later, it assumes the role of a user agent server for the

         processing of that transaction.



      UAC Core: The set of processing functions required of a UAC that

         reside above the transaction and transport layers.



      User Agent Server (UAS): A user agent server is a logical entity

         that generates a response to a SIP request.  The response

         accepts, rejects, or redirects the request.  This role lasts

         only for the duration of that transaction.  In other words, if

         a piece of software responds to a request, it acts as a UAS for

         the duration of that transaction.  If it generates a request

         later, it assumes the role of a user agent client for the

         processing of that transaction.



      UAS Core: The set of processing functions required at a UAS that

         resides above the transaction and transport layers.



      User Agent (UA): A logical entity that can act as both a user

         agent client and user agent server.



   The role of UAC and UAS, as well as proxy and redirect servers, are

   defined on a transaction-by-transaction basis.  For example, the user

   agent initiating a call acts as a UAC when sending the initial INVITE

   request and as a UAS when receiving a BYE request from the callee.

   Similarly, the same software can act as a proxy server for one

   request and as a redirect server for the next request.



   Proxy, location, and registrar servers defined above are logical

   entities; implementations MAY combine them into a single application.



7 SIP Messages



   SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279

   [7]).







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   A SIP message is either a request from a client to a server, or a

   response from a server to a client.



   Both Request (section 7.1) and Response (section 7.2) messages use

   the basic format of RFC 2822 [3], even though the syntax differs in

   character set and syntax specifics.  (SIP allows header fields that

   would not be valid RFC 2822 header fields, for example.)  Both types

   of messages consist of a start-line, one or more header fields, an

   empty line indicating the end of the header fields, and an optional

   message-body.



         generic-message  =  start-line

                             *message-header

                             CRLF

                             [ message-body ]

         start-line       =  Request-Line / Status-Line



   The start-line, each message-header line, and the empty line MUST be

   terminated by a carriage-return line-feed sequence (CRLF).  Note that

   the empty line MUST be present even if the message-body is not.



   Except for the above difference in character sets, much of SIP's

   message and header field syntax is identical to HTTP/1.1.  Rather

   than repeating the syntax and semantics here, we use [HX.Y] to refer

   to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]).



   However, SIP is not an extension of HTTP.



7.1 Requests



   SIP requests are distinguished by having a Request-Line for a start-

   line.  A Request-Line contains a method name, a Request-URI, and the

   protocol version separated by a single space (SP) character.



   The Request-Line ends with CRLF.  No CR or LF are allowed except in

   the end-of-line CRLF sequence.  No linear whitespace (LWS) is allowed

   in any of the elements.



         Request-Line  =  Method SP Request-URI SP SIP-Version CRLF



      Method: This specification defines six methods: REGISTER for

           registering contact information, INVITE, ACK, and CANCEL for

           setting up sessions, BYE for terminating sessions, and

           OPTIONS for querying servers about their capabilities.  SIP

           extensions, documented in standards track RFCs, may define

           additional methods.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      Request-URI: The Request-URI is a SIP or SIPS URI as described in

           Section 19.1 or a general URI (RFC 2396 [5]).  It indicates

           the user or service to which this request is being addressed.

           The Request-URI MUST NOT contain unescaped spaces or control

           characters and MUST NOT be enclosed in "<>".



           SIP elements MAY support Request-URIs with schemes other than

           "sip" and "sips", for example the "tel" URI scheme of RFC

           2806 [9].  SIP elements MAY translate non-SIP URIs using any

           mechanism at their disposal, resulting in SIP URI, SIPS URI,

           or some other scheme.



      SIP-Version: Both request and response messages include the

           version of SIP in use, and follow [H3.1] (with HTTP replaced

           by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version

           ordering, compliance requirements, and upgrading of version

           numbers.  To be compliant with this specification,

           applications sending SIP messages MUST include a SIP-Version

           of "SIP/2.0".  The SIP-Version string is case-insensitive,

           but implementations MUST send upper-case.



           Unlike HTTP/1.1, SIP treats the version number as a literal

           string.  In practice, this should make no difference.



7.2 Responses



   SIP responses are distinguished from requests by having a Status-Line

   as their start-line.  A Status-Line consists of the protocol version

   followed by a numeric Status-Code and its associated textual phrase,

   with each element separated by a single SP character.



   No CR or LF is allowed except in the final CRLF sequence.



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



   The Status-Code is a 3-digit integer result code that indicates the

   outcome of an attempt to understand and satisfy a request.  The

   Reason-Phrase is intended to give a short textual description of the

   Status-Code.  The Status-Code is intended for use by automata,

   whereas the Reason-Phrase is intended for the human user.  A client

   is not required to examine or display the Reason-Phrase.



   While this specification suggests specific wording for the reason

   phrase, implementations MAY choose other text, for example, in the

   language indicated in the Accept-Language header field of the

   request.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The first digit of the Status-Code defines the class of response.

   The last two digits do not have any categorization role.  For this

   reason, any response with a status code between 100 and 199 is

   referred to as a "1xx response", any response with a status code

   between 200 and 299 as a "2xx response", and so on.  SIP/2.0 allows

   six values for the first digit:



      1xx: Provisional -- request received, continuing to process the

           request;



      2xx: Success -- the action was successfully received, understood,

           and accepted;



      3xx: Redirection -- further action needs to be taken in order to

           complete the request;



      4xx: Client Error -- the request contains bad syntax or cannot be

           fulfilled at this server;



      5xx: Server Error -- the server failed to fulfill an apparently

           valid request;



      6xx: Global Failure -- the request cannot be fulfilled at any

           server.



   Section 21 defines these classes and describes the individual codes.



7.3 Header Fields



   SIP header fields are similar to HTTP header fields in both syntax

   and semantics.  In particular, SIP header fields follow the [H4.2]

   definitions of syntax for the message-header and the rules for

   extending header fields over multiple lines.  However, the latter is

   specified in HTTP with implicit whitespace and folding.  This

   specification conforms to RFC 2234 [10] and uses only explicit

   whitespace and folding as an integral part of the grammar.



   [H4.2] also specifies that multiple header fields of the same field

   name whose value is a comma-separated list can be combined into one

   header field.  That applies to SIP as well, but the specific rule is

   different because of the different grammars.  Specifically, any SIP

   header whose grammar is of the form



      header  =  "header-name" HCOLON header-value *(COMMA header-value)



   allows for combining header fields of the same name into a comma-

   separated list.  The Contact header field allows a comma-separated

   list unless the header field value is "*".







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





7.3.1 Header Field Format



   Header fields follow the same generic header format as that given in

   Section 2.2 of RFC 2822 [3].  Each header field consists of a field

   name followed by a colon (":") and the field value.



      field-name: field-value



   The formal grammar for a message-header specified in Section 25

   allows for an arbitrary amount of whitespace on either side of the

   colon; however, implementations should avoid spaces between the field

   name and the colon and use a single space (SP) between the colon and

   the field-value.



      Subject:            lunch

      Subject      :      lunch

      Subject            :lunch

      Subject: lunch



   Thus, the above are all valid and equivalent, but the last is the

   preferred form.



   Header fields can be extended over multiple lines by preceding each

   extra line with at least one SP or horizontal tab (HT).  The line

   break and the whitespace at the beginning of the next line are

   treated as a single SP character.  Thus, the following are

   equivalent:



      Subject: I know you're there, pick up the phone and talk to me!

      Subject: I know you're there,

               pick up the phone

               and talk to me!



   The relative order of header fields with different field names is not

   significant.  However, it is RECOMMENDED that header fields which are

   needed for proxy processing (Via, Route, Record-Route, Proxy-Require,

   Max-Forwards, and Proxy-Authorization, for example) appear towards

   the top of the message to facilitate rapid parsing.  The relative

   order of header field rows with the same field name is important.

   Multiple header field rows with the same field-name MAY be present in

   a message if and only if the entire field-value for that header field

   is defined as a comma-separated list (that is, if follows the grammar

   defined in Section 7.3).  It MUST be possible to combine the multiple

   header field rows into one "field-name: field-value" pair, without

   changing the semantics of the message, by appending each subsequent

   field-value to the first, each separated by a comma.  The exceptions

   to this rule are the WWW-Authenticate, Authorization, Proxy-

   Authenticate, and Proxy-Authorization header fields.  Multiple header







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   field rows with these names MAY be present in a message, but since

   their grammar does not follow the general form listed in Section 7.3,

   they MUST NOT be combined into a single header field row.



   Implementations MUST be able to process multiple header field rows

   with the same name in any combination of the single-value-per-line or

   comma-separated value forms.



   The following groups of header field rows are valid and equivalent:



      Route: <sip:alice@atlanta.com>

      Subject: Lunch

      Route: <sip:bob@biloxi.com>

      Route: <sip:carol@chicago.com>



      Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>

      Route: <sip:carol@chicago.com>

      Subject: Lunch



      Subject: Lunch

      Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>,

             <sip:carol@chicago.com>



   Each of the following blocks is valid but not equivalent to the

   others:



      Route: <sip:alice@atlanta.com>

      Route: <sip:bob@biloxi.com>

      Route: <sip:carol@chicago.com>



      Route: <sip:bob@biloxi.com>

      Route: <sip:alice@atlanta.com>

      Route: <sip:carol@chicago.com>



      Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>,

             <sip:bob@biloxi.com>



   The format of a header field-value is defined per header-name.  It

   will always be either an opaque sequence of TEXT-UTF8 octets, or a

   combination of whitespace, tokens, separators, and quoted strings.

   Many existing header fields will adhere to the general form of a

   value followed by a semi-colon separated sequence of parameter-name,

   parameter-value pairs:



         field-name: field-value *(;parameter-name=parameter-value)













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Even though an arbitrary number of parameter pairs may be attached to

   a header field value, any given parameter-name MUST NOT appear more

   than once.



   When comparing header fields, field names are always case-

   insensitive.  Unless otherwise stated in the definition of a

   particular header field, field values, parameter names, and parameter

   values are case-insensitive.  Tokens are always case-insensitive.

   Unless specified otherwise, values expressed as quoted strings are

   case-sensitive.  For example,



      Contact: <sip:alice@atlanta.com>;expires=3600



   is equivalent to



      CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600



   and



      Content-Disposition: session;handling=optional



   is equivalent to



      content-disposition: Session;HANDLING=OPTIONAL



   The following two header fields are not equivalent:



      Warning: 370 devnull "Choose a bigger pipe"

      Warning: 370 devnull "CHOOSE A BIGGER PIPE"



7.3.2 Header Field Classification



   Some header fields only make sense in requests or responses.  These

   are called request header fields and response header fields,

   respectively.  If a header field appears in a message not matching

   its category (such as a request header field in a response), it MUST

   be ignored.  Section 20 defines the classification of each header

   field.



7.3.3 Compact Form



   SIP provides a mechanism to represent common header field names in an

   abbreviated form.  This may be useful when messages would otherwise

   become too large to be carried on the transport available to it

   (exceeding the maximum transmission unit (MTU) when using UDP, for

   example).  These compact forms are defined in Section 20.  A compact

   form MAY be substituted for the longer form of a header field name at

   any time without changing the semantics of the message.  A header







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   field name MAY appear in both long and short forms within the same

   message.  Implementations MUST accept both the long and short forms

   of each header name.



7.4 Bodies



   Requests, including new requests defined in extensions to this

   specification, MAY contain message bodies unless otherwise noted.

   The interpretation of the body depends on the request method.



   For response messages, the request method and the response status

   code determine the type and interpretation of any message body.  All

   responses MAY include a body.



7.4.1 Message Body Type



   The Internet media type of the message body MUST be given by the

   Content-Type header field.  If the body has undergone any encoding

   such as compression, then this MUST be indicated by the Content-

   Encoding header field; otherwise, Content-Encoding MUST be omitted.

   If applicable, the character set of the message body is indicated as

   part of the Content-Type header-field value.



   The "multipart" MIME type defined in RFC 2046 [11] MAY be used within

   the body of the message.  Implementations that send requests

   containing multipart message bodies MUST send a session description

   as a non-multipart message body if the remote implementation requests

   this through an Accept header field that does not contain multipart.



   SIP messages MAY contain binary bodies or body parts. When no

   explicit charset parameter is provided by the sender, media subtypes

   of the "text" type are defined to have a default charset value of

   "UTF-8".



7.4.2 Message Body Length



   The body length in bytes is provided by the Content-Length header

   field.  Section 20.14 describes the necessary contents of this header

   field in detail.



   The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP.

   (Note: The chunked encoding modifies the body of a message in order

   to transfer it as a series of chunks, each with its own size

   indicator.)















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





7.5 Framing SIP Messages



   Unlike HTTP, SIP implementations can use UDP or other unreliable

   datagram protocols.  Each such datagram carries one request or

   response.  See Section 18 on constraints on usage of unreliable

   transports.



   Implementations processing SIP messages over stream-oriented

   transports MUST ignore any CRLF appearing before the start-line

   [H4.1].



      The Content-Length header field value is used to locate the end of

      each SIP message in a stream.  It will always be present when SIP

      messages are sent over stream-oriented transports.



8 General User Agent Behavior



   A user agent represents an end system.  It contains a user agent

   client (UAC), which generates requests, and a user agent server

   (UAS), which responds to them.  A UAC is capable of generating a

   request based on some external stimulus (the user clicking a button,

   or a signal on a PSTN line) and processing a response.  A UAS is

   capable of receiving a request and generating a response based on

   user input, external stimulus, the result of a program execution, or

   some other mechanism.



   When a UAC sends a request, the request passes through some number of

   proxy servers, which forward the request towards the UAS. When the

   UAS generates a response, the response is forwarded towards the UAC.



   UAC and UAS procedures depend strongly on two factors.  First, based

   on whether the request or response is inside or outside of a dialog,

   and second, based on the method of a request.  Dialogs are discussed

   thoroughly in Section 12; they represent a peer-to-peer relationship

   between user agents and are established by specific SIP methods, such

   as INVITE.



   In this section, we discuss the method-independent rules for UAC and

   UAS behavior when processing requests that are outside of a dialog.

   This includes, of course, the requests which themselves establish a

   dialog.



   Security procedures for requests and responses outside of a dialog

   are described in Section 26.  Specifically, mechanisms exist for the

   UAS and UAC to mutually authenticate.  A limited set of privacy

   features are also supported through encryption of bodies using

   S/MIME.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





8.1 UAC Behavior



   This section covers UAC behavior outside of a dialog.



8.1.1 Generating the Request



   A valid SIP request formulated by a UAC MUST, at a minimum, contain

   the following header fields: To, From, CSeq, Call-ID, Max-Forwards,

   and Via; all of these header fields are mandatory in all SIP

   requests.  These six header fields are the fundamental building

   blocks of a SIP message, as they jointly provide for most of the

   critical message routing services including the addressing of

   messages, the routing of responses, limiting message propagation,

   ordering of messages, and the unique identification of transactions.

   These header fields are in addition to the mandatory request line,

   which contains the method, Request-URI, and SIP version.



   Examples of requests sent outside of a dialog include an INVITE to

   establish a session (Section 13) and an OPTIONS to query for

   capabilities (Section 11).



8.1.1.1 Request-URI



   The initial Request-URI of the message SHOULD be set to the value of

   the URI in the To field.  One notable exception is the REGISTER

   method; behavior for setting the Request-URI of REGISTER is given in

   Section 10.  It may also be undesirable for privacy reasons or

   convenience to set these fields to the same value (especially if the

   originating UA expects that the Request-URI will be changed during

   transit).



   In some special circumstances, the presence of a pre-existing route

   set can affect the Request-URI of the message.  A pre-existing route

   set is an ordered set of URIs that identify a chain of servers, to

   which a UAC will send outgoing requests that are outside of a dialog.

   Commonly, they are configured on the UA by a user or service provider

   manually, or through some other non-SIP mechanism.  When a provider

   wishes to configure a UA with an outbound proxy, it is RECOMMENDED

   that this be done by providing it with a pre-existing route set with

   a single URI, that of the outbound proxy.



   When a pre-existing route set is present, the procedures for

   populating the Request-URI and Route header field detailed in Section

   12.2.1.1 MUST be followed (even though there is no dialog), using the

   desired Request-URI as the remote target URI.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





8.1.1.2 To



   The To header field first and foremost specifies the desired

   "logical" recipient of the request, or the address-of-record of the

   user or resource that is the target of this request.  This may or may

   not be the ultimate recipient of the request.  The To header field

   MAY contain a SIP or SIPS URI, but it may also make use of other URI

   schemes (the tel URL (RFC 2806 [9]), for example) when appropriate.

   All SIP implementations MUST support the SIP URI scheme.  Any

   implementation that supports TLS MUST support the SIPS URI scheme.

   The To header field allows for a display name.



   A UAC may learn how to populate the To header field for a particular

   request in a number of ways.  Usually the user will suggest the To

   header field through a human interface, perhaps inputting the URI

   manually or selecting it from some sort of address book.  Frequently,

   the user will not enter a complete URI, but rather a string of digits

   or letters (for example, "bob").  It is at the discretion of the UA

   to choose how to interpret this input.  Using the string to form the

   user part of a SIP URI implies that the UA wishes the name to be

   resolved in the domain to the right-hand side (RHS) of the at-sign in

   the SIP URI (for instance, sip:bob@example.com).  Using the string to

   form the user part of a SIPS URI implies that the UA wishes to

   communicate securely, and that the name is to be resolved in the

   domain to the RHS of the at-sign.  The RHS will frequently be the

   home domain of the requestor, which allows for the home domain to

   process the outgoing request.  This is useful for features like

   "speed dial" that require interpretation of the user part in the home

   domain.  The tel URL may be used when the UA does not wish to specify

   the domain that should interpret a telephone number that has been

   input by the user.  Rather, each domain through which the request

   passes would be given that opportunity.  As an example, a user in an

   airport might log in and send requests through an outbound proxy in

   the airport.  If they enter "411" (this is the phone number for local

   directory assistance in the United States), that needs to be

   interpreted and processed by the outbound proxy in the airport, not

   the user's home domain.  In this case, tel:411 would be the right

   choice.



   A request outside of a dialog MUST NOT contain a To tag; the tag in

   the To field of a request identifies the peer of the dialog.  Since

   no dialog is established, no tag is present.



   For further information on the To header field, see Section 20.39.

   The following is an example of a valid To header field:



      To: Carol <sip:carol@chicago.com>









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





8.1.1.3 From



   The From header field indicates the logical identity of the initiator

   of the request, possibly the user's address-of-record.  Like the To

   header field, it contains a URI and optionally a display name.  It is

   used by SIP elements to determine which processing rules to apply to

   a request (for example, automatic call rejection).  As such, it is

   very important that the From URI not contain IP addresses or the FQDN

   of the host on which the UA is running, since these are not logical

   names.



   The From header field allows for a display name.  A UAC SHOULD use

   the display name "Anonymous", along with a syntactically correct, but

   otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the

   identity of the client is to remain hidden.



   Usually, the value that populates the From header field in requests

   generated by a particular UA is pre-provisioned by the user or by the

   administrators of the user's local domain.  If a particular UA is

   used by multiple users, it might have switchable profiles that

   include a URI corresponding to the identity of the profiled user.

   Recipients of requests can authenticate the originator of a request

   in order to ascertain that they are who their From header field

   claims they are (see Section 22 for more on authentication).



   The From field MUST contain a new "tag" parameter, chosen by the UAC.

   See Section 19.3 for details on choosing a tag.



   For further information on the From header field, see Section 20.20.

   Examples:



      From: "Bob" <sips:bob@biloxi.com> ;tag=a48s

      From: sip:+12125551212@phone2net.com;tag=887s

      From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8



8.1.1.4 Call-ID



   The Call-ID header field acts as a unique identifier to group

   together a series of messages.  It MUST be the same for all requests

   and responses sent by either UA in a dialog.  It SHOULD be the same

   in each registration from a UA.



   In a new request created by a UAC outside of any dialog, the Call-ID

   header field MUST be selected by the UAC as a globally unique

   identifier over space and time unless overridden by method-specific

   behavior.  All SIP UAs must have a means to guarantee that the Call-

   ID header fields they produce will not be inadvertently generated by

   any other UA.  Note that when requests are retried after certain







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   failure responses that solicit an amendment to a request (for

   example, a challenge for authentication), these retried requests are

   not considered new requests, and therefore do not need new Call-ID

   header fields; see Section 8.1.3.5.



   Use of cryptographically random identifiers (RFC 1750 [12]) in the

   generation of Call-IDs is RECOMMENDED.  Implementations MAY use the

   form "localid@host".  Call-IDs are case-sensitive and are simply

   compared byte-by-byte.



      Using cryptographically random identifiers provides some

      protection against session hijacking and reduces the likelihood of

      unintentional Call-ID collisions.



   No provisioning or human interface is required for the selection of

   the Call-ID header field value for a request.



   For further information on the Call-ID header field, see Section

   20.8.



   Example:



      Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com



8.1.1.5 CSeq



   The CSeq header field serves as a way to identify and order

   transactions.  It consists of a sequence number and a method.  The

   method MUST match that of the request.  For non-REGISTER requests

   outside of a dialog, the sequence number value is arbitrary.  The

   sequence number value MUST be expressible as a 32-bit unsigned

   integer and MUST be less than 2**31.  As long as it follows the above

   guidelines, a client may use any mechanism it would like to select

   CSeq header field values.



   Section 12.2.1.1 discusses construction of the CSeq for requests

   within a dialog.



   Example:



      CSeq: 4711 INVITE





















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





8.1.1.6 Max-Forwards



   The Max-Forwards header field serves to limit the number of hops a

   request can transit on the way to its destination.  It consists of an

   integer that is decremented by one at each hop.  If the Max-Forwards

   value reaches 0 before the request reaches its destination, it will

   be rejected with a 483(Too Many Hops) error response.



   A UAC MUST insert a Max-Forwards header field into each request it

   originates with a value that SHOULD be 70.  This number was chosen to

   be sufficiently large to guarantee that a request would not be

   dropped in any SIP network when there were no loops, but not so large

   as to consume proxy resources when a loop does occur.  Lower values

   should be used with caution and only in networks where topologies are

   known by the UA.



8.1.1.7 Via



   The Via header field indicates the transport used for the transaction

   and identifies the location where the response is to be sent.  A Via

   header field value is added only after the transport that will be

   used to reach the next hop has been selected (which may involve the

   usage of the procedures in [4]).



   When the UAC creates a request, it MUST insert a Via into that

   request.  The protocol name and protocol version in the header field

   MUST be SIP and 2.0, respectively.  The Via header field value MUST

   contain a branch parameter.  This parameter is used to identify the

   transaction created by that request.  This parameter is used by both

   the client and the server.



   The branch parameter value MUST be unique across space and time for

   all requests sent by the UA.  The exceptions to this rule are CANCEL

   and ACK for non-2xx responses.  As discussed below, a CANCEL request

   will have the same value of the branch parameter as the request it

   cancels.  As discussed in Section 17.1.1.3, an ACK for a non-2xx

   response will also have the same branch ID as the INVITE whose

   response it acknowledges.



      The uniqueness property of the branch ID parameter, to facilitate

      its use as a transaction ID, was not part of RFC 2543.



   The branch ID inserted by an element compliant with this

   specification MUST always begin with the characters "z9hG4bK".  These

   7 characters are used as a magic cookie (7 is deemed sufficient to

   ensure that an older RFC 2543 implementation would not pick such a

   value), so that servers receiving the request can determine that the

   branch ID was constructed in the fashion described by this







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   specification (that is, globally unique).  Beyond this requirement,

   the precise format of the branch token is implementation-defined.



   The Via header maddr, ttl, and sent-by components will be set when

   the request is processed by the transport layer (Section 18).



   Via processing for proxies is described in Section 16.6 Item 8 and

   Section 16.7 Item 3.



8.1.1.8 Contact



   The Contact header field provides a SIP or SIPS URI that can be used

   to contact that specific instance of the UA for subsequent requests.

   The Contact header field MUST be present and contain exactly one SIP

   or SIPS URI in any request that can result in the establishment of a

   dialog.  For the methods defined in this specification, that includes

   only the INVITE request.  For these requests, the scope of the

   Contact is global.  That is, the Contact header field value contains

   the URI at which the UA would like to receive requests, and this URI

   MUST be valid even if used in subsequent requests outside of any

   dialogs.



   If the Request-URI or top Route header field value contains a SIPS

   URI, the Contact header field MUST contain a SIPS URI as well.



   For further information on the Contact header field, see Section

   20.10.



8.1.1.9 Supported and Require



   If the UAC supports extensions to SIP that can be applied by the

   server to the response, the UAC SHOULD include a Supported header

   field in the request listing the option tags (Section 19.2) for those

   extensions.



   The option tags listed MUST only refer to extensions defined in

   standards-track RFCs.  This is to prevent servers from insisting that

   clients implement non-standard, vendor-defined features in order to

   receive service.  Extensions defined by experimental and

   informational RFCs are explicitly excluded from usage with the

   Supported header field in a request, since they too are often used to

   document vendor-defined extensions.



   If the UAC wishes to insist that a UAS understand an extension that

   the UAC will apply to the request in order to process the request, it

   MUST insert a Require header field into the request listing the

   option tag for that extension.  If the UAC wishes to apply an

   extension to the request and insist that any proxies that are







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   traversed understand that extension, it MUST insert a Proxy-Require

   header field into the request listing the option tag for that

   extension.



   As with the Supported header field, the option tags in the Require

   and Proxy-Require header fields MUST only refer to extensions defined

   in standards-track RFCs.



8.1.1.10 Additional Message Components



   After a new request has been created, and the header fields described

   above have been properly constructed, any additional optional header

   fields are added, as are any header fields specific to the method.



   SIP requests MAY contain a MIME-encoded message-body.  Regardless of

   the type of body that a request contains, certain header fields must

   be formulated to characterize the contents of the body.  For further

   information on these header fields, see Sections 20.11 through 20.15.



8.1.2 Sending the Request



   The destination for the request is then computed.  Unless there is

   local policy specifying otherwise, the destination MUST be determined

   by applying the DNS procedures described in [4] as follows.  If the

   first element in the route set indicated a strict router (resulting

   in forming the request as described in Section 12.2.1.1), the

   procedures MUST be applied to the Request-URI of the request.

   Otherwise, the procedures are applied to the first Route header field

   value in the request (if one exists), or to the request's Request-URI

   if there is no Route header field present.  These procedures yield an

   ordered set of address, port, and transports to attempt.  Independent

   of which URI is used as input to the procedures of [4], if the

   Request-URI specifies a SIPS resource, the UAC MUST follow the

   procedures of [4] as if the input URI were a SIPS URI.



   Local policy MAY specify an alternate set of destinations to attempt.

   If the Request-URI contains a SIPS URI, any alternate destinations

   MUST be contacted with TLS.  Beyond that, there are no restrictions

   on the alternate destinations if the request contains no Route header

   field.  This provides a simple alternative to a pre-existing route

   set as a way to specify an outbound proxy.  However, that approach

   for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing

   route set with a single URI SHOULD be used instead.  If the request

   contains a Route header field, the request SHOULD be sent to the

   locations derived from its topmost value, but MAY be sent to any

   server that the UA is certain will honor the Route and Request-URI

   policies specified in this document (as opposed to those in RFC

   2543).  In particular, a UAC configured with an outbound proxy SHOULD







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   attempt to send the request to the location indicated in the first

   Route header field value instead of adopting the policy of sending

   all messages to the outbound proxy.



      This ensures that outbound proxies that do not add Record-Route

      header field values will drop out of the path of subsequent

      requests.  It allows endpoints that cannot resolve the first Route

      URI to delegate that task to an outbound proxy.



   The UAC SHOULD follow the procedures defined in [4] for stateful

   elements, trying each address until a server is contacted.  Each try

   constitutes a new transaction, and therefore each carries a different

   topmost Via header field value with a new branch parameter.

   Furthermore, the transport value in the Via header field is set to

   whatever transport was determined for the target server.



8.1.3 Processing Responses



   Responses are first processed by the transport layer and then passed

   up to the transaction layer.  The transaction layer performs its

   processing and then passes the response up to the TU.  The majority

   of response processing in the TU is method specific.  However, there

   are some general behaviors independent of the method.



8.1.3.1 Transaction Layer Errors



   In some cases, the response returned by the transaction layer will

   not be a SIP message, but rather a transaction layer error.  When a

   timeout error is received from the transaction layer, it MUST be

   treated as if a 408 (Request Timeout) status code has been received.

   If a fatal transport error is reported by the transport layer

   (generally, due to fatal ICMP errors in UDP or connection failures in

   TCP), the condition MUST be treated as a 503 (Service Unavailable)

   status code.



8.1.3.2 Unrecognized Responses



   A UAC MUST treat any final response it does not recognize as being

   equivalent to the x00 response code of that class, and MUST be able

   to process the x00 response code for all classes.  For example, if a

   UAC receives an unrecognized response code of 431, it can safely

   assume that there was something wrong with its request and treat the

   response as if it had received a 400 (Bad Request) response code.  A

   UAC MUST treat any provisional response different than 100 that it

   does not recognize as 183 (Session Progress).  A UAC MUST be able to

   process 100 and 183 responses.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





8.1.3.3 Vias



   If more than one Via header field value is present in a response, the

   UAC SHOULD discard the message.



      The presence of additional Via header field values that precede

      the originator of the request suggests that the message was

      misrouted or possibly corrupted.



8.1.3.4 Processing 3xx Responses



   Upon receipt of a redirection response (for example, a 301 response

   status code), clients SHOULD use the URI(s) in the Contact header

   field to formulate one or more new requests based on the redirected

   request.  This process is similar to that of a proxy recursing on a

   3xx class response as detailed in Sections 16.5 and 16.6.  A client

   starts with an initial target set containing exactly one URI, the

   Request-URI of the original request.  If a client wishes to formulate

   new requests based on a 3xx class response to that request, it places

   the URIs to try into the target set.  Subject to the restrictions in

   this specification, a client can choose which Contact URIs it places

   into the target set.  As with proxy recursion, a client processing

   3xx class responses MUST NOT add any given URI to the target set more

   than once.  If the original request had a SIPS URI in the Request-

   URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD

   inform the user of the redirection to an insecure URI.



      Any new request may receive 3xx responses themselves containing

      the original URI as a contact.  Two locations can be configured to

      redirect to each other.  Placing any given URI in the target set

      only once prevents infinite redirection loops.



   As the target set grows, the client MAY generate new requests to the

   URIs in any order.  A common mechanism is to order the set by the "q"

   parameter value from the Contact header field value.  Requests to the

   URIs MAY be generated serially or in parallel.  One approach is to

   process groups of decreasing q-values serially and process the URIs

   in each q-value group in parallel.  Another is to perform only serial

   processing in decreasing q-value order, arbitrarily choosing between

   contacts of equal q-value.



   If contacting an address in the list results in a failure, as defined

   in the next paragraph, the element moves to the next address in the

   list, until the list is exhausted.  If the list is exhausted, then

   the request has failed.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Failures SHOULD be detected through failure response codes (codes

   greater than 399); for network errors the client transaction will

   report any transport layer failures to the transaction user.  Note

   that some response codes (detailed in 8.1.3.5) indicate that the

   request can be retried; requests that are reattempted should not be

   considered failures.



   When a failure for a particular contact address is received, the

   client SHOULD try the next contact address.  This will involve

   creating a new client transaction to deliver a new request.



   In order to create a request based on a contact address in a 3xx

   response, a UAC MUST copy the entire URI from the target set into the

   Request-URI, except for the "method-param" and "header" URI

   parameters (see Section 19.1.1 for a definition of these parameters).

   It uses the "header" parameters to create header field values for the

   new request, overwriting header field values associated with the

   redirected request in accordance with the guidelines in Section

   19.1.5.



   Note that in some instances, header fields that have been

   communicated in the contact address may instead append to existing

   request header fields in the original redirected request.  As a

   general rule, if the header field can accept a comma-separated list

   of values, then the new header field value MAY be appended to any

   existing values in the original redirected request.  If the header

   field does not accept multiple values, the value in the original

   redirected request MAY be overwritten by the header field value

   communicated in the contact address.  For example, if a contact

   address is returned with the following value:



      sip:user@host?Subject=foo&Call-Info=<http://www.foo.com>



   Then any Subject header field in the original redirected request is

   overwritten, but the HTTP URL is merely appended to any existing

   Call-Info header field values.



   It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID

   used in the original redirected request, but the UAC MAY also choose

   to update the Call-ID header field value for new requests, for

   example.



   Finally, once the new request has been constructed, it is sent using

   a new client transaction, and therefore MUST have a new branch ID in

   the top Via field as discussed in Section 8.1.1.7.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   In all other respects, requests sent upon receipt of a redirect

   response SHOULD re-use the header fields and bodies of the original

   request.



   In some instances, Contact header field values may be cached at UAC

   temporarily or permanently depending on the status code received and

   the presence of an expiration interval; see Sections 21.3.2 and

   21.3.3.



8.1.3.5 Processing 4xx Responses



   Certain 4xx response codes require specific UA processing,

   independent of the method.



   If a 401 (Unauthorized) or 407 (Proxy Authentication Required)

   response is received, the UAC SHOULD follow the authorization

   procedures of Section 22.2 and Section 22.3 to retry the request with

   credentials.



   If a 413 (Request Entity Too Large) response is received (Section

   21.4.11), the request contained a body that was longer than the UAS

   was willing to accept.  If possible, the UAC SHOULD retry the

   request, either omitting the body or using one of a smaller length.



   If a 415 (Unsupported Media Type) response is received (Section

   21.4.13), the request contained media types not supported by the UAS.

   The UAC SHOULD retry sending the request, this time only using

   content with types listed in the Accept header field in the response,

   with encodings listed in the Accept-Encoding header field in the

   response, and with languages listed in the Accept-Language in the

   response.



   If a 416 (Unsupported URI Scheme) response is received (Section

   21.4.14), the Request-URI used a URI scheme not supported by the

   server.  The client SHOULD retry the request, this time, using a SIP

   URI.



   If a 420 (Bad Extension) response is received (Section 21.4.15), the

   request contained a Require or Proxy-Require header field listing an

   option-tag for a feature not supported by a proxy or UAS.  The UAC

   SHOULD retry the request, this time omitting any extensions listed in

   the Unsupported header field in the response.



   In all of the above cases, the request is retried by creating a new

   request with the appropriate modifications.  This new request

   constitutes a new transaction and SHOULD have the same value of the

   Call-ID, To, and From of the previous request, but the CSeq should

   contain a new sequence number that is one higher than the previous.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   With other 4xx responses, including those yet to be defined, a retry

   may or may not be possible depending on the method and the use case.



8.2 UAS Behavior



   When a request outside of a dialog is processed by a UAS, there is a

   set of processing rules that are followed, independent of the method.

   Section 12 gives guidance on how a UAS can tell whether a request is

   inside or outside of a dialog.



   Note that request processing is atomic.  If a request is accepted,

   all state changes associated with it MUST be performed.  If it is

   rejected, all state changes MUST NOT be performed.



   UASs SHOULD process the requests in the order of the steps that

   follow in this section (that is, starting with authentication, then

   inspecting the method, the header fields, and so on throughout the

   remainder of this section).



8.2.1 Method Inspection



   Once a request is authenticated (or authentication is skipped), the

   UAS MUST inspect the method of the request.  If the UAS recognizes

   but does not support the method of a request, it MUST generate a 405

   (Method Not Allowed) response.  Procedures for generating responses

   are described in Section 8.2.6.  The UAS MUST also add an Allow

   header field to the 405 (Method Not Allowed) response.  The Allow

   header field MUST list the set of methods supported by the UAS

   generating the message.  The Allow header field is presented in

   Section 20.5.



   If the method is one supported by the server, processing continues.



8.2.2 Header Inspection



   If a UAS does not understand a header field in a request (that is,

   the header field is not defined in this specification or in any

   supported extension), the server MUST ignore that header field and

   continue processing the message.  A UAS SHOULD ignore any malformed

   header fields that are not necessary for processing requests.



8.2.2.1 To and Request-URI



   The To header field identifies the original recipient of the request

   designated by the user identified in the From field.  The original

   recipient may or may not be the UAS processing the request, due to

   call forwarding or other proxy operations.  A UAS MAY apply any

   policy it wishes to determine whether to accept requests when the To







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   header field is not the identity of the UAS.  However, it is

   RECOMMENDED that a UAS accept requests even if they do not recognize

   the URI scheme (for example, a tel: URI) in the To header field, or

   if the To header field does not address a known or current user of

   this UAS.  If, on the other hand, the UAS decides to reject the

   request, it SHOULD generate a response with a 403 (Forbidden) status

   code and pass it to the server transaction for transmission.



   However, the Request-URI identifies the UAS that is to process the

   request.  If the Request-URI uses a scheme not supported by the UAS,

   it SHOULD reject the request with a 416 (Unsupported URI Scheme)

   response.  If the Request-URI does not identify an address that the

   UAS is willing to accept requests for, it SHOULD reject the request

   with a 404 (Not Found) response.  Typically, a UA that uses the

   REGISTER method to bind its address-of-record to a specific contact

   address will see requests whose Request-URI equals that contact

   address.  Other potential sources of received Request-URIs include

   the Contact header fields of requests and responses sent by the UA

   that establish or refresh dialogs.



8.2.2.2 Merged Requests



   If the request has no tag in the To header field, the UAS core MUST

   check the request against ongoing transactions.  If the From tag,

   Call-ID, and CSeq exactly match those associated with an ongoing

   transaction, but the request does not match that transaction (based

   on the matching rules in Section 17.2.3), the UAS core SHOULD

   generate a 482 (Loop Detected) response and pass it to the server

   transaction.



      The same request has arrived at the UAS more than once, following

      different paths, most likely due to forking.  The UAS processes

      the first such request received and responds with a 482 (Loop

      Detected) to the rest of them.



8.2.2.3 Require



   Assuming the UAS decides that it is the proper element to process the

   request, it examines the Require header field, if present.



   The Require header field is used by a UAC to tell a UAS about SIP

   extensions that the UAC expects the UAS to support in order to

   process the request properly.  Its format is described in Section

   20.32.  If a UAS does not understand an option-tag listed in a

   Require header field, it MUST respond by generating a response with

   status code 420 (Bad Extension).  The UAS MUST add an Unsupported

   header field, and list in it those options it does not understand

   amongst those in the Require header field of the request.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL

   request, or in an ACK request sent for a non-2xx response.  These

   header fields MUST be ignored if they are present in these requests.



   An ACK request for a 2xx response MUST contain only those Require and

   Proxy-Require values that were present in the initial request.



   Example:



      UAC->UAS:   INVITE sip:watson@bell-telephone.com SIP/2.0

                  Require: 100rel



      UAS->UAC:   SIP/2.0 420 Bad Extension

                  Unsupported: 100rel



      This behavior ensures that the client-server interaction will

      proceed without delay when all options are understood by both

      sides, and only slow down if options are not understood (as in the

      example above).  For a well-matched client-server pair, the

      interaction proceeds quickly, saving a round-trip often required

      by negotiation mechanisms.  In addition, it also removes ambiguity

      when the client requires features that the server does not

      understand.  Some features, such as call handling fields, are only

      of interest to end systems.



8.2.3 Content Processing



   Assuming the UAS understands any extensions required by the client,

   the UAS examines the body of the message, and the header fields that

   describe it.  If there are any bodies whose type (indicated by the

   Content-Type), language (indicated by the Content-Language) or

   encoding (indicated by the Content-Encoding) are not understood, and

   that body part is not optional (as indicated by the Content-

   Disposition header field), the UAS MUST reject the request with a 415

   (Unsupported Media Type) response.  The response MUST contain an

   Accept header field listing the types of all bodies it understands,

   in the event the request contained bodies of types not supported by

   the UAS.  If the request contained content encodings not understood

   by the UAS, the response MUST contain an Accept-Encoding header field

   listing the encodings understood by the UAS.  If the request

   contained content with languages not understood by the UAS, the

   response MUST contain an Accept-Language header field indicating the

   languages understood by the UAS.  Beyond these checks, body handling

   depends on the method and type.  For further information on the

   processing of content-specific header fields, see Section 7.4 as well

   as Section 20.11 through 20.15.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





8.2.4 Applying Extensions



   A UAS that wishes to apply some extension when generating the

   response MUST NOT do so unless support for that extension is

   indicated in the Supported header field in the request.  If the

   desired extension is not supported, the server SHOULD rely only on

   baseline SIP and any other extensions supported by the client.  In

   rare circumstances, where the server cannot process the request

   without the extension, the server MAY send a 421 (Extension Required)

   response.  This response indicates that the proper response cannot be

   generated without support of a specific extension.  The needed

   extension(s) MUST be included in a Require header field in the

   response.  This behavior is NOT RECOMMENDED, as it will generally

   break interoperability.



   Any extensions applied to a non-421 response MUST be listed in a

   Require header field included in the response.  Of course, the server

   MUST NOT apply extensions not listed in the Supported header field in

   the request.  As a result of this, the Require header field in a

   response will only ever contain option tags defined in standards-

   track RFCs.



8.2.5 Processing the Request



   Assuming all of the checks in the previous subsections are passed,

   the UAS processing becomes method-specific.  Section 10 covers the

   REGISTER request, Section 11 covers the OPTIONS request, Section 13

   covers the INVITE request, and Section 15 covers the BYE request.



8.2.6 Generating the Response



   When a UAS wishes to construct a response to a request, it follows

   the general procedures detailed in the following subsections.

   Additional behaviors specific to the response code in question, which

   are not detailed in this section, may also be required.



   Once all procedures associated with the creation of a response have

   been completed, the UAS hands the response back to the server

   transaction from which it received the request.



8.2.6.1 Sending a Provisional Response



   One largely non-method-specific guideline for the generation of

   responses is that UASs SHOULD NOT issue a provisional response for a

   non-INVITE request.  Rather, UASs SHOULD generate a final response to

   a non-INVITE request as soon as possible.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   When a 100 (Trying) response is generated, any Timestamp header field

   present in the request MUST be copied into this 100 (Trying)

   response.  If there is a delay in generating the response, the UAS

   SHOULD add a delay value into the Timestamp value in the response.

   This value MUST contain the difference between the time of sending of

   the response and receipt of the request, measured in seconds.



8.2.6.2 Headers and Tags



   The From field of the response MUST equal the From header field of

   the request.  The Call-ID header field of the response MUST equal the

   Call-ID header field of the request.  The CSeq header field of the

   response MUST equal the CSeq field of the request.  The Via header

   field values in the response MUST equal the Via header field values

   in the request and MUST maintain the same ordering.



   If a request contained a To tag in the request, the To header field

   in the response MUST equal that of the request.  However, if the To

   header field in the request did not contain a tag, the URI in the To

   header field in the response MUST equal the URI in the To header

   field; additionally, the UAS MUST add a tag to the To header field in

   the response (with the exception of the 100 (Trying) response, in

   which a tag MAY be present).  This serves to identify the UAS that is

   responding, possibly resulting in a component of a dialog ID.  The

   same tag MUST be used for all responses to that request, both final

   and provisional (again excepting the 100 (Trying)).  Procedures for

   the generation of tags are defined in Section 19.3.



8.2.7 Stateless UAS Behavior



   A stateless UAS is a UAS that does not maintain transaction state.

   It replies to requests normally, but discards any state that would

   ordinarily be retained by a UAS after a response has been sent.  If a

   stateless UAS receives a retransmission of a request, it regenerates

   the response and resends it, just as if it were replying to the first

   instance of the request. A UAS cannot be stateless unless the request

   processing for that method would always result in the same response

   if the requests are identical. This rules out stateless registrars,

   for example.  Stateless UASs do not use a transaction layer; they

   receive requests directly from the transport layer and send responses

   directly to the transport layer.



   The stateless UAS role is needed primarily to handle unauthenticated

   requests for which a challenge response is issued.  If

   unauthenticated requests were handled statefully, then malicious

   floods of unauthenticated requests could create massive amounts of











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   transaction state that might slow or completely halt call processing

   in a UAS, effectively creating a denial of service condition; for

   more information see Section 26.1.5.



   The most important behaviors of a stateless UAS are the following:



      o  A stateless UAS MUST NOT send provisional (1xx) responses.



      o  A stateless UAS MUST NOT retransmit responses.



      o  A stateless UAS MUST ignore ACK requests.



      o  A stateless UAS MUST ignore CANCEL requests.



      o  To header tags MUST be generated for responses in a stateless

         manner - in a manner that will generate the same tag for the

         same request consistently.  For information on tag construction

         see Section 19.3.



   In all other respects, a stateless UAS behaves in the same manner as

   a stateful UAS.  A UAS can operate in either a stateful or stateless

   mode for each new request.



8.3 Redirect Servers



   In some architectures it may be desirable to reduce the processing

   load on proxy servers that are responsible for routing requests, and

   improve signaling path robustness, by relying on redirection.



   Redirection allows servers to push routing information for a request

   back in a response to the client, thereby taking themselves out of

   the loop of further messaging for this transaction while still aiding

   in locating the target of the request.  When the originator of the

   request receives the redirection, it will send a new request based on

   the URI(s) it has received.  By propagating URIs from the core of the

   network to its edges, redirection allows for considerable network

   scalability.



   A redirect server is logically constituted of a server transaction

   layer and a transaction user that has access to a location service of

   some kind (see Section 10 for more on registrars and location

   services).  This location service is effectively a database

   containing mappings between a single URI and a set of one or more

   alternative locations at which the target of that URI can be found.



   A redirect server does not issue any SIP requests of its own.  After

   receiving a request other than CANCEL, the server either refuses the

   request or gathers the list of alternative locations from the







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   location service and returns a final response of class 3xx.  For

   well-formed CANCEL requests, it SHOULD return a 2xx response.  This

   response ends the SIP transaction.  The redirect server maintains

   transaction state for an entire SIP transaction.  It is the

   responsibility of clients to detect forwarding loops between redirect

   servers.



   When a redirect server returns a 3xx response to a request, it

   populates the list of (one or more) alternative locations into the

   Contact header field.  An "expires" parameter to the Contact header

   field values may also be supplied to indicate the lifetime of the

   Contact data.



   The Contact header field contains URIs giving the new locations or

   user names to try, or may simply specify additional transport

   parameters.  A 301 (Moved Permanently) or 302 (Moved Temporarily)

   response may also give the same location and username that was

   targeted by the initial request but specify additional transport

   parameters such as a different server or multicast address to try, or

   a change of SIP transport from UDP to TCP or vice versa.



   However, redirect servers MUST NOT redirect a request to a URI equal

   to the one in the Request-URI; instead, provided that the URI does

   not point to itself, the server MAY proxy the request to the

   destination URI, or MAY reject it with a 404.



      If a client is using an outbound proxy, and that proxy actually

      redirects requests, a potential arises for infinite redirection

      loops.



   Note that a Contact header field value MAY also refer to a different

   resource than the one originally called.  For example, a SIP call

   connected to PSTN gateway may need to deliver a special informational

   announcement such as "The number you have dialed has been changed."



   A Contact response header field can contain any suitable URI

   indicating where the called party can be reached, not limited to SIP

   URIs.  For example, it could contain URIs for phones, fax, or irc (if

   they were defined) or a mailto:  (RFC 2368 [32]) URL.  Section 26.4.4

   discusses implications and limitations of redirecting a SIPS URI to a

   non-SIPS URI.



   The "expires" parameter of a Contact header field value indicates how

   long the URI is valid.  The value of the parameter is a number

   indicating seconds.  If this parameter is not provided, the value of

   the Expires header field determines how long the URI is valid.

   Malformed values SHOULD be treated as equivalent to 3600.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      This provides a modest level of backwards compatibility with RFC

      2543, which allowed absolute times in this header field.  If an

      absolute time is received, it will be treated as malformed, and

      then default to 3600.



   Redirect servers MUST ignore features that are not understood

   (including unrecognized header fields, any unknown option tags in

   Require, or even method names) and proceed with the redirection of

   the request in question.



9 Canceling a Request



   The previous section has discussed general UA behavior for generating

   requests and processing responses for requests of all methods.  In

   this section, we discuss a general purpose method, called CANCEL.



   The CANCEL request, as the name implies, is used to cancel a previous

   request sent by a client.  Specifically, it asks the UAS to cease

   processing the request and to generate an error response to that

   request.  CANCEL has no effect on a request to which a UAS has

   already given a final response.  Because of this, it is most useful

   to CANCEL requests to which it can take a server long time to

   respond.  For this reason, CANCEL is best for INVITE requests, which

   can take a long time to generate a response.  In that usage, a UAS

   that receives a CANCEL request for an INVITE, but has not yet sent a

   final response, would "stop ringing", and then respond to the INVITE

   with a specific error response (a 487).



   CANCEL requests can be constructed and sent by both proxies and user

   agent clients.  Section 15 discusses under what conditions a UAC

   would CANCEL an INVITE request, and Section 16.10 discusses proxy

   usage of CANCEL.



   A stateful proxy responds to a CANCEL, rather than simply forwarding

   a response it would receive from a downstream element.  For that

   reason, CANCEL is referred to as a "hop-by-hop" request, since it is

   responded to at each stateful proxy hop.



9.1 Client Behavior



   A CANCEL request SHOULD NOT be sent to cancel a request other than

   INVITE.



      Since requests other than INVITE are responded to immediately,

      sending a CANCEL for a non-INVITE request would always create a

      race condition.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The following procedures are used to construct a CANCEL request.  The

   Request-URI, Call-ID, To, the numeric part of CSeq, and From header

   fields in the CANCEL request MUST be identical to those in the

   request being cancelled, including tags.  A CANCEL constructed by a

   client MUST have only a single Via header field value matching the

   top Via value in the request being cancelled.  Using the same values

   for these header fields allows the CANCEL to be matched with the

   request it cancels (Section 9.2 indicates how such matching occurs).

   However, the method part of the CSeq header field MUST have a value

   of CANCEL.  This allows it to be identified and processed as a

   transaction in its own right (See Section 17).



   If the request being cancelled contains a Route header field, the

   CANCEL request MUST include that Route header field's values.



      This is needed so that stateless proxies are able to route CANCEL

      requests properly.



   The CANCEL request MUST NOT contain any Require or Proxy-Require

   header fields.



   Once the CANCEL is constructed, the client SHOULD check whether it

   has received any response (provisional or final) for the request

   being cancelled (herein referred to as the "original request").



   If no provisional response has been received, the CANCEL request MUST

   NOT be sent; rather, the client MUST wait for the arrival of a

   provisional response before sending the request.  If the original

   request has generated a final response, the CANCEL SHOULD NOT be

   sent, as it is an effective no-op, since CANCEL has no effect on

   requests that have already generated a final response.  When the

   client decides to send the CANCEL, it creates a client transaction

   for the CANCEL and passes it the CANCEL request along with the

   destination address, port, and transport.  The destination address,

   port, and transport for the CANCEL MUST be identical to those used to

   send the original request.



      If it was allowed to send the CANCEL before receiving a response

      for the previous request, the server could receive the CANCEL

      before the original request.



   Note that both the transaction corresponding to the original request

   and the CANCEL transaction will complete independently.  However, a

   UAC canceling a request cannot rely on receiving a 487 (Request

   Terminated) response for the original request, as an RFC 2543-

   compliant UAS will not generate such a response.  If there is no

   final response for the original request in 64*T1 seconds (T1 is









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   defined in Section 17.1.1.1), the client SHOULD then consider the

   original transaction cancelled and SHOULD destroy the client

   transaction handling the original request.



9.2 Server Behavior



   The CANCEL method requests that the TU at the server side cancel a

   pending transaction.  The TU determines the transaction to be

   cancelled by taking the CANCEL request, and then assuming that the

   request method is anything but CANCEL or ACK and applying the

   transaction matching procedures of Section 17.2.3.  The matching

   transaction is the one to be cancelled.



   The processing of a CANCEL request at a server depends on the type of

   server.  A stateless proxy will forward it, a stateful proxy might

   respond to it and generate some CANCEL requests of its own, and a UAS

   will respond to it.  See Section 16.10 for proxy treatment of CANCEL.



   A UAS first processes the CANCEL request according to the general UAS

   processing described in Section 8.2.  However, since CANCEL requests

   are hop-by-hop and cannot be resubmitted, they cannot be challenged

   by the server in order to get proper credentials in an Authorization

   header field.  Note also that CANCEL requests do not contain a

   Require header field.



   If the UAS did not find a matching transaction for the CANCEL

   according to the procedure above, it SHOULD respond to the CANCEL

   with a 481 (Call Leg/Transaction Does Not Exist).  If the transaction

   for the original request still exists, the behavior of the UAS on

   receiving a CANCEL request depends on whether it has already sent a

   final response for the original request.  If it has, the CANCEL

   request has no effect on the processing of the original request, no

   effect on any session state, and no effect on the responses generated

   for the original request.  If the UAS has not issued a final response

   for the original request, its behavior depends on the method of the

   original request.  If the original request was an INVITE, the UAS

   SHOULD immediately respond to the INVITE with a 487 (Request

   Terminated).  A CANCEL request has no impact on the processing of

   transactions with any other method defined in this specification.



   Regardless of the method of the original request, as long as the

   CANCEL matched an existing transaction, the UAS answers the CANCEL

   request itself with a 200 (OK) response.  This response is

   constructed following the procedures described in Section 8.2.6

   noting that the To tag of the response to the CANCEL and the To tag

   in the response to the original request SHOULD be the same.  The

   response to CANCEL is passed to the server transaction for

   transmission.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





10 Registrations



10.1 Overview



   SIP offers a discovery capability.  If a user wants to initiate a

   session with another user, SIP must discover the current host(s) at

   which the destination user is reachable.  This discovery process is

   frequently accomplished by SIP network elements such as proxy servers

   and redirect servers which are responsible for receiving a request,

   determining where to send it based on knowledge of the location of

   the user, and then sending it there.  To do this, SIP network

   elements consult an abstract service known as a location service,

   which provides address bindings for a particular domain.  These

   address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com,

   for example, to one or more URIs that are somehow "closer" to the

   desired user, sip:bob@engineering.biloxi.com, for example.

   Ultimately, a proxy will consult a location service that maps a

   received URI to the user agent(s) at which the desired recipient is

   currently residing.



   Registration creates bindings in a location service for a particular

   domain that associates an address-of-record URI with one or more

   contact addresses.  Thus, when a proxy for that domain receives a

   request whose Request-URI matches the address-of-record, the proxy

   will forward the request to the contact addresses registered to that

   address-of-record.  Generally, it only makes sense to register an

   address-of-record at a domain's location service when requests for

   that address-of-record would be routed to that domain.  In most

   cases, this means that the domain of the registration will need to

   match the domain in the URI of the address-of-record.



   There are many ways by which the contents of the location service can

   be established.  One way is administratively.  In the above example,

   Bob is known to be a member of the engineering department through

   access to a corporate database.  However, SIP provides a mechanism

   for a UA to create a binding explicitly.  This mechanism is known as

   registration.



   Registration entails sending a REGISTER request to a special type of

   UAS known as a registrar.  A registrar acts as the front end to the

   location service for a domain, reading and writing mappings based on

   the contents of REGISTER requests.  This location service is then

   typically consulted by a proxy server that is responsible for routing

   requests for that domain.



   An illustration of the overall registration process is given in

   Figure 2.  Note that the registrar and proxy server are logical roles

   that can be played by a single device in a network; for purposes of







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   clarity the two are separated in this illustration.  Also note that

   UAs may send requests through a proxy server in order to reach a

   registrar if the two are separate elements.



   SIP does not mandate a particular mechanism for implementing the

   location service.  The only requirement is that a registrar for some

   domain MUST be able to read and write data to the location service,

   and a proxy or a redirect server for that domain MUST be capable of

   reading that same data.  A registrar MAY be co-located with a

   particular SIP proxy server for the same domain.



10.2 Constructing the REGISTER Request



   REGISTER requests add, remove, and query bindings.  A REGISTER

   request can add a new binding between an address-of-record and one or

   more contact addresses.  Registration on behalf of a particular

   address-of-record can be performed by a suitably authorized third

   party.  A client can also remove previous bindings or query to

   determine which bindings are currently in place for an address-of-

   record.



   Except as noted, the construction of the REGISTER request and the

   behavior of clients sending a REGISTER request is identical to the

   general UAC behavior described in Section 8.1 and Section 17.1.



   A REGISTER request does not establish a dialog.  A UAC MAY include a

   Route header field in a REGISTER request based on a pre-existing

   route set as described in Section 8.1.  The Record-Route header field

   has no meaning in REGISTER requests or responses, and MUST be ignored

   if present.  In particular, the UAC MUST NOT create a new route set

   based on the presence or absence of a Record-Route header field in

   any response to a REGISTER request.



   The following header fields, except Contact, MUST be included in a

   REGISTER request.  A Contact header field MAY be included:



      Request-URI: The Request-URI names the domain of the location

           service for which the registration is meant (for example,

           "sip:chicago.com").  The "userinfo" and "@" components of the

           SIP URI MUST NOT be present.



      To: The To header field contains the address of record whose

           registration is to be created, queried, or modified.  The To

           header field and the Request-URI field typically differ, as

           the former contains a user name.  This address-of-record MUST

           be a SIP URI or SIPS URI.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      From: The From header field contains the address-of-record of the

           person responsible for the registration.  The value is the

           same as the To header field unless the request is a third-

           party registration.



      Call-ID: All registrations from a UAC SHOULD use the same Call-ID

           header field value for registrations sent to a particular

           registrar.



           If the same client were to use different Call-ID values, a

           registrar could not detect whether a delayed REGISTER request

           might have arrived out of order.



      CSeq: The CSeq value guarantees proper ordering of REGISTER

           requests.  A UA MUST increment the CSeq value by one for each

           REGISTER request with the same Call-ID.



      Contact: REGISTER requests MAY contain a Contact header field with

           zero or more values containing address bindings.



   UAs MUST NOT send a new registration (that is, containing new Contact

   header field values, as opposed to a retransmission) until they have

   received a final response from the registrar for the previous one or

   the previous REGISTER request has timed out.























































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



RFC 3261            SIP: Session Initiation Protocol           June 2002





                                                 bob

                                               +----+

                                               | UA |

                                               |    |

                                               +----+

                                                  |

                                                  |3)INVITE

                                                  |   carol@chicago.com

         chicago.com        +--------+            V

         +---------+ 2)Store|Location|4)Query +-----+

         |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com

         +---------+        +--------+=======>+-----+

               A                      5)Resp      |

               |                                  |

               |                                  |

     1)REGISTER|                                  |

               |                                  |

            +----+                                |

            | UA |<-------------------------------+

   cube2214a|    |                            6)INVITE

            +----+                    carol@cube2214a.chicago.com

             carol



                      Figure 2: REGISTER example



      The following Contact header parameters have a special meaning in

           REGISTER requests:



      action: The "action" parameter from RFC 2543 has been deprecated.

           UACs SHOULD NOT use the "action" parameter.



      expires: The "expires" parameter indicates how long the UA would

           like the binding to be valid.  The value is a number

           indicating seconds.  If this parameter is not provided, the

           value of the Expires header field is used instead.

           Implementations MAY treat values larger than 2**32-1

           (4294967295 seconds or 136 years) as equivalent to 2**32-1.

           Malformed values SHOULD be treated as equivalent to 3600.



10.2.1 Adding Bindings



   The REGISTER request sent to a registrar includes the contact

   address(es) to which SIP requests for the address-of-record should be

   forwarded.  The address-of-record is included in the To header field

   of the REGISTER request.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The Contact header field values of the request typically consist of

   SIP or SIPS URIs that identify particular SIP endpoints (for example,

   "sip:carol@cube2214a.chicago.com"), but they MAY use any URI scheme.

   A SIP UA can choose to register telephone numbers (with the tel URL,

   RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32])

   as Contacts for an address-of-record, for example.



   For example, Carol, with address-of-record "sip:carol@chicago.com",

   would register with the SIP registrar of the domain chicago.com.  Her

   registrations would then be used by a proxy server in the chicago.com

   domain to route requests for Carol's address-of-record to her SIP

   endpoint.



   Once a client has established bindings at a registrar, it MAY send

   subsequent registrations containing new bindings or modifications to

   existing bindings as necessary.  The 2xx response to the REGISTER

   request will contain, in a Contact header field, a complete list of

   bindings that have been registered for this address-of-record at this

   registrar.



   If the address-of-record in the To header field of a REGISTER request

   is a SIPS URI, then any Contact header field values in the request

   SHOULD also be SIPS URIs.  Clients should only register non-SIPS URIs

   under a SIPS address-of-record when the security of the resource

   represented by the contact address is guaranteed by other means.

   This may be applicable to URIs that invoke protocols other than SIP,

   or SIP devices secured by protocols other than TLS.



   Registrations do not need to update all bindings.  Typically, a UA

   only updates its own contact addresses.



10.2.1.1 Setting the Expiration Interval of Contact Addresses



   When a client sends a REGISTER request, it MAY suggest an expiration

   interval that indicates how long the client would like the

   registration to be valid.  (As described in Section 10.3, the

   registrar selects the actual time interval based on its local

   policy.)



   There are two ways in which a client can suggest an expiration

   interval for a binding: through an Expires header field or an

   "expires" Contact header parameter.  The latter allows expiration

   intervals to be suggested on a per-binding basis when more than one

   binding is given in a single REGISTER request, whereas the former

   suggests an expiration interval for all Contact header field values

   that do not contain the "expires" parameter.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   If neither mechanism for expressing a suggested expiration time is

   present in a REGISTER, the client is indicating its desire for the

   server to choose.



10.2.1.2 Preferences among Contact Addresses



   If more than one Contact is sent in a REGISTER request, the

   registering UA intends to associate all of the URIs in these Contact

   header field values with the address-of-record present in the To

   field.  This list can be prioritized with the "q" parameter in the

   Contact header field.  The "q" parameter indicates a relative

   preference for the particular Contact header field value compared to

   other bindings for this address-of-record.  Section 16.6 describes

   how a proxy server uses this preference indication.



10.2.2 Removing Bindings



   Registrations are soft state and expire unless refreshed, but can

   also be explicitly removed.  A client can attempt to influence the

   expiration interval selected by the registrar as described in Section

   10.2.1.  A UA requests the immediate removal of a binding by

   specifying an expiration interval of "0" for that contact address in

   a REGISTER request.  UAs SHOULD support this mechanism so that

   bindings can be removed before their expiration interval has passed.



   The REGISTER-specific Contact header field value of "*" applies to

   all registrations, but it MUST NOT be used unless the Expires header

   field is present with a value of "0".



      Use of the "*" Contact header field value allows a registering UA

      to remove all bindings associated with an address-of-record

      without knowing their precise values.



10.2.3 Fetching Bindings



   A success response to any REGISTER request contains the complete list

   of existing bindings, regardless of whether the request contained a

   Contact header field.  If no Contact header field is present in a

   REGISTER request, the list of bindings is left unchanged.



10.2.4 Refreshing Bindings



   Each UA is responsible for refreshing the bindings that it has

   previously established.  A UA SHOULD NOT refresh bindings set up by

   other UAs.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The 200 (OK) response from the registrar contains a list of Contact

   fields enumerating all current bindings.  The UA compares each

   contact address to see if it created the contact address, using

   comparison rules in Section 19.1.4.  If so, it updates the expiration

   time interval according to the expires parameter or, if absent, the

   Expires field value.  The UA then issues a REGISTER request for each

   of its bindings before the expiration interval has elapsed.  It MAY

   combine several updates into one REGISTER request.



   A UA SHOULD use the same Call-ID for all registrations during a

   single boot cycle.  Registration refreshes SHOULD be sent to the same

   network address as the original registration, unless redirected.



10.2.5 Setting the Internal Clock



   If the response for a REGISTER request contains a Date header field,

   the client MAY use this header field to learn the current time in

   order to set any internal clocks.



10.2.6 Discovering a Registrar



   UAs can use three ways to determine the address to which to send

   registrations:  by configuration, using the address-of-record, and

   multicast.  A UA can be configured, in ways beyond the scope of this

   specification, with a registrar address.  If there is no configured

   registrar address, the UA SHOULD use the host part of the address-

   of-record as the Request-URI and address the request there, using the

   normal SIP server location mechanisms [4].  For example, the UA for

   the user "sip:carol@chicago.com" addresses the REGISTER request to

   "sip:chicago.com".



   Finally, a UA can be configured to use multicast.  Multicast

   registrations are addressed to the well-known "all SIP servers"

   multicast address "sip.mcast.net" (224.0.1.75 for IPv4).  No well-

   known IPv6 multicast address has been allocated; such an allocation

   will be documented separately when needed.  SIP UAs MAY listen to

   that address and use it to become aware of the location of other

   local users (see [33]); however, they do not respond to the request.



      Multicast registration may be inappropriate in some environments,

      for example, if multiple businesses share the same local area

      network.



10.2.7 Transmitting a Request



   Once the REGISTER method has been constructed, and the destination of

   the message identified, UACs follow the procedures described in

   Section 8.1.2 to hand off the REGISTER to the transaction layer.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   If the transaction layer returns a timeout error because the REGISTER

   yielded no response, the UAC SHOULD NOT immediately re-attempt a

   registration to the same registrar.



      An immediate re-attempt is likely to also timeout.  Waiting some

      reasonable time interval for the conditions causing the timeout to

      be corrected reduces unnecessary load on the network.  No specific

      interval is mandated.



10.2.8 Error Responses



   If a UA receives a 423 (Interval Too Brief) response, it MAY retry

   the registration after making the expiration interval of all contact

   addresses in the REGISTER request equal to or greater than the

   expiration interval within the Min-Expires header field of the 423

   (Interval Too Brief) response.



10.3 Processing REGISTER Requests



   A registrar is a UAS that responds to REGISTER requests and maintains

   a list of bindings that are accessible to proxy servers and redirect

   servers within its administrative domain.  A registrar handles

   requests according to Section 8.2 and Section 17.2, but it accepts

   only REGISTER requests.  A registrar MUST not generate 6xx responses.



   A registrar MAY redirect REGISTER requests as appropriate.  One

   common usage would be for a registrar listening on a multicast

   interface to redirect multicast REGISTER requests to its own unicast

   interface with a 302 (Moved Temporarily) response.



   Registrars MUST ignore the Record-Route header field if it is

   included in a REGISTER request.  Registrars MUST NOT include a

   Record-Route header field in any response to a REGISTER request.



      A registrar might receive a request that traversed a proxy which

      treats REGISTER as an unknown request and which added a Record-

      Route header field value.



   A registrar has to know (for example, through configuration) the set

   of domain(s) for which it maintains bindings.  REGISTER requests MUST

   be processed by a registrar in the order that they are received.

   REGISTER requests MUST also be processed atomically, meaning that a

   particular REGISTER request is either processed completely or not at

   all.  Each REGISTER message MUST be processed independently of any

   other registration or binding changes.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   When receiving a REGISTER request, a registrar follows these steps:



      1. The registrar inspects the Request-URI to determine whether it

         has access to bindings for the domain identified in the

         Request-URI.  If not, and if the server also acts as a proxy

         server, the server SHOULD forward the request to the addressed

         domain, following the general behavior for proxying messages

         described in Section 16.



      2. To guarantee that the registrar supports any necessary

         extensions, the registrar MUST process the Require header field

         values as described for UASs in Section 8.2.2.



      3. A registrar SHOULD authenticate the UAC.  Mechanisms for the

         authentication of SIP user agents are described in Section 22.

         Registration behavior in no way overrides the generic

         authentication framework for SIP.  If no authentication

         mechanism is available, the registrar MAY take the From address

         as the asserted identity of the originator of the request.



      4. The registrar SHOULD determine if the authenticated user is

         authorized to modify registrations for this address-of-record.

         For example, a registrar might consult an authorization

         database that maps user names to a list of addresses-of-record

         for which that user has authorization to modify bindings.  If

         the authenticated user is not authorized to modify bindings,

         the registrar MUST return a 403 (Forbidden) and skip the

         remaining steps.



         In architectures that support third-party registration, one

         entity may be responsible for updating the registrations

         associated with multiple addresses-of-record.



      5. The registrar extracts the address-of-record from the To header

         field of the request.  If the address-of-record is not valid

         for the domain in the Request-URI, the registrar MUST send a

         404 (Not Found) response and skip the remaining steps.  The URI

         MUST then be converted to a canonical form.  To do that, all

         URI parameters MUST be removed (including the user-param), and

         any escaped characters MUST be converted to their unescaped

         form.  The result serves as an index into the list of bindings.





















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      6. The registrar checks whether the request contains the Contact

         header field.  If not, it skips to the last step.  If the

         Contact header field is present, the registrar checks if there

         is one Contact field value that contains the special value "*"

         and an Expires field.  If the request has additional Contact

         fields or an expiration time other than zero, the request is

         invalid, and the server MUST return a 400 (Invalid Request) and

         skip the remaining steps.  If not, the registrar checks whether

         the Call-ID agrees with the value stored for each binding.  If

         not, it MUST remove the binding.  If it does agree, it MUST

         remove the binding only if the CSeq in the request is higher

         than the value stored for that binding.  Otherwise, the update

         MUST be aborted and the request fails.



      7. The registrar now processes each contact address in the Contact

         header field in turn.  For each address, it determines the

         expiration interval as follows:



         -  If the field value has an "expires" parameter, that value

            MUST be taken as the requested expiration.



         -  If there is no such parameter, but the request has an

            Expires header field, that value MUST be taken as the

            requested expiration.



         -  If there is neither, a locally-configured default value MUST

            be taken as the requested expiration.



         The registrar MAY choose an expiration less than the requested

         expiration interval.  If and only if the requested expiration

         interval is greater than zero AND smaller than one hour AND

         less than a registrar-configured minimum, the registrar MAY

         reject the registration with a response of 423 (Interval Too

         Brief).  This response MUST contain a Min-Expires header field

         that states the minimum expiration interval the registrar is

         willing to honor.  It then skips the remaining steps.



         Allowing the registrar to set the registration interval

         protects it against excessively frequent registration refreshes

         while limiting the state that it needs to maintain and

         decreasing the likelihood of registrations going stale.  The

         expiration interval of a registration is frequently used in the

         creation of services.  An example is a follow-me service, where

         the user may only be available at a terminal for a brief

         period.  Therefore, registrars should accept brief

         registrations; a request should only be rejected if the

         interval is so short that the refreshes would degrade registrar

         performance.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         For each address, the registrar then searches the list of

         current bindings using the URI comparison rules.  If the

         binding does not exist, it is tentatively added.  If the

         binding does exist, the registrar checks the Call-ID value.  If

         the Call-ID value in the existing binding differs from the

         Call-ID value in the request, the binding MUST be removed if

         the expiration time is zero and updated otherwise.  If they are

         the same, the registrar compares the CSeq value.  If the value

         is higher than that of the existing binding, it MUST update or

         remove the binding as above.  If not, the update MUST be

         aborted and the request fails.



         This algorithm ensures that out-of-order requests from the same

         UA are ignored.



         Each binding record records the Call-ID and CSeq values from

         the request.



         The binding updates MUST be committed (that is, made visible to

         the proxy or redirect server) if and only if all binding

         updates and additions succeed.  If any one of them fails (for

         example, because the back-end database commit failed), the

         request MUST fail with a 500 (Server Error) response and all

         tentative binding updates MUST be removed.



      8. The registrar returns a 200 (OK) response.  The response MUST

         contain Contact header field values enumerating all current

         bindings.  Each Contact value MUST feature an "expires"

         parameter indicating its expiration interval chosen by the

         registrar.  The response SHOULD include a Date header field.



11 Querying for Capabilities



   The SIP method OPTIONS allows a UA to query another UA or a proxy

   server as to its capabilities.  This allows a client to discover

   information about the supported methods, content types, extensions,

   codecs, etc. without "ringing" the other party.  For example, before

   a client inserts a Require header field into an INVITE listing an

   option that it is not certain the destination UAS supports, the

   client can query the destination UAS with an OPTIONS to see if this

   option is returned in a Supported header field.  All UAs MUST support

   the OPTIONS method.



   The target of the OPTIONS request is identified by the Request-URI,

   which could identify another UA or a SIP server.  If the OPTIONS is

   addressed to a proxy server, the Request-URI is set without a user

   part, similar to the way a Request-URI is set for a REGISTER request.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Alternatively, a server receiving an OPTIONS request with a Max-

   Forwards header field value of 0 MAY respond to the request

   regardless of the Request-URI.



      This behavior is common with HTTP/1.1.  This behavior can be used

      as a "traceroute" functionality to check the capabilities of

      individual hop servers by sending a series of OPTIONS requests

      with incremented Max-Forwards values.



   As is the case for general UA behavior, the transaction layer can

   return a timeout error if the OPTIONS yields no response.  This may

   indicate that the target is unreachable and hence unavailable.



   An OPTIONS request MAY be sent as part of an established dialog to

   query the peer on capabilities that may be utilized later in the

   dialog.



11.1 Construction of OPTIONS Request



   An OPTIONS request is constructed using the standard rules for a SIP

   request as discussed in Section 8.1.1.



   A Contact header field MAY be present in an OPTIONS.



   An Accept header field SHOULD be included to indicate the type of

   message body the UAC wishes to receive in the response.  Typically,

   this is set to a format that is used to describe the media

   capabilities of a UA, such as SDP (application/sdp).



   The response to an OPTIONS request is assumed to be scoped to the

   Request-URI in the original request.  However, only when an OPTIONS

   is sent as part of an established dialog is it guaranteed that future

   requests will be received by the server that generated the OPTIONS

   response.



   Example OPTIONS request:



      OPTIONS sip:carol@chicago.com SIP/2.0

      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877

      Max-Forwards: 70

      To: <sip:carol@chicago.com>

      From: Alice <sip:alice@atlanta.com>;tag=1928301774

      Call-ID: a84b4c76e66710

      CSeq: 63104 OPTIONS

      Contact: <sip:alice@pc33.atlanta.com>

      Accept: application/sdp

      Content-Length: 0









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





11.2 Processing of OPTIONS Request



   The response to an OPTIONS is constructed using the standard rules

   for a SIP response as discussed in Section 8.2.6.  The response code

   chosen MUST be the same that would have been chosen had the request

   been an INVITE.  That is, a 200 (OK) would be returned if the UAS is

   ready to accept a call, a 486 (Busy Here) would be returned if the

   UAS is busy, etc.  This allows an OPTIONS request to be used to

   determine the basic state of a UAS, which can be an indication of

   whether the UAS will accept an INVITE request.



   An OPTIONS request received within a dialog generates a 200 (OK)

   response that is identical to one constructed outside a dialog and

   does not have any impact on the dialog.



   This use of OPTIONS has limitations due to the differences in proxy

   handling of OPTIONS and INVITE requests.  While a forked INVITE can

   result in multiple 200 (OK) responses being returned, a forked

   OPTIONS will only result in a single 200 (OK) response, since it is

   treated by proxies using the non-INVITE handling.  See Section 16.7

   for the normative details.



   If the response to an OPTIONS is generated by a proxy server, the

   proxy returns a 200 (OK), listing the capabilities of the server.

   The response does not contain a message body.



   Allow, Accept, Accept-Encoding, Accept-Language, and Supported header

   fields SHOULD be present in a 200 (OK) response to an OPTIONS

   request.  If the response is generated by a proxy, the Allow header

   field SHOULD be omitted as it is ambiguous since a proxy is method

   agnostic.  Contact header fields MAY be present in a 200 (OK)

   response and have the same semantics as in a 3xx response.  That is,

   they may list a set of alternative names and methods of reaching the

   user.  A Warning header field MAY be present.



   A message body MAY be sent, the type of which is determined by the

   Accept header field in the OPTIONS request (application/sdp is the

   default if the Accept header field is not present).  If the types

   include one that can describe media capabilities, the UAS SHOULD

   include a body in the response for that purpose.  Details on the

   construction of such a body in the case of application/sdp are

   described in [13].



















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Example OPTIONS response generated by a UAS (corresponding to the

   request in Section 11.1):



      SIP/2.0 200 OK

      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877

       ;received=192.0.2.4

      To: <sip:carol@chicago.com>;tag=93810874

      From: Alice <sip:alice@atlanta.com>;tag=1928301774

      Call-ID: a84b4c76e66710

      CSeq: 63104 OPTIONS

      Contact: <sip:carol@chicago.com>

      Contact: <mailto:carol@chicago.com>

      Allow: INVITE, ACK, CANCEL, OPTIONS, BYE

      Accept: application/sdp

      Accept-Encoding: gzip

      Accept-Language: en

      Supported: foo

      Content-Type: application/sdp

      Content-Length: 274



      (SDP not shown)



12 Dialogs



   A key concept for a user agent is that of a dialog.  A dialog

   represents a peer-to-peer SIP relationship between two user agents

   that persists for some time.  The dialog facilitates sequencing of

   messages between the user agents and proper routing of requests

   between both of them.  The dialog represents a context in which to

   interpret SIP messages.  Section 8 discussed method independent UA

   processing for requests and responses outside of a dialog.  This

   section discusses how those requests and responses are used to

   construct a dialog, and then how subsequent requests and responses

   are sent within a dialog.



   A dialog is identified at each UA with a dialog ID, which consists of

   a Call-ID value, a local tag and a remote tag.  The dialog ID at each

   UA involved in the dialog is not the same.  Specifically, the local

   tag at one UA is identical to the remote tag at the peer UA.  The

   tags are opaque tokens that facilitate the generation of unique

   dialog IDs.



   A dialog ID is also associated with all responses and with any

   request that contains a tag in the To field.  The rules for computing

   the dialog ID of a message depend on whether the SIP element is a UAC

   or UAS.  For a UAC, the Call-ID value of the dialog ID is set to the

   Call-ID of the message, the remote tag is set to the tag in the To

   field of the message, and the local tag is set to the tag in the From







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   field of the message (these rules apply to both requests and

   responses).  As one would expect for a UAS, the Call-ID value of the

   dialog ID is set to the Call-ID of the message, the remote tag is set

   to the tag in the From field of the message, and the local tag is set

   to the tag in the To field of the message.



   A dialog contains certain pieces of state needed for further message

   transmissions within the dialog.  This state consists of the dialog

   ID, a local sequence number (used to order requests from the UA to

   its peer), a remote sequence number (used to order requests from its

   peer to the UA), a local URI, a remote URI, remote target, a boolean

   flag called "secure", and a route set, which is an ordered list of

   URIs.  The route set is the list of servers that need to be traversed

   to send a request to the peer.  A dialog can also be in the "early"

   state, which occurs when it is created with a provisional response,

   and then transition to the "confirmed" state when a 2xx final

   response arrives.  For other responses, or if no response arrives at

   all on that dialog, the early dialog terminates.



12.1 Creation of a Dialog



   Dialogs are created through the generation of non-failure responses

   to requests with specific methods.  Within this specification, only

   2xx and 101-199 responses with a To tag, where the request was

   INVITE, will establish a dialog.  A dialog established by a non-final

   response to a request is in the "early" state and it is called an

   early dialog.  Extensions MAY define other means for creating

   dialogs.  Section 13 gives more details that are specific to the

   INVITE method.  Here, we describe the process for creation of dialog

   state that is not dependent on the method.



   UAs MUST assign values to the dialog ID components as described

   below.



12.1.1 UAS behavior



   When a UAS responds to a request with a response that establishes a

   dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route

   header field values from the request into the response (including the

   URIs, URI parameters, and any Record-Route header field parameters,

   whether they are known or unknown to the UAS) and MUST maintain the

   order of those values.  The UAS MUST add a Contact header field to

   the response.  The Contact header field contains an address where the

   UAS would like to be contacted for subsequent requests in the dialog

   (which includes the ACK for a 2xx response in the case of an INVITE).

   Generally, the host portion of this URI is the IP address or FQDN of

   the host.  The URI provided in the Contact header field MUST be a SIP

   or SIPS URI.  If the request that initiated the dialog contained a







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   SIPS URI in the Request-URI or in the top Record-Route header field

   value, if there was any, or the Contact header field if there was no

   Record-Route header field, the Contact header field in the response

   MUST be a SIPS URI.  The URI SHOULD have global scope (that is, the

   same URI can be used in messages outside this dialog).  The same way,

   the scope of the URI in the Contact header field of the INVITE is not

   limited to this dialog either.  It can therefore be used in messages

   to the UAC even outside this dialog.



   The UAS then constructs the state of the dialog.  This state MUST be

   maintained for the duration of the dialog.



   If the request arrived over TLS, and the Request-URI contained a SIPS

   URI, the "secure" flag is set to TRUE.



   The route set MUST be set to the list of URIs in the Record-Route

   header field from the request, taken in order and preserving all URI

   parameters.  If no Record-Route header field is present in the

   request, the route set MUST be set to the empty set.  This route set,

   even if empty, overrides any pre-existing route set for future

   requests in this dialog.  The remote target MUST be set to the URI

   from the Contact header field of the request.



   The remote sequence number MUST be set to the value of the sequence

   number in the CSeq header field of the request.  The local sequence

   number MUST be empty.  The call identifier component of the dialog ID

   MUST be set to the value of the Call-ID in the request.  The local

   tag component of the dialog ID MUST be set to the tag in the To field

   in the response to the request (which always includes a tag), and the

   remote tag component of the dialog ID MUST be set to the tag from the

   From field in the request.  A UAS MUST be prepared to receive a

   request without a tag in the From field, in which case the tag is

   considered to have a value of null.



      This is to maintain backwards compatibility with RFC 2543, which

      did not mandate From tags.



   The remote URI MUST be set to the URI in the From field, and the

   local URI MUST be set to the URI in the To field.



12.1.2 UAC Behavior



   When a UAC sends a request that can establish a dialog (such as an

   INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e.,

   the same SIP URI can be used in messages outside this dialog) in the

   Contact header field of the request.  If the request has a Request-

   URI or a topmost Route header field value with a SIPS URI, the

   Contact header field MUST contain a SIPS URI.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   When a UAC receives a response that establishes a dialog, it

   constructs the state of the dialog.  This state MUST be maintained

   for the duration of the dialog.



   If the request was sent over TLS, and the Request-URI contained a

   SIPS URI, the "secure" flag is set to TRUE.



   The route set MUST be set to the list of URIs in the Record-Route

   header field from the response, taken in reverse order and preserving

   all URI parameters.  If no Record-Route header field is present in

   the response, the route set MUST be set to the empty set.  This route

   set, even if empty, overrides any pre-existing route set for future

   requests in this dialog.  The remote target MUST be set to the URI

   from the Contact header field of the response.



   The local sequence number MUST be set to the value of the sequence

   number in the CSeq header field of the request.  The remote sequence

   number MUST be empty (it is established when the remote UA sends a

   request within the dialog).  The call identifier component of the

   dialog ID MUST be set to the value of the Call-ID in the request.

   The local tag component of the dialog ID MUST be set to the tag in

   the From field in the request, and the remote tag component of the

   dialog ID MUST be set to the tag in the To field of the response.  A

   UAC MUST be prepared to receive a response without a tag in the To

   field, in which case the tag is considered to have a value of null.



      This is to maintain backwards compatibility with RFC 2543, which

      did not mandate To tags.



   The remote URI MUST be set to the URI in the To field, and the local

   URI MUST be set to the URI in the From field.



12.2 Requests within a Dialog



   Once a dialog has been established between two UAs, either of them

   MAY initiate new transactions as needed within the dialog.  The UA

   sending the request will take the UAC role for the transaction.  The

   UA receiving the request will take the UAS role.  Note that these may

   be different roles than the UAs held during the transaction that

   established the dialog.



   Requests within a dialog MAY contain Record-Route and Contact header

   fields.  However, these requests do not cause the dialog's route set

   to be modified, although they may modify the remote target URI.

   Specifically, requests that are not target refresh requests do not

   modify the dialog's remote target URI, and requests that are target

   refresh requests do.  For dialogs that have been established with an









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   INVITE, the only target refresh request defined is re-INVITE (see

   Section 14).  Other extensions may define different target refresh

   requests for dialogs established in other ways.



      Note that an ACK is NOT a target refresh request.



   Target refresh requests only update the dialog's remote target URI,

   and not the route set formed from the Record-Route.  Updating the

   latter would introduce severe backwards compatibility problems with

   RFC 2543-compliant systems.



12.2.1 UAC Behavior



12.2.1.1 Generating the Request



   A request within a dialog is constructed by using many of the

   components of the state stored as part of the dialog.



   The URI in the To field of the request MUST be set to the remote URI

   from the dialog state.  The tag in the To header field of the request

   MUST be set to the remote tag of the dialog ID.  The From URI of the

   request MUST be set to the local URI from the dialog state.  The tag

   in the From header field of the request MUST be set to the local tag

   of the dialog ID.  If the value of the remote or local tags is null,

   the tag parameter MUST be omitted from the To or From header fields,

   respectively.



      Usage of the URI from the To and From fields in the original

      request within subsequent requests is done for backwards

      compatibility with RFC 2543, which used the URI for dialog

      identification.  In this specification, only the tags are used for

      dialog identification.  It is expected that mandatory reflection

      of the original To and From URI in mid-dialog requests will be

      deprecated in a subsequent revision of this specification.



   The Call-ID of the request MUST be set to the Call-ID of the dialog.

   Requests within a dialog MUST contain strictly monotonically

   increasing and contiguous CSeq sequence numbers (increasing-by-one)

   in each direction (excepting ACK and CANCEL of course, whose numbers

   equal the requests being acknowledged or cancelled).  Therefore, if

   the local sequence number is not empty, the value of the local

   sequence number MUST be incremented by one, and this value MUST be

   placed into the CSeq header field.  If the local sequence number is

   empty, an initial value MUST be chosen using the guidelines of

   Section 8.1.1.5.  The method field in the CSeq header field value

   MUST match the method of the request.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      With a length of 32 bits, a client could generate, within a single

      call, one request a second for about 136 years before needing to

      wrap around.  The initial value of the sequence number is chosen

      so that subsequent requests within the same call will not wrap

      around.  A non-zero initial value allows clients to use a time-

      based initial sequence number.  A client could, for example,

      choose the 31 most significant bits of a 32-bit second clock as an

      initial sequence number.



   The UAC uses the remote target and route set to build the Request-URI

   and Route header field of the request.



   If the route set is empty, the UAC MUST place the remote target URI

   into the Request-URI.  The UAC MUST NOT add a Route header field to

   the request.



   If the route set is not empty, and the first URI in the route set

   contains the lr parameter (see Section 19.1.1), the UAC MUST place

   the remote target URI into the Request-URI and MUST include a Route

   header field containing the route set values in order, including all

   parameters.



   If the route set is not empty, and its first URI does not contain the

   lr parameter, the UAC MUST place the first URI from the route set

   into the Request-URI, stripping any parameters that are not allowed

   in a Request-URI.  The UAC MUST add a Route header field containing

   the remainder of the route set values in order, including all

   parameters.  The UAC MUST then place the remote target URI into the

   Route header field as the last value.



   For example, if the remote target is sip:user@remoteua and the route

   set contains:



      <sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>



   The request will be formed with the following Request-URI and Route

   header field:



   METHOD sip:proxy1

   Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>



      If the first URI of the route set does not contain the lr

      parameter, the proxy indicated does not understand the routing

      mechanisms described in this document and will act as specified in

      RFC 2543, replacing the Request-URI with the first Route header

      field value it receives while forwarding the message.  Placing the

      Request-URI at the end of the Route header field preserves the









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      information in that Request-URI across the strict router (it will

      be returned to the Request-URI when the request reaches a loose-

      router).



   A UAC SHOULD include a Contact header field in any target refresh

   requests within a dialog, and unless there is a need to change it,

   the URI SHOULD be the same as used in previous requests within the

   dialog.  If the "secure" flag is true, that URI MUST be a SIPS URI.

   As discussed in Section 12.2.2, a Contact header field in a target

   refresh request updates the remote target URI.  This allows a UA to

   provide a new contact address, should its address change during the

   duration of the dialog.



   However, requests that are not target refresh requests do not affect

   the remote target URI for the dialog.



   The rest of the request is formed as described in Section 8.1.1.



   Once the request has been constructed, the address of the server is

   computed and the request is sent, using the same procedures for

   requests outside of a dialog (Section 8.1.2).



      The procedures in Section 8.1.2 will normally result in the

      request being sent to the address indicated by the topmost Route

      header field value or the Request-URI if no Route header field is

      present.  Subject to certain restrictions, they allow the request

      to be sent to an alternate address (such as a default outbound

      proxy not represented in the route set).



12.2.1.2 Processing the Responses



   The UAC will receive responses to the request from the transaction

   layer.  If the client transaction returns a timeout, this is treated

   as a 408 (Request Timeout) response.



   The behavior of a UAC that receives a 3xx response for a request sent

   within a dialog is the same as if the request had been sent outside a

   dialog.  This behavior is described in Section 8.1.3.4.



      Note, however, that when the UAC tries alternative locations, it

      still uses the route set for the dialog to build the Route header

      of the request.



   When a UAC receives a 2xx response to a target refresh request, it

   MUST replace the dialog's remote target URI with the URI from the

   Contact header field in that response, if present.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   If the response for a request within a dialog is a 481

   (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC

   SHOULD terminate the dialog.  A UAC SHOULD also terminate a dialog if

   no response at all is received for the request (the client

   transaction would inform the TU about the timeout.)



      For INVITE initiated dialogs, terminating the dialog consists of

      sending a BYE.



12.2.2 UAS Behavior



   Requests sent within a dialog, as any other requests, are atomic.  If

   a particular request is accepted by the UAS, all the state changes

   associated with it are performed.  If the request is rejected, none

   of the state changes are performed.



      Note that some requests, such as INVITEs, affect several pieces of

      state.



   The UAS will receive the request from the transaction layer.  If the

   request has a tag in the To header field, the UAS core computes the

   dialog identifier corresponding to the request and compares it with

   existing dialogs.  If there is a match, this is a mid-dialog request.

   In that case, the UAS first applies the same processing rules for

   requests outside of a dialog, discussed in Section 8.2.



   If the request has a tag in the To header field, but the dialog

   identifier does not match any existing dialogs, the UAS may have

   crashed and restarted, or it may have received a request for a

   different (possibly failed) UAS (the UASs can construct the To tags

   so that a UAS can identify that the tag was for a UAS for which it is

   providing recovery).  Another possibility is that the incoming

   request has been simply misrouted.  Based on the To tag, the UAS MAY

   either accept or reject the request.  Accepting the request for

   acceptable To tags provides robustness, so that dialogs can persist

   even through crashes.  UAs wishing to support this capability must

   take into consideration some issues such as choosing monotonically

   increasing CSeq sequence numbers even across reboots, reconstructing

   the route set, and accepting out-of-range RTP timestamps and sequence

   numbers.



   If the UAS wishes to reject the request because it does not wish to

   recreate the dialog, it MUST respond to the request with a 481

   (Call/Transaction Does Not Exist) status code and pass that to the

   server transaction.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Requests that do not change in any way the state of a dialog may be

   received within a dialog (for example, an OPTIONS request).  They are

   processed as if they had been received outside the dialog.



   If the remote sequence number is empty, it MUST be set to the value

   of the sequence number in the CSeq header field value in the request.

   If the remote sequence number was not empty, but the sequence number

   of the request is lower than the remote sequence number, the request

   is out of order and MUST be rejected with a 500 (Server Internal

   Error) response.  If the remote sequence number was not empty, and

   the sequence number of the request is greater than the remote

   sequence number, the request is in order.  It is possible for the

   CSeq sequence number to be higher than the remote sequence number by

   more than one.  This is not an error condition, and a UAS SHOULD be

   prepared to receive and process requests with CSeq values more than

   one higher than the previous received request.  The UAS MUST then set

   the remote sequence number to the value of the sequence number in the

   CSeq header field value in the request.



      If a proxy challenges a request generated by the UAC, the UAC has

      to resubmit the request with credentials.  The resubmitted request

      will have a new CSeq number.  The UAS will never see the first

      request, and thus, it will notice a gap in the CSeq number space.

      Such a gap does not represent any error condition.



   When a UAS receives a target refresh request, it MUST replace the

   dialog's remote target URI with the URI from the Contact header field

   in that request, if present.



12.3 Termination of a Dialog



   Independent of the method, if a request outside of a dialog generates

   a non-2xx final response, any early dialogs created through

   provisional responses to that request are terminated.  The mechanism

   for terminating confirmed dialogs is method specific.  In this

   specification, the BYE method terminates a session and the dialog

   associated with it.  See Section 15 for details.



13 Initiating a Session



13.1 Overview



   When a user agent client desires to initiate a session (for example,

   audio, video, or a game), it formulates an INVITE request.  The

   INVITE request asks a server to establish a session.  This request

   may be forwarded by proxies, eventually arriving at one or more UAS

   that can potentially accept the invitation.  These UASs will

   frequently need to query the user about whether to accept the







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   invitation.  After some time, those UASs can accept the invitation

   (meaning the session is to be established) by sending a 2xx response.

   If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is

   sent, depending on the reason for the rejection.  Before sending a

   final response, the UAS can also send provisional responses (1xx) to

   advise the UAC of progress in contacting the called user.



   After possibly receiving one or more provisional responses, the UAC

   will get one or more 2xx responses or one non-2xx final response.

   Because of the protracted amount of time it can take to receive final

   responses to INVITE, the reliability mechanisms for INVITE

   transactions differ from those of other requests (like OPTIONS).

   Once it receives a final response, the UAC needs to send an ACK for

   every final response it receives.  The procedure for sending this ACK

   depends on the type of response.  For final responses between 300 and

   699, the ACK processing is done in the transaction layer and follows

   one set of rules (See Section 17).  For 2xx responses, the ACK is

   generated by the UAC core.



   A 2xx response to an INVITE establishes a session, and it also

   creates a dialog between the UA that issued the INVITE and the UA

   that generated the 2xx response.  Therefore, when multiple 2xx

   responses are received from different remote UAs (because the INVITE

   forked), each 2xx establishes a different dialog.  All these dialogs

   are part of the same call.



   This section provides details on the establishment of a session using

   INVITE.  A UA that supports INVITE MUST also support ACK, CANCEL and

   BYE.



13.2 UAC Processing



13.2.1 Creating the Initial INVITE



   Since the initial INVITE represents a request outside of a dialog,

   its construction follows the procedures of Section 8.1.1.  Additional

   processing is required for the specific case of INVITE.



   An Allow header field (Section 20.5) SHOULD be present in the INVITE.

   It indicates what methods can be invoked within a dialog, on the UA

   sending the INVITE, for the duration of the dialog.  For example, a

   UA capable of receiving INFO requests within a dialog [34] SHOULD

   include an Allow header field listing the INFO method.



   A Supported header field (Section 20.37) SHOULD be present in the

   INVITE.  It enumerates all the extensions understood by the UAC.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   An Accept (Section 20.1) header field MAY be present in the INVITE.

   It indicates which Content-Types are acceptable to the UA, in both

   the response received by it, and in any subsequent requests sent to

   it within dialogs established by the INVITE.  The Accept header field

   is especially useful for indicating support of various session

   description formats.



   The UAC MAY add an Expires header field (Section 20.19) to limit the

   validity of the invitation.  If the time indicated in the Expires

   header field is reached and no final answer for the INVITE has been

   received, the UAC core SHOULD generate a CANCEL request for the

   INVITE, as per Section 9.



   A UAC MAY also find it useful to add, among others, Subject (Section

   20.36), Organization (Section 20.25) and User-Agent (Section 20.41)

   header fields.  They all contain information related to the INVITE.



   The UAC MAY choose to add a message body to the INVITE.  Section

   8.1.1.10 deals with how to construct the header fields -- Content-

   Type among others -- needed to describe the message body.



   There are special rules for message bodies that contain a session

   description - their corresponding Content-Disposition is "session".

   SIP uses an offer/answer model where one UA sends a session

   description, called the offer, which contains a proposed description

   of the session.  The offer indicates the desired communications means

   (audio, video, games), parameters of those means (such as codec

   types) and addresses for receiving media from the answerer.  The

   other UA responds with another session description, called the

   answer, which indicates which communications means are accepted, the

   parameters that apply to those means, and addresses for receiving

   media from the offerer. An offer/answer exchange is within the

   context of a dialog, so that if a SIP INVITE results in multiple

   dialogs, each is a separate offer/answer exchange.  The offer/answer

   model defines restrictions on when offers and answers can be made

   (for example, you cannot make a new offer while one is in progress).

   This results in restrictions on where the offers and answers can

   appear in SIP messages.  In this specification, offers and answers

   can only appear in INVITE requests and responses, and ACK.  The usage

   of offers and answers is further restricted.  For the initial INVITE

   transaction, the rules are:



      o  The initial offer MUST be in either an INVITE or, if not there,

         in the first reliable non-failure message from the UAS back to

         the UAC.  In this specification, that is the final 2xx

         response.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      o  If the initial offer is in an INVITE, the answer MUST be in a

         reliable non-failure message from UAS back to UAC which is

         correlated to that INVITE.  For this specification, that is

         only the final 2xx response to that INVITE.  That same exact

         answer MAY also be placed in any provisional responses sent

         prior to the answer.  The UAC MUST treat the first session

         description it receives as the answer, and MUST ignore any

         session descriptions in subsequent responses to the initial

         INVITE.



      o  If the initial offer is in the first reliable non-failure

         message from the UAS back to UAC, the answer MUST be in the

         acknowledgement for that message (in this specification, ACK

         for a 2xx response).



      o  After having sent or received an answer to the first offer, the

         UAC MAY generate subsequent offers in requests based on rules

         specified for that method, but only if it has received answers

         to any previous offers, and has not sent any offers to which it

         hasn't gotten an answer.



      o  Once the UAS has sent or received an answer to the initial

         offer, it MUST NOT generate subsequent offers in any responses

         to the initial INVITE.  This means that a UAS based on this

         specification alone can never generate subsequent offers until

         completion of the initial transaction.



   Concretely, the above rules specify two exchanges for UAs compliant

   to this specification alone - the offer is in the INVITE, and the

   answer in the 2xx (and possibly in a 1xx as well, with the same

   value), or the offer is in the 2xx, and the answer is in the ACK.

   All user agents that support INVITE MUST support these two exchanges.



   The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be

   supported by all user agents as a means to describe sessions, and its

   usage for constructing offers and answers MUST follow the procedures

   defined in [13].



   The restrictions of the offer-answer model just described only apply

   to bodies whose Content-Disposition header field value is "session".

   Therefore, it is possible that both the INVITE and the ACK contain a

   body message (for example, the INVITE carries a photo (Content-

   Disposition: render) and the ACK a session description (Content-

   Disposition: session)).



   If the Content-Disposition header field is missing, bodies of

   Content-Type application/sdp imply the disposition "session", while

   other content types imply "render".







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Once the INVITE has been created, the UAC follows the procedures

   defined for sending requests outside of a dialog (Section 8).  This

   results in the construction of a client transaction that will

   ultimately send the request and deliver responses to the UAC.



13.2.2 Processing INVITE Responses



   Once the INVITE has been passed to the INVITE client transaction, the

   UAC waits for responses for the INVITE.  If the INVITE client

   transaction returns a timeout rather than a response the TU acts as

   if a 408 (Request Timeout) response had been received, as described

   in Section 8.1.3.



13.2.2.1 1xx Responses



   Zero, one or multiple provisional responses may arrive before one or

   more final responses are received.  Provisional responses for an

   INVITE request can create "early dialogs".  If a provisional response

   has a tag in the To field, and if the dialog ID of the response does

   not match an existing dialog, one is constructed using the procedures

   defined in Section 12.1.2.



   The early dialog will only be needed if the UAC needs to send a

   request to its peer within the dialog before the initial INVITE

   transaction completes.  Header fields present in a provisional

   response are applicable as long as the dialog is in the early state

   (for example, an Allow header field in a provisional response

   contains the methods that can be used in the dialog while this is in

   the early state).



13.2.2.2 3xx Responses



   A 3xx response may contain one or more Contact header field values

   providing new addresses where the callee might be reachable.

   Depending on the status code of the 3xx response (see Section 21.3),

   the UAC MAY choose to try those new addresses.



13.2.2.3 4xx, 5xx and 6xx Responses



   A single non-2xx final response may be received for the INVITE.  4xx,

   5xx and 6xx responses may contain a Contact header field value

   indicating the location where additional information about the error

   can be found.  Subsequent final responses (which would only arrive

   under error conditions) MUST be ignored.



   All early dialogs are considered terminated upon reception of the

   non-2xx final response.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   After having received the non-2xx final response the UAC core

   considers the INVITE transaction completed.  The INVITE client

   transaction handles the generation of ACKs for the response (see

   Section 17).



13.2.2.4 2xx Responses



   Multiple 2xx responses may arrive at the UAC for a single INVITE

   request due to a forking proxy.  Each response is distinguished by

   the tag parameter in the To header field, and each represents a

   distinct dialog, with a distinct dialog identifier.



   If the dialog identifier in the 2xx response matches the dialog

   identifier of an existing dialog, the dialog MUST be transitioned to

   the "confirmed" state, and the route set for the dialog MUST be

   recomputed based on the 2xx response using the procedures of Section

   12.2.1.2.  Otherwise, a new dialog in the "confirmed" state MUST be

   constructed using the procedures of Section 12.1.2.



      Note that the only piece of state that is recomputed is the route

      set.  Other pieces of state such as the highest sequence numbers

      (remote and local) sent within the dialog are not recomputed.  The

      route set only is recomputed for backwards compatibility.  RFC

      2543 did not mandate mirroring of the Record-Route header field in

      a 1xx, only 2xx.  However, we cannot update the entire state of

      the dialog, since mid-dialog requests may have been sent within

      the early dialog, modifying the sequence numbers, for example.



   The UAC core MUST generate an ACK request for each 2xx received from

   the transaction layer.  The header fields of the ACK are constructed

   in the same way as for any request sent within a dialog (see Section

   12) with the exception of the CSeq and the header fields related to

   authentication.  The sequence number of the CSeq header field MUST be

   the same as the INVITE being acknowledged, but the CSeq method MUST

   be ACK.  The ACK MUST contain the same credentials as the INVITE.  If

   the 2xx contains an offer (based on the rules above), the ACK MUST

   carry an answer in its body.  If the offer in the 2xx response is not

   acceptable, the UAC core MUST generate a valid answer in the ACK and

   then send a BYE immediately.



   Once the ACK has been constructed, the procedures of [4] are used to

   determine the destination address, port and transport.  However, the

   request is passed to the transport layer directly for transmission,

   rather than a client transaction.  This is because the UAC core

   handles retransmissions of the ACK, not the transaction layer.  The

   ACK MUST be passed to the client transport every time a

   retransmission of the 2xx final response that triggered the ACK

   arrives.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The UAC core considers the INVITE transaction completed 64*T1 seconds

   after the reception of the first 2xx response.  At this point all the

   early dialogs that have not transitioned to established dialogs are

   terminated.  Once the INVITE transaction is considered completed by

   the UAC core, no more new 2xx responses are expected to arrive.



   If, after acknowledging any 2xx response to an INVITE, the UAC does

   not want to continue with that dialog, then the UAC MUST terminate

   the dialog by sending a BYE request as described in Section 15.



13.3 UAS Processing



13.3.1 Processing of the INVITE



   The UAS core will receive INVITE requests from the transaction layer.

   It first performs the request processing procedures of Section 8.2,

   which are applied for both requests inside and outside of a dialog.



   Assuming these processing states are completed without generating a

   response, the UAS core performs the additional processing steps:



      1. If the request is an INVITE that contains an Expires header

         field, the UAS core sets a timer for the number of seconds

         indicated in the header field value.  When the timer fires, the

         invitation is considered to be expired.  If the invitation

         expires before the UAS has generated a final response, a 487

         (Request Terminated) response SHOULD be generated.



      2. If the request is a mid-dialog request, the method-independent

         processing described in Section 12.2.2 is first applied.  It

         might also modify the session; Section 14 provides details.



      3. If the request has a tag in the To header field but the dialog

         identifier does not match any of the existing dialogs, the UAS

         may have crashed and restarted, or may have received a request

         for a different (possibly failed) UAS.  Section 12.2.2 provides

         guidelines to achieve a robust behavior under such a situation.



   Processing from here forward assumes that the INVITE is outside of a

   dialog, and is thus for the purposes of establishing a new session.



   The INVITE may contain a session description, in which case the UAS

   is being presented with an offer for that session.  It is possible

   that the user is already a participant in that session, even though

   the INVITE is outside of a dialog.  This can happen when a user is

   invited to the same multicast conference by multiple other

   participants.  If desired, the UAS MAY use identifiers within the

   session description to detect this duplication.  For example, SDP







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   contains a session id and version number in the origin (o) field.  If

   the user is already a member of the session, and the session

   parameters contained in the session description have not changed, the

   UAS MAY silently accept the INVITE (that is, send a 2xx response

   without prompting the user).



   If the INVITE does not contain a session description, the UAS is

   being asked to participate in a session, and the UAC has asked that

   the UAS provide the offer of the session.  It MUST provide the offer

   in its first non-failure reliable message back to the UAC.  In this

   specification, that is a 2xx response to the INVITE.



   The UAS can indicate progress, accept, redirect, or reject the

   invitation.  In all of these cases, it formulates a response using

   the procedures described in Section 8.2.6.



13.3.1.1 Progress



   If the UAS is not able to answer the invitation immediately, it can

   choose to indicate some kind of progress to the UAC (for example, an

   indication that a phone is ringing).  This is accomplished with a

   provisional response between 101 and 199.  These provisional

   responses establish early dialogs and therefore follow the procedures

   of Section 12.1.1 in addition to those of Section 8.2.6.  A UAS MAY

   send as many provisional responses as it likes.  Each of these MUST

   indicate the same dialog ID.  However, these will not be delivered

   reliably.



   If the UAS desires an extended period of time to answer the INVITE,

   it will need to ask for an "extension" in order to prevent proxies

   from canceling the transaction.  A proxy has the option of canceling

   a transaction when there is a gap of 3 minutes between responses in a

   transaction.  To prevent cancellation, the UAS MUST send a non-100

   provisional response at every minute, to handle the possibility of

   lost provisional responses.



      An INVITE transaction can go on for extended durations when the

      user is placed on hold, or when interworking with PSTN systems

      which allow communications to take place without answering the

      call.  The latter is common in Interactive Voice Response (IVR)

      systems.



13.3.1.2 The INVITE is Redirected



   If the UAS decides to redirect the call, a 3xx response is sent.  A

   300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved

   Temporarily) response SHOULD contain a Contact header field









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   containing one or more URIs of new addresses to be tried.  The

   response is passed to the INVITE server transaction, which will deal

   with its retransmissions.



13.3.1.3 The INVITE is Rejected



   A common scenario occurs when the callee is currently not willing or

   able to take additional calls at this end system.  A 486 (Busy Here)

   SHOULD be returned in such a scenario.  If the UAS knows that no

   other end system will be able to accept this call, a 600 (Busy

   Everywhere) response SHOULD be sent instead.  However, it is unlikely

   that a UAS will be able to know this in general, and thus this

   response will not usually be used.  The response is passed to the

   INVITE server transaction, which will deal with its retransmissions.



   A UAS rejecting an offer contained in an INVITE SHOULD return a 488

   (Not Acceptable Here) response.  Such a response SHOULD include a

   Warning header field value explaining why the offer was rejected.



13.3.1.4 The INVITE is Accepted



   The UAS core generates a 2xx response.  This response establishes a

   dialog, and therefore follows the procedures of Section 12.1.1 in

   addition to those of Section 8.2.6.



   A 2xx response to an INVITE SHOULD contain the Allow header field and

   the Supported header field, and MAY contain the Accept header field.

   Including these header fields allows the UAC to determine the

   features and extensions supported by the UAS for the duration of the

   call, without probing.



   If the INVITE request contained an offer, and the UAS had not yet

   sent an answer, the 2xx MUST contain an answer.  If the INVITE did

   not contain an offer, the 2xx MUST contain an offer if the UAS had

   not yet sent an offer.



   Once the response has been constructed, it is passed to the INVITE

   server transaction.  Note, however, that the INVITE server

   transaction will be destroyed as soon as it receives this final

   response and passes it to the transport.  Therefore, it is necessary

   to periodically pass the response directly to the transport until the

   ACK arrives.  The 2xx response is passed to the transport with an

   interval that starts at T1 seconds and doubles for each

   retransmission until it reaches T2 seconds (T1 and T2 are defined in

   Section 17).  Response retransmissions cease when an ACK request for

   the response is received.  This is independent of whatever transport

   protocols are used to send the response.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      Since 2xx is retransmitted end-to-end, there may be hops between

      UAS and UAC that are UDP.  To ensure reliable delivery across

      these hops, the response is retransmitted periodically even if the

      transport at the UAS is reliable.



   If the server retransmits the 2xx response for 64*T1 seconds without

   receiving an ACK, the dialog is confirmed, but the session SHOULD be

   terminated.  This is accomplished with a BYE, as described in Section

   15.



14 Modifying an Existing Session



   A successful INVITE request (see Section 13) establishes both a

   dialog between two user agents and a session using the offer-answer

   model.  Section 12 explains how to modify an existing dialog using a

   target refresh request (for example, changing the remote target URI

   of the dialog).  This section describes how to modify the actual

   session.  This modification can involve changing addresses or ports,

   adding a media stream, deleting a media stream, and so on.  This is

   accomplished by sending a new INVITE request within the same dialog

   that established the session.  An INVITE request sent within an

   existing dialog is known as a re-INVITE.



      Note that a single re-INVITE can modify the dialog and the

      parameters of the session at the same time.



   Either the caller or callee can modify an existing session.



   The behavior of a UA on detection of media failure is a matter of

   local policy.  However, automated generation of re-INVITE or BYE is

   NOT RECOMMENDED to avoid flooding the network with traffic when there

   is congestion.  In any case, if these messages are sent

   automatically, they SHOULD be sent after some randomized interval.



      Note that the paragraph above refers to automatically generated

      BYEs and re-INVITEs.  If the user hangs up upon media failure, the

      UA would send a BYE request as usual.



14.1 UAC Behavior



   The same offer-answer model that applies to session descriptions in

   INVITEs (Section 13.2.1) applies to re-INVITEs.  As a result, a UAC

   that wants to add a media stream, for example, will create a new

   offer that contains this media stream, and send that in an INVITE

   request to its peer.  It is important to note that the full

   description of the session, not just the change, is sent.  This

   supports stateless session processing in various elements, and

   supports failover and recovery capabilities.  Of course, a UAC MAY







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   send a re-INVITE with no session description, in which case the first

   reliable non-failure response to the re-INVITE will contain the offer

   (in this specification, that is a 2xx response).



   If the session description format has the capability for version

   numbers, the offerer SHOULD indicate that the version of the session

   description has changed.



   The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set

   following the same rules as for regular requests within an existing

   dialog, described in Section 12.



   A UAC MAY choose not to add an Alert-Info header field or a body with

   Content-Disposition "alert" to re-INVITEs because UASs do not

   typically alert the user upon reception of a re-INVITE.



   Unlike an INVITE, which can fork, a re-INVITE will never fork, and

   therefore, only ever generate a single final response.  The reason a

   re-INVITE will never fork is that the Request-URI identifies the

   target as the UA instance it established the dialog with, rather than

   identifying an address-of-record for the user.



   Note that a UAC MUST NOT initiate a new INVITE transaction within a

   dialog while another INVITE transaction is in progress in either

   direction.



      1. If there is an ongoing INVITE client transaction, the TU MUST

         wait until the transaction reaches the completed or terminated

         state before initiating the new INVITE.



      2. If there is an ongoing INVITE server transaction, the TU MUST

         wait until the transaction reaches the confirmed or terminated

         state before initiating the new INVITE.



   However, a UA MAY initiate a regular transaction while an INVITE

   transaction is in progress.  A UA MAY also initiate an INVITE

   transaction while a regular transaction is in progress.



   If a UA receives a non-2xx final response to a re-INVITE, the session

   parameters MUST remain unchanged, as if no re-INVITE had been issued.

   Note that, as stated in Section 12.2.1.2, if the non-2xx final

   response is a 481 (Call/Transaction Does Not Exist), or a 408

   (Request Timeout), or no response at all is received for the re-

   INVITE (that is, a timeout is returned by the INVITE client

   transaction), the UAC will terminate the dialog.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   If a UAC receives a 491 response to a re-INVITE, it SHOULD start a

   timer with a value T chosen as follows:



      1. If the UAC is the owner of the Call-ID of the dialog ID

         (meaning it generated the value), T has a randomly chosen value

         between 2.1 and 4 seconds in units of 10 ms.



      2. If the UAC is not the owner of the Call-ID of the dialog ID, T

         has a randomly chosen value of between 0 and 2 seconds in units

         of 10 ms.



   When the timer fires, the UAC SHOULD attempt the re-INVITE once more,

   if it still desires for that session modification to take place.  For

   example, if the call was already hung up with a BYE, the re-INVITE

   would not take place.



   The rules for transmitting a re-INVITE and for generating an ACK for

   a 2xx response to re-INVITE are the same as for the initial INVITE

   (Section 13.2.1).



14.2 UAS Behavior



   Section 13.3.1 describes the procedure for distinguishing incoming

   re-INVITEs from incoming initial INVITEs and handling a re-INVITE for

   an existing dialog.



   A UAS that receives a second INVITE before it sends the final

   response to a first INVITE with a lower CSeq sequence number on the

   same dialog MUST return a 500 (Server Internal Error) response to the

   second INVITE and MUST include a Retry-After header field with a

   randomly chosen value of between 0 and 10 seconds.



   A UAS that receives an INVITE on a dialog while an INVITE it had sent

   on that dialog is in progress MUST return a 491 (Request Pending)

   response to the received INVITE.



   If a UA receives a re-INVITE for an existing dialog, it MUST check

   any version identifiers in the session description or, if there are

   no version identifiers, the content of the session description to see

   if it has changed.  If the session description has changed, the UAS

   MUST adjust the session parameters accordingly, possibly after asking

   the user for confirmation.



      Versioning of the session description can be used to accommodate

      the capabilities of new arrivals to a conference, add or delete

      media, or change from a unicast to a multicast conference.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   If the new session description is not acceptable, the UAS can reject

   it by returning a 488 (Not Acceptable Here) response for the re-

   INVITE.  This response SHOULD include a Warning header field.



   If a UAS generates a 2xx response and never receives an ACK, it

   SHOULD generate a BYE to terminate the dialog.



   A UAS MAY choose not to generate 180 (Ringing) responses for a re-

   INVITE because UACs do not typically render this information to the

   user.  For the same reason, UASs MAY choose not to use an Alert-Info

   header field or a body with Content-Disposition "alert" in responses

   to a re-INVITE.



   A UAS providing an offer in a 2xx (because the INVITE did not contain

   an offer) SHOULD construct the offer as if the UAS were making a

   brand new call, subject to the constraints of sending an offer that

   updates an existing session, as described in [13] in the case of SDP.

   Specifically, this means that it SHOULD include as many media formats

   and media types that the UA is willing to support.  The UAS MUST

   ensure that the session description overlaps with its previous

   session description in media formats, transports, or other parameters

   that require support from the peer.  This is to avoid the need for

   the peer to reject the session description.  If, however, it is

   unacceptable to the UAC, the UAC SHOULD generate an answer with a

   valid session description, and then send a BYE to terminate the

   session.



15 Terminating a Session



   This section describes the procedures for terminating a session

   established by SIP.  The state of the session and the state of the

   dialog are very closely related.  When a session is initiated with an

   INVITE, each 1xx or 2xx response from a distinct UAS creates a

   dialog, and if that response completes the offer/answer exchange, it

   also creates a session.  As a result, each session is "associated"

   with a single dialog - the one which resulted in its creation.  If an

   initial INVITE generates a non-2xx final response, that terminates

   all sessions (if any) and all dialogs (if any) that were created

   through responses to the request.  By virtue of completing the

   transaction, a non-2xx final response also prevents further sessions

   from being created as a result of the INVITE.  The BYE request is

   used to terminate a specific session or attempted session.  In this

   case, the specific session is the one with the peer UA on the other

   side of the dialog.  When a BYE is received on a dialog, any session

   associated with that dialog SHOULD terminate.  A UA MUST NOT send a

   BYE outside of a dialog.  The caller's UA MAY send a BYE for either

   confirmed or early dialogs, and the callee's UA MAY send a BYE on

   confirmed dialogs, but MUST NOT send a BYE on early dialogs.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   However, the callee's UA MUST NOT send a BYE on a confirmed dialog

   until it has received an ACK for its 2xx response or until the server

   transaction times out.  If no SIP extensions have defined other

   application layer states associated with the dialog, the BYE also

   terminates the dialog.



   The impact of a non-2xx final response to INVITE on dialogs and

   sessions makes the use of CANCEL attractive.  The CANCEL attempts to

   force a non-2xx response to the INVITE (in particular, a 487).

   Therefore, if a UAC wishes to give up on its call attempt entirely,

   it can send a CANCEL.  If the INVITE results in 2xx final response(s)

   to the INVITE, this means that a UAS accepted the invitation while

   the CANCEL was in progress.  The UAC MAY continue with the sessions

   established by any 2xx responses, or MAY terminate them with BYE.



      The notion of "hanging up" is not well defined within SIP.  It is

      specific to a particular, albeit common, user interface.

      Typically, when the user hangs up, it indicates a desire to

      terminate the attempt to establish a session, and to terminate any

      sessions already created.  For the caller's UA, this would imply a

      CANCEL request if the initial INVITE has not generated a final

      response, and a BYE to all confirmed dialogs after a final

      response.  For the callee's UA, it would typically imply a BYE;

      presumably, when the user picked up the phone, a 2xx was

      generated, and so hanging up would result in a BYE after the ACK

      is received.  This does not mean a user cannot hang up before

      receipt of the ACK, it just means that the software in his phone

      needs to maintain state for a short while in order to clean up

      properly.  If the particular UI allows for the user to reject a

      call before its answered, a 403 (Forbidden) is a good way to

      express that.  As per the rules above, a BYE can't be sent.



15.1 Terminating a Session with a BYE Request



15.1.1 UAC Behavior



   A BYE request is constructed as would any other request within a

   dialog, as described in Section 12.



   Once the BYE is constructed, the UAC core creates a new non-INVITE

   client transaction, and passes it the BYE request.  The UAC MUST

   consider the session terminated (and therefore stop sending or

   listening for media) as soon as the BYE request is passed to the

   client transaction.  If the response for the BYE is a 481

   (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   response at all is received for the BYE (that is, a timeout is

   returned by the client transaction), the UAC MUST consider the

   session and the dialog terminated.



15.1.2 UAS Behavior



   A UAS first processes the BYE request according to the general UAS

   processing described in Section 8.2.  A UAS core receiving a BYE

   request checks if it matches an existing dialog.  If the BYE does not

   match an existing dialog, the UAS core SHOULD generate a 481

   (Call/Transaction Does Not Exist) response and pass that to the

   server transaction.



      This rule means that a BYE sent without tags by a UAC will be

      rejected.  This is a change from RFC 2543, which allowed BYE

      without tags.



   A UAS core receiving a BYE request for an existing dialog MUST follow

   the procedures of Section 12.2.2 to process the request.  Once done,

   the UAS SHOULD terminate the session (and therefore stop sending and

   listening for media).  The only case where it can elect not to are

   multicast sessions, where participation is possible even if the other

   participant in the dialog has terminated its involvement in the

   session.  Whether or not it ends its participation on the session,

   the UAS core MUST generate a 2xx response to the BYE, and MUST pass

   that to the server transaction for transmission.



   The UAS MUST still respond to any pending requests received for that

   dialog.  It is RECOMMENDED that a 487 (Request Terminated) response

   be generated to those pending requests.



16 Proxy Behavior



16.1 Overview



   SIP proxies are elements that route SIP requests to user agent

   servers and SIP responses to user agent clients.  A request may

   traverse several proxies on its way to a UAS.  Each will make routing

   decisions, modifying the request before forwarding it to the next

   element.  Responses will route through the same set of proxies

   traversed by the request in the reverse order.



   Being a proxy is a logical role for a SIP element.  When a request

   arrives, an element that can play the role of a proxy first decides

   if it needs to respond to the request on its own.  For instance, the

   request may be malformed or the element may need credentials from the

   client before acting as a proxy.  The element MAY respond with any









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   appropriate error code.  When responding directly to a request, the

   element is playing the role of a UAS and MUST behave as described in

   Section 8.2.



   A proxy can operate in either a stateful or stateless mode for each

   new request.  When stateless, a proxy acts as a simple forwarding

   element.  It forwards each request downstream to a single element

   determined by making a targeting and routing decision based on the

   request.  It simply forwards every response it receives upstream.  A

   stateless proxy discards information about a message once the message

   has been forwarded.  A stateful proxy remembers information

   (specifically, transaction state) about each incoming request and any

   requests it sends as a result of processing the incoming request.  It

   uses this information to affect the processing of future messages

   associated with that request.  A stateful proxy MAY choose to "fork"

   a request, routing it to multiple destinations.  Any request that is

   forwarded to more than one location MUST be handled statefully.



   In some circumstances, a proxy MAY forward requests using stateful

   transports (such as TCP) without being transaction-stateful.  For

   instance, a proxy MAY forward a request from one TCP connection to

   another transaction statelessly as long as it places enough

   information in the message to be able to forward the response down

   the same connection the request arrived on.  Requests forwarded

   between different types of transports where the proxy's TU must take

   an active role in ensuring reliable delivery on one of the transports

   MUST be forwarded transaction statefully.



   A stateful proxy MAY transition to stateless operation at any time

   during the processing of a request, so long as it did not do anything

   that would otherwise prevent it from being stateless initially

   (forking, for example, or generation of a 100 response).  When

   performing such a transition, all state is simply discarded.  The

   proxy SHOULD NOT initiate a CANCEL request.



   Much of the processing involved when acting statelessly or statefully

   for a request is identical.  The next several subsections are written

   from the point of view of a stateful proxy.  The last section calls

   out those places where a stateless proxy behaves differently.



16.2 Stateful Proxy



   When stateful, a proxy is purely a SIP transaction processing engine.

   Its behavior is modeled here in terms of the server and client

   transactions defined in Section 17.  A stateful proxy has a server

   transaction associated with one or more client transactions by a

   higher layer proxy processing component (see figure 3), known as a

   proxy core.  An incoming request is processed by a server







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   transaction.  Requests from the server transaction are passed to a

   proxy core.  The proxy core determines where to route the request,

   choosing one or more next-hop locations.  An outgoing request for

   each next-hop location is processed by its own associated client

   transaction.  The proxy core collects the responses from the client

   transactions and uses them to send responses to the server

   transaction.



   A stateful proxy creates a new server transaction for each new

   request received.  Any retransmissions of the request will then be

   handled by that server transaction per Section 17.  The proxy core

   MUST behave as a UAS with respect to sending an immediate provisional

   on that server transaction (such as 100 Trying) as described in

   Section 8.2.6.  Thus, a stateful proxy SHOULD NOT generate 100

   (Trying) responses to non-INVITE requests.



   This is a model of proxy behavior, not of software.  An

   implementation is free to take any approach that replicates the

   external behavior this model defines.



   For all new requests, including any with unknown methods, an element

   intending to proxy the request MUST:



      1. Validate the request (Section 16.3)



      2. Preprocess routing information (Section 16.4)



      3. Determine target(s) for the request (Section 16.5)



            +--------------------+

            |                    | +---+

            |                    | | C |

            |                    | | T |

            |                    | +---+

      +---+ |       Proxy        | +---+   CT = Client Transaction

      | S | |  "Higher" Layer    | | C |

      | T | |                    | | T |   ST = Server Transaction

      +---+ |                    | +---+

            |                    | +---+

            |                    | | C |

            |                    | | T |

            |                    | +---+

            +--------------------+



               Figure 3: Stateful Proxy Model













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      4. Forward the request to each target (Section 16.6)



      5. Process all responses (Section 16.7)



16.3 Request Validation



   Before an element can proxy a request, it MUST verify the message's

   validity.  A valid message must pass the following checks:



      1. Reasonable Syntax



      2. URI scheme



      3. Max-Forwards



      4. (Optional) Loop Detection



      5. Proxy-Require



      6. Proxy-Authorization



   If any of these checks fail, the element MUST behave as a user agent

   server (see Section 8.2) and respond with an error code.



   Notice that a proxy is not required to detect merged requests and

   MUST NOT treat merged requests as an error condition.  The endpoints

   receiving the requests will resolve the merge as described in Section

   8.2.2.2.



   1. Reasonable syntax check



      The request MUST be well-formed enough to be handled with a server

      transaction.  Any components involved in the remainder of these

      Request Validation steps or the Request Forwarding section MUST be

      well-formed.  Any other components, well-formed or not, SHOULD be

      ignored and remain unchanged when the message is forwarded.  For

      instance, an element would not reject a request because of a

      malformed Date header field.  Likewise, a proxy would not remove a

      malformed Date header field before forwarding a request.



      This protocol is designed to be extended.  Future extensions may

      define new methods and header fields at any time.  An element MUST

      NOT refuse to proxy a request because it contains a method or

      header field it does not know about.















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   2. URI scheme check



      If the Request-URI has a URI whose scheme is not understood by the

      proxy, the proxy SHOULD reject the request with a 416 (Unsupported

      URI Scheme) response.



   3. Max-Forwards check



      The Max-Forwards header field (Section 20.22) is used to limit the

      number of elements a SIP request can traverse.



      If the request does not contain a Max-Forwards header field, this

      check is passed.



      If the request contains a Max-Forwards header field with a field

      value greater than zero, the check is passed.



      If the request contains a Max-Forwards header field with a field

      value of zero (0), the element MUST NOT forward the request.  If

      the request was for OPTIONS, the element MAY act as the final

      recipient and respond per Section 11.  Otherwise, the element MUST

      return a 483 (Too many hops) response.



   4. Optional Loop Detection check



      An element MAY check for forwarding loops before forwarding a

      request.  If the request contains a Via header field with a sent-

      by value that equals a value placed into previous requests by the

      proxy, the request has been forwarded by this element before.  The

      request has either looped or is legitimately spiraling through the

      element.  To determine if the request has looped, the element MAY

      perform the branch parameter calculation described in Step 8 of

      Section 16.6 on this message and compare it to the parameter

      received in that Via header field.  If the parameters match, the

      request has looped.  If they differ, the request is spiraling, and

      processing continues.  If a loop is detected, the element MAY

      return a 482 (Loop Detected) response.



   5. Proxy-Require check



      Future extensions to this protocol may introduce features that

      require special handling by proxies.  Endpoints will include a

      Proxy-Require header field in requests that use these features,

      telling the proxy not to process the request unless the feature is

      understood.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      If the request contains a Proxy-Require header field (Section

      20.29) with one or more option-tags this element does not

      understand, the element MUST return a 420 (Bad Extension)

      response.  The response MUST include an Unsupported (Section

      20.40) header field listing those option-tags the element did not

      understand.



   6. Proxy-Authorization check



      If an element requires credentials before forwarding a request,

      the request MUST be inspected as described in Section 22.3.  That

      section also defines what the element must do if the inspection

      fails.



16.4 Route Information Preprocessing



   The proxy MUST inspect the Request-URI of the request.  If the

   Request-URI of the request contains a value this proxy previously

   placed into a Record-Route header field (see Section 16.6 item 4),

   the proxy MUST replace the Request-URI in the request with the last

   value from the Route header field, and remove that value from the

   Route header field.  The proxy MUST then proceed as if it received

   this modified request.



      This will only happen when the element sending the request to the

      proxy (which may have been an endpoint) is a strict router.  This

      rewrite on receive is necessary to enable backwards compatibility

      with those elements.  It also allows elements following this

      specification to preserve the Request-URI through strict-routing

      proxies (see Section 12.2.1.1).



      This requirement does not obligate a proxy to keep state in order

      to detect URIs it previously placed in Record-Route header fields.

      Instead, a proxy need only place enough information in those URIs

      to recognize them as values it provided when they later appear.



   If the Request-URI contains a maddr parameter, the proxy MUST check

   to see if its value is in the set of addresses or domains the proxy

   is configured to be responsible for.  If the Request-URI has a maddr

   parameter with a value the proxy is responsible for, and the request

   was received using the port and transport indicated (explicitly or by

   default) in the Request-URI, the proxy MUST strip the maddr and any

   non-default port or transport parameter and continue processing as if

   those values had not been present in the request.















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      A request may arrive with a maddr matching the proxy, but on a

      port or transport different from that indicated in the URI.  Such

      a request needs to be forwarded to the proxy using the indicated

      port and transport.



   If the first value in the Route header field indicates this proxy,

   the proxy MUST remove that value from the request.



16.5 Determining Request Targets



   Next, the proxy calculates the target(s) of the request.  The set of

   targets will either be predetermined by the contents of the request

   or will be obtained from an abstract location service.  Each target

   in the set is represented as a URI.



   If the Request-URI of the request contains an maddr parameter, the

   Request-URI MUST be placed into the target set as the only target

   URI, and the proxy MUST proceed to Section 16.6.



   If the domain of the Request-URI indicates a domain this element is

   not responsible for, the Request-URI MUST be placed into the target

   set as the only target, and the element MUST proceed to the task of

   Request Forwarding (Section 16.6).



      There are many circumstances in which a proxy might receive a

      request for a domain it is not responsible for.  A firewall proxy

      handling outgoing calls (the way HTTP proxies handle outgoing

      requests) is an example of where this is likely to occur.



   If the target set for the request has not been predetermined as

   described above, this implies that the element is responsible for the

   domain in the Request-URI, and the element MAY use whatever mechanism

   it desires to determine where to send the request.  Any of these

   mechanisms can be modeled as accessing an abstract Location Service.

   This may consist of obtaining information from a location service

   created by a SIP Registrar, reading a database, consulting a presence

   server, utilizing other protocols, or simply performing an

   algorithmic substitution on the Request-URI.  When accessing the

   location service constructed by a registrar, the Request-URI MUST

   first be canonicalized as described in Section 10.3 before being used

   as an index.  The output of these mechanisms is used to construct the

   target set.



   If the Request-URI does not provide sufficient information for the

   proxy to determine the target set, it SHOULD return a 485 (Ambiguous)

   response.  This response SHOULD contain a Contact header field

   containing URIs of new addresses to be tried.  For example, an INVITE









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   to sip:John.Smith@company.com may be ambiguous at a proxy whose

   location service has multiple John Smiths listed.  See Section

   21.4.23 for details.



   Any information in or about the request or the current environment of

   the element MAY be used in the construction of the target set.  For

   instance, different sets may be constructed depending on contents or

   the presence of header fields and bodies, the time of day of the

   request's arrival, the interface on which the request arrived,

   failure of previous requests, or even the element's current level of

   utilization.



   As potential targets are located through these services, their URIs

   are added to the target set.  Targets can only be placed in the

   target set once.  If a target URI is already present in the set

   (based on the definition of equality for the URI type), it MUST NOT

   be added again.



   A proxy MUST NOT add additional targets to the target set if the

   Request-URI of the original request does not indicate a resource this

   proxy is responsible for.



      A proxy can only change the Request-URI of a request during

      forwarding if it is responsible for that URI.  If the proxy is not

      responsible for that URI, it will not recurse on 3xx or 416

      responses as described below.



   If the Request-URI of the original request indicates a resource this

   proxy is responsible for, the proxy MAY continue to add targets to

   the set after beginning Request Forwarding.  It MAY use any

   information obtained during that processing to determine new targets.

   For instance, a proxy may choose to incorporate contacts obtained in

   a redirect response (3xx) into the target set.  If a proxy uses a

   dynamic source of information while building the target set (for

   instance, if it consults a SIP Registrar), it SHOULD monitor that

   source for the duration of processing the request.  New locations

   SHOULD be added to the target set as they become available.  As

   above, any given URI MUST NOT be added to the set more than once.



      Allowing a URI to be added to the set only once reduces

      unnecessary network traffic, and in the case of incorporating

      contacts from redirect requests prevents infinite recursion.



   For example, a trivial location service is a "no-op", where the

   target URI is equal to the incoming request URI.  The request is sent

   to a specific next hop proxy for further processing.  During request











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   forwarding of Section 16.6, Item 6, the identity of that next hop,

   expressed as a SIP or SIPS URI, is inserted as the top-most Route

   header field value into the request.



   If the Request-URI indicates a resource at this proxy that does not

   exist, the proxy MUST return a 404 (Not Found) response.



   If the target set remains empty after applying all of the above, the

   proxy MUST return an error response, which SHOULD be the 480

   (Temporarily Unavailable) response.



16.6 Request Forwarding



   As soon as the target set is non-empty, a proxy MAY begin forwarding

   the request.  A stateful proxy MAY process the set in any order.  It

   MAY process multiple targets serially, allowing each client

   transaction to complete before starting the next.  It MAY start

   client transactions with every target in parallel.  It also MAY

   arbitrarily divide the set into groups, processing the groups

   serially and processing the targets in each group in parallel.



   A common ordering mechanism is to use the qvalue parameter of targets

   obtained from Contact header fields (see Section 20.10).  Targets are

   processed from highest qvalue to lowest.  Targets with equal qvalues

   may be processed in parallel.



   A stateful proxy must have a mechanism to maintain the target set as

   responses are received and associate the responses to each forwarded

   request with the original request.  For the purposes of this model,

   this mechanism is a "response context" created by the proxy layer

   before forwarding the first request.



   For each target, the proxy forwards the request following these

   steps:



      1.  Make a copy of the received request



      2.  Update the Request-URI



      3.  Update the Max-Forwards header field



      4.  Optionally add a Record-route header field value



      5.  Optionally add additional header fields



      6.  Postprocess routing information



      7.  Determine the next-hop address, port, and transport







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      8.  Add a Via header field value



      9.  Add a Content-Length header field if necessary



      10. Forward the new request



      11. Set timer C



   Each of these steps is detailed below:



      1. Copy request



         The proxy starts with a copy of the received request.  The copy

         MUST initially contain all of the header fields from the

         received request.  Fields not detailed in the processing

         described below MUST NOT be removed.  The copy SHOULD maintain

         the ordering of the header fields as in the received request.

         The proxy MUST NOT reorder field values with a common field

         name (See Section 7.3.1).  The proxy MUST NOT add to, modify,

         or remove the message body.



         An actual implementation need not perform a copy; the primary

         requirement is that the processing for each next hop begin with

         the same request.



      2. Request-URI



         The Request-URI in the copy's start line MUST be replaced with

         the URI for this target.  If the URI contains any parameters

         not allowed in a Request-URI, they MUST be removed.



         This is the essence of a proxy's role.  This is the mechanism

         through which a proxy routes a request toward its destination.



         In some circumstances, the received Request-URI is placed into

         the target set without being modified.  For that target, the

         replacement above is effectively a no-op.



      3. Max-Forwards



         If the copy contains a Max-Forwards header field, the proxy

         MUST decrement its value by one (1).



         If the copy does not contain a Max-Forwards header field, the

         proxy MUST add one with a field value, which SHOULD be 70.



         Some existing UAs will not provide a Max-Forwards header field

         in a request.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      4. Record-Route



         If this proxy wishes to remain on the path of future requests

         in a dialog created by this request (assuming the request

         creates a dialog), it MUST insert a Record-Route header field

         value into the copy before any existing Record-Route header

         field values, even if a Route header field is already present.



         Requests establishing a dialog may contain a preloaded Route

         header field.



         If this request is already part of a dialog, the proxy SHOULD

         insert a Record-Route header field value if it wishes to remain

         on the path of future requests in the dialog.  In normal

         endpoint operation as described in Section 12, these Record-

         Route header field values will not have any effect on the route

         sets used by the endpoints.



         The proxy will remain on the path if it chooses to not insert a

         Record-Route header field value into requests that are already

         part of a dialog.  However, it would be removed from the path

         when an endpoint that has failed reconstitutes the dialog.



         A proxy MAY insert a Record-Route header field value into any

         request.  If the request does not initiate a dialog, the

         endpoints will ignore the value.  See Section 12 for details on

         how endpoints use the Record-Route header field values to

         construct Route header fields.



         Each proxy in the path of a request chooses whether to add a

         Record-Route header field value independently - the presence of

         a Record-Route header field in a request does not obligate this

         proxy to add a value.



         The URI placed in the Record-Route header field value MUST be a

         SIP or SIPS URI.  This URI MUST contain an lr parameter (see

         Section 19.1.1).  This URI MAY be different for each

         destination the request is forwarded to.  The URI SHOULD NOT

         contain the transport parameter unless the proxy has knowledge

         (such as in a private network) that the next downstream element

         that will be in the path of subsequent requests supports that

         transport.



         The URI this proxy provides will be used by some other element

         to make a routing decision.  This proxy, in general, has no way

         of knowing the capabilities of that element, so it must

         restrict itself to the mandatory elements of a SIP

         implementation: SIP URIs and either the TCP or UDP transports.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         The URI placed in the Record-Route header field MUST resolve to

         the element inserting it (or a suitable stand-in) when the

         server location procedures of [4] are applied to it, so that

         subsequent requests reach the same SIP element.  If the

         Request-URI contains a SIPS URI, or the topmost Route header

         field value (after the post processing of bullet 6) contains a

         SIPS URI, the URI placed into the Record-Route header field

         MUST be a SIPS URI.  Furthermore, if the request was not

         received over TLS, the proxy MUST insert a Record-Route header

         field.  In a similar fashion, a proxy that receives a request

         over TLS, but generates a request without a SIPS URI in the

         Request-URI or topmost Route header field value (after the post

         processing of bullet 6), MUST insert a Record-Route header

         field that is not a SIPS URI.



         A proxy at a security perimeter must remain on the perimeter

         throughout the dialog.



         If the URI placed in the Record-Route header field needs to be

         rewritten when it passes back through in a response, the URI

         MUST be distinct enough to locate at that time.  (The request

         may spiral through this proxy, resulting in more than one

         Record-Route header field value being added).  Item 8 of

         Section 16.7 recommends a mechanism to make the URI

         sufficiently distinct.



         The proxy MAY include parameters in the Record-Route header

         field value.  These will be echoed in some responses to the

         request such as the 200 (OK) responses to INVITE.  Such

         parameters may be useful for keeping state in the message

         rather than the proxy.



         If a proxy needs to be in the path of any type of dialog (such

         as one straddling a firewall), it SHOULD add a Record-Route

         header field value to every request with a method it does not

         understand since that method may have dialog semantics.



         The URI a proxy places into a Record-Route header field is only

         valid for the lifetime of any dialog created by the transaction

         in which it occurs.  A dialog-stateful proxy, for example, MAY

         refuse to accept future requests with that value in the

         Request-URI after the dialog has terminated.  Non-dialog-

         stateful proxies, of course, have no concept of when the dialog

         has terminated, but they MAY encode enough information in the

         value to compare it against the dialog identifier of future

         requests and MAY reject requests not matching that information.

         Endpoints MUST NOT use a URI obtained from a Record-Route

         header field outside the dialog in which it was provided.  See







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         Section 12 for more information on an endpoint's use of

         Record-Route header fields.



         Record-routing may be required by certain services where the

         proxy needs to observe all messages in a dialog.  However, it

         slows down processing and impairs scalability and thus proxies

         should only record-route if required for a particular service.



         The Record-Route process is designed to work for any SIP

         request that initiates a dialog.  INVITE is the only such

         request in this specification, but extensions to the protocol

         MAY define others.



      5. Add Additional Header Fields



         The proxy MAY add any other appropriate header fields to the

         copy at this point.



      6. Postprocess routing information



         A proxy MAY have a local policy that mandates that a request

         visit a specific set of proxies before being delivered to the

         destination.  A proxy MUST ensure that all such proxies are

         loose routers.  Generally, this can only be known with

         certainty if the proxies are within the same administrative

         domain.  This set of proxies is represented by a set of URIs

         (each of which contains the lr parameter).  This set MUST be

         pushed into the Route header field of the copy ahead of any

         existing values, if present.  If the Route header field is

         absent, it MUST be added, containing that list of URIs.



         If the proxy has a local policy that mandates that the request

         visit one specific proxy, an alternative to pushing a Route

         value into the Route header field is to bypass the forwarding

         logic of item 10 below, and instead just send the request to

         the address, port, and transport for that specific proxy.  If

         the request has a Route header field, this alternative MUST NOT

         be used unless it is known that next hop proxy is a loose

         router.  Otherwise, this approach MAY be used, but the Route

         insertion mechanism above is preferred for its robustness,

         flexibility, generality and consistency of operation.

         Furthermore, if the Request-URI contains a SIPS URI, TLS MUST

         be used to communicate with that proxy.



         If the copy contains a Route header field, the proxy MUST

         inspect the URI in its first value.  If that URI does not

         contain an lr parameter, the proxy MUST modify the copy as

         follows:







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         -  The proxy MUST place the Request-URI into the Route header

            field as the last value.



         -  The proxy MUST then place the first Route header field value

            into the Request-URI and remove that value from the Route

            header field.



         Appending the Request-URI to the Route header field is part of

         a mechanism used to pass the information in that Request-URI

         through strict-routing elements.  "Popping" the first Route

         header field value into the Request-URI formats the message the

         way a strict-routing element expects to receive it (with its

         own URI in the Request-URI and the next location to visit in

         the first Route header field value).



      7. Determine Next-Hop Address, Port, and Transport



         The proxy MAY have a local policy to send the request to a

         specific IP address, port, and transport, independent of the

         values of the Route and Request-URI.  Such a policy MUST NOT be

         used if the proxy is not certain that the IP address, port, and

         transport correspond to a server that is a loose router.

         However, this mechanism for sending the request through a

         specific next hop is NOT RECOMMENDED; instead a Route header

         field should be used for that purpose as described above.



         In the absence of such an overriding mechanism, the proxy

         applies the procedures listed in [4] as follows to determine

         where to send the request.  If the proxy has reformatted the

         request to send to a strict-routing element as described in

         step 6 above, the proxy MUST apply those procedures to the

         Request-URI of the request.  Otherwise, the proxy MUST apply

         the procedures to the first value in the Route header field, if

         present, else the Request-URI.  The procedures will produce an

         ordered set of (address, port, transport) tuples.

         Independently of which URI is being used as input to the

         procedures of [4], if the Request-URI specifies a SIPS

         resource, the proxy MUST follow the procedures of [4] as if the

         input URI were a SIPS URI.



         As described in [4], the proxy MUST attempt to deliver the

         message to the first tuple in that set, and proceed through the

         set in order until the delivery attempt succeeds.



         For each tuple attempted, the proxy MUST format the message as

         appropriate for the tuple and send the request using a new

         client transaction as detailed in steps 8 through 10.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         Since each attempt uses a new client transaction, it represents

         a new branch.  Thus, the branch parameter provided with the Via

         header field inserted in step 8 MUST be different for each

         attempt.



         If the client transaction reports failure to send the request

         or a timeout from its state machine, the proxy continues to the

         next address in that ordered set.  If the ordered set is

         exhausted, the request cannot be forwarded to this element in

         the target set.  The proxy does not need to place anything in

         the response context, but otherwise acts as if this element of

         the target set returned a 408 (Request Timeout) final response.



      8. Add a Via header field value



         The proxy MUST insert a Via header field value into the copy

         before the existing Via header field values.  The construction

         of this value follows the same guidelines of Section 8.1.1.7.

         This implies that the proxy will compute its own branch

         parameter, which will be globally unique for that branch, and

         contain the requisite magic cookie. Note that this implies that

         the branch parameter will be different for different instances

         of a spiraled or looped request through a proxy.



         Proxies choosing to detect loops have an additional constraint

         in the value they use for construction of the branch parameter.

         A proxy choosing to detect loops SHOULD create a branch

         parameter separable into two parts by the implementation.  The

         first part MUST satisfy the constraints of Section 8.1.1.7 as

         described above.  The second is used to perform loop detection

         and distinguish loops from spirals.



         Loop detection is performed by verifying that, when a request

         returns to a proxy, those fields having an impact on the

         processing of the request have not changed.  The value placed

         in this part of the branch parameter SHOULD reflect all of

         those fields (including any Route, Proxy-Require and Proxy-

         Authorization header fields).  This is to ensure that if the

         request is routed back to the proxy and one of those fields

         changes, it is treated as a spiral and not a loop (see Section

         16.3).  A common way to create this value is to compute a

         cryptographic hash of the To tag, From tag, Call-ID header

         field, the Request-URI of the request received (before

         translation), the topmost Via header, and the sequence number

         from the CSeq header field, in addition to any Proxy-Require

         and Proxy-Authorization header fields that may be present.  The











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         algorithm used to compute the hash is implementation-dependent,

         but MD5 (RFC 1321 [35]), expressed in hexadecimal, is a

         reasonable choice.  (Base64 is not permissible for a token.)



         If a proxy wishes to detect loops, the "branch" parameter it

         supplies MUST depend on all information affecting processing of

         a request, including the incoming Request-URI and any header

         fields affecting the request's admission or routing.  This is

         necessary to distinguish looped requests from requests whose

         routing parameters have changed before returning to this

         server.



         The request method MUST NOT be included in the calculation of

         the branch parameter.  In particular, CANCEL and ACK requests

         (for non-2xx responses) MUST have the same branch value as the

         corresponding request they cancel or acknowledge.  The branch

         parameter is used in correlating those requests at the server

         handling them (see Sections 17.2.3 and 9.2).



      9. Add a Content-Length header field if necessary



         If the request will be sent to the next hop using a stream-

         based transport and the copy contains no Content-Length header

         field, the proxy MUST insert one with the correct value for the

         body of the request (see Section 20.14).



      10. Forward Request



         A stateful proxy MUST create a new client transaction for this

         request as described in Section 17.1 and instructs the

         transaction to send the request using the address, port and

         transport determined in step 7.



      11. Set timer C



         In order to handle the case where an INVITE request never

         generates a final response, the TU uses a timer which is called

         timer C.  Timer C MUST be set for each client transaction when

         an INVITE request is proxied.  The timer MUST be larger than 3

         minutes.  Section 16.7 bullet 2 discusses how this timer is

         updated with provisional responses, and Section 16.8 discusses

         processing when it fires.



















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





16.7 Response Processing



   When a response is received by an element, it first tries to locate a

   client transaction (Section 17.1.3) matching the response.  If none

   is found, the element MUST process the response (even if it is an

   informational response) as a stateless proxy (described below).  If a

   match is found, the response is handed to the client transaction.



      Forwarding responses for which a client transaction (or more

      generally any knowledge of having sent an associated request) is

      not found improves robustness.  In particular, it ensures that

      "late" 2xx responses to INVITE requests are forwarded properly.



   As client transactions pass responses to the proxy layer, the

   following processing MUST take place:



      1.  Find the appropriate response context



      2.  Update timer C for provisional responses



      3.  Remove the topmost Via



      4.  Add the response to the response context



      5.  Check to see if this response should be forwarded immediately



      6.  When necessary, choose the best final response from the

          response context



   If no final response has been forwarded after every client

   transaction associated with the response context has been terminated,

   the proxy must choose and forward the "best" response from those it

   has seen so far.



   The following processing MUST be performed on each response that is

   forwarded.  It is likely that more than one response to each request

   will be forwarded: at least each provisional and one final response.



      7.  Aggregate authorization header field values if necessary



      8.  Optionally rewrite Record-Route header field values



      9.  Forward the response



      10. Generate any necessary CANCEL requests













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Each of the above steps are detailed below:



      1.  Find Context



         The proxy locates the "response context" it created before

         forwarding the original request using the key described in

         Section 16.6.  The remaining processing steps take place in

         this context.



      2.  Update timer C for provisional responses



         For an INVITE transaction, if the response is a provisional

         response with status codes 101 to 199 inclusive (i.e., anything

         but 100), the proxy MUST reset timer C for that client

         transaction.  The timer MAY be reset to a different value, but

         this value MUST be greater than 3 minutes.



      3.  Via



         The proxy removes the topmost Via header field value from the

         response.



         If no Via header field values remain in the response, the

         response was meant for this element and MUST NOT be forwarded.

         The remainder of the processing described in this section is

         not performed on this message, the UAC processing rules

         described in Section 8.1.3 are followed instead (transport

         layer processing has already occurred).



         This will happen, for instance, when the element generates

         CANCEL requests as described in Section 10.



      4.  Add response to context



         Final responses received are stored in the response context

         until a final response is generated on the server transaction

         associated with this context.  The response may be a candidate

         for the best final response to be returned on that server

         transaction.  Information from this response may be needed in

         forming the best response, even if this response is not chosen.



         If the proxy chooses to recurse on any contacts in a 3xx

         response by adding them to the target set, it MUST remove them

         from the response before adding the response to the response

         context.  However, a proxy SHOULD NOT recurse to a non-SIPS URI

         if the Request-URI of the original request was a SIPS URI.  If











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         the proxy recurses on all of the contacts in a 3xx response,

         the proxy SHOULD NOT add the resulting contactless response to

         the response context.



         Removing the contact before adding the response to the response

         context prevents the next element upstream from retrying a

         location this proxy has already attempted.



         3xx responses may contain a mixture of SIP, SIPS, and non-SIP

         URIs.  A proxy may choose to recurse on the SIP and SIPS URIs

         and place the remainder into the response context to be

         returned, potentially in the final response.



         If a proxy receives a 416 (Unsupported URI Scheme) response to

         a request whose Request-URI scheme was not SIP, but the scheme

         in the original received request was SIP or SIPS (that is, the

         proxy changed the scheme from SIP or SIPS to something else

         when it proxied a request), the proxy SHOULD add a new URI to

         the target set.  This URI SHOULD be a SIP URI version of the

         non-SIP URI that was just tried.  In the case of the tel URL,

         this is accomplished by placing the telephone-subscriber part

         of the tel URL into the user part of the SIP URI, and setting

         the hostpart to the domain where the prior request was sent.

         See Section 19.1.6 for more detail on forming SIP URIs from tel

         URLs.



         As with a 3xx response, if a proxy "recurses" on the 416 by

         trying a SIP or SIPS URI instead, the 416 response SHOULD NOT

         be added to the response context.



      5.  Check response for forwarding



         Until a final response has been sent on the server transaction,

         the following responses MUST be forwarded immediately:



         -  Any provisional response other than 100 (Trying)



         -  Any 2xx response



         If a 6xx response is received, it is not immediately forwarded,

         but the stateful proxy SHOULD cancel all client pending

         transactions as described in Section 10, and it MUST NOT create

         any new branches in this context.



         This is a change from RFC 2543, which mandated that the proxy

         was to forward the 6xx response immediately.  For an INVITE

         transaction, this approach had the problem that a 2xx response

         could arrive on another branch, in which case the proxy would







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         have to forward the 2xx.  The result was that the UAC could

         receive a 6xx response followed by a 2xx response, which should

         never be allowed to happen.  Under the new rules, upon

         receiving a 6xx, a proxy will issue a CANCEL request, which

         will generally result in 487 responses from all outstanding

         client transactions, and then at that point the 6xx is

         forwarded upstream.



         After a final response has been sent on the server transaction,

         the following responses MUST be forwarded immediately:



         -  Any 2xx response to an INVITE request



         A stateful proxy MUST NOT immediately forward any other

         responses.  In particular, a stateful proxy MUST NOT forward

         any 100 (Trying) response.  Those responses that are candidates

         for forwarding later as the "best" response have been gathered

         as described in step "Add Response to Context".



         Any response chosen for immediate forwarding MUST be processed

         as described in steps "Aggregate Authorization Header Field

         Values" through "Record-Route".



         This step, combined with the next, ensures that a stateful

         proxy will forward exactly one final response to a non-INVITE

         request, and either exactly one non-2xx response or one or more

         2xx responses to an INVITE request.



      6.  Choosing the best response



         A stateful proxy MUST send a final response to a response

         context's server transaction if no final responses have been

         immediately forwarded by the above rules and all client

         transactions in this response context have been terminated.



         The stateful proxy MUST choose the "best" final response among

         those received and stored in the response context.



         If there are no final responses in the context, the proxy MUST

         send a 408 (Request Timeout) response to the server

         transaction.



         Otherwise, the proxy MUST forward a response from the responses

         stored in the response context.  It MUST choose from the 6xx

         class responses if any exist in the context.  If no 6xx class

         responses are present, the proxy SHOULD choose from the lowest

         response class stored in the response context.  The proxy MAY

         select any response within that chosen class.  The proxy SHOULD







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         give preference to responses that provide information affecting

         resubmission of this request, such as 401, 407, 415, 420, and

         484 if the 4xx class is chosen.



         A proxy which receives a 503 (Service Unavailable) response

         SHOULD NOT forward it upstream unless it can determine that any

         subsequent requests it might proxy will also generate a 503.

         In other words, forwarding a 503 means that the proxy knows it

         cannot service any requests, not just the one for the Request-

         URI in the request which generated the 503.  If the only

         response that was received is a 503, the proxy SHOULD generate

         a 500 response and forward that upstream.



         The forwarded response MUST be processed as described in steps

         "Aggregate Authorization Header Field Values" through "Record-

         Route".



         For example, if a proxy forwarded a request to 4 locations, and

         received 503, 407, 501, and 404 responses, it may choose to

         forward the 407 (Proxy Authentication Required) response.



         1xx and 2xx responses may be involved in the establishment of

         dialogs.  When a request does not contain a To tag, the To tag

         in the response is used by the UAC to distinguish multiple

         responses to a dialog creating request.  A proxy MUST NOT

         insert a tag into the To header field of a 1xx or 2xx response

         if the request did not contain one.  A proxy MUST NOT modify

         the tag in the To header field of a 1xx or 2xx response.



         Since a proxy may not insert a tag into the To header field of

         a 1xx response to a request that did not contain one, it cannot

         issue non-100 provisional responses on its own.  However, it

         can branch the request to a UAS sharing the same element as the

         proxy.  This UAS can return its own provisional responses,

         entering into an early dialog with the initiator of the

         request.  The UAS does not have to be a discreet process from

         the proxy.  It could be a virtual UAS implemented in the same

         code space as the proxy.



         3-6xx responses are delivered hop-by-hop.  When issuing a 3-6xx

         response, the element is effectively acting as a UAS, issuing

         its own response, usually based on the responses received from

         downstream elements.  An element SHOULD preserve the To tag

         when simply forwarding a 3-6xx response to a request that did

         not contain a To tag.



         A proxy MUST NOT modify the To tag in any forwarded response to

         a request that contains a To tag.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         While it makes no difference to the upstream elements if the

         proxy replaced the To tag in a forwarded 3-6xx response,

         preserving the original tag may assist with debugging.



         When the proxy is aggregating information from several

         responses, choosing a To tag from among them is arbitrary, and

         generating a new To tag may make debugging easier.  This

         happens, for instance, when combining 401 (Unauthorized) and

         407 (Proxy Authentication Required) challenges, or combining

         Contact values from unencrypted and unauthenticated 3xx

         responses.



      7.  Aggregate Authorization Header Field Values



         If the selected response is a 401 (Unauthorized) or 407 (Proxy

         Authentication Required), the proxy MUST collect any WWW-

         Authenticate and Proxy-Authenticate header field values from

         all other 401 (Unauthorized) and 407 (Proxy Authentication

         Required) responses received so far in this response context

         and add them to this response without modification before

         forwarding.  The resulting 401 (Unauthorized) or 407 (Proxy

         Authentication Required) response could have several WWW-

         Authenticate AND Proxy-Authenticate header field values.



         This is necessary because any or all of the destinations the

         request was forwarded to may have requested credentials.  The

         client needs to receive all of those challenges and supply

         credentials for each of them when it retries the request.

         Motivation for this behavior is provided in Section 26.



      8.  Record-Route



         If the selected response contains a Record-Route header field

         value originally provided by this proxy, the proxy MAY choose

         to rewrite the value before forwarding the response.  This

         allows the proxy to provide different URIs for itself to the

         next upstream and downstream elements.  A proxy may choose to

         use this mechanism for any reason.  For instance, it is useful

         for multi-homed hosts.



         If the proxy received the request over TLS, and sent it out

         over a non-TLS connection, the proxy MUST rewrite the URI in

         the Record-Route header field to be a SIPS URI.  If the proxy

         received the request over a non-TLS connection, and sent it out

         over TLS, the proxy MUST rewrite the URI in the Record-Route

         header field to be a SIP URI.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         The new URI provided by the proxy MUST satisfy the same

         constraints on URIs placed in Record-Route header fields in

         requests (see Step 4 of Section 16.6) with the following

         modifications:



         The URI SHOULD NOT contain the transport parameter unless the

         proxy has knowledge that the next upstream (as opposed to

         downstream) element that will be in the path of subsequent

         requests supports that transport.



         When a proxy does decide to modify the Record-Route header

         field in the response, one of the operations it performs is

         locating the Record-Route value that it had inserted.  If the

         request spiraled, and the proxy inserted a Record-Route value

         in each iteration of the spiral, locating the correct value in

         the response (which must be the proper iteration in the reverse

         direction) is tricky.  The rules above recommend that a proxy

         wishing to rewrite Record-Route header field values insert

         sufficiently distinct URIs into the Record-Route header field

         so that the right one may be selected for rewriting.  A

         RECOMMENDED mechanism to achieve this is for the proxy to

         append a unique identifier for the proxy instance to the user

         portion of the URI.



         When the response arrives, the proxy modifies the first

         Record-Route whose identifier matches the proxy instance.  The

         modification results in a URI without this piece of data

         appended to the user portion of the URI.  Upon the next

         iteration, the same algorithm (find the topmost Record-Route

         header field value with the parameter) will correctly extract

         the next Record-Route header field value inserted by that

         proxy.



         Not every response to a request to which a proxy adds a

         Record-Route header field value will contain a Record-Route

         header field.  If the response does contain a Record-Route

         header field, it will contain the value the proxy added.



      9.  Forward response



         After performing the processing described in steps "Aggregate

         Authorization Header Field Values" through "Record-Route", the

         proxy MAY perform any feature specific manipulations on the

         selected response.  The proxy MUST NOT add to, modify, or

         remove the message body.  Unless otherwise specified, the proxy

         MUST NOT remove any header field values other than the Via

         header field value discussed in Section 16.7 Item 3.  In

         particular, the proxy MUST NOT remove any "received" parameter







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         it may have added to the next Via header field value while

         processing the request associated with this response.  The

         proxy MUST pass the response to the server transaction

         associated with the response context.  This will result in the

         response being sent to the location now indicated in the

         topmost Via header field value.  If the server transaction is

         no longer available to handle the transmission, the element

         MUST forward the response statelessly by sending it to the

         server transport.  The server transaction might indicate

         failure to send the response or signal a timeout in its state

         machine.  These errors would be logged for diagnostic purposes

         as appropriate, but the protocol requires no remedial action

         from the proxy.



         The proxy MUST maintain the response context until all of its

         associated transactions have been terminated, even after

         forwarding a final response.



      10. Generate CANCELs



         If the forwarded response was a final response, the proxy MUST

         generate a CANCEL request for all pending client transactions

         associated with this response context.  A proxy SHOULD also

         generate a CANCEL request for all pending client transactions

         associated with this response context when it receives a 6xx

         response.  A pending client transaction is one that has

         received a provisional response, but no final response (it is

         in the proceeding state) and has not had an associated CANCEL

         generated for it.  Generating CANCEL requests is described in

         Section 9.1.



         The requirement to CANCEL pending client transactions upon

         forwarding a final response does not guarantee that an endpoint

         will not receive multiple 200 (OK) responses to an INVITE.  200

         (OK) responses on more than one branch may be generated before

         the CANCEL requests can be sent and processed.  Further, it is

         reasonable to expect that a future extension may override this

         requirement to issue CANCEL requests.



16.8 Processing Timer C



   If timer C should fire, the proxy MUST either reset the timer with

   any value it chooses, or terminate the client transaction.  If the

   client transaction has received a provisional response, the proxy

   MUST generate a CANCEL request matching that transaction.  If the

   client transaction has not received a provisional response, the proxy

   MUST behave as if the transaction received a 408 (Request Timeout)

   response.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Allowing the proxy to reset the timer allows the proxy to dynamically

   extend the transaction's lifetime based on current conditions (such

   as utilization) when the timer fires.



16.9 Handling Transport Errors



   If the transport layer notifies a proxy of an error when it tries to

   forward a request (see Section 18.4), the proxy MUST behave as if the

   forwarded request received a 503 (Service Unavailable) response.



   If the proxy is notified of an error when forwarding a response, it

   drops the response.  The proxy SHOULD NOT cancel any outstanding

   client transactions associated with this response context due to this

   notification.



      If a proxy cancels its outstanding client transactions, a single

      malicious or misbehaving client can cause all transactions to fail

      through its Via header field.



16.10 CANCEL Processing



   A stateful proxy MAY generate a CANCEL to any other request it has

   generated at any time (subject to receiving a provisional response to

   that request as described in section 9.1).  A proxy MUST cancel any

   pending client transactions associated with a response context when

   it receives a matching CANCEL request.



   A stateful proxy MAY generate CANCEL requests for pending INVITE

   client transactions based on the period specified in the INVITE's

   Expires header field elapsing.  However, this is generally

   unnecessary since the endpoints involved will take care of signaling

   the end of the transaction.



   While a CANCEL request is handled in a stateful proxy by its own

   server transaction, a new response context is not created for it.

   Instead, the proxy layer searches its existing response contexts for

   the server transaction handling the request associated with this

   CANCEL.  If a matching response context is found, the element MUST

   immediately return a 200 (OK) response to the CANCEL request.  In

   this case, the element is acting as a user agent server as defined in

   Section 8.2.  Furthermore, the element MUST generate CANCEL requests

   for all pending client transactions in the context as described in

   Section 16.7 step 10.



   If a response context is not found, the element does not have any

   knowledge of the request to apply the CANCEL to.  It MUST statelessly

   forward the CANCEL request (it may have statelessly forwarded the

   associated request previously).







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





16.11 Stateless Proxy



   When acting statelessly, a proxy is a simple message forwarder.  Much

   of the processing performed when acting statelessly is the same as

   when behaving statefully.  The differences are detailed here.



   A stateless proxy does not have any notion of a transaction, or of

   the response context used to describe stateful proxy behavior.

   Instead, the stateless proxy takes messages, both requests and

   responses, directly from the transport layer (See section 18).  As a

   result, stateless proxies do not retransmit messages on their own.

   They do, however, forward all retransmissions they receive (they do

   not have the ability to distinguish a retransmission from the

   original message).  Furthermore, when handling a request statelessly,

   an element MUST NOT generate its own 100 (Trying) or any other

   provisional response.



   A stateless proxy MUST validate a request as described in Section

   16.3



   A stateless proxy MUST follow the request processing steps described

   in Sections 16.4 through 16.5 with the following exception:



      o  A stateless proxy MUST choose one and only one target from the

         target set.  This choice MUST only rely on fields in the

         message and time-invariant properties of the server.  In

         particular, a retransmitted request MUST be forwarded to the

         same destination each time it is processed.  Furthermore,

         CANCEL and non-Routed ACK requests MUST generate the same

         choice as their associated INVITE.



   A stateless proxy MUST follow the request processing steps described

   in Section 16.6 with the following exceptions:



      o  The requirement for unique branch IDs across space and time

         applies to stateless proxies as well.  However, a stateless

         proxy cannot simply use a random number generator to compute

         the first component of the branch ID, as described in Section

         16.6 bullet 8.  This is because retransmissions of a request

         need to have the same value, and a stateless proxy cannot tell

         a retransmission from the original request.  Therefore, the

         component of the branch parameter that makes it unique MUST be

         the same each time a retransmitted request is forwarded.  Thus

         for a stateless proxy, the branch parameter MUST be computed as

         a combinatoric function of message parameters which are

         invariant on retransmission.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         The stateless proxy MAY use any technique it likes to guarantee

         uniqueness of its branch IDs across transactions.  However, the

         following procedure is RECOMMENDED.  The proxy examines the

         branch ID in the topmost Via header field of the received

         request.  If it begins with the magic cookie, the first

         component of the branch ID of the outgoing request is computed

         as a hash of the received branch ID.  Otherwise, the first

         component of the branch ID is computed as a hash of the topmost

         Via, the tag in the To header field, the tag in the From header

         field, the Call-ID header field, the CSeq number (but not

         method), and the Request-URI from the received request.  One of

         these fields will always vary across two different

         transactions.



      o  All other message transformations specified in Section 16.6

         MUST result in the same transformation of a retransmitted

         request.  In particular, if the proxy inserts a Record-Route

         value or pushes URIs into the Route header field, it MUST place

         the same values in retransmissions of the request.  As for the

         Via branch parameter, this implies that the transformations

         MUST be based on time-invariant configuration or

         retransmission-invariant properties of the request.



      o  A stateless proxy determines where to forward the request as

         described for stateful proxies in Section 16.6 Item 10.  The

         request is sent directly to the transport layer instead of

         through a client transaction.



         Since a stateless proxy must forward retransmitted requests to

         the same destination and add identical branch parameters to

         each of them, it can only use information from the message

         itself and time-invariant configuration data for those

         calculations.  If the configuration state is not time-invariant

         (for example, if a routing table is updated) any requests that

         could be affected by the change may not be forwarded

         statelessly during an interval equal to the transaction timeout

         window before or after the change.  The method of processing

         the affected requests in that interval is an implementation

         decision.  A common solution is to forward them transaction

         statefully.



   Stateless proxies MUST NOT perform special processing for CANCEL

   requests.  They are processed by the above rules as any other

   requests.  In particular, a stateless proxy applies the same Route

   header field processing to CANCEL requests that it applies to any

   other request.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Response processing as described in Section 16.7 does not apply to a

   proxy behaving statelessly.  When a response arrives at a stateless

   proxy, the proxy MUST inspect the sent-by value in the first

   (topmost) Via header field value.  If that address matches the proxy,

   (it equals a value this proxy has inserted into previous requests)

   the proxy MUST remove that header field value from the response and

   forward the result to the location indicated in the next Via header

   field value.  The proxy MUST NOT add to, modify, or remove the

   message body.  Unless specified otherwise, the proxy MUST NOT remove

   any other header field values.  If the address does not match the

   proxy, the message MUST be silently discarded.



16.12 Summary of Proxy Route Processing



   In the absence of local policy to the contrary, the processing a

   proxy performs on a request containing a Route header field can be

   summarized in the following steps.



      1.  The proxy will inspect the Request-URI.  If it indicates a

          resource owned by this proxy, the proxy will replace it with

          the results of running a location service.  Otherwise, the

          proxy will not change the Request-URI.



      2.  The proxy will inspect the URI in the topmost Route header

          field value.  If it indicates this proxy, the proxy removes it

          from the Route header field (this route node has been

          reached).



      3.  The proxy will forward the request to the resource indicated

          by the URI in the topmost Route header field value or in the

          Request-URI if no Route header field is present.  The proxy

          determines the address, port and transport to use when

          forwarding the request by applying the procedures in [4] to

          that URI.



   If no strict-routing elements are encountered on the path of the

   request, the Request-URI will always indicate the target of the

   request.



16.12.1 Examples



16.12.1.1 Basic SIP Trapezoid



   This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with

   both proxies record-routing.  Here is the flow.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   U1 sends:



      INVITE sip:callee@domain.com SIP/2.0

      Contact: sip:caller@u1.example.com



   to P1.  P1 is an outbound proxy.  P1 is not responsible for

   domain.com, so it looks it up in DNS and sends it there.  It also

   adds a Record-Route header field value:



      INVITE sip:callee@domain.com SIP/2.0

      Contact: sip:caller@u1.example.com

      Record-Route: <sip:p1.example.com;lr>



   P2 gets this.  It is responsible for domain.com so it runs a location

   service and rewrites the Request-URI.  It also adds a Record-Route

   header field value.  There is no Route header field, so it resolves

   the new Request-URI to determine where to send the request:



      INVITE sip:callee@u2.domain.com SIP/2.0

      Contact: sip:caller@u1.example.com

      Record-Route: <sip:p2.domain.com;lr>

      Record-Route: <sip:p1.example.com;lr>



   The callee at u2.domain.com gets this and responds with a 200 OK:



      SIP/2.0 200 OK

      Contact: sip:callee@u2.domain.com

      Record-Route: <sip:p2.domain.com;lr>

      Record-Route: <sip:p1.example.com;lr>



   The callee at u2 also sets its dialog state's remote target URI to

   sip:caller@u1.example.com and its route set to:



      (<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)



   This is forwarded by P2 to P1 to U1 as normal.  Now, U1 sets its

   dialog state's remote target URI to sip:callee@u2.domain.com and its

   route set to:



      (<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>)



   Since all the route set elements contain the lr parameter, U1

   constructs the following BYE request:



      BYE sip:callee@u2.domain.com SIP/2.0

      Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   As any other element (including proxies) would do, it resolves the

   URI in the topmost Route header field value using DNS to determine

   where to send the request.  This goes to P1.  P1 notices that it is

   not responsible for the resource indicated in the Request-URI so it

   doesn't change it.  It does see that it is the first value in the

   Route header field, so it removes that value, and forwards the

   request to P2:



      BYE sip:callee@u2.domain.com SIP/2.0

      Route: <sip:p2.domain.com;lr>



   P2 also notices it is not responsible for the resource indicated by

   the Request-URI (it is responsible for domain.com, not

   u2.domain.com), so it doesn't change it.  It does see itself in the

   first Route header field value, so it removes it and forwards the

   following to u2.domain.com based on a DNS lookup against the

   Request-URI:



      BYE sip:callee@u2.domain.com SIP/2.0



16.12.1.2 Traversing a Strict-Routing Proxy



   In this scenario, a dialog is established across four proxies, each

   of which adds Record-Route header field values.  The third proxy

   implements the strict-routing procedures specified in RFC 2543 and

   many works in progress.



      U1->P1->P2->P3->P4->U2



   The INVITE arriving at U2 contains:



      INVITE sip:callee@u2.domain.com SIP/2.0

      Contact: sip:caller@u1.example.com

      Record-Route: <sip:p4.domain.com;lr>

      Record-Route: <sip:p3.middle.com>

      Record-Route: <sip:p2.example.com;lr>

      Record-Route: <sip:p1.example.com;lr>



   Which U2 responds to with a 200 OK.  Later, U2 sends the following

   BYE request to P4 based on the first Route header field value.



      BYE sip:caller@u1.example.com SIP/2.0

      Route: <sip:p4.domain.com;lr>

      Route: <sip:p3.middle.com>

      Route: <sip:p2.example.com;lr>

      Route: <sip:p1.example.com;lr>











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   P4 is not responsible for the resource indicated in the Request-URI

   so it will leave it alone.  It notices that it is the element in the

   first Route header field value so it removes it.  It then prepares to

   send the request based on the now first Route header field value of

   sip:p3.middle.com, but it notices that this URI does not contain the

   lr parameter, so before sending, it reformats the request to be:



      BYE sip:p3.middle.com SIP/2.0

      Route: <sip:p2.example.com;lr>

      Route: <sip:p1.example.com;lr>

      Route: <sip:caller@u1.example.com>



   P3 is a strict router, so it forwards the following to P2:



      BYE sip:p2.example.com;lr SIP/2.0

      Route: <sip:p1.example.com;lr>

      Route: <sip:caller@u1.example.com>



   P2 sees the request-URI is a value it placed into a Record-Route

   header field, so before further processing, it rewrites the request

   to be:



      BYE sip:caller@u1.example.com SIP/2.0

      Route: <sip:p1.example.com;lr>



   P2 is not responsible for u1.example.com, so it sends the request to

   P1 based on the resolution of the Route header field value.



   P1 notices itself in the topmost Route header field value, so it

   removes it, resulting in:



      BYE sip:caller@u1.example.com SIP/2.0



   Since P1 is not responsible for u1.example.com and there is no Route

   header field, P1 will forward the request to u1.example.com based on

   the Request-URI.



16.12.1.3 Rewriting Record-Route Header Field Values



   In this scenario, U1 and U2 are in different private namespaces and

   they enter a dialog through a proxy P1, which acts as a gateway

   between the namespaces.



      U1->P1->U2















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   U1 sends:



      INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0

      Contact: <sip:caller@u1.leftprivatespace.com>



   P1 uses its location service and sends the following to U2:



      INVITE sip:callee@rightprivatespace.com SIP/2.0

      Contact: <sip:caller@u1.leftprivatespace.com>

      Record-Route: <sip:gateway.rightprivatespace.com;lr>



   U2 sends this 200 (OK) back to P1:



      SIP/2.0 200 OK

      Contact: <sip:callee@u2.rightprivatespace.com>

      Record-Route: <sip:gateway.rightprivatespace.com;lr>



   P1 rewrites its Record-Route header parameter to provide a value that

   U1 will find useful, and sends the following to U1:



      SIP/2.0 200 OK

      Contact: <sip:callee@u2.rightprivatespace.com>

      Record-Route: <sip:gateway.leftprivatespace.com;lr>



   Later, U1 sends the following BYE request to P1:



      BYE sip:callee@u2.rightprivatespace.com SIP/2.0

      Route: <sip:gateway.leftprivatespace.com;lr>



   which P1 forwards to U2 as:



      BYE sip:callee@u2.rightprivatespace.com SIP/2.0



17 Transactions



   SIP is a transactional protocol: interactions between components take

   place in a series of independent message exchanges.  Specifically, a

   SIP transaction consists of a single request and any responses to

   that request, which include zero or more provisional responses and

   one or more final responses.  In the case of a transaction where the

   request was an INVITE (known as an INVITE transaction), the

   transaction also includes the ACK only if the final response was not

   a 2xx response.  If the response was a 2xx, the ACK is not considered

   part of the transaction.



      The reason for this separation is rooted in the importance of

      delivering all 200 (OK) responses to an INVITE to the UAC.  To

      deliver them all to the UAC, the UAS alone takes responsibility







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      for retransmitting them (see Section 13.3.1.4), and the UAC alone

      takes responsibility for acknowledging them with ACK (see Section

      13.2.2.4).  Since this ACK is retransmitted only by the UAC, it is

      effectively considered its own transaction.



   Transactions have a client side and a server side.  The client side

   is known as a client transaction and the server side as a server

   transaction.  The client transaction sends the request, and the

   server transaction sends the response.  The client and server

   transactions are logical functions that are embedded in any number of

   elements.  Specifically, they exist within user agents and stateful

   proxy servers.  Consider the example in Section 4.  In this example,

   the UAC executes the client transaction, and its outbound proxy

   executes the server transaction.  The outbound proxy also executes a

   client transaction, which sends the request to a server transaction

   in the inbound proxy.  That proxy also executes a client transaction,

   which in turn sends the request to a server transaction in the UAS.

   This is shown in Figure 4.



   +---------+        +---------+        +---------+        +---------+

   |      +-+|Request |+-+   +-+|Request |+-+   +-+|Request |+-+      |

   |      |C||------->||S|   |C||------->||S|   |C||------->||S|      |

   |      |l||        ||e|   |l||        ||e|   |l||        ||e|      |

   |      |i||        ||r|   |i||        ||r|   |i||        ||r|      |

   |      |e||        ||v|   |e||        ||v|   |e||        ||v|      |

   |      |n||        ||e|   |n||        ||e|   |n||        ||e|      |

   |      |t||        ||r|   |t||        ||r|   |t||        ||r|      |

   |      | ||        || |   | ||        || |   | ||        || |      |

   |      |T||        ||T|   |T||        ||T|   |T||        ||T|      |

   |      |r||        ||r|   |r||        ||r|   |r||        ||r|      |

   |      |a||        ||a|   |a||        ||a|   |a||        ||a|      |

   |      |n||        ||n|   |n||        ||n|   |n||        ||n|      |

   |      |s||Response||s|   |s||Response||s|   |s||Response||s|      |

   |      +-+|<-------|+-+   +-+|<-------|+-+   +-+|<-------|+-+      |

   +---------+        +---------+        +---------+        +---------+

      UAC               Outbound           Inbound              UAS

                        Proxy               Proxy



                  Figure 4: Transaction relationships



   A stateless proxy does not contain a client or server transaction.

   The transaction exists between the UA or stateful proxy on one side,

   and the UA or stateful proxy on the other side.  As far as SIP

   transactions are concerned, stateless proxies are effectively

   transparent.  The purpose of the client transaction is to receive a

   request from the element in which the client is embedded (call this

   element the "Transaction User" or TU; it can be a UA or a stateful

   proxy), and reliably deliver the request to a server transaction.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The client transaction is also responsible for receiving responses

   and delivering them to the TU, filtering out any response

   retransmissions or disallowed responses (such as a response to ACK).

   Additionally, in the case of an INVITE request, the client

   transaction is responsible for generating the ACK request for any

   final response accepting a 2xx response.



   Similarly, the purpose of the server transaction is to receive

   requests from the transport layer and deliver them to the TU.  The

   server transaction filters any request retransmissions from the

   network.  The server transaction accepts responses from the TU and

   delivers them to the transport layer for transmission over the

   network.  In the case of an INVITE transaction, it absorbs the ACK

   request for any final response excepting a 2xx response.



   The 2xx response and its ACK receive special treatment.  This

   response is retransmitted only by a UAS, and its ACK generated only

   by the UAC.  This end-to-end treatment is needed so that a caller

   knows the entire set of users that have accepted the call.  Because

   of this special handling, retransmissions of the 2xx response are

   handled by the UA core, not the transaction layer.  Similarly,

   generation of the ACK for the 2xx is handled by the UA core.  Each

   proxy along the path merely forwards each 2xx response to INVITE and

   its corresponding ACK.



17.1 Client Transaction



   The client transaction provides its functionality through the

   maintenance of a state machine.



   The TU communicates with the client transaction through a simple

   interface.  When the TU wishes to initiate a new transaction, it

   creates a client transaction and passes it the SIP request to send

   and an IP address, port, and transport to which to send it.  The

   client transaction begins execution of its state machine.  Valid

   responses are passed up to the TU from the client transaction.



   There are two types of client transaction state machines, depending

   on the method of the request passed by the TU.  One handles client

   transactions for INVITE requests.  This type of machine is referred

   to as an INVITE client transaction.  Another type handles client

   transactions for all requests except INVITE and ACK.  This is

   referred to as a non-INVITE client transaction.  There is no client

   transaction for ACK.  If the TU wishes to send an ACK, it passes one

   directly to the transport layer for transmission.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The INVITE transaction is different from those of other methods

   because of its extended duration.  Normally, human input is required

   in order to respond to an INVITE.  The long delays expected for

   sending a response argue for a three-way handshake.  On the other

   hand, requests of other methods are expected to complete rapidly.

   Because of the non-INVITE transaction's reliance on a two-way

   handshake, TUs SHOULD respond immediately to non-INVITE requests.



17.1.1 INVITE Client Transaction



17.1.1.1 Overview of INVITE Transaction



   The INVITE transaction consists of a three-way handshake.  The client

   transaction sends an INVITE, the server transaction sends responses,

   and the client transaction sends an ACK.  For unreliable transports

   (such as UDP), the client transaction retransmits requests at an

   interval that starts at T1 seconds and doubles after every

   retransmission.  T1 is an estimate of the round-trip time (RTT), and

   it defaults to 500 ms.  Nearly all of the transaction timers

   described here scale with T1, and changing T1 adjusts their values.

   The request is not retransmitted over reliable transports.  After

   receiving a 1xx response, any retransmissions cease altogether, and

   the client waits for further responses.  The server transaction can

   send additional 1xx responses, which are not transmitted reliably by

   the server transaction.  Eventually, the server transaction decides

   to send a final response.  For unreliable transports, that response

   is retransmitted periodically, and for reliable transports, it is

   sent once.  For each final response that is received at the client

   transaction, the client transaction sends an ACK, the purpose of

   which is to quench retransmissions of the response.



17.1.1.2 Formal Description



   The state machine for the INVITE client transaction is shown in

   Figure 5.  The initial state, "calling", MUST be entered when the TU

   initiates a new client transaction with an INVITE request.  The

   client transaction MUST pass the request to the transport layer for

   transmission (see Section 18).  If an unreliable transport is being

   used, the client transaction MUST start timer A with a value of T1.

   If a reliable transport is being used, the client transaction SHOULD

   NOT start timer A (Timer A controls request retransmissions).  For

   any transport, the client transaction MUST start timer B with a value

   of 64*T1 seconds (Timer B controls transaction timeouts).



   When timer A fires, the client transaction MUST retransmit the

   request by passing it to the transport layer, and MUST reset the

   timer with a value of 2*T1.  The formal definition of retransmit









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   within the context of the transaction layer is to take the message

   previously sent to the transport layer and pass it to the transport

   layer once more.



   When timer A fires 2*T1 seconds later, the request MUST be

   retransmitted again (assuming the client transaction is still in this

   state).  This process MUST continue so that the request is

   retransmitted with intervals that double after each transmission.

   These retransmissions SHOULD only be done while the client

   transaction is in the "calling" state.



   The default value for T1 is 500 ms.  T1 is an estimate of the RTT

   between the client and server transactions.  Elements MAY (though it

   is NOT RECOMMENDED) use smaller values of T1 within closed, private

   networks that do not permit general Internet connection.  T1 MAY be

   chosen larger, and this is RECOMMENDED if it is known in advance

   (such as on high latency access links) that the RTT is larger.

   Whatever the value of T1, the exponential backoffs on retransmissions

   described in this section MUST be used.



   If the client transaction is still in the "Calling" state when timer

   B fires, the client transaction SHOULD inform the TU that a timeout

   has occurred.  The client transaction MUST NOT generate an ACK.  The

   value of 64*T1 is equal to the amount of time required to send seven

   requests in the case of an unreliable transport.



   If the client transaction receives a provisional response while in

   the "Calling" state, it transitions to the "Proceeding" state. In the

   "Proceeding" state, the client transaction SHOULD NOT retransmit the

   request any longer. Furthermore, the provisional response MUST be

   passed to the TU.  Any further provisional responses MUST be passed

   up to the TU while in the "Proceeding" state.



   When in either the "Calling" or "Proceeding" states, reception of a

   response with status code from 300-699 MUST cause the client

   transaction to transition to "Completed".  The client transaction

   MUST pass the received response up to the TU, and the client

   transaction MUST generate an ACK request, even if the transport is

   reliable (guidelines for constructing the ACK from the response are

   given in Section 17.1.1.3) and then pass the ACK to the transport

   layer for transmission.  The ACK MUST be sent to the same address,

   port, and transport to which the original request was sent.  The

   client transaction SHOULD start timer D when it enters the

   "Completed" state, with a value of at least 32 seconds for unreliable

   transports, and a value of zero seconds for reliable transports.

   Timer D reflects the amount of time that the server transaction can

   remain in the "Completed" state when unreliable transports are used.

   This is equal to Timer H in the INVITE server transaction, whose







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   default is 64*T1.  However, the client transaction does not know the

   value of T1 in use by the server transaction, so an absolute minimum

   of 32s is used instead of basing Timer D on T1.



   Any retransmissions of the final response that are received while in

   the "Completed" state MUST cause the ACK to be re-passed to the

   transport layer for retransmission, but the newly received response

   MUST NOT be passed up to the TU.  A retransmission of the response is

   defined as any response which would match the same client transaction

   based on the rules of Section 17.1.3.



















































































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



RFC 3261            SIP: Session Initiation Protocol           June 2002





                               |INVITE from TU

             Timer A fires     |INVITE sent

             Reset A,          V                      Timer B fires

             INVITE sent +-----------+                or Transport Err.

               +---------|           |---------------+inform TU

               |         |  Calling  |               |

               +-------->|           |-------------->|

                         +-----------+ 2xx           |

                            |  |       2xx to TU     |

                            |  |1xx                  |

    300-699 +---------------+  |1xx to TU            |

   ACK sent |                  |                     |

resp. to TU |  1xx             V                     |

            |  1xx to TU  -----------+               |

            |  +---------|           |               |

            |  |         |Proceeding |-------------->|

            |  +-------->|           | 2xx           |

            |            +-----------+ 2xx to TU     |

            |       300-699    |                     |

            |       ACK sent,  |                     |

            |       resp. to TU|                     |

            |                  |                     |      NOTE:

            |  300-699         V                     |

            |  ACK sent  +-----------+Transport Err. |  transitions

            |  +---------|           |Inform TU      |  labeled with

            |  |         | Completed |-------------->|  the event

            |  +-------->|           |               |  over the action

            |            +-----------+               |  to take

            |              ^   |                     |

            |              |   | Timer D fires       |

            +--------------+   | -                   |

                               |                     |

                               V                     |

                         +-----------+               |

                         |           |               |

                         | Terminated|<--------------+

                         |           |

                         +-----------+



                 Figure 5: INVITE client transaction



   If timer D fires while the client transaction is in the "Completed"

   state, the client transaction MUST move to the terminated state.



   When in either the "Calling" or "Proceeding" states, reception of a

   2xx response MUST cause the client transaction to enter the

   "Terminated" state, and the response MUST be passed up to the TU.

   The handling of this response depends on whether the TU is a proxy







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   core or a UAC core.  A UAC core will handle generation of the ACK for

   this response, while a proxy core will always forward the 200 (OK)

   upstream.  The differing treatment of 200 (OK) between proxy and UAC

   is the reason that handling of it does not take place in the

   transaction layer.



   The client transaction MUST be destroyed the instant it enters the

   "Terminated" state.  This is actually necessary to guarantee correct

   operation.  The reason is that 2xx responses to an INVITE are treated

   differently; each one is forwarded by proxies, and the ACK handling

   in a UAC is different.  Thus, each 2xx needs to be passed to a proxy

   core (so that it can be forwarded) and to a UAC core (so it can be

   acknowledged).  No transaction layer processing takes place.

   Whenever a response is received by the transport, if the transport

   layer finds no matching client transaction (using the rules of

   Section 17.1.3), the response is passed directly to the core.  Since

   the matching client transaction is destroyed by the first 2xx,

   subsequent 2xx will find no match and therefore be passed to the

   core.



17.1.1.3 Construction of the ACK Request



   This section specifies the construction of ACK requests sent within

   the client transaction.  A UAC core that generates an ACK for 2xx

   MUST instead follow the rules described in Section 13.



   The ACK request constructed by the client transaction MUST contain

   values for the Call-ID, From, and Request-URI that are equal to the

   values of those header fields in the request passed to the transport

   by the client transaction (call this the "original request").  The To

   header field in the ACK MUST equal the To header field in the

   response being acknowledged, and therefore will usually differ from

   the To header field in the original request by the addition of the

   tag parameter.  The ACK MUST contain a single Via header field, and

   this MUST be equal to the top Via header field of the original

   request.  The CSeq header field in the ACK MUST contain the same

   value for the sequence number as was present in the original request,

   but the method parameter MUST be equal to "ACK".



























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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   If the INVITE request whose response is being acknowledged had Route

   header fields, those header fields MUST appear in the ACK.  This is

   to ensure that the ACK can be routed properly through any downstream

   stateless proxies.



   Although any request MAY contain a body, a body in an ACK is special

   since the request cannot be rejected if the body is not understood.

   Therefore, placement of bodies in ACK for non-2xx is NOT RECOMMENDED,

   but if done, the body types are restricted to any that appeared in

   the INVITE, assuming that the response to the INVITE was not 415.  If

   it was, the body in the ACK MAY be any type listed in the Accept

   header field in the 415.



   For example, consider the following request:



   INVITE sip:bob@biloxi.com SIP/2.0

   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff

   To: Bob <sip:bob@biloxi.com>

   From: Alice <sip:alice@atlanta.com>;tag=88sja8x

   Max-Forwards: 70

   Call-ID: 987asjd97y7atg

   CSeq: 986759 INVITE



   The ACK request for a non-2xx final response to this request would

   look like this:



   ACK sip:bob@biloxi.com SIP/2.0

   Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff

   To: Bob <sip:bob@biloxi.com>;tag=99sa0xk

   From: Alice <sip:alice@atlanta.com>;tag=88sja8x

   Max-Forwards: 70

   Call-ID: 987asjd97y7atg

   CSeq: 986759 ACK



17.1.2 Non-INVITE Client Transaction



17.1.2.1 Overview of the non-INVITE Transaction



   Non-INVITE transactions do not make use of ACK.  They are simple

   request-response interactions.  For unreliable transports, requests

   are retransmitted at an interval which starts at T1 and doubles until

   it hits T2.  If a provisional response is received, retransmissions

   continue for unreliable transports, but at an interval of T2.  The

   server transaction retransmits the last response it sent, which can

   be a provisional or final response, only when a retransmission of the

   request is received.  This is why request retransmissions need to

   continue even after a provisional response; they are to ensure

   reliable delivery of the final response.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Unlike an INVITE transaction, a non-INVITE transaction has no special

   handling for the 2xx response.  The result is that only a single 2xx

   response to a non-INVITE is ever delivered to a UAC.



17.1.2.2 Formal Description



   The state machine for the non-INVITE client transaction is shown in

   Figure 6.  It is very similar to the state machine for INVITE.



   The "Trying" state is entered when the TU initiates a new client

   transaction with a request.  When entering this state, the client

   transaction SHOULD set timer F to fire in 64*T1 seconds.  The request

   MUST be passed to the transport layer for transmission.  If an

   unreliable transport is in use, the client transaction MUST set timer

   E to fire in T1 seconds.  If timer E fires while still in this state,

   the timer is reset, but this time with a value of MIN(2*T1, T2).

   When the timer fires again, it is reset to a MIN(4*T1, T2).  This

   process continues so that retransmissions occur with an exponentially

   increasing interval that caps at T2.  The default value of T2 is 4s,

   and it represents the amount of time a non-INVITE server transaction

   will take to respond to a request, if it does not respond

   immediately.  For the default values of T1 and T2, this results in

   intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc.



   If Timer F fires while the client transaction is still in the

   "Trying" state, the client transaction SHOULD inform the TU about the

   timeout, and then it SHOULD enter the "Terminated" state.  If a

   provisional response is received while in the "Trying" state, the

   response MUST be passed to the TU, and then the client transaction

   SHOULD move to the "Proceeding" state.  If a final response (status

   codes 200-699) is received while in the "Trying" state, the response

   MUST be passed to the TU, and the client transaction MUST transition

   to the "Completed" state.



   If Timer E fires while in the "Proceeding" state, the request MUST be

   passed to the transport layer for retransmission, and Timer E MUST be

   reset with a value of T2 seconds.  If timer F fires while in the

   "Proceeding" state, the TU MUST be informed of a timeout, and the

   client transaction MUST transition to the terminated state.  If a

   final response (status codes 200-699) is received while in the

   "Proceeding" state, the response MUST be passed to the TU, and the

   client transaction MUST transition to the "Completed" state.



   Once the client transaction enters the "Completed" state, it MUST set

   Timer K to fire in T4 seconds for unreliable transports, and zero

   seconds for reliable transports.  The "Completed" state exists to

   buffer any additional response retransmissions that may be received

   (which is why the client transaction remains there only for







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   unreliable transports).  T4 represents the amount of time the network

   will take to clear messages between client and server transactions.

   The default value of T4 is 5s.  A response is a retransmission when

   it matches the same transaction, using the rules specified in Section

   17.1.3.  If Timer K fires while in this state, the client transaction

   MUST transition to the "Terminated" state.



   Once the transaction is in the terminated state, it MUST be destroyed

   immediately.



17.1.3 Matching Responses to Client Transactions



   When the transport layer in the client receives a response, it has to

   determine which client transaction will handle the response, so that

   the processing of Sections 17.1.1 and 17.1.2 can take place.  The

   branch parameter in the top Via header field is used for this

   purpose.  A response matches a client transaction under two

   conditions:



      1.  If the response has the same value of the branch parameter in

          the top Via header field as the branch parameter in the top

          Via header field of the request that created the transaction.



      2.  If the method parameter in the CSeq header field matches the

          method of the request that created the transaction.  The

          method is needed since a CANCEL request constitutes a

          different transaction, but shares the same value of the branch

          parameter.



   If a request is sent via multicast, it is possible that it will

   generate multiple responses from different servers.  These responses

   will all have the same branch parameter in the topmost Via, but vary

   in the To tag.  The first response received, based on the rules

   above, will be used, and others will be viewed as retransmissions.

   That is not an error; multicast SIP provides only a rudimentary

   "single-hop-discovery-like" service that is limited to processing a

   single response.  See Section 18.1.1 for details.





























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



RFC 3261            SIP: Session Initiation Protocol           June 2002





17.1.4 Handling Transport Errors



                                   |Request from TU

                                   |send request

               Timer E             V

               send request  +-----------+

                   +---------|           |-------------------+

                   |         |  Trying   |  Timer F          |

                   +-------->|           |  or Transport Err.|

                             +-----------+  inform TU        |

                200-699         |  |                         |

                resp. to TU     |  |1xx                      |

                +---------------+  |resp. to TU              |

                |                  |                         |

                |   Timer E        V       Timer F           |

                |   send req +-----------+ or Transport Err. |

                |  +---------|           | inform TU         |

                |  |         |Proceeding |------------------>|

                |  +-------->|           |-----+             |

                |            +-----------+     |1xx          |

                |              |      ^        |resp to TU   |

                | 200-699      |      +--------+             |

                | resp. to TU  |                             |

                |              |                             |

                |              V                             |

                |            +-----------+                   |

                |            |           |                   |

                |            | Completed |                   |

                |            |           |                   |

                |            +-----------+                   |

                |              ^   |                         |

                |              |   | Timer K                 |

                +--------------+   | -                       |

                                   |                         |

                                   V                         |

             NOTE:           +-----------+                   |

                             |           |                   |

         transitions         | Terminated|<------------------+

         labeled with        |           |

         the event           +-----------+

         over the action

         to take



                 Figure 6: non-INVITE client transaction



   When the client transaction sends a request to the transport layer to

   be sent, the following procedures are followed if the transport layer

   indicates a failure.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The client transaction SHOULD inform the TU that a transport failure

   has occurred, and the client transaction SHOULD transition directly

   to the "Terminated" state.  The TU will handle the failover

   mechanisms described in [4].



17.2 Server Transaction



   The server transaction is responsible for the delivery of requests to

   the TU and the reliable transmission of responses.  It accomplishes

   this through a state machine.  Server transactions are created by the

   core when a request is received, and transaction handling is desired

   for that request (this is not always the case).



   As with the client transactions, the state machine depends on whether

   the received request is an INVITE request.



17.2.1 INVITE Server Transaction



   The state diagram for the INVITE server transaction is shown in

   Figure 7.



   When a server transaction is constructed for a request, it enters the

   "Proceeding" state.  The server transaction MUST generate a 100

   (Trying) response unless it knows that the TU will generate a

   provisional or final response within 200 ms, in which case it MAY

   generate a 100 (Trying) response.  This provisional response is

   needed to quench request retransmissions rapidly in order to avoid

   network congestion.  The 100 (Trying) response is constructed

   according to the procedures in Section 8.2.6, except that the

   insertion of tags in the To header field of the response (when none

   was present in the request) is downgraded from MAY to SHOULD NOT.

   The request MUST be passed to the TU.



   The TU passes any number of provisional responses to the server

   transaction.  So long as the server transaction is in the

   "Proceeding" state, each of these MUST be passed to the transport

   layer for transmission.  They are not sent reliably by the

   transaction layer (they are not retransmitted by it) and do not cause

   a change in the state of the server transaction.  If a request

   retransmission is received while in the "Proceeding" state, the most

   recent provisional response that was received from the TU MUST be

   passed to the transport layer for retransmission.  A request is a

   retransmission if it matches the same server transaction based on the

   rules of Section 17.2.3.



   If, while in the "Proceeding" state, the TU passes a 2xx response to

   the server transaction, the server transaction MUST pass this

   response to the transport layer for transmission.  It is not







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   retransmitted by the server transaction; retransmissions of 2xx

   responses are handled by the TU.  The server transaction MUST then

   transition to the "Terminated" state.



   While in the "Proceeding" state, if the TU passes a response with

   status code from 300 to 699 to the server transaction, the response

   MUST be passed to the transport layer for transmission, and the state

   machine MUST enter the "Completed" state.  For unreliable transports,

   timer G is set to fire in T1 seconds, and is not set to fire for

   reliable transports.



      This is a change from RFC 2543, where responses were always

      retransmitted, even over reliable transports.



   When the "Completed" state is entered, timer H MUST be set to fire in

   64*T1 seconds for all transports.  Timer H determines when the server

   transaction abandons retransmitting the response.  Its value is

   chosen to equal Timer B, the amount of time a client transaction will

   continue to retry sending a request.  If timer G fires, the response

   is passed to the transport layer once more for retransmission, and

   timer G is set to fire in MIN(2*T1, T2) seconds.  From then on, when

   timer G fires, the response is passed to the transport again for

   transmission, and timer G is reset with a value that doubles, unless

   that value exceeds T2, in which case it is reset with the value of

   T2.  This is identical to the retransmit behavior for requests in the

   "Trying" state of the non-INVITE client transaction.  Furthermore,

   while in the "Completed" state, if a request retransmission is

   received, the server SHOULD pass the response to the transport for

   retransmission.



   If an ACK is received while the server transaction is in the

   "Completed" state, the server transaction MUST transition to the

   "Confirmed" state.  As Timer G is ignored in this state, any

   retransmissions of the response will cease.



   If timer H fires while in the "Completed" state, it implies that the

   ACK was never received.  In this case, the server transaction MUST

   transition to the "Terminated" state, and MUST indicate to the TU

   that a transaction failure has occurred.

























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



RFC 3261            SIP: Session Initiation Protocol           June 2002





                               |INVITE

                               |pass INV to TU

            INVITE             V send 100 if TU won't in 200ms

            send response+-----------+

                +--------|           |--------+101-199 from TU

                |        | Proceeding|        |send response

                +------->|           |<-------+

                         |           |          Transport Err.

                         |           |          Inform TU

                         |           |--------------->+

                         +-----------+                |

            300-699 from TU |     |2xx from TU        |

            send response   |     |send response      |

                            |     +------------------>+

                            |                         |

            INVITE          V          Timer G fires  |

            send response+-----------+ send response  |

                +--------|           |--------+       |

                |        | Completed |        |       |

                +------->|           |<-------+       |

                         +-----------+                |

                            |     |                   |

                        ACK |     |                   |

                        -   |     +------------------>+

                            |        Timer H fires    |

                            V        or Transport Err.|

                         +-----------+  Inform TU     |

                         |           |                |

                         | Confirmed |                |

                         |           |                |

                         +-----------+                |

                               |                      |

                               |Timer I fires         |

                               |-                     |

                               |                      |

                               V                      |

                         +-----------+                |

                         |           |                |

                         | Terminated|<---------------+

                         |           |

                         +-----------+



              Figure 7: INVITE server transaction

















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The purpose of the "Confirmed" state is to absorb any additional ACK

   messages that arrive, triggered from retransmissions of the final

   response.  When this state is entered, timer I is set to fire in T4

   seconds for unreliable transports, and zero seconds for reliable

   transports.  Once timer I fires, the server MUST transition to the

   "Terminated" state.



   Once the transaction is in the "Terminated" state, it MUST be

   destroyed immediately.  As with client transactions, this is needed

   to ensure reliability of the 2xx responses to INVITE.



17.2.2 Non-INVITE Server Transaction



   The state machine for the non-INVITE server transaction is shown in

   Figure 8.



   The state machine is initialized in the "Trying" state and is passed

   a request other than INVITE or ACK when initialized.  This request is

   passed up to the TU.  Once in the "Trying" state, any further request

   retransmissions are discarded.  A request is a retransmission if it

   matches the same server transaction, using the rules specified in

   Section 17.2.3.



   While in the "Trying" state, if the TU passes a provisional response

   to the server transaction, the server transaction MUST enter the

   "Proceeding" state.  The response MUST be passed to the transport

   layer for transmission.  Any further provisional responses that are

   received from the TU while in the "Proceeding" state MUST be passed

   to the transport layer for transmission.  If a retransmission of the

   request is received while in the "Proceeding" state, the most

   recently sent provisional response MUST be passed to the transport

   layer for retransmission.  If the TU passes a final response (status

   codes 200-699) to the server while in the "Proceeding" state, the

   transaction MUST enter the "Completed" state, and the response MUST

   be passed to the transport layer for transmission.



   When the server transaction enters the "Completed" state, it MUST set

   Timer J to fire in 64*T1 seconds for unreliable transports, and zero

   seconds for reliable transports.  While in the "Completed" state, the

   server transaction MUST pass the final response to the transport

   layer for retransmission whenever a retransmission of the request is

   received.  Any other final responses passed by the TU to the server

   transaction MUST be discarded while in the "Completed" state.  The

   server transaction remains in this state until Timer J fires, at

   which point it MUST transition to the "Terminated" state.



   The server transaction MUST be destroyed the instant it enters the

   "Terminated" state.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





17.2.3 Matching Requests to Server Transactions



   When a request is received from the network by the server, it has to

   be matched to an existing transaction.  This is accomplished in the

   following manner.



   The branch parameter in the topmost Via header field of the request

   is examined.  If it is present and begins with the magic cookie

   "z9hG4bK", the request was generated by a client transaction

   compliant to this specification.  Therefore, the branch parameter

   will be unique across all transactions sent by that client.  The

   request matches a transaction if:



      1. the branch parameter in the request is equal to the one in the

         top Via header field of the request that created the

         transaction, and



      2. the sent-by value in the top Via of the request is equal to the

         one in the request that created the transaction, and



      3. the method of the request matches the one that created the

         transaction, except for ACK, where the method of the request

         that created the transaction is INVITE.



   This matching rule applies to both INVITE and non-INVITE transactions

   alike.



      The sent-by value is used as part of the matching process because

      there could be accidental or malicious duplication of branch

      parameters from different clients.



   If the branch parameter in the top Via header field is not present,

   or does not contain the magic cookie, the following procedures are

   used.  These exist to handle backwards compatibility with RFC 2543

   compliant implementations.



   The INVITE request matches a transaction if the Request-URI, To tag,

   From tag, Call-ID, CSeq, and top Via header field match those of the

   INVITE request which created the transaction.  In this case, the

   INVITE is a retransmission of the original one that created the

   transaction.  The ACK request matches a transaction if the Request-

   URI, From tag, Call-ID, CSeq number (not the method), and top Via

   header field match those of the INVITE request which created the

   transaction, and the To tag of the ACK matches the To tag of the

   response sent by the server transaction.  Matching is done based on

   the matching rules defined for each of those header fields.

   Inclusion of the tag in the To header field in the ACK matching

   process helps disambiguate ACK for 2xx from ACK for other responses







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   at a proxy, which may have forwarded both responses (This can occur

   in unusual conditions.  Specifically, when a proxy forked a request,

   and then crashes, the responses may be delivered to another proxy,

   which might end up forwarding multiple responses upstream).  An ACK

   request that matches an INVITE transaction matched by a previous ACK

   is considered a retransmission of that previous ACK.



























































































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



RFC 3261            SIP: Session Initiation Protocol           June 2002





                                  |Request received

                                  |pass to TU

                                  V

                            +-----------+

                            |           |

                            | Trying    |-------------+

                            |           |             |

                            +-----------+             |200-699 from TU

                                  |                   |send response

                                  |1xx from TU        |

                                  |send response      |

                                  |                   |

               Request            V      1xx from TU  |

               send response+-----------+send response|

                   +--------|           |--------+    |

                   |        | Proceeding|        |    |

                   +------->|           |<-------+    |

            +<--------------|           |             |

            |Trnsprt Err    +-----------+             |

            |Inform TU            |                   |

            |                     |                   |

            |                     |200-699 from TU    |

            |                     |send response      |

            |  Request            V                   |

            |  send response+-----------+             |

            |      +--------|           |             |

            |      |        | Completed |<------------+

            |      +------->|           |

            +<--------------|           |

            |Trnsprt Err    +-----------+

            |Inform TU            |

            |                     |Timer J fires

            |                     |-

            |                     |

            |                     V

            |               +-----------+

            |               |           |

            +-------------->| Terminated|

                            |           |

                            +-----------+



                Figure 8: non-INVITE server transaction



   For all other request methods, a request is matched to a transaction

   if the Request-URI, To tag, From tag, Call-ID, CSeq (including the

   method), and top Via header field match those of the request that

   created the transaction.  Matching is done based on the matching









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   rules defined for each of those header fields.  When a non-INVITE

   request matches an existing transaction, it is a retransmission of

   the request that created that transaction.



   Because the matching rules include the Request-URI, the server cannot

   match a response to a transaction.  When the TU passes a response to

   the server transaction, it must pass it to the specific server

   transaction for which the response is targeted.



17.2.4 Handling Transport Errors



   When the server transaction sends a response to the transport layer

   to be sent, the following procedures are followed if the transport

   layer indicates a failure.



   First, the procedures in [4] are followed, which attempt to deliver

   the response to a backup.  If those should all fail, based on the

   definition of failure in [4], the server transaction SHOULD inform

   the TU that a failure has occurred, and SHOULD transition to the

   terminated state.



18 Transport



   The transport layer is responsible for the actual transmission of

   requests and responses over network transports.  This includes

   determination of the connection to use for a request or response in

   the case of connection-oriented transports.



   The transport layer is responsible for managing persistent

   connections for transport protocols like TCP and SCTP, or TLS over

   those, including ones opened to the transport layer.  This includes

   connections opened by the client or server transports, so that

   connections are shared between client and server transport functions.

   These connections are indexed by the tuple formed from the address,

   port, and transport protocol at the far end of the connection.  When

   a connection is opened by the transport layer, this index is set to

   the destination IP, port and transport.  When the connection is

   accepted by the transport layer, this index is set to the source IP

   address, port number, and transport.  Note that, because the source

   port is often ephemeral, but it cannot be known whether it is

   ephemeral or selected through procedures in [4], connections accepted

   by the transport layer will frequently not be reused.  The result is

   that two proxies in a "peering" relationship using a connection-

   oriented transport frequently will have two connections in use, one

   for transactions initiated in each direction.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   It is RECOMMENDED that connections be kept open for some

   implementation-defined duration after the last message was sent or

   received over that connection.  This duration SHOULD at least equal

   the longest amount of time the element would need in order to bring a

   transaction from instantiation to the terminated state.  This is to

   make it likely that transactions are completed over the same

   connection on which they are initiated (for example, request,

   response, and in the case of INVITE, ACK for non-2xx responses).

   This usually means at least 64*T1 (see Section 17.1.1.1 for a

   definition of T1).  However, it could be larger in an element that

   has a TU using a large value for timer C (bullet 11 of Section 16.6),

   for example.



   All SIP elements MUST implement UDP and TCP.  SIP elements MAY

   implement other protocols.



      Making TCP mandatory for the UA is a substantial change from RFC

      2543.  It has arisen out of the need to handle larger messages,

      which MUST use TCP, as discussed below.  Thus, even if an element

      never sends large messages, it may receive one and needs to be

      able to handle them.



18.1 Clients



18.1.1 Sending Requests



   The client side of the transport layer is responsible for sending the

   request and receiving responses.  The user of the transport layer

   passes the client transport the request, an IP address, port,

   transport, and possibly TTL for multicast destinations.



   If a request is within 200 bytes of the path MTU, or if it is larger

   than 1300 bytes and the path MTU is unknown, the request MUST be sent

   using an RFC 2914 [43] congestion controlled transport protocol, such

   as TCP. If this causes a change in the transport protocol from the

   one indicated in the top Via, the value in the top Via MUST be

   changed.  This prevents fragmentation of messages over UDP and

   provides congestion control for larger messages.  However,

   implementations MUST be able to handle messages up to the maximum

   datagram packet size.  For UDP, this size is 65,535 bytes, including

   IP and UDP headers.



      The 200 byte "buffer" between the message size and the MTU

      accommodates the fact that the response in SIP can be larger than

      the request.  This happens due to the addition of Record-Route

      header field values to the responses to INVITE, for example.  With

      the extra buffer, the response can be about 170 bytes larger than

      the request, and still not be fragmented on IPv4 (about 30 bytes







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      is consumed by IP/UDP, assuming no IPSec).  1300 is chosen when

      path MTU is not known, based on the assumption of a 1500 byte

      Ethernet MTU.



   If an element sends a request over TCP because of these message size

   constraints, and that request would have otherwise been sent over

   UDP, if the attempt to establish the connection generates either an

   ICMP Protocol Not Supported, or results in a TCP reset, the element

   SHOULD retry the request, using UDP.  This is only to provide

   backwards compatibility with RFC 2543 compliant implementations that

   do not support TCP.  It is anticipated that this behavior will be

   deprecated in a future revision of this specification.



   A client that sends a request to a multicast address MUST add the

   "maddr" parameter to its Via header field value containing the

   destination multicast address, and for IPv4, SHOULD add the "ttl"

   parameter with a value of 1.  Usage of IPv6 multicast is not defined

   in this specification, and will be a subject of future

   standardization when the need arises.



   These rules result in a purposeful limitation of multicast in SIP.

   Its primary function is to provide a "single-hop-discovery-like"

   service, delivering a request to a group of homogeneous servers,

   where it is only required to process the response from any one of

   them.  This functionality is most useful for registrations.  In fact,

   based on the transaction processing rules in Section 17.1.3, the

   client transaction will accept the first response, and view any

   others as retransmissions because they all contain the same Via

   branch identifier.



   Before a request is sent, the client transport MUST insert a value of

   the "sent-by" field into the Via header field.  This field contains

   an IP address or host name, and port.  The usage of an FQDN is

   RECOMMENDED.  This field is used for sending responses under certain

   conditions, described below.  If the port is absent, the default

   value depends on the transport.  It is 5060 for UDP, TCP and SCTP,

   5061 for TLS.



   For reliable transports, the response is normally sent on the

   connection on which the request was received.  Therefore, the client

   transport MUST be prepared to receive the response on the same

   connection used to send the request.  Under error conditions, the

   server may attempt to open a new connection to send the response.  To

   handle this case, the transport layer MUST also be prepared to

   receive an incoming connection on the source IP address from which

   the request was sent and port number in the "sent-by" field.  It also











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   MUST be prepared to receive incoming connections on any address and

   port that would be selected by a server based on the procedures

   described in Section 5 of [4].



   For unreliable unicast transports, the client transport MUST be

   prepared to receive responses on the source IP address from which the

   request is sent (as responses are sent back to the source address)

   and the port number in the "sent-by" field.  Furthermore, as with

   reliable transports, in certain cases the response will be sent

   elsewhere.  The client MUST be prepared to receive responses on any

   address and port that would be selected by a server based on the

   procedures described in Section 5 of [4].



   For multicast, the client transport MUST be prepared to receive

   responses on the same multicast group and port to which the request

   is sent (that is, it needs to be a member of the multicast group it

   sent the request to.)



   If a request is destined to an IP address, port, and transport to

   which an existing connection is open, it is RECOMMENDED that this

   connection be used to send the request, but another connection MAY be

   opened and used.



   If a request is sent using multicast, it is sent to the group

   address, port, and TTL provided by the transport user.  If a request

   is sent using unicast unreliable transports, it is sent to the IP

   address and port provided by the transport user.



18.1.2 Receiving Responses



   When a response is received, the client transport examines the top

   Via header field value.  If the value of the "sent-by" parameter in

   that header field value does not correspond to a value that the

   client transport is configured to insert into requests, the response

   MUST be silently discarded.



   If there are any client transactions in existence, the client

   transport uses the matching procedures of Section 17.1.3 to attempt

   to match the response to an existing transaction.  If there is a

   match, the response MUST be passed to that transaction.  Otherwise,

   the response MUST be passed to the core (whether it be stateless

   proxy, stateful proxy, or UA) for further processing.  Handling of

   these "stray" responses is dependent on the core (a proxy will

   forward them, while a UA will discard, for example).















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





18.2 Servers



18.2.1 Receiving Requests



   A server SHOULD be prepared to receive requests on any IP address,

   port and transport combination that can be the result of a DNS lookup

   on a SIP or SIPS URI [4] that is handed out for the purposes of

   communicating with that server.  In this context, "handing out"

   includes placing a URI in a Contact header field in a REGISTER

   request or a redirect response, or in a Record-Route header field in

   a request or response.  A URI can also be "handed out" by placing it

   on a web page or business card.  It is also RECOMMENDED that a server

   listen for requests on the default SIP ports (5060 for TCP and UDP,

   5061 for TLS over TCP) on all public interfaces.  The typical

   exception would be private networks, or when multiple server

   instances are running on the same host.  For any port and interface

   that a server listens on for UDP, it MUST listen on that same port

   and interface for TCP.  This is because a message may need to be sent

   using TCP, rather than UDP, if it is too large.  As a result, the

   converse is not true.  A server need not listen for UDP on a

   particular address and port just because it is listening on that same

   address and port for TCP.  There may, of course, be other reasons why

   a server needs to listen for UDP on a particular address and port.



   When the server transport receives a request over any transport, it

   MUST examine the value of the "sent-by" parameter in the top Via

   header field value.  If the host portion of the "sent-by" parameter

   contains a domain name, or if it contains an IP address that differs

   from the packet source address, the server MUST add a "received"

   parameter to that Via header field value.  This parameter MUST

   contain the source address from which the packet was received.  This

   is to assist the server transport layer in sending the response,

   since it must be sent to the source IP address from which the request

   came.



   Consider a request received by the server transport which looks like,

   in part:



      INVITE sip:bob@Biloxi.com SIP/2.0

      Via: SIP/2.0/UDP bobspc.biloxi.com:5060



   The request is received with a source IP address of 192.0.2.4.

   Before passing the request up, the transport adds a "received"

   parameter, so that the request would look like, in part:



      INVITE sip:bob@Biloxi.com SIP/2.0

      Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Next, the server transport attempts to match the request to a server

   transaction.  It does so using the matching rules described in

   Section 17.2.3.  If a matching server transaction is found, the

   request is passed to that transaction for processing.  If no match is

   found, the request is passed to the core, which may decide to

   construct a new server transaction for that request.  Note that when

   a UAS core sends a 2xx response to INVITE, the server transaction is

   destroyed.  This means that when the ACK arrives, there will be no

   matching server transaction, and based on this rule, the ACK is

   passed to the UAS core, where it is processed.



18.2.2 Sending Responses



   The server transport uses the value of the top Via header field in

   order to determine where to send a response.  It MUST follow the

   following process:



      o  If the "sent-protocol" is a reliable transport protocol such as

         TCP or SCTP, or TLS over those, the response MUST be sent using

         the existing connection to the source of the original request

         that created the transaction, if that connection is still open.

         This requires the server transport to maintain an association

         between server transactions and transport connections.  If that

         connection is no longer open, the server SHOULD open a

         connection to the IP address in the "received" parameter, if

         present, using the port in the "sent-by" value, or the default

         port for that transport, if no port is specified.  If that

         connection attempt fails, the server SHOULD use the procedures

         in [4] for servers in order to determine the IP address and

         port to open the connection and send the response to.



      o  Otherwise, if the Via header field value contains a "maddr"

         parameter, the response MUST be forwarded to the address listed

         there, using the port indicated in "sent-by", or port 5060 if

         none is present.  If the address is a multicast address, the

         response SHOULD be sent using the TTL indicated in the "ttl"

         parameter, or with a TTL of 1 if that parameter is not present.



      o  Otherwise (for unreliable unicast transports), if the top Via

         has a "received" parameter, the response MUST be sent to the

         address in the "received" parameter, using the port indicated

         in the "sent-by" value, or using port 5060 if none is specified

         explicitly.  If this fails, for example, elicits an ICMP "port

         unreachable" response, the procedures of Section 5 of [4]

         SHOULD be used to determine where to send the response.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      o  Otherwise, if it is not receiver-tagged, the response MUST be

         sent to the address indicated by the "sent-by" value, using the

         procedures in Section 5 of [4].



18.3 Framing



   In the case of message-oriented transports (such as UDP), if the

   message has a Content-Length header field, the message body is

   assumed to contain that many bytes.  If there are additional bytes in

   the transport packet beyond the end of the body, they MUST be

   discarded.  If the transport packet ends before the end of the

   message body, this is considered an error.  If the message is a

   response, it MUST be discarded.  If the message is a request, the

   element SHOULD generate a 400 (Bad Request) response.  If the message

   has no Content-Length header field, the message body is assumed to

   end at the end of the transport packet.



   In the case of stream-oriented transports such as TCP, the Content-

   Length header field indicates the size of the body.  The Content-

   Length header field MUST be used with stream oriented transports.



18.4 Error Handling



   Error handling is independent of whether the message was a request or

   response.



   If the transport user asks for a message to be sent over an

   unreliable transport, and the result is an ICMP error, the behavior

   depends on the type of ICMP error.  Host, network, port or protocol

   unreachable errors, or parameter problem errors SHOULD cause the

   transport layer to inform the transport user of a failure in sending.

   Source quench and TTL exceeded ICMP errors SHOULD be ignored.



   If the transport user asks for a request to be sent over a reliable

   transport, and the result is a connection failure, the transport

   layer SHOULD inform the transport user of a failure in sending.



19 Common Message Components



   There are certain components of SIP messages that appear in various

   places within SIP messages (and sometimes, outside of them) that

   merit separate discussion.



















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





19.1 SIP and SIPS Uniform Resource Indicators



   A SIP or SIPS URI identifies a communications resource.  Like all

   URIs, SIP and SIPS URIs may be placed in web pages, email messages,

   or printed literature.  They contain sufficient information to

   initiate and maintain a communication session with the resource.



   Examples of communications resources include the following:



      o  a user of an online service



      o  an appearance on a multi-line phone



      o  a mailbox on a messaging system



      o  a PSTN number at a gateway service



      o  a group (such as "sales" or "helpdesk") in an organization



   A SIPS URI specifies that the resource be contacted securely.  This

   means, in particular, that TLS is to be used between the UAC and the

   domain that owns the URI.  From there, secure communications are used

   to reach the user, where the specific security mechanism depends on

   the policy of the domain.  Any resource described by a SIP URI can be

   "upgraded" to a SIPS URI by just changing the scheme, if it is

   desired to communicate with that resource securely.



19.1.1 SIP and SIPS URI Components



   The "sip:" and "sips:" schemes follow the guidelines in RFC 2396 [5].

   They use a form similar to the mailto URL, allowing the specification

   of SIP request-header fields and the SIP message-body.  This makes it

   possible to specify the subject, media type, or urgency of sessions

   initiated by using a URI on a web page or in an email message.  The

   formal syntax for a SIP or SIPS URI is presented in Section 25.  Its

   general form, in the case of a SIP URI, is:



      sip:user:password@host:port;uri-parameters?headers



   The format for a SIPS URI is the same, except that the scheme is

   "sips" instead of sip.  These tokens, and some of the tokens in their

   expansions, have the following meanings:



      user: The identifier of a particular resource at the host being

         addressed.  The term "host" in this context frequently refers

         to a domain.  The "userinfo" of a URI consists of this user

         field, the password field, and the @ sign following them.  The

         userinfo part of a URI is optional and MAY be absent when the







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         destination host does not have a notion of users or when the

         host itself is the resource being identified.  If the @ sign is

         present in a SIP or SIPS URI, the user field MUST NOT be empty.



         If the host being addressed can process telephone numbers, for

         instance, an Internet telephony gateway, a telephone-

         subscriber field defined in RFC 2806 [9] MAY be used to

         populate the user field.  There are special escaping rules for

         encoding telephone-subscriber fields in SIP and SIPS URIs

         described in Section 19.1.2.



      password: A password associated with the user.  While the SIP and

         SIPS URI syntax allows this field to be present, its use is NOT

         RECOMMENDED, because the passing of authentication information

         in clear text (such as URIs) has proven to be a security risk

         in almost every case where it has been used.  For instance,

         transporting a PIN number in this field exposes the PIN.



         Note that the password field is just an extension of the user

         portion.  Implementations not wishing to give special

         significance to the password portion of the field MAY simply

         treat "user:password" as a single string.



      host: The host providing the SIP resource.  The host part contains

         either a fully-qualified domain name or numeric IPv4 or IPv6

         address.  Using the fully-qualified domain name form is

         RECOMMENDED whenever possible.



      port: The port number where the request is to be sent.



      URI parameters: Parameters affecting a request constructed from

         the URI.



         URI parameters are added after the hostport component and are

         separated by semi-colons.



         URI parameters take the form:



            parameter-name "=" parameter-value



         Even though an arbitrary number of URI parameters may be

         included in a URI, any given parameter-name MUST NOT appear

         more than once.



         This extensible mechanism includes the transport, maddr, ttl,

         user, method and lr parameters.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         The transport parameter determines the transport mechanism to

         be used for sending SIP messages, as specified in [4].  SIP can

         use any network transport protocol.  Parameter names are

         defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP

         (RFC 2960 [16]).  For a SIPS URI, the transport parameter MUST

         indicate a reliable transport.



         The maddr parameter indicates the server address to be

         contacted for this user, overriding any address derived from

         the host field.  When an maddr parameter is present, the port

         and transport components of the URI apply to the address

         indicated in the maddr parameter value.  [4] describes the

         proper interpretation of the transport, maddr, and hostport in

         order to obtain the destination address, port, and transport

         for sending a request.



         The maddr field has been used as a simple form of loose source

         routing.  It allows a URI to specify a proxy that must be

         traversed en-route to the destination.  Continuing to use the

         maddr parameter this way is strongly discouraged (the

         mechanisms that enable it are deprecated).  Implementations

         should instead use the Route mechanism described in this

         document, establishing a pre-existing route set if necessary

         (see Section 8.1.1.1).  This provides a full URI to describe

         the node to be traversed.



         The ttl parameter determines the time-to-live value of the UDP

         multicast packet and MUST only be used if maddr is a multicast

         address and the transport protocol is UDP.  For example, to

         specify a call to alice@atlanta.com using multicast to

         239.255.255.1 with a ttl of 15, the following URI would be

         used:



            sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15



         The set of valid telephone-subscriber strings is a subset of

         valid user strings.  The user URI parameter exists to

         distinguish telephone numbers from user names that happen to

         look like telephone numbers.  If the user string contains a

         telephone number formatted as a telephone-subscriber, the user

         parameter value "phone" SHOULD be present.  Even without this

         parameter, recipients of SIP and SIPS URIs MAY interpret the

         pre-@ part as a telephone number if local restrictions on the

         name space for user name allow it.



         The method of the SIP request constructed from the URI can be

         specified with the method parameter.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         The lr parameter, when present, indicates that the element

         responsible for this resource implements the routing mechanisms

         specified in this document.  This parameter will be used in the

         URIs proxies place into Record-Route header field values, and

         may appear in the URIs in a pre-existing route set.



         This parameter is used to achieve backwards compatibility with

         systems implementing the strict-routing mechanisms of RFC 2543

         and the rfc2543bis drafts up to bis-05.  An element preparing

         to send a request based on a URI not containing this parameter

         can assume the receiving element implements strict-routing and

         reformat the message to preserve the information in the

         Request-URI.



         Since the uri-parameter mechanism is extensible, SIP elements

         MUST silently ignore any uri-parameters that they do not

         understand.



      Headers: Header fields to be included in a request constructed

         from the URI.



         Headers fields in the SIP request can be specified with the "?"

         mechanism within a URI.  The header names and values are

         encoded in ampersand separated hname = hvalue pairs.  The

         special hname "body" indicates that the associated hvalue is

         the message-body of the SIP request.



   Table 1 summarizes the use of SIP and SIPS URI components based on

   the context in which the URI appears.  The external column describes

   URIs appearing anywhere outside of a SIP message, for instance on a

   web page or business card.  Entries marked "m" are mandatory, those

   marked "o" are optional, and those marked "-" are not allowed.

   Elements processing URIs SHOULD ignore any disallowed components if

   they are present.  The second column indicates the default value of

   an optional element if it is not present.  "--" indicates that the

   element is either not optional, or has no default value.



   URIs in Contact header fields have different restrictions depending

   on the context in which the header field appears.  One set applies to

   messages that establish and maintain dialogs (INVITE and its 200 (OK)

   response).  The other applies to registration and redirection

   messages (REGISTER, its 200 (OK) response, and 3xx class responses to

   any method).

















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





19.1.2 Character Escaping Requirements



                                                       dialog

                                          reg./redir. Contact/

              default  Req.-URI  To  From  Contact   R-R/Route  external

user          --          o      o    o       o          o         o

password      --          o      o    o       o          o         o

host          --          m      m    m       m          m         m

port          (1)         o      -    -       o          o         o

user-param    ip          o      o    o       o          o         o

method        INVITE      -      -    -       -          -         o

maddr-param   --          o      -    -       o          o         o

ttl-param     1           o      -    -       o          -         o

transp.-param (2)         o      -    -       o          o         o

lr-param      --          o      -    -       -          o         o

other-param   --          o      o    o       o          o         o

headers       --          -      -    -       o          -         o



   (1): The default port value is transport and scheme dependent.  The

   default  is  5060  for  sip: using UDP, TCP, or SCTP.  The default is

   5061 for sip: using TLS over TCP and sips: over TCP.



   (2): The default transport is scheme dependent.  For sip:, it is UDP.

   For sips:, it is TCP.



   Table 1: Use and default values of URI components for SIP header

   field values, Request-URI and references



   SIP follows the requirements and guidelines of RFC 2396 [5] when

   defining the set of characters that must be escaped in a SIP URI, and

   uses its ""%" HEX HEX" mechanism for escaping.  From RFC 2396 [5]:



      The set of characters actually reserved within any given URI

      component is defined by that component.  In general, a character

      is reserved if the semantics of the URI changes if the character

      is replaced with its escaped US-ASCII encoding [5].  Excluded US-

      ASCII characters (RFC 2396 [5]), such as space and control

      characters and characters used as URI delimiters, also MUST be

      escaped.  URIs MUST NOT contain unescaped space and control

      characters.



   For each component, the set of valid BNF expansions defines exactly

   which characters may appear unescaped.  All other characters MUST be

   escaped.



   For example, "@" is not in the set of characters in the user

   component, so the user "j@s0n" must have at least the @ sign encoded,

   as in "j%40s0n".







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Expanding the hname and hvalue tokens in Section 25 show that all URI

   reserved characters in header field names and values MUST be escaped.



   The telephone-subscriber subset of the user component has special

   escaping considerations.  The set of characters not reserved in the

   RFC 2806 [9] description of telephone-subscriber contains a number of

   characters in various syntax elements that need to be escaped when

   used in SIP URIs.  Any characters occurring in a telephone-subscriber

   that do not appear in an expansion of the BNF for the user rule MUST

   be escaped.



   Note that character escaping is not allowed in the host component of

   a SIP or SIPS URI (the % character is not valid in its expansion).

   This is likely to change in the future as requirements for

   Internationalized Domain Names are finalized.  Current

   implementations MUST NOT attempt to improve robustness by treating

   received escaped characters in the host component as literally

   equivalent to their unescaped counterpart.  The behavior required to

   meet the requirements of IDN may be significantly different.



19.1.3 Example SIP and SIPS URIs



   sip:alice@atlanta.com

   sip:alice:secretword@atlanta.com;transport=tcp

   sips:alice@atlanta.com?subject=project%20x&priority=urgent

   sip:+1-212-555-1212:1234@gateway.com;user=phone

   sips:1212@gateway.com

   sip:alice@192.0.2.4

   sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com

   sip:alice;day=tuesday@atlanta.com



   The last sample URI above has a user field value of

   "alice;day=tuesday".  The escaping rules defined above allow a

   semicolon to appear unescaped in this field.  For the purposes of

   this protocol, the field is opaque.  The structure of that value is

   only useful to the SIP element responsible for the resource.



19.1.4 URI Comparison



   Some operations in this specification require determining whether two

   SIP or SIPS URIs are equivalent.  In this specification, registrars

   need to compare bindings in Contact URIs in REGISTER requests (see

   Section 10.3.).  SIP and SIPS URIs are compared for equality

   according to the following rules:



      o  A SIP and SIPS URI are never equivalent.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      o  Comparison of the userinfo of SIP and SIPS URIs is case-

         sensitive.  This includes userinfo containing passwords or

         formatted as telephone-subscribers.  Comparison of all other

         components of the URI is case-insensitive unless explicitly

         defined otherwise.



      o  The ordering of parameters and header fields is not significant

         in comparing SIP and SIPS URIs.



      o  Characters other than those in the "reserved" set (see RFC 2396

         [5]) are equivalent to their ""%" HEX HEX" encoding.



      o  An IP address that is the result of a DNS lookup of a host name

         does not match that host name.



      o  For two URIs to be equal, the user, password, host, and port

         components must match.



         A URI omitting the user component will not match a URI that

         includes one.  A URI omitting the password component will not

         match a URI that includes one.



         A URI omitting any component with a default value will not

         match a URI explicitly containing that component with its

         default value.  For instance, a URI omitting the optional port

         component will not match a URI explicitly declaring port 5060.

         The same is true for the transport-parameter, ttl-parameter,

         user-parameter, and method components.



            Defining sip:user@host to not be equivalent to

            sip:user@host:5060 is a change from RFC 2543.  When deriving

            addresses from URIs, equivalent addresses are expected from

            equivalent URIs.  The URI sip:user@host:5060 will always

            resolve to port 5060.  The URI sip:user@host may resolve to

            other ports through the DNS SRV mechanisms detailed in [4].



      o  URI uri-parameter components are compared as follows:



         -  Any uri-parameter appearing in both URIs must match.



         -  A user, ttl, or method uri-parameter appearing in only one

            URI never matches, even if it contains the default value.



         -  A URI that includes an maddr parameter will not match a URI

            that contains no maddr parameter.



         -  All other uri-parameters appearing in only one URI are

            ignored when comparing the URIs.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      o  URI header components are never ignored.  Any present header

         component MUST be present in both URIs and match for the URIs

         to match.  The matching rules are defined for each header field

         in Section 20.



   The URIs within each of the following sets are equivalent:



   sip:%61lice@atlanta.com;transport=TCP

   sip:alice@AtLanTa.CoM;Transport=tcp



   sip:carol@chicago.com

   sip:carol@chicago.com;newparam=5

   sip:carol@chicago.com;security=on



   sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com

   sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com



   sip:alice@atlanta.com?subject=project%20x&priority=urgent

   sip:alice@atlanta.com?priority=urgent&subject=project%20x



   The URIs within each of the following sets are not equivalent:



   SIP:ALICE@AtLanTa.CoM;Transport=udp             (different usernames)

   sip:alice@AtLanTa.CoM;Transport=UDP



   sip:bob@biloxi.com                   (can resolve to different ports)

   sip:bob@biloxi.com:5060



   sip:bob@biloxi.com              (can resolve to different transports)

   sip:bob@biloxi.com;transport=udp



   sip:bob@biloxi.com     (can resolve to different port and transports)

   sip:bob@biloxi.com:6000;transport=tcp



   sip:carol@chicago.com                    (different header component)

   sip:carol@chicago.com?Subject=next%20meeting



   sip:bob@phone21.boxesbybob.com   (even though that's what

   sip:bob@192.0.2.4                 phone21.boxesbybob.com resolves to)



   Note that equality is not transitive:



      o  sip:carol@chicago.com and sip:carol@chicago.com;security=on are

         equivalent



      o  sip:carol@chicago.com and sip:carol@chicago.com;security=off

         are equivalent









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      o  sip:carol@chicago.com;security=on and

         sip:carol@chicago.com;security=off are not equivalent



19.1.5 Forming Requests from a URI



   An implementation needs to take care when forming requests directly

   from a URI.  URIs from business cards, web pages, and even from

   sources inside the protocol such as registered contacts may contain

   inappropriate header fields or body parts.



   An implementation MUST include any provided transport, maddr, ttl, or

   user parameter in the Request-URI of the formed request.  If the URI

   contains a method parameter, its value MUST be used as the method of

   the request.  The method parameter MUST NOT be placed in the

   Request-URI.  Unknown URI parameters MUST be placed in the message's

   Request-URI.



   An implementation SHOULD treat the presence of any headers or body

   parts in the URI as a desire to include them in the message, and

   choose to honor the request on a per-component basis.



   An implementation SHOULD NOT honor these obviously dangerous header

   fields: From, Call-ID, CSeq, Via, and Record-Route.



   An implementation SHOULD NOT honor any requested Route header field

   values in order to not be used as an unwitting agent in malicious

   attacks.



   An implementation SHOULD NOT honor requests to include header fields

   that may cause it to falsely advertise its location or capabilities.

   These include: Accept, Accept-Encoding, Accept-Language, Allow,

   Contact (in its dialog usage), Organization, Supported, and User-

   Agent.



   An implementation SHOULD verify the accuracy of any requested

   descriptive header fields, including: Content-Disposition, Content-

   Encoding, Content-Language, Content-Length, Content-Type, Date,

   Mime-Version, and Timestamp.



   If the request formed from constructing a message from a given URI is

   not a valid SIP request, the URI is invalid.  An implementation MUST

   NOT proceed with transmitting the request.  It should instead pursue

   the course of action due an invalid URI in the context it occurs.



      The constructed request can be invalid in many ways.  These

      include, but are not limited to, syntax error in header fields,

      invalid combinations of URI parameters, or an incorrect

      description of the message body.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Sending a request formed from a given URI may require capabilities

   unavailable to the implementation.  The URI might indicate use of an

   unimplemented transport or extension, for example.  An implementation

   SHOULD refuse to send these requests rather than modifying them to

   match their capabilities.  An implementation MUST NOT send a request

   requiring an extension that it does not support.



      For example, such a request can be formed through the presence of

      a Require header parameter or a method URI parameter with an

      unknown or explicitly unsupported value.



19.1.6 Relating SIP URIs and tel URLs



   When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the

   entire telephone-subscriber portion of the tel URL, including any

   parameters, is placed into the userinfo part of the SIP or SIPS URI.



   Thus, tel:+358-555-1234567;postd=pp22 becomes



      sip:+358-555-1234567;postd=pp22@foo.com;user=phone



   or

      sips:+358-555-1234567;postd=pp22@foo.com;user=phone



   not

      sip:+358-555-1234567@foo.com;postd=pp22;user=phone



   or



      sips:+358-555-1234567@foo.com;postd=pp22;user=phone



   In general, equivalent "tel" URLs converted to SIP or SIPS URIs in

   this fashion may not produce equivalent SIP or SIPS URIs.  The

   userinfo of SIP and SIPS URIs are compared as a case-sensitive

   string.  Variance in case-insensitive portions of tel URLs and

   reordering of tel URL parameters does not affect tel URL equivalence,

   but does affect the equivalence of SIP URIs formed from them.



   For example,



      tel:+358-555-1234567;postd=pp22

      tel:+358-555-1234567;POSTD=PP22



   are equivalent, while



      sip:+358-555-1234567;postd=pp22@foo.com;user=phone

      sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   are not.



   Likewise,



      tel:+358-555-1234567;postd=pp22;isub=1411

      tel:+358-555-1234567;isub=1411;postd=pp22



   are equivalent, while



      sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone

      sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone



   are not.



   To mitigate this problem, elements constructing telephone-subscriber

   fields to place in the userinfo part of a SIP or SIPS URI SHOULD fold

   any case-insensitive portion of telephone-subscriber to lower case,

   and order the telephone-subscriber parameters lexically by parameter

   name, excepting isdn-subaddress and post-dial, which occur first and

   in that order.  (All components of a tel URL except for future-

   extension parameters are defined to be compared case-insensitive.)



   Following this suggestion, both



      tel:+358-555-1234567;postd=pp22

      tel:+358-555-1234567;POSTD=PP22



      become



        sip:+358-555-1234567;postd=pp22@foo.com;user=phone



   and both



        tel:+358-555-1234567;tsp=a.b;phone-context=5

        tel:+358-555-1234567;phone-context=5;tsp=a.b



      become



        sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone



19.2 Option Tags



   Option tags are unique identifiers used to designate new options

   (extensions) in SIP.  These tags are used in Require (Section 20.32),

   Proxy-Require (Section 20.29), Supported (Section 20.37) and

   Unsupported (Section 20.40) header fields.  Note that these options

   appear as parameters in those header fields in an option-tag = token

   form (see Section 25 for the definition of token).







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Option tags are defined in standards track RFCs.  This is a change

   from past practice, and is instituted to ensure continuing multi-

   vendor interoperability (see discussion in Section 20.32 and Section

   20.37).  An IANA registry of option tags is used to ensure easy

   reference.



19.3 Tags



   The "tag" parameter is used in the To and From header fields of SIP

   messages.  It serves as a general mechanism to identify a dialog,

   which is the combination of the Call-ID along with two tags, one from

   each participant in the dialog.  When a UA sends a request outside of

   a dialog, it contains a From tag only, providing "half" of the dialog

   ID.  The dialog is completed from the response(s), each of which

   contributes the second half in the To header field.  The forking of

   SIP requests means that multiple dialogs can be established from a

   single request.  This also explains the need for the two-sided dialog

   identifier; without a contribution from the recipients, the

   originator could not disambiguate the multiple dialogs established

   from a single request.



   When a tag is generated by a UA for insertion into a request or

   response, it MUST be globally unique and cryptographically random

   with at least 32 bits of randomness.  A property of this selection

   requirement is that a UA will place a different tag into the From

   header of an INVITE than it would place into the To header of the

   response to the same INVITE.  This is needed in order for a UA to

   invite itself to a session, a common case for "hairpinning" of calls

   in PSTN gateways.  Similarly, two INVITEs for different calls will

   have different From tags, and two responses for different calls will

   have different To tags.



   Besides the requirement for global uniqueness, the algorithm for

   generating a tag is implementation-specific.  Tags are helpful in

   fault tolerant systems, where a dialog is to be recovered on an

   alternate server after a failure.  A UAS can select the tag in such a

   way that a backup can recognize a request as part of a dialog on the

   failed server, and therefore determine that it should attempt to

   recover the dialog and any other state associated with it.



20 Header Fields



   The general syntax for header fields is covered in Section 7.3.  This

   section lists the full set of header fields along with notes on

   syntax, meaning, and usage.  Throughout this section, we use [HX.Y]

   to refer to Section X.Y of the current HTTP/1.1 specification RFC

   2616 [8].  Examples of each header field are given.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Information about header fields in relation to methods and proxy

   processing is summarized in Tables 2 and 3.



   The "where" column describes the request and response types in which

   the header field can be used.  Values in this column are:



      R: header field may only appear in requests;



      r: header field may only appear in responses;



      2xx, 4xx, etc.: A numerical value or range indicates response

           codes with which the header field can be used;



      c: header field is copied from the request to the response.



      An empty entry in the "where" column indicates that the header

           field may be present in all requests and responses.



   The "proxy" column describes the operations a proxy may perform on a

   header field:



      a: A proxy can add or concatenate the header field if not present.



      m: A proxy can modify an existing header field value.



      d: A proxy can delete a header field value.



      r: A proxy must be able to read the header field, and thus this

           header field cannot be encrypted.



   The next six columns relate to the presence of a header field in a

   method:



      c: Conditional; requirements on the header field depend on the

           context of the message.



      m: The header field is mandatory.



      m*: The header field SHOULD be sent, but clients/servers need to

           be prepared to receive messages without that header field.



      o: The header field is optional.



      t: The header field SHOULD be sent, but clients/servers need to be

           prepared to receive messages without that header field.



           If a stream-based protocol (such as TCP) is used as a

           transport, then the header field MUST be sent.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      *: The header field is required if the message body is not empty.

           See Sections 20.14, 20.15 and 7.4 for details.



      -: The header field is not applicable.



   "Optional" means that an element MAY include the header field in a

   request or response, and a UA MAY ignore the header field if present

   in the request or response (The exception to this rule is the Require

   header field discussed in 20.32).  A "mandatory" header field MUST be

   present in a request, and MUST be understood by the UAS receiving the

   request.  A mandatory response header field MUST be present in the

   response, and the header field MUST be understood by the UAC

   processing the response.  "Not applicable" means that the header

   field MUST NOT be present in a request.  If one is placed in a

   request by mistake, it MUST be ignored by the UAS receiving the

   request.  Similarly, a header field labeled "not applicable" for a

   response means that the UAS MUST NOT place the header field in the

   response, and the UAC MUST ignore the header field in the response.



   A UA SHOULD ignore extension header parameters that are not

   understood.



   A compact form of some common header field names is also defined for

   use when overall message size is an issue.



   The Contact, From, and To header fields contain a URI.  If the URI

   contains a comma, question mark or semicolon, the URI MUST be

   enclosed in angle brackets (< and >).  Any URI parameters are

   contained within these brackets.  If the URI is not enclosed in angle

   brackets, any semicolon-delimited parameters are header-parameters,

   not URI parameters.



20.1 Accept



   The Accept header field follows the syntax defined in [H14.1].  The

   semantics are also identical, with the exception that if no Accept

   header field is present, the server SHOULD assume a default value of

   application/sdp.



   An empty Accept header field means that no formats are acceptable.























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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Example:



      Header field          where   proxy ACK BYE CAN INV OPT REG

      ___________________________________________________________

      Accept                  R            -   o   -   o   m*  o

      Accept                 2xx           -   -   -   o   m*  o

      Accept                 415           -   c   -   c   c   c

      Accept-Encoding         R            -   o   -   o   o   o

      Accept-Encoding        2xx           -   -   -   o   m*  o

      Accept-Encoding        415           -   c   -   c   c   c

      Accept-Language         R            -   o   -   o   o   o

      Accept-Language        2xx           -   -   -   o   m*  o

      Accept-Language        415           -   c   -   c   c   c

      Alert-Info              R      ar    -   -   -   o   -   -

      Alert-Info             180     ar    -   -   -   o   -   -

      Allow                   R            -   o   -   o   o   o

      Allow                  2xx           -   o   -   m*  m*  o

      Allow                   r            -   o   -   o   o   o

      Allow                  405           -   m   -   m   m   m

      Authentication-Info    2xx           -   o   -   o   o   o

      Authorization           R            o   o   o   o   o   o

      Call-ID                 c       r    m   m   m   m   m   m

      Call-Info                      ar    -   -   -   o   o   o

      Contact                 R            o   -   -   m   o   o

      Contact                1xx           -   -   -   o   -   -

      Contact                2xx           -   -   -   m   o   o

      Contact                3xx      d    -   o   -   o   o   o

      Contact                485           -   o   -   o   o   o

      Content-Disposition                  o   o   -   o   o   o

      Content-Encoding                     o   o   -   o   o   o

      Content-Language                     o   o   -   o   o   o

      Content-Length                 ar    t   t   t   t   t   t

      Content-Type                         *   *   -   *   *   *

      CSeq                    c       r    m   m   m   m   m   m

      Date                            a    o   o   o   o   o   o

      Error-Info           300-699    a    -   o   o   o   o   o

      Expires                              -   -   -   o   -   o

      From                    c       r    m   m   m   m   m   m

      In-Reply-To             R            -   -   -   o   -   -

      Max-Forwards            R      amr   m   m   m   m   m   m

      Min-Expires            423           -   -   -   -   -   m

      MIME-Version                         o   o   -   o   o   o

      Organization                   ar    -   -   -   o   o   o



             Table 2: Summary of header fields, A--O













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Header field              where       proxy ACK BYE CAN INV OPT REG

   ___________________________________________________________________

   Priority                    R          ar    -   -   -   o   -   -

   Proxy-Authenticate         407         ar    -   m   -   m   m   m

   Proxy-Authenticate         401         ar    -   o   o   o   o   o

   Proxy-Authorization         R          dr    o   o   -   o   o   o

   Proxy-Require               R          ar    -   o   -   o   o   o

   Record-Route                R          ar    o   o   o   o   o   -

   Record-Route             2xx,18x       mr    -   o   o   o   o   -

   Reply-To                                     -   -   -   o   -   -

   Require                                ar    -   c   -   c   c   c

   Retry-After          404,413,480,486         -   o   o   o   o   o

                            500,503             -   o   o   o   o   o

                            600,603             -   o   o   o   o   o

   Route                       R          adr   c   c   c   c   c   c

   Server                      r                -   o   o   o   o   o

   Subject                     R                -   -   -   o   -   -

   Supported                   R                -   o   o   m*  o   o

   Supported                  2xx               -   o   o   m*  m*  o

   Timestamp                                    o   o   o   o   o   o

   To                        c(1)          r    m   m   m   m   m   m

   Unsupported                420               -   m   -   m   m   m

   User-Agent                                   o   o   o   o   o   o

   Via                         R          amr   m   m   m   m   m   m

   Via                        rc          dr    m   m   m   m   m   m

   Warning                     r                -   o   o   o   o   o

   WWW-Authenticate           401         ar    -   m   -   m   m   m

   WWW-Authenticate           407         ar    -   o   -   o   o   o



   Table 3: Summary of header fields, P--Z; (1): copied with possible

   addition of tag



      Accept: application/sdp;level=1, application/x-private, text/html



20.2 Accept-Encoding



   The Accept-Encoding header field is similar to Accept, but restricts

   the content-codings [H3.5] that are acceptable in the response.  See

   [H14.3].  The semantics in SIP are identical to those defined in

   [H14.3].



   An empty Accept-Encoding header field is permissible.  It is

   equivalent to Accept-Encoding: identity, that is, only the identity

   encoding, meaning no encoding, is permissible.



   If no Accept-Encoding header field is present, the server SHOULD

   assume a default value of identity.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   This differs slightly from the HTTP definition, which indicates that

   when not present, any encoding can be used, but the identity encoding

   is preferred.



   Example:



      Accept-Encoding: gzip



20.3 Accept-Language



   The Accept-Language header field is used in requests to indicate the

   preferred languages for reason phrases, session descriptions, or

   status responses carried as message bodies in the response.  If no

   Accept-Language header field is present, the server SHOULD assume all

   languages are acceptable to the client.



   The Accept-Language header field follows the syntax defined in

   [H14.4].  The rules for ordering the languages based on the "q"

   parameter apply to SIP as well.



   Example:



      Accept-Language: da, en-gb;q=0.8, en;q=0.7



20.4 Alert-Info



   When present in an INVITE request, the Alert-Info header field

   specifies an alternative ring tone to the UAS.  When present in a 180

   (Ringing) response, the Alert-Info header field specifies an

   alternative ringback tone to the UAC.  A typical usage is for a proxy

   to insert this header field to provide a distinctive ring feature.



   The Alert-Info header field can introduce security risks.  These

   risks and the ways to handle them are discussed in Section 20.9,

   which discusses the Call-Info header field since the risks are

   identical.



   In addition, a user SHOULD be able to disable this feature

   selectively.



      This helps prevent disruptions that could result from the use of

      this header field by untrusted elements.



   Example:



      Alert-Info: <http://www.example.com/sounds/moo.wav>











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





20.5 Allow



   The Allow header field lists the set of methods supported by the UA

   generating the message.



   All methods, including ACK and CANCEL, understood by the UA MUST be

   included in the list of methods in the Allow header field, when

   present.  The absence of an Allow header field MUST NOT be

   interpreted to mean that the UA sending the message supports no

   methods.   Rather, it implies that the UA is not providing any

   information on what methods it supports.



   Supplying an Allow header field in responses to methods other than

   OPTIONS reduces the number of messages needed.



   Example:



      Allow: INVITE, ACK, OPTIONS, CANCEL, BYE



20.6 Authentication-Info



   The Authentication-Info header field provides for mutual

   authentication with HTTP Digest.  A UAS MAY include this header field

   in a 2xx response to a request that was successfully authenticated

   using digest based on the Authorization header field.



   Syntax and semantics follow those specified in RFC 2617 [17].



   Example:



      Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"



20.7 Authorization



   The Authorization header field contains authentication credentials of

   a UA.  Section 22.2 overviews the use of the Authorization header

   field, and Section 22.4 describes the syntax and semantics when used

   with HTTP authentication.



   This header field, along with Proxy-Authorization, breaks the general

   rules about multiple header field values.  Although not a comma-

   separated list, this header field name may be present multiple times,

   and MUST NOT be combined into a single header line using the usual

   rules described in Section 7.3.















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   In the example below, there are no quotes around the Digest

   parameter:



      Authorization: Digest username="Alice", realm="atlanta.com",

       nonce="84a4cc6f3082121f32b42a2187831a9e",

       response="7587245234b3434cc3412213e5f113a5432"



20.8 Call-ID



   The Call-ID header field uniquely identifies a particular invitation

   or all registrations of a particular client.  A single multimedia

   conference can give rise to several calls with different Call-IDs,

   for example, if a user invites a single individual several times to

   the same (long-running) conference.  Call-IDs are case-sensitive and

   are simply compared byte-by-byte.



   The compact form of the Call-ID header field is i.



   Examples:



      Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com

      i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4



20.9 Call-Info



   The Call-Info header field provides additional information about the

   caller or callee, depending on whether it is found in a request or

   response.  The purpose of the URI is described by the "purpose"

   parameter.  The "icon" parameter designates an image suitable as an

   iconic representation of the caller or callee.  The "info" parameter

   describes the caller or callee in general, for example, through a web

   page.  The "card" parameter provides a business card, for example, in

   vCard [36] or LDIF [37] formats.  Additional tokens can be registered

   using IANA and the procedures in Section 27.



   Use of the Call-Info header field can pose a security risk.  If a

   callee fetches the URIs provided by a malicious caller, the callee

   may be at risk for displaying inappropriate or offensive content,

   dangerous or illegal content, and so on.  Therefore, it is

   RECOMMENDED that a UA only render the information in the Call-Info

   header field if it can verify the authenticity of the element that

   originated the header field and trusts that element.  This need not

   be the peer UA; a proxy can insert this header field into requests.



   Example:



   Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,

     <http://www.example.com/alice/> ;purpose=info







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





20.10 Contact



   A Contact header field value provides a URI whose meaning depends on

   the type of request or response it is in.



   A Contact header field value can contain a display name, a URI with

   URI parameters, and header parameters.



   This document defines the Contact parameters "q" and "expires".

   These parameters are only used when the Contact is present in a

   REGISTER request or response, or in a 3xx response.  Additional

   parameters may be defined in other specifications.



   When the header field value contains a display name, the URI

   including all URI parameters is enclosed in "<" and ">".  If no "<"

   and ">" are present, all parameters after the URI are header

   parameters, not URI parameters.  The display name can be tokens, or a

   quoted string, if a larger character set is desired.



   Even if the "display-name" is empty, the "name-addr" form MUST be

   used if the "addr-spec" contains a comma, semicolon, or question

   mark.  There may or may not be LWS between the display-name and the

   "<".



   These rules for parsing a display name, URI and URI parameters, and

   header parameters also apply for the header fields To and From.



      The Contact header field has a role similar to the Location header

      field in HTTP.  However, the HTTP header field only allows one

      address, unquoted.  Since URIs can contain commas and semicolons

      as reserved characters, they can be mistaken for header or

      parameter delimiters, respectively.



   The compact form of the Contact header field is m (for "moved").



   Examples:



      Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>

         ;q=0.7; expires=3600,

         "Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1

      m: <sips:bob@192.0.2.4>;expires=60





















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





20.11 Content-Disposition



   The Content-Disposition header field describes how the message body

   or, for multipart messages, a message body part is to be interpreted

   by the UAC or UAS.  This SIP header field extends the MIME Content-

   Type (RFC 2183 [18]).



   Several new "disposition-types" of the Content-Disposition header are

   defined by SIP.  The value "session" indicates that the body part

   describes a session, for either calls or early (pre-call) media.  The

   value "render" indicates that the body part should be displayed or

   otherwise rendered to the user.  Note that the value "render" is used

   rather than "inline" to avoid the connotation that the MIME body is

   displayed as a part of the rendering of the entire message (since the

   MIME bodies of SIP messages oftentimes are not displayed to users).

   For backward-compatibility, if the Content-Disposition header field

   is missing, the server SHOULD assume bodies of Content-Type

   application/sdp are the disposition "session", while other content

   types are "render".



   The disposition type "icon" indicates that the body part contains an

   image suitable as an iconic representation of the caller or callee

   that could be rendered informationally by a user agent when a message

   has been received, or persistently while a dialog takes place.  The

   value "alert" indicates that the body part contains information, such

   as an audio clip, that should be rendered by the user agent in an

   attempt to alert the user to the receipt of a request, generally a

   request that initiates a dialog; this alerting body could for example

   be rendered as a ring tone for a phone call after a 180 Ringing

   provisional response has been sent.



   Any MIME body with a "disposition-type" that renders content to the

   user should only be processed when a message has been properly

   authenticated.



   The handling parameter, handling-param, describes how the UAS should

   react if it receives a message body whose content type or disposition

   type it does not understand.  The parameter has defined values of

   "optional" and "required".  If the handling parameter is missing, the

   value "required" SHOULD be assumed.  The handling parameter is

   described in RFC 3204 [19].



   If this header field is missing, the MIME type determines the default

   content disposition.  If there is none, "render" is assumed.



   Example:



      Content-Disposition: session







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





20.12 Content-Encoding



   The Content-Encoding header field is used as a modifier to the

   "media-type".  When present, its value indicates what additional

   content codings have been applied to the entity-body, and thus what

   decoding mechanisms MUST be applied in order to obtain the media-type

   referenced by the Content-Type header field.  Content-Encoding is

   primarily used to allow a body to be compressed without losing the

   identity of its underlying media type.



   If multiple encodings have been applied to an entity-body, the

   content codings MUST be listed in the order in which they were

   applied.



   All content-coding values are case-insensitive.  IANA acts as a

   registry for content-coding value tokens.  See [H3.5] for a

   definition of the syntax for content-coding.



   Clients MAY apply content encodings to the body in requests.  A

   server MAY apply content encodings to the bodies in responses.  The

   server MUST only use encodings listed in the Accept-Encoding header

   field in the request.



   The compact form of the Content-Encoding header field is e.

   Examples:



      Content-Encoding: gzip

      e: tar



20.13 Content-Language



   See [H14.12]. Example:



      Content-Language: fr



20.14 Content-Length



   The Content-Length header field indicates the size of the message-

   body, in decimal number of octets, sent to the recipient.

   Applications SHOULD use this field to indicate the size of the

   message-body to be transferred, regardless of the media type of the

   entity.  If a stream-based protocol (such as TCP) is used as

   transport, the header field MUST be used.



   The size of the message-body does not include the CRLF separating

   header fields and body.  Any Content-Length greater than or equal to

   zero is a valid value.  If no body is present in a message, then the

   Content-Length header field value MUST be set to zero.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      The ability to omit Content-Length simplifies the creation of

      cgi-like scripts that dynamically generate responses.



   The compact form of the header field is l.



   Examples:



      Content-Length: 349

      l: 173



20.15 Content-Type



   The Content-Type header field indicates the media type of the

   message-body sent to the recipient.  The "media-type" element is

   defined in [H3.7].  The Content-Type header field MUST be present if

   the body is not empty.  If the body is empty, and a Content-Type

   header field is present, it indicates that the body of the specific

   type has zero length (for example, an empty audio file).



   The compact form of the header field is c.



   Examples:



      Content-Type: application/sdp

      c: text/html; charset=ISO-8859-4



20.16 CSeq



   A CSeq header field in a request contains a single decimal sequence

   number and the request method.  The sequence number MUST be

   expressible as a 32-bit unsigned integer.  The method part of CSeq is

   case-sensitive.  The CSeq header field serves to order transactions

   within a dialog, to provide a means to uniquely identify

   transactions, and to differentiate between new requests and request

   retransmissions.  Two CSeq header fields are considered equal if the

   sequence number and the request method are identical.  Example:



      CSeq: 4711 INVITE



20.17 Date



   The Date header field contains the date and time.  Unlike HTTP/1.1,

   SIP only supports the most recent RFC 1123 [20] format for dates.  As

   in [H3.3], SIP restricts the time zone in SIP-date to "GMT", while

   RFC 1123 allows any time zone.  An RFC 1123 date is case-sensitive.



   The Date header field reflects the time when the request or response

   is first sent.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      The Date header field can be used by simple end systems without a

      battery-backed clock to acquire a notion of current time.

      However, in its GMT form, it requires clients to know their offset

      from GMT.



   Example:



      Date: Sat, 13 Nov 2010 23:29:00 GMT



20.18 Error-Info



   The Error-Info header field provides a pointer to additional

   information about the error status response.



      SIP UACs have user interface capabilities ranging from pop-up

      windows and audio on PC softclients to audio-only on "black"

      phones or endpoints connected via gateways.  Rather than forcing a

      server generating an error to choose between sending an error

      status code with a detailed reason phrase and playing an audio

      recording, the Error-Info header field allows both to be sent.

      The UAC then has the choice of which error indicator to render to

      the caller.



   A UAC MAY treat a SIP or SIPS URI in an Error-Info header field as if

   it were a Contact in a redirect and generate a new INVITE, resulting

   in a recorded announcement session being established.  A non-SIP URI

   MAY be rendered to the user.



   Examples:



      SIP/2.0 404 The number you have dialed is not in service

      Error-Info: <sip:not-in-service-recording@atlanta.com>



20.19 Expires



   The Expires header field gives the relative time after which the

   message (or content) expires.



   The precise meaning of this is method dependent.



   The expiration time in an INVITE does not affect the duration of the

   actual session that may result from the invitation.  Session

   description protocols may offer the ability to express time limits on

   the session duration, however.



   The value of this field is an integral number of seconds (in decimal)

   between 0 and (2**32)-1, measured from the receipt of the request.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Example:



      Expires: 5



20.20 From



   The From header field indicates the initiator of the request.  This

   may be different from the initiator of the dialog.  Requests sent by

   the callee to the caller use the callee's address in the From header

   field.



   The optional "display-name" is meant to be rendered by a human user

   interface.  A system SHOULD use the display name "Anonymous" if the

   identity of the client is to remain hidden.  Even if the "display-

   name" is empty, the "name-addr" form MUST be used if the "addr-spec"

   contains a comma, question mark, or semicolon.  Syntax issues are

   discussed in Section 7.3.1.



   Two From header fields are equivalent if their URIs match, and their

   parameters match. Extension parameters in one header field, not

   present in the other are ignored for the purposes of comparison. This

   means that the display name and presence or absence of angle brackets

   do not affect matching.



   See Section 20.10 for the rules for parsing a display name, URI and

   URI parameters, and header field parameters.



   The compact form of the From header field is f.



   Examples:



      From: "A. G. Bell" <sip:agb@bell-telephone.com> ;tag=a48s

      From: sip:+12125551212@server.phone2net.com;tag=887s

      f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8



20.21 In-Reply-To



   The In-Reply-To header field enumerates the Call-IDs that this call

   references or returns.  These Call-IDs may have been cached by the

   client then included in this header field in a return call.



      This allows automatic call distribution systems to route return

      calls to the originator of the first call.  This also allows

      callees to filter calls, so that only return calls for calls they

      originated will be accepted.  This field is not a substitute for

      request authentication.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Example:



      In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com



20.22 Max-Forwards



   The Max-Forwards header field must be used with any SIP method to

   limit the number of proxies or gateways that can forward the request

   to the next downstream server.  This can also be useful when the

   client is attempting to trace a request chain that appears to be

   failing or looping in mid-chain.



   The Max-Forwards value is an integer in the range 0-255 indicating

   the remaining number of times this request message is allowed to be

   forwarded.  This count is decremented by each server that forwards

   the request.  The recommended initial value is 70.



   This header field should be inserted by elements that can not

   otherwise guarantee loop detection.  For example, a B2BUA should

   insert a Max-Forwards header field.



   Example:



      Max-Forwards: 6



20.23 Min-Expires



   The Min-Expires header field conveys the minimum refresh interval

   supported for soft-state elements managed by that server.  This

   includes Contact header fields that are stored by a registrar.  The

   header field contains a decimal integer number of seconds from 0 to

   (2**32)-1.  The use of the header field in a 423 (Interval Too Brief)

   response is described in Sections 10.2.8, 10.3, and 21.4.17.



   Example:



      Min-Expires: 60



20.24 MIME-Version



   See [H19.4.1].



   Example:



      MIME-Version: 1.0













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





20.25 Organization



   The Organization header field conveys the name of the organization to

   which the SIP element issuing the request or response belongs.



      The field MAY be used by client software to filter calls.



   Example:



      Organization: Boxes by Bob



20.26 Priority



   The Priority header field indicates the urgency of the request as

   perceived by the client.  The Priority header field describes the

   priority that the SIP request should have to the receiving human or

   its agent.  For example, it may be factored into decisions about call

   routing and acceptance.  For these decisions, a message containing no

   Priority header field SHOULD be treated as if it specified a Priority

   of "normal".  The Priority header field does not influence the use of

   communications resources such as packet forwarding priority in

   routers or access to circuits in PSTN gateways.  The header field can

   have the values "non-urgent", "normal", "urgent", and "emergency",

   but additional values can be defined elsewhere.  It is RECOMMENDED

   that the value of "emergency" only be used when life, limb, or

   property are in imminent danger.  Otherwise, there are no semantics

   defined for this header field.



      These are the values of RFC 2076 [38], with the addition of

      "emergency".



   Examples:



      Subject: A tornado is heading our way!

      Priority: emergency



   or



      Subject: Weekend plans

      Priority: non-urgent



20.27 Proxy-Authenticate



   A Proxy-Authenticate header field value contains an authentication

   challenge.



   The use of this header field is defined in [H14.33].  See Section

   22.3 for further details on its usage.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Example:



      Proxy-Authenticate: Digest realm="atlanta.com",

       domain="sip:ss1.carrier.com", qop="auth",

       nonce="f84f1cec41e6cbe5aea9c8e88d359",

       opaque="", stale=FALSE, algorithm=MD5



20.28 Proxy-Authorization



   The Proxy-Authorization header field allows the client to identify

   itself (or its user) to a proxy that requires authentication.  A

   Proxy-Authorization field value consists of credentials containing

   the authentication information of the user agent for the proxy and/or

   realm of the resource being requested.



   See Section 22.3 for a definition of the usage of this header field.



   This header field, along with Authorization, breaks the general rules

   about multiple header field names.  Although not a comma-separated

   list, this header field name may be present multiple times, and MUST

   NOT be combined into a single header line using the usual rules

   described in Section 7.3.1.



   Example:



   Proxy-Authorization: Digest username="Alice", realm="atlanta.com",

      nonce="c60f3082ee1212b402a21831ae",

      response="245f23415f11432b3434341c022"



20.29 Proxy-Require



   The Proxy-Require header field is used to indicate proxy-sensitive

   features that must be supported by the proxy.  See Section 20.32 for

   more details on the mechanics of this message and a usage example.



   Example:



      Proxy-Require: foo



20.30 Record-Route



   The Record-Route header field is inserted by proxies in a request to

   force future requests in the dialog to be routed through the proxy.



   Examples of its use with the Route header field are described in

   Sections 16.12.1.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Example:



      Record-Route: <sip:server10.biloxi.com;lr>,

                    <sip:bigbox3.site3.atlanta.com;lr>



20.31 Reply-To



   The Reply-To header field contains a logical return URI that may be

   different from the From header field.  For example, the URI MAY be

   used to return missed calls or unestablished sessions.  If the user

   wished to remain anonymous, the header field SHOULD either be omitted

   from the request or populated in such a way that does not reveal any

   private information.



   Even if the "display-name" is empty, the "name-addr" form MUST be

   used if the "addr-spec" contains a comma, question mark, or

   semicolon.  Syntax issues are discussed in Section 7.3.1.



   Example:



      Reply-To: Bob <sip:bob@biloxi.com>



20.32 Require



   The Require header field is used by UACs to tell UASs about options

   that the UAC expects the UAS to support in order to process the

   request.  Although an optional header field, the Require MUST NOT be

   ignored if it is present.



   The Require header field contains a list of option tags, described in

   Section 19.2.  Each option tag defines a SIP extension that MUST be

   understood to process the request.  Frequently, this is used to

   indicate that a specific set of extension header fields need to be

   understood.  A UAC compliant to this specification MUST only include

   option tags corresponding to standards-track RFCs.



   Example:



      Require: 100rel



20.33 Retry-After



   The Retry-After header field can be used with a 500 (Server Internal

   Error) or 503 (Service Unavailable) response to indicate how long the

   service is expected to be unavailable to the requesting client and

   with a 404 (Not Found), 413 (Request Entity Too Large), 480

   (Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   (Decline) response to indicate when the called party anticipates

   being available again.  The value of this field is a positive integer

   number of seconds (in decimal) after the time of the response.



   An optional comment can be used to indicate additional information

   about the time of callback.  An optional "duration" parameter

   indicates how long the called party will be reachable starting at the

   initial time of availability.  If no duration parameter is given, the

   service is assumed to be available indefinitely.



   Examples:



      Retry-After: 18000;duration=3600

      Retry-After: 120 (I'm in a meeting)



20.34 Route



   The Route header field is used to force routing for a request through

   the listed set of proxies.  Examples of the use of the Route header

   field are in Section 16.12.1.



   Example:



      Route: <sip:bigbox3.site3.atlanta.com;lr>,

             <sip:server10.biloxi.com;lr>



20.35 Server



   The Server header field contains information about the software used

   by the UAS to handle the request.



   Revealing the specific software version of the server might allow the

   server to become more vulnerable to attacks against software that is

   known to contain security holes.  Implementers SHOULD make the Server

   header field a configurable option.



   Example:



      Server: HomeServer v2



20.36 Subject



   The Subject header field provides a summary or indicates the nature

   of the call, allowing call filtering without having to parse the

   session description.  The session description does not have to use

   the same subject indication as the invitation.



   The compact form of the Subject header field is s.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Example:



      Subject: Need more boxes

      s: Tech Support



20.37 Supported



   The Supported header field enumerates all the extensions supported by

   the UAC or UAS.



   The Supported header field contains a list of option tags, described

   in Section 19.2, that are understood by the UAC or UAS.  A UA

   compliant to this specification MUST only include option tags

   corresponding to standards-track RFCs.  If empty, it means that no

   extensions are supported.



   The compact form of the Supported header field is k.



   Example:



      Supported: 100rel



20.38 Timestamp



   The Timestamp header field describes when the UAC sent the request to

   the UAS.



   See Section 8.2.6 for details on how to generate a response to a

   request that contains the header field.  Although there is no

   normative behavior defined here that makes use of the header, it

   allows for extensions or SIP applications to obtain RTT estimates.



   Example:



      Timestamp: 54



20.39 To



   The To header field specifies the logical recipient of the request.



   The optional "display-name" is meant to be rendered by a human-user

   interface.  The "tag" parameter serves as a general mechanism for

   dialog identification.



   See Section 19.3 for details of the "tag" parameter.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Comparison of To header fields for equality is identical to

   comparison of From header fields.  See Section 20.10 for the rules

   for parsing a display name, URI and URI parameters, and header field

   parameters.



   The compact form of the To header field is t.



   The following are examples of valid To header fields:



      To: The Operator <sip:operator@cs.columbia.edu>;tag=287447

      t: sip:+12125551212@server.phone2net.com



20.40 Unsupported



   The Unsupported header field lists the features not supported by the

   UAS.  See Section 20.32 for motivation.



   Example:



      Unsupported: foo



20.41 User-Agent



   The User-Agent header field contains information about the UAC

   originating the request.  The semantics of this header field are

   defined in [H14.43].



   Revealing the specific software version of the user agent might allow

   the user agent to become more vulnerable to attacks against software

   that is known to contain security holes.  Implementers SHOULD make

   the User-Agent header field a configurable option.



   Example:



      User-Agent: Softphone Beta1.5



20.42 Via



   The Via header field indicates the path taken by the request so far

   and indicates the path that should be followed in routing responses.

   The branch ID parameter in the Via header field values serves as a

   transaction identifier, and is used by proxies to detect loops.



   A Via header field value contains the transport protocol used to send

   the message, the client's host name or network address, and possibly

   the port number at which it wishes to receive responses.  A Via

   header field value can also contain parameters such as "maddr",

   "ttl", "received", and "branch", whose meaning and use are described







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   in other sections.  For implementations compliant to this

   specification, the value of the branch parameter MUST start with the

   magic cookie "z9hG4bK", as discussed in Section 8.1.1.7.



   Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP".

   "TLS" means TLS over TCP.  When a request is sent to a SIPS URI, the

   protocol still indicates "SIP", and the transport protocol is TLS.



Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7

Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207

     ;branch=z9hG4bK77asjd



   The compact form of the Via header field is v.



   In this example, the message originated from a multi-homed host with

   two addresses, 192.0.2.1 and 192.0.2.207.  The sender guessed wrong

   as to which network interface would be used.  Erlang.bell-

   telephone.com noticed the mismatch and added a parameter to the

   previous hop's Via header field value, containing the address that

   the packet actually came from.



   The host or network address and port number are not required to

   follow the SIP URI syntax.  Specifically, LWS on either side of the

   ":" or "/" is allowed, as shown here:



      Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16

        ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1



   Even though this specification mandates that the branch parameter be

   present in all requests, the BNF for the header field indicates that

   it is optional.  This allows interoperation with RFC 2543 elements,

   which did not have to insert the branch parameter.



   Two Via header fields are equal if their sent-protocol and sent-by

   fields are equal, both have the same set of parameters, and the

   values of all parameters are equal.



20.43 Warning



   The Warning header field is used to carry additional information

   about the status of a response.  Warning header field values are sent

   with responses and contain a three-digit warning code, host name, and

   warning text.



   The "warn-text" should be in a natural language that is most likely

   to be intelligible to the human user receiving the response.  This

   decision can be based on any available knowledge, such as the

   location of the user, the Accept-Language field in a request, or the







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Content-Language field in a response.  The default language is i-

   default [21].



   The currently-defined "warn-code"s are listed below, with a

   recommended warn-text in English and a description of their meaning.

   These warnings describe failures induced by the session description.

   The first digit of warning codes beginning with "3" indicates

   warnings specific to SIP.  Warnings 300 through 329 are reserved for

   indicating problems with keywords in the session description, 330

   through 339 are warnings related to basic network services requested

   in the session description, 370 through 379 are warnings related to

   quantitative QoS parameters requested in the session description, and

   390 through 399 are miscellaneous warnings that do not fall into one

   of the above categories.



      300 Incompatible network protocol: One or more network protocols

          contained in the session description are not available.



      301 Incompatible network address formats: One or more network

          address formats contained in the session description are not

          available.



      302 Incompatible transport protocol: One or more transport

          protocols described in the session description are not

          available.



      303 Incompatible bandwidth units: One or more bandwidth

          measurement units contained in the session description were

          not understood.



      304 Media type not available: One or more media types contained in

          the session description are not available.



      305 Incompatible media format: One or more media formats contained

          in the session description are not available.



      306 Attribute not understood: One or more of the media attributes

          in the session description are not supported.



      307 Session description parameter not understood: A parameter

          other than those listed above was not understood.



      330 Multicast not available: The site where the user is located

          does not support multicast.



      331 Unicast not available: The site where the user is located does

          not support unicast communication (usually due to the presence

          of a firewall).







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      370 Insufficient bandwidth: The bandwidth specified in the session

          description or defined by the media exceeds that known to be

          available.



      399 Miscellaneous warning: The warning text can include arbitrary

          information to be presented to a human user or logged.  A

          system receiving this warning MUST NOT take any automated

          action.



             1xx and 2xx have been taken by HTTP/1.1.



   Additional "warn-code"s can be defined through IANA, as defined in

   Section 27.2.



   Examples:



      Warning: 307 isi.edu "Session parameter 'foo' not understood"

      Warning: 301 isi.edu "Incompatible network address type 'E.164'"



20.44 WWW-Authenticate



   A WWW-Authenticate header field value contains an authentication

   challenge.  See Section 22.2 for further details on its usage.



   Example:



      WWW-Authenticate: Digest realm="atlanta.com",

        domain="sip:boxesbybob.com", qop="auth",

        nonce="f84f1cec41e6cbe5aea9c8e88d359",

        opaque="", stale=FALSE, algorithm=MD5



21 Response Codes



   The response codes are consistent with, and extend, HTTP/1.1 response

   codes.  Not all HTTP/1.1 response codes are appropriate, and only

   those that are appropriate are given here.  Other HTTP/1.1 response

   codes SHOULD NOT be used.  Also, SIP defines a new class, 6xx.



21.1 Provisional 1xx



   Provisional responses, also known as informational responses,

   indicate that the server contacted is performing some further action

   and does not yet have a definitive response.  A server sends a 1xx

   response if it expects to take more than 200 ms to obtain a final

   response.  Note that 1xx responses are not transmitted reliably.

   They never cause the client to send an ACK.  Provisional (1xx)

   responses MAY contain message bodies, including session descriptions.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





21.1.1 100 Trying



   This response indicates that the request has been received by the

   next-hop server and that some unspecified action is being taken on

   behalf of this call (for example, a database is being consulted).

   This response, like all other provisional responses, stops

   retransmissions of an INVITE by a UAC.  The 100 (Trying) response is

   different from other provisional responses, in that it is never

   forwarded upstream by a stateful proxy.



21.1.2 180 Ringing



   The UA receiving the INVITE is trying to alert the user.  This

   response MAY be used to initiate local ringback.



21.1.3 181 Call Is Being Forwarded



   A server MAY use this status code to indicate that the call is being

   forwarded to a different set of destinations.



21.1.4 182 Queued



   The called party is temporarily unavailable, but the server has

   decided to queue the call rather than reject it.  When the callee

   becomes available, it will return the appropriate final status

   response.  The reason phrase MAY give further details about the

   status of the call, for example, "5 calls queued; expected waiting

   time is 15 minutes".  The server MAY issue several 182 (Queued)

   responses to update the caller about the status of the queued call.



21.1.5 183 Session Progress



   The 183 (Session Progress) response is used to convey information

   about the progress of the call that is not otherwise classified.  The

   Reason-Phrase, header fields, or message body MAY be used to convey

   more details about the call progress.



21.2 Successful 2xx



   The request was successful.



21.2.1 200 OK



   The request has succeeded.  The information returned with the

   response depends on the method used in the request.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





21.3 Redirection 3xx



   3xx responses give information about the user's new location, or

   about alternative services that might be able to satisfy the call.



21.3.1 300 Multiple Choices



   The address in the request resolved to several choices, each with its

   own specific location, and the user (or UA) can select a preferred

   communication end point and redirect its request to that location.



   The response MAY include a message body containing a list of resource

   characteristics and location(s) from which the user or UA can choose

   the one most appropriate, if allowed by the Accept request header

   field.  However, no MIME types have been defined for this message

   body.



   The choices SHOULD also be listed as Contact fields (Section 20.10).

   Unlike HTTP, the SIP response MAY contain several Contact fields or a

   list of addresses in a Contact field.  UAs MAY use the Contact header

   field value for automatic redirection or MAY ask the user to confirm

   a choice.  However, this specification does not define any standard

   for such automatic selection.



      This status response is appropriate if the callee can be reached

      at several different locations and the server cannot or prefers

      not to proxy the request.



21.3.2 301 Moved Permanently



   The user can no longer be found at the address in the Request-URI,

   and the requesting client SHOULD retry at the new address given by

   the Contact header field (Section 20.10).  The requestor SHOULD

   update any local directories, address books, and user location caches

   with this new value and redirect future requests to the address(es)

   listed.



21.3.3 302 Moved Temporarily



   The requesting client SHOULD retry the request at the new address(es)

   given by the Contact header field (Section 20.10).  The Request-URI

   of the new request uses the value of the Contact header field in the

   response.

















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The duration of the validity of the Contact URI can be indicated

   through an Expires (Section 20.19) header field or an expires

   parameter in the Contact header field.  Both proxies and UAs MAY

   cache this URI for the duration of the expiration time.  If there is

   no explicit expiration time, the address is only valid once for

   recursing, and MUST NOT be cached for future transactions.



   If the URI cached from the Contact header field fails, the Request-

   URI from the redirected request MAY be tried again a single time.



      The temporary URI may have become out-of-date sooner than the

      expiration time, and a new temporary URI may be available.



21.3.4 305 Use Proxy



   The requested resource MUST be accessed through the proxy given by

   the Contact field.  The Contact field gives the URI of the proxy.

   The recipient is expected to repeat this single request via the

   proxy.  305 (Use Proxy) responses MUST only be generated by UASs.



21.3.5 380 Alternative Service



   The call was not successful, but alternative services are possible.



   The alternative services are described in the message body of the

   response.  Formats for such bodies are not defined here, and may be

   the subject of future standardization.



21.4 Request Failure 4xx



   4xx responses are definite failure responses from a particular

   server.  The client SHOULD NOT retry the same request without

   modification (for example, adding appropriate authorization).

   However, the same request to a different server might be successful.



21.4.1 400 Bad Request



   The request could not be understood due to malformed syntax.  The

   Reason-Phrase SHOULD identify the syntax problem in more detail, for

   example, "Missing Call-ID header field".



21.4.2 401 Unauthorized



   The request requires user authentication.  This response is issued by

   UASs and registrars, while 407 (Proxy Authentication Required) is

   used by proxy servers.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





21.4.3 402 Payment Required



   Reserved for future use.



21.4.4 403 Forbidden



   The server understood the request, but is refusing to fulfill it.

   Authorization will not help, and the request SHOULD NOT be repeated.



21.4.5 404 Not Found



   The server has definitive information that the user does not exist at

   the domain specified in the Request-URI.  This status is also

   returned if the domain in the Request-URI does not match any of the

   domains handled by the recipient of the request.



21.4.6 405 Method Not Allowed



   The method specified in the Request-Line is understood, but not

   allowed for the address identified by the Request-URI.



   The response MUST include an Allow header field containing a list of

   valid methods for the indicated address.



21.4.7 406 Not Acceptable



   The resource identified by the request is only capable of generating

   response entities that have content characteristics not acceptable

   according to the Accept header field sent in the request.



21.4.8 407 Proxy Authentication Required



   This code is similar to 401 (Unauthorized), but indicates that the

   client MUST first authenticate itself with the proxy.  SIP access

   authentication is explained in Sections 26 and 22.3.



   This status code can be used for applications where access to the

   communication channel (for example, a telephony gateway) rather than

   the callee requires authentication.



21.4.9 408 Request Timeout



   The server could not produce a response within a suitable amount of

   time, for example, if it could not determine the location of the user

   in time.  The client MAY repeat the request without modifications at

   any later time.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





21.4.10 410 Gone



   The requested resource is no longer available at the server and no

   forwarding address is known.  This condition is expected to be

   considered permanent.  If the server does not know, or has no

   facility to determine, whether or not the condition is permanent, the

   status code 404 (Not Found) SHOULD be used instead.



21.4.11 413 Request Entity Too Large



   The server is refusing to process a request because the request

   entity-body is larger than the server is willing or able to process.

   The server MAY close the connection to prevent the client from

   continuing the request.



   If the condition is temporary, the server SHOULD include a Retry-

   After header field to indicate that it is temporary and after what

   time the client MAY try again.



21.4.12 414 Request-URI Too Long



   The server is refusing to service the request because the Request-URI

   is longer than the server is willing to interpret.



21.4.13 415 Unsupported Media Type



   The server is refusing to service the request because the message

   body of the request is in a format not supported by the server for

   the requested method.  The server MUST return a list of acceptable

   formats using the Accept, Accept-Encoding, or Accept-Language header

   field, depending on the specific problem with the content.  UAC

   processing of this response is described in Section 8.1.3.5.



21.4.14 416 Unsupported URI Scheme



   The server cannot process the request because the scheme of the URI

   in the Request-URI is unknown to the server.  Client processing of

   this response is described in Section 8.1.3.5.



21.4.15 420 Bad Extension



   The server did not understand the protocol extension specified in a

   Proxy-Require (Section 20.29) or Require (Section 20.32) header

   field.  The server MUST include a list of the unsupported extensions

   in an Unsupported header field in the response.  UAC processing of

   this response is described in Section 8.1.3.5.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





21.4.16 421 Extension Required



   The UAS needs a particular extension to process the request, but this

   extension is not listed in a Supported header field in the request.

   Responses with this status code MUST contain a Require header field

   listing the required extensions.



   A UAS SHOULD NOT use this response unless it truly cannot provide any

   useful service to the client.  Instead, if a desirable extension is

   not listed in the Supported header field, servers SHOULD process the

   request using baseline SIP capabilities and any extensions supported

   by the client.



21.4.17 423 Interval Too Brief



   The server is rejecting the request because the expiration time of

   the resource refreshed by the request is too short.  This response

   can be used by a registrar to reject a registration whose Contact

   header field expiration time was too small.  The use of this response

   and the related Min-Expires header field are described in Sections

   10.2.8, 10.3, and 20.23.



21.4.18 480 Temporarily Unavailable



   The callee's end system was contacted successfully but the callee is

   currently unavailable (for example, is not logged in, logged in but

   in a state that precludes communication with the callee, or has

   activated the "do not disturb" feature).  The response MAY indicate a

   better time to call in the Retry-After header field.  The user could

   also be available elsewhere (unbeknownst to this server).  The reason

   phrase SHOULD indicate a more precise cause as to why the callee is

   unavailable.  This value SHOULD be settable by the UA.  Status 486

   (Busy Here) MAY be used to more precisely indicate a particular

   reason for the call failure.



   This status is also returned by a redirect or proxy server that

   recognizes the user identified by the Request-URI, but does not

   currently have a valid forwarding location for that user.



21.4.19 481 Call/Transaction Does Not Exist



   This status indicates that the UAS received a request that does not

   match any existing dialog or transaction.



21.4.20 482 Loop Detected



   The server has detected a loop (Section 16.3 Item 4).









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





21.4.21 483 Too Many Hops



   The server received a request that contains a Max-Forwards (Section

   20.22) header field with the value zero.



21.4.22 484 Address Incomplete



   The server received a request with a Request-URI that was incomplete.

   Additional information SHOULD be provided in the reason phrase.



      This status code allows overlapped dialing.  With overlapped

      dialing, the client does not know the length of the dialing

      string.  It sends strings of increasing lengths, prompting the

      user for more input, until it no longer receives a 484 (Address

      Incomplete) status response.



21.4.23 485 Ambiguous



   The Request-URI was ambiguous.  The response MAY contain a listing of

   possible unambiguous addresses in Contact header fields.  Revealing

   alternatives can infringe on privacy of the user or the organization.

   It MUST be possible to configure a server to respond with status 404

   (Not Found) or to suppress the listing of possible choices for

   ambiguous Request-URIs.



   Example response to a request with the Request-URI

   sip:lee@example.com:



      SIP/2.0 485 Ambiguous

      Contact: Carol Lee <sip:carol.lee@example.com>

      Contact: Ping Lee <sip:p.lee@example.com>

      Contact: Lee M. Foote <sips:lee.foote@example.com>



      Some email and voice mail systems provide this functionality.  A

      status code separate from 3xx is used since the semantics are

      different: for 300, it is assumed that the same person or service

      will be reached by the choices provided.  While an automated

      choice or sequential search makes sense for a 3xx response, user

      intervention is required for a 485 (Ambiguous) response.



21.4.24 486 Busy Here



   The callee's end system was contacted successfully, but the callee is

   currently not willing or able to take additional calls at this end

   system.  The response MAY indicate a better time to call in the

   Retry-After header field.  The user could also be available











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   elsewhere, such as through a voice mail service.  Status 600 (Busy

   Everywhere) SHOULD be used if the client knows that no other end

   system will be able to accept this call.



21.4.25 487 Request Terminated



   The request was terminated by a BYE or CANCEL request.  This response

   is never returned for a CANCEL request itself.



21.4.26 488 Not Acceptable Here



   The response has the same meaning as 606 (Not Acceptable), but only

   applies to the specific resource addressed by the Request-URI and the

   request may succeed elsewhere.



   A message body containing a description of media capabilities MAY be

   present in the response, which is formatted according to the Accept

   header field in the INVITE (or application/sdp if not present), the

   same as a message body in a 200 (OK) response to an OPTIONS request.



21.4.27 491 Request Pending



   The request was received by a UAS that had a pending request within

   the same dialog.  Section 14.2 describes how such "glare" situations

   are resolved.



21.4.28 493 Undecipherable



   The request was received by a UAS that contained an encrypted MIME

   body for which the recipient does not possess or will not provide an

   appropriate decryption key.  This response MAY have a single body

   containing an appropriate public key that should be used to encrypt

   MIME bodies sent to this UA.  Details of the usage of this response

   code can be found in Section 23.2.



21.5 Server Failure 5xx



   5xx responses are failure responses given when a server itself has

   erred.



21.5.1 500 Server Internal Error



   The server encountered an unexpected condition that prevented it from

   fulfilling the request.  The client MAY display the specific error

   condition and MAY retry the request after several seconds.



   If the condition is temporary, the server MAY indicate when the

   client may retry the request using the Retry-After header field.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





21.5.2 501 Not Implemented



   The server does not support the functionality required to fulfill the

   request.  This is the appropriate response when a UAS does not

   recognize the request method and is not capable of supporting it for

   any user.  (Proxies forward all requests regardless of method.)



   Note that a 405 (Method Not Allowed) is sent when the server

   recognizes the request method, but that method is not allowed or

   supported.



21.5.3 502 Bad Gateway



   The server, while acting as a gateway or proxy, received an invalid

   response from the downstream server it accessed in attempting to

   fulfill the request.



21.5.4 503 Service Unavailable



   The server is temporarily unable to process the request due to a

   temporary overloading or maintenance of the server.  The server MAY

   indicate when the client should retry the request in a Retry-After

   header field.  If no Retry-After is given, the client MUST act as if

   it had received a 500 (Server Internal Error) response.



   A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD

   attempt to forward the request to an alternate server.  It SHOULD NOT

   forward any other requests to that server for the duration specified

   in the Retry-After header field, if present.



   Servers MAY refuse the connection or drop the request instead of

   responding with 503 (Service Unavailable).



21.5.5 504 Server Time-out



   The server did not receive a timely response from an external server

   it accessed in attempting to process the request.  408 (Request

   Timeout) should be used instead if there was no response within the

   period specified in the Expires header field from the upstream

   server.



21.5.6 505 Version Not Supported



   The server does not support, or refuses to support, the SIP protocol

   version that was used in the request.  The server is indicating that

   it is unable or unwilling to complete the request using the same

   major version as the client, other than with this error message.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





21.5.7 513 Message Too Large



   The server was unable to process the request since the message length

   exceeded its capabilities.



21.6 Global Failures 6xx



   6xx responses indicate that a server has definitive information about

   a particular user, not just the particular instance indicated in the

   Request-URI.



21.6.1 600 Busy Everywhere



   The callee's end system was contacted successfully but the callee is

   busy and does not wish to take the call at this time.  The response

   MAY indicate a better time to call in the Retry-After header field.

   If the callee does not wish to reveal the reason for declining the

   call, the callee uses status code 603 (Decline) instead.  This status

   response is returned only if the client knows that no other end point

   (such as a voice mail system) will answer the request.  Otherwise,

   486 (Busy Here) should be returned.



21.6.2 603 Decline



   The callee's machine was successfully contacted but the user

   explicitly does not wish to or cannot participate.  The response MAY

   indicate a better time to call in the Retry-After header field.  This

   status response is returned only if the client knows that no other

   end point will answer the request.



21.6.3 604 Does Not Exist Anywhere



   The server has authoritative information that the user indicated in

   the Request-URI does not exist anywhere.



21.6.4 606 Not Acceptable



   The user's agent was contacted successfully but some aspects of the

   session description such as the requested media, bandwidth, or

   addressing style were not acceptable.



   A 606 (Not Acceptable) response means that the user wishes to

   communicate, but cannot adequately support the session described.

   The 606 (Not Acceptable) response MAY contain a list of reasons in a

   Warning header field describing why the session described cannot be

   supported.  Warning reason codes are listed in Section 20.43.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   A message body containing a description of media capabilities MAY be

   present in the response, which is formatted according to the Accept

   header field in the INVITE (or application/sdp if not present), the

   same as a message body in a 200 (OK) response to an OPTIONS request.



   It is hoped that negotiation will not frequently be needed, and when

   a new user is being invited to join an already existing conference,

   negotiation may not be possible.  It is up to the invitation

   initiator to decide whether or not to act on a 606 (Not Acceptable)

   response.



   This status response is returned only if the client knows that no

   other end point will answer the request.



22 Usage of HTTP Authentication



   SIP provides a stateless, challenge-based mechanism for

   authentication that is based on authentication in HTTP.  Any time

   that a proxy server or UA receives a request (with the exceptions

   given in Section 22.1), it MAY challenge the initiator of the request

   to provide assurance of its identity.  Once the originator has been

   identified, the recipient of the request SHOULD ascertain whether or

   not this user is authorized to make the request in question.  No

   authorization systems are recommended or discussed in this document.



   The "Digest" authentication mechanism described in this section

   provides message authentication and replay protection only, without

   message integrity or confidentiality.  Protective measures above and

   beyond those provided by Digest need to be taken to prevent active

   attackers from modifying SIP requests and responses.



   Note that due to its weak security, the usage of "Basic"

   authentication has been deprecated.  Servers MUST NOT accept

   credentials using the "Basic" authorization scheme, and servers also

   MUST NOT challenge with "Basic".  This is a change from RFC 2543.



22.1 Framework



   The framework for SIP authentication closely parallels that of HTTP

   (RFC 2617 [17]).  In particular, the BNF for auth-scheme, auth-param,

   challenge, realm, realm-value, and credentials is identical (although

   the usage of "Basic" as a scheme is not permitted).  In SIP, a UAS

   uses the 401 (Unauthorized) response to challenge the identity of a

   UAC.  Additionally, registrars and redirect servers MAY make use of

   401 (Unauthorized) responses for authentication, but proxies MUST

   NOT, and instead MAY use the 407 (Proxy Authentication Required)











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   response.  The requirements for inclusion of the Proxy-Authenticate,

   Proxy-Authorization, WWW-Authenticate, and Authorization in the

   various messages are identical to those described in RFC 2617 [17].



   Since SIP does not have the concept of a canonical root URL, the

   notion of protection spaces is interpreted differently in SIP.  The

   realm string alone defines the protection domain.  This is a change

   from RFC 2543, in which the Request-URI and the realm together

   defined the protection domain.



      This previous definition of protection domain caused some amount

      of confusion since the Request-URI sent by the UAC and the

      Request-URI received by the challenging server might be different,

      and indeed the final form of the Request-URI might not be known to

      the UAC.  Also, the previous definition depended on the presence

      of a SIP URI in the Request-URI and seemed to rule out alternative

      URI schemes (for example, the tel URL).



   Operators of user agents or proxy servers that will authenticate

   received requests MUST adhere to the following guidelines for

   creation of a realm string for their server:



      o  Realm strings MUST be globally unique.  It is RECOMMENDED that

         a realm string contain a hostname or domain name, following the

         recommendation in Section 3.2.1 of RFC 2617 [17].



      o  Realm strings SHOULD present a human-readable identifier that

         can be rendered to a user.



   For example:



      INVITE sip:bob@biloxi.com SIP/2.0

      Authorization: Digest realm="biloxi.com", <...>



   Generally, SIP authentication is meaningful for a specific realm, a

   protection domain.  Thus, for Digest authentication, each such

   protection domain has its own set of usernames and passwords.  If a

   server does not require authentication for a particular request, it

   MAY accept a default username, "anonymous", which has no password

   (password of "").  Similarly, UACs representing many users, such as

   PSTN gateways, MAY have their own device-specific username and

   password, rather than accounts for particular users, for their realm.



   While a server can legitimately challenge most SIP requests, there

   are two requests defined by this document that require special

   handling for authentication: ACK and CANCEL.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Under an authentication scheme that uses responses to carry values

   used to compute nonces (such as Digest), some problems come up for

   any requests that take no response, including ACK.  For this reason,

   any credentials in the INVITE that were accepted by a server MUST be

   accepted by that server for the ACK.  UACs creating an ACK message

   will duplicate all of the Authorization and Proxy-Authorization

   header field values that appeared in the INVITE to which the ACK

   corresponds.  Servers MUST NOT attempt to challenge an ACK.



   Although the CANCEL method does take a response (a 2xx), servers MUST

   NOT attempt to challenge CANCEL requests since these requests cannot

   be resubmitted.  Generally, a CANCEL request SHOULD be accepted by a

   server if it comes from the same hop that sent the request being

   canceled (provided that some sort of transport or network layer

   security association, as described in Section 26.2.1, is in place).



   When a UAC receives a challenge, it SHOULD render to the user the

   contents of the "realm" parameter in the challenge (which appears in

   either a WWW-Authenticate header field or Proxy-Authenticate header

   field) if the UAC device does not already know of a credential for

   the realm in question.  A service provider that pre-configures UAs

   with credentials for its realm should be aware that users will not

   have the opportunity to present their own credentials for this realm

   when challenged at a pre-configured device.



   Finally, note that even if a UAC can locate credentials that are

   associated with the proper realm, the potential exists that these

   credentials may no longer be valid or that the challenging server

   will not accept these credentials for whatever reason (especially

   when "anonymous" with no password is submitted).  In this instance a

   server may repeat its challenge, or it may respond with a 403

   Forbidden.  A UAC MUST NOT re-attempt requests with the credentials

   that have just been rejected (though the request may be retried if

   the nonce was stale).



22.2 User-to-User Authentication



   When a UAS receives a request from a UAC, the UAS MAY authenticate

   the originator before the request is processed.  If no credentials

   (in the Authorization header field) are provided in the request, the

   UAS can challenge the originator to provide credentials by rejecting

   the request with a 401 (Unauthorized) status code.



   The WWW-Authenticate response-header field MUST be included in 401

   (Unauthorized) response messages.  The field value consists of at

   least one challenge that indicates the authentication scheme(s) and

   parameters applicable to the realm.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   An example of the WWW-Authenticate header field in a 401 challenge

   is:



      WWW-Authenticate: Digest

              realm="biloxi.com",

              qop="auth,auth-int",

              nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

              opaque="5ccc069c403ebaf9f0171e9517f40e41"



   When the originating UAC receives the 401 (Unauthorized), it SHOULD,

   if it is able, re-originate the request with the proper credentials.

   The UAC may require input from the originating user before

   proceeding.  Once authentication credentials have been supplied

   (either directly by the user, or discovered in an internal keyring),

   UAs SHOULD cache the credentials for a given value of the To header

   field and "realm" and attempt to re-use these values on the next

   request for that destination.  UAs MAY cache credentials in any way

   they would like.



   If no credentials for a realm can be located, UACs MAY attempt to

   retry the request with a username of "anonymous" and no password (a

   password of "").



   Once credentials have been located, any UA that wishes to

   authenticate itself with a UAS or registrar -- usually, but not

   necessarily, after receiving a 401 (Unauthorized) response -- MAY do

   so by including an Authorization header field with the request.  The

   Authorization field value consists of credentials containing the

   authentication information of the UA for the realm of the resource

   being requested as well as parameters required in support of

   authentication and replay protection.



   An example of the Authorization header field is:



      Authorization: Digest username="bob",

              realm="biloxi.com",

              nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

              uri="sip:bob@biloxi.com",

              qop=auth,

              nc=00000001,

              cnonce="0a4f113b",

              response="6629fae49393a05397450978507c4ef1",

              opaque="5ccc069c403ebaf9f0171e9517f40e41"



   When a UAC resubmits a request with its credentials after receiving a

   401 (Unauthorized) or 407 (Proxy Authentication Required) response,

   it MUST increment the CSeq header field value as it would normally

   when sending an updated request.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





22.3 Proxy-to-User Authentication



   Similarly, when a UAC sends a request to a proxy server, the proxy

   server MAY authenticate the originator before the request is

   processed.  If no credentials (in the Proxy-Authorization header

   field) are provided in the request, the proxy can challenge the

   originator to provide credentials by rejecting the request with a 407

   (Proxy Authentication Required) status code.  The proxy MUST populate

   the 407 (Proxy Authentication Required) message with a Proxy-

   Authenticate header field value applicable to the proxy for the

   requested resource.



   The use of Proxy-Authenticate and Proxy-Authorization parallel that

   described in [17], with one difference.  Proxies MUST NOT add values

   to the Proxy-Authorization header field.  All 407 (Proxy

   Authentication Required) responses MUST be forwarded upstream toward

   the UAC following the procedures for any other response.  It is the

   UAC's responsibility to add the Proxy-Authorization header field

   value containing credentials for the realm of the proxy that has

   asked for authentication.



      If a proxy were to resubmit a request adding a Proxy-Authorization

      header field value, it would need to increment the CSeq in the new

      request.  However, this would cause the UAC that submitted the

      original request to discard a response from the UAS, as the CSeq

      value would be different.



   When the originating UAC receives the 407 (Proxy Authentication

   Required) it SHOULD, if it is able, re-originate the request with the

   proper credentials.  It should follow the same procedures for the

   display of the "realm" parameter that are given above for responding

   to 401.



   If no credentials for a realm can be located, UACs MAY attempt to

   retry the request with a username of "anonymous" and no password (a

   password of "").



   The UAC SHOULD also cache the credentials used in the re-originated

   request.



   The following rule is RECOMMENDED for proxy credential caching:



   If a UA receives a Proxy-Authenticate header field value in a 401/407

   response to a request with a particular Call-ID, it should

   incorporate credentials for that realm in all subsequent requests

   that contain the same Call-ID.  These credentials MUST NOT be cached

   across dialogs; however, if a UA is configured with the realm of its

   local outbound proxy, when one exists, then the UA MAY cache







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   credentials for that realm across dialogs.  Note that this does mean

   a future request in a dialog could contain credentials that are not

   needed by any proxy along the Route header path.



   Any UA that wishes to authenticate itself to a proxy server --

   usually, but not necessarily, after receiving a 407 (Proxy

   Authentication Required) response -- MAY do so by including a Proxy-

   Authorization header field value with the request.  The Proxy-

   Authorization request-header field allows the client to identify

   itself (or its user) to a proxy that requires authentication.  The

   Proxy-Authorization header field value consists of credentials

   containing the authentication information of the UA for the proxy

   and/or realm of the resource being requested.



   A Proxy-Authorization header field value applies only to the proxy

   whose realm is identified in the "realm" parameter (this proxy may

   previously have demanded authentication using the Proxy-Authenticate

   field).  When multiple proxies are used in a chain, a Proxy-

   Authorization header field value MUST NOT be consumed by any proxy

   whose realm does not match the "realm" parameter specified in that

   value.



   Note that if an authentication scheme that does not support realms is

   used in the Proxy-Authorization header field, a proxy server MUST

   attempt to parse all Proxy-Authorization header field values to

   determine whether one of them has what the proxy server considers to

   be valid credentials.  Because this is potentially very time-

   consuming in large networks, proxy servers SHOULD use an

   authentication scheme that supports realms in the Proxy-Authorization

   header field.



   If a request is forked (as described in Section 16.7), various proxy

   servers and/or UAs may wish to challenge the UAC.  In this case, the

   forking proxy server is responsible for aggregating these challenges

   into a single response.  Each WWW-Authenticate and Proxy-Authenticate

   value received in responses to the forked request MUST be placed into

   the single response that is sent by the forking proxy to the UA; the

   ordering of these header field values is not significant.



      When a proxy server issues a challenge in response to a request,

      it will not proxy the request until the UAC has retried the

      request with valid credentials.  A forking proxy may forward a

      request simultaneously to multiple proxy servers that require

      authentication, each of which in turn will not forward the request

      until the originating UAC has authenticated itself in their

      respective realm.  If the UAC does not provide credentials for











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      each challenge, the proxy servers that issued the challenges will

      not forward requests to the UA where the destination user might be

      located, and therefore, the virtues of forking are largely lost.



   When resubmitting its request in response to a 401 (Unauthorized) or

   407 (Proxy Authentication Required) that contains multiple

   challenges, a UAC MAY include an Authorization value for each WWW-

   Authenticate value and a Proxy-Authorization value for each Proxy-

   Authenticate value for which the UAC wishes to supply a credential.

   As noted above, multiple credentials in a request SHOULD be

   differentiated by the "realm" parameter.



   It is possible for multiple challenges associated with the same realm

   to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication

   Required).  This can occur, for example, when multiple proxies within

   the same administrative domain, which use a common realm, are reached

   by a forking request.  When it retries a request, a UAC MAY therefore

   supply multiple credentials in Authorization or Proxy-Authorization

   header fields with the same "realm" parameter value.  The same

   credentials SHOULD be used for the same realm.



22.4 The Digest Authentication Scheme



   This section describes the modifications and clarifications required

   to apply the HTTP Digest authentication scheme to SIP.  The SIP

   scheme usage is almost completely identical to that for HTTP [17].



   Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [39],

   SIP servers supporting RFC 2617 MUST ensure they are backwards

   compatible with RFC 2069.  Procedures for this backwards

   compatibility are specified in RFC 2617.  Note, however, that SIP

   servers MUST NOT accept or request Basic authentication.



   The rules for Digest authentication follow those defined in [17],

   with "HTTP/1.1" replaced by "SIP/2.0" in addition to the following

   differences:



      1.  The URI included in the challenge has the following BNF:



          URI  =  SIP-URI / SIPS-URI



      2.  The BNF in RFC 2617 has an error in that the 'uri' parameter

          of the Authorization header field for HTTP Digest

















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





          authentication is not enclosed in quotation marks.  (The

          example in Section 3.5 of RFC 2617 is correct.)  For SIP, the

          'uri' MUST be enclosed in quotation marks.



      3.  The BNF for digest-uri-value is:



          digest-uri-value  =  Request-URI ; as defined in Section 25



      4.  The example procedure for choosing a nonce based on Etag does

          not work for SIP.



      5.  The text in RFC 2617 [17] regarding cache operation does not

          apply to SIP.



      6.  RFC 2617 [17] requires that a server check that the URI in the

          request line and the URI included in the Authorization header

          field point to the same resource.  In a SIP context, these two

          URIs may refer to different users, due to forwarding at some

          proxy.  Therefore, in SIP, a server MAY check that the

          Request-URI in the Authorization header field value

          corresponds to a user for whom the server is willing to accept

          forwarded or direct requests, but it is not necessarily a

          failure if the two fields are not equivalent.



      7.  As a clarification to the calculation of the A2 value for

          message integrity assurance in the Digest authentication

          scheme, implementers should assume, when the entity-body is

          empty (that is, when SIP messages have no body) that the hash

          of the entity-body resolves to the MD5 hash of an empty

          string, or:



             H(entity-body) = MD5("") =

          "d41d8cd98f00b204e9800998ecf8427e"



      8.  RFC 2617 notes that a cnonce value MUST NOT be sent in an

          Authorization (and by extension Proxy-Authorization) header

          field if no qop directive has been sent.  Therefore, any

          algorithms that have a dependency on the cnonce (including

          "MD5-Sess") require that the qop directive be sent.  Use of

          the "qop" parameter is optional in RFC 2617 for the purposes

          of backwards compatibility with RFC 2069; since RFC 2543 was

          based on RFC 2069, the "qop" parameter must unfortunately

          remain optional for clients and servers to receive.  However,

          servers MUST always send a "qop" parameter in WWW-Authenticate

          and Proxy-Authenticate header field values.  If a client

          receives a "qop" parameter in a challenge header field, it

          MUST send the "qop" parameter in any resulting authorization

          header field.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   RFC 2543 did not allow usage of the Authentication-Info header field

   (it effectively used RFC 2069).  However, we now allow usage of this

   header field, since it provides integrity checks over the bodies and

   provides mutual authentication.  RFC 2617 [17] defines mechanisms for

   backwards compatibility using the qop attribute in the request.

   These mechanisms MUST be used by a server to determine if the client

   supports the new mechanisms in RFC 2617 that were not specified in

   RFC 2069.



23 S/MIME



   SIP messages carry MIME bodies and the MIME standard includes

   mechanisms for securing MIME contents to ensure both integrity and

   confidentiality (including the 'multipart/signed' and

   'application/pkcs7-mime' MIME types, see RFC 1847 [22], RFC 2630 [23]

   and RFC 2633 [24]).  Implementers should note, however, that there

   may be rare network intermediaries (not typical proxy servers) that

   rely on viewing or modifying the bodies of SIP messages (especially

   SDP), and that secure MIME may prevent these sorts of intermediaries

   from functioning.



      This applies particularly to certain types of firewalls.



      The PGP mechanism for encrypting the header fields and bodies of

      SIP messages described in RFC 2543 has been deprecated.



23.1 S/MIME Certificates



   The certificates that are used to identify an end-user for the

   purposes of S/MIME differ from those used by servers in one important

   respect - rather than asserting that the identity of the holder

   corresponds to a particular hostname, these certificates assert that

   the holder is identified by an end-user address.  This address is

   composed of the concatenation of the "userinfo" "@" and "domainname"

   portions of a SIP or SIPS URI (in other words, an email address of

   the form "bob@biloxi.com"), most commonly corresponding to a user's

   address-of-record.



   These certificates are also associated with keys that are used to

   sign or encrypt bodies of SIP messages.  Bodies are signed with the

   private key of the sender (who may include their public key with the

   message as appropriate), but bodies are encrypted with the public key

   of the intended recipient.  Obviously, senders must have

   foreknowledge of the public key of recipients in order to encrypt

   message bodies.  Public keys can be stored within a UA on a virtual

   keyring.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Each user agent that supports S/MIME MUST contain a keyring

   specifically for end-users' certificates.  This keyring should map

   between addresses of record and corresponding certificates.  Over

   time, users SHOULD use the same certificate when they populate the

   originating URI of signaling (the From header field) with the same

   address-of-record.



   Any mechanisms depending on the existence of end-user certificates

   are seriously limited in that there is virtually no consolidated

   authority today that provides certificates for end-user applications.

   However, users SHOULD acquire certificates from known public

   certificate authorities.  As an alternative, users MAY create self-

   signed certificates.  The implications of self-signed certificates

   are explored further in Section 26.4.2.  Implementations may also use

   pre-configured certificates in deployments in which a previous trust

   relationship exists between all SIP entities.



   Above and beyond the problem of acquiring an end-user certificate,

   there are few well-known centralized directories that distribute

   end-user certificates.  However, the holder of a certificate SHOULD

   publish their certificate in any public directories as appropriate.

   Similarly, UACs SHOULD support a mechanism for importing (manually or

   automatically) certificates discovered in public directories

   corresponding to the target URIs of SIP requests.



23.2 S/MIME Key Exchange



   SIP itself can also be used as a means to distribute public keys in

   the following manner.



   Whenever the CMS SignedData message is used in S/MIME for SIP, it

   MUST contain the certificate bearing the public key necessary to

   verify the signature.



   When a UAC sends a request containing an S/MIME body that initiates a

   dialog, or sends a non-INVITE request outside the context of a

   dialog, the UAC SHOULD structure the body as an S/MIME

   'multipart/signed' CMS SignedData body.  If the desired CMS service

   is EnvelopedData (and the public key of the target user is known),

   the UAC SHOULD send the EnvelopedData message encapsulated within a

   SignedData message.



   When a UAS receives a request containing an S/MIME CMS body that

   includes a certificate, the UAS SHOULD first validate the

   certificate, if possible, with any available root certificates for

   certificate authorities.  The UAS SHOULD also determine the subject

   of the certificate (for S/MIME, the SubjectAltName will contain the

   appropriate identity) and compare this value to the From header field







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   of the request.  If the certificate cannot be verified, because it is

   self-signed, or signed by no known authority, or if it is verifiable

   but its subject does not correspond to the From header field of

   request, the UAS MUST notify its user of the status of the

   certificate (including the subject of the certificate, its signer,

   and any key fingerprint information) and request explicit permission

   before proceeding.  If the certificate was successfully verified and

   the subject of the certificate corresponds to the From header field

   of the SIP request, or if the user (after notification) explicitly

   authorizes the use of the certificate, the UAS SHOULD add this

   certificate to a local keyring, indexed by the address-of-record of

   the holder of the certificate.



   When a UAS sends a response containing an S/MIME body that answers

   the first request in a dialog, or a response to a non-INVITE request

   outside the context of a dialog, the UAS SHOULD structure the body as

   an S/MIME 'multipart/signed' CMS SignedData body.  If the desired CMS

   service is EnvelopedData, the UAS SHOULD send the EnvelopedData

   message encapsulated within a SignedData message.



   When a UAC receives a response containing an S/MIME CMS body that

   includes a certificate, the UAC SHOULD first validate the

   certificate, if possible, with any appropriate root certificate.  The

   UAC SHOULD also determine the subject of the certificate and compare

   this value to the To field of the response; although the two may very

   well be different, and this is not necessarily indicative of a

   security breach.  If the certificate cannot be verified because it is

   self-signed, or signed by no known authority, the UAC MUST notify its

   user of the status of the certificate (including the subject of the

   certificate, its signator, and any key fingerprint information) and

   request explicit permission before proceeding.  If the certificate

   was successfully verified, and the subject of the certificate

   corresponds to the To header field in the response, or if the user

   (after notification) explicitly authorizes the use of the

   certificate, the UAC SHOULD add this certificate to a local keyring,

   indexed by the address-of-record of the holder of the certificate.

   If the UAC had not transmitted its own certificate to the UAS in any

   previous transaction, it SHOULD use a CMS SignedData body for its

   next request or response.



   On future occasions, when the UA receives requests or responses that

   contain a From header field corresponding to a value in its keyring,

   the UA SHOULD compare the certificate offered in these messages with

   the existing certificate in its keyring.  If there is a discrepancy,

   the UA MUST notify its user of a change of the certificate

   (preferably in terms that indicate that this is a potential security

   breach) and acquire the user's permission before continuing to









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   process the signaling.  If the user authorizes this certificate, it

   SHOULD be added to the keyring alongside any previous value(s) for

   this address-of-record.



   Note well however, that this key exchange mechanism does not

   guarantee the secure exchange of keys when self-signed certificates,

   or certificates signed by an obscure authority, are used - it is

   vulnerable to well-known attacks.  In the opinion of the authors,

   however, the security it provides is proverbially better than

   nothing; it is in fact comparable to the widely used SSH application.

   These limitations are explored in greater detail in Section 26.4.2.



   If a UA receives an S/MIME body that has been encrypted with a public

   key unknown to the recipient, it MUST reject the request with a 493

   (Undecipherable) response.  This response SHOULD contain a valid

   certificate for the respondent (corresponding, if possible, to any

   address of record given in the To header field of the rejected

   request) within a MIME body with a 'certs-only' "smime-type"

   parameter.



   A 493 (Undecipherable) sent without any certificate indicates that

   the respondent cannot or will not utilize S/MIME encrypted messages,

   though they may still support S/MIME signatures.



   Note that a user agent that receives a request containing an S/MIME

   body that is not optional (with a Content-Disposition header

   "handling" parameter of "required") MUST reject the request with a

   415 Unsupported Media Type response if the MIME type is not

   understood.  A user agent that receives such a response when S/MIME

   is sent SHOULD notify its user that the remote device does not

   support S/MIME, and it MAY subsequently resend the request without

   S/MIME, if appropriate; however, this 415 response may constitute a

   downgrade attack.



   If a user agent sends an S/MIME body in a request, but receives a

   response that contains a MIME body that is not secured, the UAC

   SHOULD notify its user that the session could not be secured.

   However, if a user agent that supports S/MIME receives a request with

   an unsecured body, it SHOULD NOT respond with a secured body, but if

   it expects S/MIME from the sender (for example, because the sender's

   From header field value corresponds to an identity on its keychain),

   the UAS SHOULD notify its user that the session could not be secured.



   A number of conditions that arise in the previous text call for the

   notification of the user when an anomalous certificate-management

   event occurs.  Users might well ask what they should do under these

   circumstances.  First and foremost, an unexpected change in a

   certificate, or an absence of security when security is expected, are







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   causes for caution but not necessarily indications that an attack is

   in progress.  Users might abort any connection attempt or refuse a

   connection request they have received; in telephony parlance, they

   could hang up and call back.  Users may wish to find an alternate

   means to contact the other party and confirm that their key has

   legitimately changed.  Note that users are sometimes compelled to

   change their certificates, for example when they suspect that the

   secrecy of their private key has been compromised.  When their

   private key is no longer private, users must legitimately generate a

   new key and re-establish trust with any users that held their old

   key.



   Finally, if during the course of a dialog a UA receives a certificate

   in a CMS SignedData message that does not correspond with the

   certificates previously exchanged during a dialog, the UA MUST notify

   its user of the change, preferably in terms that indicate that this

   is a potential security breach.



23.3 Securing MIME bodies



   There are two types of secure MIME bodies that are of interest to

   SIP: use of these bodies should follow the S/MIME specification [24]

   with a few variations.



      o  "multipart/signed" MUST be used only with CMS detached

         signatures.



            This allows backwards compatibility with non-S/MIME-

            compliant recipients.



      o  S/MIME bodies SHOULD have a Content-Disposition header field,

         and the value of the "handling" parameter SHOULD be "required."



      o  If a UAC has no certificate on its keyring associated with the

         address-of-record to which it wants to send a request, it

         cannot send an encrypted "application/pkcs7-mime" MIME message.

         UACs MAY send an initial request such as an OPTIONS message

         with a CMS detached signature in order to solicit the

         certificate of the remote side (the signature SHOULD be over a

         "message/sip" body of the type described in Section 23.4).



            Note that future standardization work on S/MIME may define

            non-certificate based keys.



      o  Senders of S/MIME bodies SHOULD use the "SMIMECapabilities"

         (see Section 2.5.2 of [24]) attribute to express their

         capabilities and preferences for further communications.  Note

         especially that senders MAY use the "preferSignedData"







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         capability to encourage receivers to respond with CMS

         SignedData messages (for example, when sending an OPTIONS

         request as described above).



      o  S/MIME implementations MUST at a minimum support SHA1 as a

         digital signature algorithm, and 3DES as an encryption

         algorithm.  All other signature and encryption algorithms MAY

         be supported.  Implementations can negotiate support for these

         algorithms with the "SMIMECapabilities" attribute.



      o  Each S/MIME body in a SIP message SHOULD be signed with only

         one certificate.  If a UA receives a message with multiple

         signatures, the outermost signature should be treated as the

         single certificate for this body.  Parallel signatures SHOULD

         NOT be used.



         The following is an example of an encrypted S/MIME SDP body

         within a SIP message:



        INVITE sip:bob@biloxi.com SIP/2.0

        Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

        To: Bob <sip:bob@biloxi.com>

        From: Alice <sip:alice@atlanta.com>;tag=1928301774

        Call-ID: a84b4c76e66710

        CSeq: 314159 INVITE

        Max-Forwards: 70

        Contact: <sip:alice@pc33.atlanta.com>

        Content-Type: application/pkcs7-mime; smime-type=enveloped-data;

             name=smime.p7m

        Content-Disposition: attachment; filename=smime.p7m

           handling=required



      *******************************************************

      * Content-Type: application/sdp                       *

      *                                                     *

      * v=0                                                 *

      * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com *

      * s=-                                                 *

      * t=0 0                                               *

      * c=IN IP4 pc33.atlanta.com                           *

      * m=audio 3456 RTP/AVP 0 1 3 99                       *

      * a=rtpmap:0 PCMU/8000                                *

      *******************************************************

















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP



   As a means of providing some degree of end-to-end authentication,

   integrity or confidentiality for SIP header fields, S/MIME can

   encapsulate entire SIP messages within MIME bodies of type

   "message/sip" and then apply MIME security to these bodies in the

   same manner as typical SIP bodies.  These encapsulated SIP requests

   and responses do not constitute a separate dialog or transaction,

   they are a copy of the "outer" message that is used to verify

   integrity or to supply additional information.



   If a UAS receives a request that contains a tunneled "message/sip"

   S/MIME body, it SHOULD include a tunneled "message/sip" body in the

   response with the same smime-type.



   Any traditional MIME bodies (such as SDP) SHOULD be attached to the

   "inner" message so that they can also benefit from S/MIME security.

   Note that "message/sip" bodies can be sent as a part of a MIME

   "multipart/mixed" body if any unsecured MIME types should also be

   transmitted in a request.



23.4.1 Integrity and Confidentiality Properties of SIP Headers



   When the S/MIME integrity or confidentiality mechanisms are used,

   there may be discrepancies between the values in the "inner" message

   and values in the "outer" message.  The rules for handling any such

   differences for all of the header fields described in this document

   are given in this section.



   Note that for the purposes of loose timestamping, all SIP messages

   that tunnel "message/sip" SHOULD contain a Date header in both the

   "inner" and "outer" headers.



23.4.1.1 Integrity



   Whenever integrity checks are performed, the integrity of a header

   field should be determined by matching the value of the header field

   in the signed body with that in the "outer" messages using the

   comparison rules of SIP as described in 20.



   Header fields that can be legitimately modified by proxy servers are:

   Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy-

   Authorization.  If these header fields are not intact end-to-end,

   implementations SHOULD NOT consider this a breach of security.

   Changes to any other header fields defined in this document

   constitute an integrity violation; users MUST be notified of a

   discrepancy.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





23.4.1.2 Confidentiality



   When messages are encrypted, header fields may be included in the

   encrypted body that are not present in the "outer" message.



   Some header fields must always have a plaintext version because they

   are required header fields in requests and responses - these include:



   To, From, Call-ID, CSeq, Contact.  While it is probably not useful to

   provide an encrypted alternative for the Call-ID, CSeq, or Contact,

   providing an alternative to the information in the "outer" To or From

   is permitted.  Note that the values in an encrypted body are not used

   for the purposes of identifying transactions or dialogs - they are

   merely informational.  If the From header field in an encrypted body

   differs from the value in the "outer" message, the value within the

   encrypted body SHOULD be displayed to the user, but MUST NOT be used

   in the "outer" header fields of any future messages.



   Primarily, a user agent will want to encrypt header fields that have

   an end-to-end semantic, including: Subject, Reply-To, Organization,

   Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info,

   Authentication-Info, Expires, In-Reply-To, Require, Supported,

   Unsupported, Retry-After, User-Agent, Server, and Warning.  If any of

   these header fields are present in an encrypted body, they should be

   used instead of any "outer" header fields, whether this entails

   displaying the header field values to users or setting internal

   states in the UA.  They SHOULD NOT however be used in the "outer"

   headers of any future messages.



   If present, the Date header field MUST always be the same in the

   "inner" and "outer" headers.



   Since MIME bodies are attached to the "inner" message,

   implementations will usually encrypt MIME-specific header fields,

   including: MIME-Version, Content-Type, Content-Length, Content-

   Language, Content-Encoding and Content-Disposition.  The "outer"

   message will have the proper MIME header fields for S/MIME bodies.

   These header fields (and any MIME bodies they preface) should be

   treated as normal MIME header fields and bodies received in a SIP

   message.



   It is not particularly useful to encrypt the following header fields:

   Min-Expires, Timestamp, Authorization, Priority, and WWW-

   Authenticate.  This category also includes those header fields that

   can be changed by proxy servers (described in the preceding section).

   UAs SHOULD never include these in an "inner" message if they are not











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   included in the "outer" message.  UAs that receive any of these

   header fields in an encrypted body SHOULD ignore the encrypted

   values.



   Note that extensions to SIP may define additional header fields; the

   authors of these extensions should describe the integrity and

   confidentiality properties of such header fields.  If a SIP UA

   encounters an unknown header field with an integrity violation, it

   MUST ignore the header field.



23.4.2 Tunneling Integrity and Authentication



   Tunneling SIP messages within S/MIME bodies can provide integrity for

   SIP header fields if the header fields that the sender wishes to

   secure are replicated in a "message/sip" MIME body signed with a CMS

   detached signature.



   Provided that the "message/sip" body contains at least the

   fundamental dialog identifiers (To, From, Call-ID, CSeq), then a

   signed MIME body can provide limited authentication.  At the very

   least, if the certificate used to sign the body is unknown to the

   recipient and cannot be verified, the signature can be used to

   ascertain that a later request in a dialog was transmitted by the

   same certificate-holder that initiated the dialog.  If the recipient

   of the signed MIME body has some stronger incentive to trust the

   certificate (they were able to validate it, they acquired it from a

   trusted repository, or they have used it frequently) then the

   signature can be taken as a stronger assertion of the identity of the

   subject of the certificate.



   In order to eliminate possible confusions about the addition or

   subtraction of entire header fields, senders SHOULD replicate all

   header fields from the request within the signed body.  Any message

   bodies that require integrity protection MUST be attached to the

   "inner" message.



   If a Date header is present in a message with a signed body, the

   recipient SHOULD compare the header field value with its own internal

   clock, if applicable.  If a significant time discrepancy is detected

   (on the order of an hour or more), the user agent SHOULD alert the

   user to the anomaly, and note that it is a potential security breach.



   If an integrity violation in a message is detected by its recipient,

   the message MAY be rejected with a 403 (Forbidden) response if it is

   a request, or any existing dialog MAY be terminated.  UAs SHOULD

   notify users of this circumstance and request explicit guidance on

   how to proceed.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The following is an example of the use of a tunneled "message/sip"

   body:



      INVITE sip:bob@biloxi.com SIP/2.0

      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

      To: Bob <sip:bob@biloxi.com>

      From: Alice <sip:alice@atlanta.com>;tag=1928301774

      Call-ID: a84b4c76e66710

      CSeq: 314159 INVITE

      Max-Forwards: 70

      Date: Thu, 21 Feb 2002 13:02:03 GMT

      Contact: <sip:alice@pc33.atlanta.com>

      Content-Type: multipart/signed;

        protocol="application/pkcs7-signature";

        micalg=sha1; boundary=boundary42

      Content-Length: 568



      --boundary42

      Content-Type: message/sip



      INVITE sip:bob@biloxi.com SIP/2.0

      Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

      To: Bob <bob@biloxi.com>

      From: Alice <alice@atlanta.com>;tag=1928301774

      Call-ID: a84b4c76e66710

      CSeq: 314159 INVITE

      Max-Forwards: 70

      Date: Thu, 21 Feb 2002 13:02:03 GMT

      Contact: <sip:alice@pc33.atlanta.com>

      Content-Type: application/sdp

      Content-Length: 147



      v=0

      o=UserA 2890844526 2890844526 IN IP4 here.com

      s=Session SDP

      c=IN IP4 pc33.atlanta.com

      t=0 0

      m=audio 49172 RTP/AVP 0

      a=rtpmap:0 PCMU/8000



      --boundary42

      Content-Type: application/pkcs7-signature; name=smime.p7s

      Content-Transfer-Encoding: base64

      Content-Disposition: attachment; filename=smime.p7s;

         handling=required













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6

      4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj

      n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4

      7GhIGfHfYT64VQbnj756



      --boundary42-



23.4.3 Tunneling Encryption



   It may also be desirable to use this mechanism to encrypt a

   "message/sip" MIME body within a CMS EnvelopedData message S/MIME

   body, but in practice, most header fields are of at least some use to

   the network; the general use of encryption with S/MIME is to secure

   message bodies like SDP rather than message headers.  Some

   informational header fields, such as the Subject or Organization

   could perhaps warrant end-to-end security.  Headers defined by future

   SIP applications might also require obfuscation.



   Another possible application of encrypting header fields is selective

   anonymity.  A request could be constructed with a From header field

   that contains no personal information (for example,

   sip:anonymous@anonymizer.invalid).  However, a second From header

   field containing the genuine address-of-record of the originator

   could be encrypted within a "message/sip" MIME body where it will

   only be visible to the endpoints of a dialog.



      Note that if this mechanism is used for anonymity, the From header

      field will no longer be usable by the recipient of a message as an

      index to their certificate keychain for retrieving the proper

      S/MIME key to associated with the sender.  The message must first

      be decrypted, and the "inner" From header field MUST be used as an

      index.



   In order to provide end-to-end integrity, encrypted "message/sip"

   MIME bodies SHOULD be signed by the sender.  This creates a

   "multipart/signed" MIME body that contains an encrypted body and a

   signature, both of type "application/pkcs7-mime".





























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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   In the following example, of an encrypted and signed message, the

   text boxed in asterisks ("*") is encrypted:



        INVITE sip:bob@biloxi.com SIP/2.0

        Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

        To: Bob <sip:bob@biloxi.com>

        From: Anonymous <sip:anonymous@atlanta.com>;tag=1928301774

        Call-ID: a84b4c76e66710

        CSeq: 314159 INVITE

        Max-Forwards: 70

        Date: Thu, 21 Feb 2002 13:02:03 GMT

        Contact: <sip:pc33.atlanta.com>

        Content-Type: multipart/signed;

          protocol="application/pkcs7-signature";

          micalg=sha1; boundary=boundary42

        Content-Length: 568



        --boundary42

        Content-Type: application/pkcs7-mime; smime-type=enveloped-data;

             name=smime.p7m

        Content-Transfer-Encoding: base64

        Content-Disposition: attachment; filename=smime.p7m

           handling=required

        Content-Length: 231



      ***********************************************************

      * Content-Type: message/sip                               *

      *                                                         *

      * INVITE sip:bob@biloxi.com SIP/2.0                       *

      * Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 *

      * To: Bob <bob@biloxi.com>                                *

      * From: Alice <alice@atlanta.com>;tag=1928301774          *

      * Call-ID: a84b4c76e66710                                 *

      * CSeq: 314159 INVITE                                     *

      * Max-Forwards: 70                                        *

      * Date: Thu, 21 Feb 2002 13:02:03 GMT                     *

      * Contact: <sip:alice@pc33.atlanta.com>                   *

      *                                                         *

      * Content-Type: application/sdp                           *

      *                                                         *

      * v=0                                                     *

      * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com     *

      * s=Session SDP                                           *

      * t=0 0                                                   *

      * c=IN IP4 pc33.atlanta.com                               *

      * m=audio 3456 RTP/AVP 0 1 3 99                           *

      * a=rtpmap:0 PCMU/8000                                    *

      ***********************************************************







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





        --boundary42

        Content-Type: application/pkcs7-signature; name=smime.p7s

        Content-Transfer-Encoding: base64

        Content-Disposition: attachment; filename=smime.p7s;

           handling=required



        ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6

        4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj

        n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4

        7GhIGfHfYT64VQbnj756



        --boundary42-



24 Examples



   In the following examples, we often omit the message body and the

   corresponding Content-Length and Content-Type header fields for

   brevity.



24.1 Registration



   Bob registers on start-up.  The message flow is shown in Figure 9.

   Note that the authentication usually required for registration is not

   shown for simplicity.



                  biloxi.com         Bob's

                   registrar       softphone

                      |                |

                      |   REGISTER F1  |

                      |<---------------|

                      |    200 OK F2   |

                      |--------------->|



                  Figure 9: SIP Registration Example



   F1 REGISTER Bob -> Registrar



       REGISTER sip:registrar.biloxi.com SIP/2.0

       Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7

       Max-Forwards: 70

       To: Bob <sip:bob@biloxi.com>

       From: Bob <sip:bob@biloxi.com>;tag=456248

       Call-ID: 843817637684230@998sdasdh09

       CSeq: 1826 REGISTER

       Contact: <sip:bob@192.0.2.4>

       Expires: 7200

       Content-Length: 0









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The registration expires after two hours.  The registrar responds

   with a 200 OK:



   F2 200 OK Registrar -> Bob



        SIP/2.0 200 OK

        Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7

         ;received=192.0.2.4

        To: Bob <sip:bob@biloxi.com>;tag=2493k59kd

        From: Bob <sip:bob@biloxi.com>;tag=456248

        Call-ID: 843817637684230@998sdasdh09

        CSeq: 1826 REGISTER

        Contact: <sip:bob@192.0.2.4>

        Expires: 7200

        Content-Length: 0



24.2 Session Setup



   This example contains the full details of the example session setup

   in Section 4.  The message flow is shown in Figure 1.  Note that

   these flows show the minimum required set of header fields - some

   other header fields such as Allow and Supported would normally be

   present.



F1 INVITE Alice -> atlanta.com proxy



INVITE sip:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

Max-Forwards: 70

To: Bob <sip:bob@biloxi.com>

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact: <sip:alice@pc33.atlanta.com>

Content-Type: application/sdp

Content-Length: 142



(Alice's SDP not shown)



























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



RFC 3261            SIP: Session Initiation Protocol           June 2002





F2 100 Trying atlanta.com proxy -> Alice



SIP/2.0 100 Trying

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

To: Bob <sip:bob@biloxi.com>

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Content-Length: 0



F3 INVITE atlanta.com proxy -> biloxi.com proxy



INVITE sip:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

Max-Forwards: 69

To: Bob <sip:bob@biloxi.com>

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact: <sip:alice@pc33.atlanta.com>

Content-Type: application/sdp

Content-Length: 142



(Alice's SDP not shown)



F4 100 Trying biloxi.com proxy -> atlanta.com proxy



SIP/2.0 100 Trying

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1

 ;received=192.0.2.2

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

To: Bob <sip:bob@biloxi.com>

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Content-Length: 0























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



RFC 3261            SIP: Session Initiation Protocol           June 2002





F5 INVITE biloxi.com proxy -> Bob



INVITE sip:bob@192.0.2.4 SIP/2.0

Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1

 ;received=192.0.2.2

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

Max-Forwards: 68

To: Bob <sip:bob@biloxi.com>

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact: <sip:alice@pc33.atlanta.com>

Content-Type: application/sdp

Content-Length: 142



(Alice's SDP not shown)



F6 180 Ringing Bob -> biloxi.com proxy



SIP/2.0 180 Ringing

Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1

 ;received=192.0.2.3

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1

 ;received=192.0.2.2

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

To: Bob <sip:bob@biloxi.com>;tag=a6c85cf

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

Contact: <sip:bob@192.0.2.4>

CSeq: 314159 INVITE

Content-Length: 0



F7 180 Ringing biloxi.com proxy -> atlanta.com proxy



SIP/2.0 180 Ringing

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1

 ;received=192.0.2.2

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

To: Bob <sip:bob@biloxi.com>;tag=a6c85cf

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

Contact: <sip:bob@192.0.2.4>

CSeq: 314159 INVITE

Content-Length: 0







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





F8 180 Ringing atlanta.com proxy -> Alice



SIP/2.0 180 Ringing

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

To: Bob <sip:bob@biloxi.com>;tag=a6c85cf

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

Contact: <sip:bob@192.0.2.4>

CSeq: 314159 INVITE

Content-Length: 0



F9 200 OK Bob -> biloxi.com proxy



SIP/2.0 200 OK

Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1

 ;received=192.0.2.3

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1

 ;received=192.0.2.2

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

To: Bob <sip:bob@biloxi.com>;tag=a6c85cf

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact: <sip:bob@192.0.2.4>

Content-Type: application/sdp

Content-Length: 131



(Bob's SDP not shown)



F10 200 OK biloxi.com proxy -> atlanta.com proxy



SIP/2.0 200 OK

Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1

 ;received=192.0.2.2

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

To: Bob <sip:bob@biloxi.com>;tag=a6c85cf

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact: <sip:bob@192.0.2.4>

Content-Type: application/sdp

Content-Length: 131



(Bob's SDP not shown)









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





F11 200 OK atlanta.com proxy -> Alice



SIP/2.0 200 OK

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8

 ;received=192.0.2.1

To: Bob <sip:bob@biloxi.com>;tag=a6c85cf

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Contact: <sip:bob@192.0.2.4>

Content-Type: application/sdp

Content-Length: 131



(Bob's SDP not shown)



F12 ACK Alice -> Bob



ACK sip:bob@192.0.2.4 SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9

Max-Forwards: 70

To: Bob <sip:bob@biloxi.com>;tag=a6c85cf

From: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 ACK

Content-Length: 0



   The media session between Alice and Bob is now established.



   Bob hangs up first.  Note that Bob's SIP phone maintains its own CSeq

   numbering space, which, in this example, begins with 231.  Since Bob

   is making the request, the To and From URIs and tags have been

   swapped.



F13 BYE Bob -> Alice



BYE sip:alice@pc33.atlanta.com SIP/2.0

Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10

Max-Forwards: 70

From: Bob <sip:bob@biloxi.com>;tag=a6c85cf

To: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 231 BYE

Content-Length: 0

















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





F14 200 OK Alice -> Bob



SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10

From: Bob <sip:bob@biloxi.com>;tag=a6c85cf

To: Alice <sip:alice@atlanta.com>;tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 231 BYE

Content-Length: 0



   The SIP Call Flows document [40] contains further examples of SIP

   messages.



25  Augmented BNF for the SIP Protocol



   All of the mechanisms specified in this document are described in

   both prose and an augmented Backus-Naur Form (BNF) defined in RFC

   2234 [10].  Section 6.1 of RFC 2234 defines a set of core rules that

   are used by this specification, and not repeated here.  Implementers

   need to be familiar with the notation and content of RFC 2234 in

   order to understand this specification.  Certain basic rules are in

   uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc.  Angle

   brackets are used within definitions to clarify the use of rule

   names.



   The use of square brackets is redundant syntactically.  It is used as

   a semantic hint that the specific parameter is optional to use.



25.1 Basic Rules



   The following rules are used throughout this specification to

   describe basic parsing constructs.  The US-ASCII coded character set

   is defined by ANSI X3.4-1986.



      alphanum  =  ALPHA / DIGIT

































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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Several rules are incorporated from RFC 2396 [5] but are updated to

   make them compliant with RFC 2234 [10].  These include:



      reserved    =  ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+"

                     / "$" / ","

      unreserved  =  alphanum / mark

      mark        =  "-" / "_" / "." / "!" / "~" / "*" / "'"

                     / "(" / ")"

      escaped     =  "%" HEXDIG HEXDIG



   SIP header field values can be folded onto multiple lines if the

   continuation line begins with a space or horizontal tab.  All linear

   white space, including folding, has the same semantics as SP.  A

   recipient MAY replace any linear white space with a single SP before

   interpreting the field value or forwarding the message downstream.

   This is intended to behave exactly as HTTP/1.1 as described in RFC

   2616 [8].  The SWS construct is used when linear white space is

   optional, generally between tokens and separators.



      LWS  =  [*WSP CRLF] 1*WSP ; linear whitespace

      SWS  =  [LWS] ; sep whitespace



   To separate the header name from the rest of value, a colon is used,

   which, by the above rule, allows whitespace before, but no line

   break, and whitespace after, including a linebreak.  The HCOLON

   defines this construct.



      HCOLON  =  *( SP / HTAB ) ":" SWS



   The TEXT-UTF8 rule is only used for descriptive field contents and

   values that are not intended to be interpreted by the message parser.

   Words of *TEXT-UTF8 contain characters from the UTF-8 charset (RFC

   2279 [7]).  The TEXT-UTF8-TRIM rule is used for descriptive field

   contents that are n t quoted strings, where leading and trailing LWS

   is not meaningful.  In this regard, SIP differs from HTTP, which uses

   the ISO 8859-1 character set.



      TEXT-UTF8-TRIM  =  1*TEXT-UTF8char *(*LWS TEXT-UTF8char)

      TEXT-UTF8char   =  %x21-7E / UTF8-NONASCII

      UTF8-NONASCII   =  %xC0-DF 1UTF8-CONT

                      /  %xE0-EF 2UTF8-CONT

                      /  %xF0-F7 3UTF8-CONT

                      /  %xF8-Fb 4UTF8-CONT

                      /  %xFC-FD 5UTF8-CONT

      UTF8-CONT       =  %x80-BF













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   A CRLF is allowed in the definition of TEXT-UTF8-TRIM only as part of

   a header field continuation.  It is expected that the folding LWS

   will be replaced with a single SP before interpretation of the TEXT-

   UTF8-TRIM value.



   Hexadecimal numeric characters are used in several protocol elements.

   Some elements (authentication) force hex alphas to be lower case.



      LHEX  =  DIGIT / %x61-66 ;lowercase a-f



   Many SIP header field values consist of words separated by LWS or

   special characters.  Unless otherwise stated, tokens are case-

   insensitive.  These special characters MUST be in a quoted string to

   be used within a parameter value.  The word construct is used in

   Call-ID to allow most separators to be used.



      token       =  1*(alphanum / "-" / "." / "!" / "%" / "*"

                     / "_" / "+" / "`" / "'" / "~" )

      separators  =  "(" / ")" / "<" / ">" / "@" /

                     "," / ";" / ":" / "\" / DQUOTE /

                     "/" / "[" / "]" / "?" / "=" /

                     "{" / "}" / SP / HTAB

      word        =  1*(alphanum / "-" / "." / "!" / "%" / "*" /

                     "_" / "+" / "`" / "'" / "~" /

                     "(" / ")" / "<" / ">" /

                     ":" / "\" / DQUOTE /

                     "/" / "[" / "]" / "?" /

                     "{" / "}" )



   When tokens are used or separators are used between elements,

   whitespace is often allowed before or after these characters:



      STAR    =  SWS "*" SWS ; asterisk

      SLASH   =  SWS "/" SWS ; slash

      EQUAL   =  SWS "=" SWS ; equal

      LPAREN  =  SWS "(" SWS ; left parenthesis

      RPAREN  =  SWS ")" SWS ; right parenthesis

      RAQUOT  =  ">" SWS ; right angle quote

      LAQUOT  =  SWS "<"; left angle quote

      COMMA   =  SWS "," SWS ; comma

      SEMI    =  SWS ";" SWS ; semicolon

      COLON   =  SWS ":" SWS ; colon

      LDQUOT  =  SWS DQUOTE; open double quotation mark

      RDQUOT  =  DQUOTE SWS ; close double quotation mark















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Comments can be included in some SIP header fields by surrounding the

   comment text with parentheses.  Comments are only allowed in fields

   containing "comment" as part of their field value definition.  In all

   other fields, parentheses are considered part of the field value.



      comment  =  LPAREN *(ctext / quoted-pair / comment) RPAREN

      ctext    =  %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII

                  / LWS



   ctext includes all chars except left and right parens and backslash.

   A string of text is parsed as a single word if it is quoted using

   double-quote marks.  In quoted strings, quotation marks (") and

   backslashes (\) need to be escaped.



      quoted-string  =  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE

      qdtext         =  LWS / %x21 / %x23-5B / %x5D-7E

                        / UTF8-NONASCII



   The backslash character ("\") MAY be used as a single-character

   quoting mechanism only within quoted-string and comment constructs.

   Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this

   mechanism to avoid conflict with line folding and header separation.



quoted-pair  =  "\" (%x00-09 / %x0B-0C

                / %x0E-7F)



SIP-URI          =  "sip:" [ userinfo ] hostport

                    uri-parameters [ headers ]

SIPS-URI         =  "sips:" [ userinfo ] hostport

                    uri-parameters [ headers ]

userinfo         =  ( user / telephone-subscriber ) [ ":" password ] "@"

user             =  1*( unreserved / escaped / user-unreserved )

user-unreserved  =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"

password         =  *( unreserved / escaped /

                    "&" / "=" / "+" / "$" / "," )

hostport         =  host [ ":" port ]

host             =  hostname / IPv4address / IPv6reference

hostname         =  *( domainlabel "." ) toplabel [ "." ]

domainlabel      =  alphanum

                    / alphanum *( alphanum / "-" ) alphanum

toplabel         =  ALPHA / ALPHA *( alphanum / "-" ) alphanum





















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





IPv4address    =  1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT

IPv6reference  =  "[" IPv6address "]"

IPv6address    =  hexpart [ ":" IPv4address ]

hexpart        =  hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]

hexseq         =  hex4 *( ":" hex4)

hex4           =  1*4HEXDIG

port           =  1*DIGIT



   The BNF for telephone-subscriber can be found in RFC 2806 [9].  Note,

   however, that any characters allowed there that are not allowed in

   the user part of the SIP URI MUST be escaped.



uri-parameters    =  *( ";" uri-parameter)

uri-parameter     =  transport-param / user-param / method-param

                     / ttl-param / maddr-param / lr-param / other-param

transport-param   =  "transport="

                     ( "udp" / "tcp" / "sctp" / "tls"

                     / other-transport)

other-transport   =  token

user-param        =  "user=" ( "phone" / "ip" / other-user)

other-user        =  token

method-param      =  "method=" Method

ttl-param         =  "ttl=" ttl

maddr-param       =  "maddr=" host

lr-param          =  "lr"

other-param       =  pname [ "=" pvalue ]

pname             =  1*paramchar

pvalue            =  1*paramchar

paramchar         =  param-unreserved / unreserved / escaped

param-unreserved  =  "[" / "]" / "/" / ":" / "&" / "+" / "$"



headers         =  "?" header *( "&" header )

header          =  hname "=" hvalue

hname           =  1*( hnv-unreserved / unreserved / escaped )

hvalue          =  *( hnv-unreserved / unreserved / escaped )

hnv-unreserved  =  "[" / "]" / "/" / "?" / ":" / "+" / "$"



SIP-message    =  Request / Response

Request        =  Request-Line

                  *( message-header )

                  CRLF

                  [ message-body ]

Request-Line   =  Method SP Request-URI SP SIP-Version CRLF

Request-URI    =  SIP-URI / SIPS-URI / absoluteURI

absoluteURI    =  scheme ":" ( hier-part / opaque-part )

hier-part      =  ( net-path / abs-path ) [ "?" query ]

net-path       =  "//" authority [ abs-path ]

abs-path       =  "/" path-segments







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





opaque-part    =  uric-no-slash *uric

uric           =  reserved / unreserved / escaped

uric-no-slash  =  unreserved / escaped / ";" / "?" / ":" / "@"

                  / "&" / "=" / "+" / "$" / ","

path-segments  =  segment *( "/" segment )

segment        =  *pchar *( ";" param )

param          =  *pchar

pchar          =  unreserved / escaped /

                  ":" / "@" / "&" / "=" / "+" / "$" / ","

scheme         =  ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

authority      =  srvr / reg-name

srvr           =  [ [ userinfo "@" ] hostport ]

reg-name       =  1*( unreserved / escaped / "$" / ","

                  / ";" / ":" / "@" / "&" / "=" / "+" )

query          =  *uric

SIP-Version    =  "SIP" "/" 1*DIGIT "." 1*DIGIT



message-header  =  (Accept

                /  Accept-Encoding

                /  Accept-Language

                /  Alert-Info

                /  Allow

                /  Authentication-Info

                /  Authorization

                /  Call-ID

                /  Call-Info

                /  Contact

                /  Content-Disposition

                /  Content-Encoding

                /  Content-Language

                /  Content-Length

                /  Content-Type

                /  CSeq

                /  Date

                /  Error-Info

                /  Expires

                /  From

                /  In-Reply-To

                /  Max-Forwards

                /  MIME-Version

                /  Min-Expires

                /  Organization

                /  Priority

                /  Proxy-Authenticate

                /  Proxy-Authorization

                /  Proxy-Require

                /  Record-Route

                /  Reply-To







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





                /  Require

                /  Retry-After

                /  Route

                /  Server

                /  Subject

                /  Supported

                /  Timestamp

                /  To

                /  Unsupported

                /  User-Agent

                /  Via

                /  Warning

                /  WWW-Authenticate

                /  extension-header) CRLF



INVITEm           =  %x49.4E.56.49.54.45 ; INVITE in caps

ACKm              =  %x41.43.4B ; ACK in caps

OPTIONSm          =  %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps

BYEm              =  %x42.59.45 ; BYE in caps

CANCELm           =  %x43.41.4E.43.45.4C ; CANCEL in caps

REGISTERm         =  %x52.45.47.49.53.54.45.52 ; REGISTER in caps

Method            =  INVITEm / ACKm / OPTIONSm / BYEm

                     / CANCELm / REGISTERm

                     / extension-method

extension-method  =  token

Response          =  Status-Line

                     *( message-header )

                     CRLF

                     [ message-body ]



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

Status-Code     =  Informational

               /   Redirection

               /   Success

               /   Client-Error

               /   Server-Error

               /   Global-Failure

               /   extension-code

extension-code  =  3DIGIT

Reason-Phrase   =  *(reserved / unreserved / escaped

                   / UTF8-NONASCII / UTF8-CONT / SP / HTAB)



Informational  =  "100"  ;  Trying

              /   "180"  ;  Ringing

              /   "181"  ;  Call Is Being Forwarded

              /   "182"  ;  Queued

              /   "183"  ;  Session Progress









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





Success  =  "200"  ;  OK



Redirection  =  "300"  ;  Multiple Choices

            /   "301"  ;  Moved Permanently

            /   "302"  ;  Moved Temporarily

            /   "305"  ;  Use Proxy

            /   "380"  ;  Alternative Service



Client-Error  =  "400"  ;  Bad Request

             /   "401"  ;  Unauthorized

             /   "402"  ;  Payment Required

             /   "403"  ;  Forbidden

             /   "404"  ;  Not Found

             /   "405"  ;  Method Not Allowed

             /   "406"  ;  Not Acceptable

             /   "407"  ;  Proxy Authentication Required

             /   "408"  ;  Request Timeout

             /   "410"  ;  Gone

             /   "413"  ;  Request Entity Too Large

             /   "414"  ;  Request-URI Too Large

             /   "415"  ;  Unsupported Media Type

             /   "416"  ;  Unsupported URI Scheme

             /   "420"  ;  Bad Extension

             /   "421"  ;  Extension Required

             /   "423"  ;  Interval Too Brief

             /   "480"  ;  Temporarily not available

             /   "481"  ;  Call Leg/Transaction Does Not Exist

             /   "482"  ;  Loop Detected

             /   "483"  ;  Too Many Hops

             /   "484"  ;  Address Incomplete

             /   "485"  ;  Ambiguous

             /   "486"  ;  Busy Here

             /   "487"  ;  Request Terminated

             /   "488"  ;  Not Acceptable Here

             /   "491"  ;  Request Pending

             /   "493"  ;  Undecipherable



Server-Error  =  "500"  ;  Internal Server Error

             /   "501"  ;  Not Implemented

             /   "502"  ;  Bad Gateway

             /   "503"  ;  Service Unavailable

             /   "504"  ;  Server Time-out

             /   "505"  ;  SIP Version not supported

             /   "513"  ;  Message Too Large















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





Global-Failure  =  "600"  ;  Busy Everywhere

               /   "603"  ;  Decline

               /   "604"  ;  Does not exist anywhere

               /   "606"  ;  Not Acceptable



Accept         =  "Accept" HCOLON

                   [ accept-range *(COMMA accept-range) ]

accept-range   =  media-range *(SEMI accept-param)

media-range    =  ( "*/*"

                  / ( m-type SLASH "*" )

                  / ( m-type SLASH m-subtype )

                  ) *( SEMI m-parameter )

accept-param   =  ("q" EQUAL qvalue) / generic-param

qvalue         =  ( "0" [ "." 0*3DIGIT ] )

                  / ( "1" [ "." 0*3("0") ] )

generic-param  =  token [ EQUAL gen-value ]

gen-value      =  token / host / quoted-string



Accept-Encoding  =  "Accept-Encoding" HCOLON

                     [ encoding *(COMMA encoding) ]

encoding         =  codings *(SEMI accept-param)

codings          =  content-coding / "*"

content-coding   =  token



Accept-Language  =  "Accept-Language" HCOLON

                     [ language *(COMMA language) ]

language         =  language-range *(SEMI accept-param)

language-range   =  ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) / "*" )



Alert-Info   =  "Alert-Info" HCOLON alert-param *(COMMA alert-param)

alert-param  =  LAQUOT absoluteURI RAQUOT *( SEMI generic-param )



Allow  =  "Allow" HCOLON [Method *(COMMA Method)]



Authorization     =  "Authorization" HCOLON credentials

credentials       =  ("Digest" LWS digest-response)

                     / other-response

digest-response   =  dig-resp *(COMMA dig-resp)

dig-resp          =  username / realm / nonce / digest-uri

                      / dresponse / algorithm / cnonce

                      / opaque / message-qop

                      / nonce-count / auth-param

username          =  "username" EQUAL username-value

username-value    =  quoted-string

digest-uri        =  "uri" EQUAL LDQUOT digest-uri-value RDQUOT

digest-uri-value  =  rquest-uri ; Equal to request-uri as specified

                     by HTTP/1.1

message-qop       =  "qop" EQUAL qop-value







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





cnonce            =  "cnonce" EQUAL cnonce-value

cnonce-value      =  nonce-value

nonce-count       =  "nc" EQUAL nc-value

nc-value          =  8LHEX

dresponse         =  "response" EQUAL request-digest

request-digest    =  LDQUOT 32LHEX RDQUOT

auth-param        =  auth-param-name EQUAL

                     ( token / quoted-string )

auth-param-name   =  token

other-response    =  auth-scheme LWS auth-param

                     *(COMMA auth-param)

auth-scheme       =  token



Authentication-Info  =  "Authentication-Info" HCOLON ainfo

                        *(COMMA ainfo)

ainfo                =  nextnonce / message-qop

                         / response-auth / cnonce

                         / nonce-count

nextnonce            =  "nextnonce" EQUAL nonce-value

response-auth        =  "rspauth" EQUAL response-digest

response-digest      =  LDQUOT *LHEX RDQUOT



Call-ID  =  ( "Call-ID" / "i" ) HCOLON callid

callid   =  word [ "@" word ]



Call-Info   =  "Call-Info" HCOLON info *(COMMA info)

info        =  LAQUOT absoluteURI RAQUOT *( SEMI info-param)

info-param  =  ( "purpose" EQUAL ( "icon" / "info"

               / "card" / token ) ) / generic-param



Contact        =  ("Contact" / "m" ) HCOLON

                  ( STAR / (contact-param *(COMMA contact-param)))

contact-param  =  (name-addr / addr-spec) *(SEMI contact-params)

name-addr      =  [ display-name ] LAQUOT addr-spec RAQUOT

addr-spec      =  SIP-URI / SIPS-URI / absoluteURI

display-name   =  *(token LWS)/ quoted-string



contact-params     =  c-p-q / c-p-expires

                      / contact-extension

c-p-q              =  "q" EQUAL qvalue

c-p-expires        =  "expires" EQUAL delta-seconds

contact-extension  =  generic-param

delta-seconds      =  1*DIGIT



Content-Disposition   =  "Content-Disposition" HCOLON

                         disp-type *( SEMI disp-param )

disp-type             =  "render" / "session" / "icon" / "alert"

                         / disp-extension-token







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





disp-param            =  handling-param / generic-param

handling-param        =  "handling" EQUAL

                         ( "optional" / "required"

                         / other-handling )

other-handling        =  token

disp-extension-token  =  token



Content-Encoding  =  ( "Content-Encoding" / "e" ) HCOLON

                     content-coding *(COMMA content-coding)



Content-Language  =  "Content-Language" HCOLON

                     language-tag *(COMMA language-tag)

language-tag      =  primary-tag *( "-" subtag )

primary-tag       =  1*8ALPHA

subtag            =  1*8ALPHA



Content-Length  =  ( "Content-Length" / "l" ) HCOLON 1*DIGIT

Content-Type     =  ( "Content-Type" / "c" ) HCOLON media-type

media-type       =  m-type SLASH m-subtype *(SEMI m-parameter)

m-type           =  discrete-type / composite-type

discrete-type    =  "text" / "image" / "audio" / "video"

                    / "application" / extension-token

composite-type   =  "message" / "multipart" / extension-token

extension-token  =  ietf-token / x-token

ietf-token       =  token

x-token          =  "x-" token

m-subtype        =  extension-token / iana-token

iana-token       =  token

m-parameter      =  m-attribute EQUAL m-value

m-attribute      =  token

m-value          =  token / quoted-string



CSeq  =  "CSeq" HCOLON 1*DIGIT LWS Method



Date          =  "Date" HCOLON SIP-date

SIP-date      =  rfc1123-date

rfc1123-date  =  wkday "," SP date1 SP time SP "GMT"

date1         =  2DIGIT SP month SP 4DIGIT

                 ; day month year (e.g., 02 Jun 1982)

time          =  2DIGIT ":" 2DIGIT ":" 2DIGIT

                 ; 00:00:00 - 23:59:59

wkday         =  "Mon" / "Tue" / "Wed"

                 / "Thu" / "Fri" / "Sat" / "Sun"

month         =  "Jan" / "Feb" / "Mar" / "Apr"

                 / "May" / "Jun" / "Jul" / "Aug"

                 / "Sep" / "Oct" / "Nov" / "Dec"



Error-Info  =  "Error-Info" HCOLON error-uri *(COMMA error-uri)







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





error-uri   =  LAQUOT absoluteURI RAQUOT *( SEMI generic-param )



Expires     =  "Expires" HCOLON delta-seconds

From        =  ( "From" / "f" ) HCOLON from-spec

from-spec   =  ( name-addr / addr-spec )

               *( SEMI from-param )

from-param  =  tag-param / generic-param

tag-param   =  "tag" EQUAL token



In-Reply-To  =  "In-Reply-To" HCOLON callid *(COMMA callid)



Max-Forwards  =  "Max-Forwards" HCOLON 1*DIGIT



MIME-Version  =  "MIME-Version" HCOLON 1*DIGIT "." 1*DIGIT



Min-Expires  =  "Min-Expires" HCOLON delta-seconds



Organization  =  "Organization" HCOLON [TEXT-UTF8-TRIM]



Priority        =  "Priority" HCOLON priority-value

priority-value  =  "emergency" / "urgent" / "normal"

                   / "non-urgent" / other-priority

other-priority  =  token



Proxy-Authenticate  =  "Proxy-Authenticate" HCOLON challenge

challenge           =  ("Digest" LWS digest-cln *(COMMA digest-cln))

                       / other-challenge

other-challenge     =  auth-scheme LWS auth-param

                       *(COMMA auth-param)

digest-cln          =  realm / domain / nonce

                        / opaque / stale / algorithm

                        / qop-options / auth-param

realm               =  "realm" EQUAL realm-value

realm-value         =  quoted-string

domain              =  "domain" EQUAL LDQUOT URI

                       *( 1*SP URI ) RDQUOT

URI                 =  absoluteURI / abs-path

nonce               =  "nonce" EQUAL nonce-value

nonce-value         =  quoted-string

opaque              =  "opaque" EQUAL quoted-string

stale               =  "stale" EQUAL ( "true" / "false" )

algorithm           =  "algorithm" EQUAL ( "MD5" / "MD5-sess"

                       / token )

qop-options         =  "qop" EQUAL LDQUOT qop-value

                       *("," qop-value) RDQUOT

qop-value           =  "auth" / "auth-int" / token



Proxy-Authorization  =  "Proxy-Authorization" HCOLON credentials







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





Proxy-Require  =  "Proxy-Require" HCOLON option-tag

                  *(COMMA option-tag)

option-tag     =  token



Record-Route  =  "Record-Route" HCOLON rec-route *(COMMA rec-route)

rec-route     =  name-addr *( SEMI rr-param )

rr-param      =  generic-param



Reply-To      =  "Reply-To" HCOLON rplyto-spec

rplyto-spec   =  ( name-addr / addr-spec )

                 *( SEMI rplyto-param )

rplyto-param  =  generic-param

Require       =  "Require" HCOLON option-tag *(COMMA option-tag)



Retry-After  =  "Retry-After" HCOLON delta-seconds

                [ comment ] *( SEMI retry-param )



retry-param  =  ("duration" EQUAL delta-seconds)

                / generic-param



Route        =  "Route" HCOLON route-param *(COMMA route-param)

route-param  =  name-addr *( SEMI rr-param )



Server           =  "Server" HCOLON server-val *(LWS server-val)

server-val       =  product / comment

product          =  token [SLASH product-version]

product-version  =  token



Subject  =  ( "Subject" / "s" ) HCOLON [TEXT-UTF8-TRIM]



Supported  =  ( "Supported" / "k" ) HCOLON

              [option-tag *(COMMA option-tag)]



Timestamp  =  "Timestamp" HCOLON 1*(DIGIT)

               [ "." *(DIGIT) ] [ LWS delay ]

delay      =  *(DIGIT) [ "." *(DIGIT) ]



To        =  ( "To" / "t" ) HCOLON ( name-addr

             / addr-spec ) *( SEMI to-param )

to-param  =  tag-param / generic-param



Unsupported  =  "Unsupported" HCOLON option-tag *(COMMA option-tag)

User-Agent  =  "User-Agent" HCOLON server-val *(LWS server-val)

















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





Via               =  ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm)

via-parm          =  sent-protocol LWS sent-by *( SEMI via-params )

via-params        =  via-ttl / via-maddr

                     / via-received / via-branch

                     / via-extension

via-ttl           =  "ttl" EQUAL ttl

via-maddr         =  "maddr" EQUAL host

via-received      =  "received" EQUAL (IPv4address / IPv6address)

via-branch        =  "branch" EQUAL token

via-extension     =  generic-param

sent-protocol     =  protocol-name SLASH protocol-version

                     SLASH transport

protocol-name     =  "SIP" / token

protocol-version  =  token

transport         =  "UDP" / "TCP" / "TLS" / "SCTP"

                     / other-transport

sent-by           =  host [ COLON port ]

ttl               =  1*3DIGIT ; 0 to 255



Warning        =  "Warning" HCOLON warning-value *(COMMA warning-value)

warning-value  =  warn-code SP warn-agent SP warn-text

warn-code      =  3DIGIT

warn-agent     =  hostport / pseudonym

                  ;  the name or pseudonym of the server adding

                  ;  the Warning header, for use in debugging

warn-text      =  quoted-string

pseudonym      =  token



WWW-Authenticate  =  "WWW-Authenticate" HCOLON challenge



extension-header  =  header-name HCOLON header-value

header-name       =  token

header-value      =  *(TEXT-UTF8char / UTF8-CONT / LWS)

message-body  =  *OCTET



26 Security Considerations: Threat Model and Security Usage

   Recommendations



   SIP is not an easy protocol to secure.  Its use of intermediaries,

   its multi-faceted trust relationships, its expected usage between

   elements with no trust at all, and its user-to-user operation make

   security far from trivial.  Security solutions are needed that are

   deployable today, without extensive coordination, in a wide variety

   of environments and usages.  In order to meet these diverse needs,

   several distinct mechanisms applicable to different aspects and

   usages of SIP will be required.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Note that the security of SIP signaling itself has no bearing on the

   security of protocols used in concert with SIP such as RTP, or with

   the security implications of any specific bodies SIP might carry

   (although MIME security plays a substantial role in securing SIP).

   Any media associated with a session can be encrypted end-to-end

   independently of any associated SIP signaling.  Media encryption is

   outside the scope of this document.



   The considerations that follow first examine a set of classic threat

   models that broadly identify the security needs of SIP.  The set of

   security services required to address these threats is then detailed,

   followed by an explanation of several security mechanisms that can be

   used to provide these services.  Next, the requirements for

   implementers of SIP are enumerated, along with exemplary deployments

   in which these security mechanisms could be used to improve the

   security of SIP.  Some notes on privacy conclude this section.



26.1 Attacks and Threat Models



   This section details some threats that should be common to most

   deployments of SIP.  These threats have been chosen specifically to

   illustrate each of the security services that SIP requires.



   The following examples by no means provide an exhaustive list of the

   threats against SIP; rather, these are "classic" threats that

   demonstrate the need for particular security services that can

   potentially prevent whole categories of threats.



   These attacks assume an environment in which attackers can

   potentially read any packet on the network - it is anticipated that

   SIP will frequently be used on the public Internet.  Attackers on the

   network may be able to modify packets (perhaps at some compromised

   intermediary).  Attackers may wish to steal services, eavesdrop on

   communications, or disrupt sessions.



26.1.1 Registration Hijacking



   The SIP registration mechanism allows a user agent to identify itself

   to a registrar as a device at which a user (designated by an address

   of record) is located.  A registrar assesses the identity asserted in

   the From header field of a REGISTER message to determine whether this

   request can modify the contact addresses associated with the

   address-of-record in the To header field.  While these two fields are

   frequently the same, there are many valid deployments in which a

   third-party may register contacts on a user's behalf.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The From header field of a SIP request, however, can be modified

   arbitrarily by the owner of a UA, and this opens the door to

   malicious registrations.  An attacker that successfully impersonates

   a party authorized to change contacts associated with an address-of-

   record could, for example, de-register all existing contacts for a

   URI and then register their own device as the appropriate contact

   address, thereby directing all requests for the affected user to the

   attacker's device.



   This threat belongs to a family of threats that rely on the absence

   of cryptographic assurance of a request's originator.  Any SIP UAS

   that represents a valuable service (a gateway that interworks SIP

   requests with traditional telephone calls, for example) might want to

   control access to its resources by authenticating requests that it

   receives.  Even end-user UAs, for example SIP phones, have an

   interest in ascertaining the identities of originators of requests.



   This threat demonstrates the need for security services that enable

   SIP entities to authenticate the originators of requests.



26.1.2 Impersonating a Server



   The domain to which a request is destined is generally specified in

   the Request-URI.  UAs commonly contact a server in this domain

   directly in order to deliver a request.  However, there is always a

   possibility that an attacker could impersonate the remote server, and

   that the UA's request could be intercepted by some other party.



   For example, consider a case in which a redirect server at one

   domain, chicago.com, impersonates a redirect server at another

   domain, biloxi.com.  A user agent sends a request to biloxi.com, but

   the redirect server at chicago.com answers with a forged response

   that has appropriate SIP header fields for a response from

   biloxi.com.  The forged contact addresses in the redirection response

   could direct the originating UA to inappropriate or insecure

   resources, or simply prevent requests for biloxi.com from succeeding.



   This family of threats has a vast membership, many of which are

   critical.  As a converse to the registration hijacking threat,

   consider the case in which a registration sent to biloxi.com is

   intercepted by chicago.com, which replies to the intercepted

   registration with a forged 301 (Moved Permanently) response.  This

   response might seem to come from biloxi.com yet designate chicago.com

   as the appropriate registrar.  All future REGISTER requests from the

   originating UA would then go to chicago.com.



   Prevention of this threat requires a means by which UAs can

   authenticate the servers to whom they send requests.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





26.1.3 Tampering with Message Bodies



   As a matter of course, SIP UAs route requests through trusted proxy

   servers.  Regardless of how that trust is established (authentication

   of proxies is discussed elsewhere in this section), a UA may trust a

   proxy server to route a request, but not to inspect or possibly

   modify the bodies contained in that request.



   Consider a UA that is using SIP message bodies to communicate session

   encryption keys for a media session.  Although it trusts the proxy

   server of the domain it is contacting to deliver signaling properly,

   it may not want the administrators of that domain to be capable of

   decrypting any subsequent media session.  Worse yet, if the proxy

   server were actively malicious, it could modify the session key,

   either acting as a man-in-the-middle, or perhaps changing the

   security characteristics requested by the originating UA.



   This family of threats applies not only to session keys, but to most

   conceivable forms of content carried end-to-end in SIP.  These might

   include MIME bodies that should be rendered to the user, SDP, or

   encapsulated telephony signals, among others.  Attackers might

   attempt to modify SDP bodies, for example, in order to point RTP

   media streams to a wiretapping device in order to eavesdrop on

   subsequent voice communications.



   Also note that some header fields in SIP are meaningful end-to-end,

   for example, Subject.  UAs might be protective of these header fields

   as well as bodies (a malicious intermediary changing the Subject

   header field might make an important request appear to be spam, for

   example).  However, since many header fields are legitimately

   inspected or altered by proxy servers as a request is routed, not all

   header fields should be secured end-to-end.



   For these reasons, the UA might want to secure SIP message bodies,

   and in some limited cases header fields, end-to-end.  The security

   services required for bodies include confidentiality, integrity, and

   authentication.  These end-to-end services should be independent of

   the means used to secure interactions with intermediaries such as

   proxy servers.



26.1.4 Tearing Down Sessions



   Once a dialog has been established by initial messaging, subsequent

   requests can be sent that modify the state of the dialog and/or

   session.  It is critical that principals in a session can be certain

   that such requests are not forged by attackers.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Consider a case in which a third-party attacker captures some initial

   messages in a dialog shared by two parties in order to learn the

   parameters of the session (To tag, From tag, and so forth) and then

   inserts a BYE request into the session.  The attacker could opt to

   forge the request such that it seemed to come from either

   participant.  Once the BYE is received by its target, the session

   will be torn down prematurely.



   Similar mid-session threats include the transmission of forged re-

   INVITEs that alter the session (possibly to reduce session security

   or redirect media streams as part of a wiretapping attack).



   The most effective countermeasure to this threat is the

   authentication of the sender of the BYE.  In this instance, the

   recipient needs only know that the BYE came from the same party with

   whom the corresponding dialog was established (as opposed to

   ascertaining the absolute identity of the sender).  Also, if the

   attacker is unable to learn the parameters of the session due to

   confidentiality, it would not be possible to forge the BYE.  However,

   some intermediaries (like proxy servers) will need to inspect those

   parameters as the session is established.



26.1.5 Denial of Service and Amplification



   Denial-of-service attacks focus on rendering a particular network

   element unavailable, usually by directing an excessive amount of

   network traffic at its interfaces.  A distributed denial-of-service

   attack allows one network user to cause multiple network hosts to

   flood a target host with a large amount of network traffic.



   In many architectures, SIP proxy servers face the public Internet in

   order to accept requests from worldwide IP endpoints.  SIP creates a

   number of potential opportunities for distributed denial-of-service

   attacks that must be recognized and addressed by the implementers and

   operators of SIP systems.



   Attackers can create bogus requests that contain a falsified source

   IP address and a corresponding Via header field that identify a

   targeted host as the originator of the request and then send this

   request to a large number of SIP network elements, thereby using

   hapless SIP UAs or proxies to generate denial-of-service traffic

   aimed at the target.



   Similarly, attackers might use falsified Route header field values in

   a request that identify the target host and then send such messages

   to forking proxies that will amplify messaging sent to the target.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Record-Route could be used to similar effect when the attacker is

   certain that the SIP dialog initiated by the request will result in

   numerous transactions originating in the backwards direction.



   A number of denial-of-service attacks open up if REGISTER requests

   are not properly authenticated and authorized by registrars.

   Attackers could de-register some or all users in an administrative

   domain, thereby preventing these users from being invited to new

   sessions.  An attacker could also register a large number of contacts

   designating the same host for a given address-of-record in order to

   use the registrar and any associated proxy servers as amplifiers in a

   denial-of-service attack.  Attackers might also attempt to deplete

   available memory and disk resources of a registrar by registering

   huge numbers of bindings.



   The use of multicast to transmit SIP requests can greatly increase

   the potential for denial-of-service attacks.



   These problems demonstrate a general need to define architectures

   that minimize the risks of denial-of-service, and the need to be

   mindful in recommendations for security mechanisms of this class of

   attacks.



26.2 Security Mechanisms



   From the threats described above, we gather that the fundamental

   security services required for the SIP protocol are: preserving the

   confidentiality and integrity of messaging, preventing replay attacks

   or message spoofing, providing for the authentication and privacy of

   the participants in a session, and preventing denial-of-service

   attacks.  Bodies within SIP messages separately require the security

   services of confidentiality, integrity, and authentication.



   Rather than defining new security mechanisms specific to SIP, SIP

   reuses wherever possible existing security models derived from the

   HTTP and SMTP space.



   Full encryption of messages provides the best means to preserve the

   confidentiality of signaling - it can also guarantee that messages

   are not modified by any malicious intermediaries.  However, SIP

   requests and responses cannot be naively encrypted end-to-end in

   their entirety because message fields such as the Request-URI, Route,

   and Via need to be visible to proxies in most network architectures

   so that SIP requests are routed correctly.  Note that proxy servers

   need to modify some features of messages as well (such as adding Via

   header field values) in order for SIP to function.  Proxy servers

   must therefore be trusted, to some degree, by SIP UAs.  To this

   purpose, low-layer security mechanisms for SIP are recommended, which







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   encrypt the entire SIP requests or responses on the wire on a hop-

   by-hop basis, and that allow endpoints to verify the identity of

   proxy servers to whom they send requests.



   SIP entities also have a need to identify one another in a secure

   fashion.  When a SIP endpoint asserts the identity of its user to a

   peer UA or to a proxy server, that identity should in some way be

   verifiable.  A cryptographic authentication mechanism is provided in

   SIP to address this requirement.



   An independent security mechanism for SIP message bodies supplies an

   alternative means of end-to-end mutual authentication, as well as

   providing a limit on the degree to which user agents must trust

   intermediaries.



26.2.1 Transport and Network Layer Security



   Transport or network layer security encrypts signaling traffic,

   guaranteeing message confidentiality and integrity.



   Oftentimes, certificates are used in the establishment of lower-layer

   security, and these certificates can also be used to provide a means

   of authentication in many architectures.



   Two popular alternatives for providing security at the transport and

   network layer are, respectively, TLS [25] and IPSec [26].



   IPSec is a set of network-layer protocol tools that collectively can

   be used as a secure replacement for traditional IP (Internet

   Protocol).  IPSec is most commonly used in architectures in which a

   set of hosts or administrative domains have an existing trust

   relationship with one another.  IPSec is usually implemented at the

   operating system level in a host, or on a security gateway that

   provides confidentiality and integrity for all traffic it receives

   from a particular interface (as in a VPN architecture).  IPSec can

   also be used on a hop-by-hop basis.



   In many architectures IPSec does not require integration with SIP

   applications; IPSec is perhaps best suited to deployments in which

   adding security directly to SIP hosts would be arduous.  UAs that

   have a pre-shared keying relationship with their first-hop proxy

   server are also good candidates to use IPSec.  Any deployment of

   IPSec for SIP would require an IPSec profile describing the protocol

   tools that would be required to secure SIP.  No such profile is given

   in this document.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   TLS provides transport-layer security over connection-oriented

   protocols (for the purposes of this document, TCP); "tls" (signifying

   TLS over TCP) can be specified as the desired transport protocol

   within a Via header field value or a SIP-URI.  TLS is most suited to

   architectures in which hop-by-hop security is required between hosts

   with no pre-existing trust association.  For example, Alice trusts

   her local proxy server, which after a certificate exchange decides to

   trust Bob's local proxy server, which Bob trusts, hence Bob and Alice

   can communicate securely.



   TLS must be tightly coupled with a SIP application.  Note that

   transport mechanisms are specified on a hop-by-hop basis in SIP, thus

   a UA that sends requests over TLS to a proxy server has no assurance

   that TLS will be used end-to-end.



   The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at

   a minimum by implementers when TLS is used in a SIP application.  For

   purposes of backwards compatibility, proxy servers, redirect servers,

   and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA.

   Implementers MAY also support any other ciphersuite.



26.2.2 SIPS URI Scheme



   The SIPS URI scheme adheres to the syntax of the SIP URI (described

   in 19), although the scheme string is "sips" rather than "sip".  The

   semantics of SIPS are very different from the SIP URI, however.  SIPS

   allows resources to specify that they should be reached securely.



   A SIPS URI can be used as an address-of-record for a particular user

   - the URI by which the user is canonically known (on their business

   cards, in the From header field of their requests, in the To header

   field of REGISTER requests).  When used as the Request-URI of a

   request, the SIPS scheme signifies that each hop over which the

   request is forwarded, until the request reaches the SIP entity

   responsible for the domain portion of the Request-URI, must be

   secured with TLS; once it reaches the domain in question it is

   handled in accordance with local security and routing policy, quite

   possibly using TLS for any last hop to a UAS.  When used by the

   originator of a request (as would be the case if they employed a SIPS

   URI as the address-of-record of the target), SIPS dictates that the

   entire request path to the target domain be so secured.



   The SIPS scheme is applicable to many of the other ways in which SIP

   URIs are used in SIP today in addition to the Request-URI, including

   in addresses-of-record, contact addresses (the contents of Contact

   headers, including those of REGISTER methods), and Route headers.  In

   each instance, the SIPS URI scheme allows these existing fields to









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   designate secure resources.  The manner in which a SIPS URI is

   dereferenced in any of these contexts has its own security properties

   which are detailed in [4].



   The use of SIPS in particular entails that mutual TLS authentication

   SHOULD be employed, as SHOULD the ciphersuite

   TLS_RSA_WITH_AES_128_CBC_SHA.  Certificates received in the

   authentication process SHOULD be validated with root certificates

   held by the client; failure to validate a certificate SHOULD result

   in the failure of the request.



      Note that in the SIPS URI scheme, transport is independent of TLS,

      and thus "sips:alice@atlanta.com;transport=tcp" and

      "sips:alice@atlanta.com;transport=sctp" are both valid (although

      note that UDP is not a valid transport for SIPS).  The use of

      "transport=tls" has consequently been deprecated, partly because

      it was specific to a single hop of the request.  This is a change

      since RFC 2543.



   Users that distribute a SIPS URI as an address-of-record may elect to

   operate devices that refuse requests over insecure transports.



26.2.3 HTTP Authentication



   SIP provides a challenge capability, based on HTTP authentication,

   that relies on the 401 and 407 response codes as well as header

   fields for carrying challenges and credentials.  Without significant

   modification, the reuse of the HTTP Digest authentication scheme in

   SIP allows for replay protection and one-way authentication.



   The usage of Digest authentication in SIP is detailed in Section 22.



26.2.4 S/MIME



   As is discussed above, encrypting entire SIP messages end-to-end for

   the purpose of confidentiality is not appropriate because network

   intermediaries (like proxy servers) need to view certain header

   fields in order to route messages correctly, and if these

   intermediaries are excluded from security associations, then SIP

   messages will essentially be non-routable.



   However, S/MIME allows SIP UAs to encrypt MIME bodies within SIP,

   securing these bodies end-to-end without affecting message headers.

   S/MIME can provide end-to-end confidentiality and integrity for

   message bodies, as well as mutual authentication.  It is also

   possible to use S/MIME to provide a form of integrity and

   confidentiality for SIP header fields through SIP message tunneling.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The usage of S/MIME in SIP is detailed in Section 23.



26.3 Implementing Security Mechanisms



26.3.1 Requirements for Implementers of SIP



   Proxy servers, redirect servers, and registrars MUST implement TLS,

   and MUST support both mutual and one-way authentication.  It is

   strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also

   be capable of acting as a TLS server.  Proxy servers, redirect

   servers, and registrars SHOULD possess a site certificate whose

   subject corresponds to their canonical hostname.  UAs MAY have

   certificates of their own for mutual authentication with TLS, but no

   provisions are set forth in this document for their use.  All SIP

   elements that support TLS MUST have a mechanism for validating

   certificates received during TLS negotiation; this entails possession

   of one or more root certificates issued by certificate authorities

   (preferably well-known distributors of site certificates comparable

   to those that issue root certificates for web browsers).



   All SIP elements that support TLS MUST also support the SIPS URI

   scheme.



   Proxy servers, redirect servers, registrars, and UAs MAY also

   implement IPSec or other lower-layer security protocols.



   When a UA attempts to contact a proxy server, redirect server, or

   registrar, the UAC SHOULD initiate a TLS connection over which it

   will send SIP messages.  In some architectures, UASs MAY receive

   requests over such TLS connections as well.



   Proxy servers, redirect servers, registrars, and UAs MUST implement

   Digest Authorization, encompassing all of the aspects required in 22.

   Proxy servers, redirect servers, and registrars SHOULD be configured

   with at least one Digest realm, and at least one "realm" string

   supported by a given server SHOULD correspond to the server's

   hostname or domainname.



   UAs MAY support the signing and encrypting of MIME bodies, and

   transference of credentials with S/MIME as described in Section 23.

   If a UA holds one or more root certificates of certificate

   authorities in order to validate certificates for TLS or IPSec, it

   SHOULD be capable of reusing these to verify S/MIME certificates, as

   appropriate.  A UA MAY hold root certificates specifically for

   validating S/MIME certificates.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      Note that is it anticipated that future security extensions may

      upgrade the normative strength associated with S/MIME as S/MIME

      implementations appear and the problem space becomes better

      understood.



26.3.2 Security Solutions



   The operation of these security mechanisms in concert can follow the

   existing web and email security models to some degree.  At a high

   level, UAs authenticate themselves to servers (proxy servers,

   redirect servers, and registrars) with a Digest username and

   password; servers authenticate themselves to UAs one hop away, or to

   another server one hop away (and vice versa), with a site certificate

   delivered by TLS.



   On a peer-to-peer level, UAs trust the network to authenticate one

   another ordinarily; however, S/MIME can also be used to provide

   direct authentication when the network does not, or if the network

   itself is not trusted.



   The following is an illustrative example in which these security

   mechanisms are used by various UAs and servers to prevent the sorts

   of threats described in Section 26.1.  While implementers and network

   administrators MAY follow the normative guidelines given in the

   remainder of this section, these are provided only as example

   implementations.



26.3.2.1 Registration



   When a UA comes online and registers with its local administrative

   domain, it SHOULD establish a TLS connection with its registrar

   (Section 10 describes how the UA reaches its registrar).  The

   registrar SHOULD offer a certificate to the UA, and the site

   identified by the certificate MUST correspond with the domain in

   which the UA intends to register; for example, if the UA intends to

   register the address-of-record 'alice@atlanta.com', the site

   certificate must identify a host within the atlanta.com domain (such

   as sip.atlanta.com).  When it receives the TLS Certificate message,

   the UA SHOULD verify the certificate and inspect the site identified

   by the certificate.  If the certificate is invalid, revoked, or if it

   does not identify the appropriate party, the UA MUST NOT send the

   REGISTER message and otherwise proceed with the registration.



      When a valid certificate has been provided by the registrar, the

      UA knows that the registrar is not an attacker who might redirect

      the UA, steal passwords, or attempt any similar attacks.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The UA then creates a REGISTER request that SHOULD be addressed to a

   Request-URI corresponding to the site certificate received from the

   registrar.  When the UA sends the REGISTER request over the existing

   TLS connection, the registrar SHOULD challenge the request with a 401

   (Proxy Authentication Required) response.  The "realm" parameter

   within the Proxy-Authenticate header field of the response SHOULD

   correspond to the domain previously given by the site certificate.

   When the UAC receives the challenge, it SHOULD either prompt the user

   for credentials or take an appropriate credential from a keyring

   corresponding to the "realm" parameter in the challenge.  The

   username of this credential SHOULD correspond with the "userinfo"

   portion of the URI in the To header field of the REGISTER request.

   Once the Digest credentials have been inserted into an appropriate

   Proxy-Authorization header field, the REGISTER should be resubmitted

   to the registrar.



      Since the registrar requires the user agent to authenticate

      itself, it would be difficult for an attacker to forge REGISTER

      requests for the user's address-of-record.  Also note that since

      the REGISTER is sent over a confidential TLS connection, attackers

      will not be able to intercept the REGISTER to record credentials

      for any possible replay attack.



   Once the registration has been accepted by the registrar, the UA

   SHOULD leave this TLS connection open provided that the registrar

   also acts as the proxy server to which requests are sent for users in

   this administrative domain.  The existing TLS connection will be

   reused to deliver incoming requests to the UA that has just completed

   registration.



      Because the UA has already authenticated the server on the other

      side of the TLS connection, all requests that come over this

      connection are known to have passed through the proxy server -

      attackers cannot create spoofed requests that appear to have been

      sent through that proxy server.



26.3.2.2 Interdomain Requests



   Now let's say that Alice's UA would like to initiate a session with a

   user in a remote administrative domain, namely "bob@biloxi.com".  We

   will also say that the local administrative domain (atlanta.com) has

   a local outbound proxy.



   The proxy server that handles inbound requests for an administrative

   domain MAY also act as a local outbound proxy; for simplicity's sake

   we'll assume this to be the case for atlanta.com (otherwise the user

   agent would initiate a new TLS connection to a separate server at

   this point).  Assuming that the client has completed the registration







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   process described in the preceding section, it SHOULD reuse the TLS

   connection to the local proxy server when it sends an INVITE request

   to another user.  The UA SHOULD reuse cached credentials in the

   INVITE to avoid prompting the user unnecessarily.



   When the local outbound proxy server has validated the credentials

   presented by the UA in the INVITE, it SHOULD inspect the Request-URI

   to determine how the message should be routed (see [4]).  If the

   "domainname" portion of the Request-URI had corresponded to the local

   domain (atlanta.com) rather than biloxi.com, then the proxy server

   would have consulted its location service to determine how best to

   reach the requested user.



      Had "alice@atlanta.com" been attempting to contact, say,

      "alex@atlanta.com", the local proxy would have proxied to the

      request to the TLS connection Alex had established with the

      registrar when he registered.  Since Alex would receive this

      request over his authenticated channel, he would be assured that

      Alice's request had been authorized by the proxy server of the

      local administrative domain.



   However, in this instance the Request-URI designates a remote domain.

   The local outbound proxy server at atlanta.com SHOULD therefore

   establish a TLS connection with the remote proxy server at

   biloxi.com.  Since both of the participants in this TLS connection

   are servers that possess site certificates, mutual TLS authentication

   SHOULD occur.  Each side of the connection SHOULD verify and inspect

   the certificate of the other, noting the domain name that appears in

   the certificate for comparison with the header fields of SIP

   messages.  The atlanta.com proxy server, for example, SHOULD verify

   at this stage that the certificate received from the remote side

   corresponds with the biloxi.com domain.  Once it has done so, and TLS

   negotiation has completed, resulting in a secure channel between the

   two proxies, the atlanta.com proxy can forward the INVITE request to

   biloxi.com.



   The proxy server at biloxi.com SHOULD inspect the certificate of the

   proxy server at atlanta.com in turn and compare the domain asserted

   by the certificate with the "domainname" portion of the From header

   field in the INVITE request.  The biloxi proxy MAY have a strict

   security policy that requires it to reject requests that do not match

   the administrative domain from which they have been proxied.



      Such security policies could be instituted to prevent the SIP

      equivalent of SMTP 'open relays' that are frequently exploited to

      generate spam.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   This policy, however, only guarantees that the request came from the

   domain it ascribes to itself; it does not allow biloxi.com to

   ascertain how atlanta.com authenticated Alice.  Only if biloxi.com

   has some other way of knowing atlanta.com's authentication policies

   could it possibly ascertain how Alice proved her identity.

   biloxi.com might then institute an even stricter policy that forbids

   requests that come from domains that are not known administratively

   to share a common authentication policy with biloxi.com.



   Once the INVITE has been approved by the biloxi proxy, the proxy

   server SHOULD identify the existing TLS channel, if any, associated

   with the user targeted by this request (in this case

   "bob@biloxi.com").  The INVITE should be proxied through this channel

   to Bob.  Since the request is received over a TLS connection that had

   previously been authenticated as the biloxi proxy, Bob knows that the

   From header field was not tampered with and that atlanta.com has

   validated Alice, although not necessarily whether or not to trust

   Alice's identity.



   Before they forward the request, both proxy servers SHOULD add a

   Record-Route header field to the request so that all future requests

   in this dialog will pass through the proxy servers.  The proxy

   servers can thereby continue to provide security services for the

   lifetime of this dialog.  If the proxy servers do not add themselves

   to the Record-Route, future messages will pass directly end-to-end

   between Alice and Bob without any security services (unless the two

   parties agree on some independent end-to-end security such as

   S/MIME).  In this respect the SIP trapezoid model can provide a nice

   structure where conventions of agreement between the site proxies can

   provide a reasonably secure channel between Alice and Bob.



      An attacker preying on this architecture would, for example, be

      unable to forge a BYE request and insert it into the signaling

      stream between Bob and Alice because the attacker has no way of

      ascertaining the parameters of the session and also because the

      integrity mechanism transitively protects the traffic between

      Alice and Bob.



26.3.2.3 Peer-to-Peer Requests



   Alternatively, consider a UA asserting the identity

   "carol@chicago.com" that has no local outbound proxy.  When Carol

   wishes to send an INVITE to "bob@biloxi.com", her UA SHOULD initiate

   a TLS connection with the biloxi proxy directly (using the mechanism

   described in [4] to determine how to best to reach the given

   Request-URI).  When her UA receives a certificate from the biloxi

   proxy, it SHOULD be verified normally before she passes her INVITE

   across the TLS connection.  However, Carol has no means of proving







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   her identity to the biloxi proxy, but she does have a CMS-detached

   signature over a "message/sip" body in the INVITE.  It is unlikely in

   this instance that Carol would have any credentials in the biloxi.com

   realm, since she has no formal association with biloxi.com.  The

   biloxi proxy MAY also have a strict policy that precludes it from

   even bothering to challenge requests that do not have biloxi.com in

   the "domainname" portion of the From header field - it treats these

   users as unauthenticated.



   The biloxi proxy has a policy for Bob that all non-authenticated

   requests should be redirected to the appropriate contact address

   registered against 'bob@biloxi.com', namely <sip:bob@192.0.2.4>.

   Carol receives the redirection response over the TLS connection she

   established with the biloxi proxy, so she trusts the veracity of the

   contact address.



   Carol SHOULD then establish a TCP connection with the designated

   address and send a new INVITE with a Request-URI containing the

   received contact address (recomputing the signature in the body as

   the request is readied).  Bob receives this INVITE on an insecure

   interface, but his UA inspects and, in this instance, recognizes the

   From header field of the request and subsequently matches a locally

   cached certificate with the one presented in the signature of the

   body of the INVITE.  He replies in similar fashion, authenticating

   himself to Carol, and a secure dialog begins.



      Sometimes firewalls or NATs in an administrative domain could

      preclude the establishment of a direct TCP connection to a UA.  In

      these cases, proxy servers could also potentially relay requests

      to UAs in a way that has no trust implications (for example,

      forgoing an existing TLS connection and forwarding the request

      over cleartext TCP) as local policy dictates.



26.3.2.4 DoS Protection



   In order to minimize the risk of a denial-of-service attack against

   architectures using these security solutions, implementers should

   take note of the following guidelines.



   When the host on which a SIP proxy server is operating is routable

   from the public Internet, it SHOULD be deployed in an administrative

   domain with defensive operational policies (blocking source-routed

   traffic, preferably filtering ping traffic).  Both TLS and IPSec can

   also make use of bastion hosts at the edges of administrative domains

   that participate in the security associations to aggregate secure

   tunnels and sockets.  These bastion hosts can also take the brunt of

   denial-of-service attacks, ensuring that SIP hosts within the

   administrative domain are not encumbered with superfluous messaging.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   No matter what security solutions are deployed, floods of messages

   directed at proxy servers can lock up proxy server resources and

   prevent desirable traffic from reaching its destination.  There is a

   computational expense associated with processing a SIP transaction at

   a proxy server, and that expense is greater for stateful proxy

   servers than it is for stateless proxy servers.  Therefore, stateful

   proxies are more susceptible to flooding than stateless proxy

   servers.



   UAs and proxy servers SHOULD challenge questionable requests with

   only a single 401 (Unauthorized) or 407 (Proxy Authentication

   Required), forgoing the normal response retransmission algorithm, and

   thus behaving statelessly towards unauthenticated requests.



      Retransmitting the 401 (Unauthorized) or 407 (Proxy Authentication

      Required) status response amplifies the problem of an attacker

      using a falsified header field value (such as Via) to direct

      traffic to a third party.



   In summary, the mutual authentication of proxy servers through

   mechanisms such as TLS significantly reduces the potential for rogue

   intermediaries to introduce falsified requests or responses that can

   deny service.  This commensurately makes it harder for attackers to

   make innocent SIP nodes into agents of amplification.



26.4 Limitations



   Although these security mechanisms, when applied in a judicious

   manner, can thwart many threats, there are limitations in the scope

   of the mechanisms that must be understood by implementers and network

   operators.



26.4.1 HTTP Digest



   One of the primary limitations of using HTTP Digest in SIP is that

   the integrity mechanisms in Digest do not work very well for SIP.

   Specifically, they offer protection of the Request-URI and the method

   of a message, but not for any of the header fields that UAs would

   most likely wish to secure.



   The existing replay protection mechanisms described in RFC 2617 also

   have some limitations for SIP.  The next-nonce mechanism, for

   example, does not support pipelined requests.  The nonce-count

   mechanism should be used for replay protection.



   Another limitation of HTTP Digest is the scope of realms.  Digest is

   valuable when a user wants to authenticate themselves to a resource

   with which they have a pre-existing association, like a service







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   provider of which the user is a customer (which is quite a common

   scenario and thus Digest provides an extremely useful function).  By

   way of contrast, the scope of TLS is interdomain or multirealm, since

   certificates are often globally verifiable, so that the UA can

   authenticate the server with no pre-existing association.



26.4.2 S/MIME



   The largest outstanding defect with the S/MIME mechanism is the lack

   of a prevalent public key infrastructure for end users.  If self-

   signed certificates (or certificates that cannot be verified by one

   of the participants in a dialog) are used, the SIP-based key exchange

   mechanism described in Section 23.2 is susceptible to a man-in-the-

   middle attack with which an attacker can potentially inspect and

   modify S/MIME bodies.  The attacker needs to intercept the first

   exchange of keys between the two parties in a dialog, remove the

   existing CMS-detached signatures from the request and response, and

   insert a different CMS-detached signature containing a certificate

   supplied by the attacker (but which seems to be a certificate for the

   proper address-of-record).  Each party will think they have exchanged

   keys with the other, when in fact each has the public key of the

   attacker.



   It is important to note that the attacker can only leverage this

   vulnerability on the first exchange of keys between two parties - on

   subsequent occasions, the alteration of the key would be noticeable

   to the UAs.  It would also be difficult for the attacker to remain in

   the path of all future dialogs between the two parties over time (as

   potentially days, weeks, or years pass).



   SSH is susceptible to the same man-in-the-middle attack on the first

   exchange of keys; however, it is widely acknowledged that while SSH

   is not perfect, it does improve the security of connections.  The use

   of key fingerprints could provide some assistance to SIP, just as it

   does for SSH.  For example, if two parties use SIP to establish a

   voice communications session, each could read off the fingerprint of

   the key they received from the other, which could be compared against

   the original.  It would certainly be more difficult for the man-in-

   the-middle to emulate the voices of the participants than their

   signaling (a practice that was used with the Clipper chip-based

   secure telephone).



   The S/MIME mechanism allows UAs to send encrypted requests without

   preamble if they possess a certificate for the destination address-

   of-record on their keyring.  However, it is possible that any

   particular device registered for an address-of-record will not hold

   the certificate that has been previously employed by the device's

   current user, and that it will therefore be unable to process an







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   encrypted request properly, which could lead to some avoidable error

   signaling.  This is especially likely when an encrypted request is

   forked.



   The keys associated with S/MIME are most useful when associated with

   a particular user (an address-of-record) rather than a device (a UA).

   When users move between devices, it may be difficult to transport

   private keys securely between UAs; how such keys might be acquired by

   a device is outside the scope of this document.



   Another, more prosaic difficulty with the S/MIME mechanism is that it

   can result in very large messages, especially when the SIP tunneling

   mechanism described in Section 23.4 is used.  For that reason, it is

   RECOMMENDED that TCP should be used as a transport protocol when

   S/MIME tunneling is employed.



26.4.3 TLS



   The most commonly voiced concern about TLS is that it cannot run over

   UDP; TLS requires a connection-oriented underlying transport

   protocol, which for the purposes of this document means TCP.



   It may also be arduous for a local outbound proxy server and/or

   registrar to maintain many simultaneous long-lived TLS connections

   with numerous UAs.  This introduces some valid scalability concerns,

   especially for intensive ciphersuites.  Maintaining redundancy of

   long-lived TLS connections, especially when a UA is solely

   responsible for their establishment, could also be cumbersome.



   TLS only allows SIP entities to authenticate servers to which they

   are adjacent; TLS offers strictly hop-by-hop security.  Neither TLS,

   nor any other mechanism specified in this document, allows clients to

   authenticate proxy servers to whom they cannot form a direct TCP

   connection.



26.4.4 SIPS URIs



   Actually using TLS on every segment of a request path entails that

   the terminating UAS must be reachable over TLS (perhaps registering

   with a SIPS URI as a contact address).  This is the preferred use of

   SIPS.  Many valid architectures, however, use TLS to secure part of

   the request path, but rely on some other mechanism for the final hop

   to a UAS, for example.  Thus SIPS cannot guarantee that TLS usage

   will be truly end-to-end.  Note that since many UAs will not accept

   incoming TLS connections, even those UAs that do support TLS may be

   required to maintain persistent TLS connections as described in the

   TLS limitations section above in order to receive requests over TLS

   as a UAS.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Location services are not required to provide a SIPS binding for a

   SIPS Request-URI.  Although location services are commonly populated

   by user registrations (as described in Section 10.2.1), various other

   protocols and interfaces could conceivably supply contact addresses

   for an AOR, and these tools are free to map SIPS URIs to SIP URIs as

   appropriate.  When queried for bindings, a location service returns

   its contact addresses without regard for whether it received a

   request with a SIPS Request-URI.  If a redirect server is accessing

   the location service, it is up to the entity that processes the

   Contact header field of a redirection to determine the propriety of

   the contact addresses.



   Ensuring that TLS will be used for all of the request segments up to

   the target domain is somewhat complex.  It is possible that

   cryptographically authenticated proxy servers along the way that are

   non-compliant or compromised may choose to disregard the forwarding

   rules associated with SIPS (and the general forwarding rules in

   Section 16.6).  Such malicious intermediaries could, for example,

   retarget a request from a SIPS URI to a SIP URI in an attempt to

   downgrade security.



   Alternatively, an intermediary might legitimately retarget a request

   from a SIP to a SIPS URI.  Recipients of a request whose Request-URI

   uses the SIPS URI scheme thus cannot assume on the basis of the

   Request-URI alone that SIPS was used for the entire request path

   (from the client onwards).



   To address these concerns, it is RECOMMENDED that recipients of a

   request whose Request-URI contains a SIP or SIPS URI inspect the To

   header field value to see if it contains a SIPS URI (though note that

   it does not constitute a breach of security if this URI has the same

   scheme but is not equivalent to the URI in the To header field).

   Although clients may choose to populate the Request-URI and To header

   field of a request differently, when SIPS is used this disparity

   could be interpreted as a possible security violation, and the

   request could consequently be rejected by its recipient.  Recipients

   MAY also inspect the Via header chain in order to double-check

   whether or not TLS was used for the entire request path until the

   local administrative domain was reached.  S/MIME may also be used by

   the originating UAC to help ensure that the original form of the To

   header field is carried end-to-end.



   If the UAS has reason to believe that the scheme of the Request-URI

   has been improperly modified in transit, the UA SHOULD notify its

   user of a potential security breach.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   As a further measure to prevent downgrade attacks, entities that

   accept only SIPS requests MAY also refuse connections on insecure

   ports.



   End users will undoubtedly discern the difference between SIPS and

   SIP URIs, and they may manually edit them in response to stimuli.

   This can either benefit or degrade security.  For example, if an

   attacker corrupts a DNS cache, inserting a fake record set that

   effectively removes all SIPS records for a proxy server, then any

   SIPS requests that traverse this proxy server may fail.  When a user,

   however, sees that repeated calls to a SIPS AOR are failing, they

   could on some devices manually convert the scheme from SIPS to SIP

   and retry.  Of course, there are some safeguards against this (if the

   destination UA is truly paranoid it could refuse all non-SIPS

   requests), but it is a limitation worth noting.  On the bright side,

   users might also divine that 'SIPS' would be valid even when they are

   presented only with a SIP URI.



26.5 Privacy



   SIP messages frequently contain sensitive information about their

   senders - not just what they have to say, but with whom they

   communicate, when they communicate and for how long, and from where

   they participate in sessions.  Many applications and their users

   require that this sort of private information be hidden from any

   parties that do not need to know it.



   Note that there are also less direct ways in which private

   information can be divulged.  If a user or service chooses to be

   reachable at an address that is guessable from the person's name and

   organizational affiliation (which describes most addresses-of-

   record), the traditional method of ensuring privacy by having an

   unlisted "phone number" is compromised.  A user location service can

   infringe on the privacy of the recipient of a session invitation by

   divulging their specific whereabouts to the caller; an implementation

   consequently SHOULD be able to restrict, on a per-user basis, what

   kind of location and availability information is given out to certain

   classes of callers.  This is a whole class of problem that is

   expected to be studied further in ongoing SIP work.



   In some cases, users may want to conceal personal information in

   header fields that convey identity.  This can apply not only to the

   From and related headers representing the originator of the request,

   but also the To - it may not be appropriate to convey to the final

   destination a speed-dialing nickname, or an unexpanded identifier for

   a group of targets, either of which would be removed from the

   Request-URI as the request is routed, but not changed in the To









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   header field if the two were initially identical.  Thus it MAY be

   desirable for privacy reasons to create a To header field that

   differs from the Request-URI.



27 IANA Considerations



   All method names, header field names, status codes, and option tags

   used in SIP applications are registered with IANA through

   instructions in an IANA Considerations section in an RFC.



   The specification instructs the IANA to create four new sub-

   registries under http://www.iana.org/assignments/sip-parameters:

   Option Tags, Warning Codes (warn-codes), Methods and Response Codes,

   added to the sub-registry of Header Fields that is already present

   there.



27.1 Option Tags



   This specification establishes the Option Tags sub-registry under

   http://www.iana.org/assignments/sip-parameters.



   Option tags are used in header fields such as Require, Supported,

   Proxy-Require, and Unsupported in support of SIP compatibility

   mechanisms for extensions (Section 19.2).  The option tag itself is a

   string that is associated with a particular SIP option (that is, an

   extension).  It identifies the option to SIP endpoints.



   Option tags are registered by the IANA when they are published in

   standards track RFCs.  The IANA Considerations section of the RFC

   must include the following information, which appears in the IANA

   registry along with the RFC number of the publication.



      o  Name of the option tag.  The name MAY be of any length, but

         SHOULD be no more than twenty characters long.  The name MUST

         consist of alphanum (Section 25) characters only.



      o  Descriptive text that describes the extension.



27.2 Warn-Codes



   This specification establishes the Warn-codes sub-registry under

   http://www.iana.org/assignments/sip-parameters and initiates its

   population with the warn-codes listed in Section 20.43.  Additional

   warn-codes are registered by RFC publication.















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   The descriptive text for the table of warn-codes is:



   Warning codes provide information supplemental to the status code in

   SIP response messages when the failure of the transaction results

   from a Session Description Protocol (SDP) (RFC 2327 [1]) problem.



   The "warn-code" consists of three digits.  A first digit of "3"

   indicates warnings specific to SIP.  Until a future specification

   describes uses of warn-codes other than 3xx, only 3xx warn-codes may

   be registered.



   Warnings 300 through 329 are reserved for indicating problems with

   keywords in the session description, 330 through 339 are warnings

   related to basic network services requested in the session

   description, 370 through 379 are warnings related to quantitative QoS

   parameters requested in the session description, and 390 through 399

   are miscellaneous warnings that do not fall into one of the above

   categories.



27.3 Header Field Names



   This obsoletes the IANA instructions about the header sub-registry

   under http://www.iana.org/assignments/sip-parameters.



   The following information needs to be provided in an RFC publication

   in order to register a new header field name:



      o  The RFC number in which the header is registered;



      o  the name of the header field being registered;



      o  a compact form version for that header field, if one is

         defined;



   Some common and widely used header fields MAY be assigned one-letter

   compact forms (Section 7.3.3).  Compact forms can only be assigned

   after SIP working group review, followed by RFC publication.



27.4 Method and Response Codes



   This specification establishes the Method and Response-Code sub-

   registries under http://www.iana.org/assignments/sip-parameters and

   initiates their population as follows.  The initial Methods table is:

















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





         INVITE                   [RFC3261]

         ACK                      [RFC3261]

         BYE                      [RFC3261]

         CANCEL                   [RFC3261]

         REGISTER                 [RFC3261]

         OPTIONS                  [RFC3261]

         INFO                     [RFC2976]



   The response code table is initially populated from Section 21, the

   portions labeled Informational, Success, Redirection, Client-Error,

   Server-Error, and Global-Failure.  The table has the following

   format:



      Type (e.g., Informational)

            Number    Default Reason Phrase         [RFC3261]



   The following information needs to be provided in an RFC publication

   in order to register a new response code or method:



      o  The RFC number in which the method or response code is

         registered;



      o  the number of the response code or name of the method being

         registered;



      o  the default reason phrase for that response code, if

         applicable;



27.5 The "message/sip" MIME type.



   This document registers the "message/sip" MIME media type in order to

   allow SIP messages to be tunneled as bodies within SIP, primarily for

   end-to-end security purposes.  This media type is defined by the

   following information:



      Media type name: message

      Media subtype name: sip

      Required parameters: none



      Optional parameters: version

         version: The SIP-Version number of the enclosed message (e.g.,

         "2.0").  If not present, the version defaults to "2.0".

      Encoding scheme: SIP messages consist of an 8-bit header

         optionally followed by a binary MIME data object.  As such, SIP

         messages must be treated as binary.  Under normal circumstances

         SIP messages are transported over binary-capable transports, no

         special encodings are needed.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





      Security considerations: see below

         Motivation and examples of this usage as a security mechanism

         in concert with S/MIME are given in 23.4.



27.6 New Content-Disposition Parameter Registrations



   This document also registers four new Content-Disposition header

   "disposition-types": alert, icon, session and render.  The authors

   request that these values be recorded in the IANA registry for

   Content-Dispositions.



   Descriptions of these "disposition-types", including motivation and

   examples, are given in Section 20.11.



   Short descriptions suitable for the IANA registry are:



      alert     the body is a custom ring tone to alert the user

      icon      the body is displayed as an icon to the user

      render    the body should be displayed to the user

      session   the body describes a communications session, for

                example, as RFC 2327 SDP body



28 Changes From RFC 2543



   This RFC revises RFC 2543.  It is mostly backwards compatible with

   RFC 2543.  The changes described here fix many errors discovered in

   RFC 2543 and provide information on scenarios not detailed in RFC

   2543.  The protocol has been presented in a more cleanly layered

   model here.



   We break the differences into functional behavior that is a

   substantial change from RFC 2543, which has impact on

   interoperability or correct operation in some cases, and functional

   behavior that is different from RFC 2543 but not a potential source

   of interoperability problems.  There have been countless

   clarifications as well, which are not documented here.



28.1 Major Functional Changes



   o  When a UAC wishes to terminate a call before it has been answered,

      it sends CANCEL.  If the original INVITE still returns a 2xx, the

      UAC then sends BYE.  BYE can only be sent on an existing call leg

      (now called a dialog in this RFC), whereas it could be sent at any

      time in RFC 2543.



   o  The SIP BNF was converted to be RFC 2234 compliant.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   o  SIP URL BNF was made more general, allowing a greater set of

      characters in the user part.  Furthermore, comparison rules were

      simplified to be primarily case-insensitive, and detailed handling

      of comparison in the presence of parameters was described.  The

      most substantial change is that a URI with a parameter with the

      default value does not match a URI without that parameter.



   o  Removed Via hiding.  It had serious trust issues, since it relied

      on the next hop to perform the obfuscation process.  Instead, Via

      hiding can be done as a local implementation choice in stateful

      proxies, and thus is no longer documented.



   o  In RFC 2543, CANCEL and INVITE transactions were intermingled.

      They are separated now.  When a user sends an INVITE and then a

      CANCEL, the INVITE transaction still terminates normally.  A UAS

      needs to respond to the original INVITE request with a 487

      response.



   o  Similarly, CANCEL and BYE transactions were intermingled; RFC 2543

      allowed the UAS not to send a response to INVITE when a BYE was

      received.  That is disallowed here.  The original INVITE needs a

      response.



   o  In RFC 2543, UAs needed to support only UDP.  In this RFC, UAs

      need to support both UDP and TCP.



   o  In RFC 2543, a forking proxy only passed up one challenge from

      downstream elements in the event of multiple challenges.  In this

      RFC, proxies are supposed to collect all challenges and place them

      into the forwarded response.



   o  In Digest credentials, the URI needs to be quoted; this is unclear

      from RFC 2617 and RFC 2069 which are both inconsistent on it.



   o  SDP processing has been split off into a separate specification

      [13], and more fully specified as a formal offer/answer exchange

      process that is effectively tunneled through SIP.  SDP is allowed

      in INVITE/200 or 200/ACK for baseline SIP implementations; RFC

      2543 alluded to the ability to use it in INVITE, 200, and ACK in a

      single transaction, but this was not well specified.  More complex

      SDP usages are allowed in extensions.





















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   o  Added full support for IPv6 in URIs and in the Via header field.

      Support for IPv6 in Via has required that its header field

      parameters allow the square bracket and colon characters.  These

      characters were previously not permitted.  In theory, this could

      cause interop problems with older implementations.  However, we

      have observed that most implementations accept any non-control

      ASCII character in these parameters.



   o  DNS SRV procedure is now documented in a separate specification

      [4].  This procedure uses both SRV and NAPTR resource records and

      no longer combines data from across SRV records as described in

      RFC 2543.



   o  Loop detection has been made optional, supplanted by a mandatory

      usage of Max-Forwards.  The loop detection procedure in RFC 2543

      had a serious bug which would report "spirals" as an error

      condition when it was not.  The optional loop detection procedure

      is more fully and correctly specified here.



   o  Usage of tags is now mandatory (they were optional in RFC 2543),

      as they are now the fundamental building blocks of dialog

      identification.



   o  Added the Supported header field, allowing for clients to indicate

      what extensions are supported to a server, which can apply those

      extensions to the response, and indicate their usage with a

      Require in the response.



   o  Extension parameters were missing from the BNF for several header

      fields, and they have been added.



   o  Handling of Route and Record-Route construction was very

      underspecified in RFC 2543, and also not the right approach.  It

      has been substantially reworked in this specification (and made

      vastly simpler), and this is arguably the largest change.

      Backwards compatibility is still provided for deployments that do

      not use "pre-loaded routes", where the initial request has a set

      of Route header field values obtained in some way outside of

      Record-Route.  In those situations, the new mechanism is not

      interoperable.



   o  In RFC 2543, lines in a message could be terminated with CR, LF,

      or CRLF.  This specification only allows CRLF.

















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   o  Usage of Route in CANCEL and ACK was not well defined in RFC 2543.

      It is now well specified; if a request had a Route header field,

      its CANCEL or ACK for a non-2xx response to the request need to

      carry the same Route header field values.  ACKs for 2xx responses

      use the Route values learned from the Record-Route of the 2xx

      responses.



   o  RFC 2543 allowed multiple requests in a single UDP packet.  This

      usage has been removed.



   o  Usage of absolute time in the Expires header field and parameter

      has been removed.  It caused interoperability problems in elements

      that were not time synchronized, a common occurrence.  Relative

      times are used instead.



   o  The branch parameter of the Via header field value is now

      mandatory for all elements to use.  It now plays the role of a

      unique transaction identifier.  This avoids the complex and bug-

      laden transaction identification rules from RFC 2543.  A magic

      cookie is used in the parameter value to determine if the previous

      hop has made the parameter globally unique, and comparison falls

      back to the old rules when it is not present.  Thus,

      interoperability is assured.



   o  In RFC 2543, closure of a TCP connection was made equivalent to a

      CANCEL.  This was nearly impossible to implement (and wrong) for

      TCP connections between proxies.  This has been eliminated, so

      that there is no coupling between TCP connection state and SIP

      processing.



   o  RFC 2543 was silent on whether a UA could initiate a new

      transaction to a peer while another was in progress.  That is now

      specified here.  It is allowed for non-INVITE requests, disallowed

      for INVITE.



   o  PGP was removed.  It was not sufficiently specified, and not

      compatible with the more complete PGP MIME.  It was replaced with

      S/MIME.



   o  Added the "sips" URI scheme for end-to-end TLS.  This scheme is

      not backwards compatible with RFC 2543.  Existing elements that

      receive a request with a SIPS URI scheme in the Request-URI will

      likely reject the request.  This is actually a feature; it ensures

      that a call to a SIPS URI is only delivered if all path hops can

      be secured.













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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   o  Additional security features were added with TLS, and these are

      described in a much larger and complete security considerations

      section.



   o  In RFC 2543, a proxy was not required to forward provisional

      responses from 101 to 199 upstream.  This was changed to MUST.

      This is important, since many subsequent features depend on

      delivery of all provisional responses from 101 to 199.



   o  Little was said about the 503 response code in RFC 2543.  It has

      since found substantial use in indicating failure or overload

      conditions in proxies.  This requires somewhat special treatment.

      Specifically, receipt of a 503 should trigger an attempt to

      contact the next element in the result of a DNS SRV lookup.  Also,

      503 response is only forwarded upstream by a proxy under certain

      conditions.



   o  RFC 2543 defined, but did no sufficiently specify, a mechanism for

      UA authentication of a server.  That has been removed.  Instead,

      the mutual authentication procedures of RFC 2617 are allowed.



   o  A UA cannot send a BYE for a call until it has received an ACK for

      the initial INVITE.  This was allowed in RFC 2543 but leads to a

      potential race condition.



   o  A UA or proxy cannot send CANCEL for a transaction until it gets a

      provisional response for the request.  This was allowed in RFC

      2543 but leads to potential race conditions.



   o  The action parameter in registrations has been deprecated.  It was

      insufficient for any useful services, and caused conflicts when

      application processing was applied in proxies.



   o  RFC 2543 had a number of special cases for multicast.  For

      example, certain responses were suppressed, timers were adjusted,

      and so on.  Multicast now plays a more limited role, and the

      protocol operation is unaffected by usage of multicast as opposed

      to unicast.  The limitations as a result of that are documented.



   o  Basic authentication has been removed entirely and its usage

      forbidden.





















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   o  Proxies no longer forward a 6xx immediately on receiving it.

      Instead, they CANCEL pending branches immediately.  This avoids a

      potential race condition that would result in a UAC getting a 6xx

      followed by a 2xx.  In all cases except this race condition, the

      result will be the same - the 6xx is forwarded upstream.



   o  RFC 2543 did not address the problem of request merging.  This

      occurs when a request forks at a proxy and later rejoins at an

      element.  Handling of merging is done only at a UA, and procedures

      are defined for rejecting all but the first request.



28.2 Minor Functional Changes



   o  Added the Alert-Info, Error-Info, and Call-Info header fields for

      optional content presentation to users.



   o  Added the Content-Language, Content-Disposition and MIME-Version

      header fields.



   o  Added a "glare handling" mechanism to deal with the case where

      both parties send each other a re-INVITE simultaneously.  It uses

      the new 491 (Request Pending) error code.



   o  Added the In-Reply-To and Reply-To header fields for supporting

      the return of missed calls or messages at a later time.



   o  Added TLS and SCTP as valid SIP transports.



   o  There were a variety of mechanisms described for handling failures

      at any time during a call; those are now generally unified.  BYE

      is sent to terminate.



   o  RFC 2543 mandated retransmission of INVITE responses over TCP, but

      noted it was really only needed for 2xx.  That was an artifact of

      insufficient protocol layering.  With a more coherent transaction

      layer defined here, that is no longer needed.  Only 2xx responses

      to INVITEs are retransmitted over TCP.



   o  Client and server transaction machines are now driven based on

      timeouts rather than retransmit counts.  This allows the state

      machines to be properly specified for TCP and UDP.



   o  The Date header field is used in REGISTER responses to provide a

      simple means for auto-configuration of dates in user agents.



   o  Allowed a registrar to reject registrations with expirations that

      are too short in duration.  Defined the 423 response code and the

      Min-Expires for this purpose.







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



RFC 3261            SIP: Session Initiation Protocol           June 2002





29 Normative References



   [1]  Handley, M. and V. Jacobson, "SDP: Session Description

        Protocol", RFC 2327, April 1998.



   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement

        Levels", BCP 14, RFC 2119, March 1997.



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



   [4]  Rosenberg, J. and H. Schulzrinne, "SIP: Locating SIP Servers",

        RFC 3263, June 2002.



   [5]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource

        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.



   [6]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for

        Transport Layer Security (TLS)", RFC 3268, June 2002.



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

        2279, January 1998.



   [8]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,

        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --

        HTTP/1.1", RFC 2616, June 1999.



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

        2000.



   [10] Crocker, D. and P. Overell, "Augmented BNF for Syntax

        Specifications: ABNF", RFC 2234, November 1997.



   [11] Freed, F. and N. Borenstein, "Multipurpose Internet Mail

        Extensions (MIME) Part Two: Media Types", RFC 2046, November

        1996.



   [12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness

        Recommendations for Security", RFC 1750, December 1994.



   [13] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with

        SDP", RFC 3264, June 2002.



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

        1980.



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

        761, January 1980.









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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   [16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,

        H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,

        "Stream Control Transmission Protocol", RFC 2960, October 2000.



   [17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,

        Leach, P., Luotonen, A. and L. Stewart, "HTTP authentication:

        Basic and Digest Access Authentication", RFC 2617, June 1999.



   [18] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation

        Information in Internet Messages: The Content-Disposition Header

        Field", RFC 2183, August 1997.



   [19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,

        Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG

        Objects", RFC 3204, December 2001.



   [20] Braden, R., "Requirements for Internet Hosts - Application and

        Support", STD 3, RFC 1123, October 1989.



   [21] Alvestrand, H., "IETF Policy on Character Sets and Languages",

        BCP 18, RFC 2277, January 1998.



   [22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security

        Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",

        RFC 1847, October 1995.



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

        1999.



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

        June 1999.



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

        2246, January 1999.



   [26] Kent, S. and R. Atkinson, "Security Architecture for the

        Internet Protocol", RFC 2401, November 1998.



30 Informative References



   [27] R. Pandya, "Emerging mobile and personal communication systems,"

        IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995.



   [28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,

        "RTP:  A Transport Protocol for Real-Time Applications", RFC

        1889, January 1996.











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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   [29] Schulzrinne, H., Rao, R. and R. Lanphier, "Real Time Streaming

        Protocol (RTSP)", RFC 2326, April 1998.



   [30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and

        J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November

        2000.



   [31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,

        "SIP: Session Initiation Protocol", RFC 2543, March 1999.



   [32] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL

        scheme", RFC 2368, July 1998.



   [33] E. M. Schooler, "A multicast user directory service for

        synchronous rendezvous," Master's Thesis CS-TR-96-18, Department

        of Computer Science, California Institute of Technology,

        Pasadena, California, Aug. 1996.



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



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

        1992.



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

        2426, September 1998.



   [37] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical

        Specification", RFC 2849, June 2000.



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

        February 1997.



   [39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,

        Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:

        Digest Access Authentication", RFC 2069, January 1997.



   [40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis,

        D., Rosenberg, J., Summers, K. and H. Schulzrinne, "SIP Call

        Flow Examples", Work in Progress.



   [41] E. M. Schooler, "Case study: multimedia conference control in a

        packet-switched teleconferencing system," Journal of

        Internetworking:  Research and Experience, Vol. 4, pp. 99--120,

        June 1993.  ISI reprint series ISI/RS-93-359.















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   [42] H. Schulzrinne, "Personal mobility for multimedia services in

        the Internet," in European Workshop on Interactive Distributed

        Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar.

        1996.



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

        2000.

























































































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



RFC 3261            SIP: Session Initiation Protocol           June 2002





A Table of Timer Values



   Table 4 summarizes the meaning and defaults of the various timers

   used by this specification.



Timer    Value            Section               Meaning

----------------------------------------------------------------------

T1       500ms default    Section 17.1.1.1     RTT Estimate

T2       4s               Section 17.1.2.2     The maximum retransmit

                                               interval for non-INVITE

                                               requests and INVITE

                                               responses

T4       5s               Section 17.1.2.2     Maximum duration a

                                               message will

                                               remain in the network

Timer A  initially T1     Section 17.1.1.2     INVITE request retransmit

                                               interval, for UDP only

Timer B  64*T1            Section 17.1.1.2     INVITE transaction

                                               timeout timer

Timer C  > 3min           Section 16.6         proxy INVITE transaction

                           bullet 11            timeout

Timer D  > 32s for UDP    Section 17.1.1.2     Wait time for response

         0s for TCP/SCTP                       retransmits

Timer E  initially T1     Section 17.1.2.2     non-INVITE request

                                               retransmit interval,

                                               UDP only

Timer F  64*T1            Section 17.1.2.2     non-INVITE transaction

                                               timeout timer

Timer G  initially T1     Section 17.2.1       INVITE response

                                               retransmit interval

Timer H  64*T1            Section 17.2.1       Wait time for

                                               ACK receipt

Timer I  T4 for UDP       Section 17.2.1       Wait time for

         0s for TCP/SCTP                       ACK retransmits

Timer J  64*T1 for UDP    Section 17.2.2       Wait time for

         0s for TCP/SCTP                       non-INVITE request

                                               retransmits

Timer K  T4 for UDP       Section 17.1.2.2     Wait time for

         0s for TCP/SCTP                       response retransmits



                   Table 4: Summary of timers





















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





Acknowledgments



   We wish to thank the members of the IETF MMUSIC and SIP WGs for their

   comments and suggestions.  Detailed comments were provided by Ofir

   Arkin, Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan,

   Keith Drage, Bill Fenner, Cedric Fluckiger, Yaron Goland, John

   Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema,

   Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders

   Kristensen, Jonathan Lennox, Gethin Liddell, Allison Mankin, William

   Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe

   J. Sambol, Chip Sharp, Igor Slepchin, Eric Tremblay, and Rick

   Workman.



   Brian Rosen provided the compiled BNF.



   Jean Mahoney provided technical writing assistance.



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



































































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



RFC 3261            SIP: Session Initiation Protocol           June 2002





Authors' Addresses



   Authors addresses are listed alphabetically for the editors, the

   writers, and then the original authors of RFC 2543.  All listed

   authors actively contributed large amounts of text to this document.



   Jonathan Rosenberg

   dynamicsoft

   72 Eagle Rock Ave

   East Hanover, NJ 07936

   USA



   EMail:  jdrosen@dynamicsoft.com





   Henning Schulzrinne

   Dept. of Computer Science

   Columbia University

   1214 Amsterdam Avenue

   New York, NY 10027

   USA



   EMail:  schulzrinne@cs.columbia.edu





   Gonzalo Camarillo

   Ericsson

   Advanced Signalling Research Lab.

   FIN-02420 Jorvas

   Finland



   EMail:  Gonzalo.Camarillo@ericsson.com





   Alan Johnston

   WorldCom

   100 South 4th Street

   St. Louis, MO 63102

   USA



   EMail:  alan.johnston@wcom.com





















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



RFC 3261            SIP: Session Initiation Protocol           June 2002





   Jon Peterson

   NeuStar, Inc

   1800 Sutter Street, Suite 570

   Concord, CA 94520

   USA



   EMail:  jon.peterson@neustar.com





   Robert Sparks

   dynamicsoft, Inc.

   5100 Tennyson Parkway

   Suite 1200

   Plano, Texas 75024

   USA



   EMail:  rsparks@dynamicsoft.com





   Mark Handley

   International Computer Science Institute

   1947 Center St, Suite 600

   Berkeley, CA 94704

   USA



   EMail:  mjh@icir.org





   Eve Schooler

   AT&T Labs-Research

   75 Willow Road

   Menlo Park, CA 94025

   USA



   EMail: schooler@research.att.com

































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



RFC 3261            SIP: Session Initiation Protocol           June 2002





Full Copyright Statement



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



   This document and translations of it may be copied and furnished to

   others, and derivative works that comment on or otherwise explain it

   or assist in its implementation may be prepared, copied, published

   and distributed, in whole or in part, without restriction of any

   kind, provided that the above copyright notice and this paragraph are

   included on all such copies and derivative works.  However, this

   document itself may not be modified in any way, such as by removing

   the copyright notice or references to the Internet Society or other

   Internet organizations, except as needed for the purpose of

   developing Internet standards in which case the procedures for

   copyrights defined in the Internet Standards process must be

   followed, or as required to translate it into languages other than

   English.



   The limited permissions granted above are perpetual and will not be

   revoked by the Internet Society or its successors or assigns.



   This document and the information contained herein is provided on an

   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Acknowledgement



   Funding for the RFC Editor function is currently provided by the

   Internet Society.







































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



