sip: session initiation protocol - softarmor systems llc

Internet Engineering Task Force SIP WGINTERNET-DRAFT Rosenberg,Schulzrinne,Camarillo,Johnston,Peterson,Sparks,Handley,Schoolerdraft-ietf-sip-rfc2543bis-05.ps Various places

October 26, 2001Expires: April 20021

SIP: Session Initiation Protocol2

Status of this Memo3

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.4

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its5

working groups. Note that other groups may also distribute working documents as Internet-Drafts.6

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced,7

or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material8

or to cite them other than as “work in progress.”9

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt10

To view the list Internet-Draft Shadow Directories, seehttp://www.ietf.org/shadow.html.11

Copyright Notice12

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

Abstract14

The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creat-15

ing, modifying and terminating sessions with one or more participants. These sessions include Internet16

telephone calls, multimedia distribution and multimedia conferences.17

SIP invitations used to create sessions carry session descriptions which allow participants to agree on18

a set of compatible media types. SIP makes use of elements called proxy servers to help route requests19

to the users current location, assist in firewall traversal, and provide features to users. SIP also provides a20

registration function that allows them to upload their current location for use by proxy servers. SIP runs21

ontop of several different transport protocols.22

Contents23

1 Introduction 724

2 Overview of SIP Functionality 725

3 Terminology 826

4 Overview of Operation 827

5 Structure of the Protocol 1328

6 Definitions 1529

7 SIP Messages 1830

7.1 Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1831

7.2 Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1932

7.3 Header Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2033

INTERNET-DRAFT draft-ietf-sip-rfc2543bis-05.ps October 26, 2001

7.3.1 Header Field Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2034

7.3.2 Header Field Classification . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2235

7.3.3 Compact Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2236

7.4 Bodies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2237

7.4.1 Message Body Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2238

7.4.2 Message Body Length. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2239

7.5 Framing SIP messages . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2340

8 General User Agent Behavior 2341

8.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2342

8.1.1 Generating the Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2343

8.1.2 Sending the Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2644

8.1.3 Processing Responses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2645

8.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2746

8.2.1 Authentication/Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2747

8.2.2 Method Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2748

8.2.3 Header Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2849

8.2.4 Content Processing .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2950

8.2.5 Applying Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2951

8.2.6 Processing the Request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2952

8.2.7 Generating the Response. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2953

8.3 Redirect Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3054

9 Canceling a Request 3155

9.1 Client Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3156

9.2 Server Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3257

10 Registrations 3258

10.1 Overview of Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3259

10.2 Construction of the REGISTER request. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3460

10.2.1 Adding Bindings withREGISTER . . . . . . . . . . . . . . . . . . . . . . . . . . 3461

10.2.2 Removing Bindings withREGISTER . . . . . . . . . . . . . . . . . . . . . . . . . 3562

10.2.3 Fetching Bindings withREGISTER . . . . . . . . . . . . . . . . . . . . . . . . . 3663

10.2.4 Refreshing Registrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3664

10.2.5 Discovering a Registrar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3665

10.3 Processing of REGISTER at the Registrar. . . . . . . . . . . . . . . . . . . . . . . . . . . 3666

11 Querying for Capabilities 3867

11.1 Construction of OPTIONS Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3868

11.2 Processing of OPTIONS Request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3969

12 Dialogs 4070

12.1 Creation of a Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4171

12.2 Requests within a Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4272

12.2.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4273

12.2.2 UAS behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4474

Rosenberg,Schulzrinne,Camarillo,Johnston,Peterson,Sparks,Handley,Schooler Expires April 2002 []


12.3 Termination of a Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4475

13 Initiating a Session 4476

13.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4477

13.2 Caller Processing .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4578

13.2.1 Creating the InitialINVITE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4579

13.2.2 ProcessingINVITE Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4680

13.3 Callee Processing .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4781

13.3.1 Processing of the INVITE . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4782

14 Modifying an Existing Session 4983

14.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5084

14.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5085

15 Terminating a Session 5186

15.1 Terminating a Dialog with a BYE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5187

15.1.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5188

15.1.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5289

16 Proxy Behavior 5290

16.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5291

16.2 Stateful Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5392

16.3 Request Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5493

16.4 Making a Routing Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5594

16.5 Request Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5795

16.6 Response Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6096

16.7 Handling transport errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6497

16.8 CANCEL Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6498

16.9 Stateless proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6499

17 Transactions 65100

17.1 Client transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67101

17.1.1 INVITE Client Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67102

17.1.2 non-INVITE Client Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70103

17.1.3 Matching Responses to Client Transactions . . . . . . . . . . . . . . . . . . . . . . 72104

17.1.4 Handling Transport Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72105

17.2 Server Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73106

17.2.1 INVITE Server Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73107

17.2.2 non-INVITE Server Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75108

17.2.3 Matching Requests to Server Transactions . . . . . . . . . . . . . . . . . . . . . . . 75109

17.3 RTT Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76110

18 Reliability of Provisional Responses 77111

19 Transport 77112

19.1 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77113



19.1.1 Sending Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77114

19.1.2 Receiving Responses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78115

19.2 Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79116

19.2.1 Receiving Requests .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79117

19.2.2 Sending Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79118

19.3 Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80119

19.4 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80120

20 Security Considerations 80121

20.1 Transport and Network Layer Security .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 81122

20.2 SIP Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82123

20.2.1 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82124

20.2.2 User to User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83125

20.2.3 Proxy to User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83126

20.2.4 Authentication Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84127

20.3 SIP Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85128

20.4 Denial of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86129

21 Common Message Components 87130

21.1 SIP Uniform Resource Locators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87131

21.1.1 SIP URL components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87132

21.1.2 Character escaping requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . 89133

21.1.3 Example SIP URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90134

21.1.4 SIP URL Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90135

21.2 Option Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92136

21.3 Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92137

22 Header Fields 92138

22.1 Accept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95139

22.2 Accept-Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95140

22.3 Accept-Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96141

22.4 Alert-Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96142

22.5 Allow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96143

22.6 Authentication-Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96144

22.7 Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97145

22.8 Call-ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97146

22.9 Call-Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97147

22.10Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98148

22.11Content-Disposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98149

22.12Content-Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98150

22.13Content-Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99151

22.14Content-Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99152

22.15Content-Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99153

22.16CSeq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100154

22.17Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100155



22.18Error-Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100156

22.19Expires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101157

22.20From . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101158

22.21In-Reply-To . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101159

22.22Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101160

22.23MIME-Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102161

22.24Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102162

22.25Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102163

22.26Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102164

22.27Proxy-Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103165

22.28Proxy-Require . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103166

22.29Record-Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103167

22.30Require . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103168

22.31Retry-After . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104169

22.32Route . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104170

22.33Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104171

22.34Subject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104172

22.35Supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105173

22.36Timestamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105174

22.37To . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105175

22.38Unsupported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105176

22.39User-Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106177

22.40Via . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106178

22.41Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106179

22.42WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107180

23 Response Codes 108181

23.1 Provisional 1xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108182

23.1.1 100 Trying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108183

23.1.2 180 Ringing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108184

23.1.3 181 Call Is Being Forwarded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108185

23.1.4 182 Queued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108186

23.1.5 183 Session Progress. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109187

23.2 Successful 2xx . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109188

23.2.1 200 OK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109189

23.3 Redirection 3xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109190

23.3.1 300 Multiple Choices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109191

23.3.2 301 Moved Permanently . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109192

23.3.3 302 Moved Temporarily. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109193

23.3.4 305 Use Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110194

23.3.5 380 Alternative Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110195

23.4 Request Failure 4xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110196

23.4.1 400 Bad Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110197

23.4.2 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110198

23.4.3 402 Payment Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110199



23.4.4 403 Forbidden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110200

23.4.5 404 Not Found . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110201

23.4.6 405 Method Not Allowed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111202

23.4.7 406 Not Acceptable .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111203

23.4.8 407 Proxy Authentication Required . . . . . . . . . . . . . . . . . . . . . . . . . . 111204

23.4.9 408 Request Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111205

23.4.10 410 Gone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111206

23.4.11 413 Request Entity Too Large .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 111207

23.4.12 414 Request-URI Too Long . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111208

23.4.13 415 Unsupported Media Type .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 111209

23.4.14 420 Bad Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112210

23.4.15 421 Extension Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112211

23.4.16 480 Temporarily Unavailable . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 112212

23.4.17 481 Call/Transaction Does Not Exist . . .. . . . . . . . . . . . . . . . . . . . . . . 112213

23.4.18 482 Loop Detected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112214

23.4.19 483 Too Many Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112215

23.4.20 484 Address Incomplete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112216

23.4.21 485 Ambiguous . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113217

23.4.22 486 Busy Here . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113218

23.4.23 487 Request Terminated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113219

23.4.24 488 Not Acceptable Here. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113220

23.5 Server Failure 5xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113221

23.5.1 500 Server Internal Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113222

23.5.2 501 Not Implemented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114223

23.5.3 502 Bad Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114224

23.5.4 503 Service Unavailable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114225

23.5.5 504 Server Time-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114226

23.5.6 505 Version Not Supported . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 114227

23.5.7 513 Message Too Large. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114228

23.6 Global Failures 6xx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114229

23.6.1 600 Busy Everywhere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115230

23.6.2 603 Decline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115231

23.6.3 604 Does Not Exist Anywhere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115232

23.6.4 606 Not Acceptable .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115233

24 Locating a SIP Server 115234

24.1 Computing the List of Next Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116235

24.1.1 Numeric Destination Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116236

24.1.2 SRV Resolution of Host Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116237

24.1.3 Address Record Resolution of Host Name . . . . . . . . . . . . . . . . . . . . . . . 117238

24.2 Contacting the Next Hops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117239

25 Examples 118240

25.1 Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118241

25.2 Session Setup . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119242



26 Augmented BNF for the SIP Protocol 124243

26.1 Basic Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125244

27 IANA Considerations 138245

27.1 Option Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138246

27.2 Warn-Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138247

27.3 Header Field Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139248

27.4 Method and Response Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139249

28 Changes Made in Version 00 139250






34 Acknowledgments 153256

35 Authors’ Addresses 153257

1 Introduction258

There are many applications of the Internet that require the creation and management of a session, where259

a session is considered an exchange of data between an association of participants. The implementation260

of these services is complicated by the practices of participants; users may move between endpoints, they261

may be addressable by multiple names, and they may communicate in several different media - sometimes262

simultaneously. Numerous protocols have been authored that carry various forms of real-time multimedia263

session data such as voice, video, or text messages. SIP works in concert with these protocols by enabling264

Internet endpoints (called “user agents”) to discover one another and to agree on a characterization of a265

session they would like to share. For locating prospective session participants, SIP relies on an infrastructure266

of network hosts (called “proxy servers”) to which user agents can send registrations, invitations to sessions267

and other requests. SIP is an agile, general-purpose tool for creating, modifying and terminating sessions268

that works independently of underlying transport protocols and without dependency on the type of session269

that is being established.270

2 Overview of SIP Functionality271

The Session Initiation Protocol (SIP) is an application-layer control protocol that can establish, modify and272

terminate multimedia sessions (conferences) such as Internet telephony calls. SIP can also invite participants273

to already existing sessions. A SIP entity issuing an invitation for an already existing session does not274

necessarily have to be a member of the session to which it is inviting. Media can be added to (and removed275



from) an existing session. SIP transparently supports name mapping and redirection services, which supports276

personal mobility[1, p. 44] - users can maintain a single externally visible identifier (SIP URI) regardless277

of their network location.278

SIP supports five facets of establishing and terminating multimedia communications:279

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

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

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

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

Session handling: including transfer and termination of sessions, modifying session parameters, and in-284

voking services.285

SIP is not a vertically integrated communications system. SIP is rather a component of the overall IETF286

multimedia data and control architecture which incorporates protocols such as RSVP (RFC 2205 [2]) for re-287

serving network resources, the real-time transport protocol (RTP) (RFC 1889 [3]) for transporting real-time288

data and providing QOS feedback, the real-time streaming protocol (RTSP) (RFC 2326 [4]) for controlling289

delivery of streaming media, the session announcement protocol (SAP) [5] for advertising multimedia ses-290

sions via multicast and the session description protocol (SDP) (RFC 2327 [6]) for describing multimedia291

sessions. Therefore, SIP should be used in conjunction with other protocols in order to provide complete292

services to the users. However, the basic functionality and operation of SIP does not depend on any of these293

protocols.294

SIP does not provide services. SIP rather provides primitives that can be used to implement different295

services. For example, SIP can locate a user and deliver an opaque object to his current location. If this296

primitive is used to deliver a session description written in SDP, for instance, the parameters of a session297

can be agreed between endpoints. If the same primitive is used to deliver a photo of the caller as well as298

the session description, a ”caller ID” service can be easily implemented. As this example shows, a single299

primitive is typically used to provide several different services. Consequently, generality is more important300

than efficiency when designing SIP primitives.301

SIP does not offer conference control services such as floor control or voting and does not prescribe how302

a conference is to be managed, but SIP can be used to initiate a session that uses some other conference303

control protocol. SIP does not allocate multicast addresses and does not reserve network resources.304

3 Terminology305

In this document, the key words “MUST”, “ MUST NOT”, “ REQUIRED”, “ SHALL”, “ SHALL NOT”, “ SHOULD”,306

“ SHOULD NOT”, “ RECOMMENDED”, “ MAY ”, and “OPTIONAL” are to be interpreted as described in RFC307

2119 [7] and indicate requirement levels for compliant SIP implementations.308

4 Overview of Operation309

This section will introduce the basic operations of the SIP protocol using simple examples. Note that this310

section is tutorial in nature and does not contain any normative statements.311



The first example will show the basic functions of SIP: location of an end point, signaling a desire to312

communicate, negotiation of session parameters to establish the session, and teardown of the session once313

established.314

Figure 1 shows a typical example of a SIP message exchange between two users, Alice and Bob. (Each315

message is labeled with the letter “F” and a number for reference by the text.) In this example, Alice uses a316

SIP application on her PC (referred to as a softphone) to call Bob on his SIP phone over the Internet. Also317

shown are two SIP proxy servers which act on behalf of Alice and Bob to facilitate the session establishment.318

This typical arrangement is often referred to as the “SIP trapezoid” as shown by the geometric shape of the319

dashed lines in Figure 1.320

��

��

��

��

��

��

��

��

��

!"�!�"!��

�#� $�� #� $��

�#� $��

%�� &� ��

%�� &� ��%�� &� ��

$� '�(�! ��

%�� &� ��

Figure 1: SIP session setup example with SIP trapezoid

Alice “calls” Bob using his SIP identity, a type of Uniform Resource Identifier (URI) called a SIP URI321

and defined in Section 21.1. It has a similar form to an email address, typically containing a username and322

a host name. In this case it is sip:[email protected], where biloxi.com is the domain of Bob’s SIP service323

provider (which can be an enterprise, retail provider, etc). Alice also has a SIP URI of sip:[email protected]

Alice might have typed in Bob’s URI or perhaps clicked on a hyperlink or an entry in an address book.325

SIP is based on an HTTP-like request/response transacton model. Each transaction consists of a request326

that invokes a particular “Method”, or function, on the server, and at least one response. In this example, the327

transaction begins with Alice’s softphone sending anINVITE request addressed to Bob’s SIP URI.INVITE328

is an example of a SIP method which specifies the action that the requestor (Alice) wants the server (Bob) to329



take. TheINVITE request contains a number of header fields. Header fields are additional named attributes330

which provide additional information about a message. The ones present in anINVITE include a unique331

identifier for the call, the destination address, Alice’s address, and information about the type of session that332

Alice wishes to establish with Bob. TheINVITE (message F1 in Figure 1) might look like this:333

INVITE sip:[email protected] SIP/2.0334

Via: SIP/2.0/UDP 10.1.3.3:5060335

To: Bob <sip:[email protected]>336

From: Alice <sip:[email protected]>;tag=1928301774337

Call-ID: [email protected]

CSeq: 314159 INVITE339

Contact: <sip:[email protected]>340

Content-Type: application/sdp341

Contact-Length: 142342

343

(Alice’s SDP not shown)344

The first line of the text-encoded message contains the method name (INVITE). The lines which follow345

are a list of header fields. This example contains a minimum required set. The headers are briefly described346

below:347

Via contains the IP address (10.1.3.3), port number (5060), and transport protocol (UDP) on which Alice348

is expecting to receive responses to this request.349

To contains a display name (Bob) and a SIP URI (sip:[email protected]) that the request was originally350

directed towards.351

From also contains a display name (Alice) and a SIP URI (sip:[email protected]) that indicate the352

originator of the request. This header field also has atag parameter which contains a pseudorandom string353

(1928301774) which was added to the URI by the softphone. It is used for identification purposes.354

Call-ID contains a globally unique identifier for this call, generated by the combination of a pseudoran-355

dom string and the softphone’s IP address. The combination of theTo, From, andCall-ID completely define356

a peer-to-peer SIP relationship betwee Alice and Bob, and is referred to as a “dialog”.357

CSeq or Command Sequence contains an integer and a method name. TheCSeq number is incremented358

for each new request, and is a traditional sequence number.359

Contact contains a SIP URI which represents a direct route to reach or contact Alice, usually composed360

of a username at an IP address. While theVia header field is used to tell other elements where to send the361

response, theContact header field tells other elements where to send future requests for this dialog.362

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

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

The complete set of SIP header fields is defined in Section 22.365

The details of the session, type of media, codec, sampling rate, etc. are not described using SIP. Rather,366

the body of a SIP message contains a description of the session, encoded in some other protocol format. One367

such format is Session Description Protocol (SDP) [6]. This SDP message (not shown in the example) is368

carried by the SIP message in an analogous way that a document attachment is carried by an email message,369

or a web page is carried in an HTTP message.370

Since the softphone has no knowledge of Bob’s exact location, or how to locate the SIP server in371

the biloxi.com domain, the softphone sends theINVITE to the SIP server that serves Alice’s domain, at-372

Rosenberg,Schulzrinne,Camarillo,Johnston,Peterson,Sparks,Handley,SchoolerExpires April 2002[]


lanta.com. The IP address of the atlanta.com SIP server could have been configured in Alice’s softphone, or373

it could have been discovered by DHCP, for example.374

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

SIP requests and forwards them on behalf of the requestor. In this example, the proxy server receives the376

INVITE request and generates a 100 Trying response which is sent back to Alice’s softphone. The 100377

Trying response indicates that theINVITE has been received and that the proxy is working on her behalf to378

try to route theINVITE to the destination. Responses in SIP use a numerical three digit code followed by379

a descriptive phrase. This response contains the sameTo, From, Call-ID, andCSeq as theINVITE, which380

allows Alice’s softphone to correlate this response to the sentINVITE. The atlanta.com proxy server locates381

the proxy server at biloxi.com, possibly by performing a DNS (Domain Name Service) lookup to find the382

SIP server which serves the biloxi.com domain. This is described in Section 24. As a result, it obtains383

the IP address of the biloxi.com proxy server and forwards, or proxies, theINVITE request there. Before384

forwarding the request, the atlanta.com proxy server adds an additionalVia header field which contains385

its own IP address (theINVITE already contains Alice’s IP address in the firstVia). The biloxi.com proxy386

server receives theINVITE and responds with a 100 Trying response back to the Atlanta.com proxy server to387

indicate that it has received theINVITE and is processing the request. The proxy server consults a database,388

generically called a location service, which contains the current IP address of Bob. (We shall see in the next389

section how this database can be populated.) The biloxi.com proxy server adds anotherVia header with its390

own IP address to theINVITE and proxies it to Bob’s SIP phone.391

Bob’s SIP phone receives theINVITE and begins to alert Bob to the incoming call from Alice so that392

Bob can decide whether or not to answer the call - i.e. Bob’s phone rings. Bob’s SIP phone sends an393

indication of this in a 180 Ringing response. This response is routed back thorough the two proxies in the394

reverse direction. Each proxy uses theVia header to figure out where to send the response, and removes its395

own address from the top. As a result, although DNS and location service lookups were required to route396

the initial INVITE, the 180 Ringing response can be returned to the caller without lookups, or without state397

being maintained in the proxies. This also has the desirable property that each proxy that sees theINVITE398

will also see all responses to theINVITE.399

When Alice’s softphone receives the 180 Ringing response, it passes this information to Alice, perhaps400

using an audio ringback tone, or just by displaying or flashing a message on Alice’s screen.401

In this example, Bob decides to answer the call. When he picks up the handset his SIP phone sends a 200402

OK response to indicate that the call has been answered. The 200 OK contains a message body containing403

the SDP media description of the type of session that Bob is willing to establish with Alice. As a result, there404

is a two-phase exchange of SDP messages; Alice sent one to Bob, and Bob sent one back to Alice. This405

two-phase exchange provides basic negotiation capabilities, and is based on a simple offer/answer model, If406

Bob did not wish to answer the call, or was busy on another call, an error response would have been sent407

instead of the 200 OK, which would have resulted in no media session being established. The complete list408

of SIP response codes is in Section 23. The 200 OK (message F9 in Figure 1) might look like this:409

SIP/2.0 200 OK410

Via: SIP/2.0/UDP 10.2.1.1:5060;branch=4b43c2ff8.1411

Via: SIP/2.0/UDP 10.1.1.1:5060;branch=77ef4c2312983.1412

Via: SIP/2.0/UDP 10.1.3.3:5060413

To: Bob <sip:[email protected]>;tag=a6c85cf414









421

(Bob’s SDP not shown)422

The first line of the response contains the response code (200) and the reason phrase (OK). The remain-423

ing lines contain header fields. TheVia header fields,To, From, Call- ID, andCSeq are all copied from424

the INVITE request. (Note that there are threeVia headers - one added by Alice’s SIP phone, one added by425

the atlanta.com proxy, and one added by the biloxi.com proxy.) Also note that Bob’s SIP phone has added a426

tag parameter to theTo header field. This tag will be incorporated by both User Agents into the dialog and427

will be included in all future requests and responses in this call. TheContact header field contains a URI at428

which Bob can be directly reached at his SIP phone. TheContent-Type andContent-Length refer to the429

not shown message body which contains Bob’s SDP media information.430

In additon to DNS and location service lookups shown in this example, proxy servers can make arbi-431

trarily complex “routing decisions” in order to decide where to send a request. For example, if Bob’s SIP432

phone returned a 486 Busy Here response, the biloxi.com proxy server could proxy theINVITE to Bob’s433

voicemail server. A proxy server can also send anINVITE to a number of locations at the same time. This434

type of parallel search is known as “forking”.435

In this case, the 200 OK is routed back through the two proxies and is received by Alice’s softphone436

which then stops the ringback tone and indicates that the call has been answered. Finally, an acknowledge-437

ment message,ACK, is sent by Alice to Bob to confirm the reception of the final response (200 OK). Note438

that in this example, theACK is sent directly from Alice to Bob, bypassing the two proxies. This is due to439

the fact that through theINVITE/200 OK exchange, the two SIP user agents have learned each other’s IP440

address through theContact header fields, something which was not known when the initialINVITE was441

sent. The lookups performed by the two proxies are no longer needed, so they drop put of the call flow. This442

completes theINVITE/200/ACK three way handshake used to establish SIP sessions, and is the end of the443

transaction. Full details on session setup is in Section 13.444

Alice and Bob’s media session has now begun, and they begin sending media packets using the format445

agreed to in the exchange of SDP. In general, the end-to-end media packets will take a different path from446

the SIP signaling messages.447

During the session, either Alice or Bob may decide to change the characteristics of the media session.448

This is accomplished by sending a re-INVITE containing a new media description. If the change is accept-449

able to the other party, a 200 OK is sent which is itself responded to with anACK. This re-INVITE will450

reference the existing dialog so the other party knows that it is to modify an existing session instead of451

establishing a new session. If the change is not acceptable, an error response, such as a 406 Not Acceptable452

response is sent, which also receives anACK. However, the failure of the re-INVITE does not cause the453

existing call to fail - the session continues using the previously negotiated characteristics. Full details on454

session modification is in Section 14.455

At the end of the call, Bob disconnects (hangs up) first, and generates aBYE message. ThisBYE is456

routed directly to Alice’s softphone, again bypassing the proxies. Alice confirms receipt of theBYE with457

a 200 OK response, which terminates the session and theBYE transaction. Note that noACK is sent - an458

ACK is only sent in response to a response to anINVITE request. The reasons for this special handling for459

INVITE will be discussed later, but relate to the reliability mechanisms in SIP, the length of time it can take460



for a ringing phone to be answered, and forking. For this reason, request handling in SIP is often classified461

as eitherINVITE or non- INVITE, referring to all other methods besidesINVITE. Full details on session462

termination is in Section 15.463

Full details of all the messages shown in the example of Figure 1 are shown in Section 25.2.464

In some cases, it may be useful for proxies in the SIP signaling path see all the messaging between465

the two endpoints for the duration of the session. For example, if the biloxi.com proxy server wished to466

remain in the SIP messaging path beyond the initialINVITE, it would add to theINVITE a required routing467

header field known asRecord-Route containing a URI which resolves to the proxy. This information468

would be received by both Bob’s SIP phone and (due to theRecord-Route header field being passed back469

in the 200 OK) Alice’s softphone and stored for the duration of the dialog. This would then result in the470

ACK, BYE, and 200 OK to theBYE being received and proxied by the biloxi.com proxy server. Each471

proxy can independently decide to receive subsequent messaging, and that messaging will go through all472

proxies that elected to receive it. A common use of this capability is in firewall traversal or mid-call feature473

implementation.474

Registration is another common operation in SIP. Registration is one way in which the biloxi.com server475

can learn the current location of Bob. Upon initialization, and at periodic intervals, Bob’s SIP phone sends476

REGISTER messages a server in the biloxi.com domain known as a SIP registrar. TheREGISTER mes-477

sages associate Bob’s SIP URL (sip:[email protected]) with the machine he is currently logged in at (con-478

veyed as a SIP URL in theContact header). The registrar writes this association, also called a binding, to479

a database, called thelocation service, where it can be used by the proxy in the biloxi.com domain. Often,480

a registrar server for a domain is co-located with the proxy for that domain. It is an important concept that481

the distinction between types of SIP servers are logical, not physical.482

Bob is not limited to registering from a single device. For example, both his SIP phone at home and483

the one in the office could send in registrations. This information is stored together in the location service,484

and allows a proxy to perform various types of searches to locate Bob. Similarly, more than one user can be485

registered on a single device at the same time.486

The location service is just an abstract concept. It generally contains information that allows a proxy487

to input a URI and get back a translated URI that tells the proxy where to send the request. Registrations488

are one way to create this information, but not the only way. Arbitrarily complex mapping functions can be489

programmed, at the discretion of the administrator.490

Finally, it is important to note that in SIP, registration is used for routing incoming SIP requests and has491

no role in authorizing outgoing requests. Authorization and authentication are handled in SIP either on a492

request by request, challenge/response mechanism, or using a lower layer scheme as discussed in Section 20.493

The complete set of SIP message details for this registration example is in Section 25.2.494

Additional operations in SIP include querying for the capabilities of a SIP server or client usingOP-495

TIONS, and canceling a pending request usingCANCEL will be introduced in later sections.496

5 Structure of the Protocol497

The SIP protocol is structured as a layered protocol, which means that its behavior is described in terms of a498

set of fairly independent processing stages, with only a loose coupling between each stage. The structuring499

of the protocols into layers is for the purpose of presentation and conciseness; it allows the grouping of500

functions common across elements into a single place. It does not dictate an implementation in any way.501

When we say that an element “contains” a layer, that means it is compliant to the set of rules defined by that502

layer.503



Not every element specified by the protocol contains every layer. Furthermore, the elements specified504

by SIP are logical elements, not physical ones. A physical realization can choose to act as different logical505

elements, perhaps even on a transaction by transaction basis.506

The lowest layer of the SIP protocol is its syntax and encoding. Its encoding is specified using a BNF.507

The complete BNF is specified in Section 26. However, a basic overview of the structure of a SIP message508

can be found in Section 7. This section introduces enough of an understanding of the format of a SIP509

message to facilitate understanding the remainder of the protocol.510

The next higher layer is the transport layer. This layer defines how a client takes a request, and physically511

sends it over the network, and how a response is sent by a server, and then received by a client. All SIP512

elements contain a transport layer. The transport layer is described in Section 19.513

The next higher layer is the transaction layer. Transactions are a fundamental component of SIP. A514

transaction is a request, sent by a client transaction (using the transport layer), to a server transaction, along515

with all responses to that request sent from the server transaction back to the client. The transaction layer516

handles retransmissions, matching of responses to requests, and timeouts. Any task that a UAC wishes to517

accomplish takes place using a series of transactions. Discussion of transactions can be found in Section 17.518

User agents contain a transaction layer, as do stateful proxies. Stateless proxies do not contain a transaction519

layer.520

The transaction layer has a client component (referred to as a client transaction), and a server component521

(referred to as a server transaction), each of which are represented by an FSM that is constructed to process522

a particular request. The layer on top of the transaction layer is called the transaction user (TU), of which523

there are several types. When a TU wishes to send a request, it creates a client transaction instance and524

passes it the request, along with the destination IP address, port, and transport to send the request to.525

SIP provides the ability for a transaction to be canceled by the client which initiated it. When a client526

cancels a transaction, it requests that the server give up on further processing, revert to the state that ex-527

isted before the transaction was initiated, and generate a specific error response to that transaction. This is528

done with aCANCEL request, which constitutes its own transaction, but references the transaction to be529

cancelled. Cancellation is described in Section 9.530

There are several different types of transaction users. A UAC contains a UAC core, a UAS contains a531

UAS core, and a proxy contains a proxy core. The behavior of the UAC and UAS cores depend largely on532

the method. However, there are some common rules for all methods. These rules are captured in Section 8.533

The primarily deal with construction of a request, in the case of a UAC, and processing of that request, and534

generation of a response, in the case of a UAS.535

UAC and UAS core behavior for theREGISTER method is described in Section 10. Registrations play536

an important role in SIP. In fact, a UAS that handles aREGISTER is given a special name - a registrar -537

and it is described in that section.538

UAC and UAS core behavior for theOPTIONS method, used for determining the capabilities of a UAC,539

are described in Section 11.540

Certain other requests are sent within adialog. A dialog is a peer-to-peer SIP relationship between a541

two user agents that persists for some time. The dialog facilitates sequencing of messages between the user542

agents, and proper routing of requests between both them. One way to setup a dialog is with theINVITE543

method. When a UAC sends a request that is within the context of a dialog, it follows the common UAC544

rules as discussed in Section 8, but also the rules for mid-dialog requests. Section 12 discusses dialogs,545

and presents the procedures for their construction, and maintenance, in addition to construction of requests546

within a dialog.547

The most important method in SIP is theINVITE method, which is used to establish a session between548



participants. A session is a collection of participants, and streams of media between them, for the purposes549

of communication. Section 13 discusses how sessions are initiated, resulting in one or more SIP dialogs.550

Section 14 discusses how characteristics of that session are modified, through the use of anINVITE request551

within a dialog. Finally, section 15 discusses how a session is terminated.552

The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal entirely with the UA core. Section 16553

discusses the proxy element, which facilitates routing of messages between user agents.554

6 Definitions555

This specification uses a number of terms to refer to the roles played by participants in SIP communications.556

The definitions of client, server and proxy are similar to those used by the Hypertext Transport Protocol557

(HTTP) (RFC 2616 [8]). The terms and generic syntax of URI and URL are defined in RFC 2396 [9]. The558

following terms have special significance for SIP.559

Back-to-Back user agent: A back-to-back user agent (B2BUA) is a logical entity that receives a request,560

and processes it as a UAS. In order to determine how the request should be answered, it acts as a561

UAC and generates requests. Unlike a proxy server, it maintains dialog state, and must participate in562

all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no563

explicit definitions are needed for its behavior.564

Call: A call is an informal term that refers to a dialog between peers, generally set up for the purposes of a565

multimedia conversation.566

Call leg: Another name for a dialog.567

Call stateful: A proxy is call stateful if it retains state for a dialog from the initiatingINVITE to the termi-568

natingBYE request. A call stateful proxy is always stateful, but the converse is not true.569

Client: A client is any network element that sends SIP requests, and receives SIP responses. Clients may570

or may not interact directly with a human user.User agent clientsandproxiesare clients.571

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

Dialog: A dialog is a peer-to-peer SIP relationship between a UAC and UAS that persists for some time.573

A dialog is established by SIP messages, such as a 2xx response to anINVITE request. A dialog is574

identified by a call identifier, local address, and remote address. A dialog was formerly known as a575

call leg in RFC 2543.576

Downstream: A direction of message forwarding within a transaction which refers to the direction that577

requests flow from the user agent client to user agent server.578

Final response: A response that terminates a SIP transaction, as opposed to aprovisional responsethat579

does not. All 2xx, 3xx, 4xx, 5xx and 6xx responses are final.580

Informational Response: Same as a provisional response.581

Initiator, calling party, caller: The party initiating a session with anINVITE request. A caller retains this582

role from the time it sends theINVITE until the termination of any dialogs established by theINVITE.583



Invitation: An INVITE request.584

Invitee, invited user, called party, callee: The party that receives anINVITE request for the purposes of585

establishing a new session. A callee retains this role from the time it receives theINVITE until the586

termination of the dialog established by thatINVITE.587

Isomorphic request or response:Two requests are defined to beisomorphicfor the purposes of this docu-588

ment if they have the same values for theCall-ID, To, From, CSeq, Request-URI and the top-most589

Via header. Two responses are isomorphic if they have the same values for theCall-ID, To, From,590

CSeq and topVia header. A message which is isomorphic to another is also known as a retransmis-591

sion.592

Location server: Seelocation service.593

Location service: A location service is used by a SIP redirect or proxy server to obtain information about594

a callee’s possible location(s). It is an abstract database, sometimes referred to as a location server.595

The contents of the database can be populated in many ways, including being written by registrars.596

Loop: A request that arrives at a proxy, is forwarded, and later arrives back at the same proxy. When it597

arrives the second time, itsRequest-URI is identical to the first time, and other headers that affect598

proxy operation are unchanged, so that the proxy would make the same processing decision on the599

request it made the first time around. Looped requests are errors, and the procedures for detecting600

them and handling them are described by the protocol.601

Method: The method is the primary function that a request is meant to invoke on a server. The method is602

carried in the request message itself. Example methods areINVITE andBYE.603

Outbound proxy: A proxy that receives all requests from a client, even though it is not the server resolved604

by theRequest-URI. The outbound proxy sends these requests, after any local processing, to the605

address indicated in theRequest-URI, or to another outbound proxy.606

Parallel search: In a parallel search, a proxy issues several requests to possible user locations upon receiv-607

ing an incoming request. Rather than issuing one request and then waiting for the final response before608

issuing the next request as in asequential search, a parallel search issues requests without waiting for609

the result of previous requests.610

Provisional response:A response used by the server to indicate progress, but that does not terminate a SIP611

transaction. 1xx responses are provisional, other responses are consideredfinal.612

Proxy, proxy server: An intermediary entity that acts as both a server and a client for the purpose of making613

requests on behalf of other clients. A proxy server primarily plays to role of routing, which means614

its job is to ensure that a request is passed on to another entity that can further process the request.615

Proxies are also useful for enforcing policy and for firewall traversal. A proxy interprets, and, if616

necessary, rewrites parts of a request message before forwarding it.617

Registrar: A registrar is a server that acceptsREGISTER requests, and places the information it receives618

in those requests into the location service for the domain it handles.619

Regular Transaction: A regular transaction is any transaction with a method other thanINVITE, ACK, or620

CANCEL.621



Ringback: Ringback is the signaling tone produced by the calling party’s application indicating that a622

called party is being alerted (ringing).623

Server: A server is a network element that receives requests in order to service them, and sends back624

responses to those requests. Examples of servers are proxies, user agent servers, redirect servers, and625

registrars.626

Sequential search: In a sequential search, a proxy server attempts each contact address in sequence, pro-627

ceeding to the next one only after the previous has generated a non-2xx final response.628

Session:From the SDP specification: “A multimedia session is a set of multimedia senders and receivers629

and the data streams flowing from senders to receivers. A multimedia conference is an example of a630

multimedia session.” (RFC 2327 [6]) (A session as defined for SDP can comprise one or more RTP631

sessions.) As defined, a callee can be invited several times, by different calls, to the same session.632

If SDP is used, a session is defined by the concatenation of theuser name, session id, network type,633

address typeandaddresselements in the origin field.634

(SIP) transaction: A SIP transaction occurs between a client and a server and comprises all messages from635

the first request sent from the client to the server up to a final (non-1xx) response sent from the server636

to the client, and theACK for the response in the case the response was a 2xx. TheACK for a 2xx637

response is a separate transaction.638

Spiral: A spiral is a SIP request which is routed to a proxy, forwarded onwards, and arrives once again639

at that proxy, but this time, differs in a way which will result in a different processing decision than640

the original request. Typically, this means that it has aRequest-URI that differs from the previous641

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

Stateless proxy: A logical entity that does not maintain the client or server transaction state machines643

defined in this specification when it processes requests. A stateless proxy forwards every request it644

receives downstream and every response it receives upstream.645

Stateful proxy: A logical entity that maintains the client and server transaction state machines defined by646

this specification during the processing of a request. Also known as a transaction stateful proxy. The647

behavior of a stateful proxy is further defined in Section 16. A stateful proxy is not the same as a call648

stateful proxy.649

Transaction User (TU): The layer of protocol processing that resides above the transaction layer. Trans-650

action users include the UAC core, UAS core, and proxy core.651

Upstream: A direction of message forwarding within a transaction which refers to the direction that re-652

sponses flow from the user agent server to user agent client.653

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

User agent client (UAC): A user agent client is a logical entity that creates a new request, and then uses655

the client transaction state machinery to send it. The role of UAC lasts only for the duration of that656

transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration657

of that transaction. If it receives a request later on, it takes on the role of a User Agent Server for the658

processing of that transaction.659



UAC Core: The set of processing functions required of a UAC that reside above the transaction and trans-660

port layers.661

User agent server (UAS):A user agent server is a logical entity that generates a response to a SIP request.662

The response accepts, rejects or redirects the request. This role lasts only for the duration of that663

transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the664

duration of that transaction. If it generates a request later on, it takes on the role of a User agent client665

for the processing of that transaction.666

UAS Core: The set of processing functions required at a UAS that reside above the transaction and transport667

layers.668

User agent (UA): A logical entity which can act as both a user agent client and user agent server for the669

duration of a dialog.670

The role of UAC and UAS as well as proxy and redirect servers are defined on a transaction-by-671

transaction basis. For example, the user agent initiating a call acts as a UAC when sending the initial672

INVITE request and as a UAS when receiving aBYE request from the callee. Similarly, the same software673

can act as a proxy server for one request and as a redirect server for the next request.674

Proxy, location and registrar servers defined above arelogical entities; implementationsMAY combine675

them into a single application program.676

7 SIP Messages677

SIP is a text-based protocol and uses the ISO 10646 character set in UTF-8 encoding (RFC 2279 [11]).678

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

Both Request (section 7.1) andResponse (section 7.2) messages use thegeneric-message format680

of RFC 822 [12]. Both types of messages consist of astart-line, one or more header fields (also known as681

“headers”), an empty line indicating the end of the header fields, and an optionalmessage-body.682

generic-message = start-line*message-headerCRLF[ message-body ]683

The start-line, each message-header line, and the empty lineMUST be terminated by a carriage-return684

line-feed sequence (CRLF). Note that the empty lineMUST be present even if the message-body is not.685

Except for the above difference in character sets, much of SIP’s message and header field syntax is686

identical to HTTP/1.1. Rather than repeating the syntax and semantics here we use [HX.Y] to refer to687

Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]).688

Note, however, that SIP is not an extension of HTTP.689

7.1 Requests690

SIP Requests are distinguished by having aRequest-Line for a start-line. A Request-Line begins with691

a method token, followed by theRequest-URI and the protocol version, and ending withCRLF. The ele-692

ments are separated bySP characters. NoCR or LF are allowed except in the end-of-lineCRLF sequence.693

No LWS is allowed in any of the elements.694



Method Request-URI SIP-Version695

• Method696

This specification defines six methods :REGISTER for registering contact information,INVITE,697

ACK andCANCEL for setting up sessions,BYE for terminating sessions andOPTIONS for querying698

servers about their capabilities. SIP extensions may define additional methods.699

• Request-URI700

The Request-URI is a SIP URL as described in Section 21.1 or a general URI (RFC 2396 [9]). It701

indicates the user or service to which this request is being addressed. TheRequest-URI MUST NOT702

contain unescaped spaces or control characters andMUST NOT be enclosed in ”<>”.703

SIP serversMAY supportRequest-URIs with schemes other than “sip”, for example the “tel” URI704

scheme of RFC 2806 [13]. ItMAY translate non-SIP URIs using any mechanism at its disposal,705

resulting in either a SIP URI or some other scheme.706

• SIP Version707

Both request and response messages include the version of SIP in use, and follow [H3.1] (with HTTP708

replaced by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version ordering, compliance require-709

ments, and upgrading of version numbers. To be compliant with this specification, applications send-710

ing SIP messagesMUST include aSIP- Version of “SIP/2.0”. The string is case-insensitive, but711

implementationsMUST send upper-case.712

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

difference.714

7.2 Responses715

SIP Responses are distinguished by having aStatus-Line for a start-line. A Status-Line, consists of the716

protocol version followed by a numericStatus-Code and its associated textual phrase, with each element717

separated by SP characters. NoCR or LF is allowed except in the finalCRLF sequence.718

SIP-version Status-Code Reason-Phrase719

TheStatus-Code is a 3-digit integer result code that indicates the outcome of an attempt to understand720

and satisfy a request. TheReason-Phrase is intended to give a short textual description of theStatus-721

Code. TheStatus-Code is intended for use by automata, whereas theReason-Phrase is intended for the722

human user. A client is not required to examine or display theReason-Phrase.723

The first digit of theStatus-Code defines the class of response. The last two digits do not have any724

categorization role. For this reason, any response with a status code between 100 and 199 is referred to as725

a “1xx response”, any response with a status code between 200 and 299 as a “2xx response”, and so on.726

SIP/2.0 allows 6 values for the first digit:727

1xx: Informational – request received, continuing to process the request;728

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

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



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

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

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

Full definitions of these classes and each registered code appear in Section 23.734

7.3 Header Fields735

SIP header fields are similar to HTTP header fields in both syntax and semantics. In particular, SIP header736

fields follow the [H4.2] definitions of syntax for message-header, the rules for extending header fields over737

multiple lines, the use of multiple message-header fields with the same field-name, and the rules regarding738

ordering of header fields.739

7.3.1 Header Field Format740

Header fields follow the same generic header format as that given in Section 3.1 of RFC 822 [12]. Each741

header field consists of a field name followed by a colon (”:”) and the field value.742

field-name: field-value743

Note that the formal grammar for amessage-header specified in Section 26 allow for an arbitrary amount744

of whitespace on either side of the colon. No space before the colon and a single space (SP) between the745

colon and the field-value is preferred. That is,746

Subject: lunch747

Subject : lunch748

Subject :lunch749

Subject: lunch750

are all valid, and equivalent, but the last is the preferred form.751

Header fields can be extended over multiple lines by preceding each extra line with at least oneSP or752

horizontal tab (HT). The line break and the whitespace at the beginning of the next line are treated as a753

single SP character. Thus the following are equivalent:754

Subject: I know you’re there, pick up the phone and talk to me!755

Subject: I know you’re there,756

pick up the phone757

and talk to me!758

The relative order of header fields with different field names is not significant. The relative order of those759

with the same field name is important. Multiple header fields with the same field-name may be present in a760

message if and only if the entire field-value for that header field is defined as a comma-separated list (i.e.,761

#(values)). It MUST be possible to combine the multiple header fields into one “field-name: field-value”762

pair, without changing the semantics of the message, by appending each subsequentfield-value to the first,763

each separated by a comma.764



ImplementationsMUST be able to process multiple header fields with the same name in any combination765

of the single-value-per-line or comma-separated value forms.766

The following blocks of headers are valid and equivalent:767

Route: sip:[email protected]

Subject: Lunch769



772

Route: sip:[email protected], sip:[email protected]


Subject: Lunch775

776

Subject: Lunch777

Route: sip:[email protected], sip:[email protected], sip:[email protected]

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




783




787

Route: sip:[email protected],sip:[email protected],sip:[email protected]

The format of a header field-value is defined per header-name. It will always be either an opaque789

sequence of TEXT-UTF8 octets, or a combination of whitespace, tokens, separators, and quoted strings.790

Many of them will adhere to the general form of a value followed by a semi-colon separated sequence of791

parameter-name, parameter-value pairs:792

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

When comparing headers, field names are always case-insensitive. Unless otherwise stated in the def-794

inition of a particular header field, field values, parameter names, and parameter values (tokens in general)795

are case-insensitive. Unless specified otherwise, values expressed as quoted strings are case-sensitive.796

The following are equivalent:797

Contact: <sip:[email protected]>;expires=3600798

CONTACT: <sip:[email protected]>;ExPiReS=3600799

800

Contact-Disposition: session;handling=optional801

contact-disposition: Session;HANDLING=OPTIONAL802

803



The following are not equivalent;804

Warning: 370 devnull "Choose a bigger pipe"805

Warning: 370 devnull "CHOOSE A BIGGER PIPE"806

7.3.2 Header Field Classification807

Some header fields only make sense in requests or responses. These are called Request Header Fields and808

Response Header fields respectively. Those header fields that can appear in either a request or response are809

called General Header Fields. If a header appears in a message not matching its category (such as a request810

header in a response), itMUST be ignored. Section 22 defines the classification of each header.811

7.3.3 Compact Form812

SIP provides a mechanism to represent common header fields in an abbreviated form. This may be useful813

when messages would otherwise become to large to be carried on the transport available to it (exceeding814

the MTU when using UDP for example). These compact forms are defined in Section 22. A compact form815

MAY be substituted for the longer form of a header name at any time without changing the semantics of a816

the message. Multiple header fields in a message with the same header nameMAY appear with an arbitrary817

mix of its long and short field name form. ImplementationsMUST accept both the long and short forms of818

each header name.819

7.4 Bodies820

Requests, including new requests defined in extensions to this specification,MAY contain message bodies821

unless otherwise noted.822

For response messages, the request method and the response status code determine the type and inter-823

pretation of any message body. All responsesMAY include a body.824

7.4.1 Message Body Type825

The Internet media type of the message bodyMUST be given by theContent-Type header field. If the body826

has undergone any encoding (such as compression) then thisMUST be indicated by theContent-Encoding827

header field, otherwiseContent-Encoding MUST be omitted. If applicable, the character set of the message828

body is indicated as part of theContent-Type header-field value.829

The “multipart” MIME type defined in RFC 2046 [14]MAY be used within the body of the message.830

Implementations that send requests containing multipart message bodiesMUST be able to send a session831

description as a non-multipart message body if the remote implementation requests this through anAccept832

header field.833

7.4.2 Message Body Length834

The body length in bytes is provided by theContent-Length header field. Section 22.14 describes the835

necessary contents of this header in detail.836

The “chunked” transfer encoding of HTTP/1.1MUST NOT be used for SIP. (Note: The chunked encoding837

modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator.)838



7.5 Framing SIP messages839

Unlike HTTP, SIPMAY use UDP or other unreliable datagram protocols. Each such datagram carries one840

request or response. Datagrams, including all headers,SHOULD NOT be larger than the path maximum841

transmission unit (MTU) if the MTU is known, or 1500 bytes if the MTU is unknown. However, implemen-842

tationsMUST be able to handle messages up to the maximum datagram packet size. For UDP, this size is843

65,535 bytes, including headers.844

The MTU of 1500 bytes accommodates encapsulation within the “typical” ethernet MTU without IP fragmen-845

tation. Recent studies [15, p. 154] indicate that an MTU of 1500 bytes is a reasonable assumption. The next lower846

common MTU values are 1006 bytes for SLIP and 296 for low-delay PPP (RFC 1191 [16]). Thus, another reason-847

able value would be a message size of 950 bytes, to accommodate packet headers within the SLIP MTU without848

fragmentation.849

In the interest of robustness, any leading empty line(s)MUST be ignored. In other words, if theRequest850

or Response message begins with one or moreCRLF, CR, or LFs, these charactersMUST be ignored.851

Likewise, Implementations processing SIP messages over stream oriented transportsMUST ignore noise852

between messages.853

8 General User Agent Behavior854

A user agent represents an end system. It contains a User Agent Client (UAC), which generates requests,855

and a User Agent Server (UAS) which responds to them. A UAC is capable of generating a request based on856

some external stimulus (the user clicking a button, or a signal on a PSTN line), and processing a response.857

A UAS is capable of receiving a request, and generating response, based on user input, external stimulus,858

the result of a program execution, or some other mechanism.859

When a UAC sends a request, it will pass through some number of proxy servers, which forward the860

request towards the UAS. When the UAS generates a response, the response is forwarded towards the UAC.861

UAC and UAS procedures depend strongly on two factors. First, whether the request or response is862

inside or outside of a dialog, and second, based on the method of a request. Dialogs are discussed thoroughly863

in Section 12; they represent a peer-to-peer relationship between user agents, and are established by specific864

SIP methods, such asINVITE.865

In this section, we discuss the method independent rules for UAC and UAS behavior when processing866

of requests that are outside of a dialog. This includes, of course, the requests which themselves establish a867

dialog.868

8.1 UAC Behavior869

8.1.1 Generating the Request870

A valid SIP request formulated by a UACMUST at a minimum contain the following headers:To, From,871

CSeq, Call-ID, andVia; all of these headers are mandatory in all SIP messages. These five headers are872

the fundamental building blocks of a SIP message, as they jointly provide for most of the critical message873

routing services including the addressing of messages, the routing of responses, ordering of messages, and874

the unique identification of transactions.875

Examples of requests send outside of a dialog include anINVITE to establish a session (Section 13) and876

anOPTIONS to query for capabilities (Section 11).877



8.1.1.1 To TheTo general-header field first and foremost specifies the desired “logical” recipient of the878

request, or the address of record of the user or resource that is the target of this request. This may or may879

not be the ultimate recipient of the request. TheTo headerMAY contain a SIP URI, but it may also make880

use of other URI schemes (for example as the tel URL [13]) when appropriate. TheTo header field allows881

for a display name; this is meant to contain a descriptive version of the URI, and is intended to be displayed882

to a user interface.883

A UAC may learn how to populate theTo header field for a particular request in a number of ways.884

Usually the user will suggest theTo header field through a human interface, perhaps inputting the URI885

manually or selecting it from some sort of address book.886

A request outside of a dialogMUST NOT contain a tag; the tag in theTo field of a request identifies the887

peer of the dialog. Since no dialog is established, no tag is present.888

For further information on theTo header see Section 22.37.889

The following is an example of validTo header:890

To: Carol <sip:[email protected]>891

8.1.1.2 From TheFrom general-header field indicates the logical identity of the initiator of the request,892

possibly the user’s address of record. Like theTo field, it contains a URI and optionally a display name.893

It is used by SIP elements to determine processing rules to apply to a request (for example, automatic call894

rejection). As such, it is very important that the URI not contain IP addresses or host names, since these are895

not logical names.896

TheFrom header field allows for a display name; this is meant to contain a descriptive version of the897

URI, and is intended to be displayed to a user interface. A UACSHOULD use the display name “Anonymous”898

if the identity of the client is to remain hidden.899

Usually the value that populates theFrom header field in requests generated by a particular user agent900

is pre-provisioned by the user or by the administrators of the user’s local domain. If a particular user agent901

is used by multiple users, it might have switchable profiles that include a URI corresponding to the identity902

of the profiled user. Recipients of requests can authenticate the originator of a request in order to ascertain903

that they are who theirFrom header field claims they are (see Section 20.2 for more on authentication).904

TheFrom field MUST contain a new “tag” parameter, chosen by the UAC. See Section 21.3 for details905

on choosing a tag.906

For further information on theFrom header see Section 22.20.907

Examples:908

From: "Bob" <sip:[email protected]> ;tag=a48s909

From: sip:[email protected];tag=887s910

From: Anonymous <sip:[email protected]>;tag=hyh8911

8.1.1.3 Call-ID TheCall-ID general-header field acts as a unique identifier to group together series of912

messages. It is always the same for all requests and responses sent by either UA in a dialog. It is also the913

same in each registration from a UA within a single boot cycle.914

In a new request created by a UAC outside of any dialog, unless overridden by method specific behavior,915

it MUST be selected by the UAC as a a globally unique identifier over space and time; all SIP user agents916

must have a means to guarantee that theCall-ID headers they produce will not be inadvertently generated917

by any other user agent.918



Use of cryptographically random identifiers [17] in the generation of Call-IDs isRECOMMENDED. Im-919

plementationsMAY use the form “localid@host”.Call-IDs are case-sensitive and are simply compared920

byte-by-byte.921

Using cryptographically random identifiers provides some protection against session hijacking, and reduces the922

likelihood of unintentional Call-ID collisions.923

No provisioning or human interface is required for the selection of theCall-ID header field value for a924

request.925

For further information on theCall-ID header see Section 22.8.926

Example:927


8.1.1.4 CSeq The Cseq header serves as a way to identify and order transactions. It consists of a929

sequence number and a method. The methodMUST match that of the request. The sequence number value930

is arbitrary, butMUST be expressible as a 32-bit unsigned integer andMUST be less than 2**31.931

As long as it follows the above guidelines, a client may use any mechanism it would like to selectCSeq932

header field values.933

For further information on theCSeq header see Section 22.16.934

Example:935


8.1.1.5 Via The Via header is used to determine the transport to use for sending a request, and for937

identifying the IP address and port where the response is to be sent. Rules for setting and using the values938

in this header are described in Section 19.939

For further information on theVia header see Section 22.40.940

8.1.1.6 Contact The Contact header provides a SIP URI that can be used to contact that specific in-941

stance of the user agent for subsequent requests. TheContact headerMUST be present in any request that942

can result in the establishment of a dialog. For the methods defined in this specification, that includes only943

the INVITE request. For these requests, the scope of theContact is the dialog. That is, theContact header944

refers to the URL that the UA would like to receive requests at, for requests that are part of that dialog only.945

Only a single URIMUST be present.946

For further information on theContact header, see Section 22.10.947

8.1.1.7 Request-URI The initial Request-URI of the messageSHOULD be set to the value of the URI948

in the To field. One notable exception is theREGISTER method; behavior for setting theRequest-URI949

of register is given in Section 10. Another exception is the case of pre-existingRoute headers; in that case,950

the procedures of Section 12.2.1.1 as they pertain to theRequest- URI are followed, even though there is951

no dialog.952

8.1.1.8 Supported and Require If the UAC supports extensions to SIP that can be applied by the953

server to the response, the UACSHOULD include aSupported header in the request listing the option tags954

for those extensions.955



The option-tags listedMUST only refer to extensions defined in standards track RFCs. This is to prevent956

servers from insisting that clients implement non-standard, vendor defined features in order to receive ser-957

vice. Extensions defined by experimental and informational RFCs are explicitly excluded from usage with958

theSupported header in a request, since they too are often used to document vendor defined extensions.959

If the UAC wishes to insist that a UAS understand an extension that the UAC will apply to the request in960

order to process the request, itMUST insert aRequire header into the request listing the option tag for that961

extension. If the UAC wishes to apply an extension to the request and insist that a proxy understand that962

extension, itMUST insert aProxy-Require header into the request listing the option tag for that extension.963

8.1.1.9 Additional Message ComponentsAfter a new request has been created, the headers described964

above have been properly constructed, any additional optional headers are added, as are any headers specific965

to the method.966

SIP requestsMAY contain a MIME-encoded message-body. Regardless of the type of body that a request967

contains, certain headers must be formulated to characterize the contents of the body. For further information968

on these headers see Section 7.4.969

8.1.2 Sending the Request970

The destination for the request is then computed. This can be a preconfigured IP address, port and transport971

of an outbound proxy, or it can be determined through DNS procedures applied to theRequest-URI. These972

procedures are described in Section 24, which yield an ordered set of address, port and transports to attempt.973

The UAC SHOULD follow the procedures defined there for stateful elements, trying each address until a974

server is contacted. Each try constitutes a new transaction, and therefore a new client transactionMUST be975

constructed for each.976

8.1.3 Processing Responses977

Responses are first processed by the transport layer, and then passed up to the transaction layer. The trans-978

action layer performs its processing, and then passes it up to the TU. The majority of response processing979

in the TU is method specific. However, there are some general behaviors independent of the method.980

8.1.3.1 Unrecognized ResponsesA UAC MUST treat any response they do not recognize as being981

equivalent to the x00 response code of that class, andMUST be able to process the x00 response code for982

all classes. For example, if a UAC receives an unrecognized response code of 431, it can safely assume that983

there was something wrong with its request and treat the response as if it had received a 400 (Bad Request)984

response code.985

8.1.3.2 Vias If more than oneVia header field is present in a response, the UACSHOULD discard the986

message.987

The presence of additionalVia header fields that precede the originator of the request suggests that the message988

was misrouted or possibly corrupted.989

8.1.3.3 Processing 3xx responsesUpon receipt of a redirection response (e.g. a 3xx response status990

code), clientsSHOULD use the URI(s) in theContact header field to formulate a new request.991



To do that, the client copies all but the “method-param” and “header” elements of theaddr-spec part992

of theContact header field into theRequest-URI of the request. It uses the “header” parameters to create993

headers for the request, replacing any default headers normally used.994

In all other respects, requests sent upon receipt of a redirect responseSHOULD re-use the headers and995

bodies of the original request.996

TheContact values present in redirection responsesSHOULD NOT be cached across calls, as they may997

not represent the most desirable location for a particular destination address.998

8.1.3.4 Processing 4xx responsesCertain 4xx response codes require specific UA processing, indepen-999

dent of the method.1000

If a 401 or 407 response is received, the UACSHOULD follow the authorization procedures of Section1001

20.2.2 and Section 20.2.3 to retry the request with credentials.1002

If a 413 response is received (Section 23.4.11), it means that the request contained a body that was1003

longer than the UAS was willing to accept. If possible, the UACSHOULD retry the request, either omitting1004

the body or using one of a smaller length.1005

If a 415 response is received (Section 23.4.13), it means the request contained media types not supported1006

by the UAS. The UACSHOULD retry sending the request, this time only using content with types listed in1007

theAccept header in the response, with encodings listed in theAccept-Encoding header in the response,1008

and with languages listed in theAccept-Language in the response.1009

If a 420 response is received (Section 23.4.14), it means the request contained aRequire or Proxy-1010

Require header listing an option-tag for a feature not supported by a proxy or UAS. The UACSHOULD1011

retry the request, this time omitting any extensions listed in theUnsupported header in the response.1012

In all of the above cases, retrying the request is accomplished by creating a new request with the appro-1013

priate modifications. This new requestSHOULD have the same value of theCall-ID, To, andFrom of the1014

previous request, but theCSeq should contain a new sequence number that is one higher than the previous.1015

With other 4xx responses, a retry may or may not be possible depending on the method and the use case.1016

8.2 UAS Behavior1017

When a request outside of a dialog is processed by a UAS, there are a set of processing rules which are1018

followed, independent of the method. Section 12 gives guidance on how a UAS can tell whether a request1019

is inside or outside of a dialog.1020

8.2.1 Authentication/Authorization1021

A UAS MAY authenticate the originator of a request, and this process may require the server to issue a1022

challenge for credentials. The required behavior is independent of the method of the request, and is detailed1023

in Section 20.2.1024

8.2.2 Method Inspection1025

Once a request is authenticated (or no authentication was desired), the UASMUST inspect the method of the1026

request. If the UAS does not support the method of a request itMUST generate a 405 (Method Not Allowed)1027

response. Procedures for generation of responses are described in Section 8.2.7. The UASMUST also add1028

anAllow header to the 405 response. TheAllow header fieldMUST list the set of methods supported by the1029

UAS generating the message.1030



TheAllow header is presented in Section 22.5.1031

If the method is one supported by the server, processing continues.1032

8.2.3 Header Inspection1033

If a UAS does not understand a header field in a request (i.e. the header is not defined in this specification1034

or in any supported extension), the serverMUST ignore that header and continue processing the message. A1035

UAS SHOULD ignore any malformed headers which are not necessary for processing requests.1036

8.2.3.1 To and Request-URI TheTo header field identifies the original recipient of the request desig-1037

nated by the user identified in theFrom field. The original recipient may or may not be the UAS processing1038

the request, do to call forwarding or other proxy operations. A UASMAY apply any policy it wishes in1039

determination of whether to accept requests when theTo field is not the identity of the UAS. However, it is1040

RECOMMENDED that a UAS accept requests even if they do not recognize the URI scheme (e.g., atel:1041

URI) in theTo header, or if theTo header does not address a known or current user of this UAS. If, on the1042

other hand, the UAS decides to reject the request, itSHOULD generate a response with a 403 status code and1043

send it to the server transaction for transmission.1044

However, theRequest-URI identifies the UAS that is to process the request. If theRequest-URI does1045

not identify an address that the UAS is willing to accept requests for, itSHOULD reject the request with1046

a 404 (Not Found) response. If theRequest-URI does not provide sufficient information for the UAS to1047

determine whether it is willing to process the request, itSHOULD return a 485 (Ambiguous) response. This1048

responseSHOULD contain aContact header field containing URIs of new addresses to be tried. Typically,1049

a UA which uses theREGISTER method to bind its address of record to a specific contact address, will see1050

requests whoseRequest-URI equals those contact addresses.1051

8.2.3.2 Require Assuming the UAS decides that it is the proper element to process the request, it ex-1052

amines theRequire header field, if present.1053

TheRequire general-header field is used by UAC to tell UAS about SIP extensions that the UAC expects1054

the UAS to support in order to properly process the request. If a UAS does not understand an option listed1055

in aRequire header field, itMUST respond by generating a response with status code 420 (Bad Extension).1056

The UASMUST add aUnsupported, and list in it those options it does not understand amongst those in1057

theRequire header of the request. Upon receipt of the 420 the clientSHOULD retry the request, this time1058

without using those extensions listed in the Unsupported header in the response.1059

Example:1060

UACC->UAS: INVITE sip:[email protected] SIP/2.01061

Require: com.example.billing1062

Payment: sheep_skins, conch_shells1063

1064

UASS->UAC: SIP/2.0 420 Bad Extension1065

Unsupported: com.example.billing1066

This is to make sure that the client-server interaction will proceed without delay when all options are understood1067

by both sides, and only slow down if options are not understood (as in the example above). For a well-matched1068

client-server pair, the interaction proceeds quickly, saving a round-trip often required by negotiation mechanisms.1069



In addition, it also removes ambiguity when the client requires features that the server does not understand. Some1070

features, such as call handling fields, are only of interest to end systems.1071

8.2.4 Content Processing1072

Assuming the UAS understands any extensions required by the client, the UAS examines the body of the1073

message, and the headers that describe it. If there are any bodies whose type (indicated by theContent-1074

Type), language (indicated by theContent-Language) or encoding (indicated by theContent-Encoding)1075

are not understood, and that body part is not optional (as indicated by theContent-Disposition) header, the1076

UAS MUST reject the request with a 415 (Unsupported Media Type) response. The responseMUST contain1077

a Accept header listing the types of all bodies it understands, in the event the request contained bodies of1078

types not supported by the UAS. If the request contained content encodings not understood by the UAS,1079

the responseMUST contain anAccept-Encoding header listing the encodings understood by the UAS. If1080

the request contained content with languages not understood by the UAS, the responseMUST contain an1081

Accept-Language header indicating the languages understood by the UAS.1082

Beyond these checks, body handling is method and type specific.1083

For further information on the processing of Content-specific headers see Section 7.4.1084

8.2.5 Applying Extensions1085

A UAS that wishes to apply some extension when generating the responseMUST only do so if support for1086

that extension is indicated in theSupported header in the request. If the desired extension is not supported,1087

the serverSHOULD rely only on baseline SIP and any other extensions supported by the client. To ensure1088

that theSHOULD can be fulfilled, any specification of a new extensionMUST include discussion of how1089

to gracefully return to baseline SIP when the extension is not present. In rare circumstances, where the1090

server cannot process the request without the extension, the serverMAY send a 421 (Extension Required)1091

response. This response indicates that the proper response cannot be generated without support of a specific1092

extension. The needed extension(s)MUST be included in aRequire header in the response. This behavior1093

is NOT RECOMMENDED, as it will generally break interoperability.1094

Any extensions applied to a non-421 responseMUST be listed in aRequire header included in the1095

response. Of course, the serverMUST NOT apply extensions not listed in theSupported header in the1096

request. As a result of this, theRequire header in a response will only ever contain option tags defined in1097

standards track RFCs.1098

8.2.6 Processing the Request1099

Assuming all of the checks in the previous subsections are passed, the UAS processing becomes method1100

specific. Section 10 deals with theREGISTER request, section 11 deals with theOPTIONS request,1101

section 13 deals with theINVITE request, and section 15 deals with theBYE request.1102

8.2.7 Generating the Response1103

When a UAS wishes to construct a response to a request, it follows these procedures. Additional procedures1104

may be needed depending on the status code of the response and the circumstances of its construction. These1105

additional procedures are documented elsewhere.1106



The From field of the responseMUST equal theFrom field of the request. TheCall-ID field of the1107

responseMUST equal theCall-ID field of the request. TheCseq field of the responseMUST equal theCseq1108

field of the request. TheVia headers in the responseMUST equal theVia headers in the request, andMUST1109

maintain the same ordering.1110

If a request contained aTo tag in the request, theTo field in the responseMUST equal that of the request.1111

However, if theTo field in the request did not contain a tag, the URI in theTo field in the responseMUST1112

equal the URI in theTo field in the request. Additionally, the UASMUST add a tag to theTo field in the1113

response. This serves to identify the UAS that is responding, possibly resulting in a component of a dialog1114

ID. The same tagMUST be used for all responses to that request, both provisional and final. Procedures for1115

generation of tags are defined in Section 21.3.1116

8.3 Redirect Servers1117

In some architectures it may be desirable to reduce the processing load on proxy servers that are responsible1118

for routing requests by relying on redirection. Redirection allows servers to push routing information for a1119

request back in a response to the client, thereby taking themselves out of the loop of further messaging for1120

this transaction while still aiding in locating the target of the request. When the originator of the request1121

receives the redirection it will send a new request based on the routing information it has received. By1122

propagating routing information from the core of the network to its edges, redirection allows for considerable1123

network scalability.1124

A redirect server is logically constituted of a server transaction layer and a transaction user that has1125

access to a location service of some kind (see Section 10 for more on registrars and location services). This1126

location service is effectively a database containing mappings between a single URI and a set of one or more1127

alternative locations at which the target of that URI can be found.1128

A redirect server does not issue any SIP requests of its own. After receiving a request other thanCAN-1129

CEL, the server gathers the list of alternative locations from the location service and either returns a final1130

response of class 3xx or it refuses the request. For well-formedCANCEL requests, itSHOULD return a1131

2xx response. This response ends the SIP transaction. The redirect server maintains transaction state for an1132

entire SIP transaction. It is the responsibility of clients to detect forwarding loops between redirect servers.1133

When a redirect server returns a 3xx response to a request, it populates the list of (one or more) alterna-1134

tive locations intoContact headers. An “expires” parameter to theContact header may also be supplied1135

to indicate the lifetime of theContact data.1136

TheContact header field contains URIs giving the new locations or user names to try, or may simply1137

specify additional transport parameters. A 301 or 302 response may also give the same location and user-1138

name that was targeted by the initial request but specify additional transport parameters such as a different1139

server or multicast address to try, or a change of SIP transport from UDP to TCP or vice versa.1140

Note that theContact header fieldMAY also refer to a different entity than the one originally called. For1141

example, a SIP call connected to GSTN gateway may need to deliver a special informational announcement1142

such as “The number you have dialed has been changed.”1143

A Contact response header field can contain any suitable URI indicating where the called party can be1144

reached, not limited to SIP URIs. For example, it could contain URL’s for phones, fax, orirc (if they were1145

defined) or amailto: (RFC 2368, [18]) URL.1146

The “expires” parameter of theContact header field indicates how long the URI is valid. The parameter1147

is either a number indicating seconds or a quoted string containing aSIP-date. If this parameter is not1148

provided, the value of theExpires header field determines how long the URI is valid. Implementations1149



MAY treat values larger than 2**32-1 (4294967295 seconds or 136 years) as equivalent to 2**32-1.1150

Redirect serversMUST ignore features that are not understood (including unrecognized headers,Re-1151

quired extensions, or even method names) and proceed with the redirection of the session in question. If1152

a particular extension requires that intermediate devices support it, the extensionMUST be tagged in the1153

Proxy-Require field as well (see Section 22.28).1154

9 Canceling a Request1155

The previous section has discussed general UA behavior for generating requests, and processing responses,1156

for requests of all methods. In this section, we discuss a general purpose method, calledCANCEL.1157

TheCANCEL request, as the name implies, is used to cancel a previous request sent by a client. Specif-1158

ically, it asks the user agent server to cease processing the request, and generate an error response to that1159

request.CANCEL has no effect on a request that has already been responded to. Because of this, it is most1160

useful toCANCEL requests which can take a long time to respond to. For this reason,CANCEL is most1161

useful forINVITE requests, which can take a long time to generate a response. In that usage, a UAS that1162

receives aCANCEL request for anINVITE, but has not yet sent a response, would “stop ringing”, and then1163

respond to theINVITE with a specific error response (a 487).1164

Cancel requests can be constructed and sent by any type of client, including both proxies and user1165

agent servers. Section 15 discusses under what conditions a UAC wouldCANCEL anINVITE request, and1166

Section 16 discusses proxy usage ofINVITE.1167

Because a stateful proxy can generate its ownCANCEL, a stateful proxy also responds to aCANCEL,1168

rather than simply forwarding a response it would receive from a downstream element. For that reason,1169

CANCEL is referred to as a “hop-by-hop” request, since it is responded to at each stateful proxy hop.1170

9.1 Client Behavior1171

The following procedures are used to construct aCANCEL request. TheRequest-URI, Call-ID, To, the1172

numeric part ofCSeq andFrom header fields in theCANCEL requestMUST be identical to those in the1173

request being cancelled, including tags. ACANCEL constructed by a clientMUST have only a singleVia1174

header, whose value matches the topVia in the request being cancelled. Using the same values for these1175

headers allows theCANCEL to be matched with the request it cancels (Section 9.2 indicates how such1176

matching occurs). However, the method part of theCseq headerMUST have a value ofCANCEL. This1177

allows it to be identified and processed as a transaction in its own right (See Section 17).1178

Once theCANCEL is constructed, the clientSHOULD check whether any response (provisional or final)1179

has been received for the request being cancelled (herein referred to as the ”original request”). TheCANCEL1180

requestMUST NOT be sent if no provisional response has been received, rather, the clientMUST wait for the1181

arrival of a provisional response before sending the request. If the original request has generated a final1182

response, theCANCEL SHOULD NOT be sent, as it is an effective no-op, sinceCANCEL has no effect on1183

requests which have already generated a final response. When the client decides to send theCANCEL, it1184

creates a client transaction for theCANCEL, and passes it theCANCEL request along with the destination1185

address, port and transport. The destination address, port, and transport for theCANCEL MUST be identical1186

to those used to send the original request.1187

If it was allowed to send theCANCEL before receiving a response for the previous request the server could1188

receive theCANCEL before the original request.1189



Note that both the transaction corresponding to the original request and theCANCEL transaction will1190

complete independently. However, a UAC canceling a request cannot rely on receiving a 487 (Request1191

Terminated) response for the original request, as an RFC 2543-compliant UAS will not generate such a1192

response. If there is no final response for the original request in 64*T1 seconds for anINVITE transaction,1193

and T3 seconds for a non-INVITE transaction, the clientSHOULD then consider the original transaction1194

cancelled andSHOULD destroy the client transaction handling the original request.1195

9.2 Server Behavior1196

TheCANCEL method requests that the TU at the server side cancel a pending request with the sameCall-1197

ID, To, From, topVia header andRequest-URI andCSeq (sequence number only) header field values.1198

The processing of aCANCEL request at a server depends on the type of server. A stateless proxy will1199

forward it, a stateful proxy might respond to it and generate someCANCEL requests of its own, and a UAS1200

will respond to it. See Section 16.8 for proxy treatment ofCANCEL.1201

When a UAS receives aCANCEL, it looks for any server transactions which were created by requests1202

with the sameTo, From, Call-ID, Cseq numeric value,Request-URI and topVia header. If no matching1203

transactions are found, theCANCEL is responded to with a 481 (Call Leg/Transaction Does Not Exist). If1204

the transaction for the original request still exists, the behavior of the UAS on receiving aCANCEL request1205

depends on whether it has already sent a final response for original request. If it has, theCANCEL request1206

has no effect on the processing of the original request, no effect on any session state, and no effect on the1207

responses generated for the original request. If the UAS has not issued a final response for the original1208

request, it immediately responds to the original request with a 487 (Request Terminated).1209

TheCANCEL request itself is answered with a 200 (OK) response in either case. Once the response is1210

constructed it is passed to the server transaction for theCANCEL request.1211

10 Registrations1212

10.1 Overview of Usage1213

SIP is a protocol that offers a discovery capability. For one user to initiate a session with another, SIP must1214

discover the current host(s) that the called user is reachable at. This discovery process is accomplished1215

by SIP proxy servers, which are responsible for receiving a request, determining where to send it based1216

on knowledge of the location of the user, and then sending it there. To do this, proxies consult an abstract1217

service known as alocation service, which provides address bindings for a particular domain. These address1218

bindings map an incoming SIP URL,sip:[email protected] , for example, to one or more SIP URLs1219

which are somehow “closer” to the desired user,sip:[email protected] , for example.1220

Ultimately, a proxy will consult a location service which maps a received URL to the current host(s) that a1221

user is logged in to.1222

There are many ways by which the contents of the location service can be established. One way is1223

administratively. In the above example, Bob is known to be a member of the engineering department through1224

access to a corporate database. SIP provides a mechanism, however, for a user agent to explicitly create a1225

binding in the location service of a proxy. This mechanism is known as registration.1226

The process of registration entails sending aREGISTER message to a special type of UAS known as a1227

registrar. The registrar acts as a front end to the location service for a domain, reading and writing mappings1228

based on the contents of theREGISTER messages. This location service will then be consulted by a proxy1229



server that is responsible for routing requests for that domain.1230

SIP does not mandate a particular mechanism for implementing the location service. The only require-1231

ment is that a registrar for some domainMUST be capable of reading and writing data to the location service,1232

and a proxy for that domainMUST be capable of reading that same data. A registrarMAY be co-located with1233

a particular SIP proxy server for the same domain, allowing usage of an in memory database for the location1234

service. Usage of a shared database is another implementation choice. The choice depends entirely on the1235

architectural requirements (redundancy, scalability, etc) of a particular deployment.1236

Registration creates bindings in a location service for a particular domain that associate an “address of1237

record” URI with one or more “contact addresses”. This means that when a proxy for that domain receives a1238

request whose request URI matches the address of record, the proxy will forward the request to the contact1239

addresses registered to that address of record. Generally, it only makes sense to register an address of record1240

at a location service for a domain when requests for that address of record would be routed to that domain.1241

In most cases, this means that the domain of the registration will need to match the domain in the URI of1242

the address of record.1243

The most important usage of the registration mechanism is to inform a proxy of the mapping between1244

the address of record and the current host on which the UA resides. However, the registration process is a1245

general mechanism for establishing bindings, and can be used for other purposes (for example, to set up call1246

forwarding).1247

bob +−−−−+ | UA | | | +−−−−+ | |3)INVITE | [email protected] chicago.com +−−−−−−−−+ V +−−−−−−−−−+ 2)Store|Location|4)Query +−−−−−+ |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com +−−−−−−−−−+ +−−−−−−−−+=======>+−−−−−+ A 5)Resp | | | | | 1)REGISTER| | | | +−−−−+ | | UA |<−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−+ cube2214a| | 6)INVITE +−−−−+ [email protected] carol

Figure 2:REGISTER example



10.2 Construction of the REGISTER request1248

Several operations can be performed with aREGISTER method with respect to a registrar. One of these is1249

the basic registration operation that is described above, which provides a new binding between an address1250

of record and one or more contact addresses. Registration on behalf of a particular address of record may be1251

performed by a third party if they are authorized to do so. A client may also remove previous bindings, or1252

query to determine which bindings are currently in place for an address of record.1253

Aside from the exceptions noted in this and the following sections, the construction of theREGISTER1254

method, and behavior of clients sending aREGISTER is identical to the general UAC behavior described in1255

Section 8.1 and Section 17.1. Regardless of the operation that is performed by aREGISTER, the following1256

header fieldsMUST be formulated as follows:1257

Request-URI : TheRequest-URI names the domain of the location service that the registration is meant1258

for (e.g. “chicago.com”). The user nameMUST be empty.1259

To: The To header field contains the address of record whose registration is to be created or modified.1260

Note that the initialTo header field and theRequest-URI field SHOULD therefore be different in a1261

REGISTER message.1262

From : TheFrom header field contains the address of record of the person responsible for the registration,1263

which MAY be identical to the value of theTo header field. For third-party registrations theFrom1264

header field andTo header field are different.1265

Call-ID : All registrations from a user agent clientSHOULD use the sameCall-ID header value, at least1266

within the same reboot cycle.1267

If different Call-IDs were used for overlappingREGISTER messages coming from the same client, the1268

registrar might have trouble determining their ordering.1269

Contact : REGISTER requestsMAY contain one or moreContact header fields. Contact addresses are1270

presented in theContact header fields ofREGISTER requests.1271

Note that user agentsMUST NOT send a new registration (containing newContact header fields, as1272

opposed to a retransmission) until they have received a response from the registrar for the previous one.1273

The following optionalContact header parameters also contain behavior specific to the registration1274

process.1275

action : The “action” parameter has been deprecated. UACsSHOULDNOT use the “action” parameter.1276

expires : The “expires” parameter indicates how long the UAC would like the binding to be valid. The1277

parameter is either a number indicating seconds or a quoted string containing aSIP-date. If this1278

parameter is not provided, the value of theExpires header field determines how long the binding is1279

valid. ImplementationsMAY treat values larger than 2**32-1 (4294967295 seconds or 136 years) as1280

equivalent to 2**32-1.1281

10.2.1 Adding Bindings withREGISTER1282

For a simple registration, aREGISTER request sent to a registrar includes contact addresses to which1283

requests should be forward for the originating user’s address of record. The address of record itself (i.e.1284



’sip:[email protected]’)MUST populate theTo header of theREGISTER. TheContact header fields of1285

the request typically contain SIP URIs that identify particular SIP endpoints (i.e. ’sip:[email protected]’),1286

but theyMAY use any URI scheme; this way a SIP UA can choose to register telephone numbers (with the1287

tel URL, [13]) or email addresses (with a mailto URL, [18]) asContacts for an address of record.1288

For example, if Carol, whose address of record is ’sip:[email protected]’, needed to register, she would1289

typically want to register with the registrar associated with the location service of chicago.com. This location1290

service would then be accessed by a proxy server that receives requests targeting users in the chicago.com1291

domain, and hence new requests for Carol’s address of record will be routed to her SIP endpoint.1292

Once a client has established bindings at a registrar, itMAY send subsequent registrations containing1293

new bindings or modifications to pre-existing bindings as necessary. The 2xx response to theREGISTER1294

message will contain (inContact header fields) a complete list of bindings that have been registered for this1295

address of record at this registrar.1296

10.2.1.1 Setting the Expiration Interval of Contact Addresses When a client sends aREGISTER1297

request, itMAY suggest an expiration interval that indicates how long the client would like the registration1298

to be valid (although as is detailed in Section 10.3, the registrar has the ultimate say).1299

There are two ways in which a client can suggest an expiration interval for a binding: through anExpires1300

header, or an “expires” Contact header parameter. The latter allows expiration intervals to be suggested1301

on a per-binding basis when more than one binding is given in a singleREGISTER, whereas the former1302

suggests an expiration interval for allContact header fields that do not contain the “expires” parameter.1303

If neither mechanism for expressing a suggested expiration time is present in aREGISTER, a default1304

suggestion of one hour is assumed.1305

10.2.1.2 Setting Preference among Contact AddressesIf more than oneContact is sent in aREGIS-1306

TER, then the registering UA intends to associate all of the URIs given in theseContact headers with the1307

address of record present in theTo field. This list can be prioritized with the “q” mechanism.1308

q: The “q” parameter indicates a relative preference for the particularContact header field compared to1309

other bindings present in thisREGISTER message or existing within the location service of the1310

registrar. For an example of how a proxy server uses “q” values, see Section 16.5.1311

10.2.2 Removing Bindings withREGISTER1312

Registrations are removed from the registrar through an expiration process; registrations are soft state and1313

need to be refreshed periodically. A client may attempt to influence the expiration intervals selected by the1314

registrar as described in Section 10.2.1.1315

A registering user agent requests the immediate removal of a binding by specifying an expiration in-1316

terval of “0” for that contact address in aREGISTER. It is RECOMMENDED that user agents support this1317

mechanism so that bindings can be removed (for whatever reason) before their expiration interval has passed.1318

TheREGISTER-specificContact header field value of “*” applies to all registrations, but itMUST only1319

be used when theExpires header is present with a value of “0”.1320

Use of the “*” Contact header field value allows a registering user agent to remove all of its bindings expediently.1321



10.2.3 Fetching Bindings withREGISTER1322

If no Contact headers are present in aREGISTER, then the UA is not in fact registering any new bindings,1323

and the list of bindings is therefore left unchanged. As noted above, in a successful response to thisREG-1324

ISTER message, the complete list of existing bindings is returned, and thus aREGISTER withoutContact1325

headers serves as a fetch operation.1326

10.2.4 Refreshing Registrations1327

When a 2xx response has been received by the client for aREGISTER request, the clientMUST determine1328

when each of the bindings enumerated in the response needs to be refreshed. This may include bindings that1329

were registered in previousREGISTER transactions.1330

Since the list of bindings returned in the response to aREGISTER may contain bindings that were not1331

included in thisREGISTER transaction, the client must correlateContact header fields in the response1332

with the Contact header fields it sent in the request in order to establish proper expiration timers. This1333

correlation should be performed in accordance with the URI comparison rules given in Section 21.1.4.1334

The registering UAMUST re-register each contact address at least as often as the mandated expiration1335

interval. A REGISTER that refreshes a bindingSHOULD have the sameCall-ID as the request which1336

created the binding. TheCSeq headerSHOULD have a numeric sequence number that is one higher than1337

the value sent in the last request with the sameCall-ID.1338

Note that a UAMUST must update its expiration timers for refreshing each binding every time it receives1339

a response to a registration request.1340

Registration refreshesSHOULD be sent to the same address as the original registration, unless redirected.1341

10.2.5 Discovering a Registrar1342

Depending on the policy of their administrative domain, SIP UAs can be configured with the address of a1343

local registrar. Some UAs may be equipped with protocol tools (outside the scope of SIP) that allow them1344

to discover their local registrar dynamically.1345

Note that as an alternate means of discovering a registrar if no local registrar is configured in the user1346

agent, clientsMAY register via multicast. Multicast registrations are addressed to the well-known “all SIP1347

servers” multicast address “sip.mcast.net” (224.0.1.75). This requestMUST be scoped to ensure it is not1348

forwarded beyond the boundaries of the administrative system. ThisMAY be done with either TTL or1349

administrative scopes (see [19]), depending on what is implemented in the network. SIP user agentsMAY1350

listen to that address and use it to become aware of the location of other local users (see [20]); however, they1351

do not respond to the request.1352

Multicast registration may be inappropriate in some environments, for example, if multiple businesses share the1353

same local area network.1354

If a SIP UA knows of an appropriate registrar itSHOULD attempt to register with this server periodically1355

- management of registration intervals is detailed below.1356

10.3 Processing of REGISTER at the Registrar1357

A registrar is a UAS that responds to aREGISTER request, and stores the information gathered from that1358

request in a location service that is in turn accessible to proxy servers within its administrative domain. A1359

registrar handles requests as a UAS (in conformity with Section 8.2 and Section 17.2) but it accepts only the1360



REGISTER method and generates only the responses detailed in this section. Note that theREGISTER1361

method also does not support theRecord-Route or Route header, and that proxy serversMUST NOT add1362

Record-Route headers toREGISTER requests.1363

A registrar must know (through provisioning or some other mechanism) the set if administrative do-1364

main(s) for which its associated location service(s) are responsible.REGISTER requestsMUST be pro-1365

cessed by a registrar in the order that they are received.1366

Upon the arrival of aREGISTER message, the registrarMUST inspect theRequest-URI to determine1367

whether it has access to a location service responsible for the domain to which this request is addressed.1368

If this message is for some other administrative domain, then if the registrar can act as a proxy server, it1369

SHOULD forward the request to the addressed domain (following the general behavior for proxying messages1370

described in Section 16).1371

When a registrar receives aREGISTER message, it isRECOMMENDED that the registrar authenticate1372

the user agent client. Mechanisms for the authentication of SIP user agents are described in Section 20.2;1373

registration behavior in no way overrides the generic authentication framework for SIP. If no authentication1374

mechanism is available, the registrarMAY take the From address as the asserted identity of the originator of1375

the request.1376

Once the identity of the registering user has been ascertained, it isRECOMMENDED that the registrar1377

determine if the authenticated user agent is authorized to request and/or modify registrations for this address1378

of record. For example, a registrar might consult a authorization database (directly or through an appropriate1379

protocol) that maps credentials or other tokens of identity resulting from authentication to one or more1380

addresses of record for which this identity is responsible.1381

Note that in architectures that support third-party registration, one entity may be responsible for updating the1382

registrations associated with multiple addresses of record.1383

When the registrar has determined that the client is permitted to make the request, the registrarMUST1384

extract the address of record from theTo header field of theREGISTER. Note that the registrarMUST1385

extract the entireTo header field URI in order to use it as an index in the location service.1386

Next, the registrarMUST query its location service (the repository of previously registered bindings)1387

for the set of bindings associated with this address of record. If the address of record is not valid for this1388

administrative domain (for example, because the username is not assigned), then the registration attempt1389

fails (see below). A full URI comparison (as described in Section 21.1.4)MUST be performed to determine1390

whether a given binding matches this address of record.1391

The registrar nowMUST extract all theContact header fields from theREGISTER message (note that1392

there may be noContact header field).1393

Each contact address in aREGISTER MUST now be compared to all existing registrations at this loca-1394

tion service according to the rules in Section 21.1.4. Note that URIs other than SIP URIs in contact addresses1395

MUST be compared according to the standard URI equivalency rules for the URI schema in question.1396

If a match is found among pre-existing registrations, the registrarMUST copy all parameters associated1397

with the currentContact header field from theREGISTER message into the pre-existing binding in its1398

location service (overwriting with changed values any existing parameters as necessary, with the exception1399

of “expires”). Expiration intervals for this contact addressMUST also be reset, based on any suggested1400

expiration in theREGISTER (remember that this can be “0”).1401

If no match is found among the set of pre-existing registrations, the registrarMUST create a new binding1402

in its location service between the address of record and the currentContact header field. AllContact1403

header field parameters are copied verbatim into this new binding (again with the exception of “expires”).1404

An expiration intervalMUST be selected by the registrar, taking into account any suggested expiration for1405



this contact address in theREGISTER.1406

Allowing the registrar to set the registration interval protects it against excessively frequent registration refreshes1407

while limiting the state that it needs to maintain and decreasing the likelihood of registrations going stale.1408

The expiration interval mandated by the registrar may be either longer or shorter than the interval sug-1409

gested by the sender of theREGISTER, though the registrarSHOULD abide by the registering client’s1410

suggestion.1411

A serverMAY decide to lengthen the expiration interval if the refresh rate of a particular client exceeds a thresh-1412

old, for example.1413

After the expiration interval selected by the registrar for a binding has passed, if the binding has not been1414

refreshed (increasing the expiration interval), the registrarSHOULD silently discard the binding.1415

Once all bindings in the location service have been updated to reflect any changes present to contact1416

addresses in theREGISTER message, the registrarMUST remove any bindings that expire immediately.1417

The REGISTER might have set the expiration interval for some bindings to “0” to remove them before their1418

expiration interval passes.1419

Finally, the registrar must generate a response. If the address of record given in theTo header field of1420

the REGISTER method is valid for its administrative domain, then a 200 responseMUST be sent, which1421

MUST contain a complete list (withinContact header fields) of the currently valid bindings in the location1422

service associated with the address of record contained in theTo field of theREGISTER request. This list1423

MAY be empty (in which case the 200 would not contain anyContact headers).1424

In a successful response to aREGISTER, wherein the bindings for this address of record are enumerated1425

as described above, the registrarMUST supply an expiration interval for each contact address in either an1426

“expires” parameter of a Contact header or anExpires header. This interval specifies the expiration interval1427

that has been mandated by the registrar (taking into account the registering UA’s suggestion).1428

If the registration failed because the address of record contained in the To field of theREGISTER is not1429

valid for this domain, then a 404MUST be sent.1430

11 Querying for Capabilities1431

The SIP methodOPTIONS allows a client to query another client or server as to its capabilities. This1432

allows a client to discover information about the methods, content types, extensions, codecs etc. supported1433

without actually ”ringing” the other party. For example, before a client inserts aRequire header field into1434

an INVITE listing an option that it is not certain the destination UAS supports, the client can query the1435

destination UAS with anOPTIONS to see if this option is returned in aSupported header field.1436

The target of theOPTIONS request is identified by theRequest-URI, which could identify another1437

User Agent or a SIP Server. Alternatively, a server receiving anOPTIONS request with aMax-Forwards1438

header value of 0MAY respond to the request regardless of theRequest-URI.1439

This behavior is common with HTTP/1.1.1440

An OPTIONS request sent as part of an established dialog does not have any impact on the dialog.1441

11.1 Construction of OPTIONS Request1442

An OPTIONS request is constructed using the standard rules for a SIP request as discussed Section 8.1.1.1443

A Contact header fieldMAY be present in anOPTIONS.1444



OPEN ISSUE #197: What is the semantic of thisContact1445

An Accept header fieldSHOULD be included to indicate the type of message body the UAC wishes to1446

receive in the response.1447

ExampleOPTIONS request:1448

OPTIONS sip:[email protected] SIP/2.01449

Via: SIP/2.0/UDP 10.1.1.1:5060;branch=23411513a61450

Via: SIP/2.0/UDP 10.1.3.3:50601451

To: <sip:[email protected]>1452



CSeq: 63104 OPTIONS1455


Accept: application/sdp1457


11.2 Processing of OPTIONS Request1459

The response to anOPTIONS is constructed using the standard rules for a SIP response as discussed in1460

Section 8.2.7. The response code chosen is the same that would have been chosen had the request been an1461

INVITE. That is, a 200 (OK) would be returned if the UAS is ready to accept a call, a 486 (Busy Here)1462

would be returned if the UAS is busy, etc. This allows anOPTIONS request to be used to determine the1463

basic state of a UAS, which can be an indication of whether the UAC will accept anINVITE request.1464

Note that this use ofOPTIONS has limitations due the differences in proxy handling ofOPTIONS and1465

INVITE requests. While a forkedINVITE can result in multiple 200 OK responses being returned, a forked1466

OPTIONS will only result in a single 200 OK response, since it is treated by proxies using the non-INVITE1467

handling. See Section 13.2.1 for the normative details.1468

Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fieldsSHOULD be1469

present in a 200 OK response to anOPTIONS request.1470

A Contact header fieldMAY be present in a 200 OK response.1471

A Warning header fieldMAY be present.1472

A message bodyMAY be sent, the type of which is determined by theAccept header in theOPTIONS1473

request.1474

ExampleOPTIONS response (corresponding to the request in Section 11.1):1475

SIP/2.0 200 OK1476

Via: SIP/2.0/UDP 10.1.1.1:5060;branch=23411513a61477

Via: SIP/2.0/UDP 10.1.3.3:50601478

To: <sip:[email protected]>;tag=938108741479



CSeq: 63104 OPTIONS1482


Allow: INVITE, ACK, CANCEL, OPTIONS, BYE1484

Accept: application/sdp1485



Accept-Encoding: gzip1486

Accept-Language: en1487

Supported: foo1488



1491

v=01492

o=carol 28908764872 28908764872 IN IP4 10.3.6.61493

s=-1494

t=0 01495

c=IN IP4 10.3.6.61496

m=audio 0 RTP/AVP 0 1 3 991497

a=rtpmap:0 PCMU/80001498

a=rtpmap:1 1016/80001499

a=rtpmap:3 GSM/80001500

a=rtpmap:99 SX7300/80001501

m=video 0 RTP/AVP 31 341502

a=rtpmap:31 H261/900001503

a=rtpmap:34 H263/900001504

12 Dialogs1505

A key concept for a user agent is that of a dialog. A dialog represents a peer- to-peer SIP relationship between1506

a two user agents that persists for some time. The dialog facilitates sequencing of messages between the1507

user agents, and proper routing of requests between both them. The dialog represents a context in which to1508

interpret SIP messages. The previous section discussed method independent UA processing for requests and1509

responses outside of a dialog. This section discusses how those requests and responses are used to construct1510

a dialog, and then how subsequent requests and responses are sent within a dialog.1511

A dialog is identified at each UA with a dialog ID, which consists of aCall-ID value, a local URI and1512

local tag (together called the local address), and a remote URI and remote tag (together called the remote1513

address). The dialog ID at each UA involved in the dialog is not the same. Specifically, the local URI and1514

local tag at one UA are identical to the remote URI and remote tag at the peer UA. The tags are opaque1515

tokens that facilitate the generation of unique dialog IDs.1516

A dialog ID is also associated with all responses, and with any request that contains a tag in theTo field.1517

The rules for computing the dialog ID of a message depend on whether the entity is a UAC or UAS. For a1518

UAC, theCall-ID value of the dialog ID is set to theCall-ID of the message, the remote address is set to the1519

To field of the message, and the local address is set to theFrom field of the message (these rules apply to1520

both requests and responses). As one would expect, for a UAS, theCall-ID value of the dialog ID is set to1521

theCall-ID of the message, the remote address is set to theFrom field of the message, and the local address1522

is set to theTo field of the message.1523

A dialog contains certain pieces of state needed for further message transmissions within the dialog.1524

This state consists of theCall-ID, a local sequence number (used to order requests from the UA to its peer),1525

a remote sequence number (used to order requests from its peer to the UA), and a route set, which is an1526

ordered list of URIs. The route set is the set of servers that need to be traversed to send a request to the peer.1527

A dialog can also be in the “early” state, which occurs when it is created with a provisional response, and1528



then transition to the “established” state when the final response comes.1529

12.1 Creation of a Dialog1530

Dialogs are created through the generation of non-failure responses to requests with specific methods.1531

Within this specification, only the 2xx and 1xx responses toINVITE establish a dialog. A dialog estab-1532

lished by a non-final response to a request is called an early dialog. ExtensionsMAY define other means for1533

creating dialogs. Section 13 gives more details that are specific to theINVITE method. Here, we describe1534

the process for creation of dialog state that is not dependent on the method.1535

12.1.0.1 UAS When a UAS responds to a request with a response that establishes a dialog (such as a1536

2xx to INVITE), the UASMUST copy all Record-Route headers from the request into the response, and1537

MUST maintain the order of those headers. This includes the URIs, URI parameters, and anyRecord-1538

Route header parameters, whether they are known or unknown to the UAS. The UASMUST add aContact1539

header field to the response. TheContact header field contains an address where the UAS would like to1540

be contacted for subsequent requests in the dialog (which includes theACK for a 2xx response in the case1541

of an INVITE). Generally, the host portion of this URI is the IP address of the host, or its FQDN. The URI1542

provided in theContact headerMUST be a SIP URL.1543

The UAS then constructs the state of the dialog. This stateMUST be maintained for the duration of the1544

dialog. First, the route setMUST be computed by following these steps:1545

1. The list of URIs in theRecord-Route headers in the request, if present, are taken, including any URI1546

parameters.1547

2. The URI in theContact header from the request if present, is taken, including any URI parameters.1548

The URI is appended to the bottom of the list of URIs from the previous step.1549

Contact was not mandatory in RFC2543. Thus, if the UAS is talking to an older UAC, the UAC might not1550

have inserted theContact header.1551

3. The resulting list of URIs is called theroute set.1552

These rules clearly imply that a UAMUST be able to parse and processRecord-Route header fields. This is a1553

change from RFC2543, where all record-route and route processing was optional for user agents.1554

It is possible for theroute setto be empty. This will occur if neitherRecord-Route headers nor a1555

Contact header were present in the request. The UASMUST also remember whether the bottom-most entry1556

in theroute setwas constructed from aContact header or not. This is effectively a boolean value, which we1557

refer to as CONTACTSET. This is needed in order for the UA to determine whether the bottom most value1558

can be updated from subsequent requests; if it was constructed from aContact, it can be updated.1559

The remote sequence number sequence numberMUST be set to the value of the sequence number in the1560

Cseq header of the request. The local sequence numberMUST be empty. The call identifier component1561

of the dialog IDMUST be set to the value of theCall-ID in the request. The local address component of1562

the dialog IDMUST be set to theTo field in the response to the request (which therefore includes the tag),1563

and the remote address component of the dialog IDMUST be set to theFrom field in the request. A UAS1564

MUST be prepared to receive a request without a tag in theFrom field, in which case the tag is considered1565

to effectively have a value of null.1566

This is to maintain backwards compatibility with RFC2543, which did not mandateFrom tags.1567



12.1.0.2 UAC When a UAC receives a response that establishes a dialog, it constructs the state of the1568

dialog. This stateMUST be maintained for the duration of the dialog. First, the route setMUST be computed1569

by following these steps:1570

1. The list of URIs present in theRecord-Route headers in the response are taken, if present, including1571

all URI parameters, and their order is reversed.1572

2. The URI in theContact header from the response, if present, is taken, including all URI parameters,1573

and appended to the end of the list from the previous step.1574

3. The list of URIs resulting from the above two operations is referred to as theroute set.1575

It is possible for theroute setto be empty. This will occur if neitherRecord-Route headers nor a1576

Contact header were present in the response. The UACMUST also remember whether the bottom-most1577

entry in theroute setwas constructed from aContact header or not. This is effectively a boolean value,1578

which we refer to as CONTACTSET. This is needed in order for the UA to determine whether the bottom1579

most value can be updated from subsequent requests; if it was constructed from aContact, it can be updated.1580

The local sequence number sequence numberMUST be set to the value of the sequence number in the1581

Cseq header of the request. The remote sequence numberMUST be empty (it is established when the UA1582

sends a request within the dialog). The call identifier component of the dialog IDMUST be set to the value1583

of the Call-ID in the request. The local address component of the dialog IDMUST be set to theFrom1584

field in the request, and the remote address component of the dialog IDMUST be set to theTo field of the1585

response. A UACMUST be prepared to receive a response without a tag in theTo field, in which case the1586

tag is considered to effectively have a value of null.1587

This is to maintain backwards compatibility with RFC2543, which did not mandateTo tags.1588

12.2 Requests within a Dialog1589

Once a dialog has been established between two UAs either of themMAY initiate new transactions as needed1590

within the dialog. However, a dialog imposes some restrictions on the use of simultaneous transactions.1591

A TU MUST NOT initiate a new regular transaction within a dialog while a regular transaction is in1592

progress (in either direction) within that dialog.1593

OPEN ISSUE #113: Should we relax the constraint on non-overlapping regular transactions?1594

A refresh request sent within a dialog is defined as a request that can modify theroute setof the dialog.1595

For dialogs that have been established with anINVITE, the only refresh request defined is re-INVITE (see1596

Section 14). Other extensions may define different refresh requests for dialogs established in other ways.1597

Note that anACK is NOTa refresh request.1598

12.2.1 UAC Behavior1599

12.2.1.1 Generating the Request A request within a dialog is constructed by using many of the com-1600

ponents of the state stored as part of the dialog.1601

TheTo header field of the requestMUST be set to the remote address, and theFrom header fieldMUST1602

be set to the local address (both including tags, assuming the tags are not null).1603

The Call-ID of the requestMUST be set to theCall-ID of the dialog. Requests within a dialogMUST1604

contain strictly monotonically increasing and contiguousCSeq sequence numbers (increasing-by-one) in1605

each direction. Therefore, if the local sequence number is not empty, the value of the local sequence number1606

MUST be incremented by one, and this valueMUST placed into theCseq header. If the local sequence1607



number is empty, an initial valueMUST be chosen using the guidelines of Section 8.1.1.4. The method field1608

in theCseq headerMUST match the method of the request.1609

With a length of 32 bits, a client could generate, within a single call, one request a second for about 136 years1610

before needing to wrap around. The initial value of the sequence number is chosen so that subsequent requests within1611

the same call will not wrap around. A non-zero initial value allows clients to use a time-based initial sequence1612

number. A client could, for example, choose the 31 most significant bits of a 32-bit second clock as an initial1613

sequence number.1614

TheRequest-URI of requests is determined according to the following rules:1615

The UAC takes the list of URI in theroute set. The top URIMUST be inserted into the request URI of1616

the request, including all URI parameters. Any URI parameters not allowed in the request URIMUST then1617

be stripped. Each of the remaining URIs (if any) from theroute set, including all URI parameters,MUST be1618

placed into aRoute header field into the request, in order.1619

A TU SHOULD follow the rules just mentioned to build theRequest-URI of the request, regardless of1620

whether the UA uses an outbound proxy server or not. However, in some instances, a UA may not be willing1621

or capable of sending the request to the top element in theroute set. One example is a UA that is not capable1622

of DNS, and therefore may not be able to follow those procedures. In these cases, the UAMAY send the1623

request to a local outbound server. In this case, itMUST NOT remove the topRoute header.1624

In dialogs created by anINVITE, if the UA is the caller, it sets theRequest-URI to the same value it used for1625

the initial request, and sends it to its local outbound server.1626

Bug#161: Which Request-URI does the callee use?1627

A UAC SHOULD include aContact header in any refresh requests within a dialog, and unless there is a1628

need to change it, the URISHOULD be the same as used in previous requests within the dialog. As discussed1629

in Section 12.2.2, aContact header in a refresh request updates the route set. This allows a UA to provide1630

a new contact address, should its address change during the duration of the dialog.1631

However, requests that are not refresh requests do not affect theroute setfor the dialog.1632

Once the request has been constructed, the address of the server is computed and the request is sent,1633

using the same procedures for requests outside of a dialog (Section 8.1.1).1634

12.2.1.2 Processing the ResponsesThe UAC will receives responses to the request from the transaction1635

layer.1636

The behavior of a UAC that receives a 3xx response for a request sent within a dialog is the same as if1637

the request would have been sent outside a dialog. This behavior is described in Section 13.2.2.1638

Note however that when the UAC tries alternative locations it still uses theroute setfor the dialog to build the1639

Route header of the request.1640

If a UAC has aroute setfor a dialog, and receives a 2xx response to a refresh it sent, theContact header1641

field of the response is examined. If not present, theroute setremains unchanged. If the response had a1642

Contact header field, and the boolean variable CONTACTSET is false, the URL in theContact header1643

field in the response is added to the bottom of theroute set, and CONTACTSET is set to true. If the refresh1644

request response had aContact header field, and CONTACTSET is true, the URL in theContact header1645

field of the response to the refresh request replaces the bottom value in theroute set. If a refresh request is1646

responded with a non-2xx final response theroute setremains unchanged as if no refresh request had been1647

issued.1648

If the response for the a request within a dialog is a 481 (Call/Transaction Does Not Exist) or a 4081649

(Request Timeout) the UACSHOULD terminate the dialog.1650

For INVITE initiated dialogs terminating the dialog consists of sending aBYE.1651



12.2.2 UAS behavior1652

The UAS will receive the request from the transaction layer. If the request has a tag in theTo header field,1653

the UAS core computes the dialog identifier corresponding to the request and compares it with existing1654

dialogs. If there is a match, this is a mid-dialog request. In that case, the same processing rules for requests1655

outside of a dialog, discussed in Section 8.2, are applied by the UAS once the request is received from the1656

transaction layer.1657

Requests that do not change in any way the state of a dialog may be received within a dialog (e.g., an1658

OPTIONS request). They are processed as if they had been received outside the dialog.1659

Requests within a dialogMAY containRecord-Route andContact header fields. However, requests1660

that are not refresh requests do not update theroute setfor the dialog. This specification only defines one1661

refresh request: re-INVITE (see Section 14).1662

Special rules apply when updatedRecord-Route or Contact header fields are received inside a refresh1663

request. If a UAS has aroute setfor a dialog, and receives a refresh for that dialog containingRecord-1664

Route header fields, itMUST copy those header fields into any 2xx response to that request. If the boolean1665

variable CONTACTSET is true, theContact header field in the request (if present) replaces the last entry in1666

the route set. If the boolean variable CONTACTSET is false, the UASMUST add the URL in theContact1667

header field in the re-INVITE to the bottom of theroute set, and then set CONTACTSET to true. If the1668

request did not contain aContact header field, the route-set at the UAS remains unchanged.1669

If the remote sequence number is empty, itMUST be set to the value of the sequence number in theCseq1670

header in the request. If the remote sequence number was not empty, but the sequence number of the request1671

is lower than the remote sequence number, the request is out of order andMUST be rejected with a 5001672

response. If the remote sequence number was not empty, and the sequence number of the request is greater1673

than the remote sequence number, the request is in order. It is possible for theCSeq header to be higher1674

than the remote sequence number by more than one. This is not an error condition, and a UASSHOULD be1675

prepared to receive and process requests withCSeq values more than one higher than the previous received1676

request. The UASMUST then set the remote sequence number to the value of the sequence number in the1677

Cseq header in the request.1678

12.3 Termination of a Dialog1679

Dialogs can end in several different ways, depending on the method. When a dialog is established with1680

INVITE, it is terminated with aBYE. No other means to terminate a dialog are described in this specification,1681

but extensions can define other ways.1682

13 Initiating a Session1683

13.1 Overview1684

When a user agent client desires to initiate a session (for example, audio, video, or a game), it formulates1685

an INVITE request. TheINVITE request asks a server to establish a session. This request is forwarded by1686

proxies, eventually arriving at one or more UAS which can potentially accept the invitation. These UAS’s1687

will frequently need to query the user about whether to accept the invitation. After some time, those UAS can1688

accept the invitation (meaning the session is to be established) by sending a 2xx response. If the invitation1689

is not accepted, a 3xx,4xx,5xx or 6xx response is sent, depending on the reason for the rejection. Before1690



sending a final response, the UAS can also send a provisional response (1xx) to advise the UAC of progress1691

in contacting the called user.1692

After possibly receiving one or more provisional responses, the UA will get one or more 2xx responses or1693

one non-2xx final response. Because of the protracted amount of time it can take to receive final responses1694

to INVITE, the reliability mechanisms forINVITE transactions differ from those of other requests (like1695

OPTIONS). Once it receives a final response, the UAC needs send anACK for every final response it1696

receives. The procedure for sending thisACK depends on the type of response. For final responses between1697

300 and 699, theACK processing is done in the transaction layer, and follows one set of rules (See Section1698

17). For 2xx responses, theACK is generated by the UAC core.1699

A 2xx response to anINVITE establishes a session, and it also creates a dialog between the UA that1700

issued theINVITE and the UA that generated the 2xx response. Therefore, when multiple 2xx responses are1701

received from different remote UAs (because theINVITE forked), each 2xx establishes a different dialog.1702

All these dialogs are part of the same call.1703

This section provides details on the establishment of a session usingINVITE.1704

13.2 Caller Processing1705

13.2.1 Creating the Initial INVITE1706

Since the initialINVITE represents a request outside of a dialog, its construction follows the procedures of1707

Section 8.1.1. Additional processing is required for the specific case ofINVITE.1708

An Allow header field (Section 22.5)SHOULD be present in theINVITE. It indicates what methods can1709

be invoked within a dialog, on the UA sending theINVITE, for the duration of the dialog. For example, a1710

UA capable of receivingINFO requests within a dialog [21]SHOULD include anAllow header listing the1711

INFO method.1712

A Supported header field (Section 22.35)SHOULD be present in theINVITE. It enumerates all the1713

extensions understood by the UAC.1714

An Accept (Section 22.1) header fieldMAY be present in theINVITE. It indicates which content-types1715

are acceptable to the UA, in both the response received by it, and in any subsequent requests sent to it within1716

dialogs established by theINVITE. TheAccept header is especially useful for indicating support of various1717

session description formats.1718

The UA MAY add anExpires header field (Section 22.19) to limit the validity of the invitation. If the1719

time indicated in theExpires header field is reached and no final answer for theINVITE has been received1720

the UAC coreSHOULD generate aCANCEL request for the originalINVITE.1721

A UAC MAY also find useful to add, among others,Subject (Section 22.34),Organization (Section1722

22.24) andUser-Agent (Section 22.39) header fields. They all contain useful information related to the1723

INVITE.1724

The UACMAY choose to add a message body to theINVITE. Section 8.1.1.9 deals with how to construct1725

the header fields-Content-Type among others- needed to describe the message body.1726

There are special rules for message bodies that contain a session description - their corresponding1727

Content-Disposition is “session”. SIP uses an offer/answer model where one UA sends a session de-1728

scription, called the offer, which contains a proposed description of the session. The offer indicates the1729

desired communications means (audio, video, games), parameters of those means (such as codec types) and1730

addresses for receiving media from the offerer. The other UA responds with another session description,1731

called the answer, which indicates which communications means are accepted, the parameters which ap-1732

ply to those means, and addresses for receiving media from the answerer. The offer/answer model can be1733



mapped into theINVITE transaction in two ways. The first, which is the most intuitive, is that theINVITE1734

contains the offer, the 2xx response contains the answer, and no session description is provided in theACK.1735

In this model, the UAC is the offerer, and the UAS is the answerer. A second model is that theINVITE con-1736

tains no session description, the 2xx response contains the offer, and theACK contains the answer. In this1737

model, the UAS is the offerer, and the UAC is the answerer. The second model is useful for gateways from1738

H.323v1 to SIP, where the H.323 media characteristics are not known until the call is established. This is1739

also useful for sessions that use third-party call control. As a result of these models, if theINVITE contains1740

a session description, theACK MUST NOT contain one. Conversely, if the caller chooses to omit the session1741

description in theINVITE, theACK MUST contain one (if a 2xx response is received). 2xx responses to1742

an INVITE MUST always contain a session description. All user agents that supportINVITE MUST support1743

both models.1744

The Session Description Protocol (SDP) [6]MUST be supported by all user agents as a means to describe1745

sessions, and its usage for construction offers and answersMUST follow the procedures defined in [22].1746

Note that the restrictions of the offer-answer model (session description only in theINVITE OR in1747

the ACK, but not in both) just described only apply to bodies whoseContent-Disposition header field1748

is “session”. Therefore, it is possible that both theINVITE and theACK contain a body message (e.g.,1749

the INVITE carries a photo (Content-Disposition: render) and theACK a session description (Content-1750

Disposition: session) ).1751

If the Content-Disposition header field is missing, bodies ofContent-Type application/sdp imply the1752

disposition “session”, while other content types imply “render”.1753

Once theINVITE has been created, the UAC follows the procedures defined for sending requests outside1754

of a dialog (Section 8). This results in the construction of a client transaction that will ultimately send the1755

request and deliver responses to the UAC.1756

If a UA A sends anINVITE request toB and receives anINVITE request fromB before it has received1757

the response to its request fromB, A MAY return a 500 (Internal Server Error), whichSHOULD include a1758

Retry- After header field specifying when the request should be resubmitted.1759

13.2.2 ProcessingINVITE Responses1760

Once theINVITE has been passed to theINVITE client trasaction, the UAC waits for responses for theIN-1761

VITE. Responses are matched to their correspondingINVITE because they have the sameCall-ID, the same1762

From header field, the sameTo header field, excluding the tag, and the sameCSeq. Rules for comparisons1763

of these headers are described in Section 22.1764

13.2.2.1 1xx responses Zero, one or multiple provisional responses may arrive before one or more1765

final responses are received. Provisional responses for anINVITE request can create “early dialogs”. If a1766

provisional response has a tag in theTo field, and if the dialog ID of the response does not match an existing1767

dialog, one is constructed using the procedures defined in Section 12.1.0.2.1768

The early dialog will only be needed if the UAC needs to send a request to its peer within the dialog1769

before the initialINVITE transaction completes. Header fields present in a provisional response are appli-1770

cable for the duration of the early dialog (e.g., anAllow header field in a provisional response contains the1771

methods that can be used in the early dialog).1772

13.2.2.2 3xx responses A 3xx response may contain aContact header field providing new addresses1773

where the callee might be reachable. Depending on the status code of the 3xx response (see Section 23.3)1774

the UACMAY choose to try those new addresses.1775



13.2.2.3 4xx, 5xx and 6xx responses A single non-2xx final response may be received for theIN-1776

VITE. 4xx, 5xx and 6xx responses may contain aContact header field indicating the location where addi-1777

tional information about the error can be found.1778

All early dialogs are considered terminated upon reception of the non-2xx final response.1779

After having received the non-2xx final response the UAC core considers the INVITE transaction com-1780

pleted. TheINVITE client transaction handles generation ofACKs for the response (see Section 17).1781

13.2.2.4 2xx responses Multiple 2xx responses may arrive at the UAC for a singleINVITE request1782

due to a forking proxy. Each response is distinguished by thetag parameter in theTo header field, and each1783

represents a distinct dialog, with a distinct dialog identifier.1784

If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog1785

MUST be transitioned to the “established”, and the route set for the dialogMUST be recomputed based on the1786

2xx response using the procedures of Section 12.1.0.2. Otherwise, a new established dialog is constructed1787

in the same fashion.1788

The route set only is recomputed for backwards compatibility. RFC 2543 did not mandate mirroring ofRecord-1789

Route headers in a 1xx, only 2xx. However, we cannot update the entire state of the dialog, since mid-dialog1790

requests may have been sent within the early call leg, modifying the sequence numbers, for example.1791

The UAC coreMUST generate anACK request for each 2xx received from the transaction layer. The1792

header fields of theACK are constructed in the same way as for any request sent within a dialog (see Section1793

12) with the exception of theCSeq. The sequence number of theCSeq header fieldMUST be the same as1794

the INVITE being acknowledged, but theCSeq methodMUST beACK. If the INVITE did not contain an1795

offer, the 2xx will contain one, and therefore theACK MUST carry an answer in its body.1796

Once theACK has been constructed, the procedures of Section 24 are used to send it. However, the1797

request is passed to the transport layer directly for transmission, rather than a client transaction. This is1798

because the UAC core handles retransmissions of theACK, not the transaction layer. TheACK MUST be1799

passed to the client transport every time a retransmission of the 2xx final response that triggered theACK1800

arrives.1801

The UAC core considers theINVITE transaction completed 62*T1 seconds after the reception of the1802

first 2xx response. At this point all the early dialogs that have not transitioned to established dialogs are1803

terminated. Once theINVITE transaction is considered completed by the UAC core, no more new 2xx1804

responses are expected to arrive.1805

If, after acknowledging any 2xx response to anINVITE, the caller does not want to continue with that1806

dialog, then the callerMUST terminate the dialog by sending aBYE request as described in Section 15.1807

13.3 Callee Processing1808

13.3.1 Processing of the INVITE1809

The UAS core will receiveINVITE requests from the transaction layer. It first performs the request process-1810

ing procedures of Section 8.2, which are applied for both requests inside and outside of a dialog.1811

Assuming these processing states complete without generating a response, the UAS core performs the1812

additional processing steps:1813

1. If the request is anINVITE that contains anExpires header field the UAS core inspects this header1814

field. If the INVITE has already expired a 487 response is generated.1815



2. If the request has no tag in theTo the UAS core checks ongoing transactions. If theTo, From, Call-ID,1816

CSeq exactly match (including tags) those of any request received previously, but the branch-ID in1817

the topmostVia is different from those received previously, the UAS coreSHOULD generate a 4821818

(Loop detected) response and pass it to the server transaction.1819

The same request that was generated by the UAC has arrived to the UAS more than once following different1820

paths. The UAS processes the request that was received first and responds with 482 (Loop detected) to the rest1821

of them.1822

If no match is found, the request does not belong to any existing dialog. If the request is anINVITE1823

the UAS core follows the procedures described in this section.1824

3. If the request is a mid-dialog request, the method-independent processing described in Section 12.2.21825

is first applied. It might also modify the session; Section 14 provides details.1826

4. If the request has a tag in theTo header field but the dialog identifier does not match any of the1827

existing dialogs, the UAS may have crashed and restarted, or may have received a request for a1828

different (possibly failed) UAS. The UASMAY either accept or reject the request. Accepting the1829

request provides robustness, so that dialogs can persist even through crashes. UAs wishing to support1830

this capability must choose monotonically increasingCSeq sequence numbers even across reboots.1831

This is because subsequent requests from the crashed-and-rebooted UA towards the other UA need to1832

have aCSeq sequence number higher than previous requests in that direction.1833

Note also that the crashed-and-rebooted UA will have lost anyRoute headers which would need to1834

be inserted into a subsequent request. Therefore, it is possible that the requests may not be properly1835

forwarded by proxies.1836

RTP media agents allowing restarts need to be robust by accepting out-of-range timestamps and sequence1837

numbers.1838

If the UAS wishes to reject the request, because it does not wish to recreate the dialog, itMUST1839

respond to the request with a 481 (Call/Transaction Does Not exist) status code and pass that to the1840

server transaction.1841

Processing from here forward assumes that theINVITE is outside of a dialog, and is thus for the purposes1842

of establishing a new session.1843

The INVITE may contain a session description, in which case the UAS is being presented with an offer1844

for that session. It is possible that the user is already a participant in that session, even though theINVITE1845

is outside of a dialog. This can happen when a user is invited to the same multicast conference by multiple1846

other participants. If desired, the UASMAY use identifiers within the session description to detect this1847

duplication. For example, SDP contains a session id and version number in the origin (o) field. If the user1848

is already a member of the session and the session parameters contained in the session description have not1849

changed, the UASMAY silently accept theINVITE1850

The INVITE may not contain a session description at all, in which case the UAS is being asked to1851

participate in a session, but the UAC has asked that the UAS provide the offer of the session.1852

The callee can indicate progress, accept, redirect, or reject the invitation. In all of these cases, it formu-1853

lates a response using the procedures described in Section 8.2.7.1854



13.3.1.1 Progess The UAS may not be able to answer the invitation immediately, and might choose1855

to indicate some kind of progress to the caller (for example, an indication that a phone is ringing). This is1856

accomplished with a provisional response between 101 and 199. These provisional responses establish early1857

dialogs and therefore follow the procedures of Section 12.1.0.1 in addition to those of Section 8.2.7. A UAS1858

MAY send as many provisional responses as it likes. Each of theseMUST indicate the same dialog ID. SIP,1859

however, does not guarantee that these provisional responses are reliably delivered to the UAC.1860

13.3.1.2 The INVITE is redirected If the UAS decides to redirect the call, a 3xx response is sent. A1861

300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved Temporarily) responseSHOULD contain1862

aContact header field containing URIs of new addresses to be tried. The response is passed to theINVITE1863

server transaction, which will deal with its retransmissions.1864

13.3.1.3 The INVITE is rejected A common scenario occurs when the callee is currently not willing1865

or able to take additional calls at this end system. A 486 (Busy Here)SHOULD be returned in such scenario.1866

If the UAS knows that no other end system will be able to accept this call a 600 (Busy Everywhere) response1867

SHOULD be sent instead. However, it is unlikely that a UAS will be able to know this in general, and thus1868

this response will not usually be used. The response is passed to theINVITE server transaction, which will1869

deal with its retransmissions.1870

13.3.1.4 The INVITE is accepted The UAS core generates a 2xx response. This response establishes1871

a dialog, and therefore follows the procedures of Section 12.1.0.1 in addition to those of Section 8.2.7.1872

A 2xx response to anINVITE SHOULD contain theAllow header field and theSupported header field,1873

andMAY contain theAccept header field. Including these header fields allows the UAC to determine the1874

features and extensions supported by the UAS for the duration of the call, without probing.1875

If the INVITE request contained an offer, the 2xxMUST contain an answer. If theINVITE did not contain1876

an offer, the 2xxMUST contain an offer.1877

Once the response has been constructed it is passed to theINVITE server transaction. Note, however,1878

that theINVITE server transaction does not retransmit 2xx responses to anINVITE. Therefore, it is neces-1879

sary to pass periodically the response to the server transaction until theACK arrives. The 2xx response is1880

resubmitted to the server transaction with an interval that starts at T1 seconds and doubles for each retrans-1881

mission until it reaches T2 seconds (T1 and T2 are defined in Section 17). Response retransmissions cease1882

when anACK request is received with the same dialog ID as the response. This is independent of whatever1883

transport protocols are used to send the response.1884

Since 2xx is retransmitted end-to-end, there may be hops between UAS and UAC which are UDP. To ensure1885

reliable delivery across these hops, the response is retransmitted periodically even if the transport at the UAS is1886

reliable.1887

If the server retransmits the 2xx response for 64*T1 seconds without receiving anACK, it considers the1888

dialog completed, the session terminated, and therefore itSHOULD send aBYE.1889

14 Modifying an Existing Session1890

A successfulINVITE request (see Section 13) establishes both a dialog between two user agents and a1891

session (using the offer/answer model). Section 12 explains how to modify an existing dialog using a1892

refresh request (e.g., changing theroute setof the dialog). This section describes how to modify the actual1893



session. This modification can involve changing addresses or ports, adding a media stream, deleting a media1894

stream, and so on. This is accomplished by sending a newINVITE request within the same dialog that1895

established the session. AnINVITE request sent within an existing dialog is known as a re-INVITE.1896

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

Either the caller or callee can modify an existing session.1898

14.1 UAC Behavior1899

The same offer-answer model that applies to session descriptions inINVITEs (Section 13.2.1) applies to1900

re-INVITEs. As a result, a UAC that wants to add a media stream, for example, will create a new offer that1901

contains this media stream, and send that in anINVITE request to its peer. It is important to note that the1902

full description of the session, not just the change, is sent. This maintains the idempotency of SIP, supports1903

stateless session processing in various elements, and supports failover and recovery capabilities. Of course,1904

a UAC MAY send a re-INVITE with no session description, in which case the response to the re-INVITE will1905

contain the offer.1906

If the session description format has the capability for version numbers, the offererSHOULD indicate1907

that the version of the session description has changed.1908

TheTo, From, Call-ID, CSeq, andRequest-URI of a re-INVITE are set following the same rules as1909

for regular requests within an existing dialog, described in Section 12.1910

Note that, as opposed to initialINVITEs (see Section 13), re-INVITEs contain tags in theTo header1911

field and are sent using theroute setfor the dialog. Therefore, a single final (2xx or non-2xx) response is1912

received for re-INVITEs.1913

Note that a UACMUST NOT initiate a newINVITE transaction within a dialog while another transaction1914

(INVITE or non-INVITE) is in progress. However, a UAMAY initiate a regular transaction within an early1915

dialog - while anINVITE transaction is in progress.1916

If a re-INVITE is responded with a non-2xx final response the session parametersMUST remain un-1917

changed, as if no re-INVITE had been issued.1918

The rules for transmitting a re-INVITE and for generating anACK for a 2xx response to re-INVITE are1919

the same as for anINVITE (Section 13.2.1).1920

14.2 UAS Behavior1921

Section 13.3.1 describes the steps to follow in order to distinguish incoming re-INVITEs from incoming1922

initial INVITEs. This Section describes the procedures to follow upon reception of a re-INVITE for an1923

existing dialog.1924

A UAS that receives a secondINVITE before it sent the final response to a firstINVITE with a lower1925

CSeq sequence number on the same dialogMUST return a 500 response to the secondINVITE andMUST1926

include aRetry-After header field with a randomly chosen value of between 0 and 10 seconds. Similarly,1927

a UAS the receives anINVITE on a dialog while anINVITE it had sent on that dialog is in progressMUST1928

return a 500 response to the receivedINVITE andMUST include aRetry-After header field with a randomly1929

chosen value of between 0 and 10 seconds.1930

If a user agent receives a re-INVITE for an existing dialog itMUST check any version identifiers in the1931

session description or, if there are no version identifiers, the content of the session description to see if it has1932

changed. If the session description has changed, the user agent serverMUST adjust the session parameters1933

accordingly, possibly after asking the user for confirmation.1934



Versioning of the session description can be used to accommodate the capabilities of new arrivals to a conference,1935

add or delete media or change from a unicast to a multicast conference.1936

If a UAS generates a 2xx response and never receives anACK, it SHOULD generate a re-INVITE itself1937

with an offer equal to the last session description sent to the peer. The purpose of this is to ensure that both1938

caller and callee have a consistent view of the session parameters.1939

A UAS providing an offer in a 2xx (because theINVITE did not contain an offer)MUST offer the same1940

session description as last provided to the peer, with the exception of being able to change the IP address/port1941

if so desired.1942

Under error conditions (e.g., the UAS has crashed and restarted) the session description in the 2xx response for1943

an empty re-INVITE may be different than the one in use at that moment. If the new session description is not1944

acceptable for the UAC itSHOULD then send aBYE (afterACKing the 2xx response).1945

15 Terminating a Session1946

Terminating a session is done either with theBYE request, or theCANCEL request, depending on the state1947

of the dialog. Either caller or callee can terminate, and may do so for any reason. Sections 13 and 121948

document some cases where call termination is normative behavior. As a general rule, if a UA decides that1949

the session is to be terminated, itMUST follow the procedures here to initiate signaling action to convey that.1950

Note that both the session and the dialog between both user agents will be terminated.1951

When a UAC sends anINVITE request to create a session, if a 1xx response with a tag in theTo field1952

is received, an early dialog is created. When a 2xx response is received, the dialog becomes established.1953

For either state of the dialog, if the UAC desires to terminate the session, the UACSHOULD follow the1954

procedures described in Section 15.1.1 to terminate the session. If the callee for a new session wishes to1955

terminate the dialog, it uses the procedures of Section 15.1.1, butMUST NOT do so until it has receive an1956

ACK or until the server transaction times out.1957

This does not mean a user can’t hang up right away; it just means that the software in their phone needs to1958

maintain state for a short while in order to properly clean up.1959

OPEN ISSUE #202: Is this the right solution.1960

If the UAC desires to end the session before any type of dialog has been created, itSHOULD send a1961

CANCEL for the INVITE request that requested establishment of the session that is to be terminated. The1962

UAC constructs and sends theCANCEL following the procedures described in Section 9. ThisCANCEL1963

will normally result in a 487 response to be returned to theINVITE, indicating successful cancellation.1964

However, it is possible that theCANCEL and a 2xx response to theINVITE “pass on the wire”. In this case,1965

the UAC will receive a 2xx to theINVITE. It SHOULD then terminate the call by following the procedures1966

described in Section 15.1.1.1967

15.1 Terminating a Dialog with a BYE1968

15.1.1 UAC Behavior1969

A user agent client usesBYE request, sent within a dialog, to indicate to the server that it wishes to terminate1970

the session. This will also terminate the dialog. ABYE requestMAY be issued by either caller or callee. A1971

BYE requestSHOULD NOT be sent before the creation of a dialog (either early or established). In that case1972

the UACSHOULD follow the procedures described in Section 9 instead.1973

Proxies ensure that aCANCEL request is routed in the same way as theINVITE was. However, a proxy1974

performing load balancing may route aBYE without aRoute header field in a different way than theINVITE, since1975

both requests have differentCSeq sequence numbers.1976



The To, From, Call-ID, CSeq, andRequest-URI of a BYE are set following the same rules as for1977

regular requests sent within a dialog, described in Section 12.1978

Once theBYE is constructed, it creates a new non-INVITE client transaction, and passes it theBYE1979

request. The user agentSHOULD stop sending media as soon as theBYE request is passed to the client1980

transaction.1981

15.1.2 UAS Behavior1982

A UAS core receiving aBYE request checks to see if it matches an existing dialog. If theBYE does1983

not match an existing dialog, the UAS coreSHOULD generate a 481 response and pass that to the server1984

transaction.1985

A UAS core receiving aBYE request for an existing dialogMUST follow the procedures of Section1986

12.2.2 to process the request. Once done, the UASMUST cease transmitting media streams for the session1987

being terminated. The UAS coreMUST generate a 2xx response to theBYE, andMUST pass that to the1988

server transaction for transmission.1989

The UASMUST still respond to any pending requests received for that dialog, (which can only be an1990

INVITE). It is RECOMMENDED that a 487 (Request Terminated) response is generated to those pending1991

requests.1992

16 Proxy Behavior1993

16.1 Overview1994

SIP proxies are elements that route SIP requests to user agent servers and SIP responses to user agent clients.1995

A request may traverse several proxies on its way to a UAS. Each will make routing decisions, modifying1996

the request before forwarding it to the next element. Responses will route through the same set of proxies1997

traversed by the request in the reverse order.1998

It is important to note that being a proxy is a logical role for a SIP element. When a request arrives, an1999

element that can play the role of a proxy must first decide if it needs to respond to the request on its own.2000

For instance, the request could be malformed or the element may need credentials from the client before2001

acting as a proxy. The elementMAY respond with any appropriate error code. When responding directly to2002

a request, the element is playing the role of a UAS andMUST behave as described in Section 8.2.2003

A proxy can operate in either a stateful or stateless mode for each new request.2004

When stateless, a proxy acts as a simple forwarding element. It forwards each request downstream to2005

a single element determined by making a routing decision based on the request. It simply forwards every2006

response it receives upstream. A stateless proxy discards information about a message once it has been2007

forwarded.2008

On the other hand, a stateful proxy remembers information (specifically, transaction state) about each2009

incoming request and any requests it sends as a result of processing the incoming request. It uses this2010

information to affect the processing of future messages associated with that request. A stateful proxyMAY2011

chose to “fork” a request, routing it to multiple destinations. Any request that is forwarded to more than2012

one locationMUST be handled statefully. Any request processed using TCP (or any other mechanism that is2013

inherently stateful),MUST be handled statefully.2014

Much of the processing involved when acting statelessly or statefully for a request is identical. The next2015

several subsections are written from the point of view of a stateful proxy. The last section calls out those2016



places where a stateless proxy behaves differently.2017

16.2 Stateful Proxy2018

When stateful, a proxy is purely a SIP transaction processing engine. Its behavior is modeled here in terms of2019

the Server and Client Transactions defined in Section 17.A stateful proxy has a server transaction associated2020

with one or more client transactions by a higher layer proxy processing component (see figure 3), known as2021

a proxy core. An incoming request is processed by a server transaction. Requests from the server transaction2022

are passed to a proxy core. The proxy core determines where to route the request, choosing one or more2023

next-hop locations. An outgoing request for each next-hop location is processed by its own associated2024

client transaction. The proxy core collects the responses from the client transactions and uses them to send2025

responses to the server transaction.2026

A stateful proxy creates a new server transaction for each new request received. Any retransmissions of2027

the request will then be handled by that server transaction per Section 17.2028

Note that this is a model of proxy behavior, not of software. An implementation is free to take any2029

approach that replicates the external behavior this model defines.2030

clie

ntserver cl

ient

clie

nt

layerproxy "higher"

Figure 3: Stateful Proxy Model

For all new requests, including any with unknown methods, an element intending to proxy the request2031

MUST:2032

1. Validate the request (Section 16.3)2033



2. Make a routing decision (Section 16.4)2034

3. Forward the request to each chosen destination (Section 16.5)2035

4. Process all responses (Section 16.6)2036

16.3 Request Validation2037

Before an element can proxy a request, itMUST verify the message’s validity. A valid message must pass2038

the following checks:2039

1. Reasonable Syntax2040

2. Max-Forwards2041

3. Loop Detection2042

4. Proxy-Require2043

5. Proxy-Authorization2044

If any of these checks fail, the elementMUST behave as a user agent server (see Section 8.2) and respond2045

with an error code.2046

1. Reasonable Syntax check2047

The requestMUST be well-formed enough to be handled with a server transaction. Any components2048

involved in the remainder of these Request Validation steps or the Request Processing sectionMUST2049

be well-formed. Any other components, well-formed or not,SHOULD be ignored. For instance, an2050

elementSHOULD NOT reject a request because of a malformedDate header field.2051

This protocol is designed to be extended. Future extensions may define new methods and header fields2052

at any time. An elementMUST NOT refuse to proxy a request because it contains a method or header2053

field it does not know about.2054

2. Max-Forwards check2055

TheMax-Forwards header (Section 22.22) is used to limit the number of elements a SIP request can2056

traverse.2057

If the request does not contain aMax-Forwards header field, this check is passed.2058

If the request contains aMax-Forwards header field with a field value greater than zero, the check is2059

passed.2060

If the request contains aMax-Forwards header field with a field value of zero (0), the elementMUST2061

NOT forward the request. If the request was forOPTIONS, the elementMAY act as the final recipient2062

and respond per Section 11. Otherwise, the elementMUST return a 483 (Too many hops) response.2063

3. Loop Detection check2064

An elementMUST check for forwarding loops before forwarding a request. If the request contains a2065

Via header field value with A sent-by value that equals a value placed into previous requests by the2066



proxy, the request has been forwarded by this element before. The request has either looped or is2067

legitimately spiraling through the element. To determine if the request has looped, the elementMUST2068

perform thebranch parameter calculation described in Section 3 on this message and compare it to2069

the parameter received in thatVia field value. If the parameters match, the request has looped. If2070

they differ, the request is spiraling, and processing continues. If a loop is detected, the elementMUST2071

return a 482 (Loop Detected) response.2072

An elementMUST NOT forward a request to a multicast group which already appears in any of the2073

Via headers.2074

4. Proxy-Require check2075

Future extensions to this protocol may introduce features that require special handling by proxies.2076

Endpoints will include aProxy-Require header in requests that use these features, telling the proxy2077

it should not process the request unless the feature is understood.2078

If the request contains aProxy-Require header (Section 22.28) with one or more option-tags this2079

element does not understand, the elementMUST return a 420 (Bad Extension) response. The response2080

MUST include anUnsupported (Section 22.38) header field listing those option-tags the element did2081

not understand.2082

5. Proxy-Authorization check2083

If an element requires credentials before forwarding a request, the requestMUST be inspected as2084

described in Section 20.2.3. That section also defines what the element must do if the inspection fails.2085

16.4 Making a Routing Decision2086

At this point, the proxy must decide where to forward the request. This can be modeled as computing a set2087

of destinations for the request. This set will either be predetermined by the contents of the request or will2088

be obtained from an abstract location service. Each destination is represented as a URI and an optional IP2089

address, port and transport. This combination is referred to as a “next-hop location”.2090

First, the proxy core checks the received request forRoute headers. If anyRoute header fields are2091

present in the request, the elementMUST use the URL (including all of its parameters) from the topmost2092

Route header field as only next hop URI in the destination set, with no IP address, port and transport set for2093

that next hop. The destination set is complete, containingonly this URL, and the proxyMUST proceed to2094

the Request Processing of Section 16.5.2095

TheRoute mechanism is used to control the path a request takes through SIP elements, much like strict2096

IP source routing. The UAC will insertRoute header fields (see Section 12), usually based on information2097

provided by proxies throughRecord-Route header fields (see Section 6).2098

Assuming there were noRoute headers in the received request, the proxy checks theRequest-URI of2099

the received request. If it has an maddr parameter, and that parameter does not indicate an interface the2100

proxy is listening on, theRequest-URI MUST be placed into the destination set as the only next hop URI,2101

with no IP address, port and transport set for that next hop, and the proxyMUST proceed to Section 16.5.2102

If the maddr parameter was present, but did indicate an interface the proxy is listening on, the proxyMUST2103

strip the maddr and continue processing as if no maddr were present.2104

OPEN ISSUE #213: Do we strip just the maddr, or the port and transport as well?2105



OPEN ISSUE #218: Are we really sure this ordering of precedence ofRoute, maddr, and domain is correct??2106

It is not yet clear. This needs resolution asap finally, since it affects things like loose source routing, outbound proxy2107

processing at a UA, and so on.2108

If the domain of theRequest-URI indicates a domain this element is not responsible for, itSHOULD set2109

the next hop URI to theRequest-URI, and leave the IP address, port and transport of the next hop empty.2110

That next hopsMUST be placed into the destination set as the only next hop, and the elementMUST proceed2111

to the task of Request Processing (Section 16.5.2112

There are many circumstances in which a proxy might receive a request for a domain it is not responsible for.2113

A firewall proxy handling outgoing calls (the way HTTP proxies handle outgoing requests) is an example of where2114

this is likely to occur.2115

If the destination set for the request has not been predetermined as described above, this implies that the2116

element is responsible for the domain in theRequest-URI, and the elementMAY use whatever mechanism2117

it desires to determine where to send the request. Any of these mechanisms can be modeled as accessing2118

an abstract Location Service. This may consist of obtaining information from a location service created2119

by a SIP Registrar, reading a database, consulting a presence server, utilizing other protocols, or simply2120

performing an algorithmic substitution on theRequest-URI. The output of these mechanisms is used to2121

construct the destination set.2122

Any information in or about the request or the current environment of the elementMAY be used in the2123

construction of the destination set. For instance, different sets may be constructed depending contents or2124

presence of header fields and bodies, the time of day of the request’s arrival, the interface on which the2125

request arrived, failure of previous requests, or even the element’s current level of utilization.2126

As potential destinations are located through these services, their next hops are added to the destination2127

set. Next-hop locations may only be placed in the destination set once. If a next-hop location is already2128

present in the set (based on the definition of equality for the URI type and equality of the optional parame-2129

ters), itMUST NOT be added again.2130

A proxy MAY continue to add destinations to the set after beginning Request Processing. ItMAY use any2131

information obtained during that processing to determine new locations. For instance, a proxy may choose2132

to incorporate contacts obtained in a redirect response (3xx class) into the destination set. If a proxy uses a2133

dynamic source of information while building the destination set (for instance, if it consults a SIP Registrar),2134

it SHOULD monitor that source for the duration of processing the request. New locationsSHOULD be added2135

to the destination set as they become available. As above, any given URIMUST NOT be added to the set2136

more than once.2137

Allowing a URI to be added to the set only once reduces unnecessary network traffic, and in the case of incor-2138

porating contacts from redirect requests prevents infinite recursion.2139

An example trivial location service is achieved by configuring an element with a default outbound des-2140

tination. All requests are forwarded to this location. TheRequest-URI of the request is placed in the2141

destination set with the optional next-hop IP address, port and transport parameters set to the default out-2142

bound destination. The destination set is complete, containingonly this URI, and the element proceeds to2143

the task of Request Processing.2144

If the Request-URI indicates a resource at this proxy that does not exist, the proxyMUST return a 4042145

(Not Found) response.2146

If the destination set remains empty after applying all of the above, the proxyMUST return an error2147

response, whichSHOULD be the 480 (Temporarily Unavailable) response.2148



16.5 Request Processing2149

As soon as the destination set is non-empty, a proxyMAY begin forwarding the request. A stateful proxy2150

MAY process the set in any order. ItMAY process multiple destinations serially, allowing each client transac-2151

tion to complete before starting the next. ItMAY start client transactions with every destination in parallel. It2152

alsoMAY arbitrarily divide the set into groups, processing the groups serially and processing the destinations2153

in each group in parallel.2154

A common ordering mechanism is to use the qvalue parameter of destinations obtained from Contact2155

header fields (see Section 22.10). Destinations are processed from highest qvalue to lowest. Destinations2156

with equal qvalues may be processed in parallel.2157

A stateful proxy must have a mechanism to maintain the destination set as responses are received and2158

associate the responses to each forwarded request with the original request. For the purposes of this model,2159

this mechanism is a “response context” created by the proxy layer before forwarding the first request.2160

For each destination, the proxy forwards the request following these steps:2161

1. Make a copy of the received request2162

2. Update the Request-URI2163

3. Add a Via header field value2164

4. Update the Max-Forwards field if present2165

5. Update the Route header field if present2166

6. Optionally add a Record-route header field value2167

7. Optionally add additional headers2168

8. send the new request2169

Each of these steps is detailed below:2170

1. Copy request2171

The proxy starts with a copy of the received request. The copyMUST initially contain all of the header2172

fields from the received request. Only those fields detailed in the processing described below may be2173

removed. The copySHOULD maintain the ordering of the header fields as in the received request. The2174

proxy MUST NOT reorder field values with a common field name (See Section 7.3.1).2175

An actual implementation need not perform a copy; the primary requirement is that the processing of each2176

next hop begin with the same request.2177

2. Request-URI2178

TheRequest-URI in the copy’s start lineMUST be replaced with the URI for this destination. If the2179

URI contains any parameters not allowed in a Request-URI, theyMUST be removed.2180

This is the essence of a proxy’s role. This is the mechanism through which a proxy routes a request2181

toward its destination.2182



3. Via2183

The proxyMUST insert aVia header field into the copy before the existingVia header fields. TheVia2184

header maddr, ttl, and sent-by components will be set when the request is processed by the transport2185

layer (Section 19). TheVia headers ensure that responses will follow the same set of elements that2186

the request traversed.2187

The proxyMUST include a “branch” parameter (Section 22.40) in theVia header. When the path of2188

a request through one or more forking proxies is graphed, the result is a tree. The branch parameter2189

identifies the “branch” each request was forwarded on. Thebranch parameter valueMUST be unique2190

for each client transaction to which the request is forwarded. The precise format of thebranch. token2191

is implementation-defined. In order to be able to both detect loops and associate responses with the2192

corresponding request, the parameterSHOULD consist of two parts separable by the implementation.2193

The first part is used to detect loops and distinguish loops from spirals. The second is used to match2194

responses to requests.2195

Loop detection is performed by verifying that those fields having an impact on the routing decision2196

have not changed. The value placed in the this part of thebranch parameterSHOULD reflect all of2197

those fields (which include anyProxy-Require andProxy-Authorization headers). This is to ensure2198

that if the request is routed back to the proxy, and one of those fields changes, it is treated as a spiral2199

and not a loop (Section 3). A common way to create this value is to compute a cryptographic hash2200

of theTo, From, Call-ID header fields, theRequest-URI of the request received (before translation)2201

and the sequence number from theCSeq header field, in addition to anyProxy-Require andProxy-2202

Authorization fields that may be present. The algorithm used to compute the hash is implementation-2203

dependent, but MD5 [23], expressed in hexadecimal, is a reasonable choice. (Note that base64 is not2204

permissible for atoken.)2205

In order to correctly match responses to requests (Section 17.1.3), the valueSHOULD also contain a2206

part that is a globally unique function of of the branch on which this request will be forwarded. One2207

example is a hash of a sequence number, local IP address andrequest-URI of the request2208

For example:7a83e5750418bce23d5106b4c06cc632.12209

The “branch” parameterMUST depend on all information used for routing decisions, including the incom-2210

ing request-URI and any header values affecting the routing choices. This is necessary to distinguish looped2211

requests from requests whose routing parameters have changed before returning to this server.2212

Note that the request methodMUST NOT be included in the calculation of thebranch parameter.2213

In particular,CANCEL andACK requestsMUST have the samebranch value as the corresponding2214

request they cancel or acknowledge. Thebranch parameter is used in correlating those requests at2215

server handling them (see Section 17.2.3 and 9.2).2216

4. Max-Forwards2217

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

5. Route2219

If the copy contains a Route header field, the proxy must remove the first (topmost) value. Note that2220

this value was placed in the destination set and then into theRequest-URI of this copy in previous2221

steps.2222



6. Record-Route2223

If this proxy wishes to request to remain on the path of future requests in this dialog, itMUST insert a2224

Record-Route header value (Section refsec:record-route) into the copy before any existingRecord-2225

Route header values. See Section 12 for details on whether this request will be honored. Each proxy2226

in the path of a request makes this request independently the presence of a Record-Route header does2227

not obligate this proxy to add a value.2228

If the request is honored, the information the proxy places in theRecord-Route header value will be2229

used at the endpoints to constructRoute headers. As shown in the processing steps above,Route2230

headers determine forwarding destinations much like strict IP source routing.2231

The URL placed in theRecord-Route header valueMUST be a SIP URL. This URLMAY be dif-2232

ferent for each destination the request is forwarded to. The URLSHOULD NOT contain the transport2233

parameter unless the proxy has knowledge (such as in a private network) that the next downstream2234

element that will be in the path of subsequent requests supports that transport.2235

The URL this proxy provides will be used by some other element to make a routing decision. This proxy, in2236

general, has no way to know what the capabilities of that element are, so it must restrict itself to the mandatory2237

elements of a SIP implementation: SIP URLs and UDP transports.2238

The URL placed in theRecord-Route header valueMUST resolve to this element when the server2239

location procedures of Section 24are applied to it. This ensures subsequent requests are routed back2240

to this element.2241

The URL placed in theRecord-Route header valueSHOULD be such that if a subsequent request is2242

received with this URL in theRequest-URI, the proxy’s normal request processing will cause it to be2243

forwarded to one of the previous elements, including the originating client, traversed by the original2244

request. This improves robustness, ensuring that theRequest-URI contains enough information to2245

forward subsequent requests to a reasonable destination even in the absence ofRoute headers.2246

The URL placed in theRecord-Route header valueMUST vary with theRequest-URI in the received2247

request. A request may legitimately pass through this proxy more than once on the way to its final2248

destination (this is called a spiraling request). TheRequest-URI will be different each time the2249

request passes through. If this proxy places the same URL in the Record-Route header field each2250

time, subsequent requests will be rejected as looped requests. It is insufficient to simply copy the2251

Request-URI from each request into the Record-Route header. Some modification, such as adding2252

an maddr parameter, is necessary.2253

URLs satisfying the above paragraphs can be constructed in many ways. One way is to use a URL2254

that is nearly the same as theContact header in the initial request (if present, else theFrom field),2255

but with the maddr and port set to resolve to the proxy, and with a transaction identifier added to the2256

user part of the request-URI (in order to meet the requirement that the URL in theRecord-Route2257

be different for each distinctRequest-URI). A call stateful proxy could use a URL of the form2258

sip:proxy.example.com and use information from the stored call state to meet the requirements.2259

The proxyMAY include Record-Route header parameters in the value it provides. These will be2260

returned in some responses to the request (200 responses toINVITE for example) and may be useful2261

for pushing state into the message.2262

TheRecord-Route process is designed to work for any SIP request that initiates a dialog. The only2263

such request in this specification isINVITE. Extensions to the protocolMAY define others, and the2264



mechanisms described here will apply. The request that initiates a dialog and all refreshes (re-INVITE2265

for example)MUST haveRecord-Route header values added to them if the proxy wishes to remain2266

in the request path. This means a proxy will often need to record-route requests that containRoute2267

headers. Section 12 describes how this will affect a dialog.2268

Including Record-Route even when Route headers already exist in a request improves robustness in the2269

presence of a preloadedRoute header field and recovery from endpoint failure.2270

If a proxy needs to be in the path of any type of dialog (such as one straddling a firewall), itSHOULD2271

add aRecord-Route header value to every request with a method it doesn’t understand.2272

Generally, the choice about whether to record-route or not is a tradeoff of features vs. performance.2273

Faster request processing and higher scalability is achieved when proxies do not record route. How-2274

ever, provision of certain services may require a proxy to observe all messages in a dialog. It is2275

RECOMMENDED that proxies do not automatically record route. They should do so only if specifi-2276

cally required.2277

7. Adding Additional Headers2278

The proxyMAY add any other appropriate headers to the copy at this point.2279

8. Forward Request2280

A stateful proxy creates a new client transaction for this request as described in Section 17.1. If2281

the next-hop location used in building this request contains the optional addressing parameters, the2282

transaction is instructed to send the request based on those parameters. Otherwise, the proxy uses2283

the procedures of Section 24 to compute an ordered set of addresses from theRequest-URI, and2284

as described there, attempts to contact the first one by instructing the client transaction to send the2285

request there. If this fails, the stateful proxy continues down the list. Each attempt is a new client2286

transaction, and therefore represents a new branch, so that the processing described above for each2287

branch would need to be repeated. This results in a requirement to use a different branch ID parameter2288

for each attempt.2289

16.6 Response Processing2290

When a response is received by an element, it first tries to locate a client transaction (Section 17.1.3) match-2291

ing the response. If none is found, the elementMUST process the response (even if it is an informational2292

response) as a stateless proxy (described below). If a match is found, the response is handed to the client2293

transaction.2294

Forwarding responses for which a client transaction (or more generally any knowledge of having sent an asso-2295

ciated request) is not found improves robustness. In particular, it ensures that “late” 2xx class responses to INVITE2296

requests are forwarded properly.2297

As client transactions pass responses to the proxy layer, the following processingMUST take place:2298

1. Find the appropriate response context2299

2. Remove the topmost Via2300

3. Add the response to the response context2301



4. Check to see if this response should be forwarded2302

The following processingMUST be performed on each response that is forwarded. Note that more than2303

one response to each request will likely be forwarded - each provisional and one final at the least.2304

1. Aggregate authorization header fields if necessary2305

2. Forward the response2306

3. Generate any necessaryCANCEL requests2307

If no final response has been forwarded after every client transaction associated with the response context2308

has been terminated, the proxy must choose and forward the “best” response from those it has seen so far.2309

Each of the above steps are detailed below:2310

1. Find Context2311

The proxy locates the “response context” it created before forwarding the original request using the2312

key described in Section 16.5. The remaining processing steps take place in this context.2313

2. Via2314

The proxy removes the topmostVia field value from the response. The address in this value necessar-2315

ily matches the proxy since the response matched a client transaction above. The branch parameter2316

from this value can be used to determine which branch the response corresponds to.2317

If no Via field values remain in the response, the response was meant for this element andMUST2318

NOT be forwarded. The remainder of the processing described in this section is not performed on this2319

message. This will happen, for instance, when the element generatesCANCEL requests as described2320

in Section sec:proxy-response-processing-cancel.2321

3. Add response to context2322

Final responses received are stored in the response context until a final response is generated on2323

the server transaction associated with this context. The response may a candidate for the best final2324

response to be returned on that server transaction. Information from this response may be needed in2325

forming the best response even if this response is not chosen.2326

If the proxy chooses to recurse on a 3xx class response, itMUST NOT add the response to the response2327

context2328

4. Check response for forwarding2329

Until a final response has been sent on the server transaction, the following responsesMUST be for-2330

warded immediately:2331

• Any provisional response other than 100 Trying2332

• Any 2xx response2333

If a 6xx response is received, it is not immediately forwarded, but the stateful proxySHOULD cancel2334

all pending transactions as described in Section 9.2335



This is a change from RFC2543, which mandated that the 6xx be forwarded immediately. The problem2336

with this is that it is possible for a 2xx to arrive on another branch, in which case the proxy would have to2337

forward that in the case of anINVITE transaction. The result is that the UAC could receive a 6xx followed by2338

a 2xx, which should never be allowed to happen. So, instead, upon receiving a 6xx, a proxy willCANCEL,2339

which will generally result in 487s to all outstanding client transactions, and then at that point the 6xx is2340

forwarded upstream.2341

After a final response has been sent on the server transaction, the following responsesMUST be for-2342

warded immediately:2343

• Any 2xx class response to anINVITE request2344

A stateful proxyMUST NOT immediately forward any other responses. In particular, a stateful proxy2345

MUST NOT forward any 100 Trying response. Those responses that are candidates for forwarding later2346

as the “best” response have been gathered as described in step “Add Response to Context”.2347

Any response chosen for immediate forwardingMUST be processed as described in steps “Aggregate2348

authorization headers” through “Record-Route”.2349

5. Choosing the best response2350

A stateful proxyMUST send a final response to a response context’s server transaction if no final2351

responses have been immediately forwarded by the above rules and all client transactions in this2352

response context have been terminated.2353

The stateful proxyMUST choose the “best” final response among those received and stored in the2354

response context.2355

If there are no final responses in the context, the proxyMUST send a 408 (Request Timeout) response2356

to the server transaction.2357

Otherwise, the proxyMUST forward one of the responses from the lowest response class stored in the2358

response context. The proxyMAY select any response within that lowest class. The proxySHOULD2359

give preference to responses that provide information affecting resubmission of this request, such as2360

401, 407, 415, 420, and 484.2361

A proxy which receives a 503 responseSHOULD NOTforward it upstream unless it can determine that2362

any subsequent requests it might proxy will also generate a 503. In other words, forwarding a 5032363

means that the proxy knows it cannot service any requests, not just the one for theRequest-URI in2364

the request which generated the 503.2365

The forwarded responseMUST be processed as described in steps “Aggregate authorization headers”2366

through “Record-Route”.2367

For example, if a proxy forwarded a request to 4 locations, and received 503, 407, 501, and 4042368

responses, it may choose to forward the 407 response.2369

The tag in theTo header field serves to distinguish responses at the UAC. If the forwarded response2370

did not have one, itMUST NOT be inserted into the response by the proxy.2371

6. Aggregate authorization headers2372

If the selected response is a 401 or 407, the proxyMUST collect anyWWW-Authenticate andProxy-2373

Authenticate header fields from all other 401 and 407 responses received so for in this response2374

context and add them to this response before forwarding.2375



This is necessary because any or all of the destinations the request was forwarded to may have re-2376

quested credentials. The client must receive all of those challenges and supply credentials for each of2377

them when it retries the request. Motivation for this behavior is provided in Section 20.2378

7. Record-Route2379

If the selected response contains aRecord-Route header field value originally provided by this proxy,2380

the proxyMAY chose to rewrite the value before forwarding the response. This allows the proxy to2381

provide different URLs for itself to the next upstream and downstream elements. A proxy may choose2382

to use this mechanism for any reason. For instance, it is useful for multi-homed hosts.2383

The new URL provided by the proxyMUST satisfy the same constraints on URLs placed inRecord-2384

Route header fields in requests (see Section 6) with the following modifications:2385

The URLSHOULD NOT contain the transport parameter unless the proxy has knowledge that the next2386

upstream (as opposed to downstream) element that will be in the path of subsequent requests supports2387

that transport.2388

The URL placed in theRecord-Route header valueSHOULD be such that if a subsequent request is2389

received with this URL in theRequest-URI, the proxy’s normal request processing will cause it to2390

be forwarded to the same next-hop element (as opposed to some previous element) as the originally2391

forwarded request.2392

When a proxy does decide to modify theRecord-Route header in the response, one of the operations2393

it must perform is to locate theRecord-Route that it had inserted. If the request spiraled, and the2394

proxy inserted aRecord-Route in each iteration of the spiral, locating the correct header in the2395

response (which must be the proper iteration in the reverse direction) is tricky. Note that the rules2396

above dictate that a proxy insert a different URI into theRecord-Route for each distinctRequest-2397

URI received. The two issues can be solved jointly. ARECOMMENDED mechanism is for the proxy2398

to append a piece of data to the user portion of the URL. This piece of data is a hash of the transaction2399

key for the incoming request, concatenated with a unique identifier for the proxy instance. Since the2400

transaction key includes theRequest-URI, this key will be unique for each distinctRequest-URI.2401

When the response arrives, the proxy modifies the firstRecord-Route whose identifier matches the2402

proxy instance. The modification results in a URI without this piece of data appended to the user2403

portion of the URI. Upon the next iteration, the same algorithm (find the topmostRecord-Route2404

header with the parameter) will correctly extract the nextRecord-Route header inserted by that2405

proxy.2406

8. Forward response2407

After performing the processing described in steps “Aggregate authorization headers” through “Record-2408

Route”, the proxy may perform any feature specific manipulations on the selected response. Unless2409

otherwise specified, the proxyMUST NOT remove the message body or any header values other than2410

the Via header value discussed in Section refsec:proxy-response-processing-via. The proxyMUST2411

pass the response to the server transaction associated with the response context. This will result in2412

the response being sent to the location now indicated in the topmostVia field value. If the server2413

transaction is no longer available to handle the transmission, the elementMUST forward the response2414

statelessly by sending it to the server transport.2415

Even after forwarding a final response, the proxyMUST maintain the response context until all of its2416

associated transactions have been terminated.2417



9. GenerateCANCELs2418

OPEN ISSUE #7: If CANCEL is restricted to INVITE only, this behavior must restrict itself to2419

INVITE requests.2420

OPEN ISSUE #122: TheMUST below reflects list discussion, but the question of how strong this2421

requirement should be was not formally closed.2422

If the forwarded response was a final response, the proxyMUST generate aCANCEL request for all2423

pending client transactions associated with this response context. A proxySHOULD also generate a2424

CANCEL request for all pending client transactions associated with this response context when it2425

receives a 6xx response. A pending client transaction is one that has received a provisional response,2426

but no final response and has not had an associatedCANCEL generated for it. GeneratingCANCEL2427

requests is described in Section 9.1.2428

16.7 Handling transport errors2429

If the transport layer notifies a proxy of an error when it tries to forward a request (see Section 19.4), the2430

proxy MUST behave as if the forwarded request received a 400 response.2431

If the proxy is notified of an error when forwarding a response, it drops the response. The proxySHOULD2432

NOT cancel any outstanding client transactions associated with this response context due to this notification.2433

If a proxy cancels its outstanding client transactions, a single malicious or misbehaving client can cause all2434

transactions to fail through its Via header field.2435

16.8 CANCEL Processing2436

A stateful proxy may generate aCANCEL to any other request it has generated at any time. For instance,2437

it may choose to generateCANCELs based on having a transaction exceed the time specified in theEx-2438

pire header of certain requests, or as a result of any logic it applies while forwarding requests. A proxy2439

MUST cancel any pending client transactions associated with a response context when it receives a matching2440

CANCEL request.2441

OPEN ISSUE #185: Should generating CANCEL at a proxy based on Expires in INVITE be deprecated?2442

While aCANCEL request is handled in a stateful proxy by its own server transaction, a new response2443

context is not created for it. Instead, the proxy layer searches its existing response contexts for the server2444

transaction handling the request associated with thisCANCEL. If a matching response context is found, the2445

elementMUST immediately return a 200 OK response to theCANCEL request. In this case, the element is2446

acting as a user agent server as defined in Section 8.2. Furthermore, the elementMUST generateCANCEL2447

requests for all pending client transactions in the context as described in Section 9.2448

If a response context is not found, the element does not have any knowledge of the request to apply2449

theCANCEL to. It MUST forward theCANCEL request statelessly (it may have statelessly forwarded the2450

associated request previously).2451

16.9 Stateless proxy2452

When acting statelessly, a proxy is a simple message forwarder. Much of the processing performed when2453

acting statelessly is the same as when behaving statefully. The differences are detailed here.2454



A stateless proxy does not have any notion of a transaction, or of the response context used to describe2455

stateful proxy behavior. Instead, the stateless proxy takes messages, both requests and responses, directly2456

from the transport layer (See section 19). As a result, stateless proxies do not retransmit messages on their2457

own. They do, however, forward all retransmission they receive (they do not have the ability to distinguish2458

a retransmission from the original message). Furthermore, when handling a request statelessly, an element2459

MUST NOT generate its own 100 Trying (or any other provisional) response.2460

A stateless proxy must validate a request as described in Section 16.32461

A stateless proxy must make a routing decision as described in Section 16.4 with the following excep-2462

tion:2463

• A stateless proxyMUST choose one and only one destination from the destination set. This choice2464

MUST only rely on fields in the message and time-invariant properties of the server. In particular, a2465

retransmitted requestMUST be forwarded to the same destination each time it is processed. Further-2466

more,CANCEL and non-RoutedACK requestsMUST generate the same choice as their associated2467

INVITE.2468

A stateless proxy must process the request before forwarding as described in Section 16.5 with the2469

following exceptions:2470

• Thebranch parameter on the insertedVia header fieldMUST be the same each time a retransmitted2471

request is forwarded. Thus for a stateless proxy, thebranch parameter calculationMUST only depend2472

on message parameters affecting the routing of the request which are invariant on retransmission.2473

• The request is sent directly to the transport layer instead of through a client transaction. If the next-2474

hop destination parameters don’t provide an explicit destination, the element applies the procedures2475

of Section 24 to theRequest-URI to determine where to send the request.2476

Stateless proxiesMUST NOT perform special processing forCANCEL requests. They are processed by2477

the above rules as any other requests.2478

Response processing as described in Section 16.6 does not apply to a proxy behaving statelessly. When2479

a response arrives at a stateless proxy, the proxy inspects the address in the first (topmost)Via header value.2480

If that address matches the proxy, the proxyMUST remove that value from the response and forward the2481

result to the location indicated in the nextVia header value. Unless specified otherwise, the proxyMUST2482

NOT remove any other header values or the message body. If the address does not match the proxy, the2483

messageMUST be silently discarded.2484

17 Transactions2485

SIP is fundamentally a transactional protocol. This means that interactions between components take place2486

in a series of independent message exchanges. Specifically, a SIP transaction consists of a single request,2487

and any responses to that request (which include zero or more provisional responses and one or more final2488

responses). In the case of a transaction where the request was anINVITE (known as anINVITE transaction),2489

the transaction also includes theACK only if the final response was not a 2xx response. If the response was2490

a 2xx, theACK is not considered part of the transaction.2491

The reason for this separation is rooted in the importance of delivering all 200 OK responses to anINVITE to2492

the UAC. To deliver them all to the UAC, the UAS alone takes responsibility for retransmitting them, and the UAC2493

alone takes responsibility for acknowledging them withACK. Since thisACK is retransmitted only by the UAC, it2494

is effectively considered its own transaction.2495



Transactions have a client side and a server side. The client side is known as a client transaction, and the2496

server side, as a server transaction. The client transaction sends the request, and the server transaction sends2497

the response. The client and server transactions are logical functions that are embedded in any number of2498

elements. Specifically, they exist within user agents and stateful proxy servers. Consider the example of2499

Section 4. In this example, the UAC executes the client transaction, and its outbound proxy executes the2500

server transaction. The outbound proxy also executes a client transaction, which sends the request to a2501

server transaction in the inbound proxy. That proxy also executes a client transaction, which in turn, sends2502

the request to a server transaction in the UAS. This is shown pictorially in Figure 4.2503

+−−−−−−−−−+ +−−−−−−−−−+ +−−−−−−−−−+ +−−−−−−−−−+ | +−+|Request |+−+ +−+|Request |+−+ +−+|Request |+−+ | | |C||−−−−−−−>||S| |C||−−−−−−−>||S| |C||−−−−−−−>||S| | | |l|| ||e| |l|| ||e| |l|| ||e| | | |i|| ||r| |i|| ||r| |i|| ||r| | | |e|| ||v| |e|| ||v| |e|| ||v| | | |n|| ||e| |n|| ||e| |n|| ||e| | | |t|| ||r| |t|| ||r| |t|| ||r| | | | || || | | || || | | || || | | | |T|| ||T| |T|| ||T| |T|| ||T| | | |r|| ||r| |r|| ||r| |r|| ||r| | | |a|| ||a| |a|| ||a| |a|| ||a| | | |n|| ||n| |n|| ||n| |n|| ||n| | | |s||Response||s| |s||Response||s| |s||Response||s| | | +−+|<−−−−−−−|+−+ +−+|<−−−−−−−|+−+ +−+|<−−−−−−−|+−+ | +−−−−−−−−−+ +−−−−−−−−−+ +−−−−−−−−−+ +−−−−−−−−−+ UAC Outbound Inbound UAS Proxy Proxy

Figure 4: Transaction relationships

A stateless proxy does not contain a client or server transaction. The transaction exists between the2504

UA or stateful proxy on one side of the stateless proxy, and the UA or stateful proxy on the other side.2505

As far as SIP transactions are concerned, stateless proxies are effectively transparent. The purpose of the2506

client transaction is to receive a request from the element the client is embedded in (call this element the2507

“Transaction User” or TU; it can be a UA or a stateful proxy), and reliably deliver the request to that server2508

transaction. The client transaction is also responsible for receiving responses, and delivering them to the2509

TU, filtering out any retransmissions or disallowed responses (such as a response toACK). In the case of2510

an INVITE transaction, that includes generation of theACK request for any final response excepting a 2xx2511

response.2512

Similarly, the purpose of the server transaction is to receive requests from the transport layer, and deliver2513

them to the TU. The server transaction filters any request retransmissions from the network. The server2514

transaction accepts responses from the TU, and delivers them to the transport layer for transmission over the2515

network. In the case of anINVITE transaction, it absorbs theACK request for any final response excepting2516

a 2xx response.2517

The 2xx response, and theACK for it, have special treatment. This response is retransmitted only by a2518



UAS, and itsACK generated only by the UAC. This end-to-end treatment is needed so that a caller knows2519

the entire set of users that have accepted the call. Because of this special handling, retransmissions of the2520

2xx response are handled by the UA core, not the transaction layer. Similarly, generation of theACK for the2521

2xx is handled by the UA core. Each proxy along the path merely forwards each 2xx response toINVITE,2522

and its correspondingACK.2523

17.1 Client transaction2524

The client transaction provides its functionality through the maintenance of a state machine.2525

The TU communicates with the client transaction through a simple interface. When the TU wishes to2526

initiate a new transaction, it creates a client transaction, and passes it the SIP request to send, a value for2527

timer C (described below), and an IP address, port, and transport to send it to. The client transaction begins2528

execution of its state machine. Valid responses are past up to the TU from the client transaction.2529

There are two types of client transaction state machines, depending on the method the request passed2530

by the TU. One handles client transactions forINVITE request. This type of machine is referred to as an2531

INVITE client transaction. Another type handles client transactions for all requests exceptINVITE and2532

ACK. This is referred to as a non-INVITE client transaction. There is no client transaction forACK. If the2533

TU wishes to send anACK, it passes one directly to the transport layer for transmission.2534

TheINVITE transaction is different from those of other methods because of its extended duration. Nor-2535

mally, human input is required in order to respond to anINVITE. The long delays expected for sending a2536

response argue for a three way handshake. Requests of other methods, on the other hand, are expected to2537

completely rapidly. In fact, because of its reliance on just a two way handshake, TUsSHOULD respond2538

immediately to non-INVITE requests. Protocol extensions which require longer durations for generation of2539

a response (such as a new method that does require human interaction)SHOULD instead use two transactions2540

- one to send the request, and another in the reverse direction to convey the result of the request.2541

17.1.1 INVITE Client Transaction2542

17.1.1.1 Overview ofINVITE Transaction TheINVITE transaction consists of a three-way handshake.2543

The client transaction sends anINVITE, the server transaction sends responses, and the client transaction2544

sends anACK. For unreliable transports (such as UDP), the client transaction will retransmit requests at an2545

interval that starts at T1 seconds and doubles after every retransmission. The request is not retransmitted over2546

reliable transports. After receiving a 1xx response, any retransmissions cease altogether, and the client waits2547

for further responses. The server transaction can send additional 1xx responses, which are not transmitted2548

reliably. Eventually, the server transaction decides to send a final response. For unreliable transports, that2549

response is retransmitted periodically, and for reliable transports, its sent once. For each final response that2550

is received at the client transaction, the client transaction sends anACK, the purpose of which is to quench2551

retransmissions of the response.2552

17.1.1.2 Formal Description The state machine for theINVITE client transaction is shown in Figure 5.2553

The initial state, “calling”,MUST be entered when the TU initiates a new client transaction with anINVITE2554

request. The client transactionMUST pass the request to the transport layer for transmission (see Section2555

19). If an unreliable transport is being used, the client transactionSHOULD start timer A with a value2556

of T1, andSHOULD NOT start timer A when a reliable transport is being used (Timer A controls request2557

retransmissions). For any transport, the client transactionMUST start timer B with a value of 64*T1 seconds2558



|INVITE from TU Timer A fires |INVITE sent Reset A, V Timer B fires INVITE sent +−−−−−−−−−−−+ t.o. to TU +−−−−−−−−−| |−−−−−−−−−−−−−−−+ | | Calling | | +−−−−−−−−>| |−−−−−−−−−−−−−−>| +−−−−−−−−−−−+ 2xx | 300−699 | | 2xx to TU | ACK sent | |1xx | +−−−−−−−−−−−−−−−+ |1xx to TU | | | | | 1xx V Timer C fires | | 1xx to TU −−−−−−−−−−−+ t.o. to TU | | +−−−−−−−−−| |−−−−−−−−−−−−−−>| | | |Proceeding | | | +−−−−−−−−>| |−−−−−−−−−−−−−−>| | +−−−−−−−−−−−+ 2xx | | 300−699 | 2xx to TU | | ACK sent, | | | resp. to TU| | | | | NOTE: | 300−699 V | | ACK sent +−−−−−−−−−−−+ | transitions | +−−−−−−−−−| | | labeled with | | | Completed | | the event | +−−−−−−−−>| | | over the action | +−−−−−−−−−−−+ | to take | ^ | | | | | Timer D fires | +−−−−−−−−−−−−−−+ | − | | | V | +−−−−−−−−−−−+ | | | | | Terminated|<−−−−−−−−−−−−−−+ | |

Figure 5:INVITE client transaction

(Timer B controls transaction timeouts).2559

When timer A fires, the client transactionSHOULD retransmit the request by passing it to the transport2560

layer, andSHOULD reset the timer with a value of 2*T1. When the timer fires 2*T1 seconds later, the2561

requestSHOULDbe retransmitted again (assuming the client transaction is still in this state). This process2562

SHOULDcontinue, so that the request is retransmitted with intervals that double after each transmission.2563

These retransmissionsSHOULDonly be done while the client transaction is in the “calling” state.2564

The default value for T1 is 500ms. T1 is an estimate of the RTT between the client and server transac-2565



tions. The optional RTT estimation procedure of Section 17.3MAY be followed, in which case the resulting2566

estimateMAY be used instead of 500ms. If no RTT estimation is used, other valuesMAY be used in private2567

networks where it is known that RTT has a different value. On the public Internet, T1MAY be chosen larger,2568

but SHOULD NOT be smaller.2569

If the client transaction is still in the “calling” when timer B fires, the client transactionSHOULD inform2570

the TU that a timeout has occurred. The client transactionMUST NOT generate anACK. The value of 64*T12571

is equal to the amount of time required to send seven requests in the case of an unreliable transport.2572

If the client transaction receives a provisional response while in the ”calling” state, it transitions to2573

the “proceeding” state. Upon entering this state, the client transactionMUST start timer C with the value2574

provided by the TU when the client transaction was created. This timeout dictates how long the client2575

transaction waits for a final response before giving up (i.e., roughly how long does it “let the phone ring”). In2576

the “proceeding” state, the client transactionSHOULD NOT retransmit the request any longer. Furthermore,2577

the provisional responseMUST be passed to the TU. Any further provisional responsesMUST be passed up2578

to the TU while in the “proceeding” state. When timer C fires, the client transactionMUST transition to the2579

terminated state, and itMUST inform the TU of the timeout.2580

When in either the ”calling” or “proceeding” states, reception of a response with status code from 300-2581

699 MUST cause the client transaction to transition to “completed”. The client transactionMUST pass the2582

received response up to the TU, and itMUST generate anACK request, even if the transport is reliable2583

(guidelines for constructing theACK from the response are given in Section 17.1.1.3) and then pass theACK2584

to the transport layer for transmission. TheACK MUST be sent to the same address, port and transport that2585

the original request was sent to. The client transactionSHOULD start timer D when it enters the “completed”2586

state, with a value of T3 seconds for unreliable transports, and zero seconds for reliable transports. T3 is2587

the total amount of time that the server transaction can remain in the “completed” state when unreliable2588

transports are used. For the default values of the timers below, this is 16 seconds.2589

OPEN ISSUE #210: Timer D should be based on the values of the timers selected at the server, but these values2590

aren’t known by the client. We could alternatively specify an absolute minimum.2591

Any retransmissions of the final response that are received while in the “completed” stateSHOULD cause2592

the ACK to be re-passed to the transport layer for retransmission, but the newly received responseMUST2593

NOT be passed up to the TU. A retransmission of the response is defined as any response which would match2594

the same client transaction, based on the rules of Section 17.1.3.2595

If timer D fires while the client transaction is in the “completed” state, the client transactionMUST move2596

to the terminated state, and itMUST inform the TU of the timeout.2597

When in either the “calling” or “proceeding” states, reception of a 2xx responseMUST cause the client2598

transaction to enter the terminated state, and the responseMUST be passed up to the TU. The handling of2599

this response depends on whether the TU is a proxy core or a UAC core. A UAC core will handle generation2600

of theACK for this response, while a proxy core will always forward the 200 OK upstream. The differing2601

treatment of 200 OK between proxy and UAC is the reason that handling of it does not take place in the2602

transaction layer.2603

The client transactionMUST be destroyed the instant it enters the terminated state. This is actually nec-2604

essary to guarantee correct operation. The reason is that 2xx responses to anINVITE are treated differently;2605

each one is forwarded by proxies, and theACK handling in a UAC is different. Thus, each 2xx needs to be2606

passed to a proxy core (so that it can be forwarded) and to a UAC core (so it can be acknowledged). No2607

transaction layer processing takes place. Whenever a response is received by the transport, if the transport2608

layer finds no matching client transaction (using the rules of Section 17.1.3, the response is passed directly2609

to the core. Since the matching client transaction is destroyed by the first 2xx, subsequent 2xx will find no2610



match and therefore be passed to the core.2611

17.1.1.3 Construction of theACK Request The ACK request constructed by the client transaction2612

MUST contain values for theCall-ID, From, and Request-URI which are equal to the values of those2613

headers in the request that created the client transaction (call this the “original request”). TheTo field in the2614

ACK MUST equal theTo field in the response being acknowledged, and will therefore usually differ from2615

theTo field in the original request by the addition of the tag parameter. TheACK MUST contain a singleVia2616

header, and thisMUST be equal to the topVia header of the original request. TheACK requestMUST NOT2617

contain anyRoute headers. TheCSeq header in theACK MUST contain the same value for the sequence2618

number as was present in the original request, but the method parameterMUST be equal to “ACK”.2619

These rules for construction ofACK only apply to the client transaction. A UAC core which generates2620

anACK for 2xx MUST instead follow the rules described in Section 13.2621

For example, consider the following request:2622


Via: SIP/2.0/UDP 10.1.3.32624


From: Alice <sip:[email protected]>;tag=88sja8x2626



TheACK request for a non-2xx final response to this request would look like:2629

ACK sip:[email protected] SIP/2.02630

Via: SIP/2.0/UDP 10.1.3.32631

To: Bob <sip:[email protected]>;tag=99sa0xk2632

From: Alice <sip:[email protected]>;tag=88sja8x2633


CSeq: 986759 ACK2635

17.1.2 non-INVITE Client Transaction2636

17.1.2.1 Overview of the non-INVITE Transaction non-INVITE transactions do not make use ofACK.2637

They are a simple request-response interaction. For unreliable transports, requests are retransmitted at an2638

interval which starts at T1, and doubles until it hits T2. If a provisional response is received, retransmis-2639

sions continue for unreliable transports, but at an interval of T2. The server transaction retransmits the last2640

response it sent (which can be a provisional or final response) only when a retransmission of the request is2641

received. This is why request retransmissions need to continue even after a provisional response, they are2642

what ensure reliable delivery of the final response.2643

Unlike anINVITE transaction, a non-INVITE transaction has no special handling for the 2xx response.2644

The result is that only a single 2xx response to a non-INVITE is ever delivered to a UAC.2645

17.1.2.2 Formal Description The state machine for the non-INVITE client transaction is shown in Fig-2646

ure 6. It is very similar to the state machine forINVITE.2647



|Request from app |send request Timer E V Timer F send request +−−−−−−−−−−−+ t.o. to TU +−−−−−−−−−| |−−−−−−−−−−−−−−−−−−−+ | | Trying | | +−−−−−−−−>| | | +−−−−−−−−−−−+ | 200−699 | | | resp. to TU | |1xx | +−−−−−−−−−−−−−−−+ |resp. to TU | | | | | Timer E V Timer F | | send req +−−−−−−−−−−−+ t.o.to TU | | +−−−−−−−−−| |−−−−−−−−−−−−−−−−−−>| | | |Proceeding | | | +−−−−−−−−>| |−−−−−+ | | +−−−−−−−−−−−+ |1xx | | | ^ |resp to TU | | 200−699 | +−−−−−−−−+ | | resp. to TU | | | | | | V | | +−−−−−−−−−−−+ | | | | | | | Completed | | | | | | | +−−−−−−−−−−−+ | | ^ | | | | | Timer K | +−−−−−−−−−−−−−−+ | − | | | V | NOTE: +−−−−−−−−−−−+ | | | | transitions | Terminated|<−−−−−−−−−−−−−−−−−−+ labeled with | | the event +−−−−−−−−−−−+ over the action to ta ke

Figure 6: non-INVITE client transaction

The “Trying” state is entered when the TU initiates a new client transaction with a request. When2648

entering this state, the client transactionSHOULD set Timer F to fire in T3 seconds. The requestMUST be2649

passed to the transport layer for transmission. If an unreliable transport is in use, the client transactionMUST2650

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 a2651



value of MIN(2*T1, T2). When the timer fires again, it is reset to a MIN(4*T1, T2). This process continues,2652

so that retransmissions occur with an exponentially increasing inverval that caps at T2. The default value2653

of T2 is 4s, and it represents the amount of time a non-INVITE server transaction will take to respond to a2654

request, if it does not respond immediately. For the default values of T1 and T2, this results in intervals of2655

500 ms, 1 s, 2 s, 4 s, 4 s, 4s, etc.2656

If Timer F fires while the client transaction is still in the “Trying” state, the client transactionSHOULD2657

inform the TU about the timeout, and then itSHOULDenter the “Terminated” state. If a provisional response2658

is received while in the “Trying” state, the responseMUST be passed to the TU, and then the client transaction2659

SHOULD move to the “Proceeding” state. If a final response (status codes 200-699) is received while in the2660

“Trying” state, the responseMUST be passed to the TU, and the client transactionMUST transition to the2661

“Completed” state.2662

If Timer E fires while in the “Proceeding” state, the requestMUST be passed to the transport layer2663

for retransmission, and Timer EMUST be reset with a value of T2 seconds. If timer F fires while in the2664

“Proceeding” state, the TUMUST be informed of a timeout, and the client transactionMUST transition to the2665

terminated state. If a final response (status codes 200-699) is received while in the “Proceeding” state, the2666

responseMUST be passed to the TU, and the client transactionMUST transition to the “Completed” state.2667

Once the client transaction enters the “Completed” state, itMUST set Timer K to fire in T4 seconds for2668

unreliable transports, and zero seconds for reliable transports. The “Completed” state exists to buffer any2669

additional response retransmissions that may be received (which is why the client transaction remains there2670

only for unreliable transports). T4 represents the amount of time the network will take to clear messages2671

between client and server transactions. The default value of T4 is 5s. A response is a retransmission when it2672

matches the same transaction, using the rules specified in Section 17.1.3. If Timer K fires while in this state,2673

the client transactionMUST transition to the “Terminated” state.2674

OPEN ISSUE #211: This special treatment for reliable transports, where the state machine transactions directly2675

to terminated, is new.2676

Once the transaction is in the terminated state, itMUST be destroyed. As with client transactions, this is2677

needed to ensure reliability of the 2xx responses toINVITE.2678

17.1.3 Matching Responses to Client Transactions2679

When the transport layer in the client receives a response, it has to figure out which client transaction will2680

handle the response, so that the processing of Sections 17.1.1 and 17.1.2 can take place.2681

A response matches a client transaction through a comparison process with fields in the request that2682

created the transaction. Specifically, theFrom, Call-ID, CSeq, and the topmostVia headerMUST match2683

the same fields in the request, using the matching operations for those headers defined in Section 22. If2684

the To field in the request had a tag, theTo field in the responseMUST match theTo field in the request,2685

as described in Section 22.37. However, if the To field in the request did not contain a tag, theTo field in2686

the responseMUST match that in the request, except that the tagMUST NOT be considered as part of the2687

matching process. This is needed since a UAS will add a tag to theTo field of the response.2688

17.1.4 Handling Transport Errors2689

When the client transaction sends a request to the transport layer to be sent, the following procedures are2690

followed if the transport layer indicates a failure.2691



The client transactionSHOULD inform the TU that a transport failure has occurred, and the client trans-2692

actionSHOULD transition directly to the terminated state.2693

17.2 Server Transaction2694

The server transaction is responsible for the delivery of requests to the TU, and the reliable transmission of2695

responses. It accomplishes this through a state machine. Server transactions are created by the core when a2696

request is received, and transaction handling is desired for that request (this won’t always be the case).2697

As with the client transactions, the state machine depends on whether the received request is anINVITE2698

request or not.2699

17.2.1 INVITE Server Transaction2700

The state diagram for theINVITE server transaction is shown in Figure 7.2701

When a server transaction is constructed with a request, it enters the “Proceeding” state. The server2702

transactionMUST generate a 100 response (not any status code - the specific value of 100) unless it knows2703

that the TU will generate a provisional or final response within 200 ms, in which case itMAY generate a 1002704

response. This provisional response is needed to rapidly quench request retransmissions in order to avoid2705

network congestion. The requestMUST be passed to the TU.2706

The TU passes any number of provisional responses to the server transaction. So long as the server2707

transaction is in the “Proceeding” state, each of theseMUST be passed to the transport layer for transmis-2708

sion. They are not sent reliably (they are not retransmitted), and do not cause a change in the state of the2709

server transaction. If a request retransmission is received while in the “Proceeding” state, the most recent2710

provisional response that was received from the TUMUST be passed to the transport layer for retransmis-2711

sion. A request is a retransmission if it matches the same server transaction based on the rules of Section2712

17.2.3.2713

If, while in the “proceeding” state, the TU passes a 2xx Response to the server transaction, the server2714

transactionMUST pass this response to the transport layer for transmission. It is not retransmitted by the2715

server transaction; retransmissions of 2xx responses are handled by the TU. The server transactionMUST2716

then transition to the “terminated” state.2717

While in the “Proceeding” state, if the TU passes a response with status code from 300 to 699 to the2718

server transaction, the responseMUST be passed to the transport layer for transmission, and the state machine2719

MUST enter the “Completed” state. For unreliable transports, timer G is set to fire in T1 seconds, and is not2720

set to fire for reliable transports.2721

This is a change from RFC2543, where responses were always retransmitted, even over reliable transports.2722

When the “Completed” state is entered, timer HMUST be set to fire in 64*T1 seconds, for all transports.2723

Timer H determines when the server transaction gives up retransmitting the response. Its value is chosen to2724

equal Timer B, the amount of time a client transaction will continue to retry sending a request. If timer G2725

fires, the response is passed to the transport layer once more for retransmission, and timer G is set to fire in2726

MIN(2*T1, T2) seconds. From then on, when timer G fires, the response is passed to the transport again for2727

transmission, and timer G is reset with a value that doubles, unless that value exceeds T2, in which case it2728

is reset with the value of T2. This is identical to the retransmit behavior for requests in the “Trying” state of2729

the non-INVITE client transaction. Furthermore, while in the “completed” state, if a request retransmission2730

is received, the server SHOULD pass the response to the transport for retransmission.2731



|INVITE |pass to TU, send 100 INVITE V send response+−−−−−−−−−−−+ +−−−−−−−−| |−−−−−−−−+101−199 from TU | | Proceeding| |send response +−−−−−−−>| |<−−−−−−−+ +−−−−−−−−−−−+ 300−699 from TU | |2xx from TU send response | |send response | +−−−−−−−−−−−−−−−−−−−+ | | INVITE V Timer G fires | send response+−−−−−−−−−−−+ send response | +−−−−−−−−| |−−−−−−−−+ | | | Completed | | | +−−−−−−−>| |<−−−−−−−+ | +−−−−−−−−−−−+ | | | | ACK | | | − | +−−−−−−−−−−−−−−−−−−>+ | Timer H fires | V fail to TU | +−−−−−−−−−−−+ | | | | | Confirmed | | | | | +−−−−−−−−−−−+ | | | |Timer I fires | |− | | | V | +−−−−−−−−−−−+ | | | | | Terminated|<−−−−−−−−−−−−−−−+ | | +−−−−−−−−−−−+

Figure 7:INVITE server transaction

If an ACK is received while the server transaction is in the “Completed” state, the server transaction2732

MUST transition to the “confirmed” state. As Timer G is ignored in this state, any retransmissions of the2733

response will cease.2734

If timer H fires while in the “Completed” state, it implies that theACK was never received. In this case,2735

the server transactionMUST transition to the terminated state, andMUST indicate to the TU that a transaction2736

failure has occurred.2737



The purpose of the “confirmed” state is to absorb any additionalACK messages that arrive, triggered2738

from retransmissions of the final response. When this state is entered, timer I is set to fire in T4 seconds for2739

unreliable transports, and zero seconds for reliable transports. Once timer I fires, the serverMUST transition2740

to the “Terminated” state.2741

Once the transaction is in the terminated state, itMUST be destroyed. As with client transactions, this is2742

needed to ensure reliability of the 2xx responses toINVITE.2743

17.2.2 non-INVITE Server Transaction2744

The state machine for the non-INVITE server transaction is shown in Figure 8.2745

The state machine is initialized in the “Trying” state, and is passed a request other thanINVITE or2746

ACK when initialized. This request is passed up to the TU. Once in the “Trying” state, any further request2747

retransmissions are discarded. A request is a retransmission if it matches the same server transaction, using2748

the rules specified in Section 17.2.3.2749

While in the “Trying” state, if the TU passes a provisional response to the server transaction, the server2750

transactionMUST enter the “Proceeding” state. The responseMUST be passed to the transport layer for2751

transmission. Any further provisional responses that are received from the TU while in the “Proceeding”2752

stateMUST be passed to the transport layer for transmission. If a retransmission of the request is received2753

while in the “Proceeding” state, the most recently sent provisional responseMUST be passed to the transport2754

layer for retransmission. If the TU passes a final response (status codes 200-699) to the server while in the2755

“Proceeding” state, the transactionMUST enter the “Completed” state, and the responseMUST be passed to2756

the transport layer for transmission.2757

When the server transaction enters the “Completed” state, itMUST set Timer J to fire in T3 seconds for2758

unreliable transports, and zero seconds for reliable transports. While in the “Completed” state, the server2759

transactionMUST pass the final response to the transport layer for retransmission whenever a retransmission2760

of the request is received. Any other final responses passed by the TU to the server transactionMUST be2761

discarded while in the “Completed” state. The server transaction remains in this state until Timer J fires, at2762

which point itMUST transition to the “Terminated” state.2763

The server transactionMUST be destroyed the instant it enters the “Terminated” state.2764

17.2.3 Matching Requests to Server Transactions2765

When anINVITE or ACK request is received from the network by the server, it has to be matched to an2766

existing INVITE transaction. TheINVITE request matches a transaction if theRequest-URI, To, From,2767

Call-ID, CSeq, and topVia header match those of theINVITE request which created the transaction. The2768

ACK request matches a transaction if theRequest-URI, From, Call-ID, CSeq method (not the number),2769

and topVia header match those of theINVITE request which created the transaction, and theTo field of2770

theACK matches theTo field of the response sent by the server transaction (which then includes the tag).2771

Matching is done based on the matching rules defined for each of those headers. The usage of the tag in2772

the To field helps disambiguateACK for 2xx from ACK for other responses at a proxy which may have2773

forwarded both responses (which can occur in unusual conditions).2774

For all other request methods, a request is matched to a transaction if theRequest-URI, To, From,2775

Call-ID andCseq (including the method) and topVia header match those of the request which created the2776

transaction. Matching is done based on the matching rules defined for each of those headers.2777

Because the matching rules include theRequest-URI, the server cannot match a response to a transac-2778

tion. When the TU passes a response to the server, it must inform the TU which transaction the response is2779



to build up estimates of the RTT to a particular IP address. To perform this procedure, the clientMUST2784

maintain a table of variables for each destination IP address to which an RTT estimate is being made.2785

OPEN ISSUE #212: Is destination IP address the right index for an RTT estimate? How aboutRequest-URI?2786

If a client wishes to measure RTT for a particular IP address, itMUST include aTimestamp header into2787

a request containing the time when the request is initially created and passed to a new client transaction,2788

which transmits the request. If a 100 response (not any 1xx, only the 100 response) is received before the2789

client transaction generates a retransmission, an RTT estimate is made. This is consistent with the RFC2790

2988 requirements on TCP for using Karn’s algorithm in RTT estimation.2791

The estimate, called R, is made by computing the difference between the current time and the value of2792

Timestamp header in the 100 response. The value of R is applied to the estimation of RTO as described2793

in Section 2 of RFC 2988 [24], with the following differences. First, the initial value of RTO is 500 ms for2794

SIP, not 3 s as is used for TCP. Second, there is no minimum value for the RTO, as there is for TCP, if SIP2795

is being run on a private network. When run on the public Internet, the minimum is 500 ms, as opposed to2796

1 s for TCP. This difference is because of the expected usage of SIP in private networks where rapid call2797

setup times are service critical. Once RTO is computed, the timer T1 is set to the value of RTO, and all other2798

timers scale proportionally as described above.2799

18 Reliability of Provisional Responses2800

Placeholder.2801

Reliability of provisional responses will be incorporated into bis. This is a heads up on that.2802

19 Transport2803

The transport layer is responsible for the actual transmission of requests and responses over network trans-2804

ports. This includes determination of the connection to use for a request or response, in the case of connec-2805

tion oriented transports.2806

The transport layer is responsible for managing any persistent connections (for transports like TCP, TLS2807

and SCTP) including ones it opened, as well as ones opened to it. This includes connections opened by the2808

client or server transports, so that connections are shared between client and server transport functions. It is2809

RECOMMENDEDthat connections be kept open for some implementation defined time after the last message2810

was sent or received over that connection. This timeSHOULD be at least 16 seconds in order to ensure with2811

high probability that responses can be sent over the same connection a request was sent.2812

All SIP elementsMUST support UDP at a minimum.2813

19.1 Clients2814

19.1.1 Sending Requests2815

The client side of the transport layer is responsible for sending the request and receiving responses. The2816

user of the transport layer passes the client transport the request, an IP address, port, transport, and possibly2817

TTL for multicast destinations.2818

A client that sends a request to a multicast addressMUST add the “maddr” parameter to itsVia header2819

field, andSHOULD add the “ttl” parameter. (In that case, themaddr parameterSHOULD contain the des-2820

tination multicast address, although under exceptional circumstances itMAY contain a unicast address.)2821



Requests sent to multicast groupsSHOULD be scoped to ensure that they are not forwarded beyond the2822

administrative domain to which they were targeted. This scoopingMAY be done with either TTL or admin-2823

istrative scopes [19], depending on what is implemented in the network.2824

It is important to note that the layers above the transport layer do not operate differently for multicast2825

as opposed to unicast requests. This means that SIP treats multicast more like anycast, assuming that there2826

is a single recipient generating responses to requests. If this is not the case, the first response will end2827

up “winning”, based on the client transaction rules. Any other responses from different UA will appear2828

as retransmissions and be discarded. This limits the utility of multicast to cases where an anycast type of2829

function is desired, such as registrations.2830

OPEN ISSUE #7: This is a proposed resolution to whether or not multicast should be removed entirely.2831

Before a request is sent, the client transportMUST insert a value of the sent-by field into theVia header.2832

This field contains an IP address or host name, and port. In certain cases discussed in Section 19.2.2, this2833

IP address and port are used to construct a SIP URL for sending the response. The transport layerMUST2834

be prepared to receive incoming connections (and receive responses sent over such connections) on any IP2835

addresses and ports that this SIP URL might resolve to using the procedures defined in Section 24. The2836

transport layerMUST also be prepared to receive an incoming connection on the source IP address that the2837

request was sent from, and port number in the sent-by field. The client transportMUST also be prepared to2838

receive the response on the same connection used to send the request.2839

For unreliable unicast transports, the client transportMUST be prepared to receive responses on the2840

source IP address that the request is sent from (as responses are sent back to the source address), but the2841

port number in the sent-by field. Furthermore, as with reliable transports, in certain cases the IP address and2842

port are used to construct a URL for sending the response. The client transportMUST be prepared to receive2843

responses on any IP address/port combinations that this SIP URL might resolve to using the procedures of2844

Section 24.2845

For multicast, the client transportMUST be prepared to receive responses on the same multicast group2846

and port that the request is sent to.2847

If a request is destined to an IP address, port, and transport to which an existing connection is open, it2848

is RECOMMENDED that this connection be used to send the request, but another connectionMAY be opened2849

and used.2850

If a request is sent using multicast, it is sent to the group address, port, and TTL provided by the transport2851

user. If a request is sent using unicast unreliable transports, it is sent to the IP address and port provided by2852

the transport user.2853

19.1.2 Receiving Responses2854

When a response is received, the client transport examines the topVia header. If the value of the sent-by2855

parameter in that header does not correspond to a value that the client transport is configured to insert into2856

requests, the responseMUST be rejected.2857

If there are any client transactions in existence, the client transport uses the matching procedures of Sec-2858

tion 17.1.3 to attempt to match the response to an existing transaction. If there is a match, the responseMUST2859

be passed to that transaction. Otherwise, the responseMUST be passed to the core (whether it be stateless2860

proxy, stateful proxy, or UA) for further processing. Handling of these “stray” responses is dependent on2861

the core (a stateless proxy will forward all responses, for example).2862



19.2 Servers2863

19.2.1 Receiving Requests2864

When the server transport receives a request over any transport, itMUST examine the value of the sent-by2865

parameter in the topVia header field. If the host portion of the sent-by parameter contains a domain name,2866

or if it contains an IP address that differs from the packet source address, the serverMUST add a “received”2867

attribute to thatVia header field. This attributeMUST contain the source address that the packet was received2868

from. This is to assist the server transport layer in sending the response, since it must be sent to the source2869

IP address that the request came from.2870

Consider a request received by the server transport which looks like, in part:2871


Via: SIP/2.0/UDP bobspc.biloxi.com:50602873

The request is received with a source IP address of 1.2.3.4. Before passing the request up, the transport2874

would add a received parameter, so that the request would look like, in part:2875


Via: SIP/2.0/UDP bobspc.biloxi.com:50602877

Next, the client transport attempts to match the request to the client transaction. It does so using the2878

matching rules described in Section 17.2.3. If a matching server transaction is found, the request is passed2879

to that transaction for processing. If no match is found, the request is passed to the core, which may decide2880

to construct a new server transaction for that request.2881

19.2.2 Sending Responses2882

The server transport uses the value of the top Via header in order to determine where to send a response. It2883

MUST follow the following process:2884

• If the “sent-protocol” is a reliable transport protocol such as TCP, TLS or SCTP, the responseMUST2885

be sent using the existing connection to the source of the original request that created the transaction, if2886

that connection is still open. This does require the server transport to maintain an association between2887

server transactions and transport connections. If that connection is no longer open, the serverMAY2888

open a connection to the IP address in thereceived parameter, if present, using the port in thesent-by2889

value, or the default port for that transport, if no port is specified (5060 for UDP and TCP, 5061 for2890

TLS and SSL). If that connection attempt fails, the serverSHOULD construct a SIP URL of the form2891

“sip:¡sent-by host¿;transport=¡sent-protocol¿” and then use the procedures defined in Section 24 to2892

determine the IP address and port to open the connection and send the response to.2893

• Otherwise, if theVia header field contains a “maddr” parameter, forward the response to the address2894

listed there, using the port indicated in “sent-by”, or port 5060 if none is present. If the address is2895

a multicast address, the responseSHOULD be sent using the TTL indicated in the “ttl” parameter, or2896

with a TTL of 1 if that parameter is not present.2897



• Otherwise (for unreliable unicast transports), if the topVia has areceived parameter, send the re-2898

sponse to the address in the “received” parameter, using the port indicated in the “sent-by” value, or2899

using port 5060 if none is specified explicitly. If this fails, e.g., elicits an ICMP “port unreachable”2900

response, send the response to the address in the “sent-by” parameter. The address to send to is de-2901

termined by constructing a SIP URL of the form “sip:¡sent-by¿”, and then using the DNS procedures2902

defined in Section 24 to send the response.2903

• Otherwise, if it is not receiver-tagged, send the response to the address indicated by the “sent-by”2904

value.2905

19.3 Framing2906

In the case of message oriented transports (such as UDP), if the message has aContent-Length header, the2907

message body is assumed to contain that many bytes. If there are additional bytes in the transport packet2908

below the end of the body, theyMUST be discarded. If the transport packet ends before the end of the2909

message body, this is considered an error. If the message is a response, itMUST be discarded. If its a2910

request, the elementSHOULD generate a 400 class response. If the message has noContent-Length header,2911

the message body is assumed to end at the end of the transport packet.2912

In the case of stream oriented transports (such as TCP), theContent-Length header indicates the size2913

of the body. TheContent-Length headerMUST be used with stream oriented transports.2914

19.4 Error Handling2915

Error handling is independent of whether the message was a request or response.2916

If the transport user asks for a message to be sent over an unreliable transport, and the result is an ICMP2917

error, the behavior depends on the type of ICMP error. A host, network, port or protocol unreachable errors,2918

or parameter problem errorsSHOULD cause the transport layer to inform the transport user of a failure in2919

sending. Source quench and TTL exceeded ICMP errorsSHOULD be ignored.2920

If the transport user asks for a request to be sent over a reliable transport, and the result is a connection2921

failure, the transport layerSHOULD inform the transport user of a failure in sending.2922

20 Security Considerations2923

The fundamental security issues confronting SIP are: preserving the confidentiality and integrity of messag-2924

ing, preventing replay attacks or message spoofing, ensuring the privacy of the participants in a session, and2925

preventing denial of service attacks.2926

SIP messages frequently contain sensitive information about their senders not just what they have to2927

say, but with whom they communicate, when they communicate and for how long, and from where they2928

participate in sessions. Many applications and their users require that this sort of private information be2929

hidden from any parties that do not need to know it.2930

Encryption provides the best means to preserve the confidentiality of signaling it can also guarantee2931

that messages are not modified by any malicious intermediaries. However, SIP requests and responses2932

cannot be encrypted end-to-end (that is, between a pair of distinct user agents who share encryption keys)2933

in their entirety because message fields such as theRequest-URI, Route andVia need, in most network2934

architectures, to be visible to proxies so that SIP requests are routed correctly. Note that proxy servers need2935



to modify signaling as well (addingVia headers) in order for SIP to function. Proxy servers must therefore2936

be a part of trust relationships in SIP networks.2937

Note that there are also less direct ways in which private information can be divulged. If a user or service2938

chooses to be reachable at an address that is guessable from the person’s name and organizational affiliation2939

(which describes most addresses of record), the traditional method of ensuring privacy by having an unlisted2940

“phone number” is compromised. A user location service can infringe on the privacy of the recipient of a2941

session invitation by divulging their specific whereabouts to the caller; an implementation consequently2942

SHOULD be able to restrict, on a per-user basis, what kind of location and availability information is given2943

out to certain classes of callers.2944

SIP entities also have a need to identify one another in a secure fashion. Ordinarily a SIP UA asserts2945

an identity for the initiator of a request in theFrom header field, but in many systems this information2946

is controlled directly by the end user, and thus spoofing the contents of theFrom is trivial. When a SIP2947

endpoint asserts the identity of its user to a peer user agent or to a proxy server, that identity should in some2948

way be verifiable. A cryptographic authentication mechanism is provided in SIP to address this requirement.2949

The most comprehensive mechanisms for securing SIP messages (providing confidentiality and integrity2950

guarantees for signaling as well as authentication) make use of transport or network layer encryption. en-2951

cryption encrypts the entire SIP request or response on the wire so that packet sniffers or other eavesdroppers2952

cannot see who is calling whom.2953

Note that the security of SIP signaling itself has no bearing on the security of protocols used in concert2954

with SIP such as RTP, or with any MIME types carried as SIP bodies, such as SDP. Any media associated2955

with a session can be encrypted end-to-end without any of the problems associated with encrypting SIP2956

signaling. Media encryption is outside the scope of this document.2957

20.1 Transport and Network Layer Security2958

SIP requests and responsesMAY be protected by security mechanisms at the transport or network layer. No2959

particular mechanism is recommended by this document, but two popular alternatives are briefly examined:2960

protection at the transport layer can be afforded by TLS [25], and network layer security is provided by2961

IPSec [26].2962

Transport or network layer security encrypts signaling traffic, guaranteeing message confidentiality and2963

integrity (note however that the originator and recipient of a session may be deducible by observers per-2964

forming a network traffic analysis). The keys used to establish encrypt traffic can also be used to verify an2965

asserted identity in many architectures, and therefore provide a means of authentication.2966

IPSec is a network layer protocol essentially, a secure replacement for traditional IP (Internet Protocol).2967

IPSec is most suited to VPN (virtual private network) architectures in which a set of SIP hosts (mingled user2968

agents and proxy servers) or bridged administrative domains have a trust relationship with one another.2969

TLS is a transport protocol and hence, like TCP and UDP, TLS can be specified as the desired transport2970

protocol within aVia header field or a SIP-URI. TLS is most suited to architectures in which a chain of trust2971

joins together a set of hosts (e.g. Alice trusts her local proxy server, which in turn trust Bob’s local proxy2972

server, which Bob trusts, hence Bob and Alice can communicate securely).2973

TLS must be tightly coupled with a SIP application. Note that transport mechanisms are specified on2974

a hop-by-hop basis in SIP, and that in some networks TLS might be used for only certain portions of the2975

signaling path.2976

It is RECOMMENDED that SIP endpoints support TLS as a secure transport for SIP.2977



20.2 SIP Authentication2978

SIP provides a stateless challenged-based mechanism for authentication. Any time that a proxy server or2979

user agent receives a request, theyMAY challenge the initiator of the request to provide assurance of their2980

identity. Once the originator has been identified, the recipient of the requestSHOULD ascertain whether or2981

not this user is authorized to make the request in question. No authorization systems are recommended or2982

discussed in this document.2983

The “basic” and “digest” authentication mechanisms described in this section provide message authen-2984

tication only, without message integrity or confidentiality. Protective measures above and beyond authen-2985

tication need to be taken to prevent active attackers from modifying and/or replaying SIP requests and2986

responses.2987

Due to its weak security, the usage of “basic” authentication isNOT RECOMMENDED. However, servers2988

MAY support it to handle older RFC 2543 clients that might still use it.2989

20.2.1 Framework2990

The framework for SIP authentication closely parallels that of HTTP (RFC 2617 [27]). In particular, the2991

BNF for auth- scheme, auth-param, challenge, realm, realm-value, andcredentials is identical. The2992

401 response is used by user agent servers in SIP to challenge the identity of a user agent client. Additionally,2993

registrars and redirect serversMAY make use of 401 (Unauthorized) responses for authentication, but proxies2994

MUST NOT, and insteadMAY use the 407 (Proxy Authentication Required) response. The requirements for2995

inclusion of theProxy-Authenticate, Proxy- Authorization, WWW-Authenticate, andAuthorization in2996

the various messages are identical to those described in RFC 2617 [27].2997

Since SIP does not have the concept of a canonical root URL, the notion of protection spaces is inter-2998

preted differently in SIP. The realm is a protection domain for all SIP URIs with the same value for the2999

userinfo, host andport part of the SIPRequest-URI. For example:3000


WWW-Authenticate: Basic realm="business"3002

and3003



Generally, SIP authentication is for a specific requestRequest-URI and realm, a protection domain.3006

Thus, for basic and digest authentication, each such protection domain has its own set of user names and3007

secrets. If a user agent does not care about differentRequest-URIs, it makes sense to establish a “global”3008

user name, secret and realm that is the default challenge if a particularRequest-URI does not have its own3009

realm or set of user names (e.g. an INVITE to ’sip:10.3.6.6’). Similarly, SIP entities representing many3010

users, such as PSTN gateways,MAY try a preconfigured global user name and secret when challenged,3011

independent of theRequest-URI.3012



20.2.2 User to User Authentication3013

When a UAS receives a request from a UAC, the UASMAY authenticate the originator before the request3014

is processed. If no credentials (in theAuthorization header field are provided in the request, the UAS can3015

challenge the originator to provide credentials by rejecting the request with a 401 (Unauthorized) status3016

code.3017

TheWWW-Authenticate response-header fieldMUST be included in 401 (Unauthorized) response mes-3018

sages. The field value consists of at least one challenge that indicates the authentication scheme(s) and3019

parameters applicable to theRequest-URI. See [H14.47] for a definition of the syntax.3020

An example of theWWW-Authenticate in a 401 challenge is:3021


When the originating UAC receives the 401 itSHOULD, if it is able, re-originate the request with the3023

proper credentials. The UAC may require input from the originating user before proceeding. The content3024

of the “realm” parameter of theWWW-Authenticate headerSHOULD be displayed to the user. Once3025

authentication credentials have been supplied (either directly by the user, or discovered in a keyring), user3026

agentsSHOULD cache the credentials for a given value of theRequest-URI and “realm” and attempt to3027

re-use these values on the next request for that destination.3028

Any user agent that wishes to authenticate itself with a UAS or registrar – usually, but not necessarily,3029

after receiving a 401 response –MAY do so by including anAuthorization header field with the request.3030

TheAuthorization field value consists of credentials containing the authentication information of the user3031

agent for the realm of the resource being requested.3032

An example of theAuthorization header is:3033

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==3034

When a UAC resubmits a request with its credentials after receiving a 401 (or 407) response, itMUST3035

increment theCSeq header field as it would normally do when sending an updated request.3036

20.2.3 Proxy to User Authentication3037

Similarly, when a UAC sends a request to a proxy server, the proxy serverMAY authenticate the originator3038

before the request is processed. If no credentials (in theProxy-Authorization header field) are provided3039

in the request, the UAS can challenge the originator to provide credentials by rejecting the request with a3040

407 (Proxy Authentication Required) status code. The proxyMUST populate the 407 (Proxy Authentication3041

Required) message with aProxy- Authenticate header applicable to the proxy for the requested resource.3042

The use of theProxy-Authentication and Proxy-Authorization parallel that described in [27, Sec-3043

tion 3.6], with one difference. ProxiesMUST NOT add theProxy-Authorization header. 407 (Proxy Au-3044

thentication Required) responsesMUST be forwarded upstream towards the UAC following the procedures3045

for any other response. It is the client’s responsibility to add theProxy-Authorization header containing3046

credentials for the realm of the proxy which has asked for authentication.3047

If a proxy were to resubmit a request with aProxy-Authorization header field, it would need to increment the3048

CSeq in the new request. However, this would mean that the UAC which submitted the original request would3049

discard a response from the UAS, as theCSeq value would be different.3050



When the originating UAC receives the 407 itSHOULD, if it is able, re-originate the request with the3051

proper credentials. It should follow the same procedures for the display of the “realm” parameter that are3052

given above for responding to 401.3053

Any user agent that wishes to authenticate itself to a proxy server – usually, but not necessarily, after3054

receiving a 407 response –MAY do so by including anProxy-Authorization header field with the request.3055

The Proxy-Authorization request-header field allows the client to identify itself (or its user) to a proxy3056

which requires authentication. TheProxy-Authorization field value consists of credentials containing the3057

authentication information of the user agent for the proxy and/or realm of the resource being requested.3058

A Proxy-Authorization header field applies only to the proxy whose realm is identifier in the “realm”3059

parameter (this proxy may previously have demanded authentication using theProxy-Authenticate field).3060

When multiple proxies are used in a chain, theProxy-Authorization header fieldMUST NOT be consumed3061

by any proxy whose realm does not match the “realm” parameter specified in theProxy-Authorization3062

header.3063

Note that if an authentication scheme is used in theProxy- Authorization that does not support realms,3064

a proxy serverMUST attempt to parse allProxy-Authorization headers to determine whether or not one3065

of them has what it considers to be valid credentials. Because this is potentially very time consuming in3066

large networks, proxy serversSHOULD use an authentication scheme that supports realms in theProxy-3067

Authorization header.3068

It is also possible that a 401 or 407 response will contain several challenges, from a mixture of proxies3069

and user agent servers, if the request was forked. If at least one user agent responds to a request with a3070

challenge, than a 401 should be used; otherwise a 407 should be used. When resubmitting its request in3071

response to the challenge, the UAC needs to include an Authorization for each WWW-Authenticate and3072

Proxy- Authorization for each Proxy-Authenticate.3073

See [H14.34] for a definition of the syntax ofProxy- Authentication andProxy-Authorization.3074

20.2.4 Authentication Schemes3075

SIP implementationsMAY use HTTP’s basic and digest authentication mechanisms ([27]) to provide a rudi-3076

mentary form of security. This section overviews usage of these mechanisms in SIP. The scheme usage is3077

almost completely identical to that for HTTP [27]. This section outlines this operation, pointing to RFC3078

2617 ([27]) for details and noting the differences that arise when using SIP. Since RFC 2543 is based on3079

HTTP basic and digest as defined in RFC 2069 [28], SIP servers supporting RFC 2617MUST ensure they3080

are backwards compatible with RFC 2069. Procedures for this backwards compatibility are specified in3081

RFC 2617.3082

20.2.4.1 HTTP Basic The rules for basic authentication follow those defined in [27, Section 2] but with3083

the words “origin server” replaced with “user agent server, redirect server , or registrar”.3084

Since SIP URIs are not hierarchical, the paragraph in [27, Section 2] that states that “all paths at or3085

deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the3086

protection space specified by the Basic realm value of the current challenge” does not apply for SIP. SIP3087

clientsMAY preemptively send the correspondingAuthorization header with requests for SIP URIs within3088

the same protection realm (as defined above) without receipt of another challenge from the server.3089

20.2.4.2 HTTP Digest The rules for digest authentication follow those defined in [27, Section 3], with3090

“HTTP 1.1” replaced by “SIP/2.0” in addition to the following differences:3091



1. The URI included in the challenge has the following BNF:3092

URI = SIP-URL3093

2. The BNF in RFC 2617 has an error in that the URI is not enclosed in quotation marks. (The example3094

in Section 3.5 is correct.) For SIP, the URIMUST be enclosed in quotation marks.3095

3. The BNF fordigest-uri-value is:3096

digest-uri-value = Request-URI ; as defined in Section 263097

4. The example procedure for choosing a nonce based onEtag does not work for SIP.3098

5. The text in RFC 2617 [27] regarding cache operation does not apply to SIP.3099

6. RFC 2617 [27] requires that a server check that the URI in the request line, and the URI included in3100

theAuthorization header, point to the same resource. In a SIP context, these two URI’s may actually3101

refer to different users, due to forwarding at some proxy. Therefore, in SIP, a serverMAY check3102

that theRequest-URI in theAuthorization header corresponds to a user for whom that the server is3103

willing to accept forwarded or direct calls.3104

RFC2543 did not allow usage of theAuthentication-Info header (it effectively used RFC 2069). How-3105

ever, we now allow usage of this header, since it provides integrity checks over the bodies and provides3106

mutual authentication. RFC2617 [27] defines mechanisms for backwards compatibility using the qop at-3107

tribute in the request. These mechanismsMUST be used by a server to determine if the client supports the3108

new mechanisms in RFC 2617 that were not specified in RFC 2069.3109

20.3 SIP Encryption3110

No mechanism is currently specified for encrypting entire SIP messages end-to-end for the purpose of con-3111

fidentiality. This is a hard problem because network intermediaries (like proxy servers) need to view certain3112

headers in order to route messages correctly, and if these intermediaries are excluded from security associa-3113

tions then SIP messages will essentially be unroutable.3114

That much said, SIP messages carry MIME bodies and the MIME standard includes mechanisms for3115

securing MIME contents to ensure both integrity and confidentiality (including the ’multipart/encrypted’3116

MIME type, see [29]), but detailed description of the use of secure MIME types are outside the scope of this3117

document. Implementors should note, however, that there may be rare network intermediaries (not typical3118

proxy servers) that rely on viewing or modifying the bodies of SIP messages (especially SDP), and that3119

secure MIME may prevent these sorts of intermediaries from functioning.3120

This applies particularly to certain types of firewalls.3121

End-to-end encryption relies on keys shared by the two user agents involved in the request. Typically,3122

the message is sent encrypted with the public key of the recipient, so that only that recipient can read the3123

message. SIP does not define any mechanism for end-to-end key exchange.3124

Note that the PGP mechanism for encrypting the headers and bodies of SIP messages described in RFC2543 has3125

been deprecated.3126



20.4 Denial of Service3127

Denial of service attacks focus on rendering a particular network element unavailable, usually by directing3128

an excessive amount of network traffic at its interfaces. A distributed denial of service attack allows one3129

network user to cause multiple network hosts to flood a target host with a large amount of network traffic.3130

In many architectures SIP proxy servers face the public Internet in order to accept requests from world-3131

wide IP endpoints. When the host on which a SIP proxy server is operating is routable from the public3132

Internet, it should be deployed in an administrative domain with secure routing policies (blocking source-3133

routed traffic, preferably filtering ping traffic).3134

SIP creates a number of potential opportunities for distributed denial of service attacks that must be3135

recognized and addressed by the implementors and operators of SIP systems.3136

Floods of messages directed at proxy servers can lock up proxy server resources and prevent desirable3137

traffic from reaching its destination. There is a computational expense associated with processing a SIP3138

transaction at a proxy server, and that expense is greater for stateful proxy servers that it is for stateless3139

proxy servers. Therefore stateful proxies are more susceptible to flooding than stateless proxy servers.3140

Attackers can create bogus requests that contain a falsifiedVia header field which identifies a targeted3141

host as the originator of the message and then send this message to a large number of SIP network elements,3142

thereby using hapless SIP UAs or proxies to generate denial of service traffic aimed at the target.3143

Similarly, attackers might use falsifiedRoute headers in a request that identify the target host and then3144

send such messages to forking proxies that will amplify messaging sent to the target.Record-Route could3145

be used to similar effect when the attacker is certain that the SIP dialog initiated by the request will result in3146

numerous transactions originating in the backwards direction.3147

One could prevent one’s host from being commandeered for such an attack by disallowing requests that3148

do not make use of a persistent security association established through a transport or network layer security3149

instrument such as TLS or IPsec. This could be an appropriate security solution for two proxy servers that3150

trust one another and exchange significant amounts of signaling traffic with one another, or between a user3151

agent and its outbound proxy.3152

Both TLS and IPSec can also make use of bastion hosts at the edges of administrative domains that3153

participate in the security associations to aggregate secure tunnels and sockets. These bastion hosts can also3154

take the brunt of denial of service attacks, ensuring that SIP hosts within the administrative domain are not3155

encumbered with superfluous messaging.3156

If such a persistent security association is not feasible, user agents and proxy serversSHOULD chal-3157

lenge questionable requests with only asingle401 (Unauthorized) or 407 (Proxy Authentication Required)3158

forgoing the normal response retransmission algorithm.3159

Retransmitting the 401 or 407 status response amplifies the problem of an attacker using a falsified header (such3160

asVia) to direct traffic to a third party.3161

A number of denial of service attacks open up ifREGISTER requests are not properly authenticated3162

and authorized by registrars. Attackers could de-register some or all users in an administrative domain,3163

thereby preventing these users from being invited to new sessions. An attacker could also register a large3164

number of contacts designating the same host for a given address of record in order to use the registrar and3165

any associated proxy servers as amplifiers in a denial of service attack. Attackers might also attempt to3166

deplete available memory and disk resources of a registrar by registering huge numbers of bindings.3167

With either TCP or UDP, a denial of service attack exists by a rogue proxy sending 6xx responses.3168

Although a clientSHOULD choose to ignore such responses if it requested authentication, a proxy cannot do3169

so. It is obliged to forward the 6xx response back to the client. The client can then ignore the response, but3170

if it repeats the request it will probably reach the same rogue proxy again, and the process will repeat.3171



The use of multicast to transmit SIP requests can greatly increase the potential for denial of service3172

attacks.3173

21 Common Message Components3174

There are certain components of SIP messages that appear in various places within SIP messages (and3175

sometimes, outside of them), which merit separate discussion.3176

21.1 SIP Uniform Resource Locators3177

A SIP URL identifies a communications resource. Like all URLs, SIP URLs may be placed in web pages,3178

email messages or printed literature. They contain sufficient information to initiate and maintain a commu-3179

nication session with the resource.3180

Examples of communications resources include3181

• a user of an online service3182

• an appearance on a multiline phone3183

• a mailbox on a messaging system3184

• a PSTN phone number at a gateway service3185

• a group (such as “sales” or “helpdesk”) in an organization3186

21.1.1 SIP URL components3187

The “sip:” scheme follows the guidelines in RFC 2396 [9]. It uses a form similar to themailto URL, al-3188

lowing the specification of SIPrequest-header fields and the SIPmessage- body. This makes it possible3189

to specify the subject, media type, or urgency of sessions initiated by using a URL on a web page or in an3190

email message. The formal syntax for a SIP URL is presented in Section 26. Its general form is3191

sip:user:password@host:port;url-parameters?headers3192

These tokens, and some of the tokens in their expansion, have the following meanings.3193

user : The identifier of a particular resource at the host being addressed. Note that “host” as used here may,3194

and frequently does, refer to a domain.3195

The “userpart” of a URL consists of this user field, the password field and the @ sign following them.3196

The userpart of a URL is optional andMAY be absent when the destination host does not have a notion3197

of users or when the host itself is the resource being identified. If the @ sign is present in a SIP URL,3198

the user fieldMUST NOT be empty.3199

If the host being addressed is capable of processing telephone numbers, an Internet telephony gateway3200

for instance, atelephone- subscriber field defined in RFC 2806 [13]MAY be used to populate the3201

user field. There are special escaping rules for encodingtelephone-subscriber fields in SIP URLs3202

described in Section 21.1.2.3203



password : A password associated with the user3204

While the SIP URL syntax allows this field to be present, its use isNOT RECOMMENDED, because3205

the passing of authentication information in clear text (such as URIs) has proven to be a security risk3206

in almost every case where it has been used. For instance, transporting a PIN number in this field3207

exposes the PIN.3208

host : The entity hosting the SIP resource3209

Thehost part contains either a fully-qualified domain name or numeric IPv4 or IPv6 address. Using3210

the fully-qualified domain name form isRECOMMENDED whenever possible.3211

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

URL parameters: Parameters affecting a request constructed from the URL.3213

URL parameters are added after thehostport component and are separated by semi-colons. This3214

extensible mechanism includes thetransport, maddr, ttl, user, andmethod parameters.3215

The transport parameter determines the transport mechanism to be used for sending SIP messages.3216

SIP can use any network transport protocol. Parameter names are defined for UDP [30], TCP [31],3217

TLS [25], and SCTP [32].3218

Themaddr parameter indicates the server address to be contacted for this user, overriding any address3219

derived from thehost field. Section 24 describes the proper interpretation of thetransport, maddr3220

andhostport in order to obtain the destination address, port and transport for sending a request.3221

Themaddr field can be used as a simple form of loose source routing. It allows a URL to specify a specific3222

proxy that must be traversed en-route to the destination. This capability is useful for a roaming user that is3223

forced to use an outbound proxy, but wishes to force requests through their home proxy.3224

The ttl parameter determines the time-to-live value of the UDP multicast packet andMUST only3225

be used ifmaddr is a multicast address and the transport protocol is UDP. Theuser parameter3226

was described above. For example, to specify to [email protected] using multicast to3227

239.255.255.1 with a ttl of 15, the following URL would be used:3228

sip:[email protected];maddr=239.255.255.1;ttl=153229

The set of validtelephone-subscriber strings is a subset of validuser strings. Theuser URL3230

parameter exists to distinguish telephone numbers from user names that happen to look like telephone3231

numbers. If the user string contains a telephone number formatted as atelephone-subscriber, the3232

user parameter value “phone” SHOULD be present. Even without this parameter, recipients of SIP3233

URLs MAY interpret the pre-@ part as a telephone number if local restrictions on the name space for3234

user name allow it.3235

The method of the SIP request constructed from the URL can be specified with themethod parameter.3236

Since the url-parameter mechanism is extensible, SIP elementsMUST silently ignore any url-parameters3237

that they do not understand.3238



Headers: Headers to be included in a request constructed from the URL.3239

Headers fields in the SIP request can be specified with the “?” mechanism within a SIP URL. The3240

header names and values are encoded in ampersand separatedhname = hvalue pairs. The special3241

hname “body” indicates that the associatedhvalue is themessage-body of the SIP request.3242

Table 1 summarizes the use of SIP URL components based on the context in which the URL appears.3243

The external column describes URLs appearing anywhere outside of a SIP message, for instance on a web3244

page or business card. Entries marked “m” are mandatory, those marked “o” are optional, and those marked3245

“-” are not allowed. Elements processing URLsSHOULD ignore any disallowed components if they are3246

present. The second column indicates the default value of an optional element if it is not present. “–”3247

indicates that the element is either not optional, or has no default value.3248

SIP URLs inContact header fields have different restrictions depending on the context in which the3249

header field appears. One set applies to messages that establish and maintain dialogs (INVITE and its 2003250

OK response). The other applies to registration and redirection messages (REGISTER, its 200 OK response,3251

and 3xx class responses to any method).3252

OPEN ISSUE #203: maddr is disallowed in To/From, but not port. Should port be disallowed?3253

OPEN ISSUE #204: Password is disallowed in From, but not To. Why?3254

OPEN ISSUE #205: Should we allow method and header URL components in registration/redirect3255

Contacts. What do they mean?3256

dialogreg./redir. Contact/

default Req.-URI To From Contact R-R/Route externaluser – o o o o o opassword – o o - o o ohost – m m m m m mport 5060 o o o o o ouser-param ip o o o o o omethod INVITE - - - o - omaddr-param – o - - o o ottl-param 1 o - - o - otransp.-param udp o - - o o oother-param – o o o o o oheaders – - - - o - o

Table 1: Use and default values of URL components for SIP headers,Request-URI and references

21.1.2 Character escaping requirements3257

SIP follows the requirements and guidelines of RFC 2396 when defining the set of characters that must be3258

escaped in a SIP URL, and uses its “”%” HEX HEX” mechanism for escaping. From RFC 2396:3259

The set of characters actually reserved within any given URI component is defined by that com-3260

ponent. In general, a character is reserved if the semantics of the URI changes if the character3261

is replaced with its escaped US-ASCII encoding. [9].3262



Excluded US-ASCII characters [9, Sec. 2.4.3], such as space and control characters and characters used as3263

URL delimiters, alsoMUST be escaped. URLsMUST NOT contain unescaped space and control characters.3264

For each component, the set of valid BNF expansions defines exactly which characters may appear3265

unescaped. All other charactersMUST be escaped.3266

For example, “@” is not in the set of characters in the user component, so the user “j@s0n” must have3267

at least the @ sign encoded, as in “j%40s0n”.3268

Expanding the hname and hvalue tokens in Section 26 show that all URL reserved characters in header3269

names and valuesMUST be escaped.3270

The telephone-subscriber subset of theuser component has special escaping considerations. The set3271

of characters not reserved in the RFC 2806 [13] description oftelephone-subscriber contains a number3272

of characters in various syntax elements that need to be escaped when used in SIP URLs. Any characters3273

occurring in atelephone-subscriber that do not appear in an expansion of the BNF for theuser rule MUST3274

be escaped.3275

21.1.3 Example SIP URLs3276

sip:[email protected]

sip:alice:[email protected];transport=tcp3278

sip:[email protected]?subject=project%20x&priority=urgent3279

sip:+1-212-555-1212:[email protected];user=phone3280



sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com3283

sip:alice;[email protected]

The last example URL above has auser field value of “alice;day=tuesday”. The escaping rules defined3285

above allow a semicolon to appear unescaped in this field. Note, however, that for the purposes of this3286

protocol, the field is opaque. The apparent structure in that value is only useful to the entity responsible for3287

the resource.3288

21.1.4 SIP URL Comparison3289

SIP URLs are compared for equality according to the following rules:3290

• Comparisons of scheme name (“sip”), domain names, parameter names and header names are case-3291

insensitive, all other comparisons are case-sensitive. (OPEN ISSUE #100 : There is a proposal to3292

make only quoted string comparisons case-sensitive.)3293

• The ordering of parameters and headers is not significant in comparing SIP URLs.3294

• Characters other than those in the “reserved” and “unsafe” sets (see RFC 2396 [9]) are equivalent to3295

their “”%” HEX HEX” encoding.3296

• An IP address that is the result of a DNS lookup of a host name doesnot match that host name.3297

• For two URLs to be equal, theuser, password, host, andport components must match. A URL3298

omitting the optional port component will match a URL explicitly declaring port 5060. A URL3299



omitting the user component willnot match a URL that includes one. A URL omitting the password3300

component willnot match a URL that includes one.3301

• URL url-parameter components are compared as follows3302

– Any url-parameter appearing in both URLs must match.3303

– A user, transport, ttl, or methodurl-parameter appearing in only one URL must contain its3304

default value or the URLs do not match.3305

– All other url-parameters appearing in only one URL are ignored when comparing the URLs.3306

• URL header components are never ignored. Any presentheader componentMUST be present in3307

both URLs and match for the URLs to match. The matching rules are defined for each header in3308

Section sec:header-fields.3309

The URLs within each of the following sets are equivalent:3310

sip:alice@%61tlanta.com:50603311

sip:[email protected];Transport=udp3312


sip:[email protected];newparam=53314

sip:[email protected];security=on3315

sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com3316

sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com3317

sip:[email protected]?subject=project%20x&priority=urgent3318

sip:[email protected]?priority=urgent&subject=project%20x3319

The URLs within each of the following sets arenot equivalent:3320

SIP:[email protected];Transport=udp (different usernames)3321

sip:[email protected];Transport=UDP3322

sip:[email protected] (different port and transport)3323

sip:[email protected]:6000;transport=tcp3324

sip:[email protected] (different header component)3325

sip:[email protected]?Subject=next%20meeting3326

sip:[email protected] (even though that’s what3327

sip:[email protected] phone21.boxesbybob.com resolves to)3328

Note that equality is not transitive:3329

sip:[email protected] and sip:[email protected];security=on are equivalent3330



and sip:[email protected] and sip:[email protected];security=off are equivalent3331

But sip:[email protected];security=on and sip:[email protected];security=off arenot equivalent3332

Comparing URLs is a major part of comparing several SIP headers (see Section 22).3333

21.2 Option Tags3334

Option tags are unique identifiers used to designate new options (extensions) in SIP. These tags are used in3335

Require (Section 22.30),Proxy-Require (Section 22.28,Supported (Section 22.35) andUnsupported3336

(Section 22.38) header fields. Note that these options appear as parameters in those headers in anoption-tag3337

= token form (see Section 26 for the definition oftoken).3338

The creator of a new SIP optionMUST either prefix the option with their reverse domain name or register3339

the new option with the Internet Assigned Numbers Authority (IANA) (See Section 27).3340

An example of a reverse-domain-name option is “com.foo.mynewfeature”, whose inventor can be reached3341

at “foo.com”. For these features, individual organizations are responsible for ensuring that option names do3342

not collide within the same domain. The host name part of the optionMUST use lower-case; the option name3343

is case-sensitive.3344

Options registered with IANA do not contain periods and are globally unique. IANA option tags are3345

case-sensitive.3346

21.3 Tags3347

The “tag” parameter is used in theTo andFrom fields of SIP messages. It serves as a general mechanism3348

to identify a particular instance of a user agent for a particular SIP URI.3349

As proxies can fork requests, the same request can reach multiple instances of a user (mobile and home3350

phones, for example). Since each can respond, there needs to be a means for the originator of a session to3351

distinguish the responses. Tag fields in theTo andFrom disambiguate these multiple instances of the same3352

user.3353

This situation also arises with multicast requests.3354

When a tag is generated by a UA for insertion into a request or response, itMUST be globally unique and3355

cryptographically random with at least 32 bits of randomness. A property of this selection requirement is3356

that a UA will place a different tag into theFrom header of anINVITE as it would place into theTo header3357

of the response to the sameINVITE. This is needed in order for a UA to invite itself to a session, a common3358

case for “hairpinning” of calls in PSTN gateways.3359

Besides the requirement for global uniqueness, the algorithm for generating a tag is implementation3360

specific. Tags are helpful in fault tolerant systems, where a dialog is to be recovered on an alternate server3361

after a failure. A UAS can select the tag in such a way that a backup can recognize a request as part of a3362

dialog on the failed server, and therefore determine that it should attempt to recover the dialog and any other3363

state associated with it.3364

22 Header Fields3365

The general syntax for header fields is covered in Section 7.3. This section lists the full set of header fields3366

along with notes on syntax, meaning, and usage. Throughout this section, we use [HX.Y] to refer to Section3367

X.Y of the current HTTP/1.1 specification RFC 2617 [27]. Examples of each header field are given.3368



Information about header fields in relation to methods and proxy processing is summarized in Ta-3369

bles 2 and 3.3370

The “where” column describes the request and response types in which the header field can be used.3371

Values in this column are:3372

R: refers to header fields that can be used in requests.3373

r: designates a header field as applicable to all responses, while a list of numeric values indicates the status3374

codes with which the header field can be used.3375

c: indicates a header field is copied from the request to the response.3376

The “proxy” column describes the operations a proxy may perform on a header.3377

c: indicates that a proxy can add (concatenate) comma-separated elements to the header3378

m: indicates that a proxy can modify the header3379

a: indicates that a proxy can add the header if not present3380

r: indicates that a proxy must be be able to read the header. Headers that need to be read cannot be en-3381

crypted.3382

The next six columns relate to the presence of a header field in a method, with the contents indicating:3383

o: for optional3384

m: for mandatory3385

m*: indicates a header thatSHOULD be sent, but servers need to be prepared to receive messages without3386

that header field.3387

*: indicates that the header fields are required if the message body is not empty. See sections 22.14, 22.153388

and 7.4 for details.3389

-: for not applicable.3390

“Optional” means thata UAMAY include the header field in a request or response, and a UAMAY ignore3391

the header field if present in the request or response (The exception to this rule is theRequire header field3392

discussed in 22.30). A “mandatory” header fieldMUST be present in a request, andMUST be understood by3393

the UAS receiving the request. A mandatory response header fieldMUST be present in the response, and the3394

header fieldMUST be understood by the UAC processing the response. “Not applicable” means for header3395

fields that the header fieldMUST NOT be present in a request. If one is placed in a request by mistake, it3396

MUST be ignored by the UAS receiving the request. Similarly, a header field labeled “not applicable” for a3397

response means that the UASMUST NOT place the header in the response, and the UACMUST ignore the3398

header in the response.3399

A compact form of some common header fields is also defined for use when overall message size is an3400

issue.3401

TheContact, From andTo header fields contain a URL. If the URL contains a comma, question mark3402

or semicolon, the URLMUST be enclosed in angle brackets (< and>). Any URL parameters are contained3403

within these brackets. If the URL is not enclosed in angle brackets, any semicolon-delimited parameters are3404

header-parameters, not URL parameters.3405



Header field where proxy ACK BYE CAN INV OPT REGAccept R - o - m* o oAccept 2xx - - - m* o oAccept 415 - o - o o oAccept-Encoding R - o - m* o oAccept-Encoding 2xx - - - m* o oAccept-Encoding 415 - o - o o oAccept-Language R - o - m* o oAccept-Language 2xx - - - m* o oAccept-Language 415 - o - o o oAlert-Info R am - - - o - -Alert-Info 180 am - - - o - -Allow R o o o o o oAllow 2xx - o o m* m* oAllow r - o o o o oAllow 405 - m m m m mAuthentication-Info 2xx - o - o o oAuthorization R o o o o o oCall-ID c r m m m m m mCall-Info am - - - o o oContact R o - - m o oContact 1xx - - - o o -Contact 2xx - - - m o oContact 3xx - o - o o oContact 485 - o - o o oContent-Disposition o o - o o oContent-Encoding o o - o o oContent-Language o o - o o oContent-Length r m* m* m* m* m* m*Content-Type * * - * * *CSeq c r m m m m m mDate a o o o o o oError-Info 300-699 - o o o o oExpires - - - o - oFrom c r m m m m m mIn-Reply-To R - - - o - -Max-Forwards R rm o o o o o oMIME-Version o o o o o oOrganization am - - - o o o

Table 2: Summary of header fields, A–O



Header field where proxy ACK BYE CAN INV OPT REGPriority R a - - - o - -Proxy-Authenticate 407 - m m m m mProxy-Authorization R r o o o o o oProxy-Require R r o o o o o oRecord-Route R amr o o o o o oRecord-Route 2xx,401,484 - o o o o oRequire g acr o o o o o oRetry-After 404,413,480,486 - o o o o o

500,503 - o o o o o600,603 - o o o o o

Route R r o o o o o oServer r - o o o o oSubject R - - - o - -Supported - o o o o oTimestamp o o o o o oTo gc(1) r m m m m m mUnsupported 420 - o o o o oUser-Agent o o o o o oVia c acmr m m m m m mWarning r o o o o o oWWW-Authenticate 401 - m m m m m

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

22.1 Accept3406

TheAccept header follows the syntax defined in [H14.1]. The semantics are also identical, with the excep-3407

tion that if noAccept header is present, the serverSHOULD assume a default value ofapplication/sdp .3408

Example:3409

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

22.2 Accept-Encoding3411

The Accept-Encoding header field is similar toAccept, but restricts the content-codings [H3.5] that are3412

acceptable in the response. See [H14.3]. The syntax of this header is defined in [H14.3]. The semantics in3413

SIP are identical to those defined in [H14.3].3414

An emptyAccept-Encoding header field is permissible, even though the syntax in [H14.3] does not3415

provide for it. It is equivalent toAccept-Encoding: identity, i.e., only the identity encoding, meaning no3416

encoding, is permissible. If this header is not present, the default value isidentity. This differs slightly3417

from the HTTP definition, which indicates that when not present, any encoding can be used, but the identity3418

encoding is preferred.3419

Example:3420



Accept-Encoding: gzip3421

22.3 Accept-Language3422

TheAccept-Language header follows the syntax defined in [H14.4]. The rules for ordering the languages3423

based on the “q” parameter apply to SIP as well.3424

TheAccept-Language header is used in requests to indicate the preferred languages for reason phrases,3425

session descriptions or status responses carried as message bodies in the response. If noAccept-Language3426

header field is present in a request, the server assumes all languages are acceptable to the client.3427

Example:3428

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

22.4 Alert-Info3430

When present in anINVITE request, theAlert-Info header field specifies an alternative ring tone to the UAS.3431

When present in a 180 (Ringing) response, theAlert-Info header field specifies an alternative ringback tone3432

to the UAC. A typical usage is for a proxy to insert this header to provide a distinctive ring feature.3433

The Alert-Info header can introduce security risks. These risks, and the ways to handle them, are3434

discussed in Section 22.9 which discusses theCall-Info header, as the risks are identical.3435

In addition, a userSHOULD be able to disable this feature selectively.3436

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

Example:3438

Alert-Info: <http://wwww.example.com/sounds/moo.wav>3439

22.5 Allow3440

TheAllow header field lists the set of methods supported by the user agent generating the message.3441

All methods, includingACK and CANCEL, understood by the UAMUST be included in the list of3442

methods in theAllow header, when present. The absence of anAllow headerMUST NOT be interpreted to3443

mean that the UA sending the message supports no methods. Rather, it implies that the UA is not providing3444

any information on what methods it supports.3445

Supplying anAllow header in responses to methods other thanOPTIONS cuts down on the number of3446

messages needed.3447

Example:3448

Allow: INVITE, ACK, OPTIONS, CANCEL, BYE3449

22.6 Authentication-Info3450

TheAuthentication-Info header provides for mutual authentication with HTTP Digest. A UASMAY include3451

this header in a 2xx response to a request that was successfully authenticated using digest based on the3452

Authorization header.3453

Syntax and semantics follow those specified in RFC2617 [27].3454

Example:3455



Authentication-Info: nextnonce="47364c23432d2e131a5fb210812c"3456

22.7 Authorization3457

The Authorization header field contains authentication credentials of a UA. Section 20.2.2 overviews the3458

use of theAuthorization header field, and Section 20.2.4 describes the syntax and semantics when used3459

with HTTP Basic and Digest authentication.3460

Note that this header field, along withProxy-Authorization breaks the general rules about multiple3461

header fields. Although not a comma-separated list, this header field may be present multiple times, and3462

MUST NOT be combined into a single header using the usual rules described in Section 7.3.3463

Example:3464

Authorization: Digest username="Alice", realm="Bob’s Friends",3465

nonce="84a4cc6f3082121f32b42a2187831a9e",3466

response="7587245234b3434cc3412213e5f113a5432"3467

22.8 Call-ID3468

TheCall-ID header field uniquely identifies a particular invitation or all registrations of a particular client.3469

Note that a single multimedia conference can give rise to several calls with differentCall-IDs, e.g., if a user3470

invites a single individual several times to the same (long-running) conference.Call-IDs are case- sensitive3471

and are simply compared byte-by-byte.3472

The compact form of theCall-IDheader field isi.3473

Examples:3474


i:[email protected]

22.9 Call-Info3477

TheCall-Info header field provides additional information about the caller or callee, depending on whether3478

it is found in a request or response. The purpose of the URI is described by the “purpose” parameter.3479

“ icon” designates an image suitable as an iconic representation of the caller or callee; “info” describes the3480

caller or callee in general, e.g., through a web page; “card” provides a business card (e.g., in vCard [33] or3481

LDIF [34] formats). Additonal tokens can be registered using IANA and the procedures in Section 27.3482

Usage of theCall-Info header can pose a security risk. If a callee fetches the URLs provided by an3483

malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or3484

illegal content, and so on. Therefore, it isRECOMMENDED that a UA only render the information in the3485

Call-Info header if it can verify the authenticity of the element which originated the header, and trusts that3486

element. This need not be the peer UA; a proxy can insert this header into requests.3487

The use of this header is important in converged applications.3488

Example:3489

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

<http://www.example.com/alice/> ;purpose=info3491



22.10 Contact3492

TheContact header field provides a URL whose meaning depends on the the type of request or response it3493

is in.3494

Parameters defined forContact include “q” and “expires”. Additional parameters may be defined in3495

other specifications.Even if the “display-name” is empty, the “name-addr” form MUST be used if the3496

“addr-spec” contains a comma, semicolon or question mark. Note that there may or may not be LWS3497

between thedisplay-name and the “<”.3498

TheContact header field fulfills functionality similar to theLocation header field in HTTP. However, the HTTP3499

header only allows one address, unquoted. Since URIs can contain commas and semicolons as reserved characters,3500

they can be mistaken for header or parameter delimiters, respectively. The current syntax corresponds to that for the3501

To andFrom header, which also allows the use of display names.3502

The compact form of theContact header field ism (for ”moved”).3503

Examples:3504

Contact: "Mr. Watson" <sip:[email protected]>3505

;q=0.7; expires=3600,3506

"Mr. Watson" <mailto:[email protected]> ;q=0.13507

m: <sip:[email protected]>3508

22.11 Content-Disposition3509

The Content-Disposition header field describes how the message body or, in the case of multipart mes-3510

sages, a message body part is to be interpreted by the UAC or UAS. The SIP header extends the MIME3511

Content-Type (RFC 1806 [35]).3512

The value “session” indicates that the body part describes a session, for either calls or early (pre-call)3513

media. The value “render” indicates that the body part should be displayed or otherwise rendered to the3514

user. For backward-compatibility, if theContent-Disposition header is not missing, bodies ofContent-3515

Type application/sdp imply the disposition “session”, while other content types imply “render”.3516

The disposition type “icon” indicates that the body part contains an image suitable as an iconic repre-3517

sentation of the caller or callee. The value “alert” indicates that the body part contains information, such as3518

an audio clip, that should be rendered instead of ring tone.3519

The handling parameter,handling-parm, describes how the UAS should react if it receives a message3520

body whose content type or disposition type it does not understand. The parameter has defined values of3521

“optional” and “required”. If the handling parameter is missing, the value “required” is to be assumed.3522

If this header field is missing, the MIME type determines the default content disposition. If there is none,3523

“ render” is assumed.3524

Example:3525

Content-Disposition: session3526

22.12 Content-Encoding3527

The Content-Encoding header field is used as a modifier to the “media-type”. When present, its value3528

indicates what additional content codings have been applied to the entity-body, and thus what decoding3529

mechanismsMUST be applied in order to obtain the media-type referenced by theContent-Type header3530



field. Content-Encoding is primarily used to allow a body to be compressed without losing the identity of3531

its underlying media type.3532

If multiple encodings have been applied to an entity, the content codingsMUST be listed in the order in3533

which they were applied.3534

All content-coding values are case-insensitive. The Internet Assigned Numbers Authority (IANA) acts3535

as a registry for content-coding value tokens. See [H3.5] for a definition of the syntax forcontent-coding.3536

ClientsMAY apply content encodings to the body in requests. A serverMAY apply content encodings to3537

the bodies in responses. The serverMUST only use encodings listed in theAccept-Encoding header in the3538

request.3539

The compact form of theContent-Encoding header field ise.3540

Examples:3541

Content-Encoding: gzip3542

e: tar3543

22.13 Content-Language3544

See [H14.12].3545

Example:3546

Content-Language: fr3547

22.14 Content-Length3548

TheContent-Length header field indicates the size of the message-body, in decimal number of octets, sent3549

to the recipient.3550

ApplicationsSHOULD use this field to indicate the size of the message-body to be transferred, regardless3551

of the media type of the entity. (The size of the message-body doesnot include the CRLF separating headers3552

and body.) AnyContent-Length greater than or equal to zero is a valid value. If no body is present in a3553

message, then theContent-Length header fieldMUST be set to zero.3554

The ability to omitContent-Length simplifies the creation of cgi-like scripts that dynamically generate re-3555

sponses.3556

The short form of the header isl.3557

Examples:3558

Content-Length: 3493559

l: 1733560

22.15 Content-Type3561

The Content-Type header field indicates the media type of the message-body sent to the recipient. The3562

“media-type” element is defined in [H3.7]. TheContent-Type headerMUST be present if the body is not3563

empty. If the body is empty, and aContent-Length header is present, it indicates that the body of the3564

specific type has zero length (for example, if it is an emtpy audio file).3565

The short form of the header isc.3566

Examples:3567




c: text/html; charset=ISO-8859-43569

22.16 CSeq3570

A CSeq header field in a request contains a single decimal sequence number and the request method. The3571

sequence numberMUST be expressible as a 32-bit unsigned integer. TheCSeq header serves to order3572

transactions within a dialog, and to provide a means to uniquely identify transactions, and to differentiate3573

between new requests and request retransmissions.3574

Example:3575


22.17 Date3577

The Date header field contains an RFC 1123 date (see [H14.18]). Note that unlike HTTP/1.1, SIP only3578

supports the most recent RFC 1123 [36] formatting for dates. As in [H3.3], SIP restricts the timezone in3579

SIP-date to “GMT”, while RFC 1123 allows any timezone.3580

The consistent use of GMT betweenDate, Expires andRetry-After headers allows implementation of simple3581

clients that do not have a notion of absolute time.3582

Note thatrfc1123-date is case-sensitive.3583

TheDate header field reflects the time when the request or response is first sent.3584

TheDate header field can be used by simple end systems without a battery-backed clock to acquire a notion of3585

current time. However, in its GMT-form, it requires clients to know their offset from GMT.3586

Example:3587

Date: Sat, 13 Nov 2001 23:29:00 GMT3588

22.18 Error-Info3589

TheError-Info header field provides a pointer to additional information about the error status response.3590

SIP UACs have user interface capabilities ranging from pop up windows and audio on PC softclients to audio-3591

only on ”black” phones or endpoints connected via gateways. Rather than forcing a server generating an error to3592

choose between sending an error status code with a detailed reason phrase and playing an audio recording, the3593

Error-Info header field allows both to be sent. The UAC then has the choice of which error indicator to render to the3594

caller.3595

A UAC MAY treat a SIP URL in anError-Info header field as if it were aContact in a redirect and3596

generate a newINVITE, resulting an a recorded announcement session being established. A non-SIP URL3597

MAY be rendered to the user.3598

Examples:3599

SIP/2.0 404 The number you have dialed is not in service3600

Error-Info: <sip:[email protected]>3601



22.19 Expires3602

TheExpires header field gives the date and time after which the message (or content) expires. The precise3603

meaning of this is method dependent.3604

Note that the expiration time in anINVITE doesnot affect the duration of the actual session that may3605

result from the invitation. Session description protocols may offer the ability to express time limits on the3606

session duration, however.3607

The value of this field can be either a date (see theDate header field) or an integer number of seconds3608

(in decimal), measured from the receipt of the request. The latter approach is preferable for short durations,3609

as it does not depend on clients and servers sharing a synchronized clock.3610

Examples:3611

Expires: Thu, 01 Dec 1994 16:00:00 GMT3612

Expires: 53613

22.20 From3614

TheFrom header field indicates the initiator of the request. (Note that this may be different from the initiator3615

of the dialog. Requests sent by the callee to the caller use the callee’s address in theFrom header field.)3616

The optional “display-name” is meant to be rendered by a human user interface. A systemSHOULD3617

use the display name “Anonymous” if the identity of the client is to remain hidden.3618

Even if the “display-name” is empty, the “name-addr” form MUST be used if the “addr-spec” con-3619

tains a comma, question mark, or semicolon. Syntax issues are discussed in Section 7.3.1.3620

The short form of the header isf.3621

Examples:3622

From: "A. G. Bell" <sip:[email protected]> ;tag=a48s3623

From: sip:[email protected];tag=887s3624

f: Anonymous <sip:[email protected]>;tag=hyh83625

22.21 In-Reply-To3626

The In-Reply-To header field enumerates theCall-IDs that this call references or returns. TheseCall-IDs3627

may have been cached by the client then included in this header in a return call.3628

This allows automatic call distribution systems to route return calls to the originator of the first call and allows3629

callees to filter calls, so that only calls that return calls they have originated will be accepted. This field is not a3630

substitute for request authentication.3631

Example:3632

In-Reply-To: [email protected], [email protected]

22.22 Max-Forwards3634

TheMax-Forwards header field may be used with any SIP method to limit the number of proxies or gate-3635

ways that can forward the request to the next downstream server. This can also be useful when the client is3636

attempting to trace a request chain which appears to be failing or looping in mid-chain.3637



The Max-Forwards value is a decimal integer indicating the remaining number of times this request3638

message is allowed to be forwarded. This count is decremented by each server that forwards the request.3639

Example:3640

Max-Forwards: 63641

22.23 MIME-Version3642

See [H19.4.1].3643

Example:3644

MIME-Version: 1.03645

22.24 Organization3646

TheOrganization header field conveys the name of the organization to which the entity issuing the request3647

or response belongs.3648

The fieldMAY be used by client software to filter calls.3649

Example:3650

Organization: Boxes by Bob3651

22.25 Priority3652

The Priority header field indicates the urgency of the request as perceived by the client. Defined values3653

include “non-urgent”, “normal”, “urgent”, and “emergency”.3654

It is RECOMMENDED that the value of “emergency” only be used when life, limb or property are in3655

imminent danger. Otherwise, there are no semantics defined for this header field.3656

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

Examples:3658

Subject: A tornado is heading our way!3659

Priority: emergency3660

or3661

Subject: Weekend plans3662

Priority: non-urgent3663

22.26 Proxy-Authenticate3664

TheProxy-Authenticate header field consists of a challenge that indicates the authentication scheme and3665

parameters applicable to the proxy for thisRequest-URI.3666

The syntax for this header and use is defined in [H14.33]. See 20.2.3 for further details on its usage.3667

Example:3668



Proxy-Authenticate: Digest realm="Carrier SIP",3669

domain="sip:ss1.carrier.com",3670

nonce="f84f1cec41e6cbe5aea9c8e88d359",3671

opaque="", stale=FALSE, algorithm=MD53672

22.27 Proxy-Authorization3673

The Proxy-Authorization header field allows the client to identify itself (or its user) to a proxy which3674

requires authentication. TheProxy-Authorization field value consists of credentials containing the authen-3675

tication information of the user agent for the proxy and/or realm of the resource being requested.3676

See [H14.34] for a definition of the syntax, and section 20.2.3 for a discussion of its usage.3677

Note that this header field, along withAuthorization breaks the general rules about multiple header3678

fields. Although not a comma-separated list, this header field may be present multiple times, andMUST NOT3679

be combined into a single header using the usual rules described in Section 7.3.1.3680

Example:3681

Proxy-Authorization: Digest username="Alice", realm="Atlanta ISP",3682

nonce="c60f3082ee1212b402a21831ae",3683

response="245f23415f11432b3434341c022"3684

22.28 Proxy-Require3685

TheProxy-Require header field is used to indicate proxy-sensitive features that must be supported by the3686

proxy. See Section 22.30 for more details on the mechanics of this message and a usage example.3687

Example:3688

Proxy-Require: foo3689

22.29 Record-Route3690

TheRecord-Route is inserted by proxies in a request to force future requests in the session to route through3691

the proxy.3692

Details of its use with theRoute header field are described in Section 16.4.3693

Example:3694

Record-Route: <sip:[email protected];maddr=10.1.1.1>,3695

<sip:[email protected];maddr=10.2.1.1>3696

22.30 Require3697

TheRequire header field is used by clients to tell user agent servers about options that the client expects the3698

server to support in order to properly process the request. Although an optional header, theRequire MUST3699

NOT be ignored if it is present.3700

This is to make sure that the client-server interaction will proceed without delay when all options are understood3701

by both sides, and only slow down if options are not understood (as in the example above). For a well-matched3702

client-server pair, the interaction proceeds quickly, saving a round-trip often required by negotiation mechanisms.3703



In addition, it also removes ambiguity when the client requires features that the server does not understand. Some3704

features, such as call handling fields, are only of interest to end systems.3705

Example:3706

Require: com.example.billing3707

22.31 Retry-After3708

TheRetry-After header field can be used with a 503 (Service Unavailable) response to indicate how long3709

the service is expected to be unavailable to the requesting client and with a 404 (Not Found), 600 (Busy), or3710

603 (Decline) response to indicate when the called party anticipates being available again. The value of this3711

field can be either anSIP-date or an integer number of seconds (in decimal) after the time of the response.3712

An optional comment can be used to indicate additional information about the time of callback. An3713

optional “duration” parameter indicates how long the called party will be reachable starting at the initial3714

time of availability. If no duration parameter is given, the service is assumed to be available indefinitely.3715

Examples:3716

Retry-After: Mon, 21 Jul 1997 18:48:34 GMT (I’m in a meeting)3717

Retry-After: Mon, 01 Jan 9999 00:00:00 GMT3718

(Dear John: Don’t call me back, ever)3719

Retry-After: Fri, 26 Sep 1997 21:00:00 GMT;duration=36003720

Retry-After: 1203721

In the third example, the callee is reachable for one hour starting at 21:00 GMT. In the last example, the3722

delay is 2 minutes.3723

22.32 Route3724

TheRoute is used to force routing for a request through the listed set of proxies. Details of its use with the3725

Record-Route header field are described in Section 13.3726

Example:3727

Route: <sip:[email protected];maddr=10.1.1.1>, <sip:[email protected]>3728

22.33 Server3729

TheServer header field contains information about the software used by the user agent server to handle the3730

request. The syntax for this field is defined in [H14.38].3731

Example:3732

Server: HomeProxy v23733

22.34 Subject3734

This header field provides a summary or indicates the nature of the call, allowing call filtering without having3735

to parse the session description. (Note that the session description does not have to use the same subject3736

indication as the invitation.)3737



The short form of the header iss.3738

Example:3739

Subject: Need more boxes3740

s: Tech Support3741

22.35 Supported3742

The Supported header field enumerates all the extensions upported by the client or server. If empty, it3743

means that no extensions are supported.3744

Example:3745

Supported: foo, bar3746

22.36 Timestamp3747

TheTimestamp header field describes when the client sent the request to the server. The use of theTimes-3748

tamp is covered in Section 13.3749

Example:3750

Timestamp: 543751

22.37 To3752

TheTo header field specifies the logical recipient of the request.3753

The optional “display-name” is meant to be rendered by a human-user interface. The “tag” parameter3754

serves as a general mechanism to distinguish multiple instances of a user identified by a single SIP URL.3755

See Section 13 for details of the “tag” parameter.3756

Section 22.20 describes howTo and From header fields are compared for the purpose of matching3757

requests to dialogs. Even if the “display-name” is empty, the “name-addr” form MUST be used if the3758

“addr-spec” contains a comma, question mark, or semicolon. Note that LWS is common, butnot manda-3759

tory between thedisplay-name and the “<”.3760

The short form of the header ist.3761

The following are examples of validTo headers:3762

To: The Operator <sip:[email protected]>;tag=2874473763

t: sip:[email protected]

22.38 Unsupported3765

TheUnsupported header field lists the features not supported by the server. See Section 22.30 for a usage3766

example and motivation.3767

Example:3768

Unsupported: foo3769



22.39 User-Agent3770

TheUser-Agent header field contains information about the client user agent originating the request. The3771

syntax and semantics are defined in [H14.43].3772

Example:3773

User-Agent: Softphone Beta1.53774

22.40 Via3775

TheVia field indicates the path taken by the request so far and indicate the path that should be followed in3776

routing responses.3777

TheVia header field contains the transport protocol used to send the message, the client’s host name or3778

network address and, if not the default port number, the port number at which it wishes to receive responses.3779

TheVia header field can also contains parameters such as “maddr”, “ ttl”, “ received”, and “branch”whose3780

meaning and use are described in other sections.3781

The short form of the header isv.3782

Example:3783

Via: SIP/2.0/UDP erlang.bell-telephone.com:50603784

Via: SIP/2.0/UDP 128.59.16.1:5060 ;received=128.59.19.33785

In this example, the message originated from a multi-homed host with two addresses, 128.59.16.13786

and 128.59.19.3. The sender guessed wrong as to which network interface would be used. Erlang.bell-3787

telephone.com noticed the mismatch, and added a parameter to the previous hop’sVia header field, contain-3788

ing the address that the packet actually came from.3789

Another example:3790

Via: SIP/2.0/UDP first.example.com:4000;ttl=163791

;maddr=224.2.0.1 ;branch=a7c6a8dlze.13792

22.41 Warning3793

TheWarning header field is used to carry additional information about the status of a response.Warning3794

headers are sent with responses and contain a three digit warning code, host name, and warning text.3795

The “warn-text” should be in a natural language that is most likely to be intelligible to the human user3796

receiving the response. This decision can be based on any available knowledge, such as the location of the3797

cache or user, theAccept-Language field in a request, or theContent-Language field in a response. The3798

default language is i-default [38].3799

The first digit of warning codes beginning with “3” indicates warnings specific to SIP.3800

This is a list of the currently-defined “warn-code”s, each with a recommended warn-text in English, and3801

a description of its meaning. Note that these warnings describe failures induced by the session description.3802

Warnings 300 through 329 are reserved for indicating problems with keywords in the session description,3803

330 through 339 are warnings related to basic network services requested in the session description, 3703804

through 379 are warnings related to quantitative QoS parameters requested in the session description, and3805

390 through 399 are miscellaneous warnings that do not fall into one of the above categories.3806



300 Incompatible network protocol: One or more network protocols contained in the session description3807

are not available.3808

301 Incompatible network address formats: One or more network address formats contained in the ses-3809

sion description are not available.3810

302 Incompatible transport protocol: One or more transport protocols described in the session descrip-3811

tion are not available.3812

303 Incompatible bandwidth units: One or more bandwidth measurement units contained in the session3813

description were not understood.3814

304 Media type not available: One or more media types contained in the session description are not avail-3815

able.3816

305 Incompatible media format: One or more media formats contained in the session description are not3817

available.3818

306 Attribute not understood: One or more of the media attributes in the session description are not sup-3819

ported.3820

307 Session description parameter not understood:A parameter other than those listed above was not3821

understood.3822

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

331 Unicast not available: The site where the user is located does not support unicast communication (usu-3824

ally due to the presence of a firewall).3825

370 Insufficient bandwidth: The bandwidth specified in the session description or defined by the media3826

exceeds that known to be available.3827

399 Miscellaneous warning:The warning text can include arbitrary information to be presented to a hu-3828

man user, or logged. A system receiving this warningMUST NOT take any automated action.3829

1xx and 2xx have been taken by HTTP/1.1.3830

If the warning is caused by the session description, the status responseSHOULD include a session de-3831

scription similar to that included inOPTIONS responses indicating the capabilities of the UAS. Additional3832

“warn-code”s, as in the example below, can be defined through IANA.3833

Examples:3834

Warning: 307 isi.edu "Session parameter ’foo’ not understood"3835

Warning: 301 isi.edu "Incompatible network address type ’E.164’"3836

22.42 WWW-Authenticate3837

TheWWW-Authenticate header field consists of a challenge that indicates the authentication scheme and3838

parameters applicable for thisRequest-URI.3839

The syntax for this header and use is defined in [H14.47]. See 20.2.2 for further details on its usage.3840

Example:3841



WWW-Authenticate: Digest realm="Bob’s Friends",3842

domain="sip:boxesbybob.com",3843

nonce="f84f1cec41e6cbe5aea9c8e88d359",3844

opaque="", stale=FALSE, algorithm=MD53845

23 Response Codes3846

The response codes are consistent with, and extend, HTTP/1.1 response codes. Not all HTTP/1.1 response3847

codes are appropriate, and only those that are appropriate are given here. Other HTTP/1.1 response codes3848

SHOULD NOT be used. Response codes not defined by HTTP/1.1 have codes x80 upwards to avoid clashes3849

with future HTTP response codes. Also, SIP defines a new class, 6xx. The default behavior for unknown3850

response codes is given for each category of codes.3851

23.1 Provisional 1xx3852

Provisional responses indicate that the server or proxy contacted is performing some further action and does3853

not yet have a definitive response. A server typically sends a 1xx response if it expects to takemore than3854

200 ms to obtain a final response. Note that 1xx responses are not transmitted reliably, that is, they do not3855

cause the client to send anACK.3856

Provisional (1xx) responsesMAY contain message bodies, including session descriptions.3857

Provisional responses are also known as informational responses.3858

23.1.1 100 Trying3859

This response indicates that the request has been received by the next hop server and that some unspeci-3860

fied action is being taken on behalf of this call (e.g., a database is being consulted). This response stops3861

retransmissions of anINVITE by a UAC.3862

23.1.2 180 Ringing3863

The user agent receiving theINVITE is trying to alert the user. This response MAY be used to initiate local3864

ringback.3865

23.1.3 181 Call Is Being Forwarded3866

A proxy serverMAY use this status code to indicate that the call is being forwarded to a different set of3867

destinations.3868

23.1.4 182 Queued3869

The called party is temporarily unavailable, but the callee has decided to queue the call rather than reject it.3870

When the callee becomes available, it will return the appropriate final status response. The reason phrase3871

MAY give further details about the status of the call, e.g., “5 calls queued; expected waiting time is 153872

minutes”. The serverMAY issue several 182 responses to update the caller about the status of the queued3873

call.3874



23.1.5 183 Session Progress3875

The 183 (Session Progress) response is used to convey information about the progress of the call which is3876

not otherwise classified. TheReason-Phrase, header fields, or message bodyMAY be used to convey more3877

details about the call progress.3878

23.2 Successful 2xx3879

The request was successful.3880

23.2.1 200 OK3881

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

request.3883

23.3 Redirection 3xx3884

3xx responses give information about the user’s new location, or about alternative services that might be3885

able to satisfy the call.3886

23.3.1 300 Multiple Choices3887

The address in the request resolved to several choices, each with its own specific location, and the user (or3888

user agent) can select a preferred communication end point and redirect its request to that location.3889

The responseMAY include a message body containing a list of resource characteristics and location(s)3890

from which the user or user agent can choose the one most appropriate, if allowed by theAccept request3891

header.3892

The choicesSHOULD also be listed asContact fields (Section 22.10). Unlike HTTP, the SIP response3893

MAY contain severalContact fields or a list of addresses in aContact field. User agentsMAY use the3894

Contact header field value for automatic redirection orMAY ask the user to confirm a choice. However, this3895

specification does not define any standard for such automatic selection.3896

This status response is appropriate if the callee can be reached at several different locations and the server cannot3897

or prefers not to proxy the request.3898

23.3.2 301 Moved Permanently3899

The user can no longer be found at the address in theRequest-URI and the requesting clientSHOULD retry3900

at the new address given by theContact header field (Section 22.10). The callerSHOULD update any local3901

directories, address books and user location caches with this new value and redirect future requests to the3902

address(es) listed.3903

23.3.3 302 Moved Temporarily3904

The requesting clientSHOULD retry the request at the new address(es) given by theContact header field3905

(Section 22.10). TheRequest-URI of the new request uses the value of theContact header in the response.3906

The new request can take two different forms. In the first approach, theTo, From, Call-ID, andCSeq3907

header fields in the new request are the same as in the original request, with a newbranch identifier in the3908



Via header field. ProxiesMUST follow this behavior and UACsMAY . In the second approach, UAsMAY3909

also use theContact information for theTo header field, as well as a newCall-ID value.3910

The duration of the redirection can be indicated through anExpires (Section 22.19) header. If there is3911

no explicit expiration time, the address is only valid for this call andMUST NOT be cached for future calls.3912

23.3.4 305 Use Proxy3913

The requested resourceMUST be accessed through the proxy given by theContact field. TheContact3914

field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 3053915

responsesMUST only be generated by user agent servers.3916

23.3.5 380 Alternative Service3917

The call was not successful, but alternative services are possible. The alternative services are described in3918

the message body of the response. Formats for such bodies are not defined here, and may be the subject of3919

future standardization.3920

23.4 Request Failure 4xx3921

4xx responses are definite failure responses from a particular server. The clientSHOULD NOT retry the3922

same request without modification (e.g., adding appropriate authorization). However, the same request to a3923

different server might be successful.3924

23.4.1 400 Bad Request3925

The request could not be understood due to malformed syntax. TheReason-Phrase SHOULD identify the3926

syntax problem in more detail, e.g., “Missing Call-ID header”.3927

23.4.2 401 Unauthorized3928

The request requires user authentication. This response is issued by user agent servers and registrars, while3929

407 (Proxy Authentication Required) is used by proxy servers.3930

23.4.3 402 Payment Required3931

Reserved for future use.3932

23.4.4 403 Forbidden3933

The server understood the request, but is refusing to fulfill it. Authorization will not help, and the request3934

SHOULD NOT be repeated.3935

23.4.5 404 Not Found3936

The server has definitive information that the user does not exist at the domain specified in theRequest-3937

URI. This status is also returned if the domain in theRequest-URI does not match any of the domains3938

handled by the recipient of the request.3939



23.4.6 405 Method Not Allowed3940

The method specified in theRequest-Line is not allowed for the address identified by theRequest-URI.3941

The responseMUST include anAllow header field containing a list of valid methods for the indicated address.3942

23.4.7 406 Not Acceptable3943

The resource identified by the request is only capable of generating response entities which have content3944

characteristics not acceptable according to the accept headers sent in the request.3945

23.4.8 407 Proxy Authentication Required3946

This code is similar to 401 (Unauthorized), but indicates that the clientMUST first authenticate itself with3947

the proxy. SIP access authentication is explained in section 20 and 20.2.3.3948

This status code can be used for applications where access to the communication channel (e.g., a tele-3949

phony gateway) rather than the callee requires authentication.3950

23.4.9 408 Request Timeout3951

The server could not produce a response within a suitable amount of time, for example, if it could not3952

determine the location of the user in time. The clientMAY repeat the request without modifications at any3953

later time.3954

23.4.10 410 Gone3955

The requested resource is no longer available at the server and no forwarding address is known. This3956

condition is expected to be considered permanent. If the server does not know, or has no facility to determine,3957

whether or not the condition is permanent, the status code 404 (Not Found)SHOULD be used instead.3958

23.4.11 413 Request Entity Too Large3959

The server is refusing to process a request because the request entity is larger than the server is willing or3960

able to process. The server MAY close the connection to prevent the client from continuing the request.3961

If the condition is temporary, the serverSHOULD include aRetry-After header field to indicate that it is3962

temporary and after what time the clientMAY try again.3963

23.4.12 414 Request-URI Too Long3964

The server is refusing to service the request because theRequest-URI is longer than the server is willing to3965

interpret.3966

23.4.13 415 Unsupported Media Type3967

The server is refusing to service the request because the message body of the request is in a format not sup-3968

ported by the server for the requested method. The serverSHOULD return a list of acceptable formats using3969

theAccept, Accept-Encoding andAccept-Language header fields. UAC processing of this response is3970

described in Section 8.1.3.4.3971



23.4.14 420 Bad Extension3972

The server did not understand the protocol extension specified in aProxy-Require (Section 22.28) orRe-3973

quire (Section 22.30) header field. The serverSHOULD include a list of the unsupported extensions in an3974

Unsupported header in the response. UAC processing of this response is described in Section 8.1.3.4.3975

23.4.15 421 Extension Required3976

The UAS needs a particular extension to process the request, but this extension is not listed in aSupported3977

header in the request. Responses with this status codeMUST contain aRequire header listing the required3978

extensions.3979

In general, a UASSHOULD NOTuse this response when it wishes to apply an extension to a request. The3980

end result will often be no service at all, and a break in interoperability. Rather, serversSHOULD process the3981

request using baseline SIP capabilities and any extensions supported by the client.3982

23.4.16 480 Temporarily Unavailable3983

The callee’s end system was contacted successfully but the callee is currently unavailable (e.g., not logged3984

in, logged in in such a manner as to preclude communication with the callee or activated the “do not disturb”3985

feature). The responseMAY indicate a better time to call in theRetry-After header. The user could also be3986

available elsewhere (unbeknownst to this host). The reason phraseSHOULD indicate a more precise cause3987

as to why the callee is unavailable. This valueSHOULD be setable by the user agent. Status 486 (Busy Here)3988

MAY be used to more precisely indicate a particular reason for the call failure.3989

This status is also returned by a redirect server that recognizes the user identified by theRequest-URI,3990

but does not currently have a valid forwarding location for that user.3991

23.4.17 481 Call/Transaction Does Not Exist3992

This status indicates that the UAS received a request that does not match any existing dialog or transaction.3993

23.4.18 482 Loop Detected3994

The server has detected a loop (Section 3).3995

23.4.19 483 Too Many Hops3996

The server received a request that contains aMax-Forwards (Section 22.22) header with the value zero.3997

23.4.20 484 Address Incomplete3998

The server received a request with aRequest-URI that was incomplete. Additional informationSHOULD3999

be provided.4000

This status code allows overlapped dialing. With overlapped dialing, the client does not know the length of the4001

dialing string. It sends strings of increasing lengths, prompting the user for more input, until it no longer receives a4002

484 status response.4003



23.4.21 485 Ambiguous4004

The callee address provided in the request was ambiguous. The responseMAY contain a listing of possible4005

unambiguous addresses inContact headers.4006

Revealing alternatives can infringe on privacy concerns of the user or the organization. ItMUST be4007

possible to configure a server to respond with status 404 (Not Found) or to suppress the listing of possible4008

choices if the request address was ambiguous.4009

Example response to a request with the [email protected] :4010

485 Ambiguous SIP/2.04011

Contact: Carol Lee <sip:[email protected]>4012

Contact: Ping Lee <sip:[email protected]>4013

Contact: Lee M. Foote <sip:[email protected]>4014

Some email and voice mail systems provide this functionality. A status code separate from 3xx is used since4015

the semantics are different: for 300, it is assumed that the same person or service will be reached by the choices4016

provided. While an automated choice or sequential search makes sense for a 3xx response, user intervention is4017

required for a 485 response.4018

23.4.22 486 Busy Here4019

The callee’s end system was contacted successfully but the callee is currently not willing or able to take4020

additional calls at this end system. The responseMAY indicate a better time to call in theRetry-After4021

header. The user could also be available elsewhere, such as through a voice mail service. Status 600 (Busy4022

Everywhere)SHOULD be used if the client knows that no other end system will be able to accept this call.4023

23.4.23 487 Request Terminated4024

The request was terminated by aBYE or CANCEL request. This response is never returned for aCANCEL4025

request itself.4026

23.4.24 488 Not Acceptable Here4027

The response has the same meaning as 606 (Not Acceptable), but only applies to the specific entity addressed4028

by theRequest-URI and the request may succeed elsewhere.4029

23.5 Server Failure 5xx4030

5xx responses are failure responses given when a server itself has erred.4031

23.5.1 500 Server Internal Error4032

The server encountered an unexpected condition that prevented it from fulfilling the request. The clientMAY4033

display the specific error condition, andMAY retry the request after several seconds.4034

If the condition is temporary, the serverMAY indicate when the client may retry the request using the4035

Retry-After header.4036



23.5.2 501 Not Implemented4037

The server does not support the functionality required to fulfill the request. This is the appropriate response4038

when a UAS does not recognize the request method and is not capable of supporting it for any user. (Proxies4039

forward all requests regardless of method.)4040

23.5.3 502 Bad Gateway4041

The server, while acting as a gateway or proxy, received an invalid response from the downstream server it4042

accessed in attempting to fulfill the request.4043

23.5.4 503 Service Unavailable4044

The server is currently unable to handle the request due to a temporary overloading (i.e., congestion) or4045

maintenance of the server. The implication is that this is a temporary condition which will be alleviated4046

after some delay. If known, the length of the delayMAY be indicated in aRetry-After header. If noRetry-4047

After is given, the clientMUST handle the response as it would for a 500 response.4048

A client (proxy or UAC) receiving a 503SHOULD attempt to forward the request to an alternate server. It4049

SHOULD NOT forward any other requests to that server for the duration specified in theRetry-After header,4050

if present.4051

Note: The existence of the 503 status code does not imply that a server has to use it when becoming4052

overloaded. Some serversMAY wish to simply refuse the connection.4053

23.5.5 504 Server Time-out4054

The server did not receive a timely response from the server (e.g., a location server) it accessed in attempting4055

to process the request. Note that 408 (Request Timeout) should be used if there was no response within the4056

period specified in theExpires header field from the upstream server.4057

23.5.6 505 Version Not Supported4058

The server does not support, or refuses to support, the SIP protocol version that was used in the request4059

message. The server is indicating that it is unable or unwilling to complete the request using the same major4060

version as the client, other than with this error message. The responseMAY contain an entity describing why4061

that version is not supported and what other protocols are supported by that server. The format for such an4062

entity is not defined here and may be the subject of future standardization.4063

23.5.7 513 Message Too Large4064

The server was unable to process the request since the message length exceeded its capabilities.4065

23.6 Global Failures 6xx4066

6xx responses indicate that a server has definitive information about a particular user, not just the particular4067

instance indicated in theRequest-URI.4068



23.6.1 600 Busy Everywhere4069

The callee’s end system was contacted successfully but the callee is busy and does not wish to take the call4070

at this time. The responseMAY indicate a better time to call in theRetry-After header. If the callee does4071

not wish to reveal the reason for declining the call, the callee uses status code 603 (Decline) instead. This4072

status response is returned only if the client knows that no other end point (such as a voice mail system) will4073

answer the request. Otherwise, 486 (Busy Here) should be returned.4074

23.6.2 603 Decline4075

The callee’s machine was successfully contacted but the user explicitly does not wish to or cannot partici-4076

pate. The responseMAY indicate a better time to call in theRetry-After header.4077

23.6.3 604 Does Not Exist Anywhere4078

The server has authoritative information that the user indicated in theRequest-URI does not exist anywhere.4079

23.6.4 606 Not Acceptable4080

The user’s agent was contacted successfully but some aspects of the session description such as the requested4081

media, bandwidth, or addressing style were not acceptable.4082

A 606 (Not Acceptable) response means that the user wishes to communicate, but cannot adequately sup-4083

port the session described. The 606 (Not Acceptable) responseMAY contain a list of reasons in aWarning4084

header field describing why the session described cannot be supported. Reasons are listed in Section 22.41.4085

It is hoped that negotiation will not frequently be needed, and when a new user is being invited to join an4086

already existing conference, negotiation may not be possible. It is up to the invitation initiator to decide4087

whether or not to act on a 606 (Not Acceptable) response.4088

24 Locating a SIP Server4089

NOTE: Usage of SRV records is still under discussion with IESG, and therefore this section is likely to change4090

in subsequent versions of bis.4091

The SIP URI provides a way to identify a communications resource. For this URI to be useful in a SIP4092

element, a mechanism is necessary to take this URI and determine the IP address, port, and transport of one4093

or more servers that message destined for this URI should be sent to. We refer to the combination of an4094

IP address, port, and transport as anext hop. There are two ways to determine the next hop. The next hop4095

can be configured to be the same for all URIs. In this case, the next hop is referred to as aoutbound proxy.4096

This is commonly used in a user agent which is required to send all requests to a specific server for policy4097

processing or firewall traversal, for example. The outbound proxy can be configured by any mechanism,4098

including DHCP [39].4099

When the next hop is not configured, a mechanism is needed to determine one or more next hops from4100

the URI. Section 24.1 provides an algorithm which can be used to determine an ordered list of next hops.4101

Typically, the URI that is used is from theRequest-URI of a request, in order to determine where to send4102

that request. However, in certain circumstances (which are documented in Section 19.2.2), a URI may have4103

been extracted from a response in order to determine where to send the response.4104



Once the ordered list of next hops is computed, they are used according to the procedures of Section4105

24.2.4106

24.1 Computing the List of Next Hops4107

The algorithm for computing the list of next hops begins by setting three variables. The first variable is4108

called thetarget address. The target addressMUST be set to the contents of themaddr parameter of the4109

URI, if present. If not present, itMUST be set to thehost element of the URI. The next variable is called the4110

target port. The target portMUST be set to theport element of the URI if present, else the target portMUST4111

remain empty. The target transportMUST be set to the headertransport element of the URI if present, else4112

the target transportMUST remain empty.4113

The algorithm begins by examining the target address. If it contains a numeric IP address, the procedures4114

of Section 24.1.1MUST be followed. Otherwise, the target transport is examined. If it is empty, and the4115

target port is either empty or contains a value of 5060, the procedures of Section 24.1.2MUST be followed.4116

If the target transport is not empty, and the target port is empty, the procedures of Section 24.1.2MUST be4117

followed if the target transport is UDP. If the target transport and target port are not empty, but the target4118

port contains the default port for the target transport (5060 for UDP, TCP, and SCTP, 5061 for TLS), the4119

procedures of Section 24.1.2MUST also be followed. Otherwise, the procedures of Section 24.1.3MUST be4120

followed. Effectively, this case occurs when the target port and target transport don’t “match”, taking into4121

account their defaults if empty.4122

24.1.1 Numeric Destination Address4123

The addresses of the next hops are all the same, andMUST be equal to the value of the target address.4124

If the target transport is specified, and the element supports that transport, there is only a single next4125

hop, using the target transport. If the target transport is not specified, the number of next hops is equal to4126

the number of transports the element supports. The first next hopMUST be UDP, and the ordering of the4127

remaining transports is at the discretion of the element.4128

For each next hop, the port number is equal to the target port, if specified, otherwise the default port for4129

that transport of that next hop.4130

For example, consider the SIP URIsip:[email protected] present in theRequest-URI of a request. A4131

UAC wishes to use this URI to determine the set of next hops. The UAC supports UDP and TLS. It applies4132

the algorithm in this section, and ends up with the following ordered list of IP address, port, transport:4133

{1.2.3.4, 5060, UDP}4134

{1.2.3.4, 5061, TLS}4135

24.1.2 SRV Resolution of Host Name4136

DNS SRV records are retrieved according to RFC 2782 [40]. The service identifier for DNS SRV records is4137

“ sip”. If the target transport is not empty, only records for that transport are retrieved. (If the element does4138

not support the transport specified, the lookup fails.) If the target transport is empty, the element retrieves4139

records for all transport protocols it supports. The results of all queries are merged and then sorted according4140

to priority, independent of the transport protocol. If this list is empty, follow the procedure in Section 24.1.3.4141

Note that the behavior above differs slightly from that described in RFC 2782. There, A records are4142

consulted if the query for one transport protocol fails; here, we only abandon the SRV lookup if none of the4143



transport protocols supported by the client yield an answer.4144

ClientsMUST NOT cache query results except according to the rules in RFC 1035 [41].4145

24.1.3 Address Record Resolution of Host Name4146

When the target address is not a numeric IP, and there is a target port which does not match the default port4147

for the target transport, SRV records are not used. This is because SRV will normally provide ports, so if4148

one is provided that is not a default, this would seem to imply the the URL is trying to explicitly identify the4149

destination, rather than using SRV.4150

In this case, the client queries the DNS server for address records for the destination address. Address4151

records include A RR’s, AAAA RR’s, or other similar records, chosen according to the client’s network4152

protocol capabilities.4153

The DNS address records are kept sorted in the order returned by the DNS server. For each address, the4154

port is set to the target port. For each address, the transport is set to the target transport if not empty, other-4155

wise, the target transportMUST be UDP for the first address, and is at the discretion of the implementation4156

for the others.4157

OPEN ISSUE #221: Selection of transports for the case when multiple A records are returned requires more4158

work.4159

ClientsMUST NOT cache query results except according to the rules in RFC 1035 [41].4160

24.2 Contacting the Next Hops4161

The algorithms of the previous section will result in an ordered list of next hops. This section describes how4162

that list is used.4163

If the ordered list was obtained through SRV, servers are contacted as specified in the “Usage rules”4164

section of RFC 2782 [40], which describes procedures for using the weight field to randomly select servers4165

amongst those of equal priority.4166

The SIP element takes the ordered list, and it tries to contact each next hop in turn, until a server4167

responds. If contacting a next hop results in a failure, as defined in the next paragraph, the element moves4168

to the next next hop in the list, until the list is exhausted. If the list is exhausted, then the element gives up.4169

FailuresSHOULD be detected through network failure indications or timeouts. If the element sending the4170

message is a client sending a request using a client transaction, the client transaction will report any transport4171

layer failures. If the element sending the message is a client sending a request directly to the transport layer,4172

the transport layer will report any failures (See Section 19.4). In either case, the clientSHOULD try the4173

next address. This will involve creating a new client transaction for it in the former case. The new request4174

MUST have a new branch ID in theVia header. Note also that the new destination might be with a different4175

transport, which might require a change in other parts of theVia header.4176

Response failures are handled by the transport layer itself, which may retry the response to the next next4177

hop. See Section 19.2.2.4178

Failures can be detected through timeouts only if the element is a client sending a request through the4179

client transaction. In that case, if a timeout is reported by the client transaction, the clientSHOULD try the4180

next next hop in the list.4181

OPEN ISSUE #219: It might be easier to encapsulate the SRV processing in one place, at the transport layer,4182

rather than the behavior being dependent on client v. server. This can only be done if merging of srv records across4183

transports is deprecated, along with failures based on timeouts.4184



Once a next hop is successfully contacted, that same next hop addressMUST be used for all subsequent4185

messages that share the sameCall-ID. More specifically, once a request is delivered successfully to a par-4186

ticular next hop, all subsequent requests with the sameCall-ID MUST be delivered to that next hop. Once a4187

response is delivered successfully to a particular next hop, all subsequent responses with the sameCall-ID4188

MUST be delivered to that next hop. However, if that next hop fails, the selection algorithmsMUST be re-run4189

for the top.4190

This is a change from RFC2543, which only used the same address for requests within a transaction. Broadening4191

the scope toCall-ID helps, for example, ensure that requests with credentials after a challenge are delivered to the4192

same server that issued the challenge.4193

A stateless proxy can accomplish this, for example, by using the moduloN of a hash of theCall-ID4194

value as the uniform random number described in the weighting algorithm of RFC 2782 [40]. Here,N is4195

the sum of weights within the priority class.4196

OPEN ISSUE #220: This stateless selection algorithm doesn’t work if there are failures.4197

25 Examples4198

In the following examples, we often omit the message body and the correspondingContent-Length and4199

Content-Type headers for brevity.4200

25.1 Registration4201

Bob registers on start-up. The message flow is shown in Figure 9.4202

��

� � ��

� ��

��

Figure 9: SIP Registration Example

4203

F1 REGISTER Bob -> Registrar4204

4205

REGISTER sip:registrar.biloxi.com4206

Via: SIP/2.0/UDP 10.4.1.4:50604207


From: Bob <sip:[email protected]>;tag=4562484209




CSeq: 1826 REGISTER4211


Expires: 72004213


The registration expires after two hours. The registrar responds with a 200 OK:4215

4216

F2 200 OK Registrar -> Bob4217

4218

SIP/2.0 200 OK4219

Via: SIP/2.0/UDP 10.4.1.4:50604220


From: Bob <sip:[email protected]>;tag=4562484222


CSeq: 1826 REGISTER4224


Expires: 72004226


4228

25.2 Session Setup4229

This example contains the full details of the example session setup in Section 4. The message flow is shown4230

in Figure 1.4231

4232

F1 INVITE Alice -> atlanta.com proxy4233

4234


Via: SIP/2.0/UDP 10.1.3.3:50604236








4244


4246

F2 100 Trying atlanta.com proxy -> Alice4247

4248



SIP/2.0 100 Trying4249

Via: SIP/2.0/UDP 10.1.3.3:50604250






4256

F3 INVITE atlanta.com proxy -> biloxi.com proxy4257

4258



Via: SIP/2.0/UDP 10.1.3.3:50604261








4269


4271

F4 100 Trying biloxi.com proxy -> atlanta.com proxy4272

4273

SIP/2.0 100 Trying4274


Via: SIP/2.0/UDP 10.1.3.3:50604276






4282

F5 INVITE biloxi.com proxy -> Bob4283

4284




Via: SIP/2.0/UDP 10.1.3.3:50604288










4296


4298

F6 180 Ringing Bob -> biloxi.com proxy4299

4300

SIP/2.0 180 Ringing4301



Via: SIP/2.0/UDP 10.1.3.3:50604304






4310

F7 180 Ringing biloxi.com proxy -> atlanta.com proxy4311

4312



Via: SIP/2.0/UDP 10.1.3.3:50604315






4321

F8 180 Ringing atlanta.com proxy -> Alice4322

4323


Via: SIP/2.0/UDP 10.1.3.3:50604325






4331



F9 200 OK Bob -> biloxi.com proxy4332

4333

SIP/2.0 200 OK4334



Via: SIP/2.0/UDP 10.1.3.3:50604337








4345


4347

F10 200 OK biloxi.com proxy -> atlanta.com proxy4348

4349

SIP/2.0 200 OK4350


Via: SIP/2.0/UDP 10.1.3.3:50604352








4360


4362

F11 200 OK atlanta.com proxy -> Alice4363

4364

SIP/2.0 200 OK4365

Via: SIP/2.0/UDP 10.1.3.3:50604366








4374




4376

F12 ACK Alice -> Bob4377

4378

ACK sip:[email protected] SIP/2.04379

Via: SIP/2.0/UDP 10.1.3.3:50604380




CSeq: 314159 ACK4384


The media session between Alice and Bob is now established.4386

Bob hangs up first. Note that Bob’s SIP phone maintains its ownCSeq numbering space, which, in this4387

example, begins with 231. Also not that since Bob is making the request, theTo andFrom URLs and tags4388

have been swapped.4389

4390

F13 BYE Bob -> Alice4391

4392

BYE sip:[email protected] SIP/2.04393

Via: SIP/2.0/UDP 10.4.1.4:50604394

From: Bob <sip:[email protected]>;tag=a6c85cf4395

To: Alice <sip:[email protected]>;tag=19283017744396


CSeq: 231 BYE4398


4400

F14 200 OK Alice -> Bob4401

4402

SIP/2.0 200 OK4403

Via: SIP/2.0/UDP 10.4.1.4:50604404

From: Bob <sip:[email protected]>;tag=a6c85cf4405

To: Alice <sip:[email protected]>;tag=19283017744406


CSeq: 231 BYE4408


The SIP Call Flows document [42] contains further examples of SIP messages.4410

;; This buffer is for notes you don’t want to save, and for Lisp evaluation. ;; If you want to create a file,4411

first visit that file with C-x C-f, ;; then enter the text in that file’s own buffer.4412



26 Augmented BNF for the SIP Protocol4413

All of the mechanisms specified in this document are described in both prose and an augmented Backus-4414

Naur Form (BNF) similar to that used by RFC 822 [12] and RFC 2234 [43]. Implementors will need to4415

be familiar with the notation in order to understand this specification. The augmented BNF includes the4416

following constructs:4417

name = definition4418

The name of a rule is simply the name itself (without any enclosing “<” and “>”) and is separated from4419

its definition by the equal “=” character. White space is only significant in that indentation of continuation4420

lines is used to indicate a rule definition that spans more than one line. Certain basic rules are in uppercase,4421

such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions whenever4422

their presence will facilitate discerning the use of rule names.4423

"literal"4424

Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.4425

rule1 | rule24426

Elements separated by a bar (”|”) are alternatives, e.g., “yes| no” will accept yes or no.4427

(rule1 rule2)4428

Elements enclosed in parentheses are treated as a single element. Thus, “(elem (foo| bar) elem)” allows the4429

token sequences “elem foo elem” and “elem bar elem”.4430

*rule4431

The character ”*” preceding an element indicates repetition. The full form is ”< n >*< m >element”4432

indicating at least< n > and at most< m > occurrences of element. Default values are 0 and infinity so4433

that ”*(element)” allows any number, including zero; ”1*element” requires at least one; and ”1*2element”4434

allows one or two.4435

[rule]4436

Square brackets enclose optional elements; ”[foo bar]” is equivalent to ”*1(foo bar)”.4437

N rule4438

Specific repetition: “<n>(element)” is equivalent to “<n>*<n>(element)”; that is, exactly<n> occur-4439

rences of (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic charac-4440

ters.4441



#rule4442

A construct “#” is defined, similar to “*”, for defining lists of elements. The full form is “< n >#< m >4443

element” indicating at least< n > and at most< m > elements, each separated by one or more commas4444

(“ ,”) and OPTIONAL linear white space (LWS). This makes the usual form of lists very easy; a rule such as4445

( *LWS element *( *LWS ”,” *LWS element ))4446

can be shown as1# element. Wherever this construct is used, null elements are allowed, but do not4447

contribute to the count of elements present. That is, “(element), , (element)” is permitted, but counts4448

as only two elements. Therefore, where at least one element is required, at least one non-null element4449

MUST be present. Default values are 0 and infinity so that “#element” allows any number, including zero;4450

“1#element” requires at least one; and “1#2element” allows one or two.4451

; comment4452

A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of4453

line. This is a simple way of including useful notes in parallel with the specifications.4454

26.1 Basic Rules4455

The following rules are used throughout this specification to describe basic parsing constructs. The US-4456

ASCII coded character set is defined by ANSI X3.4-1986.4457

OCTET = %x00-ff ; any 8-bit sequence of dataCHAR = %x00-7f ; any US-ASCII character (octets 0 - 127)upalpha = ”A” | ”B” | ”C” | ”D” | ”E” | ”F” | ”G” | ”H” | ”I” |

”J” | ”K” | ”L” | ”M” | ”N” | ”O” | ”P” | ”Q” | ”R” |”S” | ”T” | ”U” | ”V” | ”W” | ”X” | ”Y” | ”Z”

lowalpha = ”a” | ”b” | ”c” | ”d” | ”e” | ”f” | ”g” | ”h” | ”i” |”j” | ”k” | ”l” | ”m” | ”n” | ”o” | ”p” | ”q” | ”r” |”s” | ”t” | ”u” | ”v” | ”w” | ”x” | ”y” | ”z”

alpha = lowalpha | upalphaDIGIT = ”0” | ”1” | ”2” | ”3” | ”4” | ”5” | ”6” | ”7” |

”8” | ”9”alphanum = alpha | DIGITCTL = %x00-1f | %x7f ; (octets 0 – 31) andDEL (127)CR = %d13 ; US-ASCII CR, carriage return characterLF = %d10 ; US-ASCII LF, line feed characterSP = %d32 ; US-ASCII SP, space characterHT = %d09 ; US-ASCII HT, horizontal tab characterCRLF = CR LF ; typically the end of a line4458

The following are defined in RFC 2396 [9] for the SIP URI:4459



unreserved = alphanum | markmark = ”-” | ” ” | ”.” | ”!” | ”˜” | ”*” | ”’”

| ”(” | ”)”escaped = ”%” hex hex4460

SIP header field values can be folded onto multiple lines if the continuation line begins with a space or4461

horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipientMAY4462

replace any linear white space with a single SP before interpreting the field value or forwarding the message4463

downstream. This is intended to behave exactly as HTTP 1.1 as described in RFC2615 [8].4464

LWS = *( SP | HT ) [CRLF] 1*( SP | HT ) ; linear whitespace4465

To separate the header name from the rest of value, a colon is used, which, by the above rule allows4466

whitespace before, but no line break, and whitespace after, including a linebreak. The HCOLON defines4467

this construct.4468

HCOLON = *( SP | HT ) ”:” LWS4469

TheTEXT-UTF8 rule is only used for descriptive field contents and values that are not intended to be4470

interpreted by the message parser. Words of*TEXT-UTF8 contain characters from the UTF-8 character4471

set (RFC 2279 [11]). TheTEXT-UTF8-TRIM rule is used for descriptive field contents that arenot quoted4472

strings, where leading and trailing LWS is not meaningful. In this regard, SIP differs from HTTP, which4473

uses the ISO 8859-1 character set.4474

TEXT-UTF8 = *(TEXT-UTF8char | LWS)TEXT-UTF8-TRIM = *TEXT-UTF8char *(*LWS TEXT-UTF8char)TEXT-UTF8char = %x21-7e

| UTF8-NONASCIIUTF8-NONASCII = %xc0-df 1UTF8-CONT

| %xe0-ef 2UTF8-CONT| %xf0-f7 3UTF8-CONT| %xf8-fb 4UTF8-CONT| %xfc-fd 5UTF8-CONT

UTF8-CONT = %x80-bf4475

A CRLF is allowed in the definition ofTEXT-UTF8 only as part of a header field continuation. It is4476

expected that the foldingLWS will be replaced with a singleSP before interpretation of theTEXT-UTF84477

value.4478

Hexadecimal numeric characters are used in several protocol elements. Some elements (authentication)4479

force hex alphas to be lower case.4480

LHEX = digit | ”a” | ”b” | ”c” | ”d” | ”e” | ”f”4481

Others allow mixed upped and lower case4482

hex = LHEX | ”A” | ”B” | ”C” | ”D” | ”E” | ”F”4483

Many SIP header field values consist of words separated by LWS or special characters. Unless otherwise4484

stated, tokens are case-insensitive. These special charactersMUST be in a quoted string to be used within a4485

parameter value.4486



token = 1*(alphanum | ”-” | ”.” | ”!” | ”%” | ”*” | ” ” | ”+” | ”‘” | ”’” | ”˜” )separators = ”(” | ”)” | ”<” | ”>” | ”@” |

”,” | ”;” | ”:” | ”\” | <”> |”/” | ”[” | ”]” | ”?” | ”=” |”{” | ”}” | SP | HT4487

When tokens are used or separators are used between elements, whitespace is often allowed before or4488

after these characters:4489

MINUS = LWS ”-” LWS ; minusDOT = LWS ”.” LWS ; periodPERCENT = LWS ”%” LWS ; percentBANG = LWS ”!” LWS ; exclamationPLUS = LWS ”+” LWS ; plusSTAR = LWS ”*” LWS ; askeriskTILDE = LWS ””̃ LWS ; tildeEQUAL = LWS ”=” LWS ; equalLPAREN = LWS ”(” LWS ; left parenthesisRPAREN = LWS ”)” LWS ; right parenthesisLANGLE = LWS ”<” LWS ; left angle bracketRAQUOT = ”>” LWS ; right angle quoteLAQUOT = LWS ”<”; left angle quoteRANGLE = LWS ”>” LWS ; right angle bracketBAR = LWS ”—” LWS ; vertical barATSIGN = LWS ”@” LWS ; atsignCOMMA = LWS ”,” LWS ; commaSEMI = LWS ”;” LWS ; semicolonCOLON = LWS ”:” LWS ; colonDQUOT = LWS <”> LWS ; double quotation markLDQUOT = LWS <”>; open double quotation markRDQUOT = <”> LWS ; close double quotation markLBRACK = LWS ”{” LWS ; left square bracketRBRACK = LWS ”}” LWS ; right square bracket4490

Comments can be included in some SIP header fields by surrounding the comment text with parentheses.4491

Comments are only allowed in fields containing “comment” as part of their field value definition. In all other4492

fields, parentheses are considered part of the field value.4493

comment = LPAREN *(ctext | quoted-pair | comment) RPARENctext = <anyTEXT-UTF8 excluding“(“ and“)”>4494

A string of text is parsed as a single word if it is quoted using double-quote marks. In quoted strings,4495

quotation marks (”) and backslashes (\) need to be escaped.4496

quoted-string = ( LWS <”> *(qdtext | quoted-pair ) <”> )qdtext = LWS | %x21 | %x23-5b | %x5d-7e

| UTF8-NONASCII4497



The backslash character (”\”) MAY be used as a single-character quoting mechanism only within quoted-4498

string and comment constructs. Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this4499

mechanism to avoid conflict with line folding and header separation.4500

quoted-pair = ”\” (%x00 - %x09 | %x0b | %x0c | %x0e - %x7f)4501

SIP-URL = ”sip:” [ userinfo ”@” ] hostporturl-parameters [ headers ]

userinfo = [ user | telephone-subscriber [ ”:” password ]]user = *( unreserved | escaped | user-unreserved )user-unreserved = ”&” | ”=” | ”+” | ”$” | ”,” | ”;” | ”?” | ”/”password = *( unreserved | escaped |

”&” | ”=” | ”+” | ”$” | ”,” )hostport = host [ ”:” port ]host = hostname | IPv4address | IPv6referencehostname = *( domainlabel ”.” ) toplabel [ ”.” ]domainlabel = alphanum

| alphanum *( alphanum | ”-” ) alphanumtoplabel = alpha | alpha *( alphanum | ”-” ) alphanum4502

IPv4address = 1*3DIGIT ”.” 1*3DIGIT ”.” 1*3DIGIT ”.” 1*3DIGITIPv6reference = ”[” IPv6address ”]”IPv6address = hexpart [ ”:” IPv4address ]hexpart = hexseq | hexseq ”::” [ hexseq ] | ”::” [ hexseq ]hexseq = hex4 *( ”:” hex4)hex4 = 1*4HEXport = 1*DIGIT4503

url-parameters = *( ”;” url-parameter)url-parameter = transport-param | user-param | method-param

|ttl-param | maddr-param | other-paramtransport-param = ”transport=”

( ”udp” | ”tcp” | ”sctp” | ”tls”| other-transport)

other-transport = tokenuser-param = ”user=” ( ”phone” | ”ip” | other-user)other-user = tokenmethod-param = ”method=” Methodttl-param = ”ttl=” ttlmaddr-param = ”maddr=” hostother-param = pname [ ”=” pvalue ]pname = 1*paramcharpvalue = 1*paramcharparamchar = param-unreserved | unreserved | escapedparam-unreserved = ”[” | ”]” | ”/” | ”:” | ”&” | ”+” | ”$”4504



Client-Error = ”400” ; Bad Request| ”401” ; Unauthorized| ”402” ; Payment Required| ”403” ; Forbidden| ”404” ; Not Found| ”405” ; Method Not Allowed| ”406” ; Not Acceptable| ”407” ; Proxy Authentication Required| ”408” ; Request Timeout| ”409” ; Conflict| ”410” ; Gone| ”413” ; Request Entity Too Large| ”414” ; Request-URI Too Large| ”415” ; Unsupported Media Type| ”420” ; Bad Extension| ”480” ; Temporarily not available| ”481” ; Call Leg/Transaction Does Not Exist| ”482” ; Loop Detected| ”483” ; Too Many Hops| ”484” ; Address Incomplete| ”485” ; Ambiguous| ”486” ; Busy Here| ”487” ; Request Terminated| ”488” ; Not Acceptable Here4513

Server-Error = ”500” ; Internal Server Error| ”501” ; Not Implemented| ”502” ; Bad Gateway| ”503” ; Service Unavailable| ”504” ; Server Time-out| ”505” ; SIP Version not supported4514

Global-Failure = ”600” ; Busy Everywhere| ”603” ; Decline| ”604” ; Does not exist anywhere| ”606” ; Not Acceptable4515

Accept = ”Accept” HCOLON#( media-range [ accept-params ] )

media-range = ( ”*/*”| ( type LWS ”/” ”*” LWS )| ( type SLASH subtype )) *( SEMI parameter )

accept-params = SEMI ”q” EQUAL qvalue *( accept-extension )accept-extension = SEMI token [ EQUAL ( token | quoted-string ) ]4516



Accept-Encoding = ”Accept-Encoding” HCOLON1#( codings [ SEMI ”q” EQUAL qvalue ] LWS )

codings = ( content-coding | ”*” )content-coding = tokenqvalue = ( ”0” [ ”.” 0*3DIGIT ] )

— ( ”1” [ ”.” 0*3(”0”) ] )4517

Accept-Language = ”Accept-Language” HCOLON1#( language-range [ SEMI ”q” EQUAL qvalue ] )

language-range = ( ( 1*8ALPHA *( MINUS 1*8ALPHA ) ) — ”*” )4518

Alert-Info = ”Alert-Info” HCOLON #( LAQUOT URI RAQUOT *( COLON generic-param ))

generic-param = token [ EQUAL ( token | host |quoted-string ) ]4519

Allow = ”Allow” HCOLON 1#Method4520

Authorization = ”Authorization” HCOLON credentialscredentials = LWS ”Digest” digest-responsedigest-response = 1#( username | realm | nonce | digest-uri

| dresponse | [ algorithm ] | [cnonce]| [opaque] | [message-qop]| [nonce-count] | [auth-param] )

username = ”username” EQUAL username-valueusername-value = quoted-stringdigest-uri = ”uri” EQUAL digest-uri-valuedigest-uri-value = request-uri ; As specified by HTTP/1.1message-qop = ”qop” EQUAL qop-valuecnonce = ”cnonce” EQUAL cnonce-valuecnonce-value = nonce-valuenonce-count = ”nc” EQUAL nc-valuedresponse = ”response” EQUAL request-digestrequest-digest = LDQUOT 32LHEX RDQUOT4521

AuthenticationInfo = ”Authentication-info” HCOLON 1#( digest — nextnonce )nextnonce = ”nextnonce” EQUAL nonce-value

callid = token [ ATSIGN token ]4522

Call-ID = ( ”Call-ID” | ”i” ) HCOLON callid4523

Call-Info = ”Call-Info” HCOLON # ( LAQUOT URI RAQUOT*( SEMI info-param) )

info-param = ”purpose” EQUAL ( ”icon” | ”info”| ”card” | token ) | generic-param4524



Contact = ( ”Contact” | ”m” ) HCOLON(STAR | (1# (( name-addr | addr-spec )*( SEMI contact-params ))))

name-addr = [ display-name ] LAQUOT addr-spec RAQUOTaddr-spec = SIP-URL | URIdisplay-name = LWS (*token | quoted-string)4525

contact-params = ”q” EQUAL qvalue| ”action” EQUAL ”proxy” | ”redirect”| ”expires” EQUAL delta-seconds |

LDQUOT SIP-date RDQUOT| contact-extension

contact-extension = generic-paramqvalue = ( ”0” [ ”.” 0*3DIGIT ] )

| ( ”1” [ ”.” 0*3(”0”) ] )4526

delta-seconds = 1*DIGIT4527

Content-Disposition = ”Content-Disposition” HCOLONdisposition-type *( SEMI disposition-param )

disposition-type = ”render” | ”session” | ”icon” | ”alert”| disp-extension-token

disposition-param = ”handling” EQUAL( ”optional” | ”required” |other-handling ) | generic-param

other-handling = tokendisp-extension-token = token4528

Content-Encoding = ( ”Content-Encoding” | ”e” ) HCOLON1#content-coding4529

Content-Language = ”Content-Language” HCOLON 1#language-taglanguage-tag = primary-tag *( MINUS subtag )primary-tag = 1*8ALPHAsubtag = 1*8ALPHA4530

Content-Length = ( ”Content-Length” | ”l” ) HCOLON 1*DIGIT4531

Content-Type = ( ”Content-Type” | ”c” ) HCOLON media-type4532

CSeq = ”CSeq” HCOLON 1*DIGIT Method4533



Date = ”Date” HCOLON SIP-dateSIP-date = rfc1123-daterfc1123-date = wkday COMMA SP date1 SP time SP ”GMT”date1 = 2DIGIT SP month SP 4DIGIT

; day month year (e.g., 02 Jun 1982)time = 2DIGIT ”:” 2DIGIT ”:” 2DIGIT

; 00:00:00 - 23:59:59wkday = ”Mon” | ”Tue” | ”Wed”

| ”Thu” | ”Fri” | ”Sat” | ”Sun”month = ”Jan” | ”Feb” | ”Mar” | ”Apr”

| ”May” | ”Jun” | ”Jul” | ”Aug”| ”Sep” | ”Oct” | ”Nov” | ”Dec”4534

Error-Info = ”Error-Info” HCOLON #( LAQUOT URI RAQUOT*( SEMI generic-param ))4535

Expires = ”Expires” HCOLON ( SIP-date | delta-seconds )From = ( ”From” | ”f” ) HCOLON

( name-addr | addr-spec )*( SEMI from-param )

from-param = tag-param | generic-paramtag-param = ”tag” EQUAL token4536

In-Reply-To = ”In-Reply-To” HCOLON 1# callid4537

Max-Forwards = ”Max-Forwards” HCOLON 1*DIGIT4538

MIME-Version = ”MIME-Version” HCOLON 1*DIGIT ”.” 1*DIGIT4539

Organization = ”Organization” HCOLON TEXT-UTF8-TRIM4540

Priority = ”Priority” HCOLON priority-valuepriority-value = ”emergency” | ”urgent” | ”normal”

| ”non-urgent” | other-priorityother-priority = token4541



Proxy-Authenticate = ”Proxy-Authenticate” HCOLON 1#challengechallenge = LWS ”Digest” digest-challengedigest-challenge = 1#( realm | [ domain ] | nonce |

[ opaque ] | [ stale ] | [ algorithm ] |[ qop-options ] | [auth-param] )

realm = ”realm” EQUALS realm-valuerealm-value = quoted-stringdomain = ”domain” EQUAL LDQUOT URI

( 1*SP URI ) RDQUOTURI = absoluteURI | abs pathnonce = ”nonce” EQUAL nonce-valuenonce-value = quoted-stringopaque = ”opaque” EQUAL quoted-stringstale = ”stale” EQUAL ( ”true” | ”false” )algorithm = ”algorithm” EQUAL ( ”MD5” | ”MD5-sess” |

token )qop-options = ”qop” EQUAL LDQUOT 1#qop-value RDQUOTqop-value = ”auth” | ”auth-int” | token4542

Proxy-Authorization = ”Proxy-Authorization” HCOLON credentials4543

Proxy-Require = ”Proxy-Require” HCOLON 1#option-tag4544

Record-Route = ”Record-Route” HCOLON 1#( name-addr *( SEMI rr-param ))

rr-param = generic-paramRequire = ”Require” HCOLON 1#option-tag4545

Retry-After = ”Retry-After” HCOLON( SIP-date | delta-seconds )[ comment ] *( SEMI retry-param )

retry-param = ”duration” EQUAL delta-seconds |generic-param4546

Route = ”Route” HCOLON 1# ( name-addr*( SEMI rr-param ))4547

Server = ”Server” HCOLON 1*( product — comment )product = token [SLASH product-version]product-version = token4548

Subject = ( ”Subject” | ”s” ) HCOLON TEXT-UTF8-TRIM4549

Supported = ( ”Supported” | ”k” ) HCOLON 0#option-tag4550



Timestamp = ”Timestamp” HCOLON *(DIGIT)[ ”.” *(DIGIT) ] [ delay ]

delay = *(DIGIT) [ ”.” *(DIGIT) ]4551

To = ( ”To” | ”t” ) HCOLON ( name-addr |addr-spec ) *( SEMI to-param )

to-param = tag-param | generic-param4552

Unsupported = ”Unsupported” HCOLON 1#option-tag4553

User-Agent = ”User-Agent” HCOLON 1*( product — comment )4554

Via = ( ”Via” | ”v” ) HCOLON1#( sent-protocol sent-by*( SEMI via-params ) [ comment ] )

via-params = via-hidden | via-ttl | via-maddr| via-received | via-branch| via-extension

via-hidden = ”hidden”via-ttl = ”ttl” EQUAL ttlvia-maddr = ”maddr” EQUAL hostvia-received = ”received” EQUAL hostvia-branch = ”branch” EQUAL tokenvia-extension = generic-paramsent-protocol = protocol-name SLASH protocol-version

SLASH transportprotocol-name = ”SIP” | tokenprotocol-version = tokentransport = ”UDP” | ”TCP” | ”TLS” | ”SCTP”

| other-transportsent-by = host [ COLON port ]ttl = 1*3DIGIT ; 0 to 2554555

Warning = ”Warning” HCOLON 1#warning-valuewarning-value = warn-code SP warn-agent SP warn-textwarn-code = 3DIGITwarn-agent = ( host [ COLON port ] ) | pseudonym

; the name or pseudonym of the server adding; the Warning header, for use in debugging

warn-text = quoted-stringpseudonym = token4556

WWW-Authenticate = ”WWW-Authenticate” HCOLON challenge4557



27 IANA Considerations4558

All new or experimental method names, header field names, and status codes used in SIP applications4559

SHOULD be registered with IANA in order to prevent potential naming conflicts. It isRECOMMENDED that4560

new “option- tag”s and “warn-code”s also be registered. Before IANA registration, new protcol elements4561

SHOULD be characterized in an Internet- Draft or, preferably, an RFC.4562

For Internet-Drafts, IANA is requested to make the draft available as part of the registration database.4563

By the time an RFC is published, colliding names may have already been implemented.4564

When a registration for either a new header field, new method or new status code is created based on4565

an Internet-Draft, and that Internet-Draft becomes an RFC, the person that performed the registrationMUST4566

notify IANA to change the registration to point to the RFC instead of the Internet-Draft.4567

Registrations should be sent [email protected] .4568

27.1 Option Tags4569

Option tags are used in headers such asRequire, Supported, Proxy-Require andUnsupported in support4570

of SIP compatibility mechanisms for extensions. For more on the use of option tags in these headers see4571

Section 21.2. The option tag itself is a string that is associated with a particular SIP option (e.g. an extension)4572

in order to identify the option in signaling between SIP endpoints.4573

When registering a new SIP option with IANA, the following informationMUST be provided:4574

• Name and description of option. The nameMAY be of any length, butSHOULD be no more than4575

twenty characters long. The nameMUST consist ofalphanum (See Section 26) characters only4576

• A listing of any new SIP header fields, header parameter fields or parameter values defined by this4577

option. A SIP optionMUST NOT redefine header fields or parameters defined in either RFC 2543, any4578

standards-track extensions to RFC 2543, or other extensions registered through IANA4579

• Indication of who has change control over the option (for example, IETF, ISO, ITU-T, other interna-4580

tional standardization bodies, a consortium or a particular company or group of companies)4581

• A reference to a further description, if available, for example (in order of preference) an RFC, a4582

published paper, a patent filing, a technical report, documented source code or a computer manual4583

• Contact information (postal and email address)4584

This procedure has been borrowed from RTSP [4] and the RTP AVP [44].4585

27.2 Warn-Codes4586

Warning codes provide information supplemental to the status code in SIP response messages when the4587

failure of the transaction results from a Session Description Protocol (SDP, [6]). New “warn-code” values4588

can be registered with IANA as they arise.4589

The “warn-code” consists of three digits. A first digit of “3” indicates warnings specific to SIP.4590

Warnings 300 through 329 are reserved for indicating problems with keywords in the session description,4591

330 through 339 are warnings related to basic network services requested in the session description, 3704592

through 379 are warnings related to quantitative QoS parameters requested in the session description, and4593

390 through 399 are miscellaneous warnings that do not fall into one of the above categories.4594

1xx and 2xx have been taken by HTTP/1.1.4595



27.3 Header Field Names4596

Header field names do not require working group or working group chair review prior to IANA registration,4597

but SHOULD be documented in an RFC or Internet- Draft before IANA is consulted.4598

The following information needs to be provided to IANA in order to register a new header field name:4599

• The name and email address of the individual performing the registration.4600

• The name of the header field being registered.4601

• A compact form version for that header field, if one is defined.4602

• The name of the draft or RFC where the header field is defined.4603

• A copy of the draft or RFC where the header field is defined.4604

Header fieldsSHOULD NOT use theX- prefix notation andMUST NOT duplicate the names of header4605

fields used by SMTP or HTTP unless the syntax is a compatible superset and the semantics are similar.4606

Some common and widely used header fieldsMAY be assigned one-letter compact forms (Section 7.3.3).4607

Compact forms can only be assigned after SIP working group review. In the absence of this working group,4608

a designated expert reviews the request.4609

27.4 Method and Response Codes4610

Because the status code space is limited, they do require working group or working group chair review, and4611

MUST be documented in an RFC or Internet draft. The same procedures apply to new method names.4612

The following information needs to be provided to IANA in order to register a new response code or4613

method:4614

• The name and email address of the individual performing the registration.4615

• The number of the response code or name of the method being registered.4616

• The default reason phrase for that status code, if applicable.4617

• The name of the draft or RFC where the method or status code is defined.4618

• A copy of the draft or RFC where the method or status code is defined.4619

28 Changes Made in Version 004620

• Indicated that UAC should send bothCANCEL andBYE after a retransmission fails.4621

• Added semicolon and question mark to the list of unreserved characters for theuser part of SIP URLs4622

to handletel: URLs properly.4623

• Uniform handling of if hop countMax-Forwards: return 483. Note that this differs from HTTP/1.14624

behavior, where only OPTIONS and TRACE allow this header, but respond as the final recipient when4625

the value reaches zero.4626



• Clarified that a forking proxy sendsACKs only for INVITE requests.4627

• Clarified wording of DNS caching. Added paragraph on “negative caching”, i.e., what to do if one4628

of the hosts failed. It is probably not a good idea to simply drop this host from the list if the DNS ttl4629

value is more than a few minutes, since that would mean that load balancing may not work for quite a4630

while after a server is brought back on line. This will be true in particular if a server group receives a4631

large number of requests from a small number of upstream servers, as is likely to be the case for calls4632

between major consumer ISPs. However, without getting into arbitrary and complicated retry rules, it4633

seems hard to specify any general algorithm. Might it be worthwhile to simply limit the “black list”4634

interval to a few minutes?4635

• Added optionalCall-Info andAlert-Info header fields that describe the caller and information to be4636

used in alerting. (Currently, avoided use of “purpose” qualification since it is not yet clear whether4637

rendering content without understanding its meaning is always appropriate. For example, if a UAS4638

does not understand that this header is to replace ringing, it would mix both local ring tone and the4639

indicated sound URL.) TBD!4640

• SDP “s=” lines can’t be empty, unfortunately.4641

• Noted thatmaddr could also contain a unicast address, butSHOULD contain the multicast address if4642

the request is sent via multicast (Section 22.40.4643

• Clarified that responses are sent to port inVia sent-by value.4644

• Added “other-*” to theuser URL parameter and theHide andContent-Disposition headers.4645

• Clarified generation of timeout (408) responses in forking proxies and mention theExpires header.4646

• Clarified thatCANCEL and INVITE are separate transactions (Fig. 7). Thus, theINVITE request4647

generates a 487 (Request Terminated) if aCANCEL or BYE arrives.4648

• Clarified thatRecord-Route SHOULD be inserted in every request, but that the route, once estab-4649

lished, persists. This provides robustness if the called UAS crashes.4650

• Emphasized that proxy, redirect, registrar and location servers are logical, not physical entities and4651

that UAC and UAS roles are defined on a request-by-request basis. (Section 6)4652

• In Section 22.40, noted that themaddr and received parameters also need to be encrypted when4653

doingVia hiding.4654

• Simplified Fig. 7 to only showINVITE transaction.4655

• Added definition of the use ofContact (Section 22.10) forOPTIONS.4656

• Added HTTP/RFC822 headersContent-Language andMIME-Version.4657

• Added note in minimal section indicating that UAs need to support UDP.4658

• Added explanation explaining what a UA should do when receiving an initialINVITE with a tag.4659

• Clarified UA and proxy behavior for 302 responses.4660



• Added details on what a UAS should do when receiving a taggedINVITE request for an unknown call4661

leg. This could occur if the UAS had crashed and the UAC sends a re-INVITE or if the BYE got lost4662

and the UAC still believes to be in the call.4663

• Added definition ofContact in 4xx, 5xx and 6xx to “redirect” to more error details.4664

• Added note to forking proxy description to gather*-Authenticate from responses. This allows several4665

branches to be authenticated simultaneously.4666

• Changed URI syntax to use URL escaping instead of quotation marks.4667

• Changed SIP URL definition to reference RFC 2806 fortelephone-subscriber part.4668

• Clarified that theTo URI should basically be ignored by the receiving UAS except for matching4669

requests to call legs. In particular,To headers with a scheme or name unknown to the callee should4670

be accepted.4671

• Clarified thatmaddr is to be added by any client, either proxy or UAC.4672

• Added response code 488 to indicate that there was no common media at the particular destination.4673

(606 indicates such failure globally.)4674

• In Section 22.19, noted that registration updates can shorten the validity period.4675

• Added note to enclose the URI for digest in quotation marks. The BNF in RFC 2617 is in error.4676

• Clarified that registrars useAuthorization andWWW-Authenticate, not proxy authentication.4677

• Added note in Section 22.10 that “headers” are copied fromContact into the new request.4678

• Changed URL syntax so that port specifications have to have at least one digit, in line with other URL4679

formats such as “http”. Previously, an empty port number was permissible.4680

• In SDP section, added a section on how to add and delete streams in re-INVITEs.4681

• IETF-blessed extensions now have short names, withoutorg.ietf. prefix.4682

• Cseq is unique within a call leg, not just within a call (Section 22.16).4683

• Added IPv6 literal addresses to the SIP URL definition, according to RFC 2732 [45]. Modified the4684

IPv4 address to limit segments to at most three digits.4685

• modify registration procedure so that it explicitly references the URL comparison. Updates with4686

shorter expiration time are now allowed.4687

• For send-only media, SDP still must indicate the address and port, since these are needed as destina-4688

tions for RTCP messages.4689

• Changed references regarding DNS SRV records from RFC 2052 to RFC 2782, which is now a Pro-4690

posed Standard. Integrated SRV into the search procedure and removed the SRV appendix. The only4691

visible change is that protocol and service names are now prefixed by an underscore. Added wording4692

that incorporates the precedence ofmaddr.4693



• Allow parameters inRecord-Route andRoute headers.4694

• In Table 1, listudp as the default value for the transport parameter in SIP URI.4695

• Removed sentence thatFrom can be encrypted. It cannot, since the header is needed for call-leg4696

identification.4697

• Added note that a UAC only copies aTo tag into subsequent transactions if it arrives in a 200 OK to4698

an INVITE. This avoids the problem that occurs when requests get resubmitted after receiving, say,4699

a 407 (or possibly 500, 503, 504, 305, 400, 411, 413, maybe even 408). Under the old rules, these4700

requests would have a tag, which would force the called UAS to reject the request, since it doesn’t4701

have an entry for this tag.4702

• Loop detection has been modified to take therequest-URI into account. This allows the same request4703

to visit the server twice, but with different request URIs (“spiral”).4704

• Elaborated on URL comparison and comparison ofFrom/To fields.4705

• Addednp-queried user parameter.4706

• Changedtag syntax from UUID to token, since there’s no reason to restrict it to hex.4707

• Added Content-Disposition header based on earlier discussions about labeling what to do with a4708

message body (part).4709

• Clarification: proxies must insertTo tags for locally generated responses.4710

• Clarification: multicast may be used for subsequent registrations.4711

• Feature: AddedSupported header. Needed if client wants to indicate things the server can usefully4712

return in the response.4713

• Bug: TheFrom, To, and Via headers were missing extension parameters. TheEncryption and4714

Response-Key header fields now “officially” allow parameters consisting only of a token, rather4715

than just “token = value”.4716

• Bug: Allow was listed as optional in 405 responses in Table 2. It is mandatory.4717

• Added: “A BYE request from either called or calling party terminates any pendingINVITE, but the4718

INVITE request transactionMUST be completed with a final response.”4719

• Clarified: “If an INVITE request for an existing session fails, the session description agreed upon in4720

the last successfulINVITE transaction remains in force.”4721

• Clarified what happens if twoINVITE requests meet each other on the wire, either traveling the same4722

or in opposite directions:4723

A UAC MUST NOT issue anotherINVITE request for the same call leg before the pre-4724

vious transaction has completed. A UAS that receives anINVITE before it sent the final4725

response to anINVITE with a lower CSeq numberMUST return a 400 (Bad Request)4726

response andMUST include aRetry-After header field with a randomly chosen value of4727



between 0 and 10 seconds. A UA that receives anINVITE while it has anINVITE transac-4728

tion pending, returns a 500 (Internal Server Error) and also includes aRetry-After header4729

field.4730

• Expires header clarified: limits only duration ofINVITE transaction, not the actual session. SDP4731

does the latter.4732

• TheIn-Reply-To header was added.4733

• There were two incompatible BNFs forWWW-Authenticate. One defined for PGP, and the other4734

borrowed from HTTP. For basic or digest:4735

WWW-Authenticate: basic realm="Wallyworld"4736

and for pgp:4737

WWW-Authenticate: pgp; realm="Wallyworld"4738

The latter is incorrect and the semicolon has been removed.4739

• Added rules forRoute construction from called to calling UA.4740

• We now allowAccept andAccept-Encoding in BYE andCANCEL requests. There is no particular4741

reason not to allow them, as both requests could theoretically return responses, particularly when4742

interworking with other signaling systems.4743

• PGP “pgp-pubalgorithm” allows server to request the desired public-key algorithm.4744

• ABNF rules now describe tokens explicitly rather than by subtraction; explicit character enumeration4745

for CTL, etc.4746

• Registrars should be careful to check theDate header as the expiration time may well be in the past,4747

as seen by the client.4748

• Content-Length is mandatory; Table 2 erroneously marked it as optional.4749

• User-Agent was classified in a syntax definition as a request header rather than a general header.4750

• Clarified ordering of items to be signed and include realm in list.4751

• Allow Record-Route in 401 and 484 responses.4752

• Hop-by-hop headers need to precede end-to-end headers only if authentication is used.4753

• 1xx message bodiesMAY now contain session descriptions.4754

• Changed references to HTTP/1.1 and authentication to point to the latest RFCs.4755

• Added 487 (Request terminated) status response. It is issued if the original request was terminated4756

via CANCEL or BYE.4757



• The spec was not clear on the identification of a call leg. Section 1.3 says it’s the combination ofTo,4758

From, andCall-ID. However, requests from the callee to the caller have theTo andFrom reversed, so4759

this definition is not quite accurate. Additionally, the “tag” field should be included in the definition4760

of call leg. The spec now says that a call leg is defined as the combination of local-address, remote-4761

address, and call-id, where these addresses include tags.4762

Text was added to Section 6.21 to emphasize that theFrom andTo headers designate the originator4763

of the request, not that of the call leg.4764

• All URI parameters, exceptmethod, are allowed in aRequest-URI. Consequently, also updated the4765

description of which parameters are copied from 3xx responses in Sec. 22.10.4766

• The use of CRLF, CR,or LF to terminate lines was confusing. Basically, each header line can be4767

terminated by a CR, LF, or CRLF. Furthermore, the end of the headers is signified by a “double4768

return”. Simplified to require sending of CRLF, but require senders to receive CR and LF as well and4769

only allow CR CR, LF LF in addition to double CRLF as a header-body separator.4770

• Round brackets inContact header were part of the HTTP legacy, and very hard to implement. They4771

are also not that useful and were removed.4772

• The spec said that a proxy is a back-to-back UAS/UAC. This is almost, but not quite, true. For4773

example, a UAS should insert a tag into a provisional response, but a proxy should not. This was4774

clarified.4775

• Section 6.13 in the RFC begins mid-paragraph after the BNF. The following text was misplaced in the4776

conversion to ASCII:4777

Even if the “display-name” is empty, the “name-addr” form MUST be used if the “addr-4778

spec” contains a comma, semicolon or question mark.4779


• Uniform syntax specification for semicolon parameters:4781

Foo = ”Foo” ”:” something *( ”;” foo-param )foo-param = ”bar” ”=” token

| generic-param4782

• Removednp-queried user parameter since this is now part of a tel URL extension parameter.4783

• In SDP section, noted that if the capabilities intersection is empty, a dummy format list still has to be4784

returned due to SDP syntax constraints. Previously, the text had required that no formats be listed.4785

(Brian Rosen)4786

• Reorganized tables 2 and 3 to show proxy interaction with headers rather than “end-to-end” or “hop-4787

by-hop”.4788




• Added “or UAS” in description ofreceived headers in Section 22.40. This makes the response4790

algorithm work even if the last IP address in theVia is incorrect.4791

• Tentatively removed restriction thatCANCEL requests cannot haveRoute headers. (Billy Biggs)4792

• Tentatively addedAlso header forBYE requests, as it is widely implemented and a simple means to4793

implement unsupervised call transfer. Subject to removal if there is protest. (Billy Biggs)4794

• If a proxy sends a request by UDP (TCP), the spec did not disallow placing TCP (UDP) in the transport4795

parameter of theVia field, which it should. Added a note that the transport protocol actually used is4796

included.4797

• No default value for theq parameter in Contact is defined. This is not strictly needed, but is useful for4798

consistent behaviors at recursive proxies and at UAC’s. Now 0.5.4799

• Clarified thatTo andFrom tag values should be different to simplify request matching when calling4800

oneself.4801

• Removed ability to carry multiple requests in a single UDP packet (Section 22.14).4802

• Added note thatAllow MAY be included in requests, to indicate requestor capabilities for the same4803

call ID.4804

• Added note to Section 22.17 indicating that registrarsMUST include theDate header to accomodate4805

UAs that do not have a notion of absolute time.4806

• Added note emphasizing that non-SIP URIs are permissible inREGISTER.4807

• Rewrote the server lookup section to be more precise and more like pseudo-code, with nesting instead4808

of “gotos”.4809

• Removed note4810

Note that the two URLs example.com and example.com:5060, while considered equal,4811

may not lead to the same server, as the former causes a DNS SRV lookup, while the latter4812

only uses the A record.4813

since that is no longer the case.4814

• Emphasized that proxies have to forward requests with unknown methods.4815

• Aligned definition of call leg with URI comparison rules.4816

• Required that second branch parameter be globally unique, so that a proxy can distinguish different4817

branches in spiral scenarios similar to the following, with record-routing in place:4818

B ---> P1 -------> P2 ------------> P1 ----------------> A4819

BYE B B/1 P1/2,B/1 P2/3,P1/2,B/1 P1/4,P2/3,P1/2,B/14820



Here, A/1 denotes theVia entry with host A and branch parameter 1. Also, this requires updating the4821

definition of isomorphic requests, since theRequest-URI is the same for allBYE that are record-4822

routed.4823

• RemovedVia hiding from spec, for the following reasons:4824

– complexity, particularly hidden “gotchas” that surface at various points (as in this instance);4825

– interference with loop detection and debugging;4826

– Unlike HTTP, where via-hiding makes sense since all data is contained in the request or re-4827

sponse,Via-hiding in SIP by itself does nothing to hide the caller or callee, as address informa-4828

tion is revealed in a number of places:4829

∗ Contact;4830

∗ Route/Record-Route;4831

∗ SDP, including the o= and c= lines;4832

∗ possibly accidental leakage inUser-Agent header andCall-ID headers.4833

– Unless this is implemented everywhere, the feature is not likely to be very useful, without the4834

sender having any recourse such as “don’t route this request unless you can hide”. It appears4835

that almost all existing proxies simply ignore the Hide header.4836

• AddedError-Info header field.4837


• Description ofRoute andRecord-Route moved to separate section, which is new. All UAs must4839

now support this mechanism.4840

• Removed status code 411, since it cannot occur (Jonathan Rosenberg, James Jack).4841

• RewroteRecord-Route section to reflect new mechanism. In particular, requests from callee to caller4842

now use the same path as in the opposite direction, without substituting theFrom header field values.4843

Themaddr parameter is now optional.4844

• Disallowed SIP URLs that only have a password, without a user name. The prototype from RFC 17384845

also doesn’t allow this.4846

• Allow registrar to set the expiration time.4847

• CSeq (Section 22.16) is counted within a call leg, not a call.4848

• Removed wording that connection closing is equivalent toCANCEL or 500. This does not work for4849

connections that are used for multiple transactions and has other problems.4850

• Cleaned up CSeq section. Removed text about insertingCSeq method when it is absent. Clarified4851

that CSeq increments for all requests, not just invite. Clarified that all out of order requests, not4852

just out of order INVITE, are rejected with a 400 class response. Clarified the meaning of “initial”4853

sequence number. Clarified that after a request forks, each 200 OK is a separate call leg, and thus,4854

separate CSeq space. Clarified that CSeq numbers are independent for each direction of a call leg.4855



• Massive reorganization and cleanup of the SDP section. Introduced the concept of the offer-answer4856

model. Clarified that set of codecs in m line are usable all at the same time. Inserted size restriction4857

on representation of values in o line. Explicitly describe forked media. New media lines for adding4858

streams appear at the bottom of the SDP (used to say append).4859

• Removed Also.4860

• Added text to Require and Proxy-Require sections, making it a SHOULD to retry the request without4861

the unsupported extension.4862

• Added text to section on 415, saying that UAC SHOULD retry the request without the unsupported4863

body.4864

• Added text to section on CANCEL and ACK, clarifying much of the behavior.4865

• Modified Content-Type to indicate that it can be present even if the body is empty.4866

• From tags mandatory4867

• Old text said that if you hang up before sending anACK, you need not send theACK. That is wrong.4868

Text fixed so that anACK is always sent.4869

• Old text said that if you never got a response to anINVITE, the UAC should send both anINVITE and4870

CANCEL. This doesn’t make sense. Rahter, it should do nothing and consider the call terminated.4871

• Added text that says pending requests are responded to with a 487 if aBYE is received.4872

• Updated section 2.2, so that its clear thatContact is not used withBYE.4873

• Clarified Via processing rules. Added text on handling loops when proxies route on headers besides4874

the request URI. Added text on handling case when sent-by contains a domain name. Added text to4875

6.47 on opening TCP connections to send responses upstream.4876

• Clarified that a 1xx with an unknown xx is not the same as the 100 response.4877

• Removed usage ofRetry-After in REGISTER.4878

• Clarified usage of persistent connections.4879

• Clarified that servers supporting HTTP basic or digest in rfc2617MUST be backwards compatible4880

with RFC 2069.4881

• Clarified thatACK contains the same branch ID as the request its acknowledging.4882

• Added definitions for spiral, B2BUA.4883

• Rephrased definitions for UAC, UAS, Call, call-leg, caller, callee, making them more concrete.4884

• URL comparison ignores parameters not present in both URLs only for unknown parameters.4885

• Clarified that * inContact is used only inREGISTER with Expires header zero. Mentioned * case4886

in section onContact syntax.4887



• Removed text that says a UA can insert aContact in 2xx that indicates the address of a proxy. Not4888

likely to work in general.4889

• Removed SDP text about aligning media streams within a media type to handle certain crash and4890

restart cases.4891

• Receiving a 481 to a mid-call request terminates that call leg. Agreed upon at IETF 49.4892

• Introduced definition of regular transaction - non-INVITE exceptingACK andCANCEL.4893

• Clarified rules for overlapping transactions.4894

• Forking proxiesMUST be stateful (used to saySHOULD). Proxies that send requests on multicast4895

MUST be stateful (used to say nothing)4896

• Text added recommending that registrars authorize that entity inFrom field can register address-of-4897

record in theTo field.4898

• Forwarding of non-100 provisionals upstream in a proxy changed fromSHOULD to MUST.4899

• Removed PGP.4900


• Removed Unsupported as a request header from Table 3.4902

• Clarified SDP procedures for changing IP address and port. Specifically, spelled out the duration for4903

which a UA needs to received media on the old port and address.4904

• Added text in the SDP session which recommends that the answerer use the same ordering of codecs4905

as used on the offer, in order to help ensure symmetric codec operation under normal conditions.4906

• Fixed bug in the example in the SDP section, where the new media line was listed at the top. Should4907

have been the bottom.4908

• Authorization credentials are cached based on the URL of theTo header, not the entireTo header as4909

10.48 implied.4910

• Section 10.31, onProxy-Authenticate, indicated that a server responds with a 401 if the client4911

guessed wrong. This is incorrect. It should be 407.4912

• Section 10.14, removed motivational text aboutContact allowing an INVITE to be routed directly4913

between end systems, since its confusing. Some have interpreted to mean thatRecord-Route is4914

ignored whenContact is present.4915

• Added reference to SCTP RFC.4916

• Updated 2.2 to allow non-SIP URLs inOPTIONS and 2xx toOPTIONS.4917

• Fixed example in 20.5. AddedACK for 487, and addedTo tag to 487 response.4918



• Clarified further URL comparisons. Its only URL parameters without defaults that are ignored if not4919

present in both URLs.4920

• Section 1.5.2, UDP mandatory for all. TCP is aSHOULD for UA, MUST for proxy, registrar, redirect4921

servers.4922

• Brought syntax forContact, Via, and the SIP URL into alignment between the text and postscript4923

versions.4924

• Updated the text in section 6 which said that the ordering of header fields follows HTTP, with the4925

exception ofVia, where order matters. However, the HTTP spec says that order matters, so this4926

sentence is redundant and confusing. The sentence was removed.4927

• Added e lines to SDP examples in the Examples section.4928

• RewroteAllow discussion, more formally defining its semantics and usage cases.4929

• Updated text on 604 status, to indicate that its based on theRequest-URI, not theTo.4930

• Added response registrations to IANA considerations. Provided more details on registration process.4931

• Clarified that only a UAS rejects a request because theTo tag doesn’t match a local value.4932

• Clarified that stateless proxies need to route based on static criteria only.4933

• Proxy and UACCANCEL generation upon 2xx, 6xx if it forked is now aSHOULD; used to be aMAY .4934

• Added text saying that a UASSHOULD send aBYE if it never gets anACK for a 2xx establishing a4935

call leg.4936

• Added text saying that a UASSHOULD send a re-INVITE if it never gets anACK for a 2xx to a4937

re-INVITE.4938

• Added text on 503 processing, indicating that a client should try a different server when receiving a4939

503, and that a proxy shouldn’t forward a 503 upstream unless it can’t service any other requests.4940

• Removed motivational text in Section 10.43 onVia headers since its not consistent with the text before4941

it.4942

• Changed IPSec reference to RFC2401, from RFC1825.4943

• Updated retransmission defininition in 17.3.4 to be consistent with the rest of the spec.4944

• Softened the language for insertion of the transport param in the record-route. Specifically, it can be4945

inserted in private networks where it is known apriori that the specific transport is supported.4946

• Updated definition of B2BUA.4947

• Added text to section on 420 processing, which mandates that the client retry the request without4948

extensions listed in theUnsupported header in the response.4949

• Allow Authentication-Info header to be used for HTTP digest.4950




• Updated Table 2 to reflect thatError-Info is a response header in 3xx-6xx responses (it was previously4952

listed as a request header).4953

• RemovedWWW-Authenticate as a request header from Table 3. Authentication of responses is now4954

done according to RFC2617.4955

• Updated theAccept, Accept-Encoding andAccept-Language sections. More details on precise4956

semantics for the various requests and responses is now provided. Presence of these headers is now4957

a SHOULD for INVITE and 2xx toINVITE when a non-default value is present. Extra emphasis is4958

placed on including theAccept-Language in INVITE and 2xx in order to support internationaliza-4959

tion. Usage of these three headers inCANCEL has been removed since it makes no sense.4960

• Generalized local outbound processing rules in Section 16.4.1 to cover the case where the UAS is4961

using a local outbound proxy which was not in the initial call setup path.4962

• Updated record-routing section, so that a proxy can insert a transport param if it knows that the proxy4963

on one side supports the specific transport (the previous text required the proxy to know whether the4964

proxies on both sides supported the specific transport).4965

• AddedAuthentication-Info to Section 10.4966

• Clarified the meaning of Table 2 for responses.4967

• Updated Table 1 to reflect that maddr is no longer mandatory inRecord-Route.4968

• Updated Table 3 so that header fields in responses toACK are never listed as optional, mandatory, etc.4969

- only not applicable. This is because responses toACK are not allowed. Also improved wording in4970

Section 5.1.1 to clarify that thereMUST NOT be responses toACK.4971

• Updated SRV procedures. Old text said to treat a failure to contact a server as a 4xx, which would4972

stop the SRV processing. But, this is not so. Sentence was stricken.4973

• Updated 12.1 to clarify that 2xx INVITE responsesMUST contain session descriptions.4974

• ChangedUser-Agent to a request header in Table 3.4975

• Updated SDP section, so that a UA cannot change the SDP when it gets a re-INVITE with no SDP.4976

• Clarified Appendix B that a unicast offerMUST have a unicast response.4977

• Clarified that any request can be record-routed, but it may not be used by the UA, depending on the4978

method.4979

• non-2xx responses toINVITE no longer retransmitted over TCP.4980

• Removed lower bound on T1 and T2 in private networks, which can use lower values. Furthermore,4981

T1 can be smaller on the public Internet if proper RTT estimation is used.4982

• UAS Cannot send aBYE for a call leg until it receivesACK, in order to eliminate a race condition4983

betweenBYE and 200 OK.4984



• Support of CR or LF alone as line terminators, as opposed to CRLF, is no longer required.4985

• Client behavior on receipt of a 3xx to re-INVITE is now specified, and it is no longer forbidden to4986

generate a 3xx. This is needed to maintain the idempotency ofINVITE, as a proxy might redirect4987

without knowing its a 3xx.4988

• CANCEL cannot be sent before a 1xx is received, in order to eliminate race condition between request4989

andCANCEL.4990

• Termination of the client and server transactions is now based entirely on timeouts, rather than re-4991

transmission counters, in order to unify TCP and UDP behavior. Timeout values scale as a function4992

of the RTT estimate, defined as T1. For reliable transports, many of these timers are now set to zero.4993

Many timeouts differ than in bis-04.4994

• Added a working RTT estimation algorithm using theTimestamp header, and specified it to be4995

compliant to RFC 2988.4996

• UAS accepting requests with unknown schemes in the URI in theTo field is now aRECOMMENDED4997

instead ofSHOULD. This reflects the fact that processing a request when theTo field doesn’t match is4998

a matter of policy.4999

• Bodies are now allowed in any request and response, includingCANCEL, although there may not be5000

any semantics associated with that.5001

• Supporting ofINVITE without SDP is now aMUST (no strength was previously specified).5002

• Registration procedures for visiting, which had a few sentences in bis-04, have been removed. Roam-5003

ing is a complex issue, and should be treated elsewhere.5004

• Bis-04 mandated that a 2xx response toREGISTER contain expiresContact parameters indicating5005

the expiration time of a contact. This behavior has now been made consistent with requests, so that5006

the expiration time of a contact is the same in either case: the expires param is used first if present,5007

then theExpires header if present, else one hour for SIP URLs.5008

• Action parameter in contact registrations is deprecated.5009

• 2xx to REGISTER MUST contain current contacts. This was just aSHOULD in bis-04.5010

• Multicast operation radically changed. Now, the treatment is no different than unicast. That is, only5011

the first non-1xx response to a multicast request will be used. This is a natural consequence of the5012

layering now applied to the protocol. This still enables anycast types of functions, mirroring the real5013

usage of registrar discovery.5014

• To completely separate transport rules from transaction rules, the rule in bis-04 that said a UAC5015

SHOULD keep a connection opened until a response is received, has been turned into a timer recom-5016

mendation. Specifically, the spec now says that it isRECOMMENDEDthat connections be kept opened5017

for a minimum interval of sufficient duration to guarantee, with high probability, that responses are5018

sent over the same connections as a request.5019



• Re-use of existing connections for new requests to the same address and port is nowRECOMMENDED,5020

it was only aMAY in bis-04.5021

• Modification of headers below theAuthorization header by proxies is no longer disallowed, since the5022

only mechanism that usedAuthorization in that way, PGP, has been deprecated previously.5023

• Authentication of registrations nowRECOMMENDED; no strength was defined previously.5024

• Registering of new headers with IANA is nowSHOULD; no strength was defined previously.5025

• Proxy aggregation of challenges now aSHOULD; no strength was defined previously.5026

• Server support of basic authentication downgraded fromSHOULD to MAY .5027

• UAC resubmitting requests with credentials after a challenge upgraded fromMAY to SHOULD.5028

• TLS is nowRECOMMENDED as the transport layer security for SIP signaling.5029

• UA recursion on a redirect is nowSHOULD; no strength was assigned previously.5030

• UA reuse of headers in a recursed request is nowSHOULD; no strength was assigned previously.5031

• Security considerations added forCall-Info andAlert-Info.5032

• Proxies no longer forward a 6xx immediately on receiving it. Instead, theyCANCEL pending5033

branches immediately. This avoids a potential race condition that would result in a UAC getting a5034

6xx followed by a 2xx. In all cases except this race condition, the result will be the same - the 6xx is5035

forwarded upstream.5036

• The term call-leg has been eliminated from the spec; a more generic term, dialog, is used in its place.5037

• For SRV processing, subsequent requests with the sameCall-ID (as opposed to the same transaction5038

in bis-04) are sent to the same server.5039

• SRV processing generalized to deal with the fact that the default port is transport dependent.5040

• Per IESG request, draft-ietf-sip-serverfeatures has been integrated into bis.5041

• Per IESG request, draft-ietf-sip-100rel will be integrated into bis. This is marked with a placeholder5042

in this draft.5043

• The BNF has been converted from implicit LWS to explicit LWS.5044

• Caching of responses in a proxy to avoid redoing location server lookups used to be aSHOULD.5045

Caching behavior for responses is now fully encapsulated in the transaction processing.5046

• Proxy usage of SRV in processingRoute headers upgraded fromSHOULD to MUST.5047



34 Acknowledgments5048

We wish to thank the members of the IETF MMUSIC and SIP WGs for their comments and suggestions.5049

Detailed comments were provided by Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan, Cdric5050

Fluckiger, Yaron Goland, Bernie Hneisen, Phil Hoffer, Christian Huitema, Jean Jervis, Gadi Karmi, Peter5051

Kjellerstedt, Anders Kristensen, Jonathan Lennox, Gethin Liddell, Keith Moore, Vern Paxson, Moshe J.5052

Sambol, Chip Sharp, Igor Slepchin, Robert Sparks, Eric Tremblay., and Rick Workman.5053

Brian Rosen provided the compiled BNF.5054

This work is based, inter alia, on [46, 47].5055

35 Authors’ Addresses5056

Authors addresses are listed alphabetically for the editors, the writers, and then the original authors of RFC5057

2543.5058

Jonathan Rosenberg5059

dynamicsoft5060

72 Eagle Rock Ave5061

East Hanover, NJ 079365062

USA5063

electronic mail:[email protected]

Henning Schulzrinne5065

Dept. of Computer Science5066

Columbia University5067

1214 Amsterdam Avenue5068

New York, NY 100275069

USA5070


Gonzalo Camarillo5072

Ericsson5073

Advanced Signalling Research Lab.5074

FIN-02420 Jorvas5075

Finland5076


Alan Johnston5078

WorldCom5079

100 South 4th Street5080

St. Louis, MO 631025081

USA5082


Jon Peterson5084

NeuStar, Inc5085



1800 Sutter Street, Suite 5705086

Concord, CA 945205087

USA5088


Robert Sparks5090

dynamicsoft, Inc.5091

5100 Tennyson Parkway5092

Suite 12005093

Plano, Texas 750245094

USA5095


Mark Handley5097

ACIRI5098


Eve Schooler5100

Computer Science Department 256-805101

California Institute of Technology5102

Pasadena, CA 911255103

USA5104


References5106

[1] R. Pandya, “Emerging mobile and personal communication systems,”IEEE Communications Maga-5107

zine, Vol. 33, pp. 44–52, June 1995.5108

[2] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin, “Resource ReSerVation protocol5109

(RSVP) – version 1 functional specification,” Request for Comments 2205, Internet Engineering Task5110

Force, Sept. 1997.5111

[3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: a transport protocol for real-time5112

applications,” Request for Comments 1889, Internet Engineering Task Force, Jan. 1996.5113

[4] H. Schulzrinne, A. Rao, and R. Lanphier, “Real time streaming protocol (RTSP),” Request for Com-5114

ments 2326, Internet Engineering Task Force, Apr. 1998.5115

[5] M. Handley, C. Perkins, and E. Whelan, “Session announcement protocol,” Request for Comments5116

2974, Internet Engineering Task Force, Oct. 2000.5117

[6] M. Handley and V. Jacobson, “SDP: session description protocol,” Request for Comments 2327, Inter-5118

net Engineering Task Force, Apr. 1998.5119

[7] S. Bradner, “Key words for use in RFCs to indicate requirement levels,” Request for Comments 2119,5120

Internet Engineering Task Force, Mar. 1997.5121



[8] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, “Hypertext5122

transfer protocol – HTTP/1.1,” Request for Comments 2616, Internet Engineering Task Force, June5123

1999.5124

[9] T. Berners-Lee, R. Fielding, and L. Masinter, “Uniform resource identifiers (URI): generic syntax,”5125

Request for Comments 2396, Internet Engineering Task Force, Aug. 1998.5126

[10] T. Berners-Lee, L. Masinter, and M. McCahill, “Uniform resource locators (URL),” Request for Com-5127

ments 1738, Internet Engineering Task Force, Dec. 1994.5128

[11] F. Yergeau, “UTF-8, a transformation format of ISO 10646,” Request for Comments 2279, Internet5129

Engineering Task Force, Jan. 1998.5130

[12] D. Crocker, “Standard for the format of ARPA internet text messages,” Request for Comments 822,5131

Internet Engineering Task Force, Aug. 1982.5132

[13] A. Vaha-Sipila, “URLs for telephone calls,” Request for Comments 2806, Internet Engineering Task5133

Force, Apr. 2000.5134

[14] N. Freed and N. Borenstein, “Multipurpose internet mail extensions (MIME) part two: Media types,”5135

Request for Comments 2046, Internet Engineering Task Force, Nov. 1996.5136

[15] W. R. Stevens,TCP/IP illustrated: the protocols, Vol. 1. Reading, Massachusetts: Addison-Wesley,5137

1994.5138

[16] J. C. Mogul and S. E. Deering, “Path MTU discovery,” Request for Comments 1191, Internet Engi-5139

neering Task Force, Nov. 1990.5140

[17] D. Eastlake, S. Crocker, and J. Schiller, “Randomness recommendations for security,” Request for5141

Comments 1750, Internet Engineering Task Force, Dec. 1994.5142

[18] P. Hoffman, L. Masinter, and J. Zawinski, “The mailto URL scheme,” Request for Comments 2368,5143

Internet Engineering Task Force, July 1998.5144

[19] D. Meyer, “Administratively scoped IP multicast,” Request for Comments 2365, Internet Engineering5145

Task Force, July 1998.5146

[20] E. M. Schooler, “A multicast user directory service for synchronous rendezvous,” Master’s Thesis CS-5147

TR-96-18, Department of Computer Science, California Institute of Technology, Pasadena, California,5148

Aug. 1996.5149

[21] S. Donovan, “The SIP INFO method,” Request for Comments 2976, Internet Engineering Task Force,5150

Oct. 2000.5151

[22] J. Rosenberg and H. Schulzrinne, “An offer/answer model with sdp,” Internet Draft, Internet Engineer-5152

ing Task Force, Oct. 2001. Work in progress.5153

[23] R. Rivest, “The MD5 message-digest algorithm,” Request for Comments 1321, Internet Engineering5154

Task Force, Apr. 1992.5155



[24] V. Paxson and M. Allman, “Computing TCP’s retransmission timer,” Request for Comments 2988,5156

Internet Engineering Task Force, Nov. 2000.5157

[25] T. Dierks and C. Allen, “The TLS protocol version 1.0,” Request for Comments 2246, Internet Engi-5158

neering Task Force, Jan. 1999.5159

[26] S. Kent and R. Atkinson, “Security architecture for the internet protocol,” Request for Comments 2401,5160


[27] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, and L. Stewart, “HTTP5162

authentication: Basic and digest access authentication,” Request for Comments 2617, Internet Engi-5163

neering Task Force, June 1999.5164

[28] J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, and L. Stewart, “An exten-5165

sion to HTTP : Digest access authentication,” Request for Comments 2069, Internet Engineering Task5166

Force, Jan. 1997.5167

[29] J. Galvin, S. Murphy, S. Crocker, and N. Freed, “Security multiparts for MIME: multipart/signed and5168

multipart/encrypted,” Request for Comments 1847, Internet Engineering Task Force, Oct. 1995.5169

[30] J. Postel, “User datagram protocol,” Request for Comments 768, Internet Engineering Task Force,5170

Aug. 1980.5171

[31] J. Postel, “DoD standard transmission control protocol,” Request for Comments 761, Internet Engi-5172

neering Task Force, Jan. 1980.5173

[32] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang,5174

and V. Paxson, “Stream control transmission protocol,” Request for Comments 2960, Internet Engi-5175

neering Task Force, Oct. 2000.5176

[33] F. Dawson and T. Howes, “vcard MIME directory profile,” Request for Comments 2426, Internet5177

Engineering Task Force, Sept. 1998.5178

[34] G. Good, “The LDAP data interchange format (LDIF) - technical specification,” Request for Com-5179

ments 2849, Internet Engineering Task Force, June 2000.5180

[35] R. Troost and S. Dorner, “Communicating presentation information in internet messages: The content-5181

disposition header,” Request for Comments 1806, Internet Engineering Task Force, June 1995.5182

[36] R. Braden and Ed, “Requirements for internet hosts - application and support,” Request for Comments5183

1123, Internet Engineering Task Force, Oct. 1989.5184

[37] J. Palme, “Common internet message headers,” Request for Comments 2076, Internet Engineering5185

Task Force, Feb. 1997.5186

[38] H. Alvestrand, “IETF policy on character sets and languages,” Request for Comments 2277, Internet5187

Engineering Task Force, Jan. 1998.5188

[39] G. Nair and H. Schulzrinne, “DHCP option for SIP servers,” Internet Draft, Internet Engineering Task5189

Force, Mar. 2001. Work in progress.5190



[40] A. Gulbrandsen, P. Vixie, and L. Esibov, “A DNS RR for specifying the location of services (DNS5191

SRV),” Request for Comments 2782, Internet Engineering Task Force, Feb. 2000.5192

[41] P. V. Mockapetris, “Domain names - implementation and specification,” Request for Comments 1035,5193


[42] A. Johnston, S. Donovan, R. Sparks, C. Cunningham, D. Willis, J. Rosenberg, K. Summers, and5195

H. Schulzrinne, “SIP telephony call flow examples,” Internet Draft, Internet Engineering Task Force,5196

Apr. 2001. Work in progress.5197

[43] D. Crocker, Ed., and P. Overell, “Augmented BNF for syntax specifications: ABNF,” Request for5198

Comments 2234, Internet Engineering Task Force, Nov. 1997.5199

[44] H. Schulzrinne, “RTP profile for audio and video conferences with minimal control,” Request for5200

Comments 1890, Internet Engineering Task Force, Jan. 1996.5201

[45] R. Hinden, B. Carpenter, and L. Masinter, “Format for literal IPv6 addresses in URL’s,” Request for5202

Comments 2732, Internet Engineering Task Force, Dec. 1999.5203

[46] E. M. Schooler, “Case study: multimedia conference control in a packet-switched teleconferencing5204

system,”Journal of Internetworking: Research and Experience, Vol. 4, pp. 99–120, June 1993. ISI5205

reprint series ISI/RS-93-359.5206

[47] H. Schulzrinne, “Personal mobility for multimedia services in the Internet,” inEuropean Workshop on5207

Interactive Distributed Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar. 1996.5208

Full Copyright Statement5209

Copyright (c) The Internet Society (2001). All Rights Reserved.5210

This document and translations of it may be copied and furnished to others, and derivative works that5211

comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and5212

distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and5213

this paragraph are included on all such copies and derivative works. However, this document itself may not5214

be modified in any way, such as by removing the copyright notice or references to the Internet Society or5215

other Internet organizations, except as needed for the purpose of developing Internet standards in which case5216

the procedures for copyrights defined in the Internet Standards process must be followed, or as required to5217

translate it into languages other than English.5218

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or5219

its successors or assigns.5220

This document and the information contained herein is provided on an ”AS IS” basis and THE IN-5221

TERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WAR-5222

RANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT5223

THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED5224

WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.5225


sip: session initiation protocol - softarmor systems llc

Documents