Reliability of Provisional Responses in the Session Initiation Protocol (SIP) Abstract. 1 Introduction 2. 2 Terminology 2.

Transcription

1 Netwrk Wrking Grup J. Rsenberg/H. Schulzrinne Request fr Cmments: 3262 dynamicsft/clumbia U. Categry: Standards Track June 2002 Reliability f Prvisinal Respnses in the Sessin Initiatin Prtcl (SIP) Status f this Mem This dcument specifies an Internet standards track prtcl fr the Internet cmmunity, and requests discussin and suggestins fr imprvements. Please refer t the current editin f the Internet Official Prtcl Standards (STD 1) fr the standardizatin state and status f this prtcl. Distributin f this mem is unlimited. Cpyright Ntice Cpyright (c) The Internet Sciety (2002). All Rights Reserved. Abstract This dcument specifies an extensin t the Sessin Initiatin Prtcl (SIP) prviding reliable prvisinal respnse messages. This extensin uses the ptin tag 100rel and defines the Prvisinal Respnse ACKnwledgement (PRACK) methd. Cntents 1 Intrductin 2 2 Terminlgy 2 3 UAS Behavir 2 4 UAC Behavir 4 5 The Offer/Answer Mdel and PRACK 7 6 Definitin f the PRACK Methd 7 7 Header Field Definitins RSeq RAck... 8

2 8 IANA Cnsideratins IANA Registratin f the 100rel Optin Tag IANA Registratin f RSeq and RAck Headers Security Cnsideratins 9 10 Cllected BNF 9 11 Acknwledgements 9 12 Authrs Addresses 9 1 Intrductin The Sessin Initiatin Prtcl (SIP) (RFC 3261 [1]) is a request-respnse prtcl fr initiating and managing cmmunicatins sessins. SIP defines tw types f respnses, prvisinal and final. Final respnses cnvey the result f the request prcessing, and are sent reliably. Prvisinal respnses prvide infrmatin n the prgress f the request prcessing, but are nt sent reliably in RFC It was later bserved that reliability was imprtant in several cases, including interperability scenaris with the PSTN. Therefre, an ptinal capability was needed t supprt reliable transmissin f prvisinal respnses. That capability is prvided in this specificatin. The reliability mechanism wrks by mirrring the current reliability mechanisms fr 2xx final respnses t INVITE. Thse requests are transmitted peridically by the Transactin User (TU) until a separate transactin, ACK, is received that indicates receptin f the 2xx by the UAC. The reliability fr the 2xx respnses t INVITE and ACK messages are end-t-end. In rder t achieve reliability fr prvisinal respnses, we d nearly the same thing. Reliable prvisinal respnses are retransmitted by the TU with an expnential backff. Thse retransmissins cease when a PRACK message is received. The PRACK request plays the samerleasack, but fr prvisinal respnses. There is an imprtant difference, hwever. PRACK is a nrmal SIP message, like BYE. As such, its wn reliability is ensured hp-by-hp thrugh each stateful prxy. Als like BYE, but unlike ACK, PRACK has its wn respnse. If this were nt the case, the PRACK message culd nt traverse prxy servers cmpliant t RFC 2543 [4]. Each prvisinal respnse is given a sequence number, carried in the RSeq header field in the respnse. The PRACK messages cntain an RAck header field, which indicates the sequence number f the prvisinal respnse that is being acknwledged. The acknwledgments are nt cumulative, and the specificatins recmmend a single utstanding prvisinal respnse at a time, fr purpses f cngestin cntrl. 2 Terminlgy In this dcument, the key wrds MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are t be interpreted as described in RFC 2119 [2] and indicate requirement levels fr cmpliant SIP implementatins. Rsenberg & Schulzrinne Standards Track [Page 2]

