Internet Engineering Task Force  SIP WG
INTERNET-DRAFT  J. Rosenberg,H. Schulzrinne,G. Camarillo,A. Johnston,J. Peterson,R. Sparks,M. Handley,E. Schooler
draft-ietf-sip-rfc2543bis-07.9.ps  dynamicsoft,Columbia U.,Ericsson,Worldcom,Neustar,dynamicsoft,ACIRI,AT&T

February 20, 2002 Expires: Aug 2002

1

2 SIP: Session Initiation Protocol

3 Status of this Memo

4 This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 5 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its 6 working groups. Note that other groups may also distribute working documents as Internet-Drafts. 7 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, 8 or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material 9 or to cite them other than as “work in progress.” 10 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt 11 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html.

12 Copyright Notice

13 Copyright (c) The Internet Society (2002). All Rights Reserved.

Abstract

14

15 The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, 16 modifying, and terminating sessions with one or more participants. These sessions include Internet 17 telephone calls, multimedia distribution, and multimedia conferences. 18 SIP invitations used to create sessions carry session descriptions that allow participants to agree on 19 a set of compatible media types. SIP makes use of elements called proxy servers to help route requests 20 to the user’s current location, authenticate and authorize users for services, implement provider call-21 routing policies, and provide features to users. SIP also provides a registration function that allows users 22 to upload their current locations for use by proxy servers. SIP runs on top of several different transport 23 protocols.

24 Contents

25 1 Introduction 8

26 2 Overview of SIP Functionality 8

27 3 Terminology 9

28 4 Overview of Operation 9

29 5 Structure of the Protocol 14

30 6 Definitions 16

INTERNET-DRAFT  draft-ietf-sip-rfc2543bis-07.9.ps  February 20, 2002

31 7 SIP Messages 20 32 7.1 Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 33 7.2 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 34 7.3 Header Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 35 7.3.1 Header Field Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 36 7.3.2 Header Field Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 37 7.3.3 Compact Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 38 7.4 Bodies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 39 7.4.1 Message Body Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 40 7.4.2 Message Body Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 41 7.5 Framing SIP messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

42 8 General User Agent Behavior 25 43 8.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 44 8.1.1 Generating the Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 45 8.1.2 Sending the Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 46 8.1.3 Processing Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 47 8.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 48 8.2.1 Method Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 49 8.2.2 Header Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 50 8.2.3 Content Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 51 8.2.4 Applying Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 52 8.2.5 Processing the Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 53 8.2.6 Generating the Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 54 8.2.7 Stateless UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 55 8.3 Redirect Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

56 9 Canceling a Request 37 57 9.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 58 9.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

59 10 Registrations 39 60 10.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 61 10.2 Constructing the REGISTER Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 62 10.2.1 Adding Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 63 10.2.2 Removing Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 64 10.2.3 Fetching Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 65 10.2.4 Refreshing Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 66 10.2.5 Setting the Internal Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 67 10.2.6 Discovering a Registrar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 68 10.2.7 Transmitting a Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 69 10.2.8 Error Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 70 10.3 Processing REGISTER Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

71 11 Querying for Capabilities 46 72 11.1 Construction of OPTIONS Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 73 11.2 Processing of OPTIONS Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

74 12 Dialogs 48 75 12.1 Creation of a Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 76 12.1.1 UAS behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 77 12.1.2 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 78 12.2 Requests within a Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 79 12.2.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 80 12.2.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 81 12.3 Termination of a Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

82 13 Initiating a Session 53 83 13.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 84 13.2 UAC Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 85 13.2.1 Creating the Initial INVITE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 86 13.2.2 Processing INVITE Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 87 13.3 UAS Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 88 13.3.1 Processing of the INVITE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

89 14 Modifying an Existing Session 59 90 14.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 91 14.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

92 15 Terminating a Session 61 93 15.1 Terminating a Session with a BYE Request . . . . . . . . . . . . . . . . . . . . . . . . . . 61 94 15.1.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 95 15.1.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

96 16 Proxy Behavior 62 97 16.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 98 16.2 Stateful Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 99 16.3 Request Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 100 16.4 Route Information Preprocessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 101 16.5 Determining request targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 102 16.6 Request Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 103 16.7 Response Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 104 16.8 Processing Timer C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 105 16.9 Handling Transport Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 106 16.10CANCEL Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 107 16.11Stateless Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 108 16.12Summary of Proxy Route Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 109 16.12.1Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

110 17 Transactions 84 111 17.1 Client Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 112 17.1.1 INVITE Client Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 113 17.1.2 Non-INVITE Client Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 114 17.1.3 Matching Responses to Client Transactions . . . . . . . . . . . . . . . . . . . . . . 91 115 17.1.4 Handling Transport Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 116 17.2 Server Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 117 17.2.1 INVITE Server Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 118 17.2.2 Non-INVITE Server Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 119 17.2.3 Matching Requests to Server Transactions . . . . . . . . . . . . . . . . . . . . . . . 95 120 17.2.4 Handling Transport Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

121 18 Transport 96 122 18.1 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 123 18.1.1 Sending Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 124 18.1.2 Receiving Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 125 18.2 Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 126 18.2.1 Receiving Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 127 18.2.2 Sending Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 128 18.3 Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 129 18.4 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

130 19 Common Message Components 100 131 19.1 SIP and SIPS Uniform Resource Indicators . . . . . . . . . . . . . . . . . . . . . . . . . . 100 132 19.1.1 SIP and SIPS URI Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 133 19.1.2 Character Escaping Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 134 19.1.3 Example SIP and SIPS URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 135 19.1.4 URI Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 136 19.1.5 Forming Requests from a URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 137 19.1.6 Relating SIP URIs and tel URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 138 19.2 Option Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 139 19.3 Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

140 20 Header Fields 109 141 20.1 Accept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 142 20.2 Accept-Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 143 20.3 Accept-Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 144 20.4 Alert-Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 145 20.5 Allow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 146 20.6 Authentication-Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 147 20.7 Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 148 20.8 Call-ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 149 20.9 Call-Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 150 20.10Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 151 20.11Content-Disposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 152 20.12Content-Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 153 20.13Content-Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 154 20.14Content-Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 155 20.15Content-Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 156 20.16CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 157 20.17Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 158 20.18Error-Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 159 20.19Expires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 160 20.20From . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 161 20.21In-Reply-To . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 162 20.22Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 163 20.23Min-Expires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 164 20.24MIME-Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 165 20.25Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 166 20.26Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 167 20.27Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 168 20.28Proxy-Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 169 20.29Proxy-Require . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 170 20.30Record-Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 171 20.31Reply-To . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 172 20.32Require . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 173 20.33Retry-After . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 174 20.34Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 175 20.35Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 176 20.36Subject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 177 20.37Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 178 20.38Timestamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 179 20.39To . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 180 20.40Unsupported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 181 20.41User-Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 182 20.42Via . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 183 20.43Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 184 20.44WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

185 21 Response Codes 126 186 21.1 Provisional 1xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 187 21.1.1 100 Trying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 188 21.1.2 180 Ringing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 189 21.1.3 181 Call Is Being Forwarded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 190 21.1.4 182 Queued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 191 21.1.5 183 Session Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 192 21.2 Successful 2xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 193 21.2.1 200 OK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 194 21.3 Redirection 3xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 195 21.3.1 300 Multiple Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 196 21.3.2 301 Moved Permanently . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 197 21.3.3 302 Moved Temporarily . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 198 21.3.4 305 Use Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 199 21.3.5 380 Alternative Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 200 21.4 Request Failure 4xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 201 21.4.1 400 Bad Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 202 21.4.2 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 203 21.4.3 402 Payment Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 204 21.4.4 403 Forbidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 205 21.4.5 404 Not Found . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 206 21.4.6 405 Method Not Allowed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 207 21.4.7 406 Not Acceptable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 208 21.4.8 407 Proxy Authentication Required . . . . . . . . . . . . . . . . . . . . . . . . . . 129 209 21.4.9 408 Request Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 210 21.4.10410 Gone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 211 21.4.11413 Request Entity Too Large . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 212 21.4.12414 Request-URI Too Long . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 213 21.4.13415 Unsupported Media Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 214 21.4.14416 Unsupported URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 215 21.4.15420 Bad Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 216 21.4.16421 Extension Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 217 21.4.17423 Interval Too Brief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 218 21.4.18480 Temporarily Unavailable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 219 21.4.19481 Call/Transaction Does Not Exist . . . . . . . . . . . . . . . . . . . . . . . . . . 131 220 21.4.20482 Loop Detected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 221 21.4.21483 Too Many Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 222 21.4.22484 Address Incomplete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 223 21.4.23485 Ambiguous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 224 21.4.24486 Busy Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 225 21.4.25487 Request Terminated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 226 21.4.26488 Not Acceptable Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 227 21.4.27491 Request Pending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 228 21.4.28493 Undecipherable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 229 21.5 Server Failure 5xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 230 21.5.1 500 Server Internal Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 231 21.5.2 501 Not Implemented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 232 21.5.3 502 Bad Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 233 21.5.4 503 Service Unavailable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 234 21.5.5 504 Server Time-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 235 21.5.6 505 Version Not Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 236 21.5.7 513 Message Too Large . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 237 21.6 Global Failures 6xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 238 21.6.1 600 Busy Everywhere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 239 21.6.2 603 Decline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 240 21.6.3 604 Does Not Exist Anywhere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 241 21.6.4 606 Not Acceptable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

242 22 Usage of HTTP Authentication 134 243 22.1 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 244 22.2 User-to-User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 245 22.3 Proxy-to-User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 246 22.4 The Digest Authentication Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

247 23 S/MIME 140 248 23.1 S/MIME Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 249 23.2 S/MIME Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 250 23.3 Securing MIME bodies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 251 23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP . . . . . . . . . . . . . . . 143 252 23.4.1 Integrity and Confidentiality Properties of SIP Headers . . . . . . . . . . . . . . . . 144 253 23.4.2 Tunneling Integrity and Authentication . . . . . . . . . . . . . . . . . . . . . . . . 145 254 23.4.3 Tunneling Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

255 24 Examples 148 256 24.1 Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 257 24.2 Session Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

258 25 Augmented BNF for the SIP Protocol 154 259 25.1 Basic Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

260 26 Security Considerations: Threat Model and Security Usage Recommendations 169 261 26.1 Attacks and Threat Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 262 26.1.1 Registration Hijacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 263 26.1.2 Impersonating a Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 264 26.1.3 Tampering with Message Bodies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 265 26.1.4 Tearing Down Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 266 26.1.5 Denial of Service and Amplification . . . . . . . . . . . . . . . . . . . . . . . . . . 172 267 26.2 Security Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 268 26.2.1 Transport and Network Layer Security . . . . . . . . . . . . . . . . . . . . . . . . . 173 269 26.2.2 SIPS URI scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 270 26.2.3 HTTP Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 271 26.2.4 S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 272 26.3 Implementing Security Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 273 26.3.1 Requirements for Implementers of SIP . . . . . . . . . . . . . . . . . . . . . . . . . 175 274 26.3.2 Security Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 275 26.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 276 26.4.1 HTTP Digest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 277 26.4.2 S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 278 26.4.3 TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 279 26.4.4 SIPS URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 280 26.5 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

281 27 IANA Considerations 181 282 27.1 Option Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 283 27.2 Warn-Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 284 27.3 Header Field Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 285 27.4 Method and Response Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 286 27.5 The “application/sip” MIME type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 287 28 Changes From RFC 2543 183 288 28.1 Major Functional Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 289 28.2 Minor Functional Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

290 29 Acknowledgments 187

291 30 Authors’ Addresses 187

292 A Table of Timer Values 191

293 1 Introduction

294 There are many applications of the Internet that require the creation and management of a session, where 295 a session is considered an exchange of data between an association of participants. The implementation of 296 these applications is complicated by the practices of participants: users may move between endpoints, they 297 may be addressable by multiple names, and they may communicate in several different media - sometimes 298 simultaneously. Numerous protocols have been authored that carry various forms of real-time multimedia 299 session data such as voice, video, or text messages. SIP works in concert with these protocols by enabling 300 Internet endpoints (called user agents) to discover one another and to agree on a characterization of a ses-301 sion they would like to share. For locating prospective session participants, and for other functions, SIP 302 enables creation of an infrastructure of network hosts (called proxy servers) to which user agents can send 303 registrations, invitations to sessions, and other requests. SIP is an agile, general-purpose tool for creating, 304 modifying, and terminating sessions that works independently of underlying transport protocols and without 305 dependency on the type of session that is being established.

306 2 Overview of SIP Functionality

307 SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions 308 (conferences) such as Internet telephony calls. SIP can also invite participants to already existing sessions, 309 such as multicast conferences. Media can be added to (and removed from) an existing session. SIP trans-310 parently supports name mapping and redirection services, which supports personal mobility [26] - users can 311 maintain a single externally visible identifier regardless of their network location. 312 SIP supports five facets of establishing and terminating multimedia communications:

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

314 User availability: determination of the willingness of the called party to engage in communications;

315 User capabilities: determination of the media and media parameters to be used;

316 Session setup: “ringing”, establishment of session parameters at both called and calling party;

317 Session management: including transfer and termination of sessions, modifying session parameters, and 318 invoking services.

319 SIP is not a vertically integrated communications system. SIP is rather a component that can be used with 320 other IETF protocols to build a complete multimedia architecture. Typically, these architectures will include 321 protocols such as the real-time transport protocol (RTP) (RFC 1889 [27]) for transporting real-time data and 322 providing QoS feedback, the real-time streaming protocol (RTSP) (RFC 2326 [28]) for controlling delivery 323 of streaming media, the Media Gateway Control Protocol (MEGACO) (RFC 3015 [29]) for controlling 324 gateways to the Public Switched Telephone Network (PSTN), and the session description protocol (SDP) 325 (RFC 2327 [1]) for describing multimedia sessions. Therefore, SIP should be used in conjunction with other 326 protocols in order to provide complete services to the users. However, the basic functionality and operation 327 of SIP does not depend on any of these protocols. 328 SIP does not provide services. SIP rather provides primitives that can be used to implement different 329 services. For example, SIP can locate a user and deliver an opaque object to his current location. If this 330 primitive is used to deliver a session description written in SDP, for instance, the endpoints can agree on the 331 parameters of a session. If the same primitive is used to deliver a photo of the caller as well as the session 332 description, a ”caller ID” service can be easily implemented. As this example shows, a single primitive is 333 typically used to provide several different services. 334 SIP does not offer conference control services such as floor control or voting and does not prescribe how 335 a conference is to be managed. SIP can be used to initiate a session that uses some other conference control 336 protocol. Since SIP messages and the sessions they establish can pass through entirely different networks, 337 SIP cannot, and does not, provide any kind of network resource reservation capabilities. 338 The nature of the services provided make security particularly important. To that end, SIP provides a 339 suite of security services, which include denial-of-service prevention, authentication (both user to user and 340 proxy to user), integrity protection, and encryption and privacy services. 341 SIP works with both IPv4 and IPv6.

342 3 Terminology

343 In this document, the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, 344 “should not”, “recommended”, “not recommended”, “may”, and “optional” are to be inter-345 preted as described in RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.

346 4 Overview of Operation

347 This section introduces the basic operations of SIP using simple examples. This section is tutorial in nature 348 and does not contain any normative statements. 349 The first example shows the basic functions of SIP: location of an end point, signal of a desire to com-350 municate, negotiation of session parameters to establish the session, and teardown of the session once es-351 tablished. 352 Figure 1 shows a typical example of a SIP message exchange between two users, Alice and Bob. (Each 353 message is labeled with the letter “F” and a number for reference by the text.) In this example, Alice uses a 354 SIP application on her PC (referred to as a softphone) to call Bob on his SIP phone over the Internet. Also 355 shown are two SIP proxy servers that act on behalf of Alice and Bob to facilitate the session establishment. 356 This typical arrangement is often referred to as the “SIP trapezoid” as shown by the geometric shape of the 357 dashed lines in Figure 1. 358 Alice “calls” Bob using his SIP identity, a type of Uniform Resource Identifier (URI) called a SIP 359 URI and which is defined in Section 19.1. It has a similar form to an email address, typically containing 360 a username and a host name. In this case, it is sip:bob@biloxi.com, where biloxi.com is the domain of

Figure 1: SIP session setup example with SIP trapezoid

361 Bob’s SIP service provider (which can be an enterprise, retail provider, etc). Alice also has a SIP URI 362 of sip:alice@atlanta.com. Alice might have typed in Bob’s URI or perhaps clicked on a hyperlink or 363 an entry in an address book. SIP also provides a secure URI, called a SIPS URI. An example would be 364 sips:bob@biloxi.com. A call made to a SIPS URI guarantees that secure, encrypted transport (namely TLS) 365 is used to carry all SIP messages at every hop between the caller and callee. 366 SIP is based on an HTTP-like request/response transaction model. Each transaction consists of a request 367 that invokes a particular method, or function, on the server and at least one response. In this example, the 368 transaction begins with Alice’s softphone sending an INVITE request addressed to Bob’s SIP URI. INVITE 369 is an example of a SIP method that specifies the action that the requestor (Alice) wants the server (Bob) 370 to take. The INVITE request contains a number of header fields. Header fields are named attributes that 371 provide additional information about a message. The ones present in an INVITE include a unique identifier 372 for the call, the destination address, Alice’s address, and information about the type of session that Alice 373 wishes to establish with Bob. The INVITE (message F1 in Figure 1) might look like this:

374  INVITE sip:bob@biloxi.com SIP/2.0
375  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
376  Max-Forwards: 70
377  To: Bob <sip:bob@biloxi.com>
378  From: Alice <sip:alice@atlanta.com>;tag=1928301774
379  Call-ID: a84b4c76e66710@pc33.atlanta.com
380  CSeq: 314159 INVITE
381  Contact: <sip:alice@pc33.atlanta.com>
382  Content-Type: application/sdp

383  Content-Length: 142

384

385  (Alice's SDP not shown)

386 The first line of the text-encoded message contains the method name (INVITE). The lines that follow 387 are a list of header fields. This example contains a minimum required set. The header fields are briefly 388 described below: 389 Via contains the address (pc33.atlanta.com) at which Alice is expecting to receive responses to this 390 request. It also contains a branch parameter that contains an identifier for this transaction. 391 To contains a display name (Bob) and a SIP or SIPS URI (sip:bob@biloxi.com) towards which the 392 request was originally directed. Display names are described in RFC 2822 [3]. 393 From also contains a display name (Alice) and a SIP or SIPS URI (sip:alice@atlanta.com) that indicate 394 the originator of the request. This header field also has a tag parameter containing a pseudorandom string 395 (1928301774) that was added to the URI by the softphone. It is used for identification purposes. 396 Call-ID contains a globally unique identifier for this call, generated by the combination of a pseudoran-397 dom string and the softphone’s IP address. The combination of the To tag, From tag, and Call-ID completely 398 define a peer-to-peer SIP relationship between Alice and Bob and is referred to as a dialog. 399 CSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented 400 for each new request within a dialog and is a traditional sequence number. 401 Contact contains a SIP or SIPS URI that represents a direct route to contact Alice, usually composed 402 of a username at a fully qualified domain name (FQDN). While an FQDN is preferred, many end systems 403 do not have registered domain names, so IP addresses are permitted. While the Via header field tells other 404 elements where to send the response, the Contact header field tells other elements where to send future 405 requests. 406 Max-Forwards serves to limit the number of hops a request can make on the way to its destination. It 407 consists of an integer that is decremented by one at each hop. 408 Content-Type contains a description of the message body (not shown). 409 Content-Length contains an octet (byte) count of the message body. 410 The complete set of SIP header fields is defined in Section 20. 411 The details of the session, type of media, codec, sampling rate, etc. are not described using SIP. Rather, 412 the body of a SIP message contains a description of the session, encoded in some other protocol format. 413 One such format is Session Description Protocol (SDP) [1]. This SDP message (not shown in the example) 414 is carried by the SIP message in a way that is analogous to a document attachment being carried by an email 415 message, or a web page being carried in an HTTP message. 416 Since the softphone does not know the location of Bob or the SIP server in the biloxi.com domain, the 417 softphone sends the INVITE to the SIP server that serves Alice’s domain, atlanta.com. The address of the 418 atlanta.com SIP server could have been configured in Alice’s softphone, or it could have been discovered by 419 DHCP, for example. 420 The atlanta.com SIP server is a type of SIP server known as a proxy server. A proxy server receives 421 SIP requests and forwards them on behalf of the requestor. In this example, the proxy server receives the 422 INVITE request and sends a 100 (Trying) response back to Alice’s softphone. The 100 (Trying) response 423 indicates that the INVITE has been received and that the proxy is working on her behalf to route the INVITE 424 to the destination. Responses in SIP use a three-digit code followed by a descriptive phrase. This response 425 contains the same To, From, Call-ID,CSeq and branch parameter in the Via as the INVITE, which allows 426 Alice’s softphone to correlate this response to the sent INVITE. The atlanta.com proxy server locates the 427 proxy server at biloxi.com, possibly by performing a particular type of DNS (Domain Name Service) lookup 428 to find the SIP server that serves the biloxi.com domain. This is described in [4]. As a result, it obtains the 429 IP address of the biloxi.com proxy server and forwards, or proxies, the INVITE request there. Before 430 forwarding the request, the atlanta.com proxy server adds an additional Via header field value that contains 431 its own address (the INVITE already contains Alice’s address in the first Via). The biloxi.com proxy server 432 receives the INVITE and responds with a 100 (Trying) response back to the atlanta.com proxy server to 433 indicate that it has received the INVITE and is processing the request. The proxy server consults a database, 434 generically called a location service, that contains the current IP address of Bob. (We shall see in the next 435 section how this database can be populated.) The biloxi.com proxy server adds another Via header field 436 value with its own address to the INVITE and proxies it to Bob’s SIP phone. 437 Bob’s SIP phone receives the INVITE and alerts Bob to the incoming call from Alice so that Bob can 438 decide whether to answer the call, that is, Bob’s phone rings. Bob’s SIP phone indicates this in a 180 439 (Ringing) response, which is routed back through the two proxies in the reverse direction. Each proxy uses 440 the Via header field to determine where to send the response and removes its own address from the top. 441 As a result, although DNS and location service lookups were required to route the initial INVITE, the 180 442 (Ringing) response can be returned to the caller without lookups or without state being maintained in the 443 proxies. This also has the desirable property that each proxy that sees the INVITE will also see all responses 444 to the INVITE. 445 When Alice’s softphone receives the 180 (Ringing) response, it passes this information to Alice, perhaps 446 using an audio ringback tone or by displaying a message on Alice’s screen. 447 In this example, Bob decides to answer the call. When he picks up the handset, his SIP phone sends a 448 200 (OK) response to indicate that the call has been answered. The 200 (OK) contains a message body with 449 the SDP media description of the type of session that Bob is willing to establish with Alice. As a result, there 450 is a two-phase exchange of SDP messages: Alice sent one to Bob, and Bob sent one back to Alice. This 451 two-phase exchange provides basic negotiation capabilities and is based on a simple offer/answer model of 452 SDP exchange. If Bob did not wish to answer the call or was busy on another call, an error response would 453 have been sent instead of the 200 (OK), which would have resulted in no media session being established. 454 The complete list of SIP response codes is in Section 21. The 200 (OK) (message F9 in Figure 1) might 455 look like this as Bob sends it out:

456  SIP/2.0 200 OK
457  Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bKnashds8
458  ;received=10.2.1.1
459  Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
460  ;received=10.1.1.1
461  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
462  ;received=10.1.3.3
463  To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
464  From: Alice <sip:alice@atlanta.com>;tag=1928301774
465  Call-ID: a84b4c76e66710
466  CSeq: 314159 INVITE
467  Contact: <sip:bob@192.0.2.8>
468  Content-Type: application/sdp
469  Content-Length: 131

470

471  (Bob's SDP not shown)

472 The first line of the response contains the response code (200) and the reason phrase (OK). The remain-473 ing lines contain header fields. The Via, To, From, Call-ID, and CSeq header fields are copied from the 474 INVITE request. (There are three Via header field values - one added by Alice’s SIP phone, one added by 475 the atlanta.com proxy, and one added by the biloxi.com proxy.) Bob’s SIP phone has added a tag parameter 476 to the To header field. This tag will be incorporated by both endpoints into the dialog and will be included 477 in all future requests and responses in this call. The Contact header field contains a URI at which Bob can 478 be directly reached at his SIP phone. The Content-Type and Content-Length refer to the message body 479 (not shown) that contains Bob’s SDP media information. 480 In addition to DNS and location service lookups shown in this example, proxy servers can make flexible 481 “routing decisions” to decide where to send a request. For example, if Bob’s SIP phone returned a 486 (Busy 482 Here) response, the biloxi.com proxy server could proxy the INVITE to Bob’s voicemail server. A proxy 483 server can also send an INVITE to a number of locations at the same time. This type of parallel search is 484 known as forking. 485 In this case, the 200 (OK) is routed back through the two proxies and is received by Alice’s softphone, 486 which then stops the ringback tone and indicates that the call has been answered. Finally, Alice’s softphone 487 sends an acknowledgement message, ACK to Bob’s SIP phone to confirm the reception of the final response 488 (200 (OK)). In this example, the ACK is sent directly from Alice’s softphone to Bob’s SIP phone, bypassing 489 the two proxies. This occurs because the endpoints have learned each other’s address from the Contact 490 header fields through the INVITE/200 (OK) exchange, which was not known when the initial INVITE was 491 sent. The lookups performed by the two proxies are no longer needed, so the proxies drop out of the call 492 flow. This completes the INVITE/200/ACK three-way handshake used to establish SIP sessions. Full details 493 on session setup are in Section 13. 494 Alice and Bob’s media session has now begun, and they send media packets using the format to which 495 they agreed in the exchange of SDP. In general, the end-to-end media packets take a different path from the 496 SIP signaling messages. 497 During the session, either Alice or Bob may decide to change the characteristics of the media session. 498 This is accomplished by sending a re-INVITE containing a new media description. This re-INVITE refer-499 ences the existing dialog so that the other party knows that it is to modify an existing session instead of 500 establishing a new session. The other party sends a 200 (OK) to accept the change. The requestor responds 501 to the 200 (OK) with an ACK. If the other party does not accept the change, he sends an error response such 502 as 406 (Not Acceptable), which also receives an ACK. However, the failure of the re-INVITE does not cause 503 the existing call to fail - the session continues using the previously negotiated characteristics. Full details on 504 session modification are in Section 14. 505 At the end of the call, Bob disconnects (hangs up) first and generates a BYE message. This BYE is 506 routed directly to Alice’s softphone, again bypassing the proxies. Alice confirms receipt of the BYE with a 507 200 (OK) response, which terminates the session and the BYE transaction. No ACK is sent - an ACK is only 508 sent in response to a response to an INVITE request. The reasons for this special handling for INVITE will 509 be discussed later, but relate to the reliability mechanisms in SIP, the length of time it can take for a ringing 510 phone to be answered, and forking. For this reason, request handling in SIP is often classified as either 511 INVITE or non-INVITE, referring to all other methods besides INVITE. Full details on session termination 512 are in Section 15. 513 Full details of all the messages shown in the example of Figure 1 are shown in Section 24.2. 514 In some cases, it may be useful for proxies in the SIP signaling path to see all the messaging between the 515 endpoints for the duration of the session. For example, if the biloxi.com proxy server wished to remain in the 516 SIP messaging path beyond the initial INVITE, it would add to the INVITE a required routing header field 517 known as Record-Route that contained a URI resolving to the hostname or IP address of the proxy. This 518 information would be received by both Bob’s SIP phone and (due to the Record-Route header field being 519 passed back in the 200 (OK)) Alice’s softphone and stored for the duration of the dialog. The biloxi.com 520 proxy server would then receive and proxy the ACK, BYE, and 200 (OK) to the BYE. Each proxy can 521 independently decide to receive subsequent messaging, and that messaging will go through all proxies that 522 elect to receive it. This capability is frequently used for proxies that are providing mid-call features. 523 Registration is another common operation in SIP. Registration is one way that the biloxi.com server 524 can learn the current location of Bob. Upon initialization, and at periodic intervals, Bob’s SIP phone sends 525 REGISTER messages to a server in the biloxi.com domain known as a SIP registrar. The REGISTER mes-526 sages associate Bob’s SIP or SIPS URI (sip:bob@biloxi.com) with the machine into which he is currently 527 logged (conveyed as a SIP or SIPS URI in the Contact header field). The registrar writes this association, 528 also called a binding, to a database, called the location service, where it can be used by the proxy in the 529 biloxi.com domain. Often, a registrar server for a domain is co-located with the proxy for that domain. It is 530 an important concept that the distinction between types of SIP servers is logical, not physical. 531 Bob is not limited to registering from a single device. For example, both his SIP phone at home and 532 the one in the office could send registrations. This information is stored together in the location service and 533 allows a proxy to perform various types of searches to locate Bob. Similarly, more than one user can be 534 registered on a single device at the same time. 535 The location service is just an abstract concept. It generally contains information that allows a proxy to 536 input a URI and receive a set of zero or more URIs that tell the proxy where to send the request. Registrations 537 are one way to create this information, but not the only way. Arbitrary mapping functions can be configured 538 at the discretion of the administrator. 539 Finally, it is important to note that in SIP, registration is used for routing incoming SIP requests and 540 has no role in authorizing outgoing requests. Authorization and authentication are handled in SIP either 541 on a request-by-request basis with a challenge/response mechanism, or by using a lower layer scheme as 542 discussed in Section 26. 543 The complete set of SIP message details for this registration example is in Section 24.1. 544 Additional operations in SIP, such as querying for the capabilities of a SIP server or client using OP-545 TIONS, or canceling a pending request using CANCEL, will be introduced in later sections.

546 5 Structure of the Protocol

547 SIP is structured as a layered protocol, which means that its behavior is described in terms of a set of fairly 548 independent processing stages with only a loose coupling between each stage. The protocol behavior is 549 described as layers for the purpose of presentation, allowing the description of functions common across 550 elements in a single section. It does not dictate an implementation in any way. When we say that an element 551 “contains” a layer, we mean it is compliant to the set of rules defined by that layer. 552 Not every element specified by the protocol contains every layer. Furthermore, the elements specified 553 by SIP are logical elements, not physical ones. A physical realization can choose to act as different logical 554 elements, perhaps even on a transaction-by-transaction basis. 555 The lowest layer of SIP is its syntax and encoding. Its encoding is specified using an augmented Backus-556 Naur Form grammar (BNF). The complete BNF is specified in Section 25; an overview of a SIP message’s 557 structure can be found in Section 7.

558 The second layer is the transport layer. It defines how a client sends requests and receives responses and 559 how a server receives requests and sends responses over the network. All SIP elements contain a transport 560 layer. The transport layer is described in Section 18. 561 The third layer is the transaction layer. Transactions are a fundamental component of SIP. A transaction 562 is a request sent by a client transaction (using the transport layer) to a server transaction, along with all 563 responses to that request sent from the server transaction back to the client. The transaction layer handles 564 application-layer retransmissions, matching of responses to requests, and application-layer timeouts. Any 565 task that a user agent client (UAC) accomplishes takes place using a series of transactions. Discussion of 566 transactions can be found in Section 17. User agents contain a transaction layer, as do stateful proxies. 567 Stateless proxies do not contain a transaction layer. The transaction layer has a client component (referred 568 to as a client transaction) and a server component (referred to as a server transaction), each of which are 569 represented by a finite state machine that is constructed to process a particular request. 570 The layer above the transaction layer is called the transaction user (TU). Each of the SIP entities, except 571 the stateless proxy, is a transaction user. When a TU wishes to send a request, it creates a client transaction 572 instance and passes it the request along with the destination IP address, port, and transport to which to send 573 the request. A TU that creates a client transaction can also cancel it. When a client cancels a transaction, 574 it requests that the server stop further processing, revert to the state that existed before the transaction was 575 initiated, and generate a specific error response to that transaction. This is done with a CANCEL request, 576 which constitutes its own transaction, but references the transaction to be cancelled (Section 9). 577 The SIP elements, that is, user agent clients and servers, stateless and stateful proxies and registrars, 578 contain a core that distinguishes them from each other. Cores, except for the stateless proxy, are transaction 579 users. While the behavior of the UAC and UAS cores depends on the method, there are some common rules 580 for all methods (Section 8). For a UAC, these rules govern the construction of a request; for a UAS, they 581 govern the processing of a request and generating a response. Since registrations play an important role in 582 SIP, a UAS that handles a REGISTER is given the special name registrar. Section 10 describes UAC and 583 UAS core behavior for the REGISTER method. Section 11 describes UAC and UAS core behavior for the 584 OPTIONS method, used for determining the capabilities of a UA. 585 Certain other requests are sent within a dialog. A dialog is a peer-to-peer SIP relationship between two 586 user agents that persists for some time. The dialog facilitates sequencing of messages and proper routing 587 of requests between the user agents. The INVITE method is the only way defined in this specification to 588 establish a dialog. When a UAC sends a request that is within the context of a dialog, it follows the common 589 UAC rules as discussed in Section 8 but also the rules for mid-dialog requests. Section 12 discusses dialogs 590 and presents the procedures for their construction and maintenance, in addition to construction of requests 591 within a dialog. 592 The most important method in SIP is the INVITE method, which is used to establish a session between 593 participants. A session is a collection of participants, and streams of media between them, for the purposes 594 of communication. Section 13 discusses how sessions are initiated, resulting in one or more SIP dialogs. 595 Section 14 discusses how characteristics of that session are modified through the use of an INVITE request 596 within a dialog. Finally, section 15 discusses how a session is terminated. 597 The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal entirely with the UA core (Section 9 598 describes cancellation, which applies to both UA core and proxy core). Section 16 discusses the proxy 599 element, which facilitates routing of messages between user agents.

600 6 Definitions

601 This specification uses a number of terms to refer to the roles played by participants in SIP communications. 602 The terms and generic syntax of URI and URL are defined in RFC 2396 [5]. The following terms have 603 special significance for SIP.

604 Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a 605 location service that can map the URI to another URI where the user might be available. Typically, 606 the location service is populated through registrations. An AOR is frequently thought of as the “public 607 address” of the user.

608 Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a logical entity that combines a user 609 agent client and server. When receiving a request as a UAS, it generates a related request as a UAC. 610 A B2BUA may delay responding to the request until it has received a response from the request it 611 generated. A B2BUA is call stateful. Since it is a combination of a UAC and UAS, its protocol 612 behavior is defined completely by the behavior of those roles.

613 Call: A call is an informal term that refers to some communication between peers generally set up for the 614 purposes of a multimedia conversation.

615 Call Leg: Another name for a dialog [30]; no longer used in this specification.

616 Call Stateful: A proxy is call stateful if it retains state for a dialog from the initiating INVITE to the ter-617 minating BYE request. A call stateful proxy is always transaction stateful, but the converse is not 618 necessarily true.

619 Client: A client is any network element that sends SIP requests and receives SIP responses. Clients may or 620 may not interact directly with a human user. User agent clients and proxies are clients.

621 Conference: A multimedia session (see below) that contains multiple participants.

622 Core: Core designates the functions specific to a particular role of a SIP element, i.e., specific to either a 623 stateful or stateless proxy, a user agent or registrar. All cores except those for the stateless proxy are 624 transaction users.

625 Dialog: A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog 626 is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified 627 by a call identifier, local address, and remote address. A dialog was formerly known as a call leg in 628 RFC 2543.

629 Downstream: A direction of message forwarding within a transaction that refers to the direction that re-630 quests flow from the user agent client to user agent server.

631 Final Response: A response that terminates a SIP transaction, as opposed to a provisional response that 632 does not. All 2xx, 3xx, 4xx, 5xx and 6xx responses are final.

633 Header: A header is a component of a SIP message that conveys information about the message. It is 634 structured as a sequence of header fields.

635 Header field: A header field is a component of the SIP message header. It consists of one or more header 636 field values separated by comma or having the same header field name.

637 Header field value: A header field value consists of a field name and a field value, separated by a colon.

638 Home Domain: The domain providing service to a SIP user. Typically, this is the domain present in the 639 URI in the address-of-record of a registration.

640 Informational Response: Same as a provisional response.

641 Initiator, Calling Party, Caller: The party initiating a session (and dialog) with an INVITE request. A 642 caller retains this role from the time it sends the initial INVITE that established a dialog until the 643 termination of that dialog.

644 Invitation: An INVITE request.

645 Invitee, Invited User, Called Party, Callee: The party that receives an INVITE request for the purposes of 646 establishing a new session. A callee retains this role from the time it receives the INVITE until the 647 termination of the dialog established by that INVITE.

648 Location Service: A location service is used by a SIP redirect or proxy server to obtain information about 649 a callee’s possible location(s). It contains a list of bindings of address-of-record keys to zero or more 650 contact addresses. The bindings can be created and removed in many ways; this specification defines 651 a REGISTER method that updates the bindings.

652 Loop: A request that arrives at a proxy, is forwarded, and later arrives back at the same proxy. When it 653 arrives the second time, its Request-URI is identical to the first time, and other header fields that 654 affect proxy operation are unchanged, so that the proxy would make the same processing decision on 655 the request it made the first time. Looped requests are errors, and the procedures for detecting them 656 and handling them are described by the protocol.

657 Loose Routing: A proxy is said to be loose routing if it follows the procedures defined in this specification 658 for processing of the Route header field. These procedures separate the destination of the request 659 (present in the Request-URI) from the set of proxies that need to be visited along the way (present 660 in the Route header field). A proxy compliant to these mechanisms is also known as a loose router.

661 Message: Data sent between SIP elements as part of the protocol. SIP messages are either requests or 662 responses.

663 Method: The method is the primary function that a request is meant to invoke on a server. The method is 664 carried in the request message itself. Example methods are INVITE and BYE.

665 Outbound Proxy: A proxy that receives requests from a client, even though it may not be the server re-666 solved by the Request-URI. Typically, a UA is manually configured with an outbound proxy, or can 667 learn about one through auto-configuration protocols.

668 Parallel Search: In a parallel search, a proxy issues several requests to possible user locations upon re-669 ceiving an incoming request. Rather than issuing one request and then waiting for the final response 670 before issuing the next request as in a sequential search, a parallel search issues requests without 671 waiting for the result of previous requests.

672 Provisional Response: A response used by the server to indicate progress, but that does not terminate a SIP 673 transaction. 1xx responses are provisional, other responses are considered final. Provisional responses 674 are not sent reliably.

675 Proxy, Proxy Server: A SIP element that acts as both a server and a client for the purpose of making 676 requests on behalf of other clients. A proxy server primarily routes requests, ensuring that a request is 677 sent to another SIP element “closer” to the targeted user. Proxies are also useful for enforcing policy 678 (for example, making sure a user is allowed to make a call). A proxy interprets, and, if necessary, 679 rewrites specific parts of a request message before forwarding it.

680 Recursion: A client recurses on a 3xx response when it generates a new request to one or more of the URIs 681 in the Contact header field in the response.

682 Redirect Server: A redirect server is a user agent server that generates 3xx responses to requests it receives, 683 directing the client to contact an alternate set of URIs.

684 Registrar: A registrar is a server that accepts REGISTER requests and places the information it receives 685 in those requests into the location service for the domain it handles.

686 Regular Transaction: A regular transaction is any transaction with a method other than INVITE, ACK, or 687 CANCEL.

688 Request: A SIP message sent from a client to a server, for the purpose of invoking a particular operation.

689 Response: A SIP message sent from a server to a client, for indicating the status of a request sent from the 690 client to the server.

691 Ringback: Ringback is the signaling tone produced by the calling party’s application indicating that a 692 called party is being alerted (ringing).

693 ¡¡¡¡¡¡¡ definitions.tex

694 Role: SIP elements can act in several roles, namely proxy (stateless or stateful), user agent (client or server) 695 or registrar. A SIP element acts in one role for each transaction, but may change roles for different 696 transactions.

697 Route Set: A route set is a collection of ordered SIP URI which =======

698 Route Set: A route set is a collection of ordered SIP or SIPS URI which ¿¿¿¿¿¿¿ 1.31 represent a list of 699 proxies that must be traversed when sending a particular request. A route set can be learned, through 700 headers like Record-Route, or it can be configured.

701 Server: A server is a network element that receives requests in order to service them and sends back re-702 sponses to those requests. Examples of servers are proxies, user agent servers, redirect servers, and 703 registrars.

704 Sequential Search: In a sequential search, a proxy server attempts each contact address in sequence, pro-705 ceeding to the next one only after the previous has generated a final response. A 2xx or 6xx class final 706 response always terminates a sequential search.

707 Session: From the SDP specification: “A multimedia session is a set of multimedia senders and receivers 708 and the data streams flowing from senders to receivers. A multimedia conference is an example of a 709 multimedia session.” (RFC 2327 [1]) (A session as defined for SDP can comprise one or more RTP 710 sessions.) As defined, a callee can be invited several times, by different calls, to the same session. If 711 SDP is used, a session is defined by the concatenation of the SDP user name, session id, network type, 712 address type, and address elements in the origin field.

713 SIP Element: A SIP element is a SIP client or server that fulfills one of the SIP roles.

714 SIP Transaction: A SIP transaction occurs between a client and a server and comprises all messages from 715 the first request sent from the client to the server up to a final (non-1xx) response sent from the server 716 to the client. If the request is INVITE and the final response is a non-2xx, the transaction also includes 717 an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction.

718 Spiral: A spiral is a SIP request that is routed to a proxy, forwarded onwards, and arrives once again at that 719 proxy, but this time differs in a way that will result in a different processing decision than the original 720 request. Typically, this means that the request’s Request-URI differs from its previous arrival. A 721 spiral is not an error condition, unlike a loop. A typical cause for this is call forwarding. A user calls 722 joe@example.com. The example.com proxy forwards it to Joe’s PC, which in turn, forwards it to 723 bob@example.com. This request is proxied back to the example.com proxy. However, this is not a 724 loop. Since the request is targeted at a different user, it is considered a spiral, and is a valid condition.

725 Stateful Proxy: A stateful proxy is a SIP element that maintains the client and server transaction state 726 machines defined by this specification during the processing of a request. Also known as a transaction 727 stateful proxy. The behavior of a stateful proxy is further defined in Section 16. A (transaction) 728 stateful proxy is not the same as a call stateful proxy.

729 Stateless Proxy: A stateless proxy is a SIP element that does not maintain the client or server transaction 730 state machines defined in this specification when it processes requests. A stateless proxy forwards 731 every request it receives downstream and every response it receives upstream.

732 Strict Routing: A proxy is said to be strict routing if it follows the Route processing rules of RFC 2543 733 and many prior Internet Draft versions of this RFC. That rule caused proxies to destroy the contents of 734 the Request-URI when a Route header field was present. Strict routing behavior is not used in this 735 specification, in favor of a loose routing behavior. Proxies that perform strict routing are also known 736 as strict routers.

737 Target Refresh Request: A target refresh request sent within a dialog is defined as a request that can 738 modify the remote target of the dialog.

739 Transaction User (TU): The layer of protocol processing that resides above the transaction layer. Trans-740 action users include the UAC core, UAS core, and proxy core.

741 Upstream: A direction of message forwarding within a transaction that refers to the direction that responses 742 flow from the user agent server back to the user agent client.

743 URL-encoded: A character string encoded according to RFC 1738, Section 2.2 [6].

744 User Agent Client (UAC): A user agent client is a SIP element that creates a new request, and then uses 745 the client transaction state machinery to send it. The role of UAC lasts only for the duration of that 746 transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration 747 of that transaction. If it receives a request later, it assumes the role of a user agent server for the 748 processing of that transaction.

749 UAC Core: The set of processing functions required of a UAC that reside above the transaction and trans-750 port layers.

751 User Agent Server (UAS): A user agent server is a SIP element that generates a response to a SIP request. 752 The response accepts, rejects, or redirects the request. This role lasts only for the duration of that 753 transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the 754 duration of that transaction. If it generates a request later, it assumes the role of a user agent client for 755 the processing of that transaction.

756 UAS Core: The set of processing functions required at a UAS that reside above the transaction and transport 757 layers.

758 User Agent (UA): A SIP element that can act as both a user agent client and user agent server.

759 The role of UAC and UAS as well as proxy and redirect servers are defined on a transaction-by-760 transaction basis. For example, the user agent initiating a call acts as a UAC when sending the initial 761 INVITE request and as a UAS when receiving a BYE request from the callee. Similarly, the same software 762 can act as a proxy server for one request and as a redirect server for the next request. 763 Proxy, location, and registrar servers defined above are logical entities; implementations may combine 764 them into a single application.

765 7 SIP Messages

766 SIP is a text-based protocol and uses the ISO 10646 character set in UTF-8 encoding (RFC 2279 [7]). 767 A SIP message is either a request from a client to a server, or a response from a server to a client. 768 Both Request (section 7.1) and Response (section 7.2) messages use the basic format of RFC 2822 769 [3], even though the syntax differs in character set and syntax specifics. (SIP allows header fields that would 770 not be valid RFC 2822 header fields, for example.) Both types of messages consist of a start-line, one or 771 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

772

773 The start-line, each message-header line, and the empty line must be terminated by a carriage-return 774 line-feed sequence (CRLF). Note that the empty line must be present even if the message-body is not. 775 Except for the above difference in character sets, much of SIP’s message and header field syntax is 776 identical to HTTP/1.1. Rather than repeating the syntax and semantics here, we use [HX.Y] to refer to 777 Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]). 778 However, SIP is not an extension of HTTP.

779 7.1 Requests

780 SIP requests are distinguished by having a Request-Line for a start-line. A Request-Line contains a 781 method name, a Request-URI, and the protocol version separated by a single space (SP) character. 782 The Request-Line ends with CRLF. No CR or LF are allowed except in the end-of-line CRLF se-783 quence. No linear whitespace (LWS) is allowed in any of the elements.

Request-Line = Method SP Request-URI SP SIP-Version CRLF

784

785 Method: This specification defines six methods: REGISTER for registering contact information, INVITE, 786 ACK, and CANCEL for setting up sessions, BYE for terminating sessions, and OPTIONS for query-787 ing servers about their capabilities. SIP extensions, documented in standards track RFCs, may define 788 additional methods.

789 Request-URI: The Request-URI is a SIP or SIPS URI as described in Section 19.1 or a general URI 790 (RFC 2396 [5]). It indicates the user or service to which this request is being addressed. The Request-791 URI must not contain unescaped spaces or control characters and must not be enclosed in ”<>”. 792 SIP elements may support Request-URIs with schemes other than “sip” and “sips”, for example the 793 “tel” URI scheme of RFC 2806 [9]. SIP elements may translate non-SIP URIs using any mechanism 794 at their disposal, resulting in either SIP URI, SIPS URI, or some other scheme.

795 SIP-Version: Both request and response messages include the version of SIP in use, and follow [H3.1] (with 796 HTTP replaced by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version ordering, compliance 797 requirements, and upgrading of version numbers. To be compliant with this specification, applications 798 sending SIP messages must include a SIP-Version of “SIP/2.0”. The SIP-Version string is case-799 insensitive, but implementations must send upper-case.

800 Unlike HTTP/1.1, SIP treats the version number as a literal string. In practice, this should make no 801 difference.

802 7.2 Responses

803 SIP responses are distinguished from requests by having a Status-Line as their start-line. A Status-Line 804 consists of the protocol version followed by a numeric Status-Code and its associated textual phrase, with 805 each element separated by a single SP character. 806 No CR or LF is allowed except in the final CRLF sequence.

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

807

808 The Status-Code is a 3-digit integer result code that indicates the outcome of an attempt to understand 809 and satisfy a request. The Reason-Phrase is intended to give a short textual description of the Status-810 Code. The Status-Code is intended for use by automata, whereas the Reason-Phrase is intended for the 811 human user. A client is not required to examine or display the Reason-Phrase. 812 While this specification suggests specific wording for the reason phrase, implementations may choose 813 other text, for example, in the language indicated in the Accept-Language header field of the request. 814 The first digit of the Status-Code defines the class of response. The last two digits do not have any 815 categorization role. For this reason, any response with a status code between 100 and 199 is referred to as 816 a “1xx response”, any response with a status code between 200 and 299 as a “2xx response”, and so on. 817 SIP/2.0 allows six values for the first digit:

818 1xx: Provisional – request received, continuing to process the request;

819 2xx: Success – the action was successfully received, understood, and accepted;

820 3xx: Redirection – further action needs to be taken in order to complete the request;

821 4xx: Client Error – the request contains bad syntax or cannot be fulfilled at this server;

822 5xx: Server Error – the server failed to fulfill an apparently valid request;

823 6xx: Global Failure – the request cannot be fulfilled at any server.

824 Section 21 defines these classes and describes the individual codes.

825 7.3 Header Fields

826 SIP header fields are similar to HTTP header fields in both syntax and semantics. In particular, SIP header 827 fields follow the [H4.2] definitions of syntax for message-header and the rules for extending header fields 828 over multiple lines. However, the latter is specified in HTTP with implicit whitespace and folding. This 829 specification conforms with RFC 2234 [10] and uses only explicit whitespace and folding as an integral part 830 of the grammar. 831 [H4.2] also specifies that multiple header fields of the same field name whose value is a comma-separated 832 list can be combined into one header field. That applies to SIP as well, but the specific rule is different 833 because of the different grammars. Specifically, any SIP header whose grammar is of the form:

header = ”header-name” HCOLON header-value *(COMMA header-value)

834

835 allows for combining header fields of the same name into a comma-separated list. This is also true for 836 the Contact header, as long as none of the header field values are “*”.

837 7.3.1 Header Field Format

838 Header fields follow the same generic header format as that given in Section 2.2 of RFC 2822 [3]. Each 839 header field consists of a field name followed by a colon (”:”) and the field value.

840 field-name: field-value

841 The formal grammar for a message-header specified in Section 25 allows for an arbitrary amount of 842 whitespace on either side of the colon; however, implementations should avoid spaces between the field 843 name and the colon and use a single space (SP) between the colon and the field-value. Thus,

844 Subject:              lunch
845 Subject       :       lunch
846 Subject              :lunch
847 Subject: lunch

848 are all valid and equivalent, but the last is the preferred form. 849 Header fields can be extended over multiple lines by preceding each extra line with at least one SP or 850 horizontal tab (HT). The line break and the whitespace at the beginning of the next line are treated as a 851 single SP character. Thus, the following are equivalent:

852 Subject: I know you're there, pick up the phone and talk to me!
853 Subject: I know you're there,
854  pick up the phone
855  and talk to me!

856 The relative order of header fields with different field names is not significant. However, it is recom-857 mended that header fields which are needed for proxy processing (Via, Route, Record-Route, Proxy-858 Require, Max-Forwards, and Proxy-Authorization, for example) appear towards the top of the message 859 to facilitate rapid parsing. The relative order of header field rows with the same field name is important. 860 Multiple header field rows with the same field-name may be present in a message if and only if the entire 861 field-value for that header field is defined as a comma-separated list (that is, if follows the grammar defined 862 in Section 7.3). It must be possible to combine the multiple header field rows into one “field-name: field-863 value” pair, without changing the semantics of the message, by appending each subsequent field-value to 864 the first, each separated by a comma. The exceptions to this rule are the WWW-Authenticate, Authoriza-865 tion, Proxy-Authenticate, and Proxy-Authorization header fields. Multiple header field rows with these 866 names may be present in a message, but since their grammar does not follow the general form listed in 867 Section 7.3, they must not be combined into a single header field row. 868 Implementations must be able to process multiple header field rows with the same name in any combi-869 nation of the single-value-per-line or comma-separated value forms. 870 The following groups of header field rows are valid and equivalent:

871 Route: <sip:alice@atlanta.com>
872 Subject: Lunch
873 Route: <sip:bob@biloxi.com>
874 Route: <sip:carol@chicago.com>

875

876 Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>
877 Route: <sip:carol@chicago.com>
878 Subject: Lunch

879

880 Subject: Lunch
881 Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>, <sip:carol@chicago.com>

882 Each of the following blocks is valid but not equivalent to the others:

883 Route: <sip:alice@atlanta.com>
884 Route: <sip:bob@biloxi.com>
885 Route: <sip:carol@chicago.com>

886

887 Route: <sip:bob@biloxi.com>
888 Route: <sip:alice@atlanta.com>
889 Route: <sip:carol@chicago.com>

890

891 Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>,<sip:bob@biloxi.com>

892 The format of a header field-value is defined per header-name. It will always be either an opaque 893 sequence of TEXT-UTF8 octets, or a combination of whitespace, tokens, separators, and quoted strings. 894 Many existing header fields will adhere to the general form of a value followed by a semi-colon separated 895 sequence of parameter-name, parameter-value pairs:

896 field-name: field-value *(;parameter-name=parameter-value)

897 Even though an arbitrary number of parameter pairs may be attached to a header field value, any given 898 parameter-name must not appear more than once. 899 When comparing header fields, field names are always case-insensitive. Unless otherwise stated in 900 the definition of a particular header field, field values, parameter names, and parameter values are case-901 insensitive. Tokens are always case-insensitive. Unless specified otherwise, values expressed as quoted 902 strings are case-sensitive. 903 For example,

904 Contact: <sip:alice@atlanta.com>;expires=3600

905 is equivalent to

906 CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600

907 and

908 Content-Disposition: session;handling=optional

909 is equivalent to

910 content-disposition: Session;HANDLING=OPTIONAL

911 The following two header fields are not equivalent:

912 Warning: 370 devnull "Choose a bigger pipe"
913 Warning: 370 devnull "CHOOSE A BIGGER PIPE"

914 7.3.2 Header Field Classification

915 Some header fields only make sense in requests or responses. These are called request header fields and 916 response header fields, respectively. If a header field appears in a message not matching its category (such 917 as a request header field in a response), it must be ignored. Section 20 defines the classification of each 918 header field.

919 7.3.3 Compact Form

920 SIP provides a mechanism to represent common header field names in an abbreviated form. This may 921 be useful when messages would otherwise become too large to be carried on the transport available to it 922 (exceeding the maximum transmission unit (MTU) when using UDP, for example). These compact forms 923 are defined in Section 20. A compact form may be substituted for the longer form of a header field name at 924 any time without changing the semantics of the message. A header field name may appear in both long and 925 short forms within the same message. Implementations must accept both the long and short forms of each 926 header name.

927 7.4 Bodies

928 Requests, including new requests defined in extensions to this specification, may contain message bodies 929 unless otherwise noted. The interpretation of the body depends on the request method. 930 For response messages, the request method and the response status code determine the type and inter-931 pretation of any message body. All responses may include a body.

932 7.4.1 Message Body Type

933 The Internet media type of the message body must be given by the Content-Type header field. If the body 934 has undergone any encoding such as compression, then this must be indicated by the Content-Encoding 935 header field; otherwise, Content-Encoding must be omitted. If applicable, the character set of the message 936 body is indicated as part of the Content-Type header-field value. 937 The “multipart” MIME type defined in RFC 2046 [11] may be used within the body of the message. 938 Implementations that send requests containing multipart message bodies must send a session description 939 as a non-multipart message body if the remote implementation requests this through an Accept header field 940 that does not contain multipart. 941 Note that SIP messages may contain binary bodies or body parts.

942 7.4.2 Message Body Length

943 The body length in bytes is provided by the Content-Length header field. Section 20.14 describes the 944 necessary contents of this header field in detail. 945 The “chunked” transfer encoding of HTTP/1.1 must not be used for SIP. (Note: The chunked encoding 946 modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator.)

947 7.5 Framing SIP messages

948 Unlike HTTP, SIP implementations can use UDP or other unreliable datagram protocols. Each such data-949 gram carries one request or response. See Section 18 on constraints on usage of unreliable transports. 950 Implementations processing SIP messages over stream-oriented transports must ignore any CRLF ap-951 pearing before the start-line [H4.1].

952 The Content-Length header field value is used to locate the end of each SIP message in a stream. It will always 953 be present when SIP messages are sent over stream-oriented transports.

954 8 General User Agent Behavior

955 A user agent represents an end system. It contains a user agent client (UAC), which generates requests, and 956 a user agent server (UAS), which responds to them. A UAC is capable of generating a request based on 957 some external stimulus (the user clicking a button, or a signal on a PSTN line) and processing a response. A 958 UAS is capable of receiving a request and generating a response based on user input, external stimulus, the 959 result of a program execution, or some other mechanism.

960 When a UAC sends a request, it will pass through some number of proxy servers, which forward the 961 request towards the UAS. When the UAS generates a response, the response is forwarded towards the UAC. 962 UAC and UAS procedures depend strongly on two factors. First, based on whether the request or 963 response is inside or outside of a dialog, and second, based on the method of a request. Dialogs are discussed 964 thoroughly in Section 12; they represent a peer-to-peer relationship between user agents and are established 965 by specific SIP methods, such as INVITE. 966 In this section, we discuss the method-independent rules for UAC and UAS behavior when processing 967 requests that are outside of a dialog. This includes, of course, the requests which themselves establish a 968 dialog. 969 Security procedures for requests and responses outside of a dialog are described in Section 26. Specif-970 ically, mechanisms exist for the UAS and UAC to mutually authenticate. A limited set of privacy features 971 are also supported through encryption of bodies using S/MIME.

972 8.1 UAC Behavior

973 This section covers UAC behavior outside of a dialog.

974 8.1.1 Generating the Request

975 A valid SIP request formulated by a UAC must at a minimum contain the following header fields: To, From, 976 CSeq, Call-ID, Max-Forwards, and Via; all of these header fields are mandatory in all SIP messages. 977 These six header fields are the fundamental building blocks of a SIP message, as they jointly provide for 978 most of the critical message routing services including the addressing of messages, the routing of responses, 979 limiting message propagation, ordering of messages, and the unique identification of transactions. These 980 header fields are in addition to the mandatory request line, which contains the method, Request-URI, and 981 SIP version. 982 Examples of requests sent outside of a dialog include an INVITE to establish a session (Section 13) and 983 an OPTIONS to query for capabilities (Section 11).

984 8.1.1.1 Request-URI The initial Request-URI of the message should be set to the value of the URI 985 in the To field. One notable exception is the REGISTER method; behavior for setting the Request-URI 986 of REGISTER is given in Section 10. It may also be undesirable for privacy reasons or convenience to 987 set these fields to the same value (especially if the originating UA expects that the Request-URI will be 988 changed during transit). 989 In some special circumstances, the presence of a pre-existing route set can affect the Request-URI of 990 the message. A pre-existing route set is an ordered set of URIs that identify a chain of servers, to which a 991 UAC will send outgoing requests that are outside of a dialog. Commonly, they are configured on the UA by 992 a user or service provider manually, or through some other non-SIP mechanism. When a provider wishes 993 to configure a UA with an outbound proxy, it is recommended that this be done by providing it with a 994 pre-existing route set with a single URI, that of the outbound proxy. 995 When a pre-existing route set is present, the procedures for populating the Request-URI and Route 996 header field detailed in Section 12.2.1.1 must be followed, even though there is no dialog. If the Request-997 URI specifies a SIPS URI, all the SIP URI in the route set must be converted to SIPS URI (by changing 998 the scheme to SIPS) before performing the processing of Section 12.2.1.1.

999 8.1.1.2 To The To header field first and foremost specifies the desired “logical” recipient of the request, 1000 or the address-of-record of the user or resource that is the target of this request. This may or may not be 1001 the ultimate recipient of the request. The To header field may contain a SIP or SIPS URI, but it may also 1002 make use of other URI schemes (the tel URL [9], for example) when appropriate. All SIP implementations 1003 must support the SIP and URI scheme. Any implementation that supports TLS must support the SIPS 1004 URI scheme. The To header field allows for a display name. 1005 A UAC may learn how to populate the To header field for a particular request in a number of ways. 1006 Usually the user will suggest the To header field through a human interface, perhaps inputting the URI 1007 manually or selecting it from some sort of address book. Frequently, the user will not enter a complete 1008 URI, but rather, a string of digits or letters (for example, “bob”). It is at the discretion of the UA to choose 1009 how to interpret this input. Using it to form the user part of a SIP URI implies that the UA wishes the 1010 name to be resolved in the domain to the right-hand side (RHS) of the at-sign in the SIP URI (for instance, 1011 sip:bob@example.com). Using it to form the user part of a SIPS URI implies that the UA wishes to securely 1012 communicate, and that the name is to be resolved in the domain to the RHS of the at-sign. The RHS 1013 will frequently be the home domain of the user, which allows for the home domain to process the outgoing 1014 request. This is useful for features like “speed dial” that require interpretation of the user part in the home 1015 domain. The tel URL may be used when the UA does not wish to specify the domain that should interpret a 1016 telephone number that has been inputted by the user. Rather, each domain through which the request passes 1017 would be given that opportunity. As an example, a user in an airport might log in and send requests through 1018 an outbound proxy in the airport. If they enter “411” (this is the phone number for local directory assistance 1019 in the United States), that needs to be interpreted and processed by the outbound proxy in the airport, not 1020 the user’s home domain. In this case, tel:411 would be the right choice. 1021 A request outside of a dialog must not contain a tag; the tag in the To field of a request identifies the 1022 peer of the dialog. Since no dialog is established, no tag is present. 1023 For further information on the To header field, see Section 20.39. The following is an example of valid 1024 To header field:

1025  To: Carol <sip:carol@chicago.com>

1026 8.1.1.3 From The From header field indicates the logical identity of the initiator of the request, possibly 1027 the user’s address-of-record. Like the To header field, it contains a URI and optionally a display name. It 1028 is used by SIP elements to determine which processing rules to apply to a request (for example, automatic 1029 call rejection). As such, it is very important that the From URI not contain IP addresses or the FQDN of the 1030 host on which the UA is running, since these are not logical names. 1031 The From header field allows for a display name. A UAC should use the display name “Anonymous”, 1032 along with a syntactically correct, but otherwise meaningless URI (like sip:thisis@anonymous.invalid), if 1033 the identity of the client is to remain hidden. 1034 Usually the value that populates the From header field in requests generated by a particular UA is pre-1035 provisioned by the user or by the administrators of the user’s local domain. If a particular UA is used by 1036 multiple users, it might have switchable profiles that include a URI corresponding to the identity of the 1037 profiled user. Recipients of requests can authenticate the originator of a request in order to ascertain that 1038 they are who their From header field claims they are (see Section 22 for more on authentication). 1039 The From field must contain a new “tag” parameter, chosen by the UAC. See Section 19.3 for details 1040 on choosing a tag. 1041 For further information on the From header field, see Section 20.20. Examples:

1042  From: "Bob" <sips:bob@biloxi.com> ;tag=a48s
1043  From: sip:+12125551212@phone2net.com;tag=887s
1044  From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8

1045 8.1.1.4 Call-ID The Call-ID header field acts as a unique identifier to group together a series of mes-1046 sages. It must be the same for all requests and responses sent by either UA in a dialog. It should be the 1047 same in each registration from a UA. 1048 In a new request created by a UAC outside of any dialog, the Call-ID header field must be selected by 1049 the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. 1050 All SIP UAs must have a means to guarantee that the Call-ID header fields they produce will not be inad-1051 vertently generated by any other UA. Note that when requests are retried after certain failure responses that 1052 solicit an amendment to a request (for example, a challenge for authentication), these retried requests are 1053 not considered new requests, and therefore do not need new Call-ID header fields; see Section 8.1.3.5. 1054 Use of cryptographically random identifiers [12] in the generation of Call-IDs is recommended. Im-1055 plementations may use the form “localid@host”. Call-IDs are case-sensitive and are simply compared 1056 byte-by-byte.

1057 Using cryptographically random identifiers provides some protection against session hijacking and reduces the 1058 likelihood of unintentional Call-ID collisions.

1059 No provisioning or human interface is required for the selection of the Call-ID header field value for a 1060 request. 1061 For further information on the Call-ID header field, see Section 20.8. 1062 Example:

1063  Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com

1064 8.1.1.5 CSeq The CSeq header field serves as a way to identify and order transactions. It consists 1065 of a sequence number and a method. The method must match that of the request. For non-REGISTER 1066 requests outside of a dialog, the sequence number value is arbitrary. The sequence number value must 1067 be expressible as a 32-bit unsigned integer and must be less than 2**31. As long as it follows the above 1068 guidelines, a client may use any mechanism it would like to select CSeq header field values. 1069 Section 12.2.1.1 discusses construction of the CSeq for requests within a dialog. 1070 Example:

1071  CSeq: 4711 INVITE

1072 8.1.1.6 Max-Forwards The Max-Forwards header field serves to limit the number of hops a request 1073 can transit on the way to its destination. It consists of an integer that is decremented by one at each hop. 1074 If the Max-Forwards value reaches 0 before the request reaches its destination, it will be rejected with a 1075 483(Too Many Hops) error response. 1076 A UAC must insert a Max-Forwards header field into each request it originates with a value which 1077 should be 70. This number was chosen to be sufficiently large to guarantee that a request would not be 1078 dropped in any SIP network when there were no loops, but not so large as to consume proxy resources when 1079 a loop does occur. Lower values should be used with caution and only in networks where topologies are 1080 known by the UA.

1081 8.1.1.7 Via The Via header field is used to indicate the transport used for the transaction and to identify 1082 the location where the response is to be sent. A Via header field value is added only after the transport that 1083 will be used to reach the next hop has been selected (which may involve the usage of the procedures in [4]).

1084

1085 When the UAC creates a request, it must insert a Via into that request. The protocol name and protocol 1086 version in the header field must be SIP and 2.0, respectively. The Via header field value must contain a 1087 branch parameter. This parameter is used to identify the transaction created by that request. This parameter 1088 is used by both the client and the server. 1089 The branch parameter value must be unique across space and time for all requests sent by the UA. 1090 The exceptions to this rule are CANCEL and ACK for non-2xx responses. As discussed below, a CANCEL 1091 request will have the same value of the branch parameter as the request it cancels. As discussed in Section 1092 17.1.1.3, an ACK for a non-2xx response will also have the same branch ID as the INVITE whose response 1093 it acknowledges.

1094 The uniqueness property of the branch ID parameter, to facilitate its use as a transaction ID, was not part of RFC

1095 2543

1096 The branch ID inserted by an element compliant with this specification must always begin with the 1097 characters “z9hG4bK”. These 7 characters are used as a magic cookie (7 is deemed sufficient to ensure that 1098 an older RFC 2543 implementation would not pick such a value), so that servers receiving the request can 1099 determine that the branch ID was constructed in the fashion described by this specification (that is, globally 1100 unique). Beyond this requirement, the precise format of the branch token is implementation-defined. 1101 The Via header maddr, ttl, and sent-by components will be set when the request is processed by the 1102 transport layer (Section 18). 1103 Via processing for proxies is described in Section 16.6 Item 8 and Section 16.7 Item 3.

1104 8.1.1.8 Contact The Contact header field provides a SIP URI that can be used to contact that specific 1105 instance of the UA for subsequent requests. The Contact header field must be present and contain exactly 1106 one SIP URI in any request that can result in the establishment of a dialog. For the methods defined in this 1107 specification, that includes only the INVITE request. For these requests, the scope of the Contact is global. 1108 That is, the Contact header field value contains the URI at which the UA would like to receive requests, 1109 and this URI must be valid even if used in subsequent requests outside of any dialogs. 1110 If the Request-URI contains a SIPS URI, the Contact header field must contain a SIPS URI as well. 1111 For further information on the Contact header field, see Section 20.10.

1112 8.1.1.9 Supported and Require If the UAC supports extensions to SIP that can be applied by the 1113 server to the response, the UAC should include a Supported header field in the request listing the option 1114 tags (Section 19.2) for those extensions. 1115 The option tags listed must only refer to extensions defined in standards-track RFCs. This is to pre-1116 vent servers from insisting that clients implement non-standard, vendor-defined features in order to receive 1117 service. Extensions defined by experimental and informational RFCs are explicitly excluded from usage 1118 with the Supported header field in a request, since they too are often used to document vendor-defined 1119 extensions. 1120 If the UAC wishes to insist that a UAS understand an extension that the UAC will apply to the request 1121 in order to process the request, it must insert a Require header field into the request listing the option tag 1122 for that extension. If the UAC wishes to apply an extension to the request and insist that any proxies that are 1123 traversed understand that extension, it must insert a Proxy-Require header field into the request listing the 1124 option tag for that extension. 1125 As with the Supported header field, the option tags in the Require and Proxy-Require header fields 1126 must only refer to extensions defined in standards-track RFCs.

1127 8.1.1.10 Additional Message Components After a new request has been created, and the header fields 1128 described above have been properly constructed, any additional optional header fields are added, as are any 1129 header fields specific to the method. 1130 SIP requests may contain a MIME-encoded message-body. Regardless of the type of body that a request 1131 contains, certain header fields must be formulated to characterize the contents of the body. For further 1132 information on these header fields, see Sections 20.11 through 20.15.

1133 8.1.2 Sending the Request

1134 The destination for the request is then computed. Unless there is local policy specifying otherwise, then 1135 the destination must be determined by applying the DNS procedures described in [4] as follows. If the 1136 first element in the route set indicated a strict router (resulting in forming the request as described in Sec-1137 tion 12.2.1.1), the procedures must be applied to the Request-URI of the request. Otherwise, the pro-1138 cedures are applied to the first Route header field value in the request (if one exists), or to the request’s 1139 Request-URI if there is no Route header field present. These procedures yield an ordered set of address, 1140 port, and transports to attempt. 1141 Local policy may specify an alternate set of destinations to attempt. If the Request-URI contains a 1142 SIPS URI, any alternate destinations must be contacted with TLS. Beyond that, there are no restrictions on 1143 the alternate destinations if the request contains no Route header field. This provides a simple alternative 1144 to a pre-existing route set as a way to specify an outbound proxy. However, that approach for configuring 1145 an outbound proxy is not recommended; a pre-existing route set with a single URI should be used 1146 instead. If the request contains a Route header field, the request should be sent to the locations derived 1147 from its topmost value, but may be sent to any server that the UA is certain will honor the Route and 1148 Request-URI policies specified in this document (as opposed to those in RFC 2543). In particular, a UAC 1149 configured with an outbound proxy should attempt to send the request to the location indicated in the first 1150 Route header field value instead of adopting the policy of sending all messages to the outbound proxy.

1151 This ensures that outbound proxies choosing not to add Record-Route header field values will drop out of the 1152 path of subsequent requests. It allows endpoints that cannot resolve the first Route URI to delegate that task to an 1153 outbound proxy.

1154 The UAC should follow the procedures defined in [4] for stateful elements, trying each address until 1155 a server is contacted. Each try constitutes a new transaction, and therefore each carries a different topmost 1156 Via header field value with a new branch parameter. Furthermore, the transport value in the Via header field 1157 is set to whatever transport was determined for the target server.

1158 8.1.3 Processing Responses

1159 Responses are first processed by the transport layer and then passed up to the transaction layer. The trans-1160 action layer performs its processing and then passes the response up to the TU. The majority of response 1161 processing in the TU is method specific. However, there are some general behaviors independent of the 1162 method.

1163 8.1.3.1 Transaction Layer Errors In some cases, the response returned by the transaction layer will not 1164 be a SIP message, but rather a transaction layer error. When a timeout error is received from the transaction 1165 layer, it must be treated as if a 408 (Request Timeout) status code has been received. If a fatal transport 1166 error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in 1167 TCP), the condition must be treated as a 503 (Service Unavailable) status code.

1168 8.1.3.2 Unrecognized Responses A UAC must treat any final response it does not recognize as being 1169 equivalent to the x00 response code of that class, and must be able to process the x00 response code for 1170 all classes. For example, if a UAC receives an unrecognized response code of 431, it can safely assume that 1171 there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) 1172 response code. A UAC must treat any provisional response different than 100 that it does not recognize as 1173 183 (Session Progress). A UAC must be able to process 100 and 183 responses.

1174 8.1.3.3 Vias If more than one Via header field value is present in a response, the UAC should discard 1175 the message.

1176 The presence of additional Via header field values that precede the originator of the request suggests that the 1177 message was misrouted or possibly corrupted.

1178 8.1.3.4 Processing 3xx Responses Upon receipt of a redirection response (for example, a 301 response 1179 status code), clients should use the URI(s) in the Contact header field to formulate one or more new 1180 requests based on the redirected request. If the original request had a SIPS URI in the Request-URI, the 1181 client must discard any Contact header fields which do not contain SIPS URIs. 1182 If more than one URI is present in Contact header field within the 3xx response, the UA must determine 1183 an order in which these contact addresses should be processed. UAs must consult the “q” parameter value 1184 of the Contact header field value (see Section 20.10) if available. Contact addresses must be ordered from 1185 highest qvalue to lowest. If no qvalue is present, a contact address is considered to have a qvalue of 1.0. 1186 Note that two or more contact addresses might have an equal qvalue - these URIs are eligible to be tried in 1187 parallel. 1188 Once an ordered list has been established, UACs may remove from the list any entry that they do not 1189 want to try. After this, UACs must try to contact each URI in the ordered list in turn by sending a request 1190 for a single contact address at a time, continuing down the ordered list only when a final response to the 1191 current request has been received. If there are contact addresses with an equal qvalue, the UAC may decide 1192 randomly on an order in which to process these addresses, or it may attempt to process contact addresses of 1193 equal qvalue in parallel. 1194 Note that, for example, the UAC may effectively divide the ordered list into groups, processing the 1195 groups serially and processing the destinations in each group in parallel. 1196 If contacting an address in the list results in a failure, as defined in the next paragraph, the element moves 1197 to the next address in the list, until the list is exhausted. If the list is exhausted, then the request has failed. 1198 Failures should be detected through failure response codes (codes greater than 399); for network errors 1199 the client transaction will report any transport layer failures to the transaction user. Note that some response 1200 codes (detailed in 8.1.3.5) indicate that the request can be retried; requests that are reattempted should not 1201 be considered failures. 1202 When a failure for a particular contact address is received, the client should try the next contact 1203 address. This will involve creating a new client transaction to deliver a new request.

1204 In order to create a request based on a contact address in a 3xx response, a UAC must copy the entire 1205 URI from the Contact header field value into the Request-URI, except for the “method-param” and 1206 “header” URI parameters (see Section 19.1.1 for a definition of these parameters). It uses the “header” 1207 parameters to create header field values for the new request, overwriting header field values associated with 1208 the redirected request in accordance with the guidelines in Section 19.1.5. 1209 Note that in some instances, header fields that have been communicated in the contact address may 1210 instead append to existing request header fields in the original redirected request. As a general rule, if the 1211 header field can accept a comma-separated list of values, then the new header field value may be appended 1212 to any existing values in the original redirected request. If the header field does not accept multiple values, 1213 the value in the original redirected request may be overwritten by the header field value communicated in 1214 the contact address. For example, if a contact address is returned with the following value:

1215 sip:user@host?Subject=foo&Call-Info=<http://www.foo.com>

1216 Then any Subject header field in the original redirected request is overwritten, but the HTTP URL is 1217 merely appended to any existing Call-Info header field values. 1218 It is recommended that the UAC reuse the same To, From, and Call-ID used in the original redirected 1219 request, but the UAC may also choose to update the Call-ID header field value for new requests, for example. 1220 Finally, once the new request has been constructed, it is sent using a new client transaction, and therefore 1221 must have a new branch ID in the top Via field as discussed in Section 8.1.1.7. 1222 In all other respects, requests sent upon receipt of a redirect response should re-use the header fields 1223 and bodies of the original request. 1224 Redirections can result in requests that are in turn redirected. For example, if an initial 3xx response 1225 contains multiple contacts, and the retry of the request to the first of these contacts is in turn redirected, 1226 UACs must reconcile the two resulting sets of URIs. UAs must combine the two sets of contact addresses 1227 and recompute the ordering of the elements following the steps described above. However, if any two URIs 1228 in the set are equivalent, the less preferred URI, meaning the URI with the numerically highest “q” value, 1229 must be discarded. 1230 In some instances, Contact header field values may be cached at UAC temporarily or permanently 1231 depending on the status code received and the presence of an expiration interval; see Sections 21.3.2 and 1232 21.3.3.

1233 8.1.3.5 Processing 4xx Responses Certain 4xx response codes require specific UA processing, indepen-1234 dent of the method. 1235 If a 401 (Unauthorized) or 407 (Proxy Authentication Required) response is received, the UAC should 1236 follow the authorization procedures of Section 22.2 and Section 22.3 to retry the request with credentials. 1237 If a 413 (Request Entity Too Large) response is received (Section 21.4.11), the request contained a body 1238 that was longer than the UAS was willing to accept. If possible, the UAC should retry the request, either 1239 omitting the body or using one of a smaller length. 1240 If a 415 (Unsupported Media Type) response is received (Section 21.4.13), the request contained media 1241 types not supported by the UAS. The UAC should retry sending the request, this time only using content 1242 with types listed in the Accept header field in the response, with encodings listed in the Accept-Encoding 1243 header field in the response, and with languages listed in the Accept-Language in the response. 1244 If a 416 (Unsupported URI Scheme) response is received (Section 21.4.14), the Request-URI used a 1245 URI scheme not supported by the server. The client should retry the request, this time, using a SIP URI.

1246 If a 420 (Bad Extension) response is received (Section 21.4.15), the request contained a Require or 1247 Proxy-Require header field listing an option-tag for a feature not supported by a proxy or UAS. The UAC 1248 should retry the request, this time omitting any extensions listed in the Unsupported header field in the 1249 response. 1250 In all of the above cases, the request is retried by creating a new request with the appropriate modifica-1251 tions. This new request should have the same value of the Call-ID, To, and From of the previous request, 1252 but the CSeq should contain a new sequence number that is one higher than the previous. 1253 With other 4xx responses, including those yet to be defined, a retry may or may not be possible depend-1254 ing on the method and the use case.

1255 8.2 UAS Behavior

1256 When a request outside of a dialog is processed by a UAS, there is a set of processing rules that are followed, 1257 independent of the method. Section 12 gives guidance on how a UAS can tell whether a request is inside or 1258 outside of a dialog. 1259 Note that request processing is atomic. If a request is accepted, all state changes associated with it must 1260 be performed. If it is rejected, all state changes must not be performed. 1261 UASs should process the requests in the order of the steps that follow in this section (that is, starting 1262 with authentication, then inspecting the method, the header fields, and so on throughout the remainder of 1263 this section).

1264 8.2.1 Method Inspection

1265 Once a request is authenticated (or authentication is skipped), the UAS must inspect the method of the 1266 request. If the UAS recognizes but does not support the method of a request, it must generate a 405 1267 (Method Not Allowed) response. Procedures for generating responses are described in Section 8.2.6. The 1268 UAS must also add an Allow header field to the 405 (Method Not Allowed) response. The Allow header 1269 field must list the set of methods supported by the UAS generating the message. The Allow header field is 1270 presented in Section 20.5. 1271 If the method is one supported by the server, processing continues.

1272 8.2.2 Header Inspection

1273 If a UAS does not understand a header field in a request (that is, the header field is not defined in this spec-1274 ification or in any supported extension), the server must ignore that header field and continue processing 1275 the message. A UAS should ignore any malformed header fields that are not necessary for processing 1276 requests.

1277 8.2.2.1 To and Request-URI The To header field identifies the original recipient of the request desig-1278 nated by the user identified in the From field. The original recipient may or may not be the UAS processing 1279 the request, due to call forwarding or other proxy operations. A UAS may apply any policy it wishes to 1280 determine whether to accept requests when the To header field is not the identity of the UAS. However, it is 1281 recommended that a UAS accept requests even if they do not recognize the URI scheme (for example, a 1282 tel: URI) in the To header field, or if the To header field does not address a known or current user of this 1283 UAS. If, on the other hand, the UAS decides to reject the request, it should generate a response with a 403 1284 (Forbidden) status code and pass it to the server transaction for transmission.

1285 However, the Request-URI identifies the UAS that is to process the request. If the Request-URI uses 1286 a scheme not supported by the UAS, it should reject the request with a 416 (Unsupported URI Scheme) 1287 response. If the Request-URI does not identify an address that the UAS is willing to accept requests for, 1288 it should reject the request with a 404 (Not Found) response. Typically, a UA that uses the REGISTER 1289 method to bind its address-of-record to a specific contact address will see requests whose Request-URI 1290 equals that contact address. Other potential sources of received Request-URIs include the Contact header 1291 fields of requests and responses sent by the UA that establish or refresh dialogs.

1292 8.2.2.2 Merged Requests If the request has no tag in the To header field, the UAS core must check 1293 the request against ongoing transactions. If the To tag, From tag, Call-ID, CSeq exactly match (including 1294 tags) those associated with an ongoing transaction, but the branch-ID in the topmost Via does not match , 1295 the UAS core should generate a 482 (Loop Detected) response and pass it to the server transaction.

1296 The same request has arrived at the UAS more than once, following different paths, most likely due to forking. 1297 The UAS processes the first such request received and responds with a 482 (Loop Detected) to the rest of them.

1298 8.2.2.3 Require Assuming the UAS decides that it is the proper element to process the request, it ex-1299 amines the Require header field, if present. 1300 The Require header field is used by a UAC to tell a UAS about SIP extensions that the UAC expects 1301 the UAS to support in order to process the request properly. Its format is described in Section 20.32. If a 1302 UAS does not understand an option-tag listed in a Require header field, it must respond by generating a 1303 response with status code 420 (Bad Extension). The UAS must add an Unsupported header field, and list 1304 in it those options it does not understand amongst those in the Require header field of the request. 1305 Note that Require and Proxy-Require must not be used in a SIP CANCEL request, or in an ACK 1306 request sent for a non-2xx response. These header fields must be ignored if they are present in these 1307 requests. 1308 An ACK request for a 2xx response must contain only those Require and Proxy-Require values that 1309 were present in the initial request. 1310 Example:

1311 UAC->UAS:   INVITE sip:watson@bell-telephone.com SIP/2.0
1312  Require: 100rel

1313 1314

1315 UAS->UAC:   SIP/2.0 420 Bad Extension
1316  Unsupported: 100rel

1317 This behavior ensures that the client-server interaction will proceed without delay when all options are under-1318 stood by both sides, and only slow down if options are not understood (as in the example above). For a well-matched 1319 client-server pair, the interaction proceeds quickly, saving a round-trip often required by negotiation mechanisms. 1320 In addition, it also removes ambiguity when the client requires features that the server does not understand. Some 1321 features, such as call handling fields, are only of interest to end systems.

1322 8.2.3 Content Processing

1323 Assuming the UAS understands any extensions required by the client, the UAS examines the body of the 1324 message, and the header fields that describe it. If there are any bodies whose type (indicated by the Content-1325 Type), language (indicated by the Content-Language) or encoding (indicated by the Content-Encoding)

1326 are not understood, and that body part is not optional (as indicated by the Content-Disposition header 1327 field), the UAS must reject the request with a 415 (Unsupported Media Type) response. The response must 1328 contain an Accept header field listing the types of all bodies it understands, in the event the request contained 1329 bodies of types not supported by the UAS. If the request contained content encodings not understood by the 1330 UAS, the response must contain an Accept-Encoding header field listing the encodings understood by 1331 the UAS. If the request contained content with languages not understood by the UAS, the response must 1332 contain an Accept-Language header field indicating the languages understood by the UAS. Beyond these 1333 checks, body handling depends on the method and type. For further information on the processing of 1334 content-specific header fields, see Section 7.4 as well as Section 20.11 through 20.15.

1335 8.2.4 Applying Extensions

1336 A UAS that wishes to apply some extension when generating the response must not do so unless support 1337 for that extension is indicated in the Supported header field in the request. If the desired extension is not 1338 supported, the server should rely only on baseline SIP and any other extensions supported by the client. In 1339 rare circumstances, where the server cannot process the request without the extension, the server may send 1340 a 421 (Extension Required) response. This response indicates that the proper response cannot be generated 1341 without support of a specific extension. The needed extension(s) must be included in a Require header 1342 field in the response. This behavior is not recommended, as it will generally break interoperability. 1343 Any extensions applied to a non-421 response must be listed in a Require header field included in the 1344 response. Of course, the server must not apply extensions not listed in the Supported header field in the 1345 request. As a result of this, the Require header field in a response will only ever contain option tags defined 1346 in standards-track RFCs.

1347 8.2.5 Processing the Request

1348 Assuming all of the checks in the previous subsections are passed, the UAS processing becomes method-1349 specific. Section 10 covers the REGISTER request, section 11 covers the OPTIONS request, section 13 1350 covers the INVITE request, and section 15 covers the BYE request.

1351 8.2.6 Generating the Response

1352 When a UAS wishes to construct a response to a request, it follows the general procedures detailed in the 1353 following subsections. Additional behaviors specific to the response code in question, which are not detailed 1354 in this section, may also be required. 1355 Once all procedures associated with the creation of a response have been completed, the UAS hands the 1356 response back to the server transaction from which it received the request.

1357 8.2.6.1 Sending a Provisional Response One largely non-method-specific guideline for the generation 1358 of responses is that UASs should not issue a provisional response for a non-INVITE request. Rather, 1359 UASs should generate a final response to a non-INVITE request as soon as possible. 1360 When a 100 (Trying) response is generated, any Timestamp header field present in the request must be 1361 copied into this 100 (Trying) response. If there is a delay in generating the response, the UAS should add 1362 a delay value into the Timestamp value in the response. This value must contain the difference between 1363 time of sending of the response and receipt of the request, measured in seconds.

1364 8.2.6.2 Headers and Tags The From field of the response must equal the From header field of the 1365 request. The Call-ID header field of the response must equal the Call-ID header field of the request. The 1366 CSeq header field of the response must equal the CSeq field of the request. The Via header field values in 1367 the response must equal the Via header field values in the request and must maintain the same ordering. 1368 If a request contained a To tag in the request, the To header field in the response must equal that of 1369 the request. However, if the To header field in the request did not contain a tag, the URI in the To header 1370 field in the response must equal the URI in the To header field; additionally, the UAS must add a tag to 1371 the To header field in the response (with the exception of the 100 (Trying) response, in which a tag may be 1372 present). This serves to identify the UAS that is responding, possibly resulting in a component of a dialog 1373 ID. The same tag must be used for all responses to that request, both final and provisional (again excepting 1374 the 100 (Trying)). Procedures for generation of tags are defined in Section 19.3.

1375 8.2.7 Stateless UAS Behavior

1376 A stateless UAS is a UAS that does not maintain transaction state. It replies to requests normally, but 1377 discards any state that would ordinarily be retained by a UAS after a response has been sent. If a stateless 1378 UAS receives a retransmission of a request, it regenerates the response and resends it, just as if it were 1379 replying to the first instance of the request. Stateless UASs do not use a transaction layer; they receive 1380 requests directly from the transport layer and send responses directly to the transport layer. 1381 The stateless UAS role is needed primarily to handle unauthenticated requests for which a challenge 1382 response is issued. If unauthenticated requests were handled statefully, then malicious floods of unau-1383 thenticated requests could create massive amounts of transaction state that might slow or completely halt 1384 call processing in a UAS, effectively creating a denial of service condition; for more information see Sec-1385 tion 26.1.5. 1386 The most important behaviors of a stateless UAS are the following:

1387 • A stateless UAS must not send provisional (1xx) responses.

1388 • A stateless UAS must not retransmit responses.

1389 • A stateless UAS must ignore ACK requests.

1390 • A stateless UAS must ignore CANCEL requests.

1391 • To header tags must be generated for responses in a stateless manner - in a manner that will generate 1392 the same tag for the same request consistently. For information on tag construction see Section 19.3.

1393 In all other respects, a stateless UAS behaves in the same manner as a stateful UAS. A UAS can operate 1394 in either a stateful or stateless mode for each new request.

1395 8.3 Redirect Servers

1396 In some architectures it may be desirable to reduce the processing load on proxy servers that are responsible 1397 for routing requests, and improve signaling path robustness, by relying on redirection. Redirection allows 1398 servers to push routing information for a request back in a response to the client, thereby taking themselves 1399 out of the loop of further messaging for this transaction while still aiding in locating the target of the request. 1400 When the originator of the request receives the redirection, it will send a new request based on the URI(s)

1401 it has received. By propagating URIs from the core of the network to its edges, redirection allows for 1402 considerable network scalability. 1403 A redirect server is logically constituted of a server transaction layer and a transaction user that has 1404 access to a location service of some kind (see Section 10 for more on registrars and location services). This 1405 location service is effectively a database containing mappings between a single URI and a set of one or more 1406 alternative locations at which the target of that URI can be found. 1407 A redirect server does not issue any SIP requests of its own. After receiving a request other than CAN-1408 CEL, the server either refuses the request or gathers the list of alternative locations from the location service 1409 and returns a final response of class 3xx. For well-formed CANCEL requests, it should return a 2xx re-1410 sponse. This response ends the SIP transaction. The redirect server maintains transaction state for an entire 1411 SIP transaction. It is the responsibility of clients to detect forwarding loops between redirect servers. 1412 When a redirect server returns a 3xx response to a request, it populates the list of (one or more) alter-1413 native locations into the Contact header field. An “expires” parameter to the Contact header field values 1414 may also be supplied to indicate the lifetime of the Contact data. 1415 The Contact header field contains URIs giving the new locations or user names to try, or may simply 1416 specify additional transport parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily) response 1417 may also give the same location and username that was targeted by the initial request but specify additional 1418 transport parameters such as a different server or multicast address to try, or a change of SIP transport from 1419 UDP to TCP or vice versa. 1420 However, redirect servers must not redirect a request to a URI equal to the one in the Request-URI; 1421 instead, provided that the URI does not point to itself, the redirect server should proxy the request to the 1422 destination URI.

1423 If a client is using an outbound proxy, and that proxy actually redirects requests, a potential arises for infinite 1424 redirection loops.

1425 Note that a Contact header field value may also refer to a different resource than the one originally 1426 called. For example, a SIP call connected to PSTN gateway may need to deliver a special informational 1427 announcement such as “The number you have dialed has been changed.” 1428 A Contact response header field can contain any suitable URI indicating where the called party can be 1429 reached, not limited to SIP URIs. For example, it could contain URIs for phones, fax, or irc (if they were 1430 defined) or a mailto: (RFC 2368, [31]) URL. However, if the Request-URI of the request contained a SIPS 1431 URI, the Contact header fields in the 3xx response must all be SIPS URIs. 1432 The “expires” parameter of a Contact header field value indicates how long the URI is valid. The value 1433 of the parameter is a number indicating seconds. If this parameter is not provided, the value of the Expires 1434 header field determines how long the URI is valid. Malformed values should be treated as equivalent to 1435 3600.

1436 This provides a modest level of backwards compatibility with RFC 2543, which allowed absolute times in this 1437 header field. If an absolute time is received, it will be treated as malformed, and then default to 3600.

1438 Redirect servers must ignore features that are not understood (including unrecognized header fields, any 1439 unknown option tags in Require, or even method names) and proceed with the redirection of the request in 1440 question.

1441 9 Canceling a Request

1442 The previous section has discussed general UA behavior for generating requests and processing responses 1443 for requests of all methods. In this section, we discuss a general purpose method, called CANCEL.

1444 The CANCEL request, as the name implies, is used to cancel a previous request sent by a client. Specif-1445 ically, it asks the UAS to cease processing the request and to generate an error response to that request. 1446 CANCEL has no effect on a request to which a UAS has already given a final response. Because of this, 1447 it is most useful to CANCEL requests to which it can take a server long time to respond. For this reason, 1448 CANCEL is best for INVITE requests, which can take a long time to generate a response. In that usage, 1449 a UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would “stop 1450 ringing”, and then respond to the INVITE with a specific error response (a 487). 1451 CANCEL requests can be constructed and sent by both proxies and user agent clients. Section 15 1452 discusses under what conditions a UAC would CANCEL an INVITE request, and Section 16.10 discusses 1453 proxy usage of CANCEL. 1454 A stateful proxy responds to a CANCEL, rather than simply forwarding a response it would receive 1455 from a downstream element. For that reason, CANCEL is referred to as a “hop-by-hop” request, since it is 1456 responded to at each stateful proxy hop.

1457 9.1 Client Behavior

1458 A CANCEL request should not be sent to cancel a request other than INVITE.

1459 Since requests other than INVITE are responded to immediately, sending a CANCEL for a non-INVITE request 1460 would always create a race condition.

1461 The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, 1462 the numeric part of CSeq, and From header fields in the CANCEL request must be identical to those in 1463 the request being cancelled, including tags. A CANCEL constructed by a client must have only a single 1464 Via header field value matching the top Via value in the request being cancelled. Using the same values 1465 for these header fields allows the CANCEL to be matched with the request it cancels (Section 9.2 indicates 1466 how such matching occurs). However, the method part of the CSeq header field must have a value of 1467 CANCEL. This allows it to be identified and processed as a transaction in its own right (See Section 17). 1468 If the request being cancelled contains a Route header field, the CANCEL request must include that 1469 Route header field’s values.

1470 This is needed so that stateless proxies are able to route CANCEL requests properly.

1471 The CANCEL request must not contain any Require or Proxy-Require header fields. 1472 Once the CANCEL is constructed, the client should check whether it has received any response (pro-1473 visional or final) for the request being cancelled (herein referred to as the ”original request”). 1474 If no provisional response has been received, the CANCEL request must not be sent; rather, the client 1475 must wait for the arrival of a provisional response before sending the request. If the original request has 1476 generated a final response, the CANCEL should not be sent, as it is an effective no-op, since CANCEL 1477 has no effect on requests that have already generated a final response. When the client decides to send the 1478 CANCEL, it creates a client transaction for the CANCEL and passes it the CANCEL request along with 1479 the destination address, port, and transport. The destination address, port, and transport for the CANCEL 1480 must be identical to those used to send the original request.

1481 If it was allowed to send the CANCEL before receiving a response for the previous request, the server could 1482 receive the CANCEL before the original request.

1483 Note that both the transaction corresponding to the original request and the CANCEL transaction will 1484 complete independently. However, a UAC canceling a request cannot rely on receiving a 487 (Request 1485 Terminated) response for the original request, as an RFC 2543-compliant UAS will not generate such a 1486 response. If there is no final response for the original request in 64*T1 seconds (T1 is defined in Section 1487 17.1.1.1), the client should then consider the original transaction cancelled and should destroy the client 1488 transaction handling the original request.

1489 9.2 Server Behavior

1490 The CANCEL method requests that the TU at the server side cancel a pending transaction. The TU deter-1491 mines the transaction to be cancelled by taking the CANCEL request, and then assuming that the request 1492 method is anything but CANCEL and applying the transaction matching procedures of Section 17.2.3. The 1493 matching transaction is the one to be cancelled. 1494 The processing of a CANCEL request at a server depends on the type of server. A stateless proxy will 1495 forward it, a stateful proxy might respond to it and generate some CANCEL requests of its own, and a UAS 1496 will respond to it. See Section 16.10 for proxy treatment of CANCEL. 1497 A UAS first processes the CANCEL request according to the general UAS processing described in 1498 Section 8.2. However, since CANCEL requests are hop-by-hop and cannot be resubmitted, they cannot be 1499 challenged by the server in order to get proper credentials in an Authorization header field. Note also that 1500 CANCEL requests do not contain a Require header field. 1501 If the UAS did not find a matching transaction for the CANCEL according to the procedure above, it 1502 should respond to the CANCEL with a 481 (Call Leg/Transaction Does Not Exist). If the transaction 1503 for the original request still exists, the behavior of the UAS on receiving a CANCEL request depends on 1504 whether it has already sent a final response for the original request. If it has, the CANCEL request has no 1505 effect on the processing of the original request, no effect on any session state, and no effect on the responses 1506 generated for the original request. If the UAS has not issued a final response for the original request, its 1507 behavior depends on the method of the original request. If the original request was an INVITE, the UAS 1508 should immediately respond to the INVITE with a 487 (Request Terminated). The behavior upon reception 1509 of a CANCEL request for any other method defined in this specification is effectively no-op. 1510 Regardless of the method of the original request, as long as the CANCEL matched an existing transac-1511 tion, the UAS answers the CANCEL request itself with a 200 (OK) response. This response is constructed 1512 following the procedures described in Section 8.2.6 noting that the To tag of the response to the CANCEL 1513 and the To tag in the response to the original request should be the same. The response to CANCEL is 1514 passed to the server transaction for transmission.

1515 10 Registrations

1516 10.1 Overview

1517 SIP offers a discovery capability. If a user wants to initiate a session with another user, SIP must discover the 1518 current host(s) at which the destination user is reachable. This discovery process is frequently accomplished 1519 by SIP network elements such as proxy servers and redirect servers which are responsible for receiving a 1520 request, determining where to send it based on knowledge of the location of the user, and then sending it 1521 there. To do this, SIP network elements consult an abstract service known as a location service, which 1522 provides address bindings for a particular domain. These address bindings map an incoming SIP or SIPS 1523 URI, sip:bob@biloxi.com, for example, to one or more URIs that are somehow “closer” to the desired 1524 user, sip:bob@engineering.biloxi.com, for example. Ultimately, a proxy will consult a location 1525 service that maps a received URI to the user agent(s) at which the desired recipient is currently residing. 1526 Registration creates bindings in a location service for a particular domain that associate an address-of-1527 record URI with one or more contact addresses. Thus, when a proxy for that domain receives a request whose 1528 Request-URI matches the address-of-record, the proxy will forward the request to the contact addresses 1529 registered to that address-of-record. Generally, it only makes sense to register an address-of-record at a 1530 domain’s location service when requests for that address-of-record would be routed to that domain. In 1531 most cases, this means that the domain of the registration will need to match the domain in the URI of the 1532 address-of-record. 1533 There are many ways by which the contents of the location service can be established. One way is 1534 administratively. In the above example, Bob is known to be a member of the engineering department through 1535 access to a corporate database. However, SIP provides a mechanism for a UA to create a binding explicitly. 1536 This mechanism is known as registration. 1537 Registration entails sending a REGISTER request to a special type of UAS known as a registrar. A 1538 registrar acts as the front end to the location service for a domain, reading and writing mappings based on 1539 the contents of REGISTER requests. This location service is then typically consulted by a proxy server that 1540 is responsible for routing requests for that domain. 1541 An illustration of the overall registration process is given in 2. Note that the registrar and proxy server 1542 are logical roles that can be played by a single device in a network; for purposes of clarity the two are 1543 separated in this illustration. Also note that UAs may send requests through a proxy server in order to reach 1544 a registrar if the two are separate elements. 1545 SIP does not mandate a particular mechanism for implementing the location service. The only require-1546 ment is that a registrar for some domain must be able to read and write data to the location service, and 1547 a proxy or redirect server for that domain must be capable of reading that same data. A registrar may be 1548 co-located with a particular SIP proxy server for the same domain.

1549 10.2 Constructing the REGISTER Request

1550 REGISTER requests add, remove, and query bindings. A REGISTER request can add a new binding 1551 between an address-of-record and one or more contact addresses. Registration on behalf of a particular 1552 address-of-record can be performed by a suitably authorized third party. A client can also remove previous 1553 bindings or query to determine which bindings are currently in place for an address-of-record. 1554 Except as noted, the construction of the REGISTER request and the behavior of clients sending a 1555 REGISTER request is identical to the general UAC behavior described in Section 8.1 and Section 17.1. 1556 A REGISTER request does not establish a dialog. A UAC may include a Route header field in a 1557 REGISTER request based on a pre-existing route set as described in Section 8.1. The Record-Route 1558 header field has no meaning in REGISTER requests or responses, and must be ignored if present. In 1559 particular, the UAC must not create a new route set based on the presence or absence of a Record-Route 1560 header field in any response to a REGISTER request. 1561 The following header fields, except Contact, must be included in a REGISTER request. A Contact 1562 header field may be included:

1563 Request-URI: The Request-URI names the domain of the location service for which the registration is 1564 meant (for example, “sip:chicago.com”). The “userinfo” and “@” components of the SIP URI must 1565 not be present.

1566 To: The To header field contains the address of record whose registration is to be created, queried, or 1567 modified. The To header field and the Request-URI field typically differ, as the former contains a 1568 user name. This address-of-record must be a SIP URI or SIPS URI.

Figure 2: REGISTER example

1569 From: The From header field contains the address-of-record of the person responsible for the registration. 1570 The value is the same as the To header field unless the request is a third-party registration.

1571 Call-ID: All registrations from a UAC should use the same Call-ID header field value for registrations 1572 sent to a particular registrar.

1573 If the same client were to use different Call-ID values, a registrar could not detect whether a delayed 1574 REGISTER request might have arrived out of order.

1575 CSeq: The CSeq value guarantees proper ordering of REGISTER requests. A UA must increment the 1576 CSeq value by one for each REGISTER request with the same Call-ID.

1577 Contact: REGISTER requests may contain a Contact header field with zero or more values containing 1578 address bindings.

1579 UAs must not send a new registration (that is, containing new Contact header field values, as opposed 1580 to a retransmission) until they have received a final response from the registrar for the previous one or the 1581 previous REGISTER request has timed out. 1582 The following Contact header parameters have a special meaning in REGISTER requests:

1583 action: The “action” parameter from RFC 2543 has been deprecated. UACs should not use the 1584 “action” parameter.

1585 expires: The “expires” parameter indicates how long the UA would like the binding to be valid. The value 1586 is a number indicating seconds. If this parameter is not provided, the value of the Expires header field 1587 is used instead. Implementations may treat values larger than 2**32-1 (4294967295 seconds or 136 1588 years) as equivalent to 2**32-1. Malformed values should be treated as equivalent to 3600.

1589 10.2.1 Adding Bindings

1590 The REGISTER request sent to a registrar includes the contact address(es) to which SIP requests for the 1591 address-of-record should be forwarded. The address-of-record is included in the To header field of the 1592 REGISTER request. 1593 The Contact header field values of the request typically consist of SIP or SIPS URIs that identify 1594 particular SIP endpoints (for example, “sip:carol@cube2214a.chicago.com”), but they may use any URI 1595 scheme. A SIP UA can choose to register telephone numbers (with the tel URL, [9]) or email addresses 1596 (with a mailto URL, [31]) as Contacts for an address-of-record, for example. 1597 For example, Carol, with address-of-record “sip:carol@chicago.com”, would register with the SIP reg-1598 istrar of the domain chicago.com. Her registrations would then be used by a proxy server in the chicago.com 1599 domain to route requests for Carol’s address-of-record to her SIP endpoint. 1600 Once a client has established bindings at a registrar, it may send subsequent registrations containing 1601 new bindings or modifications to existing bindings as necessary. The 2xx response to the REGISTER 1602 request will contain, in a Contact header field, a complete list of bindings that have been registered for this 1603 address-of-record at this registrar. 1604 If the address-of-record in the To header field of a REGISTER request is a SIPS URI, then any Contact 1605 header field values in the request must also be a SIPS URIs. 1606 Registrations do not need to update all bindings. Typically, a UA only updates its own contact addresses.

1607 10.2.1.1 Setting the Expiration Interval of Contact Addresses When a client sends a REGISTER 1608 request, it may suggest an expiration interval that indicates how long the client would like the registration 1609 to be valid. (As described in Section 10.3, the registrar selects the actual time interval based on its local 1610 policy.) 1611 There are two ways in which a client can suggest an expiration interval for a binding: through an 1612 Expires header field or an “expires” Contact header parameter. The latter allows expiration intervals to 1613 be suggested on a per-binding basis when more than one binding is given in a single REGISTER request, 1614 whereas the former suggests an expiration interval for all Contact header field values that do not contain 1615 the “expires” parameter. 1616 If neither mechanism for expressing a suggested expiration time is present in a REGISTER, a default 1617 suggestion of one hour should be assumed.

1618 10.2.1.2 Preferences among Contact Addresses If more than one Contact is sent in a REGISTER 1619 request, the registering UA intends to associate all of the URIs in these Contact header field values with the 1620 address-of-record present in the To field. This list can be prioritized with the “q” parameter in the Contact 1621 header field. The “q” parameter indicates a relative preference for the particular Contact header field value 1622 compared to other bindings present in this REGISTER message or existing within the location service of 1623 the registrar. Section 16.6 describes how a proxy server uses this preference indication.

1624 10.2.2 Removing Bindings

1625 Registrations are soft state and expire unless refreshed, but can also be explicitly removed. A client can 1626 attempt to influence the expiration interval selected by the registrar as described in Section 10.2.1. A UA 1627 requests the immediate removal of a binding by specifying an expiration interval of “0” for that contact 1628 address in a REGISTER request. UAs should support this mechanism so that bindings can be removed 1629 before their expiration interval has passed. 1630 The REGISTER-specific Contact header field value of “*” applies to all registrations, but it must not 1631 be used unless the Expires header field is present with a value of “0”.

1632 Use of the “*” Contact header field value allows a registering UA to remove all of its bindings without knowing 1633 their precise values.

1634 10.2.3 Fetching Bindings

1635 A success response to any REGISTER request contains the complete list of existing bindings, regardless of 1636 whether the request contained a Contact header field. If no Contact header field is present in a REGISTER 1637 request, the list of bindings is left unchanged.

1638 10.2.4 Refreshing Bindings

1639 Each UA is responsible for refreshing the bindings that it has previously established. A UA should not 1640 refresh bindings set up by other UAs. 1641 The 200 (OK) response from the registrar contains a list of Contact fields enumerating all current 1642 bindings. The UA compares each contact address to see if it created the contact address, using comparison 1643 rules in Section 19.1.4. If so, it updates the expiration time interval according to the expires parameter or, 1644 if absent, the Expires field value. The UA then issues a REGISTER request for each of its bindings before 1645 the expiration interval has elapsed. It may combine several updates into one REGISTER request. 1646 A UA should use the same Call-ID for all registrations during a single boot cycle. Registration re-1647 freshes should be sent to the same network address as the original registration, unless redirected.

1648 10.2.5 Setting the Internal Clock

1649 If the response for a REGISTER request contains a Date header field, the client may use this header field 1650 to learn the current time in order to set any internal clocks.

1651 10.2.6 Discovering a Registrar

1652 UAs can use three ways to determine the address to which to send registrations: by configuration, using the 1653 address-of-record, and multicast. A UA can be configured, in ways beyond the scope of this specification, 1654 with a registrar address. If there is no configured registrar address, the UA should use the host part of the 1655 address-of-record as the Request-URI and address the request there, using the normal SIP server location 1656 mechanisms [4]. For example, the UA for the user “sip:carol@chicago.com” addresses the REGISTER 1657 request to “sip:chicago.com”. 1658 Finally, a UA can be configured to use multicast. Multicast registrations are addressed to the well-known 1659 “all SIP servers” multicast address “sip.mcast.net” (224.0.1.75 for IPv4). No well-known IPv6 multicast 1660 address has been allocated; such an allocation will be documented separately when needed. SIP UAs may 1661 listen to that address and use it to become aware of the location of other local users (see [32]); however, they 1662 do not respond to the request.

1663 Multicast registration may be inappropriate in some environments, for example, if multiple businesses share the 1664 same local area network.

1665 10.2.7 Transmitting a Request

1666 Once the REGISTER method has been constructed, and the destination of the message identified, UACs 1667 follow the procedures described in Section 8.1.2 to hand off the REGISTER to the transaction layer. 1668 If the transaction layer returns a timeout error because the REGISTER yielded no response, the UAC 1669 should not immediately re-attempt a registration to the same registrar.

1670 An immediate re-attempt is likely to also timeout. Waiting some reasonable time interval for the conditions 1671 causing the timeout to be corrected reduces unnecessary load on the network. No specific interval is mandated.

1672 10.2.8 Error Responses

1673 If a UA receives a 423 (Interval Too Brief) response, it may retry the registration after making the expiration 1674 interval of all contact addresses in the REGISTER request equal to or greater than the expiration interval 1675 within the Min-Expires header field of the 423 (Interval Too Brief) response.

1676 10.3 Processing REGISTER Requests

1677 A registrar is a UAS that responds to REGISTER requests and maintains a list of bindings that are accessible 1678 to proxy servers and redirect servers within its administrative domain. A registrar handles requests according 1679 to Section 8.2 and Section 17.2, but it accepts only REGISTER requests. A registrar must not generate 1680 6xx responses. 1681 A registrar may redirect REGISTER requests as appropriate. One common usage would be for a 1682 registrar listening on a multicast interface to redirect multicast REGISTER requests to its own unicast 1683 interface with a 302 (Moved Temporarily) response. 1684 Registrars must ignore the Record-Route header field if it is included in a REGISTER request. Reg-1685 istrars must not include a Record-Route header field in any response to a REGISTER request.

1686 A registrar might receive a request that traversed a proxy which treats REGISTER as an unknown request and 1687 which added a Record-Route header field value.

1688 A registrar has to know (for example, through configuration) the set of domain(s) for which it maintains 1689 bindings. REGISTER requests must be processed by a registrar in the order that they are received. REG-1690 ISTER requests must also be processed atomically, meaning that a particular REGISTER request is either 1691 processed completely or not at all. Each REGISTER message must be processed independently of any 1692 other registration or binding changes. 1693 When receiving a REGISTER request, a registrar follows these steps:

1694 1. The registrar inspects the Request-URI to determine whether it has access to bindings for the domain 1695 identified in the Request-URI. If not, and if the server also acts as a proxy server, the server should 1696 forward the request to the addressed domain, following the general behavior for proxying messages 1697 described in Section 16.

1698 2. To guarantee that the registrar supports any necessary extensions, the registrar must process the 1699 Require header field values as described for UASs in Section 8.2.2.

1700 3. A registrar should authenticate the UAC. Mechanisms for the authentication of SIP user agents 1701 are described in Section 22. Registration behavior in no way overrides the generic authentication 1702 framework for SIP. If no authentication mechanism is available, the registrar may take the From 1703 address as the asserted identity of the originator of the request.

1704 4. The registrar should determine if the authenticated user is authorized to modify registrations for 1705 this address-of-record. For example, a registrar might consult a authorization database that maps user 1706 names to a list of addresses-of-record for which that user has authorization to modify bindings. If the 1707 authenticated user is not authorized to modify bindings, the registrar must return a 403 (Forbidden) 1708 and skip the remaining steps.

1709 In architectures that support third-party registration, one entity may be responsible for updating the regis-1710 trations associated with multiple addresses-of-record.

1711 5. The registrar extracts the address-of-record from the To header field of the request. If the address-of-1712 record is not valid for the domain in the Request-URI, the registrar must send a 404 (Not Found) 1713 response and skip the remaining steps. The URI must then be converted to a canonical form. To do 1714 that, all URI parameters must be removed (including the user-param), and any escaped characters 1715 must be converted to their unescaped form. The result serves as an index into the list of bindings.

1716 6. The registrar checks whether the request contains the Contact header field. If not, it skips to the last 1717 step. If the Contact header field is present, the registrar checks if there is one Contact field value 1718 that contains the special value “*” and an Expires field. If the request has additional Contact fields 1719 or an expiration time other than zero, the request is invalid, and the server must return a 400 Invalid 1720 Request and skip the remaining steps. If not, the registrar checks whether the Call-ID agrees with the 1721 value stored for each binding. If not, it must remove the binding. If it does agree, it must remove 1722 the binding only if the CSeq in the request is higher than the value stored for that binding. Otherwise 1723 the registrar must leave the binding as is. It then skips to the last step.

1724 7. If the address-of-record in the To header field of the request represents a SIPS URI, then the registrar 1725 must discard any Contact header field values that do not use the SIPS URI scheme before performing 1726 any further processing.

1727 8. The registrar now processes each contact address in the Contact header field in turn. For each address, 1728 it determines the expiration interval as follows: 1729 • If the field value has an “expires” parameter, that value must be used. 1730 • If there is no such parameter, but the request has an Expires header field, that value must be 1731 used. 1732 • If there is neither, a locally-configured default value must be used.

1733 The registrar may shorten the expiration interval. If and only if the expiration interval is greater than 1734 zero AND smaller than one hour AND less than a registrar-configured minimum, the registrar may 1735 reject the registration with a response of 423 (Registration Too Brief). This response must contain a 1736 Min-Expires header field that states the minimum expiration interval the registrar is willing to honor. 1737 It then skips the remaining steps.

1738 Allowing the registrar to set the registration interval protects it against excessively frequent registration 1739 refreshes while limiting the state that it needs to maintain and decreasing the likelihood of registrations going 1740 stale. The expiration interval of a registration is frequently used in the creation of services. An example is a 1741 follow-me service, where the user may only be available at a terminal for a brief period. Therefore, registrars 1742 should accept brief registrations; a request should only be rejected if the interval is so short that the refreshes 1743 would degrade registrar performance.

1744 For each address, the registrar then searches the list of current bindings using the URI comparison 1745 rules. If the binding does not exist, it is tentatively added. If the binding does exist, the registrar 1746 checks the Call-ID value. If the Call-ID value in the existing binding differs from the Call-ID value in 1747 the request, the binding must be removed if the expiration time is zero and updated otherwise. If they 1748 are the same, the registrar compares the CSeq value. If the value is higher than that of the existing 1749 binding, it must update or remove the binding as above. If not, the update must be aborted and the 1750 request fails.

1751 This algorithm ensures that out-of-order requests from the same UA are ignored.

1752 Each binding record records the Call-ID and CSeq values from the request.

1753 The binding updates must be committed (that is, made visible to the proxy or redirect server) if and 1754 only if all binding updates and additions succeed. If any one of them fails (for example, because the 1755 back-end database commit failed), the request must fail with a 500 (Server Error) response and all 1756 tentative binding updates must be removed.

1757 9. The registrar returns a 200 (OK) response. The response must contain Contact header field values 1758 enumerating all current bindings. Each Contact value must feature an “expires” parameter indi-1759 cating its expiration interval chosen by the registrar. The response should include a Date header 1760 field.

1761 11 Querying for Capabilities

1762 The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. This 1763 allows a client to discover information about the supported methods, content types, extensions, codecs, etc. 1764 without ”ringing” the other party. For example, before a client inserts a Require header field into an INVITE 1765 listing an option that it is not certain the destination UAS supports, the client can query the destination UAS 1766 with an OPTIONS to see if this option is returned in a Supported header field. All UAs must support the 1767 OPTIONS method. 1768 The target of the OPTIONS request is identified by the Request-URI, which could identify another 1769 UA or a SIP server. If the OPTIONS is addressed to a proxy server, the Request-URI is set without a user 1770 part, similar to the way a Request-URI is set for a REGISTER request. 1771 Alternatively, a server receiving an OPTIONS request with a Max-Forwards header field value of 0 1772 may respond to the request regardless of the Request-URI.

1773 This behavior is common with HTTP/1.1. This behavior can be used as a “traceroute” functionality to check the 1774 capabilities of individual hop servers by sending a series of OPTIONS requests with incremented Max-Forwards 1775 values.

1776 As is the case for general UA behavior, the transaction layer can return a timeout error if the OPTIONS 1777 yields no response. This may indicate that the target is unreachable and hence unavailable.

1778 An OPTIONS request may be sent as part of an established dialog to query the peer on capabilities that 1779 may be utilized later in the dialog.

1780 11.1 Construction of OPTIONS Request

1781 An OPTIONS request is constructed using the standard rules for a SIP request as discussed Section 8.1.1. 1782 A Contact header field may be present in an OPTIONS. 1783 An Accept header field should be included to indicate the type of message body the UAC wishes to 1784 receive in the response. Typically, this is set to a format that is used to describe the media capabilities of a 1785 UA, such as SDP (application/sdp). 1786 The response to an OPTIONS request is assumed to be scoped to the Request-URI in the original 1787 request. However, only when an OPTIONS is sent as part of an established dialog is it guaranteed that 1788 future requests will be received by the server that generated the OPTIONS response. 1789 Example OPTIONS request:

1790  OPTIONS sip:carol@chicago.com SIP/2.0
1791  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
1792  Max-Forwards: 70
1793  To: <sip:carol@chicago.com>
1794  From: Alice <sip:alice@atlanta.com>;tag=1928301774
1795  Call-ID: a84b4c76e66710
1796  CSeq: 63104 OPTIONS
1797  Contact: <sip:alice@pc33.atlanta.com>
1798  Accept: application/sdp
1799  Content-Length: 0

1800 11.2 Processing of OPTIONS Request

1801 The response to an OPTIONS is constructed using the standard rules for a SIP response as discussed in 1802 Section 8.2.6. The response code chosen must be the same that would have been chosen had the request 1803 been an INVITE. That is, a 200 (OK) would be returned if the UAS is ready to accept a call, a 486 (Busy 1804 Here) would be returned if the UAS is busy, etc. This allows an OPTIONS request to be used to determine 1805 the basic state of a UAS, which can be an indication of whether the UAC will accept an INVITE request. 1806 An OPTIONS request received within a dialog generates a 200 (OK) response that is identical to one 1807 constructed outside a dialog and does not have any impact on the dialog. 1808 This use of OPTIONS has limitations due the differences in proxy handling of OPTIONS and INVITE 1809 requests. While a forked INVITE can result in multiple 200 (OK) responses being returned, a forked OP-1810 TIONS will only result in a single 200 (OK) response, since it is treated by proxies using the non-INVITE 1811 handling. See Section 16.7 for the normative details. 1812 If the response to an OPTIONS is generated by a proxy server, the proxy returns a 200 (OK) listing the 1813 capabilities of the server. The response does not contain a message body. 1814 Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields should be 1815 present in a 200 (OK) response to an OPTIONS request. If the response is generated by a proxy, the 1816 Allow header field should be omitted as it is ambiguous since a proxy is method agnostic. Contact header 1817 fields may be present in a 200 (OK) response and have the same semantics as in a 3xx response. That is, 1818 they may list a set of alternative names and methods of reaching the user. A Warning header field may be 1819 present. 1820 A message body may be sent, the type of which is determined by the Accept header field in the OP-1821 TIONS request (application/sdp is the default if the Accept header field is not present). If the types include 1822 one that can describe media capabilities, the UAS should include a body in the response for that purpose. 1823 Details on construction of such a body in the case of application/sdp are described in [13]. 1824 Example OPTIONS response generated by a UAS (corresponding to the request in Section 11.1):

1825  SIP/2.0 200 OK
1826  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
1827  ;received=192.0.2.4
1828  To: <sip:carol@chicago.com>;tag=93810874
1829  From: Alice <sip:alice@atlanta.com>;tag=1928301774
1830  Call-ID: a84b4c76e66710
1831  CSeq: 63104 OPTIONS
1832  Contact: <sip:carol@chicago.com>
1833  Contact: <mailto:carol@chicago.com>
1834  Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
1835  Accept: application/sdp
1836  Accept-Encoding: gzip
1837  Accept-Language: en
1838  Supported: foo
1839  Content-Type: application/sdp
1840  Content-Length: 274

1841

1842  (SDP not shown)

1843 12 Dialogs

1844 A key concept for a user agent is that of a dialog. A dialog represents a peer-to-peer SIP relationship between 1845 two user agents that persists for some time. The dialog facilitates sequencing of messages between the user 1846 agents and proper routing of requests between both of them. The dialog represents a context in which to 1847 interpret SIP messages. Section 8 discussed method independent UA processing for requests and responses 1848 outside of a dialog. This section discusses how those requests and responses are used to construct a dialog, 1849 and then how subsequent requests and responses are sent within a dialog. 1850 A dialog is identified at each UA with a dialog ID, which consists of a Call-ID value, a local tag and a 1851 remote tag. The dialog ID at each UA involved in the dialog is not the same. Specifically, the local tag at one 1852 UA is identical to the remote tag at the peer UA. The tags are opaque tokens that facilitate the generation of 1853 unique dialog IDs. 1854 A dialog ID is also associated with all responses and with any request that contains a tag in the To field. 1855 The rules for computing the dialog ID of a message depend on whether the SIP element is a UAC or UAS. 1856 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 1857 the tag in the To field of the message, and the local tag is set to the tag in the From field of the message 1858 (these rules apply to both requests and responses). As one would expect, for a UAS, the Call-ID value of 1859 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 1860 message, and the local tag is set to the tag in the To field of the message. 1861 A dialog contains certain pieces of state needed for further message transmissions within the dialog. 1862 This state consists of the dialog ID, a local sequence number (used to order requests from the UA to its 1863 peer), a remote sequence number (used to order requests from its peer to the UA), a local URI, a remote 1864 URI, the Contact URI of the peer, a boolean flag called “secure”, and a route set, which is an ordered list of 1865 URIs. The route set is the list of servers that need to be traversed to send a request to the peer. A dialog can 1866 also be in the “early” state, which occurs when it is created with a provisional response, and then transition 1867 to the “confirmed” state when a 2xx final response arrives. For other responses, or if no response arrives at 1868 all on that dialog, the early dialog terminates.

1869 12.1 Creation of a Dialog

1870 Dialogs are created through the generation of non-failure responses to requests with specific methods. 1871 Within this specification, only 2xx and 101-199 responses with a To tag to INVITE establish a dialog. 1872 A dialog established by a non-final response to a request is in the “early” state and it is called an early dia-1873 log. Extensions may define other means for creating dialogs. Section 13 gives more details that are specific 1874 to the INVITE method. Here, we describe the process for creation of dialog state that is not dependent on 1875 the method. 1876 UAs must assign values to the dialog ID components as described below.

1877 12.1.1 UAS behavior

1878 When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), 1879 the UAS must copy all Record-Route header field values from the request into the response (including 1880 the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or 1881 unknown to the UAS) and must maintain the order of those values. The UAS must add a Contact header 1882 field to the response. The Contact header field contains an address where the UAS would like to be con-1883 tacted for subsequent requests in the dialog (which includes the ACK for a 2xx response in the case of an 1884 INVITE). Generally, the host portion of this URI is the IP address or FQDN of the host.The URI provided 1885 in the Contact header field must be a SIP or SIPS URI. If the request which initiated the dialog contained 1886 a SIPS URI in the Request-URI, the Contact header field must be a SIPS URI. In either case, the URI 1887 should have global scope (that is, the same URI can be used in messages outside this dialog). The same 1888 way, the scope of the URI in the Contact header field of the INVITE is not limited to this dialog either. It 1889 can therefore be used in messages to the UAC even outside this dialog. 1890 The UAS then constructs the state of the dialog. This state must be maintained for the duration of the 1891 dialog. 1892 If the request arrived over TLS, and the Request-URI contained a SIPS URI, the “secure” flag is set to 1893 TRUE. 1894 The route set must be set to the list of URIs in the Record-Route header field from the request, taken 1895 in order and preserving all URI parameters. If no Record-Route header field is present in the request, the 1896 route set must be set to the empty set. This route set, even if empty, overrides any pre-existing route set for 1897 future requests in this dialog. The remote target must be set to the URI from the Contact header field of 1898 the request. If the “secure” flag is true, the UA must convert any SIP URI in the route set and remote target 1899 to SIPS URI (this is done by just changing the scheme). 1900 The remote sequence number must be set to the value of the sequence number in the CSeq header field 1901 of the request. The local sequence number must be empty. The call identifier component of the dialog ID 1902 must be set to the value of the Call-ID in the request. The local tag component of the dialog ID must be 1903 set to the tag in the To field in the response to the request (which always includes a tag), and the remote tag 1904 component of the dialog ID must be set to the tag from the From field in the request. A UAS must be 1905 prepared to receive a request without a tag in the From field, in which case the tag is considered to have a 1906 value of null.

1907 This is to maintain backwards compatibility with RFC 2543, which did not mandate From tags.

1908 The remote URI must be set to the URI in the From field, and the local URI must be set to the URI in 1909 the To field.

1910 12.1.2 UAC Behavior

1911 When a UAC sends a request that can establish a dialog (such as an INVITE) it must provide a SIP or SIPS 1912 URI with global scope (i.e., the same SIP URI can be used in messages outside this dialog) in the Contact 1913 header field of the request. If the request is sent to a Request-URI with a SIPS URI, the Contact header 1914 must be a SIPS URI. 1915 When a UAC receives a response that establishes a dialog, it constructs the state of the dialog. This state 1916 must be maintained for the duration of the dialog. 1917 If the request was sent over TLS, and the Request-URI contained a SIPS URI, the “secure” flag is set 1918 to TRUE. 1919 The route set must be set to the list of URIs in the Record-Route header field from the response, 1920 taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in 1921 the response, the route set must be set to the empty set. This route set, even if empty, overrides any pre-1922 existing route set for future requests in this dialog. The remote target must be set to the URI from the 1923 Contact header field of the response. If the “secure” flag is true, the UA must convert any SIP URI in the 1924 route set and remote target to SIPS URI (this is done by just changing the scheme). 1925 The local sequence number must be set to the value of the sequence number in the CSeq header field 1926 of the request. The remote sequence number must be empty (it is established when the remote UA sends 1927 a request within the dialog). The call identifier component of the dialog ID must be set to the value of the 1928 Call-ID in the request. The local tag component of the dialog ID must be set to the tag in the From field 1929 in the request, and the remote tag component of the dialog ID must be set to the tag in the To field of the 1930 response. A UAC must be prepared to receive a response without a tag in the To field, in which case the 1931 tag is considered to have a value of null.

1932 This is to maintain backwards compatibility with RFC 2543, which did not mandate To tags.

1933 The remote URI must be set to the URI in the To field, and the local URI must be set to the URI in 1934 the From field.

1935 12.2 Requests within a Dialog

1936 Once a dialog has been established between two UAs, either of them may initiate new transactions as needed 1937 within the dialog. The UA sending the request will take the UAC role for the transaction. The UA receiving 1938 the request will take the UAS role. Note that these may be different roles than the UAs held during the 1939 transaction that established the dialog. 1940 Requests within a dialog may contain Record-Route and Contact header fields. However, these re-1941 quests do not cause the dialog’s route set to be modified, although they may modify the remote target URI.

1942 Specifically, requests that are not target refresh requests do not modify the dialog’s remote target URI, and 1943 requests that are target refresh requests do. For dialogs that have been established with an INVITE, the only 1944 target refresh request defined is re-INVITE (see Section 14). Other extensions may define different target 1945 refresh requests for dialogs established in other ways.

1946 Note that an ACK is NOT a target refresh request. 1947 Target refresh requests only update the dialog’s remote target URI, and not the route set formed from Record-1948 Route. Updating the latter would introduce severe backwards compatibility problems with RFC 2543-compliant 1949 systems.

1950 12.2.1 UAC Behavior

1951 12.2.1.1 Generating the Request A request within a dialog is constructed by using many of the com-1952 ponents of the state stored as part of the dialog. 1953 The URI in the To field of the request must be set to the remote URI from the dialog state. The tag 1954 in the To header field of the request must be set to the remote tag of the dialog ID. The From URI of the 1955 request must be set to the local URI from the dialog state. The tag in the From header field of the request 1956 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 1957 must be omitted from the To or From header fields, respectively.

1958 Usage of the URI from the To and From fields in the original request within subsequent requests is done for 1959 backwards compatibility with RFC 2543, which used the URI for dialog identification. In this specification, only 1960 the tags are used for dialog identification. It is expected that mandatory reflection of the original To and From URI 1961 in mid-dialog requests will be deprecated in a subsequent revision of this specification.

1962 The Call-ID of the request must be set to the Call-ID of the dialog. Requests within a dialog must 1963 contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in 1964 each direction (excepting ACK and CANCEL of course, whose numbers equal the requests being acknowl-1965 edged or cancelled). Therefore, if the local sequence number is not empty, the value of the local sequence 1966 number must be incremented by one, and this value must be placed into the CSeq header field. If the 1967 local sequence number is empty, an initial value must be chosen using the guidelines of Section 8.1.1.5. 1968 The method field in the CSeq header field value must match the method of the request.

1969 With a length of 32 bits, a client could generate, within a single call, one request a second for about 136 years 1970 before needing to wrap around. The initial value of the sequence number is chosen so that subsequent requests within 1971 the same call will not wrap around. A non-zero initial value allows clients to use a time-based initial sequence 1972 number. A client could, for example, choose the 31 most significant bits of a 32-bit second clock as an initial 1973 sequence number.

1974 The UAC uses the remote target and route set to build the Request-URI and Route header field of the 1975 request. 1976 If the route set is empty, the UAC must place the remote target URI into the Request-URI. The UAC 1977 must not add a Route header field to the request. 1978 If the route set is not empty, and the first URI in the route set contains the lr parameter (see Sec-1979 tion 19.1.1), the UAC must place the remote target URI into the Request-URI and must include a Route 1980 header field containing the route set values in order, including all parameters. 1981 If the route set is not empty, and its first URI does not contain the lr parameter, the UAC must place 1982 the first URI from the route set into the Request-URI, stripping any parameters that are not allowed in a 1983 Request-URI. The UAC must add a Route header field containing the remainder of the route set values 1984 in order, including all parameters. The UAC must then place the remote target URI into the Route header 1985 field as the last value. 1986 For example, if the remote target is sip:user@remoteua and the route set contains

1987 <sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>

1988 The request will be formed with the following Request-URI and Route header field:

1989 METHOD sip:proxy1
1990 Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua>

1991 If the first URI of the route set does not contain the lr parameter, the proxy indicated does not understand the 1992 routing mechanisms described in this document and will act as specified in RFC 2543, replacing the Request-URI 1993 with the first Route header field value it receives while forwarding the message. Placing the Request-URI at the 1994 end of the Route header field preserves the information in that Request-URI across the strict router (it will be 1995 returned to the Request-URI when the request reaches a loose-router).

1996 A UAC should include a Contact header field in any target refresh requests within a dialog, and unless 1997 there is a need to change it, the URI should be the same as used in previous requests within the dialog. If 1998 the “secure” flag is true, that URI must be a SIPS URI. As discussed in Section 12.2.2, a Contact header 1999 field in a target refresh request updates the remote target URI. This allows a UA to provide a new contact 2000 address, should its address change during the duration of the dialog. 2001 However, requests that are not target refresh requests do not affect the remote target URI for the dialog. 2002 The rest of the request is formed as described in Section 8.1.1. 2003 Once the request has been constructed, the address of the server is computed and the request is sent, 2004 using the same procedures for requests outside of a dialog (Section 8.1.2).

2005 The procedures in Section 8.1.2 will normally result in the request being sent to the address indicated by the 2006 topmost Route header field value or the Request-URI if no Route header field is present. Subject to certain 2007 restrictions, they allow the request to be sent to an alternate address (such as a default outbound proxy not represented 2008 in the route set).

2009 12.2.1.2 Processing the Responses The UAC will receive responses to the request from the transaction 2010 layer. If the client transaction returns a timeout this is treated as a 408 (Request Timeout) response. 2011 The behavior of a UAC that receives a 3xx response for a request sent within a dialog is the same as if 2012 the request had been sent outside a dialog. This behavior is described in Section 8.1.3.4.

2013 Note, however, that when the UAC tries alternative locations, it still uses the route set for the dialog to build the 2014 Route header of the request.

2015 When a UAC receives a 2xx response to a target refresh request, it must replace the dialog’s remote 2016 target URI with the URI from the Contact header field in that response, if present. If the “secure” flag is 2017 true, the UAC must convert the URI to a SIPS URI if it is not one already. 2018 If the response for a request within a dialog is a 481 (Call/Transaction Does Not Exist) or a 408 (Request 2019 Timeout), the UAC should terminate the dialog. A UAC should also terminate a dialog if no response 2020 at all is received for the request (the client transaction would inform the TU about the timeout.)

2021 For INVITE initiated dialogs, terminating the dialog consists of sending a BYE.

2022 12.2.2 UAS Behavior

2023 Requests sent within a dialog, as any other requests, are atomic. If a particular request is accepted by the 2024 UAS, all the state changes associated with it are performed. If the request is rejected, none of the state 2025 changes is performed.

2026 Note that some requests such as INVITEs affect several pieces of state.

2027 The UAS will receive the request from the transaction layer. If the request has a tag in the To header 2028 field, the UAS core computes the dialog identifier corresponding to the request and compares it with existing 2029 dialogs. If there is a match, this is a mid-dialog request. In that case, the UAS first applies the same 2030 processing rules for requests outside of a dialog, discussed in Section 8.2. 2031 If the request has a tag in the To header field, but the dialog identifier does not match any existing di-2032 alogs, the UAS may have crashed and restarted, or it may have received a request for a different (possibly 2033 failed) UAS (the UASs can construct the To tags so that a UAS can identify that the tag was for a UAS 2034 for which it is providing recovery). Another possibility is that the incoming request has been simply mis-2035 routed. Based on the To tag, the UAS may either accept or reject the request. Accepting the request for 2036 acceptable To tags provides robustness, so that dialogs can persist even through crashes. UAs wishing to 2037 support this capability must take into consideration some issues such as choosing monotonically increasing 2038 CSeq sequence numbers even across reboots, reconstructing the route set, and accepting out-of-range RTP 2039 timestamps and sequence numbers. 2040 If the UAS wishes to reject the request, because it does not wish to recreate the dialog, it must respond 2041 to the request with a 481 (Call/Transaction Does Not Exist) status code and pass that to the server transaction. 2042 Requests that do not change in any way the state of a dialog may be received within a dialog (for 2043 example, an OPTIONS request). They are processed as if they had been received outside the dialog. 2044 If the remote sequence number is empty, it must be set to the value of the sequence number in the CSeq 2045 header field value in the request. If the remote sequence number was not empty, but the sequence number of 2046 the request is lower than the remote sequence number, the request is out of order and must be rejected with 2047 a 500 (Server Internal Error) response. If the remote sequence number was not empty, and the sequence 2048 number of the request is greater than the remote sequence number, the request is in order. It is possible for 2049 the CSeq sequence number to be higher than the remote sequence number by more than one. This is not 2050 an error condition, and a UAS should be prepared to receive and process requests with CSeq values more 2051 than one higher than the previous received request. The UAS must then set the remote sequence number to 2052 the value of the sequence number in the CSeq header field value in the request.

2053 If a proxy challenges a request generated by the UAC, the UAC has to resubmit the request with credentials. The 2054 resubmitted request will have a new CSeq number. The UAS will never see the first request, and thus, it will notice 2055 a gap in the CSeq number space. Such a gap does not represent any error condition.

2056 When a UAS receives a target refresh request, it must replace the dialog’s remote target URI with the 2057 URI from the Contact header field in that request, if present. If the “secure” flag is true, the UAC must 2058 convert the URI to a SIPS URI if it is not one already.

2059 12.3 Termination of a Dialog

2060 Independent of the method, if a request outside of a dialog generates a non-2xx final response, any early 2061 dialogs created through provisional responses to that request are terminated. The mechanism for terminating 2062 confirmed dialogs is method specific. In this specification, the BYE method terminates a session and the 2063 dialog associated with it. See Section 15 for details.

2064 13 Initiating a Session

2065 13.1 Overview

2066 When a user agent client desires to initiate a session (for example, audio, video, or a game), it formulates an 2067 INVITE request. The INVITE request asks a server to establish a session. This request may be forwarded by 2068 proxies, eventually arriving at one or more UAS that can potentially accept the invitation. These UASs will 2069 frequently need to query the user about whether to accept the invitation. After some time, those UAS can 2070 accept the invitation (meaning the session is to be established) by sending a 2xx response. If the invitation 2071 is not accepted, a 3xx, 4xx, 5xx or 6xx response is sent, depending on the reason for the rejection. Before 2072 sending a final response, the UAS can also send provisional responses (1xx) to advise the UAC of progress 2073 in contacting the called user. 2074 After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses 2075 or one non-2xx final response. Because of the protracted amount of time it can take to receive final responses 2076 to INVITE, the reliability mechanisms for INVITE transactions differ from those of other requests (like 2077 OPTIONS). Once it receives a final response, the UAC needs to send an ACK for every final response 2078 it receives. The procedure for sending this ACK depends on the type of response. For final responses 2079 between 300 and 699, the ACK processing is done in the transaction layer and follows one set of rules (See 2080 Section 17). For 2xx responses, the ACK is generated by the UAC core. 2081 A 2xx response to an INVITE establishes a session, and it also creates a dialog between the UA that 2082 issued the INVITE and the UA that generated the 2xx response. Therefore, when multiple 2xx responses are 2083 received from different remote UAs (because the INVITE forked), each 2xx establishes a different dialog. 2084 All these dialogs are part of the same call. 2085 This section provides details on the establishment of a session using INVITE. A UA that supports IN-2086 VITE must also support ACK, CANCEL and BYE.

2087 13.2 UAC Processing

2088 13.2.1 Creating the Initial INVITE

2089 Since the initial INVITE represents a request outside of a dialog, its construction follows the procedures of 2090 Section 8.1.1. Additional processing is required for the specific case of INVITE. 2091 An Allow header field (Section 20.5) should be present in the INVITE. It indicates what methods can 2092 be invoked within a dialog, on the UA sending the INVITE, for the duration of the dialog. For example, a 2093 UA capable of receiving INFO requests within a dialog [33] should include an Allow header field listing 2094 the INFO method. 2095 A Supported header field (Section 20.37) should be present in the INVITE. It enumerates all the 2096 extensions understood by the UAC. 2097 An Accept (Section 20.1) header field may be present in the INVITE. It indicates which Content-Types 2098 are acceptable to the UA, in both the response received by it, and in any subsequent requests sent to it within 2099 dialogs established by the INVITE. The Accept header field is especially useful for indicating support of 2100 various session description formats. 2101 The UAC may add an Expires header field (Section 20.19) to limit the validity of the invitation. If the 2102 time indicated in the Expires header field is reached and no final answer for the INVITE has been received 2103 the UAC core should generate a CANCEL request for the INVITE, as per Section 9. 2104 A UAC may also find it useful to add, among others, Subject (Section 20.36), Organization (Sec-2105 tion 20.25) and User-Agent (Section 20.41) header fields. They all contain information related to the 2106 INVITE. 2107 The UAC may choose to add a message body to the INVITE. Section 8.1.1.10 deals with how to con-2108 struct the header fields – Content-Type among others – needed to describe the message body. 2109 There are special rules for message bodies that contain a session description - their corresponding 2110 Content-Disposition is “session”. SIP uses an offer/answer model where one UA sends a session de-2111 scription, called the offer, which contains a proposed description of the session. The offer indicates the 2112 desired communications means (audio, video, games), parameters of those means (such as codec types) and 2113 addresses for receiving media from the answerer. The other UA responds with another session description, 2114 called the answer, which indicates which communications means are accepted, the parameters that apply to 2115 those means, and addresses for receiving media from the offerer. The offer/answer model defines restric-2116 tions on when offers and answers can be made. This results in restrictions on where the offers and answers 2117 can appear in SIP messages. In this specification, offers and answers can only appear in INVITE requests 2118 and responses, and ACK. The usage of offers and answers is further restricted. For the initial INVITE 2119 transaction, the rules are:

2120 • The initial offer must be in either an INVITE or, if not there, in the first reliable non-failure message 2121 from the UAS back to the UAC. In this specification, that is the final 2xx response.

2122 • If the initial offer is in an INVITE, the answer must be in a reliable non-failure message from UAS 2123 back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx 2124 response to that INVITE.

2125 • If the initial offer is in the first reliable non-failure message from the UAS back to UAC, the answer 2126 must be in the acknowledgement for that message (in this specification, ACK for a 2xx response).

2127 • After having sent or received an answer to the first offer, the UAC may generate subsequent offers 2128 in requests, but only if it has received answers to any previous offers, and has not sent any offers to 2129 which it hasn’t gotten an answer.

2130 • Once the UAS has sent or received an answer to the initial offer, it must not generate subsequent 2131 offers in any responses to the initial INVITE. This means that a UAS based on this specification alone 2132 can never generate subsequent offers until completion of the initial transaction.

2133 Concretely, the above rules specify two exchanges - the offer is in the INVITE, and the answer in the 2134 2xx, or the offer is in the 2xx, and the answer is in the ACK. All user agents that support INVITE must 2135 support these two exchanges. 2136 The Session Description Protocol (SDP) [1] must be supported by all user agents as a means to describe 2137 sessions, and its usage for constructing offers and answers must follow the procedures defined in [13]. 2138 The restrictions of the offer-answer model just described only apply to bodies whose Content-Disposition 2139 header field value is “session”. Therefore, it is possible that both the INVITE and the ACK contain a body 2140 message (for example, the INVITE carries a photo (Content-Disposition: render) and the ACK a session 2141 description (Content-Disposition: session)).

2142 If the Content-Disposition header field is missing, bodies of Content-Type application/sdp imply the 2143 disposition “session”, while other content types imply “render”.

2144 Once the INVITE has been created, the UAC follows the procedures defined for sending requests outside 2145 of a dialog (Section 8). This results in the construction of a client transaction that will ultimately send the 2146 request and deliver responses to the UAC.

2147 13.2.2 Processing INVITE Responses

2148 Once the INVITE has been passed to the INVITE client transaction, the UAC waits for responses for the 2149 INVITE. If the INVITE client transaction returns a timeout rather than a response the TU acts as if a 408 2150 (Request Timeout) response had been received, as described in Section 8.1.3.

2151 13.2.2.1 1xx responses Zero, one or multiple provisional responses may arrive before one or more 2152 final responses are received. Provisional responses for an INVITE request can create “early dialogs”. If a 2153 provisional response has a tag in the To field, and if the dialog ID of the response does not match an existing 2154 dialog, one is constructed using the procedures defined in Section 12.1.2. 2155 The early dialog will only be needed if the UAC needs to send a request to its peer within the dialog 2156 before the initial INVITE transaction completes. Header fields present in a provisional response are appli-2157 cable as long as the dialog is in the early state (for example, an Allow header field in a provisional response 2158 contains the methods that can be used in the dialog while this is in the early state).

2159 13.2.2.2 3xx responses A 3xx response may contain one or more Contact header field values provid-2160 ing new addresses where the callee might be reachable. Depending on the status code of the 3xx response 2161 (see Section 21.3) the UAC may choose to try those new addresses.

2162 13.2.2.3 4xx, 5xx and 6xx responses A single non-2xx final response may be received for the IN-2163 VITE. 4xx, 5xx and 6xx responses may contain a Contact header field value indicating the location where 2164 additional information about the error can be found. 2165 All early dialogs are considered terminated upon reception of the non-2xx final response. 2166 After having received the non-2xx final response the UAC core considers the INVITE transaction com-2167 pleted. The INVITE client transaction handles generation of ACKs for the response (see Section 17).

2168 13.2.2.4 2xx responses Multiple 2xx responses may arrive at the UAC for a single INVITE request 2169 due to a forking proxy. Each response is distinguished by the tag parameter in the To header field, and each 2170 represents a distinct dialog, with a distinct dialog identifier. 2171 If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog 2172 must be transitioned to the “confirmed” state, and the route set for the dialog must be recomputed based 2173 on the 2xx response using the procedures of Section 12.2.1.2. Otherwise, a new dialog in the “confirmed” 2174 state must be constructed using the procedures of Section 12.1.2.

2175 Note that the only piece of state that is recomputed is the route set. Other pieces of state such as the highest 2176 sequence numbers (remote and local) sent within the dialog are not recomputed. The route set only is recomputed 2177 for backwards compatibility. RFC 2543 did not mandate mirroring of the Record-Route header field in a 1xx, only 2178 2xx. However, we cannot update the entire state of the dialog, since mid-dialog requests may have been sent within 2179 the early dialog, modifying the sequence numbers, for example.

2180 The UAC core must generate an ACK request for each 2xx received from the transaction layer. The 2181 header fields of the ACK are constructed in the same way as for any request sent within a dialog (see 2182 Section 12) with the exception of the CSeq and the header fields related to authentication. The sequence 2183 number of the CSeq header field must be the same as the INVITE being acknowledged, but the CSeq 2184 method must be ACK. The ACK must contain the same credentials as the INVITE. If the 2xx contains 2185 an offer (based on the rules above), the ACK must carry an answer in its body. If the offer in the 2xx 2186 response is not acceptable, the UAC core must generate a valid answer in the ACK and then send a BYE 2187 immediately. 2188 Once the ACK has been constructed, the procedures of [4] are used to determine the destination address, 2189 port and transport. However, the request is passed to the transport layer directly for transmission, rather than 2190 a client transaction. This is because the UAC core handles retransmissions of the ACK, not the transaction 2191 layer. The ACK must be passed to the client transport every time a retransmission of the 2xx final response 2192 that triggered the ACK arrives.

2193 The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the 2194 first 2xx response. At this point all the early dialogs that have not transitioned to established dialogs are 2195 terminated. Once the INVITE transaction is considered completed by the UAC core, no more new 2xx 2196 responses are expected to arrive. 2197 If, after acknowledging any 2xx response to an INVITE, the UAC does not want to continue with that 2198 dialog, then the UAC must terminate the dialog by sending a BYE request as described in Section 15.

2199 13.3 UAS Processing

2200 13.3.1 Processing of the INVITE

2201 The UAS core will receive INVITE requests from the transaction layer. It first performs the request process-2202 ing procedures of Section 8.2, which are applied for both requests inside and outside of a dialog. 2203 Assuming these processing states complete without generating a response, the UAS core performs the 2204 additional processing steps:

2205 1. If the request is an INVITE that contains an Expires header field the UAS core sets a timer for 2206 the number of seconds indicated in the header field value. When the timer fires, the invitation is 2207 considered to be expired. If the invitation expires before the UAS has generated a final response, a 2208 487 (Request Terminated) response should be generated.

2209 2. If the request is a mid-dialog request, the method-independent processing described in Section 12.2.2 2210 is first applied. It might also modify the session; Section 14 provides details.

2211 3. If the request has a tag in the To header field but the dialog identifier does not match any of the 2212 existing dialogs, the UAS may have crashed and restarted, or may have received a request for a 2213 different (possibly failed) UAS. Section 12.2.2 provides guidelines to achieve a robust behavior under 2214 such a situation.

2215 Processing from here forward assumes that the INVITE is outside of a dialog, and is thus for the purposes 2216 of establishing a new session. 2217 The INVITE may contain a session description, in which case the UAS is being presented with an offer 2218 for that session. It is possible that the user is already a participant in that session, even though the INVITE 2219 is outside of a dialog. This can happen when a user is invited to the same multicast conference by multiple 2220 other participants. If desired, the UAS may use identifiers within the session description to detect this 2221 duplication. For example, SDP contains a session id and version number in the origin (o) field. If the user 2222 is already a member of the session, and the session parameters contained in the session description have 2223 not changed, the UAS may silently accept the INVITE (that is, send a 2xx response without prompting the 2224 user). 2225 If the INVITE does not contain a session description, the UAS is being asked to participate in a session, 2226 and the UAC has asked that the UAS provide the offer of the session. It must provide the offer in its first 2227 non-failure reliable message back to the UAC. In this specification, that is a 2xx response to the INVITE. 2228 The UAS can indicate progress, accept, redirect, or reject the invitation. In all of these cases, it formu-2229 lates a response using the procedures described in Section 8.2.6.

2230 13.3.1.1 Progress If the UAS is not able to answer the invitation immediately, it can choose to indicate 2231 some kind of progress to the UAC (for example, an indication that a phone is ringing). This is accomplished 2232 with a provisional response between 101 and 199. These provisional responses establish early dialogs and 2233 therefore follow the procedures of Section 12.1.1 in addition to those of Section 8.2.6. A UAS may send 2234 as many provisional responses as it likes. Each of these must indicate the same dialog ID. However, these 2235 will not be delivered reliably. 2236 If the UAS desires an extended period of time to answer the INVITE, it will need to ask for an “ex-2237 tension” in order to prevent proxies from canceling the transaction. A proxy has the option of canceling a 2238 transaction when there is a gap of 3 minutes between messages in a transaction. To prevent cancellation, the 2239 UAS must send a non-100 provisional response at every minute, to handle the possibility of lost provisional 2240 responses.

2241 An INVITE transaction can go on for extended durations when the user is placed on hold, or when interworking 2242 with PSTN systems which allow communications to take place without answering the call. The latter is common in 2243 Interactive Voice Response (IVR) systems.

2244 13.3.1.2 The INVITE is redirected If the UAS decides to redirect the call, a 3xx response is sent. A 2245 300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved Temporarily) response should contain 2246 a Contact header field containing one or more URIs of new addresses to be tried. The response is passed to 2247 the INVITE server transaction, which will deal with its retransmissions.

2248 13.3.1.3 The INVITE is rejected A common scenario occurs when the callee is currently not willing 2249 or able to take additional calls at this end system. A 486 (Busy Here) should be returned in such scenario. 2250 If the UAS knows that no other end system will be able to accept this call a 600 (Busy Everywhere) response 2251 should be sent instead. However, it is unlikely that a UAS will be able to know this in general, and thus 2252 this response will not usually be used. The response is passed to the INVITE server transaction, which will 2253 deal with its retransmissions. 2254 A UAS rejecting an offer contained in an INVITE should return a 488 (Not Acceptable Here) response. 2255 Such a response should include a Warning header field value explaining why the offer was rejected.

2256 13.3.1.4 The INVITE is accepted The UAS core generates a 2xx response. This response establishes 2257 a dialog, and therefore follows the procedures of Section 12.1.1 in addition to those of Section 8.2.6. 2258 A 2xx response to an INVITE should contain the Allow header field and the Supported header field, 2259 and may contain the Accept header field. Including these header fields allows the UAC to determine the 2260 features and extensions supported by the UAS for the duration of the call, without probing. 2261 If the INVITE request contained an offer, and the UAS had not yet sent an answer, the 2xx must contain 2262 an answer. If the INVITE did not contain an offer, the 2xx must contain an offer if the UAS had not yet 2263 sent an offer. 2264 Once the response has been constructed it is passed to the INVITE server transaction. Note, however, 2265 that the INVITE server transaction will be destroyed as soon as it receives this final response and passes it 2266 to the transport. Therefore, it is necessary to pass periodically the response directly to the transport until 2267 the ACK arrives. The 2xx response is passed to the transport with an interval that starts at T1 seconds and 2268 doubles for each retransmission until it reaches T2 seconds (T1 and T2 are defined in Section 17). Response 2269 retransmissions cease when an ACK request for the response is received. This is independent of whatever 2270 transport protocols are used to send the response.

2271 Since 2xx is retransmitted end-to-end, there may be hops between UAS and UAC that are UDP. To ensure reliable 2272 delivery across these hops, the response is retransmitted periodically even if the transport at the UAS is reliable.

2273 If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is 2274 confirmed, but the session should be terminated. This is accomplished with a BYE as described in Section

2275 15.

2276 14 Modifying an Existing Session

2277 A successful INVITE request (see Section 13) establishes both a dialog between two user agents and a 2278 session using the offer-answer model. Section 12 explains how to modify an existing dialog using a target 2279 refresh request (for example, changing the remote target URI of the dialog). This section describes how 2280 to modify the actual session. This modification can involve changing addresses or ports, adding a media 2281 stream, deleting a media stream, and so on. This is accomplished by sending a new INVITE request within 2282 the same dialog that established the session. An INVITE request sent within an existing dialog is known as 2283 a re-INVITE.

2284 Note that a single re-INVITE can modify the dialog and the parameters of the session at the same time.

2285 Either the caller or callee can modify an existing session. 2286 The behavior of a UA on detection of media failure is a matter of local policy. However, automated 2287 generation of re-INVITE or BYE is not recommended to avoid flooding the network with traffic when 2288 there is congestion. In any case, if these messages are sent automatically, they should be sent after some 2289 randomized interval.

2290 Note that the paragraph above refers to automatically generated BYEs and re-INVITEs. If the user hangs up 2291 upon media failure the UA would send a BYE request as usual.

2292 14.1 UAC Behavior

2293 The same offer-answer model that applies to session descriptions in INVITEs (Section 13.2.1) applies to 2294 re-INVITEs. As a result, a UAC that wants to add a media stream, for example, will create a new offer that 2295 contains this media stream, and send that in an INVITE request to its peer. It is important to note that the full 2296 description of the session, not just the change, is sent. This supports stateless session processing in various 2297 elements, and supports failover and recovery capabilities. Of course, a UAC may send a re-INVITE with no 2298 session description, in which case the first reliable non-failure response to the re-INVITE will contain the 2299 offer (in this specification, that is a 2xx response). 2300 If the session description format has the capability for version numbers, the offerer should indicate 2301 that the version of the session description has changed. 2302 The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set following the same rules as 2303 for regular requests within an existing dialog, described in Section 12. 2304 A UAC may choose not to add an Alert-Info header field or a body with Content-Disposition ”alert” 2305 to re-INVITEs because UASs do not typically alert the user upon reception of a re-INVITE. 2306 Unlike an INVITE, which can fork, a re-INVITE will never fork, and therfore, only ever generate a 2307 single final response. The reason a re-INVITE will never fork is that the Request-URI identifies the target 2308 as the UA instance it established the dialog with, rather than identifying an address-of-record for the user. 2309 Note that a UAC must not initiate a new INVITE transaction within a dialog while another INVITE 2310 transaction is in progress in either direction.

2311 1. If there is an ongoing INVITE client transaction, the TU must wait until the transaction reaches the 2312 completed or terminated state before initiating the new INVITE.

2313 2. If there is an ongoing INVITE server transaction, the TU must wait until the transaction reaches the 2314 confirmed or terminated state before initiating the new INVITE.

2315 However, a UA may initiate a regular transaction while an INVITE transaction is in progress. A UA 2316 may also initiate an INVITE transaction while a regular transaction is in progress. 2317 If a UA receives a non-2xx final response to a re-INVITE, the session parameters must remain un-2318 changed, as if no re-INVITE had been issued. Note that, as stated in Section 12.2.1.2, if the non-2xx final 2319 response is a 481 (Call/Transaction Does Not Exist), or a 408 (Request Timeout), or no response at all is 2320 received for the re-INVITE (that is, a timeout is returned by the INVITE client transaction), the UAC will 2321 terminate the dialog. 2322 The rules for transmitting a re-INVITE and for generating an ACK for a 2xx response to re-INVITE are 2323 the same as for the initial INVITE (Section 13.2.1).

2324 14.2 UAS Behavior

2325 Section 13.3.1 describes the procedure for distinguishing incoming re-INVITEs from incoming initial IN-2326 VITEs and handling a re-INVITE for an existing dialog. 2327 A UAS that receives a second INVITE before it sends the final response to a first INVITE with a lower 2328 CSeq sequence number on the same dialog must return a 500 (Server Internal Error) response to the second 2329 INVITE and must include a Retry-After header field with a randomly chosen value of between 0 and 10 2330 seconds. 2331 A UAS that receives an INVITE on a dialog while an INVITE it had sent on that dialog is in progress 2332 must return a 491 (Request Pending) response to the received INVITE and must include a Retry-After 2333 header field with a value chosen as follows:

2334 1. If the UAS is the owner of the Call-ID of the dialog ID (meaning it generated the value), the Retry-2335 After header field has a randomly chosen value of between 2.1 and 4 seconds in units of 10 ms.

2336 2. If the UAS is not the owner of the Call-ID of the dialog ID, the Retry-After header field has a ran-2337 domly chosen value of between 0 and 2 seconds in units of 10 ms.

2338 If a UA receives a re-INVITE for an existing dialog, it must check any version identifiers in the session 2339 description or, if there are no version identifiers, the content of the session description to see if it has changed. 2340 If the session description has changed, the UAS must adjust the session parameters accordingly, possibly 2341 after asking the user for confirmation.

2342 Versioning of the session description can be used to accommodate the capabilities of new arrivals to a conference, 2343 add or delete media, or change from a unicast to a multicast conference.

2344 If the new session description is not acceptable, the UAS can reject it by returning a 488 (Not Acceptable 2345 Here) response for the re-INVITE. This response should include a Warning header field. 2346 If a UAS generates a 2xx response and never receives an ACK, it should generate a BYE to terminate 2347 the dialog. 2348 A UAS may choose not to generate 180 (Ringing) responses for a re-INVITE because UACs do not 2349 typically render this information to the user. For the same reason, UASs may choose not to use an Alert-2350 Info header field or a body with Content-Disposition ”alert” in responses to a re-INVITE. 2351 A UAS providing an offer in a 2xx (because the INVITE did not contain an offer) should construct 2352 the offer as if the UAS were making a brand new call, subject to the constraints of sending an offer that 2353 updates an existing session, as described in [13] in the case of SDP. Specifically, this means that it should 2354 include as many media formats and media types that the UA is willing to support. The UAS must ensure 2355 that the session description overlaps with its previous session description in media formats, transports, or 2356 other parameters that require support from the peer. This is to avoid the need for the peer to reject the session 2357 description. If, however, it is unacceptable to the UAC, the UAC should generate an answer with a valid 2358 session description, and then send a BYE to terminate the session.

2359 15 Terminating a Session

2360 This section describes the procedures for terminating a session established by SIP. The state of the session 2361 and the state of the dialog are very closely related. When a session is initiated with an INVITE, each 1xx or 2362 2xx response from a distinct UAS creates a dialog, and if that response completes the offer/answer exchange, 2363 it also creates a session. As a result, each session is “associated” with a single dialog - the one which resulted 2364 in its creation. If an initial INVITE generates a non-2xx final response, that terminates all sessions (if any) 2365 and all dialogs (if any) that were created through responses to the request. By virtue of completing the 2366 transaction, a non-2xx final response also prevents further sessions from being created as a result of the 2367 INVITE. The BYE request is used to terminate a specific session or attempted session. In this case, the 2368 specific session is the one with the peer UA on the other side of the dialog. When a BYE is received on a 2369 dialog, any session associated with that dialog should terminate. A UA must not send a BYE outside of 2370 a dialog. The caller’s UA may send a BYE for either confirmed or early dialogs, and the callee’s UA may 2371 send a BYE on confirmed dialogs, but must not send a BYE on early dialogs. However, the callee’s UA 2372 must not send a BYE on a confirmed dialog until it has received an ACK for its 2xx response or until the 2373 server transaction times out. If no SIP extensions have defined other application layer state associated with 2374 the dialog, the BYE also terminates the dialog. 2375 The impact of a non-2xx final response to INVITE on dialogs and sessions makes the use of CANCEL 2376 attractive. The CANCEL attempts to force a non-2xx response to the INVITE (in particular, a 487). There-2377 fore, if a UAC wishes to give up on its call attempt entirely, it can send a CANCEL. If the INVITE results in 2378 2xx final response(s) to the INVITE, this means that a UAS accepted the invitation while the CANCEL was 2379 in progress. The UAC may continue with the sessions established by any 2xx responses, or may terminate 2380 them with BYE.

2381 The notion of “hanging up” is not well defined within SIP. It is specific to a particular, albeit common, user 2382 interface. Typically, when the user hangs up, it indicates a desire to terminate the attempt to establish a session, and 2383 to terminate any sessions already created. For the caller’s UA, this would imply a CANCEL request if the initial 2384 INVITE has not generated a final response, and a BYE to all confirmed dialogs after a final response. For the callee’s 2385 UA, it would typically imply a BYE; presumably, when the user picked up the phone, a 2xx was generated, and so 2386 hanging up would result in a BYE after the ACK is received. This does not mean a user cannot hang up before 2387 receipt of the ACK, it just means that the software in his phone needs to maintain state for a short while in order to 2388 clean up properly. If the particular UI allows for the user to reject a call before its answered, a 403 (Forbidden) is a 2389 good way to express that. As per the rules above, a BYE can’t be sent.

2390 15.1 Terminating a Session with a BYE Request

2391 15.1.1 UAC Behavior

2392 A BYE request is constructed as would any other request within a dialog, as described in Section 12. 2393 Once the BYE is constructed, the UAC core creates a new non-INVITE client transaction, and passes it 2394 the BYE request. The UAC must consider the session terminated (and therefore stop sending or listening 2395 for media) as soon as the BYE request is passed to the client transaction. If the response for the BYE is a 2396 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no response at all is received for the 2397 BYE (that is, a timeout is returned by the client transaction), the UAC must consider the session and the 2398 dialog terminated.

2399 15.1.2 UAS Behavior

2400 A UAS first processes the BYE request according to the general UAS processing described in Section 8.2. 2401 A UAS core receiving a BYE request checks if it matches an existing dialog. If the BYE does not match an 2402 existing dialog, the UAS core should generate a 481 (Call/Transaction Does Not Exist) response and pass 2403 that to the server transaction.

2404 This rule means that a BYE sent without tags by a UAC will be rejected. This is a change from RFC 2543, which 2405 allowed BYE without tags.

2406 A UAS core receiving a BYE request for an existing dialog must follow the procedures of Sec-2407 tion 12.2.2 to process the request. Once done, the UAS should terminate the session (and therefore stop 2408 sending and listening for media). The only case where it can elect not to are multicast sessions, where par-2409 ticipation is possible even if the other participant in the dialog has terminated its involvement in the session. 2410 Whether or not it ends its participation on the session, the UAS core must generate a 2xx response to the 2411 BYE, and must pass that to the server transaction for transmission. 2412 The UAS must still respond to any pending requests received for that dialog. It is recommended that 2413 a 487 (Request Terminated) response is generated to those pending requests.

2414 16 Proxy Behavior

2415 16.1 Overview

2416 SIP proxies are elements that route SIP requests to user agent servers and SIP responses to user agent clients. 2417 A request may traverse several proxies on its way to a UAS. Each will make routing decisions, modifying 2418 the request before forwarding it to the next element. Responses will route through the same set of proxies 2419 traversed by the request in the reverse order. 2420 Being a proxy is a logical role for a SIP element. When a request arrives, an element that can play the 2421 role of a proxy first decides if it needs to respond to the request on its own. For instance, the request may be 2422 malformed or the element may need credentials from the client before acting as a proxy. The element may 2423 respond with any appropriate error code. When responding directly to a request, the element is playing the 2424 role of a UAS and must behave as described in Section 8.2. 2425 A proxy can operate in either a stateful or stateless mode for each new request. When stateless, a proxy 2426 acts as a simple forwarding element. It forwards each request downstream to a single element determined by 2427 making a targeting and routing decision based on the request. It simply forwards every response it receives 2428 upstream. A stateless proxy discards information about a message once the message has been forwarded. 2429 A stateful proxy remembers information (specifically, transaction state) about each incoming request and 2430 any requests it sends as a result of processing the incoming request. It uses this information to affect the 2431 processing of future messages associated with that request. A stateful proxy may choose to “fork” a request, 2432 routing it to multiple destinations. Any request that is forwarded to more than one location must be handled 2433 statefully. 2434 In some circumstances, a proxy may forward requests using stateful transports (such as TCP) without 2435 being transaction-stateful. For instance, a proxy may forward a request from one TCP connection to another 2436 transaction statelessly as long as it places enough information in the message to be able to forward the 2437 response down the same connection the request arrived on. Requests forwarded between different types of 2438 transports where the proxy’s TU must take an active role in ensuring reliable delivery on one of the transports 2439 must be forwarded transaction statefully. 2440 A stateful proxy may transition to stateless operation at any time during the processing of a request, 2441 so long as it did not do anything that would otherwise prevent it from being stateless initially (forking, for 2442 example, or generation of a 100 response). When performing such a transition, all state is simply discarded. 2443 The proxy should not initiate a CANCEL request. 2444 Much of the processing involved when acting statelessly or statefully for a request is identical. The next 2445 several subsections are written from the point of view of a stateful proxy. The last section calls out those 2446 places where a stateless proxy behaves differently.

2447 16.2 Stateful Proxy

2448 When stateful, a proxy is purely a SIP transaction processing engine. Its behavior is modeled here in terms of 2449 the server and client transactions defined in Section 17. A stateful proxy has a server transaction associated 2450 with one or more client transactions by a higher layer proxy processing component (see figure 3), known as 2451 a proxy core. An incoming request is processed by a server transaction. Requests from the server transaction 2452 are passed to a proxy core. The proxy core determines where to route the request, choosing one or more 2453 next-hop locations. An outgoing request for each next-hop location is processed by its own associated 2454 client transaction. The proxy core collects the responses from the client transactions and uses them to send 2455 responses to the server transaction. 2456 A stateful proxy creates a new server transaction for each new request received. Any retransmissions 2457 of the request will then be handled by that server transaction per Section 17. The proxy core must behave 2458 as a UAS with respect to sending an immediate provisional on that server transaction (such as 100 Trying) 2459 as described in Section 8.2.6. Thus, a stateful proxy should not generate 100 Trying responses to non-2460 INVITE requests. 2461 This is a model of proxy behavior, not of software. An implementation is free to take any approach that 2462 replicates the external behavior this model defines. 2463 For all new requests, including any with unknown methods, an element intending to proxy the request 2464 must:

2465 1. Validate the request (Section 16.3)

2466 2. Preprocess routing information (Section 16.4)

2467 3. Determine target(s) for the request (Section 16.5)

2468 4. Forward the request to each target (Section 16.6)

2469 5. Process all responses (Section 16.7)

2470 16.3 Request Validation

2471 Before an element can proxy a request, it must verify the message’s validity. A valid message must pass 2472 the following checks:

2473 1. Reasonable Syntax

Figure 3: Stateful Proxy Model

2474 2. URI scheme 2475 3. Max-Forwards 2476 4. (Optional) Loop Detection 2477 5. Proxy-Require 2478 6. Proxy-Authorization 2479 If any of these checks fail, the element must behave as a user agent server (see Section 8.2) and respond 2480 with an error code.

2481 Notice that a proxy is not required to detect merged requests and must not treat merged requests as an 2482 error condition. The endpoints receiving the requests will resolve the merge as described in Section 8.2.2.2.

2483 1. Reasonable syntax check

2484 The request must be well-formed enough to be handled with a server transaction. Any components 2485 involved in the remainder of these Request Validation steps or the Request Forwarding section must 2486 be well-formed. Any other components, well-formed or not, should be ignored and remain un-2487 changed when the message is forwarded. For instance, an element would not reject a request because 2488 of a malformed Date header field. Likewise, a proxy would not remove a malformed Date header 2489 field before forwarding a request.

2490 This protocol is designed to be extended. Future extensions may define new methods and header fields 2491 at any time. An element must not refuse to proxy a request because it contains a method or header 2492 field it does not know about.

2493 2. URI scheme check

2494 If the Request-URI has a URI whose scheme is not understood by the proxy, the proxy should 2495 reject the request with a 416 (Unsupported URI Scheme) response.

2496 3. Max-Forwards check

2497 The Max-Forwards header field (Section 20.22) is used to limit the number of elements a SIP request 2498 can traverse.

2499 If the request does not contain a Max-Forwards header field, this check is passed.

2500 If the request contains a Max-Forwards header field with a field value greater than zero, the check is 2501 passed.

2502 If the request contains a Max-Forwards header field with a field value of zero (0), the element must 2503 not forward the request. If the request was for OPTIONS, the element may act as the final recipient 2504 and respond per Section 11. Otherwise, the element must return a 483 (Too many hops) response.

2505 4. Optional Loop Detection check

2506 An element may check for forwarding loops before forwarding a request. If the request contains a 2507 Via header field with a sent-by value that equals a value placed into previous requests by the proxy, 2508 the request has been forwarded by this element before. The request has either looped or is legitimately 2509 spiraling through the element. To determine if the request has looped, the element may perform the 2510 branch parameter calculation described in Step 8 of Section 16.6 on this message and compare it to 2511 the parameter received in that Via header field. If the parameters match, the request has looped. If 2512 they differ, the request is spiraling, and processing continues. If a loop is detected, the element may 2513 return a 482 (Loop Detected) response.

2514 5. Proxy-Require check

2515 Future extensions to this protocol may introduce features that require special handling by proxies. 2516 Endpoints will include a Proxy-Require header field in requests that use these features, telling the 2517 proxy not to process the request unless the feature is understood.

2518 If the request contains a Proxy-Require header field (Section 20.29) with one or more option-tags this 2519 element does not understand, the element must return a 420 (Bad Extension) response. The response 2520 must include an Unsupported (Section 20.40) header field listing those option-tags the element did 2521 not understand.

2522 6. Proxy-Authorization check

2523 If an element requires credentials before forwarding a request, the request must be inspected as 2524 described in Section 22.3. That section also defines what the element must do if the inspection fails.

2525 16.4 Route Information Preprocessing

2526 The proxy must inspect the Request-URI of the request. If the Request-URI of the request contains a 2527 value this proxy previously placed into a Record-Route header field (see Section 16.6 item 4), the proxy 2528 must replace the Request-URI in the request with the last value from the Route header field, and remove 2529 that value from the Route header field. The proxy must then proceed as if it received this modified request.

2530 This will only happen when the element sending the request to the proxy (which may have been an endpoint) 2531 is a strict router. This rewrite on receive is necessary to enable backwards compatibility with those elements. It 2532 also allows elements following this specification to preserve the Request-URI through strict-routing proxies (see 2533 Section 12.2.1.1).

2534 This requirement does not obligate a proxy to keep state in order to detect URIs it previously placed in Record-2535 Route header fields. Instead, a proxy need only place enough information in those URIs to recognize them as values 2536 it provided when they later appear.

2537 If the Request-URI contains an maddr parameter, the proxy must check to see if its value is in the set 2538 of addresses or domains the proxy is configured to be responsible for. If the Request-URI has an maddr 2539 parameter with a value the proxy is responsible for, and the request was received using the port and transport 2540 indicated (explicitly or by default) in the Request-URI, the proxy must strip the maddr and any non-default 2541 port or transport parameter and continue processing as if those values had not been present in the request.

2542 A request may arrive with an maddr matching the proxy, but on a port or transport different from that indicated 2543 in the URI. Such a request needs to be forwarded to the proxy using the indicated port and transport.

2544 If the first value in the Route header field indicates this proxy, the proxy must remove that value from 2545 the request.

2546 16.5 Determining request targets

2547 Next, the proxy calculates the target(s) of the request. The set of targets will either be predetermined 2548 by the contents of the request or will be obtained from an abstract location service. Each target in the set is 2549 represented as a URI. 2550 If the Request-URI of the request contains an maddr parameter, the Request-URI must be placed 2551 into the target set as the only target URI, and the proxy must proceed to Section 16.6. 2552 If the domain of the Request-URI indicates a domain this element is not responsible for, the Request-2553 URI must be placed into the target set as the only target, and the element must proceed to the task of 2554 Request Forwarding (Section 16.6).

2555 There are many circumstances in which a proxy might receive a request for a domain it is not responsible for. 2556 A firewall proxy handling outgoing calls (the way HTTP proxies handle outgoing requests) is an example of where 2557 this is likely to occur.

2558 If the target set for the request has not been predetermined as described above, this implies that the 2559 element is responsible for the domain in the Request-URI, and the element may use whatever mechanism 2560 it desires to determine where to send the request. Any of these mechanisms can be modeled as accessing an 2561 abstract Location Service. This may consist of obtaining information from a location service created by a SIP 2562 Registrar, reading a database, consulting a presence server, utilizing other protocols, or simply performing 2563 an algorithmic substitution on the Request-URI. When accessing the location service constructed by a 2564 registrar, the Request-URI must first be canonicalized as described in Section 10.3 before being used as 2565 an index. The output of these mechanisms is used to construct the target set. If the Request-URI contains 2566 a SIPS URI, all elements in the target set must be SIPS URIs. 2567 If the Request-URI does not provide sufficient information for the proxy to determine the target set, 2568 it should return a 485 (Ambiguous) response. This response should contain a Contact header field 2569 containing URIs of new addresses to be tried. For example, an INVITE to sip:John.Smith@company.com 2570 may be ambiguous at a proxy whose location service has multiple John Smiths listed. See Section 21.4.23 2571 for details. 2572 Any information in or about the request or the current environment of the element may be used in the 2573 construction of the target set. For instance, different sets may be constructed depending on contents or the 2574 presence of header fields and bodies, the time of day of the request’s arrival, the interface on which the 2575 request arrived, failure of previous requests, or even the element’s current level of utilization. 2576 As potential targets are located through these services, their URIs are added to the target set. Targets can 2577 only be placed in the target set once. If a target URI is already present in the set (based on the definition of 2578 equality for the URI type), it must not be added again. 2579 A proxy must not add additional targets to the target set if the Request-URI of the original request 2580 does not indicate a resource this proxy is responsible for.

2581 A proxy can only change the Request-URI of a request during forwarding if it is responsible for that URI. If 2582 the proxy is not responsible for that URI, it will not recurse on 3xx or 416 responses as described below.

2583 If the Request-URI of the original request indicates a resource this proxy is responsible for, the proxy 2584 may continue to add targets to the set after beginning Request Forwarding. It may use any information 2585 obtained during that processing to determine new targets. For instance, a proxy may choose to incorporate 2586 contacts obtained in a redirect response (3xx) into the target set. If a proxy uses a dynamic source of 2587 information while building the target set (for instance, if it consults a SIP Registrar), it should monitor 2588 that source for the duration of processing the request. New locations should be added to the target set as 2589 they become available. As above, any given URI must not be added to the set more than once.

2590 Allowing a URI to be added to the set only once reduces unnecessary network traffic, and in the case of incor-2591 porating contacts from redirect requests prevents infinite recursion.

2592 For example, a trivial location service is a ”no-op”, where the target URI is equal to the incoming request 2593 URI. The request is sent to a specific next hop proxy for further processing. During request forwarding of 2594 Section 16.6, Item 6, the identity of that next hop, expressed as a SIP or SIPS URI, is inserted as the top-most 2595 Route header field value into the request. 2596 If the Request-URI indicates a resource at this proxy that does not exist, the proxy must return a 404 2597 (Not Found) response. 2598 If the target set remains empty after applying all of the above, the proxy must return an error response, 2599 which should be the 480 (Temporarily Unavailable) response.

2600 16.6 Request Forwarding

2601 As soon as the target set is non-empty, a proxy may begin forwarding the request. A stateful proxy may 2602 process the set in any order. It may process multiple targets serially, allowing each client transaction to 2603 complete before starting the next. It may start client transactions with every target in parallel. It also may 2604 arbitrarily divide the set into groups, processing the groups serially and processing the targets in each group 2605 in parallel. 2606 A common ordering mechanism is to use the qvalue parameter of targets obtained from Contact header 2607 fields (see Section 20.10). Targets are processed from highest qvalue to lowest. Targets with equal qvalues 2608 may be processed in parallel. 2609 A stateful proxy must have a mechanism to maintain the target set as responses are received and associate 2610 the responses to each forwarded request with the original request. For the purposes of this model, this 2611 mechanism is a “response context” created by the proxy layer before forwarding the first request. 2612 For each target, the proxy forwards the request following these steps:

2613 1. Make a copy of the received request

2614 2. Update the Request-URI

2615 3. Update the Max-Forwards header field

2616 4. Optionally add a Record-route header field value

2617 5. Optionally add additional header fields

2618 6. Postprocess routing information

2619 7. Determine the next-hop address, port, and transport

2620 8. Add a Via header field value

2621 9. Add a Content-Length header field if necessary

2622 10. Forward the new request

2623 11. Set timer C

2624 Each of these steps is detailed below:

2625 1. Copy request

2626 The proxy starts with a copy of the received request. The copy must initially contain all of the header 2627 fields from the received request. Fields not detailed in the processing described below must not be 2628 removed. The copy should maintain the ordering of the header fields as in the received request. 2629 The proxy must not reorder field values with a common field name (See Section 7.3.1). The proxy 2630 must not add to, modify, or remove the message body.

2631 An actual implementation need not perform a copy; the primary requirement is that the processing for each 2632 next hop begin with the same request.

2633 2. Request-URI

2634 The Request-URI in the copy’s start line must be replaced with the URI for this target. If the URI 2635 contains any parameters not allowed in a Request-URI, they must be removed.

2636 This is the essence of a proxy’s role. This is the mechanism through which a proxy routes a request 2637 toward its destination.

2638 In some circumstances, the received Request-URI is placed into the target set without being modified. 2639 For that target, the replacement above is effectively a no-op.

2640 3. Max-Forwards

2641 If the copy contains a Max-Forwards header field, the proxy must decrement its value by one (1).

2642 If the copy does not contain a Max-Forwards header field, the proxy must add one with a field value 2643 which should be 70.

2644 Some existing UAs will not provide a Max-Forwards header field in a request.

2645 4. Record-Route

2646 If this proxy wishes to remain on the path of future requests in a dialog created by this request (as-2647 suming the request creates a dialog), it must insert a Record-Route header field value into the copy 2648 before any existing Record-Route header field values, even if a Route header field is already present.

2649 Requests establishing a dialog may contain a preloaded Route header field.

2650 If this request is already part of a dialog, the proxy should insert a Record-Route header field value 2651 if it wishes to remain on the path of future requests in the dialog. In normal endpoint operation as 2652 described in Section 12 these Record-Route header field values will not have any effect on the route 2653 sets used by the endpoints.

2654 The proxy will remain on the path if it chooses to not insert a Record-Route header field value into 2655 requests that are already part of a dialog. However, it would be removed from the path when an endpoint that 2656 has failed reconstitutes the dialog.

2657 A proxy may insert a Record-Route header field value into any request. If the request does not 2658 initiate a dialog, the endpoints will ignore the value. See Section 12 for details on how endpoints use 2659 the Record-Route header field values to construct Route header fields.

2660 Each proxy in the path of a request chooses whether to add a Record-Route header field value 2661 independently - the presence of a Record-Route header field in a request does not obligate this proxy 2662 to add a value.

2663 The URI placed in the Record-Route header field value must be a SIP URI. This URI must contain 2664 an lr parameter (see Section 19.1.1). This URI may be different for each destination the request is 2665 forwarded to. The URI should not contain the transport parameter unless the proxy has knowledge 2666 (such as in a private network) that the next downstream element that will be in the path of subsequent 2667 requests supports that transport.

2668 The URI this proxy provides will be used by some other element to make a routing decision. This proxy, in 2669 general, has no way to know what the capabilities of that element are, so it must restrict itself to the mandatory 2670 elements of a SIP implementation: SIP URIs and either the TCP or UDP transports.

2671 The URI placed in the Record-Route header field must resolve to the element inserting it (or a 2672 suitable stand-in) when the server location procedures of [4] are applied to it, so that subsequent 2673 requests reach the same SIP element. If the Request-URI contains a SIPS URI, the URI placed into 2674 the Record-Route header field must be a SIPS URI.

2675 If the URI placed in the Record-Route header field needs to be rewritten when it passes back through 2676 in a response, the URI must be distinct enough to locate at that time. (The request may spiral through 2677 this proxy, resulting in more than one Record-Route header field value being added). Item 8 of 2678 Section 16.7 recommends a mechanism to make the URI sufficiently distinct.

2679 The proxy may include parameters in the Record-Route header field value. These will be echoed in 2680 some responses to the request such as the 200 (OK) responses to INVITE. Such parameters may be 2681 useful for keeping state in the message rather than the proxy.

2682 If a proxy needs to be in the path of any type of dialog (such as one straddling a firewall), it should 2683 add a Record-Route header field value to every request with a method it does not understand since 2684 that method may have dialog semantics.

2685 The URI a proxy places into a Record-Route header field is only valid for the lifetime of any dialog 2686 created by the transaction in which it occurs. A dialog-stateful proxy, for example, may refuse to 2687 accept future requests with that value in the Request-URI after the dialog has terminated. Non-2688 dialog-stateful proxies, of course, have no concept of when the dialog has terminated, but they may 2689 encode enough information in the value to compare it against the dialog identifier of future requests 2690 and may reject requests not matching that information. Endpoints must not use a URI obtained 2691 from a Record-Route header field outside the dialog in which it was provided. See Section 12 for 2692 more information on an endpoint’s use of Record-Route header fields.

2693 Record-routing may be required by certain services where the proxy needs to observe all messages 2694 in a dialog. However, it slows down processing and impairs scalability and thus proxies should only 2695 record-route if required for a particular service.

2696 The Record-Route process is designed to work for any SIP request that initiates a dialog. INVITE is 2697 the only such request in this specification, but extensions to the protocol may define others.

2698 5. Add Additional Header Fields

2699 The proxy may add any other appropriate header fields to the copy at this point.

2700 6. Postprocess routing information

2701 A proxy may have a local policy that mandates that a request visit a specific set of proxies before being 2702 delivered to the destination. A proxy must ensure that all such proxies are loose routers. Generally, 2703 this can only be known with certainty if the proxies are within the same administrative domain. This 2704 set of proxies is represented by a set of URIs (each of which contains the lr parameter). This set must 2705 be pushed into the Route header field of the copy ahead of any existing values, if present. If the 2706 Route header field is absent, it must be added, containing that list of URIs. If the Request-URI 2707 specifies a SIPS URI, the set of URIs must all be converted to SIPS URI, if they were not already 2708 SIPS URI.

2709 If the proxy has a local policy that mandates that the request visit one specific proxy, an alternative to 2710 pushing a Route value into the Route header field is to bypass the forwarding logic of item 10 below, 2711 and instead just send the request to the address, port, and transport for that specific proxy. If the 2712 request has a Route header field, this alternative must not be used unless it is known that next hop 2713 proxy is a loose router. Otherwise, this approach may be used, but the Route insertion mechanism 2714 above is preferred for its robustness, flexibility, generality and consistency of operation. Furthermore, 2715 if the Request-URI contains a SIPS URI, TLS must be used to communicate with that proxy.

2716 If the copy contains a Route header field, the proxy must inspect the URI in its first value. If that 2717 URI does not contain a lr parameter, the proxy must modify the copy as follows:

2718 • The proxy must place the Request-URI into the Route header field as the last value.

2719 • The proxy must then place the first Route header field value into the Request-URI and remove 2720 that value from the Route header field.

2721 Appending the Request-URI to the Route header field is part of a mechanism used to pass the information 2722 in that Request-URI through strict-routing elements. ”Popping” the first Route header field value into the 2723 Request-URI formats the message the way a strict-routing element expects to receive it (with its own URI in 2724 the Request-URI and the next location to visit in the first Route header field value).

2725 7. Determine Next-Hop Address, Port, and Transport

2726 The proxy may have a local policy to send the request to a specific IP address, port, and transport, 2727 independent of the values of the Route and Request-URI. Such a policy must not be used if the 2728 proxy is not certain that the IP address, port, and transport correspond to a server that is a loose router. 2729 However, this mechanism for sending the request through a specific next hop is not recommended; 2730 instead a Route header field should be used for that purpose as described above.

2731 In the absence of such an overriding mechanism, the proxy applies the procedures listed in [4] as 2732 follows to determine where to send the request. If the proxy has reformatted the request to send to 2733 a strict-routing element as described in step 6 above, the proxy must apply those procedures to the 2734 Request-URI of the request. Otherwise, the proxy must apply the procedures to the first value in 2735 the Route header field, if present, else the Request-URI. The procedures will produce an ordered set 2736 of (address, port, transport) tuples.

2737 As described in [4], the proxy must attempt to deliver the message to the first tuple in that set, and 2738 proceed through the set in order until the delivery attempt succeeds.

2739 For each tuple attempted, the proxy must format the message as appropriate for the tuple and send 2740 the request using a new client transaction as detailed in steps 8 through 10. Since each attempt uses a 2741 new client transaction, it represents a new branch. Thus, the branch parameter provided with the Via 2742 header field inserted in step 8 must be different for each attempt.

2743 If the client transaction reports failure to send the request or a timeout from its state machine, the 2744 proxy continues to the next address in that ordered set. If the ordered set is exhausted, the request 2745 cannot be forwarded to this element in the target set. The proxy does not need to place anything in 2746 the response context, but otherwise acts as if this element of the target set returned a 408 (Request 2747 Timeout) final response.

2748 8. Add a Via header field value

2749 The proxy must insert a Via header field value into the copy before the existing Via header field 2750 values. The construction of this value follows the same guidelines of Section 8.1.1.7. This implies 2751 that the proxy will compute its own branch parameter, which will be globally unique for that branch, 2752 and contain the requisite magic cookie.

2753 Proxies choosing to detect loops have an additional constraint in the value they use for construction of 2754 the branch parameter. A proxy choosing to detect loops should create a branch parameter separable 2755 into two parts by the implementation. The first part must satisfy the constraints of Section 8.1.1.7 as 2756 described above. The second is used to perform loop detection and distinguish loops from spirals.

2757 Loop detection is performed by verifying that, when a request returns to a proxy, those fields hav-2758 ing an impact on the processing of the request have not changed. The value placed in this part of 2759 the branch parameter should reflect all of those fields (including any Route, Proxy-Require and 2760 Proxy-Authorization header fields). This is to ensure that if the request is routed back to the proxy 2761 and one of those fields changes, it is treated as a spiral and not a loop (Section 16.3 A common 2762 way to create this value is to compute a cryptographic hash of the To tag, From tag, Call-ID header 2763 field, the Request-URI of the request received (before translation) and the sequence number from 2764 the CSeq header field, in addition to any Proxy-Require and Proxy-Authorization header fields that 2765 may be present. The algorithm used to compute the hash is implementation-dependent, but MD5 2766 [34], expressed in hexadecimal, is a reasonable choice. (Base64 is not permissible for a token.)

2767 If a proxy wishes to detect loops, the “branch” parameter it supplies must depend on all information 2768 affecting processing of a request, including the incoming Request-URI and any header fields affecting the 2769 request’s admission or routing. This is necessary to distinguish looped requests from requests whose routing 2770 parameters have changed before returning to this server.

2771 The request method must not be included in the calculation of the branch parameter. In particular, 2772 CANCEL and ACK requests (for non-2xx responses) must have the same branch value as the cor-2773 responding request they cancel or acknowledge. The branch parameter is used in correlating those 2774 requests at the server handling them (see Sections 17.2.3 and 9.2).

2775 9. Add a Content-Length header field if necessary

2776 If the request will be sent to the next hop using a stream-based transport and the copy contains no 2777 Content-Length header field, the proxy must insert one with the correct value for the body of the 2778 request (see Section 20.14).

2779 10. Forward Request

2780 A stateful proxy must create a new client transaction for this request as described in Section 17.1 and 2781 instructs the transaction to send the request using the address, port and transport determined in step 7.

2782

2783 11. Set timer C

2784 In order to handle the case where an INVITE request never generates a final response, the TU uses 2785 a timer which is called timer C. Timer C must be set for each client transaction when an INVITE 2786 request is proxied. The timer must be larger than 3 minutes. Section 16.7 bullet 2 discusses how this 2787 timer is updated with provisional responses, and Section 16.8 discusses processing when it fires.

2788 16.7 Response Processing

2789 When a response is received by an element, it first tries to locate a client transaction (Section 17.1.3) match-2790 ing the response. If none is found, the element must process the response (even if it is an informational 2791 response) as a stateless proxy (described below). If a match is found, the response is handed to the client 2792 transaction.

2793 Forwarding responses for which a client transaction (or more generally any knowledge of having sent an associ-2794 ated request) is not found improves robustness. In particular, it ensures that “late” 2xx responses to INVITE requests 2795 are forwarded properly.

2796 As client transactions pass responses to the proxy layer, the following processing must take place:

2797 1. Find the appropriate response context

2798 2. Update timer C for provisional responses

2799 3. Remove the topmost Via

2800 4. Add the response to the response context

2801 5. Check to see if this response should be forwarded immediately

2802 6. When necessary, choose the best final response from the response context

2803 If no final response has been forwarded after every client transaction associated with the response 2804 context has been terminated, the proxy must choose and forward the “best” response from those it has 2805 seen so far.

2806 The following processing must be performed on each response that is forwarded. It is likely that 2807 more than one response to each request will be forwarded: at least each provisional and one final 2808 response.

2809 7. Aggregate authorization header field values if necessary

2810 8. Optionally rewrite Record-Route header field values

2811 9. Forward the response

2812 10. Generate any necessary CANCEL requests

2813 Each of the above steps are detailed below:

2814 1. Find Context

2815 The proxy locates the “response context” it created before forwarding the original request using the 2816 key described in Section 16.6. The remaining processing steps take place in this context.

2817 2. Update timer C for provisional responses

2818 For an INVITE transaction, if the response is a provisional response with status codes 101 to 199 2819 inclusive (i.e., anything but 100), the proxy must reset timer C for that client transaction. The timer 2820 may be reset to a different value, but this value must be greater than 3 minutes.

2821 3. Via

2822 The proxy removes the topmost Via header field value from the response.

2823 If no Via header field values remain in the response, the response was meant for this element and 2824 must not be forwarded. The remainder of the processing described in this section is not performed 2825 on this message, the UAC processing rules described in Section 8.1.3 are followed instead (transport 2826 layer processing has already occurred).

2827 This will happen, for instance, when the element generates CANCEL requests as described in Sec-2828 tion 10.

2829 4. Add response to context

2830 Final responses received are stored in the response context until a final response is generated on the 2831 server transaction associated with this context. The response may be a candidate for the best final 2832 response to be returned on that server transaction. Information from this response may be needed in 2833 forming the best response even if this response is not chosen.

2834 If the proxy chooses to recurse on any contacts in a 3xx response by adding them to the target set, it 2835 must remove them from the response before adding the response to the response context. However, 2836 a proxy must not recurse to a non-SIPS URI if the Request-URI of the original request was a SIPS 2837 URI. If the proxy recurses on all of the contacts in a 3xx response, the proxy should not add the 2838 resulting contactless response to the response context.

2839 Removing the contact before adding the response to the response context prevents the next element up-2840 stream from retrying a location this proxy has already attempted. 2841 3xx responses may contain a mixture of SIP, SIPS, and non-SIP URIs. A proxy may choose to recurse on 2842 the SIP and SIPS URIs and place the remainder into the response context to be returned potentially in the final 2843 response.

2844 If a proxy receives a 416 (Unsupported URI Scheme) response to a request whose Request-URI 2845 scheme was not SIP, but the scheme in the original received request was SIP or SIPS (that is, the 2846 proxy changed the scheme from SIP or SIPS to something else when it proxied a request), the proxy 2847 should add a new URI to the target set. This URI should be a SIP URI version of the non-SIP URI 2848 that was just tried. In the case of the tel URL, this is accomplished by placing the telephone-subscriber 2849 part of the tel URL into the user part of the SIP URI, and setting the hostpart to the domain where the 2850 prior request was sent. See Section 19.1.6 for more detail on forming SIP URIs from tel URLs.

2851 As with a 3xx response, if a proxy “recurses” on the 416 by trying a SIP or SIPS URI instead, the 416 2852 response should not be added to the response context.

2853 5. Check response for forwarding

2854 Until a final response has been sent on the server transaction, the following responses must be for-2855 warded immediately:

2856 • Any provisional response other than 100 (Trying) 2857 • Any 2xx response

2858 If a 6xx response is received, it is not immediately forwarded, but the stateful proxy should cancel 2859 all client pending transactions as described in Section 10, and it must not create any new branches 2860 in this context.

2861 This is a change from RFC 2543, which mandated that the proxy was to forward the 6xx response imme-2862 diately. For an INVITE transaction, this approach had the problem that a 2xx response could arrive on another 2863 branch, in which case the proxy would have to forward the 2xx. The result was that the UAC could receive 2864 a 6xx response followed by a 2xx response, which should never be allowed to happen. Under the new rules, 2865 upon receiving a 6xx, a proxy will issue a CANCEL request, which will generally result in 487 responses from 2866 all outstanding client transactions, and then at that point the 6xx is forwarded upstream.

2867 After a final response has been sent on the server transaction, the following responses must be for-2868 warded immediately:

2869 • Any 2xx response to an INVITE request

2870 A stateful proxy must not immediately forward any other responses. In particular, a stateful proxy 2871 must not forward any 100 (Trying) response. Those responses that are candidates for forwarding 2872 later as the “best” response have been gathered as described in step “Add Response to Context”.

2873 Any response chosen for immediate forwarding must be processed as described in steps “Aggregate 2874 Authorization Header Field Values” through “Record-Route”.

2875 This step, combined with the next, ensures that a stateful proxy will forward exactly one final response 2876 to a non-INVITE request, and either exactly one non-2xx response or one or more 2xx responses to 2877 an INVITE request.

2878 6. Choosing the best response

2879 A stateful proxy must send a final response to a response context’s server transaction if no final 2880 responses have been immediately forwarded by the above rules and all client transactions in this 2881 response context have been terminated.

2882 The stateful proxy must choose the “best” final response among those received and stored in the 2883 response context.

2884 If there are no final responses in the context, the proxy must send a 408 (Request Timeout) response 2885 to the server transaction.

2886 Otherwise, the proxy must forward a response from the responses stored in the response context. 2887 It must choose from the 6xx class responses if any exist in the context. If no 6xx class responses 2888 are present, the proxy should choose from the lowest response class stored in the response context. 2889 The proxy may select any response within that chosen class. The proxy should give preference to 2890 responses that provide information affecting resubmission of this request, such as 401, 407, 415, 420, 2891 and 484 if the 4xx class is chosen.

2892 A proxy which receives a 503 (Service Unavailable) response should not forward it upstream 2893 unless it can determine that any subsequent requests it might proxy will also generate a 503. In other 2894 words, forwarding a 503 means that the proxy knows it cannot service any requests, not just the one 2895 for the Request-URI in the request which generated the 503.

2896 The forwarded response must be processed as described in steps “Aggregate Authorization Header 2897 Field Values” through “Record-Route”.

2898 For example, if a proxy forwarded a request to 4 locations, and received 503, 407, 501, and 404 2899 responses, it may choose to forward the 407 (Proxy Authentication Required) response.

2900 1xx and 2xx responses may be involved in the establishment of dialogs. When a request does not 2901 contain a To tag, the To tag in the response is used by the UAC to distinguish multiple responses to 2902 a dialog creating request. A proxy must not insert a tag into the To header field of a 1xx or 2xx 2903 response if the request did not contain one. A proxy must not modify the tag in the To header field 2904 of a 1xx or 2xx response.

2905 Since a proxy may not insert a tag into the To header field of a 1xx response to a request that did not 2906 contain one, it cannot issue non-100 provisional responses on its own. However, it can branch the 2907 request to a UAS sharing the same element as the proxy. This UAS can return its own provisional 2908 responses, entering into an early dialog with the initiator of the request. The UAS does not have to be 2909 a discreet process from the proxy. It could be a virtual UAS implemented in the same code space as 2910 the proxy.

2911 3-6xx responses are delivered hop-hop. When issuing a 3-6xx response, the element is effectively 2912 acting as a UAS, issuing its own response, usually based on the responses received from downstream 2913 elements. An element should preserve the To tag when simply forwarding a 3-6xx response to a 2914 request that did not contain a To tag.

2915 A proxy must not modify the To tag in any forwarded response to a request that contains a To tag.

2916 While it makes no difference to the upstream elements if the proxy replaced the To tag in a forwarded 2917 3-6xx response, preserving the original tag may assist with debugging. 2918 When the proxy is aggregating information from several responses, choosing a To tag from among them 2919 is arbitrary, and generating a new To tag may make debugging easier. This happens, for instance, when 2920 combining 401 (Unauthorized) and 407 (Proxy Authentication Required) challenges, or combining Contact 2921 values from unencrypted and unauthenticated 3xx responses.

2922 7. Aggregate Authorization Header Field Values

2923 If the selected response is a 401 (Unauthorized) or 407 (Proxy Authentication Required), the proxy 2924 must collect any WWW-Authenticate and Proxy-Authenticate header field values from all other 2925 401 (Unauthorized) and 407 (Proxy Authentication Required) responses received so far in this re-2926 sponse context and add them to this response without modification before forwarding. The resulting 2927 401 (Unauthorized) or 407 (Proxy Authentication Required) response could have several WWW-2928 Authenticate AND Proxy-Authenticate header field values.

2929 This is necessary because any or all of the destinations the request was forwarded to may have re-2930 quested credentials. The client needs to receive all of those challenges and supply credentials for each 2931 of them when it retries the request. Motivation for this behavior is provided in Section 26.

2932 8. Record-Route

2933 If the selected response contains a Record-Route header field value originally provided by this proxy, 2934 the proxy may choose to rewrite the value before forwarding the response. This allows the proxy to 2935 provide different URIs for itself to the next upstream and downstream elements. A proxy may choose 2936 to use this mechanism for any reason. For instance, it is useful for multi-homed hosts.

2937 The new URI provided by the proxy must satisfy the same constraints on URIs placed in Record-2938 Route header fields in requests (see Step 4 of Section 16.6) with the following modifications:

2939 The URI should not contain the transport parameter unless the proxy has knowledge that the next 2940 upstream (as opposed to downstream) element that will be in the path of subsequent requests supports 2941 that transport.

2942 When a proxy does decide to modify the Record-Route header field in the response, one of the 2943 operations it performs is locating the Record-Route value that it had inserted. If the request spiraled, 2944 and the proxy inserted a Record-Route value in each iteration of the spiral, locating the correct value 2945 in the response (which must be the proper iteration in the reverse direction) is tricky. The rules above 2946 recommend that a proxy wishing to rewrite Record-Route header field values insert sufficiently 2947 distinct URIs into the Record-Route header field so that the right one may be selected for rewriting. 2948 A recommended mechanism to achieve this is for the proxy to append a unique identifier for the 2949 proxy instance to the user portion of the URI.

2950 When the response arrives, the proxy modifies the first Record-Route whose identifier matches the 2951 proxy instance. The modification results in a URI without this piece of data appended to the user 2952 portion of the URI. Upon the next iteration, the same algorithm (find the topmost Record-Route 2953 header field value with the parameter) will correctly extract the next Record-Route header field 2954 value inserted by that proxy.

2955 Not every response to a request to which a proxy adds a Record-Route header field value will contain 2956 a Record-Route header field. If the response does contain a Record-Route header field, it will contain the 2957 value the proxy added.

2958 9. Forward response

2959 After performing the processing described in steps “Aggregate Authorization Header Field Values” 2960 through “Record-Route”, the proxy may perform any feature specific manipulations on the selected 2961 response. The proxy must not add to, modify, or remove the message body. Unless otherwise 2962 specified, the proxy must not remove any header field values other than the Via header field value 2963 discussed in Section 16.7 Item 3. In particular, the proxy must not remove any “received” pa-2964 rameter it may have added to the next Via header field value while processing the request associated 2965 with this response. The proxy must pass the response to the server transaction associated with the 2966 response context. This will result in the response being sent to the location now indicated in the top-2967 most Via header field value. If the server transaction is no longer available to handle the transmission, 2968 the element must forward the response statelessly by sending it to the server transport. The server 2969 transaction might indicate failure to send the response or signal a timeout in its state machine. These 2970 errors would be logged for diagnostic purposes as appropriate, but the protocol requires no remedial 2971 action from the proxy.

2972 The proxy must maintain the response context until all of its associated transactions have been ter-2973 minated, even after forwarding a final response.

2974 10. Generate CANCELs

2975 If the forwarded response was a final response, the proxy must generate a CANCEL request for all 2976 pending client transactions associated with this response context. A proxy should also generate a 2977 CANCEL request for all pending client transactions associated with this response context when it 2978 receives a 6xx response. A pending client transaction is one that has received a provisional response, 2979 but no final response (it is in the proceeding state) and has not had an associated CANCEL generated 2980 for it. Generating CANCEL requests is described in Section 9.1.

2981 The requirement to CANCEL pending client transactions upon forwarding a final response does not 2982 guarantee that an endpoint will not receive multiple 200 (OK) responses to an INVITE. 200 (OK)

2983 responses on more than one branch may be generated before the CANCEL requests can be sent and 2984 processed. Further, it is reasonable to expect that a future extension may override this requirement to 2985 issue CANCEL requests.

2986 16.8 Processing Timer C

2987 If timer C should fire, the proxy must either reset the timer with any value it chooses, or terminate the 2988 client transaction. If the client transaction has received a provisional response, the proxy must generate a 2989 CANCEL request matching that transaction. If the client transaction has not received a provisional response, 2990 the proxy must behave as if the transaction received a 408 (Request Timeout) response. 2991 Allowing the proxy to reset the timer allows the proxy to dynamically extend the transaction’s lifetime 2992 based on current conditions (such as utilization) when the timer fires.

2993 16.9 Handling Transport Errors

2994 If the transport layer notifies a proxy of an error when it tries to forward a request (see Section 18.4), the 2995 proxy must behave as if the forwarded request received a 400 (Bad Request) response. 2996 If the proxy is notified of an error when forwarding a response, it drops the response. The proxy should 2997 not cancel any outstanding client transactions associated with this response context due to this notification.

2998 If a proxy cancels its outstanding client transactions, a single malicious or misbehaving client can cause all 2999 transactions to fail through its Via header field.

3000 16.10 CANCEL Processing

3001 A stateful proxy may generate a CANCEL to any other request it has generated at any time (subject to re-3002 ceiving a provisional response to that request as described in section 9.1). A proxy must cancel any pending 3003 client transactions associated with a response context when it receives a matching CANCEL request. 3004 A stateful proxy may generate CANCEL requests for pending INVITE client transactions based on the 3005 period specified in the INVITE’s Expires header field elapsing. However, this is generally unnecessary 3006 since the endpoints involved will take care of signaling the end of the transaction. 3007 While a CANCEL request is handled in a stateful proxy by its own server transaction, a new response 3008 context is not created for it. Instead, the proxy layer searches its existing response contexts for the server 3009 transaction handling the request associated with this CANCEL. If a matching response context is found, the 3010 element must immediately return a 200 (OK) response to the CANCEL request. In this case, the element is 3011 acting as a user agent server as defined in Section 8.2. Furthermore, the element must generate CANCEL 3012 requests for all pending client transactions in the context as described in Section 16.7 step 10. 3013 If a response context is not found, the element does not have any knowledge of the request to apply 3014 the CANCEL to. It must statelessly forward the CANCEL request (it may have statelessly forwarded the 3015 associated request previously).

3016 16.11 Stateless Proxy

3017 When acting statelessly, a proxy is a simple message forwarder. Much of the processing performed when 3018 acting statelessly is the same as when behaving statefully. The differences are detailed here. 3019 A stateless proxy does not have any notion of a transaction, or of the response context used to describe 3020 stateful proxy behavior. Instead, the stateless proxy takes messages, both requests and responses, directly 3021 from the transport layer (See section 18). As a result, stateless proxies do not retransmit messages on their 3022 own. They do, however, forward all retransmission they receive (they do not have the ability to distinguish 3023 a retransmission from the original message). Furthermore, when handling a request statelessly, an element 3024 must not generate its own 100 (Trying) or any other provisional response. 3025 A stateless proxy must validate a request as described in Section 16.3 3026 A stateless proxy must follow the request processing steps described in Sections 16.4 through 16.5 with 3027 the following exception:

3028 • A stateless proxy must choose one and only one target from the target set. This choice must only 3029 rely on fields in the message and time-invariant properties of the server. In particular, a retransmitted 3030 request must be forwarded to the same destination each time it is processed. Furthermore, CANCEL 3031 and non-Routed ACK requests must generate the same choice as their associated INVITE.

3032 A stateless proxy must follow the request processing steps described in Section 16.6 with the following 3033 exceptions:

3034 • The requirement for unique branch IDs across space and time applies to stateless proxies as well. 3035 However, a stateless proxy cannot simply use a random number generator to compute the first com-3036 ponent of the branch ID, as described in Section 16.6 bullet 8. This is because retransmissions of 3037 a request need to have the same value, and a stateless proxy cannot tell a retransmission from the 3038 original request. Therefore, the component of the branch parameter that makes it unique must be 3039 the same each time a retransmitted request is forwarded. Thus for a stateless proxy, the branch pa-3040 rameter must be computed as a combinatoric function of message parameters which are invariant on 3041 retransmission.

3042 The stateless proxy may use any technique it likes to guarantee uniqueness of its branch IDs across 3043 transactions. However, the following procedure is recommended. The proxy examines the branch 3044 ID in the topmost Via header field of the received request. If it begins with the magic cookie, the first 3045 component of the branch ID of the outgoing request is computed as a hash of the received branch ID. 3046 Otherwise, the first component of the branch ID is computed as a hash of the topmost Via, the tag in 3047 the To header field, the tag in the From header field, the Call-ID header field, the CSeq number (but 3048 not method), and the Request-URI from the received request. One of these fields will always vary 3049 across two different transactions.

3050 • All other message transformations specified in Section 16.6 must result in the same transformation 3051 of a retransmitted request. In particular, if the proxy inserts a Record-Route value or pushes URIs 3052 into the Route header field, it must place the same values in retransmissions of the request. As 3053 for the Via branch parameter, this implies that the transformations must be based on time-invariant 3054 configuration or retransmission-invariant properties of the request.

3055 • A stateless proxy determines where to forward the request as described for stateful proxies in Sec-3056 tion 16.6 Item 10. The request is sent directly to the transport layer instead of through a client trans-3057 action.

3058 Since a stateless proxy must forward retransmitted requests to the same destination and add identical branch 3059 parameters to each of them, it can only use information from the message itself and time-invariant configuration 3060 data for those calculations. If the configuration state is not time-invariant (for example, if a routing table is updated) 3061 any requests that could be affected by the change may not be forwarded statelessly during an interval equal to the 3062 transaction timeout window before or after the change. The method of processing the affected requests in that 3063 interval is an implementation decision. A common solution is to forward them transaction statefully.

3064 Stateless proxies must not perform special processing for CANCEL requests. They are processed by 3065 the above rules as any other requests. In particular, a stateless proxy applies the same Route header field 3066 processing to CANCEL requests that it applies to any other request. 3067 Response processing as described in Section 16.7 does not apply to a proxy behaving statelessly. When 3068 a response arrives at a stateless proxy, the proxy must inspect the sent-by value in the first (topmost) Via 3069 header field value. If that address matches the proxy (it equals a value this proxy has inserted into previous 3070 requests) the proxy must remove that header field value from the response and forward the result to the 3071 location indicated in the next Via header field value. The proxy must not add to, modify, or remove the 3072 message body. Unless specified otherwise, the proxy must not remove any other header field values. If 3073 the address does not match the proxy, the message must be silently discarded.

3074 16.12 Summary of Proxy Route Processing

3075 In the absence of local policy to the contrary, the processing a proxy performs on a request containing a 3076 Route header field can be summarized in the following steps.

3077 1. The proxy will inspect the Request-URI. If it indicates a resource owned by this proxy, the proxy 3078 will replace it with the results of running a location service. Otherwise, the proxy will not change the 3079 Request-URI.

3080 2. The proxy will inspect the URI in the topmost Route header field value. If it indicates this proxy, the 3081 proxy removes it from the Route header field (this route node has been reached).

3082 3. The proxy will forward the request to the resource indicated by the URI in the topmost Route header 3083 field value or in the Request-URI if no Route header field is present. The proxy determines the 3084 address, port and transport to use when forwarding the request by applying the procedures in [4] to 3085 that URI.

3086 If no strict-routing elements are encountered on the path of the request, the Request-URI will always 3087 indicate the target of the request.

3088 16.12.1 Examples

3089 16.12.1.1 Basic SIP Trapezoid This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with 3090 both proxies record-routing. Here is the flow. 3091 U1 sends:

3092 INVITE sip:callee@domain.com SIP/2.0
3093 Contact: sip:caller@u1.example.com

3094 to P1. P1 is an outbound proxy. P1 is not responsible for domain.com, so it looks it up in DNS and 3095 sends it there. It also adds a Record-Route header field value:

3096 INVITE sip:callee@domain.com SIP/2.0
3097 Contact: sip:caller@u1.example.com
3098 Record-Route: <sip:p1.example.com;lr>

3099 P2 gets this. It is responsible for domain.com so it runs a location service and rewrites the Request-3100 URI. It also adds a Record-Route header field value. There is no Route header field, so it resolves the new 3101 Request-URI to determine where to send the request:

3102 INVITE sip:callee@u2.domain.com SIP/2.0
3103 Contact: sip:caller@u1.example.com
3104 Record-Route: <sip:p2.domain.com;lr>
3105 Record-Route: <sip:p1.example.com;lr>

3106 The callee at u2.domain.com gets this and responds with a 200 OK:

3107 SIP/2.0 200 OK
3108 Contact: sip:callee@u2.domain.com
3109 Record-Route: <sip:p2.domain.com;lr>
3110 Record-Route: <sip:p1.example.com;lr>

3111 The callee at u2 also sets its dialog state’s remote target URI to sip:caller@u1.example.com and its route 3112 set to

3113 (<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)

3114 This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its dialog state’s remote target URI to 3115 sip:callee@u2.domain.com and its route set to

3116 (<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>)

3117 Since all the route set elements contain the lr parameter, U1 constructs the following BYE request:

3118 BYE sip:callee@u2.domain.com SIP/2.0
3119 Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>

3120 As any other element (including proxies) would do, it resolves the URI in the topmost Route header 3121 field value using DNS to determine where to send the request. This goes to P1. P1 notices that it is not 3122 responsible for the resource indicated in the Request-URI so it doesn’t change it. It does see that it is the 3123 first value in the Route header field, so it removes that value, and forwards the request to P2:

3124 BYE sip:callee@u2.domain.com SIP/2.0
3125 Route: <sip:p2.domain.com;lr>

3126 P2 also notices it is not responsible for the resource indicated by the Request-URI (it is responsible for 3127 domain.com, not u2.domain.com), so it doesn’t change it. It does see itself in the first Route header field 3128 value, so it removes it and forwards the following to u2.domain.com based on a DNS lookup against the 3129 Request-URI:

3130 BYE sip:callee@u2.domain.com SIP/2.0

3131 16.12.1.2 Traversing a strict-routing proxy In this scenario, a dialog is established across four prox-3132 ies, each of which adds Record-Route header field values. The third proxy implements the strict-routing 3133 procedures specified in RFC 2543 and the bis drafts up to bis-05.

3134 U1->P1->P2->P3->P4->U2

3135 The INVITE arriving at U2 contains

3136 INVITE sip:callee@u2.domain.com SIP/2.0
3137 Contact: sip:caller@u1.example.com
3138 Record-Route: <sip:p4.domain.com;lr>
3139 Record-Route: <sip:p3.middle.com>
3140 Record-Route: <sip:p2.example.com;lr>
3141 Record-Route: <sip:p1.example.com;lr>

3142 Which U2 responds to with a 200 OK. Later, U2 sends the following BYE request to P4 based on the 3143 first Route header field value.

3144 BYE sip:caller@u1.example.com SIP/2.0
3145 Route: <sip:p4.domain.com;lr>
3146 Route: <sip:p3.middle.com>
3147 Route: <sip:p2.example.com;lr>
3148 Route: <sip:p1.example.com;lr>

3149 P4 is not responsible for the resource indicated in the Request-URI so it will leave it alone. It notices 3150 that it is the element in the first Route header field value so it removes it. It then prepares to send the request 3151 based on the now first Route header field value of sip:p3.middle.com, but it notices that this URI does not 3152 contain the lr parameter, so before sending, it reformats the request to be:

3153 BYE sip:p3.middle.com SIP/2.0
3154 Route: <sip:p2.example.com;lr>
3155 Route: <sip:p1.example.com;lr>
3156 Route: <sip:caller@u1.example.com>

3157 P3 is a strict router, so it forwards the following to P2:

3158 BYE sip:p2.example.com;lr SIP/2.0
3159 Route: <sip:p1.example.com;lr>
3160 Route: <sip:caller@u1.example.com>

3161 P2 sees the request-URI is a value it placed into a Record-Route header field, so before further pro-3162 cessing, it rewrites the request to be

3163 BYE sip:caller@u1.example.com SIP/2.0
3164 Route: <sip:p1.example.com;lr>

3165 P2 is not responsible for u1.example.com so it sends the request to P1 based on the resolution of the 3166 Route header field value. 3167 P1 notices itself in the topmost Route header field value, so it removes it, resulting in:

3168 BYE sip:caller@u1.example.com SIP/2.0

3169 Since P1 is not responsible for u1.example.com and there is no Route header field, P1 will forward the 3170 request to u1.example.com based on the Request-URI.

3171 16.12.1.3 Rewriting Record-Route header field values In this scenario, U1 and U2 are in different 3172 private namespaces and they enter a dialog through a proxy P1, which acts as a gateway between the names-3173 paces.

3174 U1->P1->U2

3175 U1 sends:

3176 INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0
3177 Contact: <sip:caller@u1.leftprivatespace.com>

3178 P1 uses its location service and sends the following to U2:

3179 INVITE sip:callee@rightprivatespace.com SIP/2.0
3180 Contact: <sip:caller@u1.leftprivatespace.com>
3181 Record-Route: <sip:gateway.rightprivatespace.com;lr>

3182 U2 sends this 200 (OK) back to PI:

3183 SIP/2.0 200 OK
3184 Contact: <sip:callee@u2.rightprivatespace.com>
3185 Record-Route: <sip:gateway.rightprivatespace.com;lr>

3186 P1 rewrites its Record-Route header parameter to provide a value that U1 will find useful, and sends 3187 the following to U1:

3188 SIP/2.0 200 OK
3189 Contact: <sip:callee@u2.rightprivatespace.com>
3190 Record-Route: <sip:gateway.leftprivatespace.com;lr>

3191 Later, U1 sends the following BYE request to P1:

3192 BYE sip:callee@u2.rightprivatespace.com SIP/2.0
3193 Route: <sip:gateway.leftprivatespace.com;lr>

3194 which P1 forwards to U2 as

3195 BYE sip:callee@u2.rightprivatespace.com SIP/2.0

3196 17 Transactions

3197 SIP is a transactional protocol: interactions between components take place in a series of independent 3198 message exchanges. Specifically, a SIP transaction consists of a single request and any responses to that 3199 request, which include zero or more provisional responses and one or more final responses. In the case 3200 of a transaction where the request was an INVITE (known as an INVITE transaction), the transaction also 3201 includes the ACK only if the final response was not a 2xx response. If the response was a 2xx, the ACK is 3202 not considered part of the transaction.

3203 The reason for this separation is rooted in the importance of delivering all 200 (OK) responses to an INVITE 3204 to the UAC. To deliver them all to the UAC, the UAS alone takes responsibility for retransmitting them (see Sec-3205 tion 13.3.1.4), and the UAC alone takes responsibility for acknowledging them with ACK (see Section 13.2.2.4). 3206 Since this ACK is retransmitted only by the UAC, it is effectively considered its own transaction.

3207 Transactions have a client side and a server side. The client side is known as a client transaction and the 3208 server side as a server transaction. The client transaction sends the request, and the server transaction sends 3209 the response. The client and server transactions are logical functions that are embedded in any number of 3210 elements. Specifically, they exist within user agents and stateful proxy servers. Consider the example in 3211 Section 4. In this example, the UAC executes the client transaction, and its outbound proxy executes the 3212 server transaction. The outbound proxy also executes a client transaction, which sends the request to a 3213 server transaction in the inbound proxy. That proxy also executes a client transaction, which in turn sends 3214 the request to a server transaction in the UAS. This is shown in Figure 4.

Figure 4: Transaction relationships 3215 A stateless proxy does not contain a client or server transaction. The transaction exists between the UA 3216 or stateful proxy on one side, and the UA or stateful proxy on the other side. As far as SIP transactions are 3217 concerned, stateless proxies are effectively transparent. The purpose of the client transaction is to receive 3218 a request from the element in which the client is embedded (call this element the “Transaction User” or 3219 TU; it can be a UA or a stateful proxy), and reliably deliver the request to a server transaction. The client 3220 transaction is also responsible for receiving responses and delivering them to the TU, filtering out any re-3221 sponse retransmissions or disallowed responses (such as a response to ACK). Additionally, in the case of an 3222 INVITE request, the client transaction is responsible for generating the ACK request for any final response 3223 excepting a 2xx response. 3224 Similarly, the purpose of the server transaction is to receive requests from the transport layer and deliver 3225 them to the TU. The server transaction filters any request retransmissions from the network. The server 3226 transaction accepts responses from the TU and delivers them to the transport layer for transmission over the 3227 network. In the case of an INVITE transaction, it absorbs the ACK request for any final response excepting 3228 a 2xx response. 3229 The 2xx response and its ACK receive special treatment. This response is retransmitted only by a UAS, 3230 and its ACK generated only by the UAC. This end-to-end treatment is needed so that a caller knows the 3231 entire set of users that have accepted the call. Because of this special handling, retransmissions of the 2xx 3232 response are handled by the UA core, not the transaction layer. Similarly, generation of the ACK for the 2xx 3233 is handled by the UA core. Each proxy along the path merely forwards each 2xx response to INVITE and 3234 its corresponding ACK.

3235 17.1 Client Transaction

3236 The client transaction provides its functionality through the maintenance of a state machine. 3237 The TU communicates with the client transaction through a simple interface. When the TU wishes to 3238 initiate a new transaction, it creates a client transaction and passes it the SIP request to send and an IP 3239 address, port, and transport to which to send it. The client transaction begins execution of its state machine. 3240 Valid responses are passed up to the TU from the client transaction. 3241 There are two types of client transaction state machines, depending on the method of the request passed 3242 by the TU. One handles client transactions for INVITE requests. This type of machine is referred to as 3243 an INVITE client transaction. Another type handles client transactions for all requests except INVITE and 3244 ACK. This is referred to as a non-INVITE client transaction. There is no client transaction for ACK. If the 3245 TU wishes to send an ACK, it passes one directly to the transport layer for transmission. 3246 The INVITE transaction is different from those of other methods because of its extended duration. Nor-3247 mally, human input is required in order to respond to an INVITE. The long delays expected for sending a 3248 response argue for a three-way handshake. On the other hand, requests of other methods are expected to 3249 complete rapidly. Because of the non-INVITE transaction’s reliance on a two-way handshake, TUs should 3250 respond immediately to non-INVITE requests.

3251 17.1.1 INVITE Client Transaction

3252 17.1.1.1 Overview of INVITE Transaction The INVITE transaction consists of a three-way handshake. 3253 The client transaction sends an INVITE, the server transaction sends responses, and the client transaction 3254 sends an ACK. For unreliable transports (such as UDP), the client transaction retransmits requests at an 3255 interval that starts at T1 seconds and doubles after every retransmission. T1 is an estimate of the round-3256 trip time (RTT), and it defaults to 500 ms. Nearly all of the transaction timers described here scale with 3257 T1, and changing T1 adjusts their values. The request is not retransmitted over reliable transports. After 3258 receiving a 1xx response, any retransmissions cease altogether, and the client waits for further responses. 3259 The server transaction can send additional 1xx responses, which are not transmitted reliably by the server 3260 transaction. Eventually, the server transaction decides to send a final response. For unreliable transports, 3261 that response is retransmitted periodically, and for reliable transports, it is sent once. For each final response 3262 that is received at the client transaction, the client transaction sends an ACK, the purpose of which is to 3263 quench retransmissions of the response.

3264 17.1.1.2 Formal Description The state machine for the INVITE client transaction is shown in Figure 5. 3265 The initial state, “calling”, must be entered when the TU initiates a new client transaction with an INVITE 3266 request. The client transaction must pass the request to the transport layer for transmission (see Section 18). 3267 If an unreliable transport is being used, the client transaction must start timer A with a value of T1. If a 3268 reliable transport is being used, the client transaction should not start timer A (Timer A controls request 3269 retransmissions). For any transport, the client transaction must start timer B with a value of 64*T1 seconds 3270 (Timer B controls transaction timeouts). 3271 When timer A fires, the client transaction must retransmit the request by passing it to the transport 3272 layer, and must reset the timer with a value of 2*T1. The formal definition of retransmit within the context 3273 of the transaction layer is to take the message previously sent to the transport layer and pass it to the transport 3274 layer once more. 3275 When timer A fires 2*T1 seconds later, the request must be retransmitted again (assuming the client 3276 transaction is still in this state). This process must continue so that the request is retransmitted with intervals 3277 that double after each transmission. These retransmissions should only be done while the client transaction 3278 is in the “calling” state. 3279 The default value for T1 is 500 ms. T1 is an estimate of the RTT between the client and server trans-3280 actions. Elements may (though it is not recommended) use smaller values of T1 within closed, private 3281 networks that do not permit general Internet connection. T1 may be chosen larger, and this is recom-3282 mended if it is known in advance (such as on high latency access links) that the RTT is larger. Whatever 3283 the value of T1, the exponential backoffs on retransmissions described in this section must be used. 3284 If the client transaction is still in the “calling” state when timer B fires, the client transaction should 3285 inform the TU that a timeout has occurred. The client transaction must not generate an ACK. The value of 3286 64*T1 is equal to the amount of time required to send seven requests in the case of an unreliable transport. 3287 If the client transaction receives a provisional response while in the ”Calling” state, it transitions to the 3288 “proceeding” state. In the “proceeding” state, the client transaction should not retransmit the request any 3289 longer. Furthermore, the provisional response must be passed to the TU. Any further provisional responses 3290 must be passed up to the TU while in the “proceeding” state. 3291 When in either the ”Calling” or “Proceeding” states, reception of a response with status code from 3292 300-699 must cause the client transaction to transition to “Completed”. The client transaction must pass 3293 the received response up to the TU, and the client transaction must generate an ACK request, even if the 3294 transport is reliable (guidelines for constructing the ACK from the response are given in Section 17.1.1.3) 3295 and then pass the ACK to the transport layer for transmission. The ACK must be sent to the same address, 3296 port, and transport to which the original request was sent. The client transaction should start timer D 3297 when it enters the “Completed” state, with a value of at least 32 seconds for unreliable transports, and a 3298 value of zero seconds for reliable transports. Timer D reflects the amount of time that the server transaction 3299 can remain in the “Completed” state when unreliable transports are used. This is equal to Timer H in the 3300 INVITE server transaction, whose default is 64*T1. However, the client transaction does not know the value

Figure 5: INVITE client transaction

3301 of T1 in use by the server transaction, so an absolute minimum of 32s is used instead of basing Timer D on

3302 T1.

3303 Any retransmissions of the final response that are received while in the “Completed” state must cause 3304 the ACK to be re-passed to the transport layer for retransmission, but the newly received response must 3305 not be passed up to the TU. A retransmission of the response is defined as any response which would match 3306 the same client transaction based on the rules of Section 17.1.3.

3307 If timer D fires while the client transaction is in the “Completed” state, the client transaction must move 3308 to the terminated state, and it must inform the TU of the timeout. 3309 When in either the “Calling” or “Proceeding” states, reception of a 2xx response must cause the client 3310 transaction to enter the ”Terminated” state, and the response must be passed up to the TU. The handling of 3311 this response depends on whether the TU is a proxy core or a UAC core. A UAC core will handle generation 3312 of the ACK for this response, while a proxy core will always forward the 200 (OK) upstream. The differing 3313 treatment of 200 (OK) between proxy and UAC is the reason that handling of it does not take place in the 3314 transaction layer. 3315 The client transaction must be destroyed the instant it enters the ”Terminated” state. This is actually 3316 necessary to guarantee correct operation. The reason is that 2xx responses to an INVITE are treated differ-3317 ently; each one is forwarded by proxies, and the ACK handling in a UAC is different. Thus, each 2xx needs 3318 to be passed to a proxy core (so that it can be forwarded) and to a UAC core (so it can be acknowledged). No 3319 transaction layer processing takes place. Whenever a response is received by the transport, if the transport 3320 layer finds no matching client transaction (using the rules of Section 17.1.3), the response is passed directly 3321 to the core. Since the matching client transaction is destroyed by the first 2xx, subsequent 2xx will find no 3322 match and therefore be passed to the core.

3323 17.1.1.3 Construction of the ACK Request This section specifies the construction of ACK requests 3324 sent within the client transaction. A UAC core that generates an ACK for 2xx must instead follow the rules 3325 described in Section 13. 3326 The ACK request constructed by the client transaction must contain values for the Call-ID, From, and 3327 Request-URI that are equal to the values of those header fields in the request passed to the transport by 3328 the client transaction (call this the “original request”). The To header field in the ACK must equal the To 3329 header field in the response being acknowledged, and therefore will usually differ from the To header field 3330 in the original request by the addition of the tag parameter. The ACK must contain a single Via header 3331 field, and this must be equal to the top Via header field of the original request. The CSeq header field in 3332 the ACK must contain the same value for the sequence number as was present in the original request, but 3333 the method parameter must be equal to “ACK”. 3334 If the INVITE request whose response is being acknowledged had Route header fields, those header 3335 fields must appear in the ACK. This is to ensure that the ACK can be routed properly through any down-3336 stream stateless proxies. 3337 Although any request may contain a body, a body in an ACK is special since the request cannot be 3338 rejected if the body is not understood. Therefore, placement of bodies in ACK for non-2xx is not recom-3339 mended, but if done, the body types are restricted to any that appeared in the INVITE, assuming that the 3340 response to the INVITE was not 415. If it was, the body in the ACK may be any type listed in the Accept 3341 header field in the 415. 3342 For example, consider the following request:

3343 INVITE sip:bob@biloxi.com SIP/2.0
3344 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
3345 To: Bob <sip:bob@biloxi.com>
3346 From: Alice <sip:alice@atlanta.com>;tag=88sja8x
3347 Max-Forwards: 70
3348 Call-ID: 987asjd97y7atg
3349 CSeq: 986759 INVITE

3350 The ACK request for a non-2xx final response to this request would look like this:

3351 ACK sip:bob@biloxi.com SIP/2.0
3352 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff
3353 To: Bob <sip:bob@biloxi.com>;tag=99sa0xk
3354 From: Alice <sip:alice@atlanta.com>;tag=88sja8x
3355 Max-Forwards: 70
3356 Call-ID: 987asjd97y7atg
3357 CSeq: 986759 ACK

3358 17.1.2 Non-INVITE Client Transaction

3359 17.1.2.1 Overview of the non-INVITE Transaction Non-INVITE transactions do not make use of ACK. 3360 They are simple request-response interactions. For unreliable transports, requests are retransmitted at an in-3361 terval which starts at T1 and doubles until it hits T2. If a provisional response is received, retransmissions 3362 continue for unreliable transports, but at an interval of T2. The server transaction retransmits the last re-3363 sponse it sent, which can be a provisional or final response, only when a retransmission of the request is 3364 received. This is why request retransmissions need to continue even after a provisional response, they are to 3365 ensure reliable delivery of the final response. 3366 Unlike an INVITE transaction, a non-INVITE transaction has no special handling for the 2xx response. 3367 The result is that only a single 2xx response to a non-INVITE is ever delivered to a UAC.

3368 17.1.2.2 Formal Description The state machine for the non-INVITE client transaction is shown in Fig-3369 ure 6. It is very similar to the state machine for INVITE. 3370 The “Trying” state is entered when the TU initiates a new client transaction with a request. When 3371 entering this state, the client transaction should set timer F to fire in 64*T1 seconds. The request must be 3372 passed to the transport layer for transmission. If an unreliable transport is in use, the client transaction must 3373 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 3374 value of MIN(2*T1, T2). When the timer fires again, it is reset to a MIN(4*T1, T2). This process continues 3375 so that retransmissions occur with an exponentially increasing interval that caps at T2. The default value 3376 of T2 is 4s, and it represents the amount of time a non-INVITE server transaction will take to respond to a 3377 request, if it does not respond immediately. For the default values of T1 and T2, this results in intervals of 3378 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc. 3379 If Timer F fires while the client transaction is still in the “Trying” state, the client transaction should 3380 inform the TU about the timeout, and then it should enter the “Terminated” state. If a provisional response 3381 is received while in the “Trying” state, the response must be passed to the TU, and then the client transaction 3382 should move to the “Proceeding” state. If a final response (status codes 200-699) is received while in the 3383 “Trying” state, the response must be passed to the TU, and the client transaction must transition to the 3384 “Completed” state. 3385 If Timer E fires while in the “Proceeding” state, the request must be passed to the transport layer 3386 for retransmission, and Timer E must be reset with a value of T2 seconds. If timer F fires while in the 3387 “Proceeding” state, the TU must be informed of a timeout, and the client transaction must transition to the 3388 terminated state. If a final response (status codes 200-699) is received while in the “Proceeding” state, the 3389 response must be passed to the TU, and the client transaction must transition to the “Completed” state. 3390 Once the client transaction enters the “Completed” state, it must set Timer K to fire in T4 seconds for

Figure 6: non-INVITE client transaction

3391 unreliable transports, and zero seconds for reliable transports. The “Completed” state exists to buffer any 3392 additional response retransmissions that may be received (which is why the client transaction remains there 3393 only for unreliable transports). T4 represents the amount of time the network will take to clear messages 3394 between client and server transactions. The default value of T4 is 5s. A response is a retransmission when it 3395 matches the same transaction, using the rules specified in Section 17.1.3. If Timer K fires while in this state, 3396 the client transaction must transition to the “Terminated” state. 3397 Once the transaction is in the terminated state, it must be destroyed.

3398 17.1.3 Matching Responses to Client Transactions

3399 When the transport layer in the client receives a response, it has to determine which client transaction 3400 will handle the response, so that the processing of Sections 17.1.1 and 17.1.2 can take place. The branch 3401 parameter in the top Via header field is used for this purpose. A response matches a client transaction under 3402 two conditions:

3403 1. If the response has the same value of the branch parameter in the top Via header field as the branch 3404 parameter in the top Via header field of the request that created the transaction.

3405 2. If the method parameter in the CSeq header field matches the method of the request that created the 3406 transaction. The method is needed since a CANCEL request constitutes a different transaction, but 3407 shares the same value of the branch parameter.

3408 A response that matches a transaction matched by a previous response is considered a retransmission of 3409 that response. 3410 If a request is sent via multicast, it is possible that it will generate multiple responses from different 3411 servers. These responses will all have the same branch parameter in the topmost Via, but vary in the To 3412 tag. The first response received, based on the rules above, will be used, and others will be viewed as 3413 retransmissions. That is not an error; multicast SIP provides only a rudimentary “single-hop-discovery-3414 like” service that is limited to processing a single response. See Section 18.1.1 for details.

3415 17.1.4 Handling Transport Errors

3416 When the client transaction sends a request to the transport layer to be sent, the following procedures are 3417 followed if the transport layer indicates a failure. 3418 The client transaction should inform the TU that a transport failure has occurred, and the client trans-3419 action should transition directly to the ”Terminated” state. The TU will handle the failover mechanisms 3420 described in [4].

3421 17.2 Server Transaction

3422 The server transaction is responsible for the delivery of requests to the TU and the reliable transmission of 3423 responses. It accomplishes this through a state machine. Server transactions are created by the core when a 3424 request is received, and transaction handling is desired for that request (this is not always the case). 3425 As with the client transactions, the state machine depends on whether the received request is an INVITE 3426 request.

3427 17.2.1 INVITE Server Transaction

3428 The state diagram for the INVITE server transaction is shown in Figure 7. 3429 When a server transaction is constructed with a request, it enters the “Proceeding” state. The server 3430 transaction must generate a 100 (Trying) response unless it knows that the TU will generate a provisional Figure 7: INVITE server transaction

J. Rosenberg,H. Schulzrinne,G. Camarillo,A. Johnston,J. Peterson,R. Sparks,M. Handley,E. Schooler Expires Aug 2002 [Page 92]

3431 or final response within 200 ms, in which case it may generate a 100 (Trying) response. This provisional 3432 response is needed to quench request retransmissions rapidly in order to avoid network congestion. The 100 3433 (Trying) response is constructed according to the procedures in Section 8.2.6, except that the insertion of 3434 tags in the To header field of the response (when none was present in the request) is downgraded from may 3435 to should not. The request must be passed to the TU. 3436 The TU passes any number of provisional responses to the server transaction. So long as the server 3437 transaction is in the “Proceeding” state, each of these must be passed to the transport layer for transmission. 3438 They are not sent reliably by the transaction layer (they are not retransmitted by it) and do not cause a change 3439 in the state of the server transaction. If a request retransmission is received while in the “Proceeding” state, 3440 the most recent provisional response that was received from the TU must be passed to the transport layer 3441 for retransmission. A request is a retransmission if it matches the same server transaction based on the rules 3442 of Section 17.2.3. 3443 If, while in the “Proceeding” state, the TU passes a 2xx response to the server transaction, the server 3444 transaction must pass this response to the transport layer for transmission. It is not retransmitted by the 3445 server transaction; retransmissions of 2xx responses are handled by the TU. The server transaction must 3446 then transition to the “Terminated” state. 3447 While in the “Proceeding” state, if the TU passes a response with status code from 300 to 699 to the 3448 server transaction, the response must be passed to the transport layer for transmission, and the state machine 3449 must enter the “Completed” state. For unreliable transports, timer G is set to fire in T1 seconds, and is not 3450 set to fire for reliable transports.

3451 This is a change from RFC 2543, where responses were always retransmitted, even over reliable transports.

3452 When the “Completed” state is entered, timer H must be set to fire in 64*T1 seconds for all transports. 3453 Timer H determines when the server transaction abandons retransmitting the response. Its value is chosen 3454 to equal Timer B, the amount of time a client transaction will continue to retry sending a request. If timer G 3455 fires, the response is passed to the transport layer once more for retransmission, and timer G is set to fire in 3456 MIN(2*T1, T2) seconds. From then on, when timer G fires, the response is passed to the transport again for 3457 transmission, and timer G is reset with a value that doubles, unless that value exceeds T2, in which case it 3458 is reset with the value of T2. This is identical to the retransmit behavior for requests in the “Trying” state of 3459 the non-INVITE client transaction. Furthermore, while in the “Completed” state, if a request retransmission 3460 is received, the server should pass the response to the transport for retransmission. 3461 If an ACK is received while the server transaction is in the “Completed” state, the server transaction 3462 must transition to the “Confirmed” state. As Timer G is ignored in this state, any retransmissions of the 3463 response will cease. 3464 If timer H fires while in the “Completed” state, it implies that the ACK was never received. In this 3465 case, the server transaction must transition to the ”Terminated” state, and must indicate to the TU that a 3466 transaction failure has occurred. 3467 The purpose of the “Confirmed” state is to absorb any additional ACK messages that arrive, triggered 3468 from retransmissions of the final response. When this state is entered, timer I is set to fire in T4 seconds for 3469 unreliable transports, and zero seconds for reliable transports. Once timer I fires, the server must transition 3470 to the “Terminated” state. 3471 Once the transaction is in the ”Terminated” state, it must be destroyed. As with client transactions, this 3472 is needed to ensure reliability of the 2xx responses to INVITE.

Figure 8: non-INVITE server transaction

J. Rosenberg,H. Schulzrinne,G. Camarillo,A. Johnston,J. Peterson,R. Sparks,M. Handley,E. Schooler Expires Aug 2002 [Page 94]

3473 17.2.2 Non-INVITE Server Transaction

3474 The state machine for the non-INVITE server transaction is shown in Figure 8. 3475 The state machine is initialized in the “Trying” state and is passed a request other than INVITE or 3476 ACK when initialized. This request is passed up to the TU. Once in the “Trying” state, any further request 3477 retransmissions are discarded. A request is a retransmission if it matches the same server transaction, using 3478 the rules specified in Section 17.2.3. 3479 While in the “Trying” state, if the TU passes a provisional response to the server transaction, the server 3480 transaction must enter the “Proceeding” state. The response must be passed to the transport layer for 3481 transmission. Any further provisional responses that are received from the TU while in the “Proceeding” 3482 state must be passed to the transport layer for transmission. If a retransmission of the request is received 3483 while in the “Proceeding” state, the most recently sent provisional response must be passed to the transport 3484 layer for retransmission. If the TU passes a final response (status codes 200-699) to the server while in the 3485 “Proceeding” state, the transaction must enter the “Completed” state, and the response must be passed to 3486 the transport layer for transmission. 3487 When the server transaction enters the “Completed” state, it must set Timer J to fire in 64*T1 seconds 3488 for unreliable transports, and zero seconds for reliable transports. While in the “Completed” state, the server 3489 transaction must pass the final response to the transport layer for retransmission whenever a retransmission 3490 of the request is received. Any other final responses passed by the TU to the server transaction must be 3491 discarded while in the “Completed” state. The server transaction remains in this state until Timer J fires, at 3492 which point it must transition to the “Terminated” state. 3493 The server transaction must be destroyed the instant it enters the “Terminated” state.

3494 17.2.3 Matching Requests to Server Transactions

3495 When a request is received from the network by the server, it has to be matched to an existing transaction. 3496 This is accomplished in the following manner. 3497 The branch parameter in the topmost Via header field of the request is examined. If it is present and 3498 begins with the magic cookie “z9hG4bK”, the request was generated by a client transaction compliant to this 3499 specification. Therefore, the branch parameter will be unique across all transactions sent by that client. The 3500 request matches a transaction if the branch parameter in the request is equal to the one in the top Via header 3501 field of the request that created the transaction, the sent-by value in the top Via of the request is equal to 3502 the one in the request that created the transaction, and in the case of a CANCEL request, the method of 3503 the request that created the transaction was also CANCEL. This matching rule applies to both INVITE and 3504 non-INVITE transactions alike.

3505 The sent-by value is used as part of the matching process because there could be duplication of branch param-3506 eters from different clients; uniqueness in time is mandated for construction of the parameter, but not uniqueness in 3507 space.

3508 If the branch parameter in the top Via header field is not present, or does not contain the magic cookie, 3509 the following procedures are used. These exist to handle backwards compatibility with RFC 2543 compliant 3510 implementations. 3511 The INVITE request matches a transaction if the Request-URI, To tag, From tag, Call-ID, CSeq, and 3512 top Via header field match those of the INVITE request which created the transaction. In this case, the 3513 INVITE is a retransmission of the original one that created the transaction. The ACK request matches a 3514 transaction if the Request-URI, From tag, Call-ID, CSeq number (not the method), and top Via header 3515 field match those of the INVITE request which created the transaction, and the To tag of the ACK matches 3516 the To tag of the response sent by the server transaction. Matching is done based on the matching rules 3517 defined for each of those header fields. The usage of the tag in the To header field helps disambiguate ACK 3518 for 2xx from ACK for other responses at a proxy, which may have forwarded both responses (which can 3519 occur in unusual conditions). An ACK request that matches an INVITE transaction matched by a previous 3520 ACK is considered a retransmission of that previous ACK. 3521 For all other request methods, a request is matched to a transaction if the Request-URI, To tag, From 3522 tag, Call-ID Cseq (including the method), and top Via header field match those of the request that created 3523 the transaction. Matching is done based on the matching rules defined for each of those header fields. When 3524 a non-INVITE request matches an existing transaction, it is a retransmission of the request that created that 3525 transaction. 3526 Because the matching rules include the Request-URI, the server cannot match a response to a transac-3527 tion. When the TU passes a response to the server transaction, it must pass it to the specific server transaction 3528 for which the response is targeted.

3529 17.2.4 Handling Transport Errors

3530 When the server transaction sends a response to the transport layer to be sent, the following procedures are 3531 followed if the transport layer indicates a failure. 3532 First, the procedures in [4] are followed, which attempt to deliver the response to a backup. If those 3533 should all fail, based on the definition of failure in [4], the server transaction should inform the TU that a 3534 failure has occurred, and should transition to the terminated state.

3535 18 Transport

3536 The transport layer is responsible for the actual transmission of requests and responses over network trans-3537 ports. This includes determination of the connection to use for a request or response in the case of connection-3538 oriented transports. 3539 The transport layer is responsible for managing persistent connections for transport protocols like TCP 3540 and SCTP, or TLS over those, including ones opened to the transport layer. This includes connections 3541 opened by the client or server transports, so that connections are shared between client and server transport 3542 functions. These connections are indexed by the tuple formed from the address, port, and transport protocol 3543 at the far end of the connection. When a connection is opened by the transport layer, this index is set to the 3544 destination IP, port and transport. When the connection is accepted by the transport layer, this index is set to 3545 the source IP address, port number, and transport. Note that, because the source port is often ephemeral, but 3546 it cannot be known whether it is ephemeral or selected through procedures in [4], connections accepted by 3547 the transport layer will frequently not be reused. The result is that two proxies in a “peering” relationship 3548 using a connection-oriented transport frequently will have two connections in use, one for transactions 3549 initiated in each direction. 3550 It is recommended that connections be kept open for some implementation-defined duration after the 3551 last message was sent or received over that connection. This duration should at least equal the longest 3552 amount of time the element would need in order to bring a transaction from instantiation to the terminated 3553 state. This is to make it likely that transactions complete over the same connection on which they are 3554 initiated (for example, request, response, and in the case of INVITE, ACK for non-2xx responses). This 3555 usually means at least 64*T1 (see Section 17.1.1.1 for a definition of T1). However, it could be larger in an 3556 element that has a TU using a large value for timer C (bullet 11 of Section 16.6), for example. 3557 All SIP elements must implement UDP and TCP. SIP elements may implement other protocols.

3558 Making TCP mandatory for the UA is a substantial change from RFC 2543. It has arisen out of the need to 3559 handle larger messages, which must use TCP, as discussed below. Thus, even if an element never sends large 3560 messages, it may receive one and needs to be able to handle them.

3561 18.1 Clients

3562 18.1.1 Sending Requests

3563 The client side of the transport layer is responsible for sending the request and receiving responses. The 3564 user of the transport layer passes the client transport the request, an IP address, port, transport, and possibly 3565 TTL for multicast destinations. 3566 If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU 3567 is unknown, the request must be sent using TCP. This prevents fragmentation of messages over UDP 3568 and provides congestion control for larger messages. However, implementations must be able to handle 3569 messages up to the maximum datagram packet size. For UDP, this size is 65,535 bytes, including IP and 3570 UDP headers.

3571 The 200 byte “buffer” between the message size and the MTU accommodates the fact that the response in 3572 SIP can be larger than the request. This happens due to the addition of Record-Route header field values to the 3573 responses to INVITE, for example. With the extra buffer, the response can be about 170 bytes larger than the request, 3574 and still not be fragmented on IPv4 (about 30 bytes is consumed by IP/UDP, assuming no IPSec). 1300 is chosen 3575 when path MTU is not known, based on the assumption of a 1500 byte Ethernet MTU.

3576 If an element sends a request over TCP because of these message size constraints, and that request 3577 would have otherwise been sent over UDP, if the attempt to establish the connection generates either an 3578 ICMP Protocol Not Supported, or results in a TCP reset, the element should retry the request, using UDP. 3579 This is only to provide backwards compatibility with RFC 2543 compliant implementations that do not 3580 support UDP. It is anticipated that this behavior will be deprecated in a future revision of this specification. 3581 A client that sends a request to a multicast address must add the “maddr” parameter to its Via header 3582 field value containing the destination multicast address, and for IPv4, should add the “ttl” parameter with 3583 a value of 1. Usage of IPv6 multicast is not defined in this specification, and will be a subject of future 3584 standardization when the need arises. 3585 These rules result in a purposeful limitation of multicast in SIP. Its primary function is to provide an 3586 “single-hop-discovery-like” service, delivering a request to a group of homogeneous servers, where it is only 3587 required to process the response from any one of them. This functionality is most useful for registrations. 3588 In fact, based on the transaction processing rules in Section 17.1.3, the client transaction will accept the first 3589 response, and view any others as retransmissions because they all contain the same Via branch identifier. 3590 Before a request is sent, the client transport must insert a value of the ”sent-by” field into the Via header 3591 field. This field contains an IP address or host name, and port. The usage of an FQDN is recommended. 3592 This field is used for sending responses under certain conditions, described below. If the port is absent, the 3593 default value depends on the transport. It is 5060 for UDP, TCP and SCTP, 5061 for TLS. 3594 For reliable transports, the response is normally sent on the connection on which the request was re-3595 ceived. Therefore, the client transport must be prepared to receive the response on the same connection 3596 used to send the request. Under error conditions, the server may attempt to open a new connection to send 3597 the response. To handle this case, the transport layer must also be prepared to receive an incoming con-3598 nection on the source IP address from which the request was sent and port number in the ”sent-by” field. It 3599 also must be prepared to receive incoming connections on any address and port that would be selected by 3600 a server based on the procedures described in Section 5 of [4]. 3601 For unreliable unicast transports, the client transport must be prepared to receive responses on the 3602 source IP address from which the request is sent (as responses are sent back to the source address) and the 3603 port number in the ”sent-by” field. Furthermore, as with reliable transports, in certain cases the response 3604 will be sent elsewhere. The client must be prepared to receive responses on any address and port that would 3605 be selected by a server based on the procedures described in Section 5 of [4]. 3606 For multicast, the client transport must be prepared to receive responses on the same multicast group 3607 and port to which the request is sent (that is, it needs to be a member of the multicast group it sent the request

3608 to.)

3609 If a request is destined to an IP address, port, and transport to which an existing connection is open, it 3610 is recommended that this connection be used to send the request, but another connection may be opened 3611 and used. 3612 If a request is sent using multicast, it is sent to the group address, port, and TTL provided by the transport 3613 user. If a request is sent using unicast unreliable transports, it is sent to the IP address and port provided by 3614 the transport user.

3615 18.1.2 Receiving Responses

3616 When a response is received, the client transport examines the top Via header field value. If the value of 3617 the ”sent-by” parameter in that header field value does not correspond to a value that the client transport is 3618 configured to insert into requests, the response must be silently discarded. 3619 If there are any client transactions in existence, the client transport uses the matching procedures of Sec-3620 tion 17.1.3 to attempt to match the response to an existing transaction. If there is a match, the response must 3621 be passed to that transaction. Otherwise, the response must be passed to the core (whether it be stateless 3622 proxy, stateful proxy, or UA) for further processing. Handling of these “stray” responses is dependent on 3623 the core (a proxy will forward them, while a UA will discard, for example).

3624 18.2 Servers

3625 18.2.1 Receiving Requests

3626 A server should be prepared to received requests on any IP address, port and transport combination that can 3627 be the result of a DNS lookup on a SIP or SIPS URI [4] that is handed out for the purposes of communicating 3628 with that server. In this context, “handing out” includes placing a URI in a Contact header field in a 3629 REGISTER request or a any redirect response, or in a Record-Route header field in a request or response. 3630 A URI can also be “handed out” by placing it on a web page or business card. It is also recommended that 3631 a server listen for requests on the default SIP ports on all public interfaces. The typical exception would be 3632 private networks, or when multiple server instances are running on the same host. For any port and interface 3633 that a server listens on for UDP, it must listen on that same port and interface for TCP. This is because 3634 a message may need to be sent using TCP, rather than UDP, if it is too large. As a result, the converse is 3635 not true. A server need not, and indeed should not listen for UDP on a particular address and port just 3636 because it is listening on that same address and port for UDP. There may, of course, be other reasons why a 3637 server needs to listen for UDP on a particular address and port. 3638 When the server transport receives a request over any transport, it must examine the value of the ”sent-3639 by” parameter in the top Via header field value. If the host portion of the ”sent-by” parameter contains a 3640 domain name, or if it contains an IP address that differs from the packet source address, the server must 3641 add a “received” parameter to that Via header field value. This parameter must contain the source address 3642 from which the packet was received. This is to assist the server transport layer in sending the response, since 3643 it must be sent to the source IP address from which the request came. 3644 Consider a request received by the server transport which looks like, in part:

3645  INVITE sip:bob@Biloxi.com SIP/2.0
3646  Via: SIP/2.0/UDP bobspc.biloxi.com:5060

3647 The request is received with a source IP address of 1.2.3.4. Before passing the request up, the transport 3648 adds a ”received” parameter, so that the request would look like, in part:

3649  INVITE sip:bob@Biloxi.com SIP/2.0
3650  Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=1.2.3.4

3651 Next, the server transport attempts to match the request to a server transaction. It does so using the 3652 matching rules described in Section 17.2.3. If a matching server transaction is found, the request is passed 3653 to that transaction for processing. If no match is found, the request is passed to the core, which may 3654 decide to construct a new server transaction for that request. Note that when a UAS core sends a 2xx 3655 response to INVITE, the server transaction is destroyed. This means that when the ACK arrives, there will 3656 be no matching server transaction, and based on this rule, the ACK is passed to the UAS core, where it is 3657 processed.

3658 18.2.2 Sending Responses

3659 The server transport uses the value of the top Via header field in order to determine where to send a response. 3660 It must follow the following process:

3661 • If the “sent-protocol” is a reliable transport protocol such as TCP or SCTP, or TLS over those, 3662 the response must be sent using the existing connection to the source of the original request that 3663 created the transaction, if that connection is still open. This requires the server transport to maintain 3664 an association between server transactions and transport connections. If that connection is no longer 3665 open, the server should open a connection to the IP address in the ”received” parameter, if present, 3666 using the port in the ”sent-by” value, or the default port for that transport, if no port is specified. 3667 If that connection attempt fails, the server should use the procedures in [4] for servers in order to 3668 determine the IP address and port to open the connection and send the response to.

3669 • Otherwise, if the Via header field value contains a “maddr” parameter, the response must be for-3670 warded to the address listed there, using the port indicated in “sent-by”, or port 5060 if none is 3671 present. If the address is a multicast address, the response should be sent using the TTL indicated 3672 in the “ttl” parameter, or with a TTL of 1 if that parameter is not present.

3673 • Otherwise (for unreliable unicast transports), if the top Via has a ”received” parameter, the response 3674 must be sent to the address in the “received” parameter, using the port indicated in the “sent-by” 3675 value, or using port 5060 if none is specified explicitly. If this fails, for example, elicits an ICMP 3676 “port unreachable” response, the procedures of Section 5 of [4] should be used to determine where 3677 to send the response.

3678 • Otherwise, if it is not receiver-tagged, the response must be sent to the address indicated by the 3679 “sent-by” value, using the procedures in Section 5 of [4].

3680 18.3 Framing

3681 In the case of message-oriented transports (such as UDP), if the message has a Content-Length header 3682 field, the message body is assumed to contain that many bytes. If there are additional bytes in the transport 3683 packet beyond the end of the body, they must be discarded. If the transport packet ends before the end 3684 of the message body, this is considered an error. If the message is a response, it must be discarded. If its 3685 a request, the element should generate a 400 (Bad Request) response. If the message has no Content-3686 Length header field, the message body is assumed to end at the end of the transport packet. 3687 In the case of stream-oriented transports such as TCP, the Content-Length header field indicates the 3688 size of the body. The Content-Length header field must be used with stream oriented transports.

3689 18.4 Error Handling

3690 Error handling is independent of whether the message was a request or response. 3691 If the transport user asks for a message to be sent over an unreliable transport, and the result is an ICMP 3692 error, the behavior depends on the type of ICMP error. Host, network, port or protocol unreachable errors, 3693 or parameter problem errors should cause the transport layer to inform the transport user of a failure in 3694 sending. Source quench and TTL exceeded ICMP errors should be ignored. 3695 If the transport user asks for a request to be sent over a reliable transport, and the result is a connection 3696 failure, the transport layer should inform the transport user of a failure in sending.

3697 19 Common Message Components

3698 There are certain components of SIP messages that appear in various places within SIP messages (and 3699 sometimes, outside of them) that merit separate discussion.

3700 19.1 SIP and SIPS Uniform Resource Indicators

3701 A SIP or SIPS URI identifies a communications resource. Like all URIs, SIP and SIPS URIs may be placed 3702 in web pages, email messages, or printed literature. They contain sufficient information to initiate and 3703 maintain a communication session with the resource. 3704 Examples of communications resources include the following:

3705 • a user of an online service

3706 • an appearance on a multi-line phone

3707 • a mailbox on a messaging system

3708 • a PSTN number at a gateway service

3709 • a group (such as “sales” or “helpdesk”) in an organization 3710 A SIPS URI specifies that the resource be contacted securely. This means, in particular, that TLS is to 3711 be used between all elements, starting from the UAC, and ending at the UAS. Any resource described by a 3712 SIP URI can be “upgraded” to a SIPS URI by just changing the scheme, if it is desired to communicate with 3713 that resource securely.

3714 19.1.1 SIP and SIPS URI Components

3715 The “sip:” and “sips:” schemes follow the guidelines in RFC 2396 [5]. They use a form similar to the mailto 3716 URL, allowing the specification of SIP request-header fields and the SIP message-body. This makes it 3717 possible to specify the subject, media type, or urgency of sessions initiated by using a URI on a web page or 3718 in an email message. The formal syntax for a SIP or SIPS URI is presented in Section 25. Its general form, 3719 in the case of a SIP URI, is

3720 sip:user:password@host:port;uri-parameters?headers

3721 The format for a SIPS URI is the same, except that the scheme is “sips” instead of sip. These tokens, and 3722 some of the tokens in their expansions, have the following meanings:

3723 user: The identifier of a particular resource at the host being addressed. The term “host” in this context 3724 frequently refers to a domain. The “userinfo” of a URI consists of this user field, the password field, 3725 and the @ sign following them. The userinfo part of a URI is optional and may be absent when the 3726 destination host does not have a notion of users or when the host itself is the resource being identified. 3727 If the @ sign is present in a SIP or SIPS URI, the user field must not be empty.

3728 If the host being addressed can process telephone numbers, for instance, an Internet telephony gate-3729 way, a telephone-subscriber field defined in RFC 2806 [9] may be used to populate the user field. 3730 There are special escaping rules for encoding telephone-subscriber fields in SIP and SIPS URIs 3731 described in Section 19.1.2.

3732 password: A password associated with the user. While the SIP and SIPS URI syntax allows this field to 3733 be present, its use is not recommended, because the passing of authentication information in clear 3734 text (such as URIs) has proven to be a security risk in almost every case where it has been used. For 3735 instance, transporting a PIN number in this field exposes the PIN.

3736 Note that the password field is just an extension of user portion. Implementations not wishing to give 3737 special significance to the password portion of the field may simply treat “user:password” as a single 3738 string.

3739 host: The host providing the SIP resource. The host part contains either a fully-qualified domain name 3740 or numeric IPv4 or IPv6 address. Using the fully-qualified domain name form is recommended 3741 whenever possible.

3742 port: The port number where the request is to be sent.

3743 URI parameters: Parameters affecting a request constructed from the URI.

3744 URI parameters are added after the hostport component and are separated by semi-colons.

3745 URI parameters take the form:

3746 parameter-name ”=” parameter-value 3747 Even though an arbitrary number of URI parameters may be included in a URI, any given parameter-3748 name must not appear more than once.

3749 This extensible mechanism includes the transport, maddr, ttl, user, method and lr parameters.

3750 The transport parameter determines the transport mechanism to be used for sending SIP messages, 3751 as specified in [4]. SIP can use any network transport protocol. Parameter names are defined for 3752 UDP [14], TCP [15], and SCTP [16]. For a SIPS URI, the transport parameter must indicate a 3753 reliable transport.

3754 The maddr parameter indicates the server address to be contacted for this user, overriding any address 3755 derived from the host field. When an maddr parameter is present, the port and transport components 3756 of the URI apply to the address indicated in the maddr parameter value. [4] describes the proper 3757 interpretation of the transport, maddr, and hostport in order to obtain the destination address, port, 3758 and transport for sending a request.

3759 The maddr field has been used as a simple form of loose source routing. It allows a URI to specify a proxy 3760 that must be traversed en-route to the destination. Continuing to use the maddr parameter this way is strongly 3761 discouraged (the mechanisms that enable it are deprecated). Implementations should instead use the Route 3762 mechanism described in this document, establishing a pre-existing route set if necessary (see Section 8.1.1.1). 3763 This provides a full URI to describe the node to be traversed.

3764 The ttl parameter determines the time-to-live value of the UDP multicast packet and must only be 3765 used if maddr is a multicast address and the transport protocol is UDP. For example, to specify to call 3766 alice@atlanta.com using multicast to 239.255.255.1 with a ttl of 15, the following URI would 3767 be used:

3768  sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15

3769 The set of valid telephone-subscriber strings is a subset of valid user strings. The user URI pa-3770 rameter exists to distinguish telephone numbers from user names that happen to look like telephone 3771 numbers. If the user string contains a telephone number formatted as a telephone-subscriber, the 3772 user parameter value “phone” should be present. Even without this parameter, recipients of SIP 3773 and SIPS URIs may interpret the pre-@ part as a telephone number if local restrictions on the name 3774 space for user name allow it.

3775 The method of the SIP request constructed from the URI can be specified with the method parameter. 3776 The lr parameter, when present, indicates that the element responsible for this resource implements 3777 the routing mechanisms specified in this document. This parameter will be used in the URIs proxies 3778 place into Record-Route header field values, and may appear in the URIs in a pre-existing route set.

3779 This parameter is used to achieve backwards compatibility with systems implementing the strict-routing 3780 mechanisms of RFC 2543 and the rfc2543bis drafts up to bis-05. An element preparing to send a request 3781 based on a URI not containing this parameter can assume the receiving element implements strict-routing and 3782 reformat the message to preserve the information in the Request-URI.

3783 Since the uri-parameter mechanism is extensible, SIP elements must silently ignore any uri-parameters 3784 that they do not understand.

3785 Headers: Header fields to be included in a request constructed from the URI.

3786 Headers fields in the SIP request can be specified with the “?” mechanism within a URI. The header 3787 names and values are encoded in ampersand separated hname = hvalue pairs. The special hname 3788 “body” indicates that the associated hvalue is the message-body of the SIP request.

3789 Table 1 summarizes the use of SIP and SIPS URI components based on the context in which the URI 3790 appears. The external column describes URIs appearing anywhere outside of a SIP message, for instance on 3791 a web page or business card. Entries marked “m” are mandatory, those marked “o” are optional, and those 3792 marked “-” are not allowed. Elements processing URIs should ignore any disallowed components if they 3793 are present. The second column indicates the default value of an optional element if it is not present. “–” 3794 indicates that the element is either not optional, or has no default value. 3795 URIs in Contact header fields have different restrictions depending on the context in which the header 3796 field appears. One set applies to messages that establish and maintain dialogs (INVITE and its 200 (OK) 3797 response). The other applies to registration and redirection messages (REGISTER, its 200 (OK) response, 3798 and 3xx class responses to any method).

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

3799 19.1.2 Character Escaping Requirements

3800 SIP follows the requirements and guidelines of RFC 2396 [5] when defining the set of characters that must 3801 be escaped in a SIP URI, and uses its “”%” HEX HEX” mechanism for escaping. From RFC 2396:

3802 The set of characters actually reserved within any given URI component is defined by that com-3803 ponent. In general, a character is reserved if the semantics of the URI changes if the character 3804 is replaced with its escaped US-ASCII encoding. [5].

3805 Excluded US-ASCII characters [5], such as space and control characters and characters used as URI delim-3806 iters, also must be escaped. URIs must not contain unescaped space and control characters. 3807 For each component, the set of valid BNF expansions defines exactly which characters may appear 3808 unescaped. All other characters must be escaped. 3809 For example, “@” is not in the set of characters in the user component, so the user “j@s0n” must have 3810 at least the @ sign encoded, as in “j%40s0n”. 3811 Expanding the hname and hvalue tokens in Section 25 show that all URI reserved characters in header 3812 field names and values must be escaped. 3813 The telephone-subscriber subset of the user component has special escaping considerations. The set 3814 of characters not reserved in the RFC 2806 [9] description of telephone-subscriber contains a number 3815 of characters in various syntax elements that need to be escaped when used in SIP URIs. Any characters 3816 occurring in a telephone-subscriber that do not appear in an expansion of the BNF for the user rule must 3817 be escaped. 3818 Note that character escaping is not allowed in the host component of a SIP or SIPS URI (the % character 3819 is not valid in its expansion). This is likely to change in the future as requirements for Internationalized 3820 Domain Names are finalized. Current implementations must not attempt to improve robustness by treating 3821 received escaped characters in the host component as literally equivalent to their unescaped counterpart. The 3822 behavior required to meet the requirements of IDN may be significantly different.

3823 19.1.3 Example SIP and SIPS URIs

3824  sip:alice@atlanta.com
3825  sip:alice:secretword@atlanta.com;transport=tcp
3826  sips:alice@atlanta.com?subject=project%20x&priority=urgent
3827  sip:+1-212-555-1212:1234@gateway.com;user=phone
3828  sips:1212@gateway.com
3829  sip:alice@192.0.2.4
3830  sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
3831  sip:alice;day=tuesday@atlanta.com

3832 The last sample URI above has a user field value of “alice;day=tuesday”. The escaping rules defined 3833 above allow a semicolon to appear unescaped in this field. For the purposes of this protocol, the field is 3834 opaque. The structure of that value is only useful to the SIP element responsible for the resource.

3835 19.1.4 URI Comparison

3836 Some operations in this specification require determining whether two SIP or SIPS URIs are equivalent. 3837 In this specification, registrars need to compare bindings in Contact URIs in REGISTER requests (see 3838 Section 10.3.) SIP and SIPS URIs are compared for equality according to the following rules:

3839 • A SIP and SIPS URI are not equivalent, even if the rest of the URIs are equivalent.

3840 • Comparison of the userinfo of SIP and SIPS URIs is case-sensitive. This includes userinfo containing 3841 passwords or formatted as telephone-subscribers. Comparison of all other components of the URI 3842 is case-insensitive unless explicitly defined otherwise.

3843 • The ordering of parameters and header fields is not significant in comparing SIP and SIPS URIs.

3844 • Characters other than those in the “reserved” and “unsafe” sets (see RFC 2396 [5]) are equivalent to 3845 their “”%” HEX HEX” encoding.

3846 • An IP address that is the result of a DNS lookup of a host name does not match that host name.

3847 • For two URIs to be equal, the user, password, host, and port components must match.

3848 A URI omitting the user component will not match a URI that includes one. A URI omitting the 3849 password component will not match a URI that includes one.

3850 A URI omitting any component with a default value will not match a URI explicitly containing that 3851 component with its default value. For instance, a URI omitting the optional port component will 3852 not match a URI explicitly declaring port 5060. The same is true for the transport-parameter, ttl-3853 parameter, user-parameter, and method components.

3854 Defining sip:user@host to not be equivalent to sip:user@host:5060 is a change from RFC 2543. When de-3855 riving addresses from URIs, equivalent addresses are expected from equivalent URIs. The URI sip:user@host:5060 3856 will always resolve to port 5060. The URI sip:user@host may resolve to other ports through the DNS SRV 3857 mechanisms detailed in [4].

3858 • URI uri-parameter components are compared as follows

3859 – Any uri-parameter appearing in both URIs must match. 3860 – A user, ttl, or method uri-parameter appearing in only one URI never matches, even if it 3861 contains the default value. 3862 – A URI that includes an maddr parameter will not match a URI that contains no maddr param-3863 eter. 3864 – All other uri-parameters appearing in only one URI are ignored when comparing the URIs.

3865 • URI header components are never ignored. Any present header component must be present in 3866 both URIs and match for the URIs to match. The matching rules are defined for each header field in 3867 Section 20.

3868 The URIs within each of the following sets are equivalent:

3869 sip:%61lice@atlanta.com;transport=TCP
3870 sip:alice@AtLanTa.CoM;Transport=tcp

3871 sip:carol@chicago.com
3872 sip:carol@chicago.com;newparam=5
3873 sip:carol@chicago.com;security=on
3874 sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com
3875 sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com
3876 sip:alice@atlanta.com?subject=project%20x&priority=urgent
3877 sip:alice@atlanta.com?priority=urgent&subject=project%20x

3878 The URIs within each of the following sets are not equivalent:

3879 SIP:ALICE@AtLanTa.CoM;Transport=udp                 (different usernames)
3880 sip:alice@AtLanTa.CoM;Transport=UDP

3881 sip:bob@biloxi.com                        (can resolve to different ports)
3882 sip:bob@biloxi.com:5060
3883 sip:bob@biloxi.com                  (can resolve to different transports)
3884 sip:bob@biloxi.com;transport=udp
3885 sip:bob@biloxi.com        (can resolve to different port and transports)
3886 sip:bob@biloxi.com:6000;transport=tcp

3887 sip:carol@chicago.com                         (different header component)
3888 sip:carol@chicago.com?Subject=next%20meeting
3889 sip:bob@phone21.boxesbybob.com       (even though that's what
3890 sip:bob@192.0.2.4                       phone21.boxesbybob.com resolves to)

3891 Note that equality is not transitive:

3892 sip:carol@chicago.com and sip:carol@chicago.com;security=on are equivalent

3893 and sip:carol@chicago.com and sip:carol@chicago.com;security=off are equivalent

3894 But sip:carol@chicago.com;security=on and sip:carol@chicago.com;security=off are not equivalent

3895 19.1.5 Forming Requests from a URI

3896 An implementation needs to take care when forming requests directly from a URI. URIs from business cards, 3897 web pages, and even from sources inside the protocol such as registered contacts may contain inappropriate 3898 header fields or body parts. 3899 An implementation must include any provided transport, maddr, ttl, or user parameter in the Request-3900 URI of the formed request. If the URI contains a method parameter, its value must be used as the method 3901 of the request. The method parameter must not be placed in the Request-URI. Unknown URI parameters 3902 must be placed in the message’s Request-URI. 3903 An implementation should treat the presence of any headers or body parts in the URI as a desire to 3904 include them in the message, and choose to honor the request on a per-component basis. 3905 An implementation should not honor these obviously dangerous header fields: From, Call-ID, CSeq, 3906 Via, and Record-Route. 3907 An implementation should not honor any requested Route header field values in order to not be used 3908 as an unwitting agent in malicious attacks.

3909 An implementation should not honor requests to include header fields that may cause it to falsely ad-3910 vertise its location or capabilities. These include: Accept, Accept-Encoding, Accept-Language, Allow, 3911 Contact (in its dialog usage), Organization, Supported, and User-Agent. 3912 An implementation should verify the accuracy of any requested descriptive header fields, including: 3913 Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-Type, Date, 3914 Mime-Version, and Timestamp. 3915 If the request formed from constructing a message from a given URI is not a valid SIP request, the URI 3916 is invalid. An implementation must not proceed with transmitting the request. It should instead pursue 3917 the course of action due an invalid URI in the context it occurs.

3918 The constructed request can be invalid in many ways. These include, but are not limited to, syntax error in 3919 header fields, invalid combinations of URI parameters, or an incorrect description of the message body.

3920 Sending a request formed from a given URI may require capabilities unavailable to the implementation. 3921 The URI might indicate use of an unimplemented transport or extension, for example. An implementation 3922 should refuse to send these requests rather than modifying them to match their capabilities. An imple-3923 mentation must not send a request requiring an extension that it does not support.

3924 For example, such a request can be formed through the presence of a Require header parameter or a method 3925 URI parameter with an unknown or explicitly unsupported value.

3926 19.1.6 Relating SIP URIs and tel URLs

3927 When a tel URL [9] is converted to a SIP or SIPS URI, the entire telephone-subscriber portion of the tel 3928 URL, including any parameters, is placed into the userinfo part of the SIP or SIPS URI. 3929 Thus, tel:+358-555-1234567;postd=pp22 becomes

3930  sip:+358-555-1234567;postd=pp22@foo.com;user=phone

3931 or

3932  sips:+358-555-1234567;postd=pp22@foo.com;user=phone

3933 not

3934  sip:+358-555-1234567@foo.com;postd=pp22;user=phone

3935 or

3936  sips:+358-555-1234567@foo.com;postd=pp22;user=phone

3937 In general, equivalent “tel” URLs converted to SIP or SIPS URIs in this fashion may not produce equiv-3938 alent SIP or SIPS URIs. The userinfo of SIP and SIPS URIs are compared as a case-sensitive string. 3939 Variance in case-insensitive portions of tel URLs and reordering of tel URL parameters does not affect tel 3940 URL equivalence, but does affect the equivalence of SIP URIs formed from them. 3941 For example,

3942  tel:+358-555-1234567;postd=pp22
3943  tel:+358-555-1234567;POSTD=PP22

3944 are equivalent, while

3945  sip:+358-555-1234567;postd=pp22@foo.com;user=phone

3946  sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone

3947 are not. 3948 Likewise,

3949  tel:+358-555-1234567;postd=pp22;isub=1411
3950  tel:+358-555-1234567;isub=1411;postd=pp22

3951 are equivalent, while

3952  sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone
3953  sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone

3954 are not. 3955 To mitigate this problem, elements constructing telephone-subscriber fields to place in the userinfo part 3956 of a SIP or SIPS URI should fold any case-insensitive portion of telephone-subscriber to lower case, 3957 and order the telephone-subscriber parameters lexically by parameter name. (All components of a tel URL 3958 except for future-extension parameters are defined to be compared case-insensitive.) 3959 Following this suggestion, both

3960  tel:+358-555-1234567;postd=pp22
3961  tel:+358-555-1234567;POSTD=PP22

3962 become

3963  sip:+358-555-1234567;postd=pp22@foo.com;user=phone

3964 and both

3965  tel:+358-555-1234567;postd=pp22;isub=1411
3966  tel:+358-555-1234567;isub=1411;postd=pp22

3967 become

3968  sip:+358-555-1234567;isub=1411;postd=pp22;user=phone

3969 19.2 Option Tags

3970 Option tags are unique identifiers used to designate new options (extensions) in SIP. These tags are used in 3971 Require (Section 20.32), Proxy-Require (Section 20.29), Supported (Section 20.37) and Unsupported 3972 (Section 20.40) header fields. Note that these options appear as parameters in those header fields in an 3973 option-tag = token form (see Section 25 for the definition of token). 3974 The creator of a new SIP option must either prefix the option with their reverse domain name or register 3975 the new option with the Internet Assigned Numbers Authority (IANA) (See Section 27). 3976 An example of a reverse-domain-name option is “com.foo.mynewfeature”, whose inventor can be reached 3977 at “foo.com”. For these features, individual organizations are responsible for ensuring that option names do 3978 not collide within the same domain. The domain name part of the option must use lower-case; the option 3979 name is case-insensitive. 3980 Options registered with IANA do not contain periods and are globally unique. IANA option tags are 3981 case-insensitive.

3982 19.3 Tags

3983 The “tag” parameter is used in the To and From header fields of SIP messages. It serves as a general 3984 mechanism to identify a dialog, which is the combination of the Call-ID along with two tags, one from 3985 each participant in the dialog. When a UA sends a request outside of a dialog, it contains a From tag only, 3986 providing “half” of the dialog ID. The dialog is completed from the response(s), each of which contributes 3987 the second half in the To header field. The forking of SIP requests means that multiple dialogs can be 3988 established from a single request. This also explains the need for the two-sided dialog identifier; without a 3989 contribution from the recipients, the originator could not disambiguate the multiple dialogs established from 3990 a single request. 3991 When a tag is generated by a UA for insertion into a request or response, it must be globally unique 3992 and cryptographically random with at least 32 bits of randomness. A property of this selection requirement 3993 is that a UA will place a different tag into the From header of an INVITE as it would place into the To 3994 header of the response to the same INVITE. This is needed in order for a UA to invite itself to a session, a 3995 common case for “hairpinning” of calls in PSTN gateways. Similarly, two INVITEs for different calls will 3996 have different From tags. 3997 Besides the requirement for global uniqueness, the algorithm for generating a tag is implementation-3998 specific. Tags are helpful in fault tolerant systems, where a dialog is to be recovered on an alternate server 3999 after a failure. A UAS can select the tag in such a way that a backup can recognize a request as part of a 4000 dialog on the failed server, and therefore determine that it should attempt to recover the dialog and any other 4001 state associated with it.

4002 20 Header Fields

4003 The general syntax for header fields is covered in Section 7.3. This section lists the full set of header fields 4004 along with notes on syntax, meaning, and usage. Throughout this section, we use [HX.Y] to refer to Section 4005 X.Y of the current HTTP/1.1 specification RFC 2616 [8]. Examples of each header field are given. 4006 Information about header fields in relation to methods and proxy processing is summarized in Tables 2 4007 and 3. 4008 The “where” column describes the request and response types in which the header field can be used. 4009 Values in this column are:

4010 R: header field may only appear in requests;

4011 r: header field may only appear in responses;

4012 2xx, 4xx, etc.: A numerical value or range indicates response codes with which the header field can be 4013 used;

4014 c: header field is copied from the request to the response.

4015 An empty entry in the “where” column indicates that the header field may be present in all requests and 4016 responses.

4017 The “proxy” column describes the operations a proxy may perform on a header field:

4018 a: A proxy can add or concatenate the header field if not present.

4019 m: A proxy can modify an existing header field value.

4020 d: A proxy can delete a header field value.

4021 r: A proxy must be able to read the header field, and thus this header field cannot be encrypted.

4022 The next six columns relate to the presence of a header field in a method:

4023 c: Conditional; the header field is either mandatory or optional, depending on the presence of a route set or 4024 the response code.

4025 m: The header field is mandatory.

4026 m*: The header field should be sent, but clients/servers need to be prepared to receive messages without 4027 that header field.

4028 o: The header field is optional.

4029 t: The header field should be sent, but clients/servers need to be prepared to receive messages without 4030 that header field. If a stream-based protocol (such as TCP) is used as a transport, then the header field 4031 must be sent.

4032 *: The header field is required if the message body is not empty. See sections 20.14, 20.15 and 7.4 for 4033 details.

4034 -: The header field is not applicable.

4035 “Optional” means that a UA may include the header field in a request or response, and a UA may ignore 4036 the header field if present in the request or response (The exception to this rule is the Require header field 4037 discussed in 20.32). A “mandatory” header field must be present in a request, and must be understood 4038 by the UAS receiving the request. A mandatory response header field must be present in the response, and 4039 the header field must be understood by the UAC processing the response. “Not applicable” means that the 4040 header field must not be present in a request. If one is placed in a request by mistake, it must be ignored 4041 by the UAS receiving the request. Similarly, a header field labeled “not applicable” for a response means 4042 that the UAS must not place the header field in the response, and the UAC must ignore the header field 4043 in the response. 4044 A UA should ignore extension header parameters that are not understood. 4045 A compact form of some common header field names is also defined for use when overall message size 4046 is an issue. 4047 The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark 4048 or semicolon, the URI must be enclosed in angle brackets (< and >). Any URI parameters are contained 4049 within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are 4050 header-parameters, not URI parameters.

INTERNET-DRAFT  draft-ietf-sip-rfc2543bis-07.9.ps  February 20, 2002
Header field  where proxy ACK BYE CAN INV OPT REG
Accept  R  -  o  -  o  m*  o
Accept  2xx  -  -  -  o  m*  o
Accept  415  -  o  -  o  o  o
Accept-Encoding  R  -  o  -  o  o  o
Accept-Encoding  2xx  -  -  -  o  m*  o
Accept-Encoding  415  -  o  -  o  o  o
Accept-Language  R  -  o  -  o  o  o
Accept-Language  2xx  -  -  -  o  m*  o
Accept-Language  415  -  o  -  o  o  o
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

J. Rosenberg,H. Schulzrinne,G. Camarillo,A. Johnston,J. Peterson,R. Sparks,M. Handley,E. Schooler Expires Aug 2002 [Page 111]

Header field  where  proxy ACK BYE CAN INV OPT REG
Priority  R  ar  -  -  -  o  -  -
Proxy-Authenticate  407  -  m  -  m  m  m
Proxy-Authenticate  401  -  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  -  o  -  o  o  o
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  -  o  o  o  o  o
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  -  m  -  m  m  m
WWW-Authenticate  407  -  o  -  o  o  o

Table 3: Summary of header fields, P–Z; (1): copied with possible addition of tag

4051 20.1 Accept

4052 The Accept header field follows the syntax defined in [H14.1]. The semantics are also identical, with 4053 the exception that if no Accept header field is present, the server should assume a default value of

4054 application/sdp.

4055 An empty Accept header field means that no formats are acceptable. 4056 Example:

4057  Accept: application/sdp;level=1, application/x-private, text/html

4058 20.2 Accept-Encoding

4059 The Accept-Encoding header field is similar to Accept, but restricts the content-codings [H3.5] that are 4060 acceptable in the response. See [H14.3]. The syntax of this header field is defined in [H14.3]. The semantics 4061 in SIP are identical to those defined in [H14.3].

4062 An empty Accept-Encoding header field is permissible, even though the syntax in [H14.3] does not 4063 provide for it. It is equivalent to Accept-Encoding: identity, that is, only the identity encoding, meaning 4064 no encoding, is permissible. 4065 If no Accept-Encoding header field is present, the server should assume a default value of identity. 4066 This differs slightly from the HTTP definition, which indicates that when not present, any encoding can 4067 be used, but the identity encoding is preferred. 4068 Example:

4069  Accept-Encoding: gzip

4070 20.3 Accept-Language

4071 The Accept-Language header field is used in requests to indicate the preferred languages for reason 4072 phrases, session descriptions, or status responses carried as message bodies in the response. If no Accept-4073 Language header field is present, the server should assume all languages are acceptable to the client. 4074 The Accept-Language header field follows the syntax defined in [H14.4]. The rules for ordering the 4075 languages based on the “q” parameter apply to SIP as well. 4076 Example:

4077  Accept-Language: da, en-gb;q=0.8, en;q=0.7

4078 20.4 Alert-Info

4079 When present in an INVITE request, the Alert-Info header field specifies an alternative ring tone to the UAS. 4080 When present in a 180 (Ringing) response, the Alert-Info header field specifies an alternative ringback tone 4081 to the UAC. A typical usage is for a proxy to insert this header field to provide a distinctive ring feature. 4082 The Alert-Info header field can introduce security risks. These risks and the ways to handle them are 4083 discussed in Section 20.9, which discusses the Call-Info header field since the risks are identical. 4084 In addition, a user should be able to disable this feature selectively.

4085 This helps prevent disruptions that could result from the use of this header field by untrusted elements.

4086 Example:

4087 Alert-Info: <http://www.example.com/sounds/moo.wav>

4088 20.5 Allow

4089 The Allow header field lists the set of methods supported by the UA generating the message. 4090 All methods, including ACK and CANCEL, understood by the UA must be included in the list of 4091 methods in the Allow header field, when present. The absence of an Allow header field must not be 4092 interpreted to mean that the UA sending the message supports no methods. Rather, it implies that the UA is 4093 not providing any information on what methods it supports. 4094 Supplying an Allow header field in responses to methods other than OPTIONS reduces the number of 4095 messages needed. 4096 Example:

4097  Allow: INVITE, ACK, OPTIONS, CANCEL, BYE

4098 20.6 Authentication-Info

4099 The Authentication-Info header field provides for mutual authentication with HTTP Digest. A UAS may 4100 include this header field in a 2xx response to a request that was successfully authenticated using digest based 4101 on the Authorization header field. 4102 Syntax and semantics follow those specified in RFC 2617 [17]. 4103 Example:

4104  Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"

4105 20.7 Authorization

4106 The Authorization header field contains authentication credentials of a UA. Section 22.2 overviews the use 4107 of the Authorization header field, and Section 22.4 describes the syntax and semantics when used with 4108 HTTP authentication. 4109 This header field, along with Proxy-Authorization, breaks the general rules about multiple header field 4110 values. Although not a comma-separated list, this header field name may be present multiple times, and 4111 must not be combined into a single header line using the usual rules described in Section 7.3. 4112 In the example below, there are no quotes around the Digest parameter:

4113  Authorization: Digest username="Alice", realm="atlanta.com",
4114  nonce="84a4cc6f3082121f32b42a2187831a9e",
4115  response="7587245234b3434cc3412213e5f113a5432"

4116 20.8 Call-ID

4117 The Call-ID header field uniquely identifies a particular invitation or all registrations of a particular client. 4118 A single multimedia conference can give rise to several calls with different Call-IDs, for example, if a user 4119 invites a single individual several times to the same (long-running) conference. Call-IDs are case-sensitive 4120 and are simply compared byte-by-byte. 4121 The compact form of the Call-ID header field is i. 4122 Examples:

4123  Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
4124  i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4

4125 20.9 Call-Info

4126 The Call-Info header field provides additional information about the caller or callee, depending on whether 4127 it is found in a request or response. The purpose of the URI is described by the “purpose” parameter. 4128 The “icon” parameter designates an image suitable as an iconic representation of the caller or callee. The 4129 “info” parameter describes the caller or callee in general, for example, through a web page. The “card” 4130 parameter provides a business card, for example, in vCard [35] or LDIF [36] formats. Additional tokens can 4131 be registered using IANA and the procedures in Section 27.

4132 Use of the Call-Info header field can pose a security risk. If a callee fetches the URIs provided by a 4133 malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or 4134 illegal content, and so on. Therefore, it is recommended that a UA only render the information in the 4135 Call-Info header field if it can verify the authenticity of the element that originated the header field and 4136 trusts that element. This need not be the peer UA; a proxy can insert this header field into requests. 4137 Example:

4138 Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
4139  <http://www.example.com/alice/> ;purpose=info

4140 20.10 Contact

4141 A Contact header field value provides a URI whose meaning depends on the type of request or response it 4142 is in. 4143 A Contact header field value can contain a display name, a URI with URI parameters, and header 4144 parameters. 4145 This document defines the Contact parameters “q” and “expires”. These parameters are only used 4146 when the Contact is present in a REGISTER request or response, or in a 3xx response. Additional param-4147 eters may be defined in other specifications. 4148 When the header field value contains a display name, the URI including all URI parameters is enclosed 4149 in “<” and “>”. If no “<” and “>” are present, all parameters after the URI are header parameters, not URI 4150 parameters. The display name can be tokens, or a quoted string, if a larger character set is desired. 4151 Even if the “display-name” is empty, the “name-addr” form must be used if the “addr-spec” con-4152 tains a comma, semicolon, or question mark. There may or may not be LWS between the display-name 4153 and the “<”. 4154 These rules for parsing a display name, URI and URI parameters, and header parameters also apply for 4155 the header fields To and From.

4156 The Contact header field has a role similar to the Location header field in HTTP. However, the HTTP header 4157 field only allows one address, unquoted. Since URIs can contain commas and semicolons as reserved characters, 4158 they can be mistaken for header or parameter delimiters, respectively.

4159 The compact form of the Contact header field is m (for “moved”). 4160 The second example below shows a Contact header field value containing both a URI parameter 4161 (transport) and a header parameter (expires).

4162  Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
4163  ;q=0.7; expires=3600,
4164  "Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
4165  m: <sips:bob@192.0.2.4>;expires=60

4166 20.11 Content-Disposition

4167 The Content-Disposition header field describes how the message body or, for multipart messages, a mes-4168 sage body part is to be interpreted by the UAC or UAS. This SIP header field extends the MIME Content-4169 Type (RFC 2183 [18]). 4170 The value “session” indicates that the body part describes a session, for either calls or early (pre-call) 4171 media. The value “render” indicates that the body part should be displayed or otherwise rendered to the 4172 user. For backward-compatibility, if the Content-Disposition header field is missing, the server should 4173 assume bodies of Content-Type application/sdp are the disposition “session”, while other content 4174 types are “render”. 4175 The disposition type “icon” indicates that the body part contains an image suitable as an iconic repre-4176 sentation of the caller or callee. The value “alert” indicates that the body part contains information, such as 4177 an audio clip, that should be rendered instead of ring tone. 4178 The handling parameter, handling-param, describes how the UAS should react if it receives a message 4179 body whose content type or disposition type it does not understand. The parameter has defined values 4180 of “optional” and “required”. If the handling parameter is missing, the value “required” should be 4181 assumed. 4182 If this header field is missing, the MIME type determines the default content disposition. If there is 4183 none, “render” is assumed. 4184 Example:

4185  Content-Disposition: session

4186 20.12 Content-Encoding

4187 The Content-Encoding header field is used as a modifier to the “media-type”. When present, its value 4188 indicates what additional content codings have been applied to the entity-body, and thus what decoding 4189 mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header 4190 field. Content-Encoding is primarily used to allow a body to be compressed without losing the identity of 4191 its underlying media type. 4192 If multiple encodings have been applied to an entity-body, the content codings must be listed in the 4193 order in which they were applied. 4194 All content-coding values are case-insensitive. IANA acts as a registry for content-coding value tokens. 4195 See [H3.5] for a definition of the syntax for content-coding. 4196 Clients may apply content encodings to the body in requests. A server may apply content encodings to 4197 the bodies in responses. The server must only use encodings listed in the Accept-Encoding header field 4198 in the request. 4199 The compact form of the Content-Encoding header field is e. Examples:

4200  Content-Encoding: gzip
4201  e: tar

4202 20.13 Content-Language

4203 See [H14.12]. Example:

4204  Content-Language: fr

4205 20.14 Content-Length

4206 The Content-Length header field indicates the size of the message-body, in decimal number of octets, 4207 sent to the recipient. Applications should use this field to indicate the size of the message-body to be 4208 transferred, regardless of the media type of the entity. If a stream-based protocol (such as TCP) is used as 4209 transport, the header field must be used. 4210 The size of the message-body does not include the CRLF separating header fields and body. Any 4211 Content-Length greater than or equal to zero is a valid value. If no body is present in a message, then 4212 the Content-Length header field value must be set to zero.

4213 The ability to omit Content-Length simplifies the creation of cgi-like scripts that dynamically generate re-4214 sponses.

4215 The compact form of the header field is l. 4216 Examples:

4217  Content-Length: 349
4218  l: 173

4219 20.15 Content-Type

4220 The Content-Type header field indicates the media type of the message-body sent to the recipient. The 4221 “media-type” element is defined in [H3.7]. The Content-Type header field must be present if the body is 4222 not empty. If the body is empty, and a Content-Type header field is present, it indicates that the body of the 4223 specific type has zero length (for example, an empty audio file). 4224 The compact form of the header field is c. 4225 Examples:

4226  Content-Type: application/sdp
4227  c: text/html; charset=ISO-8859-4

4228 20.16 CSeq

4229 A CSeq header field in a request contains a single decimal sequence number and the request method. 4230 The sequence number must be expressible as a 32-bit unsigned integer. The method part of CSeq is 4231 case-sensitive. The CSeq header field serves to order transactions within a dialog, to provide a means to 4232 uniquely identify transactions, and to differentiate between new requests and request retransmissions. Two 4233 CSeq header fields are considered equal if the sequence number and the request method are identical. 4234 Example:

4235  CSeq: 4711 INVITE

4236 20.17 Date

4237 The Date header field contains a the date and time. Unlike HTTP/1.1, SIP only supports the most recent 4238 RFC 1123 [19] format for dates. As in [H3.3], SIP restricts the time zone in SIP-date to “GMT”, while 4239 RFC 1123 allows any time zone. rfc1123-date is case-sensitive. 4240 The Date header field reflects the time when the request or response is first sent.

4241 The Date header field can be used by simple end systems without a battery-backed clock to acquire a notion of 4242 current time. However, in its GMT form, it requires clients to know their offset from GMT.

4243 Example:

4244  Date: Sat, 13 Nov 2010 23:29:00 GMT

4245 20.18 Error-Info

4246 The Error-Info header field provides a pointer to additional information about the error status response.

4247 SIP UACs have user interface capabilities ranging from pop-up windows and audio on PC softclients to audio-4248 only on ”black” phones or endpoints connected via gateways. Rather than forcing a server generating an error to 4249 choose between sending an error status code with a detailed reason phrase and playing an audio recording, the 4250 Error-Info header field allows both to be sent. The UAC then has the choice of which error indicator to render to the 4251 caller.

4252 A UAC may treat a SIP or SIPS URI in an Error-Info header field as if it were a Contact in a redirect 4253 and generate a new INVITE, resulting in a recorded announcement session being established. A non-SIP 4254 URI may be rendered to the user. 4255 Examples:

4256  SIP/2.0 404 The number you have dialed is not in service
4257  Error-Info: <sip:not-in-service-recording@atlanta.com>

4258 20.19 Expires

4259 The Expires header field gives the relative time after which the message (or content) expires. 4260 The precise meaning of this is method dependent. 4261 The expiration time in an INVITE does not affect the duration of the actual session that may result 4262 from the invitation. Session description protocols may offer the ability to express time limits on the session 4263 duration, however. 4264 The value of this field is an integral number of seconds (in decimal) between 0 and (2**31)-1, measured 4265 from the receipt of the request. 4266 Example:

4267  Expires: 5

4268 20.20 From

4269 The From header field indicates the initiator of the request. This may be different from the initiator of the 4270 dialog. Requests sent by the callee to the caller use the callee’s address in the From header field. 4271 The optional “display-name” is meant to be rendered by a human user interface. A system should use 4272 the display name “Anonymous” if the identity of the client is to remain hidden. Even if the “display-name” 4273 is empty, the “name-addr” form must be used if the “addr-spec” contains a comma, question mark, or 4274 semicolon. Syntax issues are discussed in Section 7.3.1. 4275 Section 12 describes how From header fields are compared for the purpose of matching requests to 4276 dialogs. See Section 20.10 for the rules for parsing a display name, URI and URI parameters, and header 4277 field parameters. 4278 The compact form of the From header field is f. 4279 Examples:

4280  From: "A. G. Bell" <sip:agb@bell-telephone.com> ;tag=a48s
4281  From: sip:+12125551212@server.phone2net.com;tag=887s
4282  f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8

4283 20.21 In-Reply-To

4284 The In-Reply-To header field enumerates the Call-IDs that this call references or returns. These Call-IDs 4285 may have been cached by the client then included in this header field in a return call.

4286 This allows automatic call distribution systems to route return calls to the originator of the first call. This also 4287 allows callees to filter calls, so that only return calls for calls they originated will be accepted. This field is not a 4288 substitute for request authentication.

4289 Example:

4290  In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com

4291 20.22 Max-Forwards

4292 The Max-Forwards header field must be used with any SIP method to limit the number of proxies or 4293 gateways that can forward the request to the next downstream server. This can also be useful when the client 4294 is attempting to trace a request chain that appears to be failing or looping in mid-chain. 4295 The Max-Forwards value is an integer in the range 0-255 indicating the remaining number of times this 4296 request message is allowed to be forwarded. This count is decremented by each server that forwards the 4297 request. The recommended value is 70. 4298 This header field should be inserted by elements that can not otherwise guarantee loop detection. For 4299 example, a B2BUA should insert a Max-Forwards header field. 4300 Example:

4301  Max-Forwards: 6

4302 20.23 Min-Expires

4303 The Min-Expires header field conveys the minimum refresh interval supported for soft-state elements man-4304 aged by that server. This includes Contact header fields that are stored by a registrar. The header field 4305 contains a decimal integer number of seconds from 0 to (2**32)-1. The use of the header field in a 423 4306 (Registration Too Brief) response is described in Sections 10.2.8, 10.3, and 21.4.17. 4307 Example:

4308  Min-Expires: 60

4309 20.24 MIME-Version

4310 See [H19.4.1]. 4311 Example:

4312  MIME-Version: 1.0

4313 20.25 Organization

4314 The Organization header field conveys the name of the organization to which the SIP element issuing the 4315 request or response belongs.

4316 The field may be used by client software to filter calls.

4317 Example:

4318  Organization: Boxes by Bob

4319 20.26 Priority

4320 The Priority header field indicates the urgency of the request as perceived by the client. The Priority header 4321 field describes the priority that the SIP request should have to the receiving human or its agent. For example, 4322 it may be factored into decisions about call routing and acceptance. For these decisions, a message contain-4323 ing no Priority header field should be treated as if it specified a Priority of “non-urgent”. The Priority 4324 header field does not influence the use of communications resources such as packet forwarding priority in 4325 routers or access to circuits in PSTN gateways. The header field can have the values “non-urgent”, “normal”, 4326 “urgent”, and “emergency”, but additional values can be defined elsewhere. It is recommended that the 4327 value of “emergency” only be used when life, limb, or property are in imminent danger. Otherwise, there 4328 are no semantics defined for this header field.

4329 These are the values of RFC 2076 [37], with the addition of “emergency”.

4330 Examples:

4331  Subject: A tornado is heading our way!
4332  Priority: emergency

4333 or

4334  Subject: Weekend plans
4335  Priority: non-urgent

4336 20.27 Proxy-Authenticate

4337 A Proxy-Authenticate header field value contains an authentication challenge. 4338 The syntax for this header field and its use is defined in [H14.33]. See 22.3 for further details on its 4339 usage. 4340 Example:

4341  Proxy-Authenticate: Digest realm="atlanta.com",
4342  domain="sip:ss1.carrier.com",
4343  nonce="f84f1cec41e6cbe5aea9c8e88d359",
4344  opaque="", stale=FALSE, algorithm=MD5

4345 20.28 Proxy-Authorization

4346 The Proxy-Authorization header field allows the client to identify itself (or its user) to a proxy that requires 4347 authentication. A Proxy-Authorization field value consists of credentials containing the authentication 4348 information of the user agent for the proxy and/or realm of the resource being requested.

4349 See [H14.34] for a definition of the syntax, and section 22.3 for a discussion of its usage. 4350 This header field, along with Authorization, breaks the general rules about multiple header field names. 4351 Although not a comma-separated list, this header field name may be present multiple times, and must not 4352 be combined into a single header line using the usual rules described in Section 7.3.1. 4353 Example:

4354 Proxy-Authorization: Digest username="Alice", realm="atlanta.com",
4355  nonce="c60f3082ee1212b402a21831ae",
4356  response="245f23415f11432b3434341c022"

4357 20.29 Proxy-Require

4358 The Proxy-Require header field is used to indicate proxy-sensitive features that must be supported by the 4359 proxy. See Section 20.32 for more details on the mechanics of this message and a usage example. 4360 Example:

4361  Proxy-Require: foo

4362 20.30 Record-Route

4363 The Record-Route header field is inserted by proxies in a request to force future requests in the dialog to 4364 be routed through the proxy. 4365 Examples of its use with the Route header field are described in Sections 16.12.1. 4366 Example:

4367  Record-Route: <sip:server10.biloxi.com;lr>, <sip:bigbox3.site3.atlanta.com;lr>

4368 20.31 Reply-To

4369 The Reply-To header field contains a logical return URI that may be different from the From header field. 4370 For example, the URI may be used to return missed calls or unestablished sessions. If the user wished to 4371 remain anonymous, the header field should either be omitted from the request or populated in such a way 4372 that does not reveal any private information. 4373 Even if the “display-name” is empty, the “name-addr” form must be used if the “addr-spec” con-4374 tains a comma, question mark, or semicolon. Syntax issues are discussed in Section 7.3.1. 4375 Example:

4376  Reply-To: Bob <sip:bob@biloxi.com>

4377 20.32 Require

4378 The Require header field is used by UACs to tell UASs about options that the UAC expects the UAS to 4379 support in order to process the request. Although an optional header field, the Require must not be 4380 ignored if it is present. 4381 The Require header field contains a list of option tags, described in Section 19.2. Each option tag 4382 defines a SIP extension that must be understood to process the request. Frequently, this is used to indicate 4383 that a specific set of extension header fields need to be understood. A UAC compliant to this specification 4384 must only include option tags corresponding to standards-track RFCs. 4385 Example:

4386  Require: 100rel

4387 20.33 Retry-After

4388 The Retry-After header field can be used with a 503 (Service Unavailable) response to indicate how long 4389 the service is expected to be unavailable to the requesting client and with a 404 (Not Found), 413 (Request 4390 Entity Too Large), 480 (Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603 (Decline) response 4391 to indicate when the called party anticipates being available again. The value of this field is a positive integer 4392 number of seconds (in decimal) after the time of the response. 4393 An optional comment can be used to indicate additional information about the time of callback. An 4394 optional “duration” parameter indicates how long the called party will be reachable starting at the initial 4395 time of availability. If no duration parameter is given, the service is assumed to be available indefinitely. 4396 Examples:

4397  Retry-After: 18000;duration=3600
4398  Retry-After: 120 (I'm in a meeting)

4399 20.34 Route

4400 The Route header field is used to force routing for a request through the listed set of proxies. Examples of 4401 the use of the Record-Route header field are in Section 16.12.1. 4402 Example:

4403  Route: <sip:bigbox3.site3.atlanta.com;lr>, <sip:server10.biloxi.com;lr>

4404 20.35 Server

4405 The Server header field contains information about the software used by the UAS to handle the request. 4406 The syntax for this field is defined in [H14.38]. 4407 Revealing the specific software version of the server might allow the server to become more vulnerable 4408 to attacks against software that is known to contain security holes. Implementers should make the Server 4409 header field a configurable option. 4410 Example:

4411  Server: HomeProxy v2

4412 20.36 Subject

4413 The Subject header field provides a summary or indicates the nature of the call, allowing call filtering 4414 without having to parse the session description. The session description does not have to use the same 4415 subject indication as the invitation. 4416 The compact form of the Subject header field is s.

4417 Example:

4418  Subject: Need more boxes
4419  s: Tech Support

4420 20.37 Supported

4421 The Supported header field enumerates all the extensions supported by the UAC or UAS. 4422 The Supported header field contains a list of option tags, described in Section 19.2, that are understood 4423 by the UAC or UAS. A UA compliant to this specification must only include option tags corresponding to 4424 standards-track RFCs. If empty, it means that no extensions are supported. 4425 Example:

4426  Supported: 100rel

4427 20.38 Timestamp

4428 The Timestamp header field describes when the UAC sent the request to the UAS. 4429 See Section 8.2.6 for details on how to generate a response to a request that contains the header field. 4430 Although there is no normative behavior defined here that makes use of the header, it allows for extensions 4431 or SIP applications to obtain RTT estimates. 4432 Example:

4433  Timestamp: 54

4434 20.39 To

4435 The To header field specifies the logical recipient of the request. 4436 The optional “display-name” is meant to be rendered by a human-user interface. The “tag” parameter 4437 serves as a general mechanism for dialog identification. 4438 See Section 19.3 for details of the “tag” parameter. 4439 Section 12 describes how To and From header fields are compared for the purpose of matching requests 4440 to dialogs. See Section 20.10 for the rules for parsing a display name, URI and URI parameters, and header 4441 field parameters. 4442 The compact form of the To header field is t. 4443 The following are examples of valid To header fields:

4444  To: The Operator <sip:operator@cs.columbia.edu>;tag=287447
4445  t: sip:+12125551212@server.phone2net.com

4446 20.40 Unsupported

4447 The Unsupported header field lists the features not supported by the UAS. See Section 20.32 for motivation. 4448 Example:

4449  Unsupported: foo

4450 20.41 User-Agent

4451 The User-Agent header field contains information about the UAC originating the request. The syntax and 4452 semantics are defined in [H14.43]. 4453 Revealing the specific software version of the user agent might allow the user agent to become more 4454 vulnerable to attacks against software that is known to contain security holes. Implementers should make 4455 the User-Agent header field a configurable option. 4456 Example:

4457  User-Agent: Softphone Beta1.5

4458 20.42 Via

4459 The Via header field indicates the path taken by the request so far and indicates the path that should be 4460 followed in routing responses. The branch ID parameter in the Via header field values serves as a transaction 4461 identifier, and is used by proxies to detect loops. 4462 A Via header field value contains the transport protocol used to send the message, the client’s host name 4463 or network address, and possibly the port number at which it wishes to receive responses. A Via header field 4464 value can also contain parameters such as “maddr”, “ttl”, “received”, and “branch”, whose meaning and 4465 use are described in other sections. 4466 Transport protocols defined here are “UDP”, “TCP”, “TLS”, and “SCTP”. “TLS” means TLS over 4467 TCP. When a request is sent to a SIPS URI, the protocol still indicates “SIP”, and the transport protocol is

4468 TLS.

4469  Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
4470  Via: SIP/2.0/UDP 128.59.16.1:5060 ;received=128.59.19.3;branch=z9hG4bK77asjd

4471 The compact form of the Via header field is v. 4472 In this example, the message originated from a multi-homed host with two addresses, 128.59.16.1 4473 and 128.59.19.3. The sender guessed wrong as to which network interface would be used. Erlang.bell-4474 telephone.com noticed the mismatch and added a parameter to the previous hop’s Via header field value, 4475 containing the address that the packet actually came from. 4476 The host or network address and port number are not required to follow the SIP URI syntax. Specifically, 4477 LWS on either side of the “:” or “/” is allowed, as shown here:

4478  Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16
4479  ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1

4480 Even though this specification mandates that the branch parameter be present in all requests, the BNF 4481 for the header field indicates that it is optional. This allows interoperation with RFC 2543 elements, which 4482 did not have to insert the branch parameter.

4483 20.43 Warning

4484 The Warning header field is used to carry additional information about the status of a response. Warning 4485 header field values are sent with responses and contain a three-digit warning code, host name, and warning 4486 text. 4487 The “warn-text” should be in a natural language that is most likely to be intelligible to the human user 4488 receiving the response. This decision can be based on any available knowledge, such as the location of the 4489 user, the Accept-Language field in a request, or the Content-Language field in a response. The default 4490 language is i-default [20]. 4491 The currently-defined “warn-code”s are listed below, with a recommended warn-text in English and a 4492 description of their meaning. These warnings describe failures induced by the session description. The first 4493 digit of warning codes beginning with “3” indicates warnings specific to SIP. Warnings 300 through 329 are 4494 reserved for indicating problems with keywords in the session description, 330 through 339 are warnings 4495 related to basic network services requested in the session description, 370 through 379 are warnings related 4496 to quantitative QoS parameters requested in the session description, and 390 through 399 are miscellaneous 4497 warnings that do not fall into one of the above categories.

4498 300 Incompatible network protocol: One or more network protocols contained in the session description 4499 are not available.

4500 301 Incompatible network address formats: One or more network address formats contained in the ses-4501 sion description are not available.

4502 302 Incompatible transport protocol: One or more transport protocols described in the session descrip-4503 tion are not available.

4504 303 Incompatible bandwidth units: One or more bandwidth measurement units contained in the session 4505 description were not understood.

4506 304 Media type not available: One or more media types contained in the session description are not avail-4507 able.

4508 305 Incompatible media format: One or more media formats contained in the session description are not 4509 available.

4510 306 Attribute not understood: One or more of the media attributes in the session description are not sup-4511 ported.

4512 307 Session description parameter not understood: A parameter other than those listed above was not 4513 understood.

4514 330 Multicast not available: The site where the user is located does not support multicast.

4515 331 Unicast not available: The site where the user is located does not support unicast communication (usu-4516 ally due to the presence of a firewall).

4517 370 Insufficient bandwidth: The bandwidth specified in the session description or defined by the media 4518 exceeds that known to be available.

4519 399 Miscellaneous warning: The warning text can include arbitrary information to be presented to a hu-4520 man user or logged. A system receiving this warning must not take any automated action.

4521 1xx and 2xx have been taken by HTTP/1.1.

4522 Additional “warn-code”s can be defined through IANA, as defined in Section 27.2. 4523 Examples:

4524  Warning: 307 isi.edu "Session parameter 'foo' not understood"
4525  Warning: 301 isi.edu "Incompatible network address type 'E.164'"

4526 20.44 WWW-Authenticate

4527 A WWW-Authenticate header field value contains an authentication challenge. The syntax for this header 4528 field and use is defined in [H14.47]. See 22.2 for further details on its usage. 4529 Example:

4530  WWW-Authenticate: Digest realm="atlanta.com",
4531  domain="sip:boxesbybob.com",
4532  nonce="f84f1cec41e6cbe5aea9c8e88d359",
4533  opaque="", stale=FALSE, algorithm=MD5

4534 21 Response Codes

4535 The response codes are consistent with, and extend, HTTP/1.1 response codes. Not all HTTP/1.1 response 4536 codes are appropriate, and only those that are appropriate are given here. Other HTTP/1.1 response codes 4537 should not be used. Also, SIP defines a new class, 6xx.

4538 21.1 Provisional 1xx

4539 Provisional responses, also known as informational responses, indicate that the server contacted is perform-4540 ing some further action and does not yet have a definitive response. A server sends a 1xx response if it 4541 expects to take more than 200 ms to obtain a final response. Note that 1xx responses are not transmitted 4542 reliably. They never cause the client to send an ACK. Provisional (1xx) responses may contain message 4543 bodies, including session descriptions.

4544 21.1.1 100 Trying

4545 This response indicates that the request has been received by the next-hop server and that some unspecified 4546 action is being taken on behalf of this call (for example, a database is being consulted). This response, like 4547 all other provisional responses, stops retransmissions of an INVITE by a UAC. The 100 (Trying) response 4548 is different from other provisional responses, in that it is never forwarded upstream by a stateful proxy.

4549 21.1.2 180 Ringing

4550 The UA receiving the INVITE is trying to alert the user. This response may be used to initiate local ringback.

4551 21.1.3 181 Call Is Being Forwarded

4552 A server may use this status code to indicate that the call is being forwarded to a different set of destinations.

4553 21.1.4 182 Queued

4554 The called party is temporarily unavailable, but the server has decided to queue the call rather than reject it. 4555 When the callee becomes available, it will return the appropriate final status response. The reason phrase 4556 may give further details about the status of the call, for example, “5 calls queued; expected waiting time is 4557 15 minutes”. The server may issue several 182 (Queued) responses to update the caller about the status of 4558 the queued call.

4559 21.1.5 183 Session Progress

4560 The 183 (Session Progress) response is used to convey information about the progress of the call that is not 4561 otherwise classified. The Reason-Phrase, header fields, or message body may be used to convey more 4562 details about the call progress.

4563 21.2 Successful 2xx

4564 The request was successful.

4565 21.2.1 200 OK

4566 The request has succeeded. The information returned with the response depends on the method used in the 4567 request.

4568 21.3 Redirection 3xx

4569 3xx responses give information about the user’s new location, or about alternative services that might be 4570 able to satisfy the call.

4571 21.3.1 300 Multiple Choices

4572 The address in the request resolved to several choices, each with its own specific location, and the user (or 4573 UA) can select a preferred communication end point and redirect its request to that location. 4574 The response may include a message body containing a list of resource characteristics and location(s) 4575 from which the user or UA can choose the one most appropriate, if allowed by the Accept request header 4576 field. However, no MIME types have been defined for this message body. 4577 The choices should also be listed as Contact fields (Section 20.10). Unlike HTTP, the SIP response 4578 may contain several Contact fields or a list of addresses in a Contact field. UAs may use the Contact 4579 header field value for automatic redirection or may ask the user to confirm a choice. However, this specifi-4580 cation does not define any standard for such automatic selection.

4581 This status response is appropriate if the callee can be reached at several different locations and the server cannot 4582 or prefers not to proxy the request.

4583 21.3.2 301 Moved Permanently

4584 The user can no longer be found at the address in the Request-URI, and the requesting client should retry 4585 at the new address given by the Contact header field (Section 20.10). The requestor should update any 4586 local directories, address books, and user location caches with this new value and redirect future requests to 4587 the address(es) listed.

4588 21.3.3 302 Moved Temporarily

4589 The requesting client should retry the request at the new address(es) given by the Contact header field 4590 (Section 20.10). The Request-URI of the new request uses the value of the Contact header field in the 4591 response. 4592 The duration of the validity of the Contact URI can be indicated through an Expires (Section 20.19) 4593 header field or an expires parameter in the Contact header field. Both proxies and UAs may cache this 4594 URI for the duration of the expiration time. If there is no explicit expiration time, the address is only valid 4595 once for recursing, and must not be cached for future transactions. 4596 If the URI cached from the Contact header field fails, the Request-URI from the redirected request 4597 may be tried again a single time.

4598 The temporary URI may have become out-of-date sooner than the expiration time, and a new temporary URI 4599 may be available.

4600 21.3.4 305 Use Proxy

4601 The requested resource must be accessed through the proxy given by the Contact field. The Contact field 4602 gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 (Use 4603 Proxy) responses must only be generated by UASs.

4604 21.3.5 380 Alternative Service

4605 The call was not successful, but alternative services are possible. The alternative services are described in 4606 the message body of the response. Formats for such bodies are not defined here, and may be the subject of 4607 future standardization.

4608 21.4 Request Failure 4xx

4609 4xx responses are definite failure responses from a particular server. The client should not retry the same 4610 request without modification (for example, adding appropriate authorization). However, the same request to 4611 a different server might be successful.

4612 21.4.1 400 Bad Request

4613 The request could not be understood due to malformed syntax. The Reason-Phrase should identify the 4614 syntax problem in more detail, for example, “Missing Call-ID header field”.

4615 21.4.2 401 Unauthorized

4616 The request requires user authentication. This response is issued by UASs and registrars, while 407 (Proxy 4617 Authentication Required) is used by proxy servers.

4618 21.4.3 402 Payment Required

4619 Reserved for future use.

4620 21.4.4 403 Forbidden

4621 The server understood the request, but is refusing to fulfill it. Authorization will not help, and the request 4622 should not be repeated.

4623 21.4.5 404 Not Found

4624 The server has definitive information that the user does not exist at the domain specified in the Request-4625 URI. This status is also returned if the domain in the Request-URI does not match any of the domains 4626 handled by the recipient of the request.

4627 21.4.6 405 Method Not Allowed

4628 The method specified in the Request-Line is understood, but not allowed for the address identified by the 4629 Request-URI. 4630 The response must include an Allow header field containing a list of valid methods for the indicated 4631 address.

4632 21.4.7 406 Not Acceptable

4633 The resource identified by the request is only capable of generating response entities that have content 4634 characteristics not acceptable according to the Accept header field sent in the request.

4635 21.4.8 407 Proxy Authentication Required

4636 This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with 4637 the proxy. SIP access authentication is explained in Sections 26 and 22.3. 4638 This status code can be used for applications where access to the communication channel (for example, 4639 a telephony gateway) rather than the callee requires authentication.

4640 21.4.9 408 Request Timeout

4641 The server could not produce a response within a suitable amount of time, for example, if it could not 4642 determine the location of the user in time. The client may repeat the request without modifications at any 4643 later time.

4644 21.4.10 410 Gone

4645 The requested resource is no longer available at the server and no forwarding address is known. This 4646 condition is expected to be considered permanent. If the server does not know, or has no facility to determine, 4647 whether or not the condition is permanent, the status code 404 (Not Found) should be used instead.

4648 21.4.11 413 Request Entity Too Large

4649 The server is refusing to process a request because the request entity-body is larger than the server is willing 4650 or able to process. The server may close the connection to prevent the client from continuing the request. 4651 If the condition is temporary, the server should include a Retry-After header field to indicate that it is 4652 temporary and after what time the client may try again.

4653 21.4.12 414 Request-URI Too Long

4654 The server is refusing to service the request because the Request-URI is longer than the server is willing to 4655 interpret.

4656 21.4.13 415 Unsupported Media Type

4657 The server is refusing to service the request because the message body of the request is in a format not sup-4658 ported by the server for the requested method. The server should return a list of acceptable formats using 4659 the Accept, Accept-Encoding and Accept-Language header fields. UAC processing of this response is 4660 described in Section 8.1.3.5.

4661 21.4.14 416 Unsupported URI Scheme

4662 The server cannot process the request because the scheme of the URI in the Request-URI is unknown to 4663 the server. Client processing of this response is described in Section 8.1.3.5.

4664 21.4.15 420 Bad Extension

4665 The server did not understand the protocol extension specified in a Proxy-Require (Section 20.29) or Re-4666 quire (Section 20.32) header field. The server should include a list of the unsupported extensions in an 4667 Unsupported header field in the response. UAC processing of this response is described in Section 8.1.3.5.

4668 21.4.16 421 Extension Required

4669 The UAS needs a particular extension to process the request, but this extension is not listed in a Supported 4670 header field in the request. Responses with this status code must contain a Require header field listing the 4671 required extensions. 4672 A UAS should not use this response unless it truly cannot provide any useful service to the client. 4673 Instead, if a desirable extension is not listed in the Supported header field, servers should process the 4674 request using baseline SIP capabilities and any extensions supported by the client.

4675 21.4.17 423 Interval Too Brief

4676 The server is rejecting the request because the expiration time of the resource refreshed by the request is too 4677 short. This response can be used by a registrar to reject a registration whose Contact header field expiration 4678 time was too small. The use of this response and the related Min-Expires header field are described in 4679 Sections 10.2.8, 10.3, and 20.23.

4680 21.4.18 480 Temporarily Unavailable

4681 The callee’s end system was contacted successfully but the callee is currently unavailable (for example, is 4682 not logged in, logged in but in a state that precludes communication with the callee, or has activated the “do 4683 not disturb” feature). The response may indicate a better time to call in the Retry-After header field. The 4684 user could also be available elsewhere (unbeknownst to this server). The reason phrase should indicate a 4685 more precise cause as to why the callee is unavailable. This value should be settable by the UA. Status 4686 486 (Busy Here) may be used to more precisely indicate a particular reason for the call failure. 4687 This status is also returned by a redirect or proxy server that recognizes the user identified by the 4688 Request-URI, but does not currently have a valid forwarding location for that user.

4689 21.4.19 481 Call/Transaction Does Not Exist

4690 This status indicates that the UAS received a request that does not match any existing dialog or transaction.

4691 21.4.20 482 Loop Detected

4692 The server has detected a loop (Section 16.3 Item 4).

4693 21.4.21 483 Too Many Hops

4694 The server received a request that contains a Max-Forwards (Section 20.22) header field with the value 4695 zero.

4696 21.4.22 484 Address Incomplete

4697 The server received a request with a Request-URI that was incomplete. Additional information should 4698 be provided in the reason phrase.

4699 This status code allows overlapped dialing. With overlapped dialing, the client does not know the length of the 4700 dialing string. It sends strings of increasing lengths, prompting the user for more input, until it no longer receives a 4701 484 (Address Incomplete) status response.

4702 21.4.23 485 Ambiguous

4703 The Request-URI was ambiguous. The response may contain a listing of possible unambiguous addresses 4704 in Contact header fields. Revealing alternatives can infringe on privacy of the user or the organization. It 4705 must be possible to configure a server to respond with status 404 (Not Found) or to suppress the listing of 4706 possible choices for ambiguous Request-URIs. 4707 Example response to a request with the Request-URI sip:lee@example.com:

4708 SIP/2.0 485 Ambiguous
4709 Contact: Carol Lee <sip:carol.lee@example.com>
4710 Contact: Ping Lee <sip:p.lee@example.com>
4711 Contact: Lee M. Foote <sips:lee.foote@example.com>

4712 Some email and voice mail systems provide this functionality. A status code separate from 3xx is used since 4713 the semantics are different: for 300, it is assumed that the same person or service will be reached by the choices 4714 provided. While an automated choice or sequential search makes sense for a 3xx response, user intervention is 4715 required for a 485 (Ambiguous) response.

4716 21.4.24 486 Busy Here

4717 The callee’s end system was contacted successfully, but the callee is currently not willing or able to take 4718 additional calls at this end system. The response may indicate a better time to call in the Retry-After header 4719 field. The user could also be available elsewhere, such as through a voice mail service. Status 600 (Busy 4720 Everywhere) should be used if the client knows that no other end system will be able to accept this call.

4721 21.4.25 487 Request Terminated

4722 The request was terminated by a BYE or CANCEL request. This response is never returned for a CANCEL 4723 request itself.

4724 21.4.26 488 Not Acceptable Here

4725 The response has the same meaning as 606 (Not Acceptable), but only applies to the specific resource 4726 addressed by the Request-URI and the request may succeed elsewhere. 4727 A message body containing a description of media capabilities may be present in the response, which is 4728 formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same 4729 as a message body in a 200 (OK) response to an OPTIONS request.

4730 21.4.27 491 Request Pending

4731 The request was received by a UAS that had a pending request within the same dialog. Section 14.2 describes 4732 how such “glare” situations are resolved.

4733 21.4.28 493 Undecipherable

4734 The request was received by a UAS that contained an encrypted MIME body for which the recipient does not 4735 possess or will not provide an appropriate decryption key. This response may have a single body containing 4736 an appropriate public key that should be used to encrypt MIME bodies sent to this UA. Details of the usage 4737 of this response code can be found in Section 23.2.

4738 21.5 Server Failure 5xx

4739 5xx responses are failure responses given when a server itself has erred.

4740 21.5.1 500 Server Internal Error

4741 The server encountered an unexpected condition that prevented it from fulfilling the request. The client may 4742 display the specific error condition and may retry the request after several seconds. 4743 If the condition is temporary, the server may indicate when the client may retry the request using the 4744 Retry-After header field.

4745 21.5.2 501 Not Implemented

4746 The server does not support the functionality required to fulfill the request. This is the appropriate response 4747 when a UAS does not recognize the request method and is not capable of supporting it for any user. (Proxies 4748 forward all requests regardless of method.) 4749 Note that a 405 (Method Not Allowed) is sent when the server recognizes the request method, but that 4750 method is not allowed or supported.

4751 21.5.3 502 Bad Gateway

4752 The server, while acting as a gateway or proxy, received an invalid response from the downstream server it 4753 accessed in attempting to fulfill the request.

4754 21.5.4 503 Service Unavailable

4755 The server is temporarily unable to process the request due to a temporary overloading or maintenance of 4756 the server. The server may indicate when the client should retry the request in a Retry-After header field. 4757 If no Retry-After is given, the client must act as if it had received a 500 (Server Internal Error) response. 4758 A client (proxy or UAC) receiving a 503 (Service Unavailable) should attempt to forward the request 4759 to an alternate server. It should not forward any other requests to that server for the duration specified in 4760 the Retry-After header field, if present. 4761 Servers may refuse the connection or drop the request instead of responding with 503 (Service Unavail-4762 able).

4763 21.5.5 504 Server Time-out

4764 The server did not receive a timely response from an external server it accessed in attempting to process the 4765 request. 408 (Request Timeout) should be used instead if there was no response within the period specified 4766 in the Expires header field from the upstream server.

4767 21.5.6 505 Version Not Supported

4768 The server does not support, or refuses to support, the SIP protocol version that was used in the request. The 4769 server is indicating that it is unable or unwilling to complete the request using the same major version as the 4770 client, other than with this error message.

4771 21.5.7 513 Message Too Large

4772 The server was unable to process the request since the message length exceeded its capabilities.

4773 21.6 Global Failures 6xx

4774 6xx responses indicate that a server has definitive information about a particular user, not just the particular 4775 instance indicated in the Request-URI.

4776 21.6.1 600 Busy Everywhere

4777 The callee’s end system was contacted successfully but the callee is busy and does not wish to take the call 4778 at this time. The response may indicate a better time to call in the Retry-After header field. If the callee 4779 does not wish to reveal the reason for declining the call, the callee uses status code 603 (Decline) instead. 4780 This status response is returned only if the client knows that no other end point (such as a voice mail system) 4781 will answer the request. Otherwise, 486 (Busy Here) should be returned.

4782 21.6.2 603 Decline

4783 The callee’s machine was successfully contacted but the user explicitly does not wish to or cannot partici-4784 pate. The response may indicate a better time to call in the Retry-After header field. This status response 4785 is returned only if the client knows that no other end point will answer the request.

4786 21.6.3 604 Does Not Exist Anywhere

4787 The server has authoritative information that the user indicated in the Request-URI does not exist anywhere.

4788 21.6.4 606 Not Acceptable

4789 The user’s agent was contacted successfully but some aspects of the session description such as the requested 4790 media, bandwidth, or addressing style were not acceptable. 4791 A 606 (Not Acceptable) response means that the user wishes to communicate, but cannot adequately 4792 support the session described. The 606 (Not Acceptable) response may contain a list of reasons in a Warn-4793 ing header field describing why the session described cannot be supported. Warning reason codes are listed 4794 in Section 20.43. 4795 A message body containing a description of media capabilities may be present in the response, which is 4796 formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same 4797 as a message body in a 200 (OK) response to an OPTIONS request. 4798 It is hoped that negotiation will not frequently be needed, and when a new user is being invited to join 4799 an already existing conference, negotiation may not be possible. It is up to the invitation initiator to decide 4800 whether or not to act on a 606 (Not Acceptable) response. 4801 This status response is returned only if the client knows that no other end point will answer the request.

4802 22 Usage of HTTP Authentication

4803 SIP provides a stateless, challenge-based mechanism for authentication that is based on authentication in 4804 HTTP. Any time that a proxy server or UA receives a request (with the exceptions given in Section 22.1), it 4805 may challenge the initiator of the request to provide assurance of its identity. Once the originator has been 4806 identified, the recipient of the request should ascertain whether or not this user is authorized to make the 4807 request in question. No authorization systems are recommended or discussed in this document. 4808 The “Digest” authentication mechanism described in this section provides message authentication and 4809 replay protection only, without message integrity or confidentiality. Protective measures above and beyond 4810 those provided by Digest need to be taken to prevent active attackers from modifying SIP requests and 4811 responses.

4812 Note that due to its weak security, the usage of “Basic” authentication has been deprecated. Servers 4813 must not accept credentials using the “Basic” authorization scheme, and servers also must not challenge 4814 with “Basic”. This is a change from RFC 2543.

4815 22.1 Framework

4816 The framework for SIP authentication closely parallels that of HTTP (RFC 2617 [17]). In particular, the 4817 BNF for auth-scheme, auth-param, challenge, realm, realm-value, and credentials is identical (al-4818 though the usage of “Basic” as a scheme is not permitted). In SIP, a UAS uses the 401 (Unauthorized) 4819 response to challenge the identity of a UAC. Additionally, registrars and redirect servers may make use 4820 of 401 (Unauthorized) responses for authentication, but proxies must not, and instead may use the 407 4821 (Proxy Authentication Required) response. The requirements for inclusion of the Proxy-Authenticate, 4822 Proxy-Authorization, WWW-Authenticate, and Authorization in the various messages are identical to 4823 those described in RFC 2617 [17]. 4824 Since SIP does not have the concept of a canonical root URL, the notion of protection spaces is in-4825 terpreted differently in SIP. The realm string alone defines the protection domain. This is a change from 4826 RFC 2543, in which the Request-URI and the realm together defined the protection domain.

4827 This previous definition of protection domain caused some amount of confusion since the Request-URI sent by 4828 the UAC and the Request-URI received by the challenging server might be different, and indeed the final form of 4829 the Request-URI might not be known to the UAC. Also, the previous definition depended on the presence of a SIP 4830 URI in the Request-URI and seemed to rule out alternative URI schemes (for example, the tel URL).

4831 Operators of user agents or proxy servers that will authenticate received requests must adhere to the 4832 following guidelines for creation of a realm string for their server:

4833 • Realm strings must be globally unique. It is recommended that a realm string contain a hostname 4834 or domain name, following the recommendation in Section 3.2.1 of RFC 2617 [17].

4835 • Realm strings should present a human-readable identifier that can be rendered to a user.

4836 For example:

4837  INVITE sip:bob@biloxi.com SIP/2.0
4838  Authorization: Digest realm="biloxi.com", <...>

4839 Generally, SIP authentication is meaningful for a specific realm, a protection domain. Thus, for Digest 4840 authentication, each such protection domain has its own set of usernames and passwords. If a server does 4841 not require authentication for a particular request, it may accept a default username, “anonymous”, which 4842 has no password (password of “”). Similarly, UACs representing many users, such as PSTN gateways, may 4843 have their own device-specific username and password, rather than accounts for particular users, for their 4844 realm. 4845 While a server can legitimately challenge most SIP requests, there are two requests defined by this 4846 document that require special handling for authentication: ACK and CANCEL. 4847 Under an authentication scheme that uses responses to carry values used to compute nonces (such as 4848 Digest), some problems come up for any requests that take no response, including ACK. For this reason, 4849 any credentials in the INVITE that were accepted by a server must be accepted by that server for the ACK. 4850 UACs creating an ACK message will duplicate all of the Authorization and Proxy-Authorization header 4851 field values that appeared in the INVITE to which the ACK corresponds. Servers must not attempt to 4852 challenge an ACK. 4853 Although the CANCEL method does take a response (a 2xx), servers must not attempt to challenge 4854 CANCEL requests since these requests cannot be resubmitted. Generally, a CANCEL request should be 4855 accepted by a server if it comes from the same hop that sent the request being canceled (provided that some 4856 sort of transport or network layer security association, as described in Section 26.2.1, is in place). 4857 When a UAC receives a challenge, it should render to the user the contents of the “realm” param-4858 eter in the challenge (which appears in either a WWW-Authenticate header field or Proxy-Authenticate 4859 header field) if the UAC device does not already know of a credential for the realm in question. A service 4860 provider that pre-configures UAs with credentials for its realm should be aware that users will not have the 4861 opportunity to present their own credentials for this realm when challenged at a pre-configured device. 4862 Finally, note that even if a UAC can locate credentials that are associated with the proper realm, the 4863 potential exists that these credentials may no longer be valid or that the challenging server will not accept 4864 these credentials for whatever reason (especially when “anonymous” with no password is submitted). In 4865 this instance a server may repeat its challenge, or it may respond with a 403 Forbidden. A UAC must not 4866 re-attempt requests with the credentials that have just been rejected (though the request may be are retried if 4867 the nonce was stale).

4868 22.2 User-to-User Authentication

4869 When a UAS receives a request from a UAC, the UAS may authenticate the originator before the request 4870 is processed. If no credentials (in the Authorization header field) are provided in the request, the UAS 4871 can challenge the originator to provide credentials by rejecting the request with a 401 (Unauthorized) status 4872 code. 4873 The WWW-Authenticate response-header field must be included in 401 (Unauthorized) response mes-4874 sages. The field value consists of at least one challenge that indicates the authentication scheme(s) and 4875 parameters applicable to the realm. See [H14.47] for a definition of the syntax. 4876 An example of the WWW-Authenticate header field in a 401 challenge is:

4877  WWW-Authenticate: Digest
4878  realm="biloxi.com",
4879  qop="auth,auth-int",
4880  nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
4881  opaque="5ccc069c403ebaf9f0171e9517f40e41"

4882 When the originating UAC receives the 401 (Unauthorized), it should, if it is able, re-originate the 4883 request with the proper credentials. The UAC may require input from the originating user before proceeding. 4884 Once authentication credentials have been supplied (either directly by the user, or discovered in an internal 4885 keyring), UAs should cache the credentials for a given value of the To header field and “realm” and 4886 attempt to re-use these values on the next request for that destination. UAs may cache credentials in any 4887 way they would like. 4888 If no credentials for a realm can be located, UACs may attempt to retry the request with a username of 4889 “anonymous” and no password (a password of “”). 4890 Once credentials have been located, any UA that wishes to authenticate itself with a UAS or registrar 4891 – usually, but not necessarily, after receiving a 401 (Unauthorized) response – may do so by including an 4892 Authorization header field with the request. The Authorization field value consists of credentials containing 4893 the authentication information of the UA for the realm of the resource being requested as well as parameters 4894 required in support of authentication and replay protection. 4895 An example of the Authorization header field is:

4896  Authorization: Digest username="bob",
4897  realm="biloxi.com",
4898  nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
4899  uri="sip:bob@biloxi.com",
4900  qop=auth,
4901  nc=00000001,
4902  cnonce="0a4f113b",
4903  response="6629fae49393a05397450978507c4ef1",
4904  opaque="5ccc069c403ebaf9f0171e9517f40e41"

4905

4906 When a UAC resubmits a request with its credentials after receiving a 401 (Unauthorized) or 407 (Proxy 4907 Authentication Required) response, it must increment the CSeq header field value as it would normally 4908 when sending an updated request.

4909 22.3 Proxy-to-User Authentication

4910 Similarly, when a UAC sends a request to a proxy server, the proxy server may authenticate the originator 4911 before the request is processed. If no credentials (in the Proxy-Authorization header field) are provided 4912 in the request, the proxy can challenge the originator to provide credentials by rejecting the request with a 4913 407 (Proxy Authentication Required) status code. The proxy must populate the 407 (Proxy Authentication 4914 Required) message with a Proxy-Authenticate header field value applicable to the proxy for the requested 4915 resource. 4916 The use of Proxy-Authentication and Proxy-Authorization parallel that described in [17], with one 4917 difference. Proxies must not add values to the Proxy-Authorization header field. All 407 (Proxy Au-4918 thentication Required) responses must be forwarded upstream toward the UAC following the procedures 4919 for any other response. It is the UAC’s responsibility to add the Proxy-Authorization header field value 4920 containing credentials for the realm of the proxy that has asked for authentication.

4921 If a proxy were to resubmit a request adding a Proxy-Authorization header field value, it would need to in-4922 crement the CSeq in the new request. However, this would cause the UAC that submitted the original request to 4923 discard a response from the UAS, as the CSeq value would be different.

4924 When the originating UAC receives the 407 (Proxy Authentication Required) it should, if it is able, 4925 re-originate the request with the proper credentials. It should follow the same procedures for the display of 4926 the “realm” parameter that are given above for responding to 401. 4927 If no credentials for a realm can be located, UACs may attempt to retry the request with a username of 4928 “anonymous” and no password (a password of “”). 4929 The UAC should also cache the credentials used in the re-originated request. 4930 The following rule is recommended for proxy credential caching: 4931 If a UA receives a Proxy-Authenticate header field value in a 401/407 response to a request with a 4932 particular Call-ID, it should incorporate credentials for that realm in all subsequent requests that contain the 4933 same Call-ID. These credentials must not be cached across dialogs; however, if a UA is configured with 4934 the realm of its local outbound proxy, when one exists, then the UA may cache credentials for that realm 4935 across dialogs. Note that this does mean a future request in a dialog could contain credentials that are not 4936 needed by any proxy along the Route header path. 4937 Any UA that wishes to authenticate itself to a proxy server – usually, but not necessarily, after receiving 4938 a 407 (Proxy Authentication Required) response – may do so by including a Proxy-Authorization header 4939 field value with the request. The Proxy-Authorization request-header field allows the client to identify itself 4940 (or its user) to a proxy that requires authentication. The Proxy-Authorization header field value consists of 4941 credentials containing the authentication information of the UA for the proxy and/or realm of the resource 4942 being requested. 4943 A Proxy-Authorization header field value applies only to the proxy whose realm is identified in the 4944 “realm” parameter (this proxy may previously have demanded authentication using the Proxy-Authenticate 4945 field). When multiple proxies are used in a chain, a Proxy-Authorization header field value must not be 4946 consumed by any proxy whose realm does not match the “realm” parameter specified in that value. 4947 Note that if an authentication scheme that does not support realms is used in the Proxy-Authorization 4948 header field, a proxy server must attempt to parse all Proxy-Authorization header field values to determine 4949 whether one of them has what the proxy server considers to be valid credentials. Because this is potentially 4950 very time-consuming in large networks, proxy servers should use an authentication scheme that supports 4951 realms in the Proxy-Authorization header field. 4952 If a request is forked (as described in Section 16.7), various proxy servers and/or UAs may wish to 4953 challenge the UAC. In this case, the forking proxy server is responsible for aggregating these challenges 4954 into a single response. Each WWW-Authenticate and Proxy-Authenticate value received in responses to 4955 the forked request must be placed into the single response that is sent by the forking proxy to the UA; the 4956 ordering of these header field values is not significant.

4957 When a proxy server issues a challenge in response to a request, it will not proxy the request until the UAC has 4958 retried the request with valid credentials. A forking proxy may forward a request simultaneously to multiple proxy 4959 servers that require authentication, each of which in turn will not forward the request until the originating UAC has 4960 authenticated itself in their respective realm. If the UAC does not provide credentials for each challenge, then the 4961 proxy servers that issued the challenges will not forward requests to the UA where the destination user might be 4962 located, and therefore, the virtues of forking are largely lost.

4963 When resubmitting its request in response to a 401 (Unauthorized) or 407 (Proxy Authentication Re-4964 quired) that contains multiple challenges, a UAC may include an Authorization value for each WWW-4965 Authenticate value and a Proxy-Authorization value for each Proxy-Authenticate value for which the 4966 UAC wishes to supply a credential. As noted above, multiple credentials in a request should be differen-4967 tiated by the “realm” parameter. 4968 It is possible for multiple challenges associated with the same realm to appear in the same 401 (Unautho-4969 rized) or 407 (Proxy Authentication Required). This can occur, for example, when multiple proxies within 4970 the same administrative domain, which use a common realm, are reached by a forking request. When it re-4971 tries a request, a UAC may therefore supply multiple credentials in Authorization or Proxy-Authorization 4972 header fields with the same “realm” parameter value. The same credentials should be used for the same 4973 realm. 4974 See [H14.34] for a definition of the syntax of Proxy-Authentication and Proxy-Authorization.

4975 22.4 The Digest Authentication Scheme

4976 This section describes the modifications and clarifications required to apply the HTTP Digest authentication 4977 scheme to SIP. The SIP scheme usage is almost completely identical to that for HTTP [17]. 4978 Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [38], SIP servers supporting RFC 4979 2617 must ensure they are backwards compatible with RFC 2069. Procedures for this backwards com-4980 patibility are specified in RFC 2617. Note, however, that SIP servers must not accept or request Basic 4981 authentication. 4982 The rules for Digest authentication follow those defined in [17], with “HTTP/1.1” replaced by “SIP/2.0” 4983 in addition to the following differences:

4984 1. The URI included in the challenge has the following BNF:

URI = SIP-URI / SIPS-URI

4985

4986 2. The BNF in RFC 2617 has an error in that the ’uri’ parameter of the Authorization header field for 4987 HTTP Digest authentication is not enclosed in quotation marks. (The example in Section 3.5 of RFC 4988 2617 is correct.) For SIP, the ’uri’ must be enclosed in quotation marks.

4989 3. The BNF for digest-uri-value is:

digest-uri-value = Request-URI ; as defined in Section 25

4990

4991 4. The example procedure for choosing a nonce based on Etag does not work for SIP.

4992 5. The text in RFC 2617 [17] regarding cache operation does not apply to SIP.

4993 6. RFC 2617 [17] requires that a server check that the URI in the request line and the URI included in 4994 the Authorization header field point to the same resource. In a SIP context, these two URIs may refer 4995 to different users, due to forwarding at some proxy. Therefore, in SIP, a server may check that the 4996 Request-URI in the Authorization header field value corresponds to a user for whom the server is 4997 willing to accept forwarded or direct requests, but it is not necessarily a failure if the two fields are 4998 not equivalent.

4999 7. As a clarification to the calculation of the A2 value for message integrity assurance in the Digest 5000 authentication scheme, implementers should assume, when the entity-body is empty (that is, when 5001 SIP messages have no body) that the hash of the entity-body resolves to the MD5 hash of an empty 5002 string, or:

5003 H(entity-body) = MD5(””) = ”d41d8cd98f00b204e9800998ecf8427e”

5004 8. RFC 2617 notes that a cnonce value must not be sent in an Authorization (and by extension Proxy-5005 Authorization) header field if no qop directive has been sent. Therefore, any algorithms that have a 5006 dependency on the cnonce (including “MD5-Sess”) require that the qop directive be sent. Use of the 5007 “qop” parameter is optional in RFC 2617 for the purposes of backwards compatibility with RFC 2069; 5008 since RFC 2543 was based on RFC 2069, the “qop” parameter must unfortunately remain optional 5009 for clients and servers to receive. However, servers must always send a “qop” parameter in WWW-5010 Authenticate and Proxy-Authenticate header field values. If a client receives a “qop” parameter in a 5011 challenge header field, it must send the “qop” parameter in any resulting authorization header field.

5012 RFC 2543 did not allow usage of the Authentication-Info header field (it effectively used RFC 2069). 5013 However, we now allow usage of this header field, since it provides integrity checks over the bodies and 5014 provides mutual authentication. RFC 2617 [17] defines mechanisms for backwards compatibility using the 5015 qop attribute in the request. These mechanisms must be used by a server to determine if the client supports 5016 the new mechanisms in RFC 2617 that were not specified in RFC 2069.

5017 23 S/MIME

5018 SIP messages carry MIME bodies and the MIME standard includes mechanisms for securing MIME con-5019 tents to ensure both integrity and confidentiality (including the ’multipart/signed’ and ’application/pkcs7-5020 mime’ MIME types, see RFC 1847 [21], RFC 2630 [22] and RFC 2633 [23]). Implementers should note, 5021 however, that there may be rare network intermediaries (not typical proxy servers) that rely on viewing or 5022 modifying the bodies of SIP messages (especially SDP), and that secure MIME may prevent these sorts of 5023 intermediaries from functioning.

5024 This applies particularly to certain types of firewalls. 5025 The PGP mechanism for encrypting the header fields and bodies of SIP messages described in RFC 2543 has 5026 been deprecated.

5027 23.1 S/MIME Certificates

5028 The certificates that are used to identify an end-user for the purposes of S/MIME differ from those used 5029 by servers in one important respect - rather than asserting that the identity of the holder corresponds to a 5030 particular hostname, these certificates assert that the holder is identified by an end-user address. This address 5031 is composed of the concatenation of the “userinfo” “@” and “domainname” portions of a SIP or SIPS URI 5032 (in other words, an email address of the form “bob@biloxi.com”), most commonly corresponding to a user’s 5033 address-of-record. 5034 These certificates are also associated with keys that are used to sign or encrypt bodies of SIP messages. 5035 Bodies are signed with the private key of the sender (who may include their public key with the message 5036 as appropriate), but bodies are encrypted with the public key of the intended recipient. Obviously, senders 5037 must have foreknowledge of the public key of recipients in order to encrypt message bodies. Public keys 5038 can be stored within a UA on a virtual keyring. 5039 Each user agent that supports S/MIME must contain a keyring specifically for end-users’ certificates. 5040 This keyring should map between addresses of record and corresponding certificates. Over time, users 5041 should use the same certificate when they populate the originating URI of signaling (the From header 5042 field) with the same address-of-record. 5043 Any mechanisms depending on the existence of end-user certificates are seriously limited in that there is 5044 virtually no consolidated authority today that provides certificates for end-user applications. However, users 5045 should acquire certificates from known public certificate authorities. As an alternative, users may create 5046 self-signed certificates. The implications of self-signed certificates are explored further in Section 26.4.2. 5047 Implementations may also use pre-configured certificates in deployments in which a previous trust relation-5048 ship exists between all SIP entities. 5049 Above and beyond the problem of acquiring an end-user certificate, there are few well-known central-5050 ized directories that distribute end-user certificates. However, the holder of a certificate should publish 5051 their certificate in any public directories as appropriate. Similarly, UACs should support a mechanism 5052 for importing (manually or automatically) certificates discovered in public directories corresponding to the 5053 target URIs of SIP requests.

5054 23.2 S/MIME Key Exchange

5055 SIP itself can also be used as a means to distribute public keys in the following manner. 5056 Whenever the CMS SignedData message is used in S/MIME for SIP, it must contain the certificate 5057 bearing the public key necessary to verify the signature. 5058 When a UAC sends a request containing an S/MIME body that initiates a dialog, or sends a non-5059 INVITE request outside the context of a dialog, the UAC should structure the body as an S/MIME ’multi-5060 part/signed’ CMS SignedData body. If the desired CMS service is EnvelopedData (and the public key of the 5061 target user is known), the UAC should send the EnvelopedData message encapsulated within a SignedData 5062 message. 5063 When a UAS receives a request containing an S/MIME CMS body that includes a certificate, the UAS 5064 should first verify the certificate, if possible, with any available certificate authority. The UAS should 5065 also determine the subject of the certificate and compare this value to the From header field of the request. 5066 If the certificate cannot be verified, because it is self-signed, or signed by no known authority, or if it is 5067 verifiable but its subject does not correspond to the From header field of request, the UAS must notify its 5068 user of the status of the certificate (including the subject of the certificate, its signer, and any key fingerprint 5069 information) and request explicit permission before proceeding. If the certificate was successfully verified 5070 and the subject of the certificate corresponds to the From header field of the SIP request, or if the user (after 5071 notification) explicitly authorizes the use of the certificate, the UAS should add this certificate to a local 5072 keyring, indexed by the address-of-record of the holder of the certificate. 5073 When a UAS sends a response containing an S/MIME body that answers the first request in a dialog, or 5074 a response to a non-INVITE request outside the context of a dialog, the UAS should structure the body 5075 as an S/MIME ’multipart/signed’ CMS SignedData body. If the desired CMS service is EnvelopedData, the 5076 UAS should send the EnvelopedData message encapsulated within a SignedData message. 5077 When a UAC receives a response containing an S/MIME CMS body that includes a certificate, the UAC 5078 should first verify the certificate, if possible, with any available certificate authority. The UAC should 5079 also determine the subject of the certificate and compare this value to the To field of the response; although 5080 the two may very well be different, and this is not necessarily indicative of a security breach. If the certificate 5081 cannot be verified because it is self-signed, or signed by no known authority, the UAC must notify its user 5082 of the status of the certificate (including the subject of the certificate, its signator, and any key fingerprint 5083 information) and request explicit permission before proceeding. If the certificate was successfully verified, 5084 and the subject of the certificate corresponds to the To header field in the response, or if the user (after 5085 notification) explicitly authorizes the use of the certificate, the UAC should add this certificate to a local 5086 keyring, indexed by the address-of-record of the holder of the certificate. If the UAC had not transmitted its 5087 own certificate to the UAS in any previous transaction, it should use a CMS SignedData body for its next 5088 request or response. 5089 On future occasions, when the UA receives requests or responses that contain a From header field 5090 corresponding to a value in its keyring, the UA should compare the certificate offered in these messages 5091 with the existing certificate in its keyring. If there is a discrepancy, the UA must notify its user of a change 5092 of the certificate (preferably in terms that indicate that this is a potential security breach) and acquire the 5093 user’s permission before continuing to process the signaling. If the user authorizes this certificate, it should 5094 be added to the keyring alongside any previous value(s) for this address-of-record. 5095 Note well however, that this key exchange mechanism does not guarantee the secure exchange of keys 5096 when self-signed certificates, or certificates signed by an obscure authority, are used - it is vulnerable to 5097 well-known attacks. In the opinion of the authors, however, the security it provides is proverbially better 5098 than nothing; it is in fact comparable to the widely used SSH application. These limitations are explored in 5099 greater detail in Section 26.4.2. 5100 If a UA receives an S/MIME body that has been encrypted with a public key unknown to the recipient, 5101 it must reject the request with a 493 (Undecipherable) response. This response should contain a valid 5102 certificate for the respondent (corresponding, if possible, to any address of record given in the To header 5103 field of the rejected request) within a MIME body with a ‘certs-only’ “smime-type” parameter. 5104 A 493 (Undecipherable) sent without any certificate indicates that the respondent cannot or will not 5105 utilize S/MIME encrypted messages, though they may still support S/MIME signatures. 5106 Note that a user agent that receives a request containing an S/MIME body that is not optional (with 5107 a Content-Disposition header “handling” parameter of “required”) must reject the request with a 415 5108 Unsupported Media Type response if the MIME type is not understood. A user agent that receives such a 5109 response when S/MIME is sent should notify its user that the remote device does not support S/MIME, 5110 and it may subsequently resend the request without S/MIME, if appropriate; however, this 415 response 5111 may constitute a downgrade attack. 5112 If a user agent sends an S/MIME body in a request, but receives a response that contains a MIME body 5113 that is not secured, the UAC should notify its user that the session could not be secured. However, if a 5114 user agent that supports S/MIME receives a request with an unsecured body, it should not respond with 5115 a secured body, but if it expects S/MIME from the sender (for example, because the sender’s From header 5116 field value corresponds to an identity on its keychain), the UAS should notify its user that the session 5117 could not be secured. 5118 Finally, if during the course of a dialog a UA receives a certificate in a CMS SignedData message that 5119 does not correspond with the certificates previously exchanged during a dialog, the UA must notify its user 5120 of the change, preferably in terms that indicate that this is a potential security breach.

5121 23.3 Securing MIME bodies

5122 There are two types of secure MIME bodies that are of interest to SIP: ’multipart/signed’ and ’application/pkcs7-5123 mime’. The procedures for the use of these bodies should follow the S/MIME specification [23] with a few 5124 variations.

5125 • “multipart/signed” must be used only with CMS detached signatures.

5126 This allows backwards compatibility with non-S/MIME-compliant recipients.

5127 • S/MIME bodies should have a Content-Disposition header field, and the value of the “handling” 5128 parameter should be “required.”

5129 • If a UAC has no certificate on its keyring associated with the address-of-record to which it wants to 5130 send a request, it cannot send an encrypted “application/pkcs7-mime” MIME message. UACs may 5131 send an initial request such as an OPTIONS message with a CMS detached signature in order to 5132 solicit the certificate of the remote side (the signature should be over a “application/sip” body of the 5133 type described in Section 23.4).

5134 Note that future standardization work on S/MIME may define non-certificate based keys.

5135 • Senders of S/MIME bodies should use the “SMIMECapabilities” (see Section 2.5.2 of [23]) at-5136 tribute to express their capabilities and preferences for further communications. Note especially that 5137 senders may use the “preferSignedData” capability to encourage receivers to respond with CMS 5138 SignedData messages (for example, when sending an OPTIONS request as described above).

5139 • S/MIME implementations must at a minimum support SHA1 as a digital signature algorithm, and 5140 3DES as an encryption algorithm. All other signature and encryption algorithms may be supported. 5141 Implementations can negotiate support for these algorithms with the “SMIMECapabilities” attribute.

5142 • Each S/MIME body in a SIP message should be signed with only one certificate. If a UA receives 5143 a message with multiple signatures, the outermost signature should be treated as the single certificate 5144 for this body. Parallel signatures should not be used.

5145 The following is an example of an encrypted S/MIME SDP body within a SIP message:

5146  INVITE sip:bob@biloxi.com SIP/2.0
5147  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
5148  To: Bob <sip:bob@biloxi.com>
5149  From: Alice <sip:alice@atlanta.com>;tag=1928301774
5150  Call-ID: a84b4c76e66710
5151  CSeq: 314159 INVITE
5152  Max-Forwards: 70
5153  Contact: <sip:alice@pc33.atlanta.com>
5154  Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
5155  name=smime.p7m
5156  Content-Transfer-Encoding: base64
5157  Content-Disposition: attachment; filename=smime.p7m
5158  handling=required

5159

5160  *******************************************************
5161  * Content-Type: application/sdp                          *

5162 * *

5163  * v=0                                                        *
5164  * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com *
5165  * s=-                                                        *
5166  * t=0 0                                                      *
5167  * c=IN IP4 pc33.atlanta.com                               *
5168  * m=audio 3456 RTP/AVP 0 1 3 99                          *
5169  * a=rtpmap:0 PCMU/8000                                     *
5170  *******************************************************

5171 23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP

5172 As a means of providing some degree of end-to-end authentication, integrity or confidentiality for SIP header 5173 fields, S/MIME can encapsulate entire SIP messages within MIME bodies of type “application/sip” and 5174 then apply MIME security to these bodies in the same manner as typical SIP bodies. These encapsulated 5175 SIP requests and responses do not constitute a separate dialog or transaction, they are a copy of the “outer” 5176 message that is used to verify integrity or to supply additional information.

5177 If a UAS receives a request that contains a tunneled “application/sip” S/MIME body, it should include 5178 a tunneled “application/sip” body in the response with the same smime-type. 5179 Any traditional MIME bodies (such as SDP) should be attached to the ”inner” message so that they 5180 can also benefit from S/MIME security. Note that “application/sip” bodies can be sent as a part of a MIME 5181 “multipart/mixed” body if any unsecured MIME types should also be transmitted in a request.

5182 23.4.1 Integrity and Confidentiality Properties of SIP Headers

5183 When the S/MIME integrity or confidentiality mechanisms are used, there may be discrepancies between the 5184 values in the “inner” message and values in the “outer” message. The rules for handling any such differences 5185 for all of the header fields described in this document are given in this section.

5186 23.4.1.1 Integrity Whenever integrity checks are performed, the integrity of a header field should be 5187 determined by matching the value of the header field in the signed body with that in the “outer” messages 5188 using the comparison rules of SIP as described in 20. 5189 Header fields that can be legitimately modified by proxy servers are: Request-URI, Via, Record-5190 Route, Route, Max-Forwards, and Proxy-Authorization. If these header fields are not intact end-to-end, 5191 implementations should not consider this a breach of security. Changes to any other header fields defined 5192 in this document constitute an integrity violation; users must be notified of a discrepancy.

5193 23.4.1.2 Confidentiality When messages are encrypted, header fields may be included in the encrypted 5194 body that are not present in the “outer” message. 5195 Some header fields must always have a plaintext version because they are required header fields in 5196 requests and responses - these include: To, From, Call-ID, CSeq, Contact. While it is probably not 5197 useful to provide an encrypted alternative for the Call-ID, Cseq, or Contact, providing an alternative to the 5198 information in the “outer” To or From is permitted. Note that the values in an encrypted body are not used 5199 for the purposes of identifying transactions or dialogs - they are merely informational. If the From header 5200 field in an encrypted body differs from the value in the “outer” message, the value within the encrypted 5201 body should be displayed to the user, but must not be used in the “outer” header fields of any future 5202 messages. 5203 Primarily, a user agent will want to encrypt header fields that have an end-to-end semantic, including: 5204 Subject, Reply-To, Organization, Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-5205 Info, Authentication-Info, Expires, In-Reply-To, Require, Supported, Unsupported, Retry-After, User-5206 Agent, Server, and Warning. If any of these header fields are present in an encrypted body, they should be 5207 used instead of any “outer” header fields, whether this entails displaying the header field values to users or 5208 setting internal states in the UA. They should not however be used in the “outer” headers of any future 5209 messages. 5210 Since MIME bodies are attached to the “inner” message, implementations will usually encrypt MIME-5211 specific header fields, including: MIME-Version, Content-Type, Content-Length, Content-Language, 5212 Content-Encoding and Content-Disposition. The “outer” message will have the proper MIME header 5213 fields for S/MIME bodies. These header fields (and any MIME bodies they preface) should be treated as 5214 normal MIME header fields and bodies received in a SIP message. 5215 It is not particularly useful to encrypt the following header fields: Date, Min-Expires, Timestamp, 5216 Authorization, Priority, and WWW-Authenticate. This category also includes those header fields that can 5217 be changed by proxy servers (described in the preceding section). UAs should never include these in an 5218 “inner” message if they are not included in the “outer” message. UAs that receive any of these header fields 5219 in an encrypted body should ignore the encrypted values. 5220 Note that extensions to SIP may define additional header fields; the authors of these extensions should 5221 describe the integrity and confidentiality properties of such header fields. If a SIP UA encounters an un-5222 known header field with an integrity violation, it must ignore the header field.

5223 23.4.2 Tunneling Integrity and Authentication

5224 Tunneling SIP messages within S/MIME bodies can provide integrity for SIP header fields if the header 5225 fields that the sender wishes to secure are replicated in a “application/sip” MIME body signed with a CMS 5226 detached signature. 5227 Provided that the “application/sip” body contains at least the fundamental dialog identifiers (To, From, 5228 Call-ID, CSeq), then a signed MIME body can provide limited authentication. At the very least, if the 5229 certificate used to sign the body is unknown to the recipient and cannot be verified, the signature can be used 5230 to ascertain that a later request in a dialog was transmitted by the same certificate-holder that initiated the 5231 dialog. If the recipient of the signed MIME body has some stronger incentive to trust the certificate (they 5232 were able to verify it, acquire it from a trusted repository, or they have used it frequently) then the signature 5233 can be taken as a stronger assertion of the identity of the subject of the certificate. 5234 In order to eliminate possible confusions about the addition or subtraction of entire header fields, senders 5235 should replicate all header fields from the request within the signed body. Any message bodies that require 5236 integrity protection must be attached to the “inner” message. 5237 If an integrity violation in a message is detected by its recipient, the message may be rejected with a 5238 403 (Forbidden) response if it is a request, or any existing dialog may be terminated. UAs should notify 5239 users of this circumstance and request explicit guidance on how to proceed. 5240 The following is an example of the use of a tunneled “application/sip” body:

5241  INVITE sip:bob@biloxi.com SIP/2.0
5242  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
5243  To: Bob <sip:bob@biloxi.com>
5244  From: Alice <sip:alice@atlanta.com>;tag=1928301774
5245  Call-ID: a84b4c76e66710
5246  CSeq: 314159 INVITE
5247  Max-Forwards: 70
5248  Contact: <sip:alice@pc33.atlanta.com>
5249  Content-Type: multipart/signed;
5250  protocol="application/pkcs7-signature";
5251  micalg=sha1; boundary=boundary42
5252  Content-Length: 568

5253

5254  --boundary42
5255  Content-Type: application/sip

5256

5257  INVITE sip:bob@biloxi.com SIP/2.0
5258  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
5259  To: Bob <bob@biloxi.com>

5260  From: Alice <alice@atlanta.com>;tag=1928301774
5261  Call-ID: a84b4c76e66710
5262  CSeq: 314159 INVITE
5263  Max-Forwards: 70
5264  Contact: <sip:alice@pc33.atlanta.com>
5265  Content-Type: application/sdp
5266  Content-Length: 147

5267 5268 v=0

5269  o=UserA 2890844526 2890844526 IN IP4 here.com
5270  s=Session SDP
5271  c=IN IP4 pc33.atlanta.com
5272  t=0 0
5273  m=audio 49172 RTP/AVP 0
5274  a=rtpmap:0 PCMU/8000

5275

5276  --boundary42
5277  Content-Type: application/pkcs7-signature; name=smime.p7s
5278  Content-Transfer-Encoding: base64
5279  Content-Disposition: attachment; filename=smime.p7s;
5280  handling=required

5281

5282  ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
5283  4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
5284  n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
5285  7GhIGfHfYT64VQbnj756

5286

5287  --boundary42-

5288 23.4.3 Tunneling Encryption

5289 It may also be desirable to use this mechanism to encrypt a “application/sip” MIME body within a CMS 5290 EnvelopedData message S/MIME body, but in practice, most header fields are of at least some use to the 5291 network; the general use of encryption with S/MIME is to secure message bodies like SDP rather than 5292 message headers. Some informational header fields, such as the Subject or Organization could perhaps 5293 warrant end-to-end security. Headers defined by future SIP applications might also require obfuscation. 5294 Another possible application of encrypting header fields is selective anonymity. A request could be con-5295 structed with a From header field that contains no personal information (for example, sip:anonymous@anonymizer.invalid). 5296 However, a second From header field containing the genuine address-of-record of the originator could be 5297 encrypted within a “application/sip” MIME body where it will only be visible to the endpoints of a dialog. 5298 motivationNote that if this mechanism is used for anonymity, the From header field will no longer 5299 be usable by the recipient of a message as an index to their certificate keychain for retrieving the proper 5300 S/MIME key to associated with the sender. The message must first be decrypted, and the “inner” From 5301 header field must be used as an index. 5302 In order to provide end-to-end integrity, encrypted “application/sip” MIME bodies should be signed by 5303 the sender. This creates a “multipart/signed” MIME body that contains an encrypted body and a signature, 5304 both of type “application/pkcs7-mime”. 5305 In the following example, of an encrypted and signed message, the text boxed in asterisks (“*”) is 5306 encrypted:

5307  INVITE sip:bob@biloxi.com SIP/2.0
5308  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
5309  To: Bob <sip:bob@biloxi.com>
5310  From: Anonymous <sip:anonymous@atlanta.com>;tag=1928301774
5311  Call-ID: a84b4c76e66710
5312  CSeq: 314159 INVITE
5313  Max-Forwards: 70
5314  Contact: <sip:pc33.atlanta.com>
5315  Content-Type: multipart/signed;
5316  protocol="application/pkcs7-signature";
5317  micalg=sha1; boundary=boundary42
5318  Content-Length: 568

5319

5320  --boundary42
5321  Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
5322  name=smime.p7m
5323  Content-Transfer-Encoding: base64
5324  Content-Disposition: attachment; filename=smime.p7m
5325  handling=required
5326  Content-Length: 231

5327

5328  ***********************************************************
5329  * Content-Type: application/sip                               *

5330 * *

5331  * INVITE sip:bob@biloxi.com SIP/2.0                          *
5332  * Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 *
5333  * To: Bob <bob@biloxi.com>                                     *
5334  * From: Alice <alice@atlanta.com>;tag=1928301774           *
5335  * Call-ID: a84b4c76e66710                                      *
5336  * CSeq: 314159 INVITE                                          *
5337  * Max-Forwards: 70                                              *
5338  * Contact: <sip:alice@pc33.atlanta.com>                      *

5339 * *

5340  * Content-Type: application/sdp                               *

5341 * *

5342  * v=0                                                             *
5343  * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com      *
5344  * s=Session SDP                                                 *
5345  * t=0 0                                                          *
5346  * c=IN IP4 pc33.atlanta.com                                   *

5347  * m=audio 3456 RTP/AVP 0 1 3 99                               *
5348  * a=rtpmap:0 PCMU/8000                                         *
5349  ***********************************************************

5350

5351  --boundary42
5352  Content-Type: application/pkcs7-signature; name=smime.p7s
5353  Content-Transfer-Encoding: base64
5354  Content-Disposition: attachment; filename=smime.p7s;
5355  handling=required

5356

5357  ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
5358  4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
5359  n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
5360  7GhIGfHfYT64VQbnj756

5361

5362  --boundary42-

5363 24 Examples

5364 In the following examples, we often omit the message body and the corresponding Content-Length and 5365 Content-Type header fields for brevity.

5366 24.1 Registration

5367 Bob registers on start-up. The message flow is shown in Figure 9. Note that the authentication usually 5368 required for registration is not shown for simplicity.

Figure 9: SIP Registration Example

5369

5370 F1 REGISTER Bob -> Registrar

5371

5372  REGISTER sip:registrar.biloxi.com SIP/2.0
5373  Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
5374  Max-Forwards: 70
5375  To: Bob <sip:bob@biloxi.com>
5376  From: Bob <sip:bob@biloxi.com>;tag=456248
5377  Call-ID: 843817637684230@998sdasdh09
5378  CSeq: 1826 REGISTER
5379  Contact: <sip:bob@192.0.2.4>
5380  Expires: 7200
5381  Content-Length: 0

5382 The registration expires after two hours. The registrar responds with a 200 OK:

5383

5384 F2 200 OK Registrar -> Bob

5385

5386  SIP/2.0 200 OK
5387  Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7
5388  ;received=192.0.2.4
5389  To: Bob <sip:bob@biloxi.com>
5390  From: Bob <sip:bob@biloxi.com>;tag=456248
5391  Call-ID: 843817637684230@998sdasdh09
5392  CSeq: 1826 REGISTER
5393  Contact: <sip:bob@192.0.2.4>
5394  Expires: 7200
5395  Content-Length: 0

5396

5397 24.2 Session Setup

5398 This example contains the full details of the example session setup in Section 4. The message flow is shown 5399 in Figure 1. Note that these flows show the minimum required set of header fields - some other header fields 5400 such as Allow and Supported would normally be present.

5401

5402 F1 INVITE Alice -> atlanta.com proxy

5403

5404  INVITE sip:bob@biloxi.com SIP/2.0
5405  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
5406  Max-Forwards: 70
5407  To: Bob <sip:bob@biloxi.com>
5408  From: Alice <sip:alice@atlanta.com>;tag=1928301774
5409  Call-ID: a84b4c76e66710
5410  CSeq: 314159 INVITE

5411  Contact: <sip:alice@pc33.atlanta.com>
5412  Content-Type: application/sdp
5413  Content-Length: 142

5414

5415  (Alice's SDP not shown)

5416

5417 F2 100 Trying atlanta.com proxy -> Alice

5418

5419  SIP/2.0 100 Trying
5420  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
5421  ;received=10.1.3.3
5422  To: Bob <sip:bob@biloxi.com>
5423  From: Alice <sip:alice@atlanta.com>;tag=1928301774
5424  Call-ID: a84b4c76e66710
5425  CSeq: 314159 INVITE
5426  Content-Length: 0

5427

5428 F3 INVITE atlanta.com proxy -> biloxi.com proxy

5429

5430  INVITE sip:bob@biloxi.com SIP/2.0
5431  Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
5432  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
5433  ;received=10.1.3.3
5434  Max-Forwards: 69
5435  To: Bob <sip:bob@biloxi.com>
5436  From: Alice <sip:alice@atlanta.com>;tag=1928301774
5437  Call-ID: a84b4c76e66710
5438  CSeq: 314159 INVITE
5439  Contact: <sip:alice@pc33.atlanta.com>
5440  Content-Type: application/sdp
5441  Content-Length: 142

5442

5443  (Alice's SDP not shown)

5444

5445 F4 100 Trying biloxi.com proxy -> atlanta.com proxy

5446

5447  SIP/2.0 100 Trying
5448  Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
5449  ;received=10.1.1.1
5450  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
5451  ;received=10.1.3.3

5452  To: Bob <sip:bob@biloxi.com>
5453  From: Alice <sip:alice@atlanta.com>;tag=1928301774
5454  Call-ID: a84b4c76e66710
5455  CSeq: 314159 INVITE
5456  Content-Length: 0

5457

5458 F5 INVITE biloxi.com proxy -> Bob

5459

5460  INVITE sip:bob@192.0.2.4 SIP/2.0
5461  Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
5462  Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
5463  ;received=10.1.1.1
5464  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
5465  ;received=10.1.3.3
5466  Max-Forwards: 68
5467  To: Bob <sip:bob@biloxi.com>
5468  From: Alice <sip:alice@atlanta.com>;tag=1928301774
5469  Call-ID: a84b4c76e66710
5470  CSeq: 314159 INVITE
5471  Contact: <sip:alice@pc33.atlanta.com>
5472  Content-Type: application/sdp
5473  Content-Length: 142

5474

5475  (Alice's SDP not shown)

5476

5477 F6 180 Ringing Bob -> biloxi.com proxy

5478

5479  SIP/2.0 180 Ringing
5480  Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
5481  ;received=10.2.1.1
5482  Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
5483  ;received=10.1.1.1
5484  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
5485  ;received=10.1.3.3
5486  To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
5487  From: Alice <sip:alice@atlanta.com>;tag=1928301774
5488  Call-ID: a84b4c76e66710
5489  Contact: <sip:bob@192.0.2.4>
5490  CSeq: 314159 INVITE
5491  Content-Length: 0

5492

5493 F7 180 Ringing biloxi.com proxy -> atlanta.com proxy

5494

5495  SIP/2.0 180 Ringing
5496  Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
5497  ;received=10.1.1.1
5498  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
5499  ;received=10.1.3.3
5500  To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
5501  From: Alice <sip:alice@atlanta.com>;tag=1928301774
5502  Call-ID: a84b4c76e66710
5503  Contact: <sip:bob@192.0.2.4>
5504  CSeq: 314159 INVITE
5505  Content-Length: 0

5506

5507 F8 180 Ringing atlanta.com proxy -> Alice

5508

5509  SIP/2.0 180 Ringing
5510  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
5511  ;received=10.1.3.3
5512  To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
5513  From: Alice <sip:alice@atlanta.com>;tag=1928301774
5514  Call-ID: a84b4c76e66710
5515  Contact: <sip:bob@192.0.2.4>
5516  CSeq: 314159 INVITE
5517  Content-Length: 0

5518

5519 F9 200 OK Bob -> biloxi.com proxy

5520

5521  SIP/2.0 200 OK
5522  Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
5523  ;received=10.2.1.1
5524  Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
5525  ;received=10.1.1.1
5526  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
5527  ;received=10.1.3.3
5528  To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
5529  From: Alice <sip:alice@atlanta.com>;tag=1928301774
5530  Call-ID: a84b4c76e66710
5531  CSeq: 314159 INVITE
5532  Contact: <sip:bob@192.0.2.4>
5533  Content-Type: application/sdp
5534  Content-Length: 131

5535

5536  (Bob's SDP not shown)

5537

5538 F10 200 OK biloxi.com proxy -> atlanta.com proxy

5539

5540  SIP/2.0 200 OK
5541  Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
5542  ;received=10.1.1.1
5543  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
5544  ;received=10.1.3.3
5545  To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
5546  From: Alice <sip:alice@atlanta.com>;tag=1928301774
5547  Call-ID: a84b4c76e66710
5548  CSeq: 314159 INVITE
5549  Contact: <sip:bob@192.0.2.4>
5550  Content-Type: application/sdp
5551  Content-Length: 131

5552

5553  (Bob's SDP not shown)

5554

5555 F11 200 OK atlanta.com proxy -> Alice

5556

5557  SIP/2.0 200 OK
5558  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
5559  ;received=10.1.3.3
5560  To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
5561  From: Alice <sip:alice@atlanta.com>;tag=1928301774
5562  Call-ID: a84b4c76e66710
5563  CSeq: 314159 INVITE
5564  Contact: <sip:bob@192.0.2.4>
5565  Content-Type: application/sdp
5566  Content-Length: 131

5567

5568  (Bob's SDP not shown)

5569

5570 F12 ACK Alice -> Bob

5571

5572  ACK sip:bob@192.0.2.4 SIP/2.0
5573  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9
5574  Max-Forwards: 70
5575  To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
5576  From: Alice <sip:alice@atlanta.com>;tag=1928301774
5577  Call-ID: a84b4c76e66710
5578  CSeq: 314159 ACK
5579  Content-Length: 0

5580 The media session between Alice and Bob is now established. 5581 Bob hangs up first. Note that Bob’s SIP phone maintains its own CSeq numbering space, which, in 5582 this example, begins with 231. Since Bob is making the request, the To and From URIs and tags have been 5583 swapped.

5584

5585 F13 BYE Bob -> Alice

5586

5587  BYE sip:alice@pc33.atlanta.com SIP/2.0
5588  Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
5589  Max-Forwards: 70
5590  From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
5591  To: Alice <sip:alice@atlanta.com>;tag=1928301774
5592  Call-ID: a84b4c76e66710
5593  CSeq: 231 BYE
5594  Content-Length: 0

5595

5596 F14 200 OK Alice -> Bob

5597

5598  SIP/2.0 200 OK
5599  Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
5600  ;received=10.1.3.3
5601  From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
5602  To: Alice <sip:alice@atlanta.com>;tag=1928301774
5603  Call-ID: a84b4c76e66710
5604  CSeq: 231 BYE
5605  Content-Length: 0

5606 The SIP Call Flows document [39] contains further examples of SIP messages.

5607 25 Augmented BNF for the SIP Protocol

5608 All of the mechanisms specified in this document are described in both prose and an augmented Backus-5609 Naur Form (BNF) defined in RFC 2234 [10]. Section 6.1 of RFC 2234 defines a set of core rules that are 5610 used by this specification, and not repeated here. Implementers need to be familiar with the notation and 5611 content of RFC 2234 in order to understand this specification. Certain basic rules are in uppercase, such as 5612 SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions to clarify the use 5613 of rule names. 5614 In some cases, the BNF for a choice will indicate that some elements are optional through angle brackets. 5615 For example:

foo = bar / baz / [boo]

5616

5617 The use of angle brackets is redundant syntactically. It is used as a semantic hint that the specific 5618 parameter is optional to use.

5619 25.1 Basic Rules

5620 The following rules are used throughout this specification to describe basic parsing constructs. The US-5621 ASCII coded character set is defined by ANSI X3.4-1986.

alphanum = ALPHA / DIGIT

5622

5623 Several rules are incorporated from RFC 2396 [5] but are updated to make them compliant with RFC 5624 2234 [10]. These include:

reserved  = ”;” / ”/” / ”?” / ”:” / ”@” / ”&” / ”=” / ”+”
/ ”$” / ”,”
unreserved = alphanum / mark
mark  = ”-” / ” ” / ”.” / ”!” / ”˜ ” / ”*” / ”’”
/ ”(” / ”)”
escaped  = ”%” HEXDIG HEXDIG

5625

5626 SIP header field values can be folded onto multiple lines if the continuation line begins with a space or 5627 horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient may 5628 replace any linear white space with a single SP before interpreting the field value or forwarding the message 5629 downstream. This is intended to behave exactly as HTTP/1.1 as described in RFC 2616 [8]. The SWS 5630 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

5631

5632 To separate the header name from the rest of value, a colon is used, which, by the above rule, allows 5633 whitespace before, but no line break, and whitespace after, including a linebreak. The HCOLON defines 5634 this construct.

HCOLON = *( SP / HTAB ) ”:” SWS

5635

5636 The TEXT-UTF8 rule is only used for descriptive field contents and values that are not intended to be 5637 interpreted by the message parser. Words of *TEXT-UTF8 contain characters from the UTF-8 character 5638 set (RFC 2279 [7]). The TEXT-UTF8-TRIM rule is used for descriptive field contents that are not quoted 5639 strings, where leading and trailing LWS is not meaningful. In this regard, SIP differs from HTTP, which 5640 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

5641

5642 A CRLF is allowed in the definition of TEXT-UTF8-TRIM only as part of a header field continuation. 5643 It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT-5644 UTF8-TRIM value. 5645 Hexadecimal numeric characters are used in several protocol elements. Some elements (authentication) 5646 force hex alphas to be lower case.

LHEX = DIGIT / %x61-66 ;lowercase a-f

5647

5648 Many SIP header field values consist of words separated by LWS or special characters. Unless otherwise 5649 stated, tokens are case-insensitive. These special characters must be in a quoted string to be used within a 5650 parameter value. The word construct is used in Call-ID to allow most separators to be used.

token  = 1*(alphanum / ”-” / ”.” / ”!” / ”%” / ”*”

/ ” ” / ”+” / ”‘” / ”’” / ”˜ ” )

separators = ”(” / ”)” / ”<” / ”>” / ”@” /

”,” / ”;” / ”:” / ”\” / <”> / ”/” / ”[” / ”]” / ”?” / ”=” / ”{” / ”}” / SP / HTAB

word  = 1*(alphanum / ”-” / ”.” / ”!” / ”%” / ”*” /

” ” / ”+” / ”‘” / ”’” / ”˜ ” / ”(” / ”)” / ”<” / ”>” / ”:” / ”\” / <”> / ”/” / ”[” / ”]” / ”?” /

”{” / ”}” ) 5651

5652 When tokens are used or separators are used between elements, whitespace is often allowed before or 5653 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

5654

5655 Comments can be included in some SIP header fields by surrounding the comment text with parentheses. 5656 Comments are only allowed in fields containing “comment” as part of their field value definition. In all other 5657 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 5658

5659 ctext includes all chars except left and right parens and backslash. A string of text is parsed as a single 5660 word if it is quoted using double-quote marks. In quoted strings, quotation marks (”) and backslashes (\) 5661 need to be escaped.

quoted-string = SWS <”> *(qdtext / quoted-pair ) <”>
qdtext  = LWS / %x21 / %x23-5B / %x5D-7E

/ UTF8-NONASCII

5662

5663 The backslash character (”\”) may be used as a single-character quoting mechanism only within quoted-5664 string and comment constructs. Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this 5665 mechanism to avoid conflict with line folding and header separation.

quoted-pair = ”\” (%x00-09 / %x0B-0C

/ %x0E-7F) 5666

SIP-URI  = ”sip:” [ userinfo ”@” ] hostport

uri-parameters [ headers ]

SIPS-URI  = ”sips:” [ userinfo ”@” ] hostport

uri-parameters [ headers ]

userinfo  = [ user / telephone-subscriber [ ”:” password ]]
user  = *( 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

5667

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

5668

5669 The BNF for telephone-subscriber can be found in RFC 2806 [9]. Note, however, that any characters 5670 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 = ”[” / ”]” / ”/” / ”:” / ”&” / ”+” / ”$”

5671

headers  = ”?” header *( ”&” header )
header  = hname ”=” hvalue
hname  = 1*( hnv-unreserved / unreserved / escaped )
hvalue  = *( hnv-unreserved / unreserved / escaped )
hnv-unreserved = ”[” / ”]” / ”/” / ”?” / ”:” / ”+” / ”$”

5672

SIP-message  = Request / Response
Request  = Request-Line

*( message-header )

CRLF

[ message-body ]

Request-Line = Method SP Request-URI SP SIP-Version CRLF
Request-URI  = SIP-URI / SIPS-URI / absoluteURI
absoluteURI  = scheme ”:” ( hier-part / opaque-part )
hier-part  = ( net-path / abs-path ) [ ”?” query ]
net-path  = ”//” authority [ abs-path ]
abs-path  = ”/” path-segments
opaque-part  = uric-no-slash *uric
uric  = reserved / unreserved / escaped
uric-no-slash  = unreserved / escaped / ”;” / ”?” / ”:” / ”@”

/ ”&” / ”=” / ”+” / ”$” / ”,”

path-segments = segment *( ”/” segment )
segment  = *pchar *( ”;” param )
param  = *pchar
pchar  = unreserved / escaped /

”:” / ”@” / ”&” / ”=” / ”+” / ”$” / ”,”

scheme  = ALPHA *( ALPHA / DIGIT / ”+” / ”-” / ”.” )
authority  = srvr / reg-name
srvr  = [ [ userinfo ”@” ] hostport ]
reg-name  = 1*( unreserved / escaped / ”$” / ”,”

/ ”;” / ”:” / ”@” / ”&” / ”=” / ”+” )

query  = *uric
SIP-Version  = ”SIP” ”/” 1*DIGIT ”.” 1*DIGIT

5673

INTERNET-DRAFT  draft-ietf-sip-rfc2543bis-07.9.ps  February 20, 2002
message-header = (Accept
/ Accept-Encoding
/ Accept-Language
/ Alert-Info
/ Allow
/ Authentication-Info
/ Authorization
/ Call-ID
/ Call-Info
/ Contact
/ Content-Disposition
/ Content-Encoding
/ Content-Language
/ Content-Length
/ Content-Type
/ CSeq
/ Date
/ Error-Info
/ Expires
/ From
/ In-Reply-To
/ Max-Forwards
/ MIME-Version
/ Min-Expires
/ Organization
/ Priority
/ Proxy-Authenticate
/ Proxy-Authorization
/ Proxy-Require
/ Record-Route
/ Reply-To
/ Require
/ Retry-After
/ Route
/ Server
/ Subject
/ Supported
/ Timestamp
/ To
/ Unsupported
/ User-Agent
/ Via
/ Warning
/ WWW-Authenticate
/ extension-header) CRLF

5674

J. Rosenberg,H. Schulzrinne,G. Camarillo,A. Johnston,J. Peterson,R. Sparks,M. Handley,E. Schooler Expires Aug 2002 [Page 160]

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 ]

5675

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)

5676

Informational = ”100” ; Trying
/ ”180” ; Ringing
/ ”181” ; Call Is Being Forwarded
/ ”182” ; Queued
/ ”183” ; Session Progress

5677

Success = ”200” ; OK

5678

Redirection = ”300” ; Multiple Choices
/ ”301” ; Moved Permanently
/ ”302” ; Moved Temporarily
/ ”305” ; Use Proxy
/ ”380” ; Alternative Service

5679

INTERNET-DRAFT  draft-ietf-sip-rfc2543bis-07.9.ps  February 20, 2002
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

5680

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

5681

Global-Failure = ”600” ; Busy Everywhere
/ ”603” ; Decline
/ ”604” ; Does not exist anywhere
/ ”606” ; Not Acceptable

5682

J. Rosenberg,H. Schulzrinne,G. Camarillo,A. Johnston,J. Peterson,R. Sparks,M. Handley,E. Schooler Expires Aug 2002 [Page 162]

Accept  = ”Accept” HCOLON

( accept-range *(COMMA accept-range) )

accept-range  = media-range [ accept-params ]
media-range  = ( ”*/*”

/ ( m-type SLASH ”*” )

/ ( m-type SLASH m-subtype )

) *( SEMI m-parameter )

accept-params  = SEMI ”q” EQUAL qvalue *( accept-extension )
accept-extension = SEMI ae-name [ EQUAL ae-value ]
ae-name  = token
ae-value  = token / quoted-string

5683

Accept-Encoding = ”Accept-Encoding” HCOLON

( encoding *(COMMA encoding) )

encoding  = codings [ SEMI ”q” EQUAL qvalue ]
codings  = content-coding / ”*”
content-coding  = token
qvalue  = ( ”0” [ ”.” 0*3DIGIT ] )

/ ( ”1” [ ”.” 0*3(”0”) ] ) 5684

Accept-Language = ”Accept-Language” HCOLON

( language *(COMMA language) )

language  = language-range [ SEMI ”q” EQUAL qvalue ]
language-range  = ( ( 1*8ALPHA *( ”-” 1*8ALPHA ) ) / ”*” )

5685

Alert-Info  = ”Alert-Info” HCOLON alert-param *(COMMA alert-param)
alert-param  = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )
generic-param = token [ EQUAL gen-value ]
gen-value  = token / host / quoted-string

5686

Allow = ”Allow” HCOLON Method *(COMMA Method)

5687

Authorization  = ”Authorization” HCOLON credentials
credentials  = (”Digest” LWS digest-response)

/ other-response

digest-response  = dig-resp *(COMMA dig-resp)
dig-resp  = username / realm / nonce / digest-uri

/ dresponse / [ algorithm ] / [cnonce] / [opaque] / [message-qop] / [nonce-count] / [auth-param]

username  = ”username” EQUAL username-value
username-value  = quoted-string
digest-uri  = ”uri” EQUAL LDQUOT digest-uri-value RDQUOT
digest-uri-value  = rquest-uri ; Equal to request-uri as specified by HTTP/1.1
message-qop  = ”qop” EQUAL qop-value
cnonce  = ”cnonce” EQUAL cnonce-value
cnonce-value  = nonce-value
nonce-count  = ”nc” EQUAL nc-value
nc-value  = 8LHEX
dresponse  = ”response” EQUAL request-digest
request-digest  = LDQUOT 32LHEX RDQUOT
auth-param  = auth-param-name EQUAL

( token / quoted-string )

auth-param-name = token
other-response  = auth-scheme LWS auth-param

*(COMMA auth-param)

auth-scheme  = token

5688

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

5689

Call-ID = ( ”Call-ID” / ”i” ) HCOLON callid
callid = word [ ”@” word ]

5690

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

5691

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

5692

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

5693

Content-Disposition = ”Content-Disposition” HCOLON

disp-type *( SEMI disp-param )

disp-type  = ”render” / ”session” / ”icon” / ”alert”

/ disp-extension-token

disp-param  = handling-param / generic-param
handling-param  = ”handling” EQUAL

( ”optional” / ”required”

/ other-handling )

other-handling  = token
disp-extension-token = token

5694

Content-Encoding = ( ”Content-Encoding” / ”e” ) HCOLON

content-coding *(COMMA content-coding)

5695

Content-Language = ”Content-Language” HCOLON

language-tag *(COMMA language-tag)

language-tag  = primary-tag *( ”-” subtag )
primary-tag  = 1*8ALPHA
subtag  = 1*8ALPHA

5696

Content-Length = ( ”Content-Length” / ”l” ) HCOLON 1*DIGIT

5697

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

5698

CSeq = ”CSeq” HCOLON 1*DIGIT LWS Method

5699

Date  = ”Date” HCOLON SIP-date
SIP-date  = rfc1123-date
rfc1123-date = wkday ”,” 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”

5700

Error-Info = ”Error-Info” HCOLON error-uri *(COMMA error-uri)
error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )

5701

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

5702

In-Reply-To = ”In-Reply-To” HCOLON callid *(COMMA callid)

5703

Max-Forwards = ”Max-Forwards” HCOLON 1*DIGIT

5704

MIME-Version = ”MIME-Version” HCOLON 1*DIGIT ”.” 1*DIGIT

5705

Min-Expires = ”Min-Expires” HCOLON delta-seconds

5706

Organization = ”Organization” HCOLON TEXT-UTF8-TRIM

5707

Priority  = ”Priority” HCOLON priority-value
priority-value = ”emergency” / ”urgent” / ”normal”

/ ”non-urgent” / other-priority

other-priority = token

5708

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

5709

Proxy-Authorization = ”Proxy-Authorization” HCOLON credentials

5710

Proxy-Require = ”Proxy-Require” HCOLON option-tag

*(COMMA option-tag)

option-tag  = token

5711

Record-Route = ”Record-Route” HCOLON rec-route *(COMMA rec-route)
rec-route  = name-addr *( SEMI rr-param )
rr-param  = generic-param

5712

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)

5713

Retry-After = ”Retry-After” HCOLON delta-seconds

[ comment ] *( SEMI retry-param )

retry-param = (”duration” EQUAL delta-seconds)

/ generic-param

5714

Route  = ”Route” HCOLON route-param *(COMMA route-param)
route-param = name-addr *( SEMI rr-param )

5715

Server  = ”Server” HCOLON 1*( product / comment )
product  = token [SLASH product-version]
product-version = token

5716

Subject = ( ”Subject” / ”s” ) HCOLON TEXT-UTF8-TRIM

5717

Supported = ( ”Supported” / ”k” ) HCOLON

[option-tag *(COMMA option-tag)]

5718

Timestamp = ”Timestamp” HCOLON 1*(DIGIT)

[ ”.” *(DIGIT) ] [ delay ]

delay  = *(DIGIT) [ ”.” *(DIGIT) ]

5719

To  = ( ”To” / ”t” ) HCOLON ( name-addr

/ addr-spec ) *( SEMI to-param )

to-param = tag-param / generic-param

5720

Unsupported = ”Unsupported” HCOLON option-tag *(COMMA option-tag)

5721

User-Agent = ”User-Agent” HCOLON 1*( product / comment )

5722

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

5723

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

5724

WWW-Authenticate = ”WWW-Authenticate” HCOLON challenge

5725

extension-header = header-name HCOLON header-value
header-name  = token
header-value  = *(TEXT-UTF8char / UTF8-CONT / LWS)

5726

message-body = *OCTET

5727

5728 26 Security Considerations: Threat Model and Security Usage Recommen-5729 dations

5730 SIP is not an easy protocol to secure. Its use of intermediaries, its multi-faceted trust relationships, its 5731 expected usage between elements with no trust at all, and its user-to-user operation make security far from 5732 trivial. Security solutions are needed that are deployable today, without extensive coordination, in a wide 5733 variety of environments and usages. In order to meet these diverse needs, several distinct mechanisms 5734 applicable to different aspects and usages of SIP will be required. 5735 Note that the security of SIP signaling itself has no bearing on the security of protocols used in concert 5736 with SIP such as RTP, or with the security implications of any specific bodies SIP might carry (although 5737 MIME security plays a substantial role in securing SIP). Any media associated with a session can be en-5738 crypted end-to-end independently of any associated SIP signaling. Media encryption is outside the scope of 5739 this document. 5740 The considerations that follow first examine a set of classic threat models that broadly identify the 5741 security needs of SIP. The set of security services required to address these threats is then detailed, followed 5742 by an explanation of several security mechanisms that can be used to provide these services. Next, the 5743 requirements for implementers of SIP are enumerated, along with exemplary deployments in which these 5744 security mechanisms could be used to improve the security of SIP. Some notes on privacy conclude this 5745 section.

5746 26.1 Attacks and Threat Models

5747 This section details some threats that should be common to most deployments of SIP. These threats have 5748 been chosen specifically to illustrate each of the security services that SIP requires. 5749 The following examples by no means provide an exhaustive list of the threats against SIP; rather, these 5750 are ”classic” threats that demonstrate the need for particular security services that can potentially prevent 5751 whole categories of threats.

5752 These attacks assume an environment in which attackers can potentially read any packet on the network 5753 - it is anticipated that SIP will frequently be used on the public Internet. Attackers on the network may be 5754 able to modify packets (perhaps at some compromised intermediary). Attackers may wish to steal services, 5755 eavesdrop on communications, or disrupt sessions.

5756 26.1.1 Registration Hijacking

5757 The SIP registration mechanism allows a user agent to identify itself to a registrar as a device at which a 5758 user (designated by an address of record) is located. A registrar assesses the identity asserted in the From 5759 header field of a REGISTER message to determine whether this request can modify the contact addresses 5760 associated with the address-of-record in the To header field. While these two fields are frequently the same, 5761 there are many valid deployments in which a third-party may register contacts on a user’s behalf. 5762 The From header field of a SIP request, however, can be modified arbitrarily by the owner of a UA, and 5763 this opens the door to malicious registrations. An attacker that successfully impersonates a party authorized 5764 to change contacts associated with an address-of-record could, for example, de-register all existing contacts 5765 for a URI and then register their own device as the appropriate contact address, thereby directing all requests 5766 for the affected user to the attacker’s device. 5767 This threat belongs to a family of threats that rely on the absence of cryptographic assurance of a re-5768 quest’s originator. Any SIP UAS that represents a valuable service (a gateway that interworks SIP requests 5769 with traditional telephone calls, for example) might want to control access to its resources by authenticating 5770 requests that it receives. Even end-user UAs, for example SIP phones, have an interest in ascertaining the 5771 identities of originators of requests. 5772 This threat demonstrates the need for security services that enable SIP entities to authenticate the origi-5773 nators of requests.

5774 26.1.2 Impersonating a Server

5775 The domain to which a request is destined is generally specified in the Request-URI. UAs commonly 5776 contact a server in this domain directly in order to deliver a request. However, there is always a possibility 5777 that an attacker could impersonate the remote server, and that the UA’s request could be intercepted by some 5778 other party. 5779 For example, consider a case in which a redirect server at one domain, chicago.com, impersonates a 5780 redirect server at another domain, biloxi.com. A user agent sends a request to biloxi.com, but the redirect 5781 server at chicago.com answers with a forged response that has appropriate SIP header fields for a response 5782 from biloxi.com. The forged contact addresses in the redirection response could direct the originating UA 5783 to inappropriate or insecure resources, or simply prevent requests for biloxi.com from succeeding. 5784 This family of threats has a vast membership, many of which are critical. As a converse to the registration 5785 hijacking threat, consider the case in which a registration sent to biloxi.com is intercepted by chicago.com, 5786 which replies to the intercepted registration with a forged 301 (Moved Permanently) response. This response 5787 might seem to come from biloxi.com yet designate chicago.com as the appropriate registrar. All future 5788 REGISTER requests from the originating UA would then go to chicago.com. 5789 Prevention of this threat requires a means by which UAs can authenticate the servers to whom they send 5790 requests.

5791 26.1.3 Tampering with Message Bodies

5792 As a matter of course, SIP UAs route requests through trusted proxy servers. Regardless of how that trust is 5793 established (authentication of proxies is discussed elsewhere in this section), a UA may trust a proxy server 5794 to route a request, but not to inspect or possibly modify the bodies contained in that request. 5795 Consider a UA that is using SIP message bodies to communicate session encryption keys for a media 5796 session. Although it trusts the proxy server of the domain it is contacting to deliver signaling properly, it 5797 may not want the administrators of that domain to be capable of decrypting any subsequent media session. 5798 Worse yet, if the proxy server were actively malicious, it could modify the session key, either acting as a 5799 man-in-the-middle, or perhaps changing the security characteristics requested by the originating UA. 5800 This family of threats applies not only to session keys, but to most conceivable forms of content car-5801 ried end-to-end in SIP. These might include MIME bodies that should be rendered to the user, SDP, or 5802 encapsulated telephony signals, among others. Attackers might attempt to modify SDP bodies, for example, 5803 in order to point RTP media streams to a wiretapping device in order to eavesdrop on subsequent voice 5804 communications. 5805 Also note that some header fields in SIP are meaningful end-to-end, for example, Subject. UAs might 5806 be protective of these header fields as well as bodies (a malicious intermediary changing the Subject header 5807 field might make an important request appear to be spam, for example). However, since many header fields 5808 are legitimately inspected or altered by proxy servers as a request is routed, not all header fields should be 5809 secured end-to-end. 5810 For these reasons, the UA might want to secure SIP message bodies, and in some limited cases header 5811 fields, end-to-end. The security services required for bodies include confidentiality, integrity, and authen-5812 tication. These end-to-end services should be independent of the means used to secure interactions with 5813 intermediaries such as proxy servers.

5814 26.1.4 Tearing Down Sessions

5815 Once a dialog has been established by initial messaging, subsequent requests can be sent that modify the 5816 state of the dialog and/or session. It is critical that principals in a session can be certain that such requests 5817 are not forged by attackers. 5818 Consider a case in which a third-party attacker captures some initial messages in a dialog shared by two 5819 parties in order to learn the parameters of the session (To tag, From tag, and so forth) and then inserts a 5820 BYE request into the session. The attacker could opt to forge the request such that it seemed to come from 5821 either participant. Once the BYE is received by its target, the session will be torn down prematurely. 5822 Similar mid-session threats include the transmission of forged re-INVITEs that alter the session (possibly 5823 to reduce session security or redirect media streams as part of a wiretapping attack). 5824 The most effective countermeasure to this threat is the authentication of the sender of the BYE. In this 5825 instance, the recipient needs only know that the BYE came from the same party with whom the correspond-5826 ing dialog was established (as opposed to ascertaining the absolute identity of the sender). Also, if the 5827 attacker is unable to learn the parameters of the session due to confidentiality, it would not be possible to 5828 forge the BYE. However, some intermediaries (like proxy servers) will need to inspect those parameters as 5829 the session is established.

5830 26.1.5 Denial of Service and Amplification

5831 Denial-of-service attacks focus on rendering a particular network element unavailable, usually by directing 5832 an excessive amount of network traffic at its interfaces. A distributed denial-of-service attack allows one 5833 network user to cause multiple network hosts to flood a target host with a large amount of network traffic. 5834 In many architectures, SIP proxy servers face the public Internet in order to accept requests from world-5835 wide IP endpoints. SIP creates a number of potential opportunities for distributed denial-of-service attacks 5836 that must be recognized and addressed by the implementers and operators of SIP systems. 5837 Attackers can create bogus requests that contain a falsified source IP address and a corresponding Via 5838 header field that identify a targeted host as the originator of the request and then send this request to a large 5839 number of SIP network elements, thereby using hapless SIP UAs or proxies to generate denial-of-service 5840 traffic aimed at the target. 5841 Similarly, attackers might use falsified Route header field values in a request that identify the target 5842 host and then send such messages to forking proxies that will amplify messaging sent to the target. Record-5843 Route could be used to similar effect when the attacker is certain that the SIP dialog initiated by the request 5844 will result in numerous transactions originating in the backwards direction. 5845 A number of denial-of-service attacks open up if REGISTER requests are not properly authenticated 5846 and authorized by registrars. Attackers could de-register some or all users in an administrative domain, 5847 thereby preventing these users from being invited to new sessions. An attacker could also register a large 5848 number of contacts designating the same host for a given address-of-record in order to use the registrar and 5849 any associated proxy servers as amplifiers in a denial-of-service attack. Attackers might also attempt to 5850 deplete available memory and disk resources of a registrar by registering huge numbers of bindings. 5851 The use of multicast to transmit SIP requests can greatly increase the potential for denial-of-service 5852 attacks. 5853 These problems demonstrate a general need to define architectures that minimize the risks of denial-of-5854 service, and the need to be mindful in recommendations for security mechanisms of this class of attacks.

5855 26.2 Security Mechanisms

5856 From the threats described above, we gather that the fundamental security services required for the SIP 5857 protocol are: preserving the confidentiality and integrity of messaging, preventing replay attacks or message 5858 spoofing, providing for the authentication and privacy of the participants in a session, and preventing denial-5859 of-service attacks. Bodies within SIP messages separately require the security services of confidentiality, 5860 integrity, and authentication. 5861 Rather than defining new security mechanisms specific to SIP, SIP reuses wherever possible existing 5862 security models derived from the HTTP and SMTP space. 5863 Full encryption of messages provides the best means to preserve the confidentiality of signaling - it 5864 can also guarantee that messages are not modified by any malicious intermediaries. However, SIP requests 5865 and responses cannot be naively encrypted end-to-end in their entirety because message fields such as the 5866 Request-URI, Route, and Via need to be visible to proxies in most network architectures so that SIP 5867 requests are routed correctly. Note that proxy servers need to modify some features of messages as well (such 5868 as adding Via header field values) in order for SIP to function. Proxy servers must therefore be trusted, to 5869 some degree, by SIP UAs. To this purpose, low-layer security mechanisms for SIP are recommended, which 5870 encrypt the entire SIP requests or responses on the wire on a hop-by-hop basis, and that allow endpoints to 5871 verify the identity of proxy servers to whom they send requests. 5872 SIP entities also have a need to identify one another in a secure fashion. When a SIP endpoint asserts 5873 the identity of its user to a peer UA or to a proxy server, that identity should in some way be verifiable. A 5874 cryptographic authentication mechanism is provided in SIP to address this requirement. 5875 An independent security mechanism for SIP message bodies supplies an alternative means of end-to-end 5876 mutual authentication, as well as providing a limit on the degree to which user agents must trust intermedi-5877 aries.

5878 26.2.1 Transport and Network Layer Security

5879 Transport or network layer security encrypts signaling traffic, guaranteeing message confidentiality and 5880 integrity. 5881 Oftentimes, certificates are used in the establishment of lower-layer security, and these certificates can 5882 also be used to provide a means of authentication in many architectures. 5883 Two popular alternatives for providing security at the transport and network layer are, respectively, TLS 5884 [24] and IPSec [25]. 5885 IPSec is a set of network-layer protocol tools that collectively can be used as a secure replacement for 5886 traditional IP (Internet Protocol). IPSec is most commonly used in architectures in which a set of hosts or 5887 administrative domains have an existing trust relationship with one another. IPSec is usually implemented 5888 at the operating system level in a host, or on a security gateway that provides confidentiality and integrity 5889 for all traffic it receives from a particular interface (as in a VPN architecture). IPSec can also be used on a 5890 hop-by-hop basis. 5891 In many architectures IPSec does not require integration with SIP applications; IPSec is perhaps best 5892 suited to deployments in which adding security directly to SIP hosts would be arduous. UAs that have a 5893 pre-shared keying relationship with their first-hop proxy server are also good candidates to use IPSec. Any 5894 deployment of IPSec for SIP would require an IPSec profile describing the protocol tools that would be 5895 required to secure SIP. No such profile is given in this document. 5896 TLS provides transport-layer security over connection-oriented protocols (for the purposes of this docu-5897 ment, TCP); “tls” (signifying TLS over TCP) can be specified as the desired transport protocol within a Via 5898 header field value or a SIP-URI. TLS is most suited to architectures in which hop-by-hop security is required 5899 between hosts with no pre-existing trust association. For example, Alice trusts her local proxy server, which 5900 after a certificate exchange decides to trust Bob’s local proxy server, which Bob trusts, hence Bob and Alice 5901 can communicate securely. 5902 TLS must be tightly coupled with a SIP application. Note that transport mechanisms are specified on 5903 a hop-by-hop basis in SIP, thus a UA that sends requests over TLS to a proxy server has no assurance that 5904 TLS will be used end-to-end. 5905 The TLS RSA WITH AES 128 CBC SHA ciphersuite must be supported at a minimum by imple-5906 menters when TLS is used in a SIP application. For purposes of backwards compatibility, proxy servers, 5907 redirect servers, and registrars should support TLS RSA WITH 3DES EDE CBC SHA. Implementers 5908 may also support any other ciphersuite.

5909 26.2.2 SIPS URI scheme

5910 The SIPS URI scheme adheres to the syntax of the SIP URI (described in 19), although the scheme string is 5911 ”sips” rather than ”sip”. The semantics of SIPS are very different from the SIP URI, however. 5912 A SIPS URI can be used as an address-of-record for a particular user - the URI by which the user is 5913 canonically known (on their business cards, in the From header field of their requests, in the To header field 5914 of REGISTER requests). When used as the Request-URI of a request, the SIPS scheme signifies that each 5915 hop over which the request is forwarded must be secured with TLS. When used by the originator of a request 5916 (as would be the case if they encountered a SIPS URI as the address-of-record of the target), SIPS dictates 5917 that the entire request path be so secured. No other mechanism in SIP allows the originator of a request to 5918 specify security characteristics that are preferred for the entire request path. 5919 The SIPS scheme is also applicable to many of the other ways in which SIP URIs are used in SIP today, 5920 including in the Request-URI, in addresses-of-record, contact addresses (populating Contact headers, in-5921 cluding those of REGISTER methods), and Route headers. The SIPS URI scheme allows these existing 5922 fields to designate secure resources. 5923 In effect, using SIPS in the Request-URI ensures that TLS is used on every segment between the 5924 originator of the request and the destination. This is a handy service, though one that is useful only in 5925 architectures in which it is desirable to use TLS for every hop. 5926 The use of SIPS in particular entails that mutual TLS authentication should be employed, as should 5927 the ciphersuite TLS RSA WITH AES 128 CBC SHA. Certificates received in the authentication process 5928 should be verified against root certificates in the client; failure to verify a certificate should result in the 5929 failure of the request. 5930 motivationNote that in the SIPS URI scheme, transport is independent of TLS, and thus “sips:alice@atlanta.com;transport=tcp” 5931 and “sips:alice@atlanta.com;transport=sctp” are both valid (although note that UDP is not a valid transport 5932 for SIPS). The use of “transport=tls” has consequently been deprecated, partly because it was specific to a 5933 single hop of the request. This is a change since RFC 2543. 5934 Users that distribute a SIPS URI as an address-of-record may elect to operate devices that do not even 5935 accept requests over insecure transports.

5936 26.2.3 HTTP Authentication

5937 SIP provides a challenge capability, based on HTTP authentication, that relies on the 401 and 407 response 5938 codes as well as header fields for carrying challenges and credentials. Without significant modification, the 5939 reuse of the HTTP Digest authentication scheme in SIP allows for replay protection and one-way authenti-5940 cation. 5941 The usage of Digest authentication in SIP is detailed in Section 22.

5942 26.2.4 S/MIME

5943 As is discussed above, encrypting entire SIP messages end-to-end for the purpose of confidentiality is not 5944 appropriate because network intermediaries (like proxy servers) need to view certain header fields in order 5945 to route messages correctly, and if these intermediaries are excluded from security associations, then SIP 5946 messages will essentially be non-routable. 5947 However, S/MIME allows SIP UAs to encrypt MIME bodies within SIP, securing these bodies end-to-5948 end without affecting message headers. S/MIME can provide end-to-end confidentiality and integrity for 5949 message bodies, as well as mutual authentication. It is also possible to use S/MIME to provide a form of 5950 integrity and confidentiality for SIP header fields through SIP message tunneling. 5951 The usage of S/MIME in SIP is detailed in Section 23.

5952 26.3 Implementing Security Mechanisms

5953 26.3.1 Requirements for Implementers of SIP

5954 Proxy servers, redirect servers, and registrars must implement TLS, and must support both mutual and 5955 one-way authentication. It is strongly recommended that UAs be capable initiating TLS; UAs may 5956 also be capable of acting as a TLS server. Proxy servers, redirect servers, and registrars should possess 5957 a site certificate whose subject corresponds to their canonical hostname. UAs may have certificates of 5958 their own for mutual authentication with TLS, but no provisions are set forth in this document for their 5959 use. All SIP elements that support TLS must have a mechanism for verifying certificates received during 5960 TLS negotiation; this entails possession of one or more root certificates issued by certificate authorities 5961 (preferably well-known distributors of site certificates comparable to those issuing root certificates for web 5962 browsers). All SIP elements that support TLS must also support the SIPS URI scheme. 5963 Proxy servers, redirect servers, registrars, and UAs may also implement IPSec or other lower-layer 5964 security protocols. 5965 When a UA attempts to contact a proxy server, redirect server, or registrar, the UAC should initiate a 5966 TLS connection over which it will send SIP messages. In some architectures, UASs may receive requests 5967 over such TLS connections as well. 5968 Proxy servers, redirect servers, registrars, and UAs must implement Digest Authorization, encompassing 5969 all of the aspects required in 22. Proxy servers, redirect servers, and registrars should be configured with 5970 at least one Digest realm, and at least one “realm” string supported by a given server should correspond 5971 to the server’s hostname or domainname. 5972 UAs may support the signing and encrypting of MIME bodies, and transference of credentials with 5973 S/MIME as described in 23. If a UA holds one or more root certificates of certificate authorities in order to 5974 verify certificates for TLS or IPSec, it should be capable of reusing these to verify S/MIME certificates, 5975 as appropriate. A UA may hold root certificates specifically for verifying S/MIME certificates.

5976 Note that is it anticipated that future security extensions may upgrade the normative strength associated with 5977 S/MIME as S/MIME implementations appear and the problem space becomes better understood.

5978 26.3.2 Security Solutions

5979 The operation of these security mechanisms in concert can follow the existing web and email security models 5980 to some degree. At a high level, UAs authenticate themselves to servers (proxy servers, redirect servers, and 5981 registrars) with a Digest username and password; servers authenticate themselves to UAs one hop away, or 5982 to another server one hop away (and vice versa), with a site certificate delivered by TLS. 5983 On a peer-to-peer level, UAs trust the network to authenticate one another ordinarily; however, S/MIME 5984 can also be used to provide direct authentication when the network does not, or if the network itself is not 5985 trusted. 5986 The following is an illustrative example in which these security mechanisms are used by various UAs 5987 and servers to prevent the sorts of threats described in Section 26.1. While implementers and network 5988 administrators may follow the normative guidelines given in the remainder of this section, these are provided 5989 only as example implementations.

5990 26.3.2.1 Registration When a UA comes online and registers with its local administrative domain, it 5991 should establish a TLS connection with its registrar (Section 10 describes how the UA reaches its reg-5992 istrar). The registrar should offer a certificate to the UA, and the site identified by the certificate must 5993 correspond with the domain in which the UA intends to register; for example, if the UA intends to register 5994 the address-of-record ’alice@atlanta.com’, the site certificate must identify a host within the atlanta.com 5995 domain (such as sip.atlanta.com). When it receives the TLS Certificate message, the UA should verify the 5996 certificate and inspect the site identified by the certificate. If the certificate is invalid, revoked, or if it does 5997 not identify the appropriate party, the UA must not send the REGISTER message and otherwise proceed 5998 with the registration.

5999 When a valid certificate has been provided by the registrar, the UA knows that the registrar is not an attacker 6000 who might redirect the UA, steal passwords, or attempt any similar attacks.

6001 The UA then creates a REGISTER request that should be addressed to a Request-URI correspond-6002 ing to the site certificate received from the registrar. When the UA sends the REGISTER request over 6003 the existing TLS connection, the registrar should challenge the request with a 401 (Proxy Authentication 6004 Required) response. The “realm” parameter within the Proxy-Authenticate header field of the response 6005 should correspond to the domain previously given by the site certificate. When the UAC receives the 6006 challenge, it should either prompt the user for credentials or take an appropriate credential from a keyring 6007 corresponding to the “realm” parameter in the challenge. The username of this credential should corre-6008 spond with the “userinfo” portion of the URI in the To header field of the REGISTER request. Once the 6009 Digest credentials have been inserted into an appropriate Proxy-Authorization header field, the REGIS-6010 TER should be resubmitted to the registrar.

6011 Since the registrar requires the user agent to authenticate itself, it would be difficult for an attacker to forge REG-6012 ISTER requests for the user’s address-of-record. Also note that since the REGISTER is sent over a confidential 6013 TLS connection, attackers will not be able to intercept the REGISTER to record credentials for any possible replay 6014 attack.

6015 Once the registration has been accepted by the registrar, the UA should leave this TLS connection 6016 open provided that the registrar also acts as the proxy server to which requests are sent for users in this 6017 administrative domain. The existing TLS connection will be reused to deliver incoming requests to the UA 6018 that has just completed registration.

6019 Because the UA has already authenticated the server on the other side of the TLS connection, all requests that 6020 come over this connection are known to have passed through the proxy server - attackers cannot create spoofed 6021 requests that appear to have been sent through that proxy server.

6022 26.3.2.2 Interdomain Requests Now let’s say that Alice’s UA would like to initiate a session with a user 6023 in a remote administrative domain, namely “bob@biloxi.com”. We will also say that the local administrative 6024 domain (atlanta.com) has a local outbound proxy. 6025 The proxy server that handles inbound requests for an administrative domain may also act as a local 6026 outbound proxy; for simplicity’s sake we’ll assume this to be the case for atlanta.com (otherwise the user 6027 agent would initiate a new TLS connection to a separate server at this point). Assuming that the client has 6028 completed the registration process described in the preceding section, it should reuse the TLS connection 6029 to the local proxy server when it sends an INVITE request to another user. The UA should reuse cached 6030 credentials in the INVITE to avoid prompting the user unnecessarily. 6031 When the local outbound proxy server has validated the credentials presented by the UA in the INVITE, 6032 it should inspect the Request-URI to determine how the message should be routed (see [4]). If the 6033 “domainname” portion of the Request-URI had corresponded to the local domain (atlanta.com) rather than 6034 biloxi.com, then the proxy server would have consulted its location service to determine how best to reach 6035 the requested user.

6036 Had “alice@atlanta.com” been attempting to contact, say, “alex@atlanta.com”, the local proxy would have 6037 proxied to the request to the TLS connection Alex had established with the registrar when he registered. Since 6038 Alex would receive this request over his authenticated channel, he would be assured that Alice’s request had been 6039 authorized by the proxy server of the local administrative domain.

6040 However, in this instance the Request-URI designates a remote domain. The local outbound proxy 6041 server at atlanta.com should therefore establish a TLS connection with the remote proxy server at biloxi.com. 6042 Since both of the participants in this TLS connection are servers that possess site certificates, mutual TLS 6043 authentication should occur. Each side of the connection should verify and inspect the certificate of 6044 the other, noting the domain name that appears in the certificate for comparison with the header fields of 6045 SIP messages. The atlanta.com proxy server, for example, should verify at this stage that the certificate 6046 received from the remote side corresponds with the biloxi.com domain. Once it has done so, and TLS ne-6047 gotiation has completed, resulting in a secure channel between the two proxies, the atlanta.com proxy can 6048 forward the INVITE request to biloxi.com. 6049 The proxy server at biloxi.com should inspect the certificate of the proxy server at atlanta.com in turn 6050 and compare the domain asserted by the certificate with the “domainname” portion of the From header field 6051 in the INVITE request. The biloxi proxy may have a strict security policy that requires it to reject requests 6052 that do not match the administrative domain from which they have been proxied.

6053 Such security policies could be instituted to prevent the SIP equivalent of SMTP ’open relays’ that are frequently 6054 exploited to generate spam.

6055 This policy, however, only guarantees that the request came from the domain it ascribes to itself; it 6056 does not allow biloxi.com to ascertain how atlanta.com authenticated Alice. Only if biloxi.com has some 6057 other way of knowing atlanta.com’s authentication policies could it possibly ascertain how Alice proved her 6058 identity. biloxi.com might then institute an even stricter policy that forbids requests that come from domains 6059 that are not known administratively to share a common authentication policy with biloxi.com. 6060 Once the INVITE has been approved by the biloxi proxy, the proxy server should identify the existing 6061 TLS channel, if any, associated with the user targeted by this request (in this case “bob@biloxi.com”). The 6062 INVITE should be proxied through this channel to Bob. Since the request is received over a TLS connection 6063 that had previously been authenticated as the biloxi proxy, Bob knows that the From header field was not 6064 tampered with and that atlanta.com has validated Alice, although not necessarily whether or not to trust 6065 Alice’s identity. 6066 Before they forward the request, both proxy servers should add a Record-Route header field to the 6067 request so that all future requests in this dialog will pass through the proxy servers. The proxy servers can 6068 thereby continue to provide security services for the lifetime of this dialog. If the proxy servers do not add 6069 themselves to the Record-Route, future messages will pass directly end-to-end between Alice and Bob 6070 without any security services (unless the two parties agree on some independent end-to-end security such 6071 as S/MIME). In this respect the SIP trapezoid model can provide a nice structure where conventions of 6072 agreement between the site proxies can provide a reasonably secure channel between Alice and Bob.

6073 An attacker preying on this architecture would, for example, be unable to forge a BYE request and insert it into 6074 the signaling stream between Bob and Alice because the attacker has no way of ascertaining the parameters of the 6075 session and also because the integrity mechanism transitively protects the traffic between Alice and Bob.

6076 26.3.2.3 Peer to Peer Requests Alternatively, consider a UA asserting the identity “carol@chicago.com” 6077 that has no local outbound proxy. When Carol wishes to send an INVITE to “bob@biloxi.com”, her UA 6078 should initiate a TLS connection with the biloxi proxy directly (using the mechanism described in [4] 6079 to determine how to best to reach the given Request-URI). When her UA receives a certificate from the 6080 biloxi proxy, it should be verified normally before she passes her INVITE across the TLS connection. 6081 However, Carol has no means of proving her identity to the biloxi proxy, but she does have a CMS-detached 6082 signature over a “message/sip” body in the INVITE. It is unlikely in this instance that Carol would have any 6083 credentials in the biloxi.com realm, since she has no formal association with biloxi.com. The biloxi proxy 6084 may also have a strict policy that precludes it from even bothering to challenge requests that do not have 6085 biloxi.com in the “domainname” portion of the From header field - it treats these users as unauthenticated. 6086 The biloxi proxy has a policy for Bob that all non-authenticated requests should be redirected to the 6087 appropriate contact address registered against ’bob@biloxi.com’, namely <sip:bob@192.0.2.4>. Carol 6088 receives the redirection response over the TLS connection she established with the biloxi proxy, so she 6089 trusts the veracity of the contact address. 6090 Carol should then establish a TCP connection with the designated address and send a new INVITE 6091 with a Request-URI containing the received contact address (recomputing the signature in the body as 6092 the request is readied). Bob receives this INVITE on an insecure interface, but his UA inspects and, in 6093 this instance, recognizes the From header field of the request and subsequently matches a locally cached 6094 certificate with the one presented in the signature of the body of the INVITE. He replies in similar fashion, 6095 authenticating himself to Carol, and a secure dialog begins.

6096 Sometimes firewalls or NATs in an administrative domain could preclude the establishment of a direct TCP 6097 connection to a UA. In these cases, proxy servers could also potentially relay requests to UAs in a way that has no 6098 trust implications (for example, forgoing an existing TLS connection and forwarding the request over cleartext TCP) 6099 as local policy dictates.

6100 26.3.2.4 DoS Protection In order to minimize the risk of a denial-of-service attack against architectures 6101 using these security solutions, implementers should take note of the following guidelines. 6102 When the host on which a SIP proxy server is operating is routable from the public Internet, it should 6103 be deployed in an administrative domain with defensive operational policies (blocking source-routed traffic, 6104 preferably filtering ping traffic). Both TLS and IPSec can also make use of bastion hosts at the edges of 6105 administrative domains that participate in the security associations to aggregate secure tunnels and sockets. 6106 These bastion hosts can also take the brunt of denial-of-service attacks, ensuring that SIP hosts within the 6107 administrative domain are not encumbered with superfluous messaging. 6108 No matter what security solutions are deployed, floods of messages directed at proxy servers can lock up 6109 proxy server resources and prevent desirable traffic from reaching its destination. There is a computational 6110 expense associated with processing a SIP transaction at a proxy server, and that expense is greater for 6111 stateful proxy servers than it is for stateless proxy servers. Therefore, stateful proxies are more susceptible 6112 to flooding than stateless proxy servers. 6113 UAs and proxy servers should challenge questionable requests with only a single 401 (Unauthorized) 6114 or 407 (Proxy Authentication Required), forgoing the normal response retransmission algorithm, and thus 6115 behaving statelessly towards unauthenticated requests.

6116 Retransmitting the 401 (Unauthorized) or 407 (Proxy Authentication Required) status response amplifies the 6117 problem of an attacker using a falsified header field value (such as Via) to direct traffic to a third party.

6118 In summary, the mutual authentication of proxy servers through mechanisms such as TLS significantly 6119 reduces the potential for rogue intermediaries to introduce falsified requests or responses that can deny 6120 service. This commensurately makes it harder for attackers to make innocent SIP nodes into agents of 6121 amplification.

6122 26.4 Limitations

6123 Although these security mechanisms, when applied in a judicious manner, can thwart many threats, there are 6124 limitations in the scope of the mechanisms that must be understood by implementers and network operators.

6125 26.4.1 HTTP Digest

6126 One of the primary limitations of using HTTP Digest in SIP is that the integrity mechanisms in Digest do 6127 not work very well for SIP. Specifically, they offer protection of the Request-URI and the method of a 6128 message, but not for any of the header fields that UAs would most likely wish to secure. 6129 The existing replay protection mechanisms described in RFC 2617 also have some limitations for SIP. 6130 The next-nonce mechanism, for example, does not support pipelined requests. The nonce-count mechanism 6131 should be used for replay protection. 6132 Another limitation of HTTP Digest is the scope of realms. Digest is valuable when a user wants to 6133 authenticate themselves to a resource with which they have a pre-existing association, like a service provider 6134 of which the user is a customer (which is quite a common scenario and thus Digest provides an extremely 6135 useful function). By way of contrast, the scope of TLS is interdomain or multirealm, since certificates are 6136 often globally verifiable, so that the UA can authenticate the server with no pre-existing association.

6137 26.4.2 S/MIME

6138 The largest outstanding defect with the S/MIME mechanism is the lack of a prevalent public key infrastruc-6139 ture for end users. If self-signed certificates (or certificates that cannot be verified by one of the participants 6140 in a dialog) are used, the SIP-based key exchange mechanism described in Section 23.2 is susceptible to a 6141 man-in-the-middle attack with which an attacker can potentially inspect and modify S/MIME bodies. The 6142 attacker needs to intercept the first exchange of keys between the two parties in a dialog, remove the exist-6143 ing CMS-detached signatures from the request and response, and insert a different CMS-detached signature 6144 containing a certificate supplied by the attacker (but which seems to be a certificate for the proper address-6145 of-record). Each party will think they have exchanged keys with the other, when in fact each has the public 6146 key of the attacker. 6147 It is important to note that the attacker can only leverage this vulnerability on the first exchange of keys 6148 between two parties - on subsequent occasions, the alteration of the key would be noticeable to the UAs. It 6149 would also be difficult for the attacker to remain in the path of all future dialogs between the two parties 6150 over time (as potentially days, weeks, or years pass). 6151 SSH is susceptible to the same man-in-the-middle attack on the first exchange of keys; however, it is 6152 widely acknowledged that while SSH is not perfect, it does improve the security of connections. The use of 6153 key fingerprints could provide some assistance to SIP, just as it does for SSH. For example, if two parties use 6154 SIP to establish a voice communications session, each could read off the fingerprint of the key they received 6155 from the other, which could be compared against the original. It would certainly be more difficult for the 6156 man-in-the-middle to emulate the voices of the participants than their signaling (a practice that was used 6157 with the Clipper chip-based secure telephone). 6158 The S/MIME mechanism allows UAs to send encrypted requests without preamble if they possess a 6159 certificate for the destination address-of-record on their keyring. However, it is possible that any particular 6160 device registered for an address-of-record will not hold the certificate that has been previously employed by 6161 the device’s current user, and that it will therefore be unable to process an encrypted request properly, which 6162 could lead to some avoidable error signaling. This is especially likely when an encrypted request is forked.

6163 The keys associated with S/MIME are most useful when associated with a particular user (an address-6164 of-record) rather than a device (a UA). When users move between devices, it may be difficult to transport 6165 private keys securely between UAs; how such keys might be acquired by a device is outside the scope of 6166 this document. 6167 Another, more prosaic difficulty with the S/MIME mechanism is that it can result in very large messages, 6168 especially when the SIP tunneling mechanism described in Section 23.4 is used. For that reason, it is 6169 recommended that TCP should be used as a transport protocol when S/MIME tunneling is employed.

6170 26.4.3 TLS

6171 The most commonly voiced concern about TLS is that it cannot run over UDP; TLS requires a connection-6172 oriented underlying transport protocol, which for the purposes of this document means TCP. 6173 It may also be arduous for a local outbound proxy server and/or registrar to maintain many simultaneous 6174 long-lived TLS connections with numerous UAs. This introduces some valid scalability concerns, especially 6175 for intensive ciphersuites. Maintaining redundancy of long-lived TLS connections, especially when a UA is 6176 solely responsible for their establishment, could also be cumbersome. 6177 TLS only allows SIP entities to authenticate servers to which they are adjacent; TLS offers strictly 6178 hop-by-hop security. Neither TLS, nor any other mechanism specified in this document, allows clients to 6179 authenticate proxy servers to whom they cannot form a direct TCP connection.

6180 26.4.4 SIPS URIs

6181 Using TLS on every segment of a request path entails that the terminating UAS must be reachable over TLS. 6182 This means that many hybrid architectures that use TLS to secure part of the request path, but rely on some 6183 other mechanism for the final hop to a UAS, cannot make use of the SIPS AoR. Also, since many UAs will 6184 not accept incoming TLS connections, even those UAs that do support TLS may be required to maintain 6185 persistent TLS connections as described in the TLS limitations section above. 6186 It is very difficult to guarantee that TLS will be used end-to-end. It is possible that cryptographically 6187 authenticated proxy servers that are non-compliant or compromised may choose to disregard the forwarding 6188 rules associated with SIPS. These intermediaries may, for example, retarget a request from a SIPS URI to 6189 a SIP URI. It is therefore recommended that recipients of a request to SIP URI inspect the To header field 6190 value to see if it contains a SIPS URI. S/MIME may also be used to ensure that the original form of the To 6191 header field is carried end-to-end. Entities that accept only SIPS request may also refuse connections on 6192 insecure ports. 6193 End users will undoubtedly discern the difference between SIPS and SIP URIs, and they may manually 6194 edit them in response to stimuli. This can either benefit or degrade security. For example, if an attacker 6195 corrupts a DNS cache, inserting a fake record set that effectively removes all SIPS records for a proxy 6196 server, then any SIPS requests that traverse this proxy server may fail. When a user, however, sees that 6197 repeated calls to a SIPS AoR are failing, on some devices they could manually convert the scheme from 6198 SIPS to SIP and retry. Of course, there are some safeguards against this (if the destination UA is truly 6199 paranoid it could refuse all non-SIPS requests), but it is a limitation worth noting. On the bright side, users 6200 might also divine that ’SIPS’ would be valid even when they are presented only with a SIP URI.

6201 26.5 Privacy

6202 SIP messages frequently contain sensitive information about their senders - not just what they have to say, but 6203 with whom they communicate, when they communicate and for how long, and from where they participate 6204 in sessions. Many applications and their users require that this sort of private information be hidden from 6205 any parties that do not need to know it. 6206 Note that there are also less direct ways in which private information can be divulged. If a user or service 6207 chooses to be reachable at an address that is guessable from the person’s name and organizational affiliation 6208 (which describes most addresses-of-record), the traditional method of ensuring privacy by having an unlisted 6209 “phone number” is compromised. A user location service can infringe on the privacy of the recipient of a 6210 session invitation by divulging their specific whereabouts to the caller; an implementation consequently 6211 should be able to restrict, on a per-user basis, what kind of location and availability information is given 6212 out to certain classes of callers. This is a whole class of problem that is expected to be studied further in 6213 ongoing SIP work. 6214 In some cases, users may want to conceal personal information in header fields that convey identity. This 6215 can apply not only to the From and related headers representing the originator of the request, but also the 6216 To - it may not be appropriate to convey to the final destination a speed-dialing nickname, or an unexpanded 6217 identifier for a group of targets, either of which would be removed from the Request-URI as the request is 6218 routed, but not changed in the To header field if the two were initially identical. Thus it may be desirable 6219 for privacy reasons to create a To header field that differs from the Request-URI.

6220 27 IANA Considerations

6221 All new or experimental method names, header field names, and status codes used in SIP applications 6222 should be registered with IANA in order to prevent potential naming conflicts. It is recommended that 6223 new “option-tag”s and “warn-code”s also be registered. Before IANA registration, new protocol elements 6224 should be described in an Internet-Draft or, preferably, an RFC. 6225 For Internet-Drafts, IANA is requested to make the draft available as part of the registration database.

6226 By the time an RFC is published, colliding names may have already been implemented.

6227 When a registration for either a new header field, new method, or new status code is created based on 6228 an Internet-Draft, and that Internet-Draft becomes an RFC, the person that performed the registration must 6229 notify IANA to change the registration to point to the RFC instead of the Internet-Draft. 6230 Registrations should be sent to iana@iana.org.

6231 27.1 Option Tags

6232 Option tags are used in header fields such as Require, Supported, Proxy-Require, and Unsupported in 6233 support of SIP compatibility mechanisms for extensions (Section 19.2). The option tag itself is a string that 6234 is associated with a particular SIP option (that is, an extension). It identifies the option to SIP endpoints. 6235 When registering a new SIP option with IANA, the following information must be provided:

6236 • Name and description of option. The name may be of any length, but should be no more than 6237 twenty characters long. The name must consist of alphanum (Section 25) characters only.

6238 • A listing of any new SIP header fields, header parameter fields, or parameter values defined by this 6239 option. A SIP option must not redefine header fields or parameters defined in either RFC 2543, any 6240 standards-track extensions to RFC 2543, or other extensions registered through IANA.

6241 • Indication of who has change control over the option (for example, IETF, ISO, ITU-T, other interna-6242 tional standardization bodies, a consortium, or a particular company or group of companies).

6243 • A reference to a further description if available, for example (in order of preference) an RFC, a pub-6244 lished paper, a patent filing, a technical report, documented source code, or a computer manual.

6245 • Contact information (postal and email address).

6246 This procedure has been borrowed from RTSP [28] and the RTP AVP [40].

6247 27.2 Warn-Codes

6248 Warning codes provide information supplemental to the status code in SIP response messages when the 6249 failure of the transaction results from a Session Description Protocol (SDP, [1]). New “warn-code” values 6250 can be registered with IANA as they arise. 6251 The “warn-code” consists of three digits. A first digit of “3” indicates warnings specific to SIP. 6252 Warnings 300 through 329 are reserved for indicating problems with keywords in the session description, 6253 330 through 339 are warnings related to basic network services requested in the session description, 370 6254 through 379 are warnings related to quantitative QoS parameters requested in the session description, and 6255 390 through 399 are miscellaneous warnings that do not fall into one of the above categories.

6256 1xx and 2xx have been taken by HTTP/1.1.

6257 27.3 Header Field Names

6258 Header field names do not require working group or working group chair review prior to IANA registration, 6259 but should be documented in an RFC or Internet-Draft before IANA is consulted. 6260 The following information needs to be provided to IANA in order to register a new header field name:

6261 • The name and email address of the individual performing the registration;

6262 • the name of the header field being registered;

6263 • a compact form version for that header field, if one is defined;

6264 • the name of the draft or RFC where the header field is defined;

6265 • a copy of the draft or RFC where the header field is defined.

6266 Header fields should not use the X- prefix notation and must not duplicate the names of header 6267 fields used by SMTP or HTTP unless the syntax is a compatible superset and the semantics are similar. 6268 Some common and widely used header fields may be assigned one-letter compact forms (Section 7.3.3). 6269 Compact forms can only be assigned after SIP working group review. In the absence of this working group, 6270 a designated expert reviews the request.

6271 27.4 Method and Response Codes

6272 Because the status code space is limited, they do require working group or working group chair review, and 6273 must be documented in an RFC or Internet draft. The same procedures apply to new method names. 6274 The following information needs to be provided to IANA in order to register a new response code or 6275 method:

6276 • The name and email address of the individual performing the registration;

6277 • the number of the response code or name of the method being registered;

6278 • the default reason phrase for that status code, if applicable;

6279 • the name of the draft or RFC where the method or status code is defined;

6280 • a copy of the draft or RFC where the method or status code is defined.

6281 27.5 The “application/sip” MIME type.

6282 This document registers the “application/sip” MIME media type in order to allow SIP messages to be tun-6283 neled as bodies within SIP, primarily for end-to-end security purposes. This media type is defined by the 6284 following information: 6285 Media type name: application Media subtype name: sip Required parameters: none Optional parame-6286 ters: version

6287 • version: The SIP-Version number of the enclosed message (e.g., ”2.0”). If not present, the version 6288 can be determined from the first line of the body.

6289 Encoding scheme: see below Security considerations: see below 6290 SIP specifies UTF-8 encoding. While most header field names and data elements will lie in the 7-bit 6291 ASCII compatible range, data elements and SIP bodies may contain 8-bit values. In order to preserve the 6292 readability of SIP messages being carried as the body of other messages, “application/sip” bodies (including 6293 any bodies they in turn contain) SHOULD be UTF-8 encoded. If transcoding a body to UTF-8 is not feasible, 6294 the “application/sip” part MAY be binary encoded. If the transport is not 8-bit clean, encoding formats such 6295 as base-64 can be used. 6296 Motivation and examples of this usage as a security mechanism in concert with S/MIME are given in 6297 23.4.

6298 28 Changes From RFC 2543

6299 This RFC revises RFC 2543. It is mostly backwards compatible with RFC 2543. The changes described 6300 here fix many errors discovered in RFC 2543 and provide information on scenarios not detailed in RFC 6301 2543. The protocol has been presented in a more cleanly layered model here. 6302 We break the differences into functional behavior that is a substantial change from RFC 2543, which has 6303 impact on interoperability or correct operation in some cases, and functional behavior that is different from 6304 RFC 2543 but not a potential source of interoperability problems. There have been countless clarifications 6305 as well, which are not documented here.

6306 28.1 Major Functional Changes

6307 • When a UAC wishes to terminate a call before it has been answered, it sends CANCEL. If the original 6308 INVITE still returns a 2xx, the UAC then sends BYE. BYE can only be sent on an existing call leg 6309 (now called a dialog in this RFC), whereas it could be sent at any time in RFC 2543.

6310 • The SIP BNF was converted to be RFC 2234 compliant.

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

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

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

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

6324 • In RFC 2543, UAs needed to support only UDP. In this RFC, UAs need to support both UDP and

6325 TCP.

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

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

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

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

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

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

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

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

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

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

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

6362 • Comments (expressed with rounded brackets) have been removed from the grammar of SIP.

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

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

6368 • Usage of absolute time in the Expires header field and parameter has been removed. It caused inter-6369 operability problems in elements that were not time synchronized, a common occurrence. Relative 6370 times are used instead.

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

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

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

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

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

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

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

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

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

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

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

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

6404 • Basic authentication has been removed entirely and its usage forbidden.

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

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

6412 28.2 Minor Functional Changes

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

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

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

6418 • Added the In-Reply-To and Reply-To header fields for supporting the return of missed calls or mes-6419 sages at a later time.

6420 • Added TLS and SCTP as valid SIP transports.

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

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

6426 TCP.

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

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

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

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

6437 29 Acknowledgments

6438 We wish to thank the members of the IETF MMUSIC and SIP WGs for their comments and suggestions. 6439 Detailed comments were provided by Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan, Keith 6440 Drage, Cédric Fluckiger, Yaron Goland, John Hearty, Bernie Höneisen, Jo Hornsby, Phil Hoffer, Christian 6441 Huitema, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders Kristensen, Jonathan Lennox, Gethin Liddell, 6442 Allison Mankin, William Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Moshe J. Sambol, Chip Sharp, 6443 Igor Slepchin, Eric Tremblay, and Rick Workman. 6444 Brian Rosen provided the compiled BNF. 6445 This work is based, inter alia, on [41, 42].

6446 30 Authors’ Addresses

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

6449 Jonathan Rosenberg 6450 dynamicsoft 6451 72 Eagle Rock Ave 6452 East Hanover, NJ 07936

6453 USA

6454 electronic mail: jdrosen@dynamicsoft.com

6455 Henning Schulzrinne 6456 Dept. of Computer Science 6457 Columbia University 6458 1214 Amsterdam Avenue 6459 New York, NY 10027

6460 USA

6461 electronic mail: schulzrinne@cs.columbia.edu

6462 Gonzalo Camarillo 6463 Ericsson 6464 Advanced Signalling Research Lab. 6465 FIN-02420 Jorvas 6466 Finland 6467 electronic mail: Gonzalo.Camarillo@ericsson.com

6468 Alan Johnston 6469 WorldCom 6470 100 South 4th Street 6471 St. Louis, MO 63102

6472 USA

6473 electronic mail: alan.johnston@wcom.com

6474 Jon Peterson 6475 NeuStar, Inc 6476 1800 Sutter Street, Suite 570 6477 Concord, CA 94520

6478 USA

6479 electronic mail: jon.peterson@neustar.com

6480 Robert Sparks 6481 dynamicsoft, Inc. 6482 5100 Tennyson Parkway 6483 Suite 1200 6484 Plano, Texas 75024

6485 USA

6486 electronic mail: rsparks@dynamicsoft.com

6487 Mark Handley 6488 ACIRI 6489 electronic mail: mjh@aciri.org 6490 Eve Schooler 6491 Computer Science Department 256-80 6492 California Institute of Technology 6493 Pasadena, CA 91125

6494 USA

6495 electronic mail: schooler@cs.caltech.edu

6496 Normative References

6497 [1] M. Handley and V. Jacobson, “SDP: session description protocol,” Request for Comments 2327, Inter-6498 net Engineering Task Force, Apr. 1998.

6499 [2] S. Bradner, “Key words for use in RFCs to indicate requirement levels,” Request for Comments 2119, 6500 Internet Engineering Task Force, Mar. 1997.

6501 [3] P. Resnick and Ed, “Internet message format,” Request for Comments 2822, Internet Engineering Task 6502 Force, Apr. 2001.

6503 [4] H. Schulzrinne and J. Rosenberg, “SIP: Locating SIP servers,” Internet Draft, Internet Engineering 6504 Task Force, Jan. 2002. Work in progress.

6505 [5] T. Berners-Lee, R. Fielding, and L. Masinter, “Uniform resource identifiers (URI): generic syntax,” 6506 Request for Comments 2396, Internet Engineering Task Force, Aug. 1998.

6507 [6] T. Berners-Lee, L. Masinter, and M. McCahill, “Uniform resource locators (URL),” Request for Com-6508 ments 1738, Internet Engineering Task Force, Dec. 1994.

6509 [7] F. Yergeau, “UTF-8, a transformation format of ISO 10646,” Request for Comments 2279, Internet 6510 Engineering Task Force, Jan. 1998.

6511 [8] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, “Hypertext 6512 transfer protocol – HTTP/1.1,” Request for Comments 2616, Internet Engineering Task Force, June 6513 1999.

6514 [9] A. Vaha-Sipila, “URLs for telephone calls,” Request for Comments 2806, Internet Engineering Task 6515 Force, Apr. 2000.

6516 [10] D. Crocker, Ed., and P. Overell, “Augmented BNF for syntax specifications: ABNF,” Request for 6517 Comments 2234, Internet Engineering Task Force, Nov. 1997.

6518 [11] N. Freed and N. Borenstein, “Multipurpose internet mail extensions (MIME) part two: Media types,” 6519 Request for Comments 2046, Internet Engineering Task Force, Nov. 1996.

6520 [12] D. Eastlake, S. Crocker, and J. Schiller, “Randomness recommendations for security,” Request for 6521 Comments 1750, Internet Engineering Task Force, Dec. 1994.

6522 [13] J. Rosenberg and H. Schulzrinne, “An offer/answer model with SDP,” Internet Draft, Internet Engi-6523 neering Task Force, Jan. 2002. Work in progress.

6524 [14] J. Postel, “User datagram protocol,” Request for Comments 768, Internet Engineering Task Force, 6525 Aug. 1980.

6526 [15] J. Postel, “DoD standard transmission control protocol,” Request for Comments 761, Internet Engi-6527 neering Task Force, Jan. 1980.

6528 [16] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, 6529 and V. Paxson, “Stream control transmission protocol,” Request for Comments 2960, Internet Engi-6530 neering Task Force, Oct. 2000.

6531 [17] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, and L. Stewart, “HTTP 6532 authentication: Basic and digest access authentication,” Request for Comments 2617, Internet Engi-6533 neering Task Force, June 1999.

6534 [18] R. Troost, S. Dorner, K. Moore, and Ed, “Communicating presentation information in internet mes-6535 sages: The content-disposition header field,” Request for Comments 2183, Internet Engineering Task 6536 Force, Aug. 1997.

6537 [19] R. Braden and Ed, “Requirements for internet hosts - application and support,” Request for Comments 6538 1123, Internet Engineering Task Force, Oct. 1989.

6539 [20] H. Alvestrand, “IETF policy on character sets and languages,” Request for Comments 2277, Internet 6540 Engineering Task Force, Jan. 1998.

6541 [21] J. Galvin, S. Murphy, S. Crocker, and N. Freed, “Security multiparts for MIME: multipart/signed and 6542 multipart/encrypted,” Request for Comments 1847, Internet Engineering Task Force, Oct. 1995.

6543 [22] R. Housley, “Cryptographic message syntax,” Request for Comments 2630, Internet Engineering Task 6544 Force, June 1999.

6545 [23] B. Ramsdell and Ed, “S/MIME version 3 message specification,” Request for Comments 2633, Internet 6546 Engineering Task Force, June 1999.

6547 [24] T. Dierks and C. Allen, “The TLS protocol version 1.0,” Request for Comments 2246, Internet Engi-6548 neering Task Force, Jan. 1999.

6549 [25] S. Kent and R. Atkinson, “Security architecture for the internet protocol,” Request for Comments 2401, 6550 Internet Engineering Task Force, Nov. 1998.

6551 Non-Normative References

6552 [26] R. Pandya, “Emerging mobile and personal communication systems,” IEEE Communications Maga-6553 zine, vol. 33, pp. 44–52, June 1995.

6554 [27] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: a transport protocol for real-time 6555 applications,” Request for Comments 1889, Internet Engineering Task Force, Jan. 1996.

6556 [28] H. Schulzrinne, A. Rao, and R. Lanphier, “Real time streaming protocol (RTSP),” Request for Com-6557 ments 2326, Internet Engineering Task Force, Apr. 1998.

6558 [29] F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, and J. Segers, “Megaco protocol version 6559 1.0,” Request for Comments 3015, Internet Engineering Task Force, Nov. 2000.

6560 [30] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, “SIP: session initiation protocol,” Request 6561 for Comments 2543, Internet Engineering Task Force, Mar. 1999.

6562 [31] P. Hoffman, L. Masinter, and J. Zawinski, “The mailto URL scheme,” Request for Comments 2368, 6563 Internet Engineering Task Force, July 1998.

6564 [32] E. M. Schooler, “A multicast user directory service for synchronous rendezvous,” Master’s Thesis CS-6565 TR-96-18, Department of Computer Science, California Institute of Technology, Pasadena, California, 6566 Aug. 1996.

6567 [33] S. Donovan, “The SIP INFO method,” Request for Comments 2976, Internet Engineering Task Force, 6568 Oct. 2000.

6569 [34] R. Rivest, “The MD5 message-digest algorithm,” Request for Comments 1321, Internet Engineering 6570 Task Force, Apr. 1992.

6571 [35] F. Dawson and T. Howes, “vcard MIME directory profile,” Request for Comments 2426, Internet 6572 Engineering Task Force, Sept. 1998.

6573 [36] G. Good, “The LDAP data interchange format (LDIF) - technical specification,” Request for Com-6574 ments 2849, Internet Engineering Task Force, June 2000.

6575 [37] J. Palme, “Common internet message headers,” Request for Comments 2076, Internet Engineering 6576 Task Force, Feb. 1997.

6577 [38] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, and L. Stewart, “An exten-6578 sion to HTTP : Digest access authentication,” Request for Comments 2069, Internet Engineering Task 6579 Force, Jan. 1997.

6580 [39] A. Johnston, S. Donovan, R. Sparks, C. Cunningham, D. Willis, J. Rosenberg, K. Summers, and 6581 H. Schulzrinne, “SIP telephony call flow examples,” Internet Draft, Internet Engineering Task Force, 6582 Apr. 2001. Work in progress.

6583 [40] H. Schulzrinne, “RTP profile for audio and video conferences with minimal control,” Request for 6584 Comments 1890, Internet Engineering Task Force, Jan. 1996.

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

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

6590 A Table of Timer Values

6591 Table 4 sumarizes 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 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

6592 Full Copyright Statement

6593 Copyright (c) The Internet Society (2002). All Rights Reserved. 6594 This document and translations of it may be copied and furnished to others, and derivative works that 6595 comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and 6596 distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and 6597 this paragraph are included on all such copies and derivative works. However, this document itself may not 6598 be modified in any way, such as by removing the copyright notice or references to the Internet Society or 6599 other Internet organizations, except as needed for the purpose of developing Internet standards in which case 6600 the procedures for copyrights defined in the Internet Standards process must be followed, or as required to 6601 translate it into languages other than English. 6602 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or 6603 its successors or assigns. 6604 This document and the information contained herein is provided on an ”AS IS” basis and THE IN-6605 TERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WAR-6606 RANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 6607 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 6608 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.