Internet Engineering Task Force Gonzalo Camarillo Internet draft Ericsson October 2000 Expires June 2001 Confirmation of SDP preconditions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes certain functionality that is missing in the current "Integration of Resource Management and SIP" [1] (a.k.a. manyfolks draft). An extension to add this functionality is outlined. This functionality is needed in general to provide richer signalling capabilities and can be employed in several scenarios. This draft describes its use in third party call control applications. If this extension is accepted it is foreseen that this draft would be merged with [1]. 1. Introduction "Integration of Resource Management in SIP" [1] provides a mechanism that allows a UA issuing a SIP message with SDP preconditions to ask the other party to confirm that the preconditions are met. The "confirm" attribute together with the COMET method are used for that purpose. A typical situation where the "confirm" attribute is used is a two party session with QoS preconditions. The callee will request a Camarillo 1 Confirmation of SDP preconditions confirmation message (COMET) from the caller by including a "confirm" attribute in a 183 response. As soon as the calleeÆs UA has finished the resource reservation in the callee-caller direction (using RSVP for instance) and a COMET arrives from the caller (confirming that resources are also available in the caller-callee direction) the callee will be alerted. The "confirm" attribute in (b) triggers the COMET in (e). Caller Callee | (a) INVITE | |------------------>| | (b) 183 | |<------------------| | (c) PRACK | |------------------>| |(d) 200 OK (PRACK) | |<------------------| | (e) COMET | |------------------>| | (f) 200 OK (COMET)| |<------------------| |(g) 200 OK (INVITE)| |<------------------| | (h) ACK | |------------------>| (a) INVITE sip:callee@ws4321.provider2.com SIP/2.0 Via: SIP/2.0/UDP ws1234.provider1.com:5060 Require: 100rel From: Caller To: Calee Call-ID: 12345678@ws1234.provider1.com CSeq: 1 INVITE Contact: Caller Content-Type: application/sdp Content-Length: 155 v=0 o=Caller 2891234526 2891234526 IN IP4 ws1234.provider1.com s=Session SDP c=IN IP4 10.0.0.1 t=0 0 m=audio 20002 RTP/AVP 0 a=qos:mandatory sendrecv (b) SIP/2.0 183 Session Progress Camarillo 2 Confirmation of SDP preconditions Via: SIP/2.0/UDP ws1234.provider1.com:5060 Require: 100rel RSeq: 112233 From: Caller To: Callee ;tag=314159 Call-ID: 12345678@ws1234.provider1.com CSeq: 1 INVITE Contact: Callee Content-Type: application/sdp Content-Length: 163 v=0 o=Callee 2891234526 2891234526 IN IP4 ws4321.provider2.com s=Session SDP c=IN IP4 10.0.0.3 t=0 0 m=audio 30000 RTP/AVP 0 a=qos:mandatory sendrecv confirm (c) PRACK sip:callee@ws4321.provider2.com SIP/2.0 RAck: 112233 1 INVITE Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: Caller To: Callee ;tag=314159 Call-ID: 12345678@ws1234.provider1.com CSeq: 2 PRACK (d) SIP/2.0 200 OK Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: Caller To: Callee ;tag=314159 Call-ID: 12345678@ws1234.provider1.com CSeq: 2 PRACK (e) COMET sip:callee@ws4321.provider2.com SIP/2.0 Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: Caller To: Callee ;tag=314159 Call-ID: 12345678@ws1234.provider1.com CSeq: 3 COMET Content-Type: application/sdp Content-Length: 149 v=0 o=Caller 2891234526 2891234526 IN IP4 ws1234.provider1.com s=Session SDP c=IN IP4 10.0.0.1 t=0 0 m=audio 20002 RTP/AVP 0 a=qos:success send Camarillo 3 Confirmation of SDP preconditions (f) SIP/2.0 200 OK Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: Caller To: Callee ;tag=314159 Call-ID: 12345678@ws1234.provider1.com CSeq: 3 COMET (g) SIP/2.0 200 OK Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: Caller To: Callee ;tag=314159 Call-ID: 12345678@ws1234.provider1.com CSeq: 1 INVITE Contact: Callee Content-Type: application/sdp Content-Length: 129 v=0 o=Callee 2891234526 2891234526 IN IP4 ws4321.provider2.com s=Session SDP c=IN IP4 10.0.0.3 t=0 0 m=audio 30000 RTP/AVP 0 (h) ACK sip:callee@ws4321.provider2.com SIP/2.0 Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: Caller To: Callee ;tag=314159 Call-ID: 12345678@ws1234.provider1.com CSeq: 1 ACK Contact: Caller 2. Caller triggering COMETs Note that in the previous example, the COMET in (e) is sent because the callee wanted it to be sent - (b) contained a "confirm" parameter. If the caller included a "confirm" attribute in the INVITE (a), it would trigger a COMET from the callee to the caller. The caller does not have a means for triggering COMETs from the caller to the callee. Similarly, the callee cannot trigger COMETs from the callee to the caller. This mechanism is needed is certain situations, such as the ones described in [2]. The need of this mechanism is described in the "open issues" section of [2] and it was presented in the SIP WG meeting in Pittsburgh [3]. Camarillo 4 Confirmation of SDP preconditions When third party call control is performed, the controller wants to be sure that the session establishment does not go on until it sends a COMET. The following example, taken from [2], helps understand this need. Controller A B | (1) INVITE | | |------------------>| | | (2) 183 SDP A | | |<------------------| | | (3) INVITE SDP A | | |------------------------------------->| | (4) 183 SDP B | | |<-------------------------------------| | (5) PRACK SDP B | | |------------------>| | | (6) 200 OK (PRACK)| | |<------------------| | | (7) PRACK | | |------------------------------------->| | (8) 200 OK (PRACK)| | |<-------------------------------------| | (9) COMET | | |<-------------------------------------| |(10) 200 OK (COMET)| | |------------------------------------->| | (11) COMET | | |<------------------| | |(12) 200 OK (COMET)| | |------------------>| | | (13) COMET | | |------------------>| | |(14) 200 OK (COMET)| | |<------------------| | |(15) 200 OK (INVITE) | |<------------------| | | (16) COMET | | |------------------------------------->| |(17) 200 OK (COMET)| | |<-------------------------------------| |(18) 200 OK (INVITE) | |<-------------------------------------| | (19) ACK | | |------------------>| | | (20) ACK | | |------------------------------------->| | | | Controller A B Camarillo 5 Confirmation of SDP preconditions After (12), all the preconditions are met. However, the controller does not send a COMET to B (16) until A has answered the INVITE (15). Therefore, if A relied on mechanisms different than COMET (such as ResvConf in RSVP) to check if the resource reservation was already done third party call control mechanisms would fail, since A would go on with the session establishment after (12), instead of waiting for (15). Preconditions met confirmations must rely solely on application layer mechanisms - SIP. Thus, a mechanism that allows the controller to ask A to wait for the COMET before continuing with the session is needed. 3. Solution A direction attribute is needed in order to indicate to which direction the "confirm" attribute applies. That is, which party sends the COMET. Section 4 of [1] would look as follows: qos-attribute = "a=qos:" strength-tag SP direction-tag [SP confirmation-tag] strength-tag = ("mandatory" | "optional" | "success" | "failure") direction-tag = ("send" | "recv" | "sendrecv") confirmation-tag = "confirm" SP direction-tag The SDP contained in INVITE (a) would look as follows: v=0 o=Caller 2891234526 2891234526 IN IP4 ws1234.provider1.com s=Session SDP c=IN IP4 10.0.0.1 t=0 0 m=audio 20002 RTP/AVP 0 a=qos:mandatory sendrecv confirm send The SDP in (b) would be then: v=0 o=Callee 2891234526 2891234526 IN IP4 ws4321.provider2.com s=Session SDP c=IN IP4 10.0.0.3 t=0 0 m=audio 30000 RTP/AVP 0 a=qos:mandatory sendrecv confirm recv The following table illustrates the allowed values for the direction attribute in the response. Each row represents a value of the direction in the SIP INVITE, and each column the value in the response. An entry of N/A means that this combination is not allowed. A value of A->B (B->A) implies that the COMET will be sent from A to B (B to A). A value of A<->B means that the will be two Camarillo 6 Confirmation of SDP preconditions COMETs, one in each direction. The value in the response is the one used by both parties. B: response A: request send recv sendrecv none send N/A A->B A<->B N/A recv B->A N/A A<->B N/A sendrecv N/A N/A A<->B N/A none B->A A->B A<->B No COMETs This table assumes that the preconditions suggested in the INVITE (e.g. mandatory sendrecv) are accepted and thus included in the response. If the response does not include all of them (e.g. mandatory recv) there are interactions with the direction attribute regarding COMETs and this table would not be valid. Some N/A entries would become valid combinations. These interactions are already present in the current approach [1]. 4. Backward compatibility An implementation that does not understand the direction attribute introduced by this draft would find the "a=qos" line malformed and it will thus return an error to the UA issuing the INVITE. The UA can then fall back to the previous syntax (defined by [1]) if it wishes to proceed anyway. 5. References [1] W. Marshall et al, "Integration of Resource Management and SIP", draft-manyfolks-sip-resource-01.txt, IETF; June 2000. Work in progress. [2] G. Camarillo, "Third party call control with SDP preconditions", draft-camarillo-3pcc-qos-00.txt, IETF; July 2000. Work in progress. [3] http://www.softarmor.com/sipwg/meets/IETF48/slides/pres- camarillo-3pccprecon-sip-48.ppt 6. Author's Addresses Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland Phone: +358 9 299 3371 Fax: +358 9 299 3052 Email: Gonzalo.Camarillo@ericsson.com Camarillo 7