3 3 UAS Behavir AUASMAY send any nn-100 prvisinal respnse t INVITE reliably, s lng as the initial INVITE request (the request whse prvisinal respnse is being sent reliably) cntained a Supprted header field with the ptin tag 100rel. While this specificatin des nt allw reliable prvisinal respnses fr any methd but INVITE, extensins that define new methds that can establish dialgs may make use f the mechanism. The UAS MUST send any nn-100 prvisinal respnse reliably if the initial request cntained a Require header field with the ptin tag 100rel. If the UAS is unwilling t d s, it MUST reject the initial request with a 420 (Bad Extensin) and include an Unsupprted header field cntaining the ptin tag 100rel. AUASMUST NOT attempt t send a 100 (Trying) respnse reliably. Only prvisinal respnses numbered 101 t 199 may be sent reliably. If the request did nt include either a Supprted r Require header field indicating this feature, the UAS MUST NOT send the prvisinal respnse reliably. 100 (Trying) respnses are hp-by-hp nly. Fr this reasn, the reliability mechanisms described here, which are end-t-end, cannt be used. An element that can act as a prxy can als send reliable prvisinal respnses. In this case, it acts as a UAS fr purpses f that transactin. Hwever, it MUST NOT attempt t d s fr any request that cntains a tag in the T field. That is, a prxy cannt generate reliable prvisinal respnses t requests sent within the cntext f a dialg. Of curse, unlike a UAS, when the prxy element receives a PRACK that des nt match any utstanding reliable prvisinal respnse, the PRACK MUST be prxied. There are several reasns why a UAS might want t send a reliable prvisinal respnse. One reasn is if the INVITE transactin will take sme time t generate a final respnse. As discussed in Sectin f RFC 3261, the UAS will need t send peridic prvisinal respnses t request an extensin f the transactin at prxies. The requirement is that a prxy receive them every three minutes, but the UAS needs t send them mre frequently (nce a minute is recmmended) because f the pssibility f packet lss. As a mre efficient alternative, the UAS can send the respnse reliably, in which case the UAS SHOULD send prvisinal respnses nce every tw and a half minutes. Use f reliable prvisinal respnses fr extending transactins is RECOMMENDED. The rest f this discussin assumes that the initial request cntained a Supprted r Require header field listing 100rel, and that there is a prvisinal respnse t be sent reliably. The prvisinal respnse t be sent reliably is cnstructed by the UAS cre accrding t the prcedures f Sectin f RFC In additin, it MUST cntain a Require header field cntaining the ptin tag 100rel, and MUST include an RSeq header field. The value f the header field fr the first reliable prvisinal respnse in a transactin MUST be between 1 and 2**31-1. It is RECOMMENDED that it be chsen unifrmly in this range. The RSeq numbering space is within a single transactin. This means that prvisinal respnses fr different requests MAY use the same values fr the RSeq number. The reliable prvisinal respnse MAY cntain a bdy. The usage f sessin descriptins is described in Sectin 5. The reliable prvisinal respnse is passed t the transactin layer peridically with an interval that starts at T1 secnds and dubles fr each retransmissin (T1 is defined in Sectin 17 f RFC 3261). Once passed t the server transactin, it is added t an internal list f unacknwledged reliable prvisinal respnses. The transactin layer will frward each retransmissin passed frm the UAS cre. Rsenberg & Schulzrinne Standards Track [Page 3]

4 This differs frm retransmissins f 2xx respnses, whse intervals cap at T2 secnds. This is because retransmissins f ACK are triggered n receipt f a 2xx, but retransmissins f PRACKtake place independently f receptin f 1xx. Retransmissins f the reliable prvisinal respnse cease when a matching PRACK is received by the UA cre. PRACK is like any ther request within a dialg, and the UAS cre prcesses it accrding t the prcedures f Sectins 8.2 and f RFC A matching PRACK is defined as ne within the same dialg as the respnse, and whse methd, CSeq-num,andrespnse-num in the RAck header field match, respectively, the methd frm the CSeq, the sequence number frm the CSeq, and the sequence number frm the RSeq f the reliable prvisinal respnse. If a PRACK request is received by the UA cre that des nt match any unacknwledged reliable prvisinal respnse, the UAS MUST respnd t the PRACK with a 481 respnse. If the PRACK des match an unacknwledged reliable prvisinal respnse, it MUST be respnded t with a 2xx respnse. The UAS can be certain at this pint that the prvisinal respnse has been received in rder. It SHOULD cease retransmissins f the reliable prvisinal respnse, and MUST remve it frm the list f unacknwledged prvisinal respnses. If a reliable prvisinal respnse is retransmitted fr 64*T1 secnds withut receptin f a crrespnding PRACK,theUASSHOULD reject the riginal request with a 5xx respnse. If the PRACK cntained a sessin descriptin, it is prcessed as described in Sectin 5 f this dcument. If the PRACK instead cntained any ther type f bdy, the bdy is treated in the same way that bdy in an ACK wuld be treated. After the first reliable prvisinal respnse fr a request has been acknwledged, the UAS MAY send additinal reliable prvisinal respnses. The UAS MUST NOT send a secnd reliable prvisinal respnse until the first is acknwledged. After the first, it is RECOMMENDED that the UAS nt send an additinal reliable prvisinal respnse until the previus is acknwledged. The first reliable prvisinal respnse receives special treatment because it cnveys the initial sequence number. If additinal reliable prvisinal respnses were sent befre the first was acknwledged, the UAS culd nt be certain these were received in rder. The value f the RSeq in each subsequent reliable prvisinal respnse fr the same request MUST be greater by exactly ne. RSeq numbers MUST NOT wrap arund. Because the initial ne is chsen t be less than 2**31-1, but the maximum is 2**32-1, there can be up t 2**31 reliable prvisinal respnses per request, which is mre than sufficient. The UAS MAY send a final respnse t the initial request befre having received PRACKs fr all unacknwledged reliable prvisinal respnses, unless the final respnse is 2xx and any f the unacknwledged reliable prvisinal respnses cntained a sessin descriptin. In that case, it MUST NOT send a final respnse until thse prvisinal respnses are acknwledged. If the UAS des send a final respnse when reliable respnses are still unacknwledged, it SHOULD NOT cntinue t retransmit the unacknwledged reliable prvisinal respnses, but it MUST be prepared t prcess PRACK requests fr thse utstanding respnses. A UAS MUST NOT send new reliable prvisinal respnses (as ppsed t retransmissins f unacknwledged nes) after sending a final respnse t a request. Rsenberg & Schulzrinne Standards Track [Page 4]

5 4 UAC Behavir When the UAC creates a new request, it can insist n reliable delivery f prvisinal respnses fr that request. T d that, it inserts a Require header field with the ptin tag 100rel int the request. A Require header with the value 100rel MUST NOT be present in any requests excepting INVITE, althugh extensins t SIP may allw its usage with ther request methds. If the UAC des nt wish t insist n usage f reliable prvisinal respnses, but merely indicate that it supprts them if the UAS needs t send ne, a Supprted header MUST be included in the request with the ptin tag 100rel. The UAC SHOULD include this in all INVITE requests. If a prvisinal respnse is received fr an initial request, and that respnse cntains a Require header field cntaining the ptin tag 100rel, the respnse is t be sent reliably. If the respnse is a 100 (Trying) (as ppsed t 101 t 199), this ptin tag MUST be ignred, and the prcedures belw MUST NOT be used. The prvisinal respnse MUST establish a dialg if ne is nt yet created. Assuming the respnse is t be transmitted reliably, the UAC MUST create a new request with methd PRACK. This request is sent within the dialg assciated with the prvisinal respnse (indeed, the prvisinal respnse may have created the dialg). PRACK requests MAY cntain bdies, which are interpreted accrding t their type and dispsitin. Nte that the PRACK is like any ther nn-invite request within a dialg. In particular, a UAC SHOULD NOT retransmit the PRACK request when it receives a retransmissin f the prvisinal respnse being acknwledged, althugh ding s des nt create a prtcl errr. Once a reliable prvisinal respnse is received, retransmissins f that respnse MUST be discarded. A respnse is a retransmissin when its dialg ID, CSeq, andrseq match the riginal respnse. The UAC MUST maintain a sequence number that indicates the mst recently received in-rder reliable prvisinal respnse fr the initial request. This sequence number MUST be maintained until a final respnse is received fr the initial request. Its value MUST be initialized t the RSeq header field in the first reliable prvisinal respnse received fr the initial request. Handling f subsequent reliable prvisinal respnses fr the same initial request fllws the same rules as abve, with the fllwing difference: reliable prvisinal respnses are guaranteed t be in rder. As a result, if the UAC receives anther reliable prvisinal respnse t the same request, and its RSeq value is nt ne higher than the value f the sequence number, that respnse MUST NOT be acknwledged with a PRACK, andmust NOT be prcessed further by the UAC. An implementatin MAY discard the respnse, r MAY cache the respnse in the hpes f receiving the missing respnses. The UAC MAY acknwledge reliable prvisinal respnses received after the final respnse r MAY discard them. 5 The Offer/Answer Mdel and PRACK RFC 3261 describes guidelines fr the sets f messages in which ffers and answers [3] can appear. Based n thse guidelines, this extensin prvides additinal pprtunities fr ffer/answer exchanges. If the INVITE cntained an ffer, the UAS MAY generate an answer in a reliable prvisinal respnse (assuming these are supprted by the UAC). That results in the establishment f the sessin befre cmpletin Rsenberg & Schulzrinne Standards Track [Page 5]

6 Header field where PRACK Accept R Accept 2xx - Accept 415 c Accept-Encding R Accept-Encding 2xx - Accept-Encding 415 c Accept-Language R Accept-Language 2xx - Accept-Language 415 c Alert-Inf R - Alert-Inf Allw R Allw 2xx Allw r Allw 405 m Authenticatin-Inf 2xx Authrizatin R Call-ID c m Call-Inf - Cntact R - Cntact 1xx - Cntact 2xx - Cntact 3xx Cntact 485 Cntent-Dispsitin Cntent-Encding Cntent-Language Cntent-Length t Cntent-Type * CSeq c m Date Errr-Inf Expires - Frm c m In-Reply-T R - Max-Frwards R m Min-Expires MIME-Versin Organizatin - Table 1: Summary f header fields, A O Rsenberg & Schulzrinne Standards Track [Page 6]

7 Header field where PRACK Pririty R - Prxy-Authenticate 407 m Prxy-Authenticate 401 Prxy-Authrizatin R Prxy-Require R Recrd-Rute R Recrd-Rute 2xx,18x Reply-T - Require c Retry-After 404,413,480, , ,603 Rute R c Server r Subject R - Supprted R Supprted 2xx Timestamp T c m Unsupprted 420 m User-Agent Via c m Warning r WWW-Authenticate 401 m Table 2: Summary f header fields, P Z f the call. Similarly, if a reliable prvisinal respnse is the first reliable message sent back t the UAC, and the INVITE did nt cntain an ffer, ne MUST appear in that reliable prvisinal respnse. If the UAC receives a reliable prvisinal respnse with an ffer (this wuld ccur if the UAC sent an INVITE withut an ffer, in which case the first reliable prvisinal respnse will cntain the ffer), it MUST generate an answer in the PRACK. If the UAC receives a reliable prvisinal respnse with an answer, it MAY generate an additinal ffer in the PRACK. If the UAS receives a PRACK with an ffer, it MUST place the answer in the 2xx t the PRACK. Once an answer has been sent r received, the UA SHOULD establish the sessin based n the parameters f the ffer and answer, even if the riginal INVITE itself has nt been respnded t. If the UAS had placed a sessin descriptin in any reliable prvisinal respnse that is unacknwledged when the INVITE is accepted, the UAS MUST delay sending the 2xx until the prvisinal respnse is acknwledged. Otherwise, the reliability f the 1xx cannt be guaranteed, and reliability is needed fr prper peratin f the ffer/answer exchange. All user agents that supprt this extensin MUST supprt all ffer/answer exchanges that are pssible based n the rules in Sectin 13.2 f RFC 3261, based n the existence f INVITE and PRACK as requests, and Rsenberg & Schulzrinne Standards Track [Page 7]

8 2xx and reliable 1xx as nn-failure reliable respnses. 6 Definitin f the PRACK Methd This specificatin defines a new SIP methd, PRACK. The semantics f this methd are described abve. Tables 1 and 2 extend Tables 2 and 3 frm RFC 3261 fr this new methd. 7 Header Field Definitins This specificatin defines tw new header fields, RAck and RSeq. Table 1 extends Tables 2 and 3 frm RFC 3261 fr these headers. 7.1 RSeq The RSeq header is used in prvisinal respnses in rder t transmit them reliably. It cntains a single numeric value frm 1 t 2**32 1. Fr details n its usage, see Sectin 3. Example: RSeq: Header field where prxy ACK BYE CAN INV OPT REG PRA RAck R m RSeq 1xx Figure 1: RAck and RSeq Header Fields 7.2 RAck The RAck header is sent in a PRACK request t supprt reliability f prvisinal respnses. It cntains tw numbers and a methd tag. The first number is the value frm the RSeq header in the prvisinal respnse that is being acknwledged. The next number, and the methd, are cpied frm the CSeq in the respnse that is being acknwledged. The methd name in the RAck header is case sensitive. Example: RAck: {\INVITE} 8 IANA Cnsideratins This dcument registers a new ptin tag and tw new headers, based n the IANA registratin prcess f RFC Rsenberg & Schulzrinne Standards Track [Page 8]

9 8.1 IANA Registratin f the 100rel Optin Tag This specificatin registers a single ptin tag, 100rel. The required infrmatin fr this registratin, as specified in RFC 3261, is: Name: 100rel Descriptin: This ptin tag is fr reliability f prvisinal respnses. When present in a Supprted header, it indicates that the UA can send r receive reliable prvisinal respnses. When present in a Require header in a request, it indicates that the UAS MUST send all prvisinal respnses reliably. When present in a Require header in a reliable prvisinal respnse, it indicates that the respnse is t be sent reliably. 8.2 IANA Registratin f RSeq and RAck Headers The fllwing is the registratin fr the RSeq header: RFC Number: RFC3262 Header Name: RSeq Cmpact Frm: nne The fllwing is the registratin fr the RAck header: RFC Number: RFC3262 Header Name: RAck Cmpact Frm: nne 9 Security Cnsideratins ThePRACK request can be injected by attackers t frce retransmissins f reliable prvisinal respnses t cease. As these respnses can cnvey imprtant infrmatin, PRACK messages SHOULD be authenticated as any ther request. Authenticatin prcedures are specified in RFC Cllected BNF The BNF fr the RAck and RSeq headers and the PRACK methd are defined here. PRACKm = %x b ; PRACK in caps Methd = INVITEm / ACKm / OPTIONSm / BYEm / CANCELm / REGISTERm / PRACKm Rsenberg & Schulzrinne Standards Track [Page 9]

10 / extensin-methd RAck = "RAck" HCOLON respnse-num LWS CSeq-num LWS Methd respnse-num = 1*DIGIT CSeq-num = 1*DIGIT RSeq = "RSeq" HCOLON respnse-num 11 Acknwledgements The authrs wuld like t thank J Hrnsby, Jnathan Lennx, Rhan Mahy, Allisn Mankin, Adam Rach, and Tim Schreder fr the cmments n this dcument. 12 Authrs Addresses Jnathan Rsenberg dynamicsft 72 Eagle Rck Avenue First Flr East Hanver, NJ jdrsen@dynamicsft.cm Henning Schulzrinne Clumbia University M/S Amsterdam Ave. New Yrk, NY schulzrinne@cs.clumbia.edu Full Cpyright Statement Cpyright (c) The Internet Sciety (2002). All Rights Reserved. This dcument and translatins f it may be cpied and furnished t thers, and derivative wrks that cmment n r therwise explain it r assist in its implementatin may be prepared, cpied, published and distributed, in whle r in part, withut restrictin f any kind, prvided that the abve cpyright ntice and this paragraph are included n all such cpies and derivative wrks. Hwever, this dcument itself may nt be mdified in any way, such as by remving the cpyright ntice r references t the Internet Sciety r ther Internet rganizatins, except as needed fr the purpse f develping Internet standards in which case the prcedures fr cpyrights defined in the Internet Standards prcess must be fllwed, r as required t translate it int languages ther than English. The limited permissins granted abve are perpetual and will nt be revked by the Internet Sciety r its successrs r assigns. This dcument and the infrmatin cntained herein is prvided n an AS IS basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, Rsenberg & Schulzrinne Standards Track [Page 10]

11 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WAR- RANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknwledgement Funding fr the RFC Editr functin is currently prvided by the Internet Sciety. Nrmative References [1] J. Rsenberg, H. Schulzrinne, G. Camarill, A. Jhnstn, J. Petersn, R. Sparks, M. Handley, and E. Schler, SIP: sessin initiatin prtcl, RFC 3261, Internet Engineering Task Frce, June [2] S. Bradner, Key wrds fr use in RFCs t indicate requirement levels, RFC 2119, Internet Engineering Task Frce, Mar [3] J. Rsenberg and H. Schulzrinne, An ffer/answer mdel with sessin descriptin prtcl (SDP), RFC 3264, Internet Engineering Task Frce, June Infrmative References [4] M. Handley, H. Schulzrinne, E. Schler, and J. Rsenberg, SIP: sessin initiatin prtcl, RFC 2543, Internet Engineering Task Frce, Mar Rsenberg & Schulzrinne Standards Track [Page 11]