SIP Working Group F. Haerens Internet Draft Alcatel Document: February 2001 Category: Informational Third Party Call Control for Resource Management Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract This document describes how to perform third party call control in SIP for both a basic single-media and multi-media call when SDP preconditions are used. This draft considers the Quality of Service and the resource management. There are no new SIP extensions needed to accomplish this. The mechanism outlined is illustrated with examples in order to help understand it. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. This document refers to ôcontrollerö as the entity in the third party call control which allows to set up and manage a communications relationship between two or more other parties [6]. 3. Basic SingleûMedia Third party call control with SDP preconditions The section explains the basic single-media third party call control with SDP preconditions based on reference [3] W. Marshall et al, "Integration of Resource Management and SIP", draft-manyfolks-sip- resource-01.txt, IETF; June 2000. Work in progress. Haerens Category:Informational û Expiration:August 2001 1 Third Party Call Control for Resource Management February 2001 The confirmation of the SDP preconditions follows the revised procedures given in section 6. Figure 1 presents a high-level overview of a basic Third Party Call Control flow. This example is appropriate for a single-media session with a mandatory quality-of-service "sendrecv" precondition, where both the user A and User B can only perform a single-direction ("send") resource reservation. The controller prepares for User A an SDP message body for the INVITE describing the desired QoS and security preconditions for each media flow, and the desired direction "sendrecv. This SDP is included in the INVITE message sent to User A through the proxies, and includes an entry "a=qos:mandatory sendrecv." The User A on receipt of the INVITE , being willing to perform the requested precondition, returns a 183-Session-Progress provisional response containing SDP, along with the qos/security attribute for each stream having a precondition. This 183-Session-Progress provisional response is sent using the reliability mechanism of [2]. The controller sends the appropriate PRACK and the User A UAS responds with a 200-OK to the PRACK. Figure 1 (Proposal 1) User A User B | Controller | | | | | (1) INVITE SDP held | | |<----------------------| | | (2) 183 w/SDP A | | |---------------------->| | | | (5) INVITE w/SDP A | | (3) PRACK |---------------------->| |<----------------------|(6) 183 w/SDP B confirm:recv | (4) 200 OK (of PRACK) |<----------------------| |---------------------->| (7) PRACK | | |---------------------->| | | (8)200 OK (of PRACK) | | |<----------------------| |(9) NOTIFY w/SDP B confirm:recv | |<----------------------| | |(10) 200 OK (of NOTIFY)| | |---------------------->| | | | | | | | | Reservation Reservation | ===========> <=========== | | | (20) COMET | | |---------------------->| | | | (21) COMET | | |---------------------->| Haerens 2 Third Party Call Control for Resource Management February 2001 | | (22) 200 OK (of COMET)| | |<----------------------| | (23) 200 OK (of COMET)| | |<----------------------| | | | | | | Controller User Alerted | | | | (25) 180 Ringing | (24) 180 Ringing | |---------------------->|<----------------------| | (26) PRACK | (27) PRACK | |<----------------------|---------------------->| | (29) 200 OK (of PRACK)| (28) 200 OK (of PRACK)| |---------------------->|<----------------------| | | | | | User Picks-Up | Controller the phone | | | | (31) 200 OK | (30) 200 OK | |---------------------->|<----------------------| | | | | (32) ACK | (33) ACK | |<----------------------|---------------------->| | | Figure 1(Proposal 1): Basic 3PCC Flow with SDP Preconditions Figure 1 (Proposal 2) User A User B | Controller | | | | | (1) INVITE SDP held | | |<----------------------| | | (2) 200 SDP A | | |---------------------->| | | (3) ACK | | |<----------------------| | | | (5) INVITE w/SDP A | | |---------------------->| | | (6) 183 w/SDP B | | |<----------------------| | | (7) PRACK | | |---------------------->| | | (8)200 OK (of PRACK) | | (9) INVITE w/SDP B |<----------------------| |<----------------------| | | | | | Reservation Reservation | Haerens 3 Third Party Call Control for Resource Management February 2001 ===========> <=========== | | | (20) COMET | | |---------------------->| | | | (21) COMET | | |---------------------->| | | (22) 200 OK (of COMET)| | |<----------------------| | (23) 200 OK (of COMET)| | |<----------------------| | | | | | | Controller User Alerted | | | | (25) 180 Ringing | (24) 180 Ringing | |---------------------->|<----------------------| | (26) PRACK | (27) PRACK | |<----------------------|---------------------->| | (29) 200 OK (of PRACK)| (28) 200 OK (of PRACK)| |---------------------->|<----------------------| | | | | | User Picks-Up | Controller the phone | | | | (31) 200 OK | (30) 200 OK | |---------------------->|<----------------------| | | | | (32) ACK | (33) ACK | |<----------------------|---------------------->| | | Figure 1(Proposal 2): Basic 3PCC Flow with SDP Preconditions Figure 1 (Proposal 3) User A User B | Controller | | | | | (1) INVITE SDP held | | |<----------------------| (4) INVITE SDP held | | (2) 200 SDP A |---------------------->| |---------------------->| (5) 200 SDP B | | (3) ACK |<----------------------| |<----------------------| (6) ACK | | |---------------------->| | | (5) INVITE w/SDP A | | |---------------------->| | (9) INVITE w/SDP B | | |<----------------------| | Haerens 4 Third Party Call Control for Resource Management February 2001 | | | | Reservation Reservation | ===========> <=========== | | | (20) COMET | | |---------------------->| | | | (21) COMET | | |---------------------->| | | (22) 200 OK (of COMET)| | |<----------------------| | (23) 200 OK (of COMET)| | |<----------------------| | | | | | | Controller User Alerted | | | | (25) 180 Ringing | (24) 180 Ringing | |---------------------->|<----------------------| | (26) PRACK | (27) PRACK | |<----------------------|---------------------->| | (29) 200 OK (of PRACK)| (28) 200 OK (of PRACK)| |---------------------->|<----------------------| | | | | | User Picks-Up | Controller the phone | | | | (31) 200 OK | (30) 200 OK | |---------------------->|<----------------------| | | | | (32) ACK | (33) ACK | |<----------------------|---------------------->| | | Figure 1(Proposal 3): Basic 3PCC Flow with SDP Preconditions Similarly the controller also prepares for User B an SDP message body for the INVITE describing the desired QoS and security preconditions for each media flow as received from User A into the 183-Session_Progress provisional response, and the desired direction "sendrecv. This SDP is included in the INVITE message sent to User B through the proxies, and includes an entry "a=qos:mandatory sendrecv." The User B on receipt of the INVITE , being willing to perform the requested precondition,, returns a 183-Session-Progress provisional response containing SDP, along with the qos/security attribute for each stream having a precondition. Since the "sendrecv" direction tag required a cooperative effort of the User A and User B, the User B requests a confirmation when the preconditions are met, with the SDP entry "a=qos:mandatory sendrecv confirm recvö. The direction-tag indicates that the COMET will be sent by the party (here Controller) who received the confirmation- Haerens 5 Third Party Call Control for Resource Management February 2001 tag. This 183-Session-Progress provisional response is sent using the reliability mechanism of [2]. The controller sends the appropriate PRACK and the User B UAS responds with a 200-OK to the PRACK. The User B now attempts to reserve the qos resources and establish the security associations. The controller now waits until the receipt of the 200-OK to the PRACK from User B is obtained before sending the SDP B to User A. During the discussion at the 49th IETF San Diego meeting it was not recommended to sent the SDP B into the PRACK message due to time outs which may occur during the provisional response reliability procedures at both sides. It was recommended to consider a re-INVITE w/SDP B but this assumes that an 200 OK was returned for User A. Presently a re-INVITE cannot be sent before a 200 OK is received from the UAS. Also the sending of the initial INVITE with ôSDP heldö may not cause an alerting to be sent to the User A (by assuming that the sending with SDP with ôSDP heldö may not trigger an alerting at the UserÆs A side or specifying a SDP attribute). This procedure is given in figure 1 (proposal 2). The proposal 3 also describes the possibility that an INVITE with ôSDP heldö is sent to user B. In figure 1 of proposal 1 the SDP B is sent from the Controller to the User A in a NOTIFY mechanism defined in Event Notification in SIP [7] followed by a 200 OK message returned form Party A to the Controller. In particular the following should be noted: i) The NOTIFY should reflect the To:, From:, and Call-ID headers from the INVITE as if they had arrived in a SUBSCRIBE. ii) Analogous to the case for SUBSCRIBE described in [7], the agent that issued the INVITE MUST be prepared to receive a NOTIFY before the session completes. iii) The presence of the ôAllow-Eventsö header in a message is sufficient to indicate support for NOTIFY. iv) The presence an ôeventö header containing e.g.Event: precondition is proposed As an alternative solution the INFO mechanism or the 18x-Session- Progess message using the reliability mechanism could be considered. The use of the 18x-Session-Progress message is not recommended because this assumes that call progress messages need to be sent from UAC to UAS, it should also be decided whether a new 18x- Session-Progress or the present 183-Session-Progress could be used. It is proposed that a decision is made on one of the above proposals. Haerens 6 Third Party Call Control for Resource Management February 2001 The figures 1 above describe the various proposals for passing the SDP B on receipt in the controller of the 200-OK to the PRACK from User B. The SDP B will be sent to the User A with the SDP entry as received from User B with the qos attribute set to "a=qos:mandatory sendrecv confirm recvö. The direction-flag will indicate that the COMET message will be sent by the party (here User A) who received the confirmation-tag. The SDP B is received by the User A, and the User A requests the resources needed in its "send" direction, and establishes the security associations. Once the preconditions are met, the User A sends a COMET message as requested by the confirmation token. This COMET message contains an entry "a=qos:success send". This COMET message is relayed by the controller via a COMET message to User B. At this point the User A is also alerted and a 180- Ringing provisional response is forwarded. This provisional response is also sent using the reliability mechanism of [2], resulting in a PRACK message and 200-OK of the PRACK The User B successfully performs its resource reservation, in its "send" direction, and waits for the COMET message from the User A. On receipt of the COMET message, the User B combines the "send" confirmation in the SDP with its "send" success, and knows all preconditions have been met. The User B then continues with session establishment. At this point it alerts the user, and sends a 180- Ringing provisional response. This provisional response is also sent using the reliability mechanism of [2], resulting in a PRACK message and 200-OK of the PRACK. When the User A or User B answers, the normal SIP 200-OK final response is sent through the proxies to the Controller; and the controller responds with an ACK message. At this point, both users A and B are in a single point-to-point call and are under control of a third party (named controller) provided the controller has identified itself in the From field of the INVITE. It should be noted that the media is exchanged between users A and B rather than with the controller. Either user can terminate the call. An endpoint that detects an "on-hook" (request to terminate the call) releases the QoS resources held for the connection, and sends a SIP BYE message to the controller which still has complete control over the call. This message will be acknowledged with a 200-OK. 4. Message example of a Basic SingleûMedia Third party call control with SDP preconditions In this example the controller is part of a gateway which e.g. maps the Open Service Access interface method from the Application Servers to the SIP based Service Capability Servers. Haerens 7 Third Party Call Control for Resource Management February 2001 See also section 6 for more details on the use of the proposed third party call control flows for the OSA architecture. (1) INVITE sip:userA@provider1.com SIP/2.0 Via: SIP/2.0/UDP gateway.provider3.com:5060 Require: 100rel From: Controller To: UserA Call-ID: 12345678@gateway.provider3.com CSeq: 1 INVITE Contact: Controller Content-Type: application/sdp Content-Length: 156 v=0 o=Controller 2891234526 2891234526 IN IP gateway.provider3.com s=Session SDP c=IN IP4 0.0.0.0 t=0 0 m=audio 0 RTP/AVP a=qos:mandatory sendrecv (2) SIP/2.0 183 Session Progress Via: SIP/2.0/UDP gateway.provider3.com:5060 Require: 100rel RSeq: 223344 From: Controller To: UserA ;tag=123456 Call-ID: 12345678@gateway.provider3.com CSeq: 1 INVITE Contact: UserA Content-Type: application/sdp Content-Length: 169 v=0 o=UserA 2891234526 2891234526 IN IP4 provider1.com s=Session SDP c=IN IP4 10.0.0.3 t=0 0 m=audio 30002 RTP/AVP 0 8 a=qos:mandatory sendrecv (3) PRACK sip:userA@provider1.com SIP/2.0 RAck: 223344 1 INVITE Via: SIP/2.0/UDP gateway.provider3.com:5060 From: Controller To: UserA ;tag=123456 Call-ID: 12345678@gateway.provider3.com CSeq: 2 PRACK Haerens 8 Third Party Call Control for Resource Management February 2001 (4) SIP/2.0 200 OK Via: SIP/2.0/UDP gateway.provider3.com:5060 From: Controller To: UserA ;tag=123456 Call-ID: 12345678@gateway.provider3.com CSeq: 2 PRACK (5) INVITE sip:UserB@provider2.com SIP/2.0 Via: SIP/2.0/UDP gateway.provider3.com:5060 Require: 100rel From: Controller To: UserB Call-ID: 11223344@gateway.provider3.com CSeq: 1 INVITE Contact: Controller Content-Type: application/sdp Content-Length: 268 v=0 o=Controller 2891234526 2891234526 IN IP4 gateway.provider3.com s=Session SDP t=0 0 m=audio 30002 RTP/AVP 0 8 c=IN IP4 10.0.0.3 a=qos:mandatory sendrecv The INVITE method to User B could also be sent using the same Call- ID (= 12345678)as the INVITE to User A and will create a second call leg. This INVITE message must contain a ôbranch=1ö field in order to distinguish the various/repeated responses received from the different call legs involved. INVITE sip:UserB@provider2.com SIP/2.0 Via: SIP/2.0/UDP gateway.provider3.com:5060; branch=1 Require: 100rel From: Controller To: UserB Call-ID: 12345678@gateway.provider3.com CSeq: 1 INVITE Contact: Controller Content-Type: application/sdp Content-Length: 268 v=0 o=Controller 2891234526 2891234526 IN IP4 gateway.provider3.com s=Session SDP t=0 0 m=audio 30002 RTP/AVP 0 8 c=IN IP4 10.0.0.3 a=qos:mandatory sendrecv Haerens 9 Third Party Call Control for Resource Management February 2001 (6) SIP/2.0 183 Session Progress Via: SIP/2.0/UDP gateway.provider3.com:5060 Require: 100rel RSeq: 334455 From: Controller To: UserB ;tag=112233 Call-ID: 11223344@gateway.provider3.com CSeq: 1 INVITE Contact: UserB Content-Type: application/sdp Content-Length: 246 v=0 o=UserB 2891234526 2891234526 IN IP4 provider2.com s=Session SDP c=IN IP4 10.0.0.2 t=0 0 m=audio 40002 RTP/AVP 8 a=qos:mandatory sendrecv confirm recv. (7) PRACK sip:UserB@provider2.com SIP/2.0 RAck: 334455 1 INVITE Via: SIP/2.0/UDP gateway.provider3.com:5060 From: Controller To: UserB ;tag=112233 Call-ID: 11223344@gateway.provider3.com CSeq: 2 PRACK (8) SIP/2.0 200 OK Via: SIP/2.0/UDP gateway.provider3.com:5060 From: Controller To: UserB ;tag=112233 Call-ID: 11223344@gateway.provider3.com CSeq: 2 PRACK (9) SIP/2.0 NOTIFY Via: SIP/2.0/UDP gateway.provider3.com:5060 Require: 100rel RSeq: 445566 From: Controller To: UserA ;tag=123456 Call-ID: 12345678@gateway.provider3.com CSeq: 1 INVITE Contact: UserA Content-Type: application/sdp Haerens 10 Third Party Call Control for Resource Management February 2001 Content-Length: 169 v=0 o=UserB 2891234526 2891234526 IN IP4 provider2.com s=Session SDP c=IN IP4 10.0.0.2 t=0 0 m=audio 40002 RTP/AVP 8 a=qos:mandatory sendrecv confirm recv (10) SIP/2.0 200 OK Via: SIP/2.0/UDP gateway.provider3.com:5060 From: Controller To: UserA ;tag=123456 Call-ID: 12345678@gateway.provider3.com CSeq: 3 PRACK (20) COMET sip:UserA@provider1.com SIP/2.0 Via: SIP/2.0/UDP gateway.provider3.com:5060 To: UserA From: Controller ;tag=123456 Call-ID: 12345678@gateway.provider3.com CSeq: 1 COMET Content-Type: application/sdp Content-Length: 159 v=0 o=UserA 2891234526 2891234526 IN IP4 userA.provider1.com s=Session SDP c=IN IP4 10.0.0.3 t=0 0 m=audio 30002 RTP/AVP 0 8 a=qos:success sendrecv (21) COMET sip:UserB@provider2.com SIP/2.0 Via: SIP/2.0/UDP gateway.provider3.com:5060 From: Controller ;tag=112233 To: UserB Call-ID: 11223344@gateway.provider3.com CSeq: 3 COMET Content-Type: application/sdp Content-Length: 248 v=0 o=UserA 2891234526 2891234526 IN IP4 userA.provider1.com s=Session SDP t=0 0 Haerens 11 Third Party Call Control for Resource Management February 2001 m=audio 30002 RTP/AVP 0 8 c=IN IP4 10.0.0.3 a=qos:success sendrecv (22) SIP/2.0 200 OK Via: SIP/2.0/UDP gateway.provider3.com:5060 From: Controller ;tag=112233 To: UserB Call-ID: 11223344@gateway.provider3.com CSeq: 3 COMET (23) SIP/2.0 200 OK Via: SIP/2.0/UDP gateway.provider3.com:5060 To: UserA From: Controller ;tag=123456 Call-ID: 12345678@gateway.provider3.com CSeq: 1 COMET (24) SIP/2.0 180 Ringing Via: SIP/2.0/UDP gateway.provider3.com:5060 From: Controller To: UserB ;tag=112233 Call-ID: 11223344@gateway.provider3.com CSeq: 1 INVITE (25) SIP/2.0 180 Ringing Via: SIP/2.0/UDP gateway.provider3.com:5060 From: Controller To: UserA ;tag=123456 Call-ID: 12345678@gateway.provider3.com CSeq: 1 INVITE (26) PRACK sip:userA@provider1.com SIP/2.0 Via: SIP/2.0/UDP gateway.provider3.com:5060 From: Controller To: UserA ;tag=123456 Call-ID: 12345678@gateway.provider3.com CSeq: 2 PRACK RAck: 223344 1 INVITE (27) Haerens 12 Third Party Call Control for Resource Management February 2001 PRACK sip:UserB@provider2.com SIP/2.0 Via: SIP/2.0/UDP gateway.provider3.com:5060 From: Controller To: UserB ;tag=112233 Call-ID: 11223344@gateway.provider3.com CSeq: 2 PRACK RAck: 334455 1 INVITE (28) SIP/2.0 200 OK Via: SIP/2.0/UDP gateway.provider3.com:5060 From: Controller To: UserB ;tag=112233 Call-ID: 11223344@gateway.provider3.com CSeq: 2 PRACK (29) SIP/2.0 200 OK Via: SIP/2.0/UDP gateway.provider3.com:5060 From: Controller To: UserA ;tag=123456 Call-ID: 12345678@gateway.provider3.com CSeq: 2 PRACK (30) SIP/2.0 200 OK Via: SIP/2.0/UDP gateway.provider3.com:5060 From: Controller To: UserB ;tag=112233 Call-ID: 11223344@gateway.provider3.com CSeq: 1 INVITE Contact: UserB Content-Type: application/sdp Content-Length: 178 v=0 o=UserB 2891234526 2891234526 IN IP4 userB.provider2.com s=Session SDP c=IN IP4 10.0.0.2 t=0 0 m=audio 40002 RTP/AVP 8 (31) SIP/2.0 200 OK Via: SIP/2.0/UDP gateway.provider3.com:5060 From: Controller To: UserA ;tag=123456 Call-ID: 12345678@gateway.provider3.com CSeq: 1 INVITE Contact: UserB Content-Type: application/sdp Haerens 13 Third Party Call Control for Resource Management February 2001 Content-Length: 178 v=0 o=UserB 2891234526 2891234526 IN IP4 userB.provider2.com s=Session SDP c=IN IP4 10.0.0.2 t=0 0 m=audio 40002 RTP/AVP 8 (32) ACK sip:userA@provider1.com SIP/2.0 Via: SIP/2.0/UDP gateway.provider3.com:5060 From: Controller To: UserA ;tag=123456 Call-ID: 12345678@gateway.provider3.com CSeq: 1 ACK (33) ACK sip:userB@provider2.com SIP/2.0 Via: SIP/2.0/UDP gateway.provider3.com:5060 From: Controller To: UserB ;tag=112233 Call-ID: 11223344@gateway.provider3.com CSeq: 1 ACK 5. Multi-Media Third party call control with SDP preconditions The section explains the multi-media third party call control with SDP preconditions based on reference [3] W. Marshall et al, "Integration of Resource Management and SIP", draft-manyfolks-sip- resource-01.txt, IETF; June 2000. Work in progress. Figure 2 presents a high-level overview of an advanced end-point to end-point (User A-User B) third party call flow. This example is appropriate for a multiple-media session with some combination of mandatory and optional quality-of-service precondition. For example, the User A may suggest five media streams, and be willing to establish the session if any three of them are satisfied. The use of reliable provisional responses is assumed. The controller prepares for UserA an SDP message body for the INVITE describing the desired QoS and security preconditions for each media flow, and the desired direction "sendrecvö. This SDP is included in the INVITE message sent to UserA through the proxies, and includes an entry "a=qos:mandatory sendrecv.or an entry "a=qos:optional sendrecv.ö as appropriate " The UserA on receipt of the INVITE , being willing to perform the requested precondition, returns a 183- Session-Progress provisional response containing SDP, along with the qos/security attribute for each stream having a precondition and the desired direction.. The User A also requests confirmation of the Haerens 14 Third Party Call Control for Resource Management February 2001 preconditions with the relevant direction-tag. This 183-Session- Progress provisional response is sent using the reliability mechanism of [2]. The controller sends the appropriate PRACK and the UserA UAS responds with a 200-OK to the PRACK. Similarly the controller also prepares for UserB an SDP message body for the INVITE describing the desired QoS and security preconditions for each media flow as received from UserA into the 183- Session_Progress provisional response, and the desired direction "sendrecvö. This SDP is included in the INVITE message sent to UserB through the proxies, and includes an entry "a=qos:mandatory sendrecv." or an entry "a=qos:optional sendrecv.ö as appropriate together with the relevant confirmation of the preconditions and direction tags. The UserB on receipt of the INVITE , prepares an SDP message body for the INVITE describing the desired QoS and security preconditions for each media flow, and the desired directions being willing to perform the requested precondition, returns a 183-Session-Progress provisional response containing SDP. Since the "sendrecv" direction tag required a cooperative effort of the UserA and UserB, the UserB requests a confirmation when the preconditions are met, with the SDP entry "a=qos:mandatory sendrecv or an entry "a=qos:optional sendrecv.ö as appropriate together with the required confirmation of the preconditions and direction tags. This 183-Session-Progress provisional response is sent using the reliability mechanism of [2]. The controller sends the appropriate PRACK and the UserB UAS responds with a 200-OK to the PRACK. The UserB now attempts to reserve the qos resources and establish the security associations. The controller now waits until the receipt of the 200-OK to the PRACK from User B is obtained before sending the SDP B to User A. When the 200-OK is received in the controller the SDP B is sent to the User A in a NOTIFY mechanism defined in Event Notification in SIP [7] followed by a 200 OK message returned form Party A to the Controller. When the User B has completed the resource reservations and security session establishment, it sends a confirmation to the User A relayed by the Controller in the form of a COMET message, with each precondition marked in the SDP as either success or failure. Note that if User B was not satisfied with the combination of successful preconditions, it could instead have responded with 580- Precondition-Failure, and ended the INVITE transaction. If the User A has satisfied its preconditions, and is satisfied with the preconditions achieved by the User B, it responds with the COMET message. The COMET message is relayed via the Controller and contains the SDP with the success/failure results of each precondition attempted by User A. If User A is not satisfied with Haerens 15 Third Party Call Control for Resource Management February 2001 the combination of successful preconditions, it could instead have sent a CANCEL message.. Otherwise, the session proceeds as in the previous example. On receipt of the COMET message which is relayed via the controller, the User B examines the combination of satisfied preconditions reported by User A, and makes a final decision whether to proceed with the session. If sufficient preconditions are not satisfied, the User B responds with 580-Precondition-Failure. Otherwise, the session proceeds as in the previous example. User A User B | Controller | | | | | (1) INVITE SDP held | | |<----------------------| | | (2) 183 w/SDP A | | |---------------------->| | | | (5) INVITE w/SDP A | | (3) PRACK |---------------------->| |<----------------------| (6) 183 w/SDP B | | (4) 200 OK (of PRACK) |<----------------------| |---------------------->| (7) PRACK | | |---------------------->| | | (8)200 OK (of PRACK) | | (9) NOTIFY |<----------------------| |<----------------------| | |(10) 200 OK (of NOTIFY)| | |---------------------->| | | | | | Reservation Reservation | ===========> <=========== | | | | (20) COMET | | (21) COMET |<----------------------| |<----------------------| | | (22) 200 OK (of COMET)| | |---------------------->| (23) 200 OK (of COMET)| | |---------------------->| | | | (24) COMET | | |---------------------->| (25) COMET | | |---------------------->| | | (26) 200 OK (of COMET)| |(27) 200 OK (of COMET) |<----------------------| |<----------------------| | | | | | Controller User Alerted | | | | (29) 180 Ringing | (28) 180 Ringing | |---------------------->|<----------------------| Haerens 16 Third Party Call Control for Resource Management February 2001 | (30) PRACK | (31) PRACK | |<----------------------|---------------------->| | (33) 200 OK (of PRACK)| (32) 200 OK (of PRACK)| |---------------------->|<----------------------| | | | | | User Picks-Up | Controller the phone | | | | (35) 200 OK | (34) 200 OK | |---------------------->|<----------------------| | | | | (36) ACK | (37) ACK | |<----------------------|---------------------->| | | Figure 2: 3PCC Flow with negotiation of optional preconditions 6. Enhancements required to the COMET Method 6.1 Justification for extensions to the COMET Method In the Third Party call establishment the behavior of the Originator (UCA) and the Destination (UAS) for handling the requested confirmation of a precondition has to be extended as discussed at the San Diego 49th IETF meeting (see Ref. {5]). With regard to the examples given in sections 3, 4 and 5 the following should be noted: i)If in the Basic single-media third party call control example the mandatory precondition is to be confirmed from User A to the controller then this has to be requested via an INVITE method with the ôconfirmö attribute present. This is presently specified in reference [2].If subsequently this mandatory precondition is to be indicated (confirmed) from the Controller to the User B then this has to be requested by the controller via a ôconfirmö attribute present in a method forwarded from controller to User B.(from the calling party to the called party). The COMET from the calling party (controller) to the called party B can only be indicated (triggered)if e.g. a ôconfirmö attribute is included in the INVITE. This is presently not supported in reference [2]. ii)A similar reasoning can be done for the multi-media third party call control in order to request the sending of COMETÆs for the directions Controller to User A triggered by the controller. The conclusion is that the COMET method procedures specifying the behavior have to be extended for the sending of COMETs from the calling party to the called party triggered by the calling party at the Originating side and for the sending of COMETs from the called party to the calling party triggered by the called party at the Destination side. Haerens 17 Third Party Call Control for Resource Management February 2001 It was proposed at the San Diego meeting to define the qos-attribute 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 direction-tag of the confirmation-tag indicates which party sends the COMET message. i) If a direction-tag ôsendö is included in the confirmation-tag then the send party will confirm the COMET message. ii) If a direction-tag ôrecvö is included then the party who received the confirmation-tag will confirm the COMET message. iii) If a direction-tag ôsendrecvö is included then the send and receive party of the confirmation-tag will confirm the COMET message. The definition of the allowed values for the direction attribute in the response are as follows: 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 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 6.2 Revised SIP Usage Rules for the COMET method procedures This section is provided as a place holder and will contain the revised SIP Usage Rules of section 8 in reference {3} for the enhancements explained under section 6.1 based on the agreements of the 50th IETF Minneapolis Meeting. Both the procedures for Basic and Third Party call control will be described. 6.2.1. Overview The session originator (UAC) prepares an SDP message body for the INVITE describing the desired QoS and security preconditions for Haerens 18 Third Party Call Control for Resource Management February 2001 each media flow, and the desired directions. The token value "send" means the direction of media from originator (whichever entity created the SDP) to recipient (whichever entity received the SDP in a SIP message), and "recv" is from recipient to originator. In an INVITE, the UAC is the originator, and the UAS is the recipient. The roles are reversed in the response. Note: This description is given as an initial proposal for further refinement. For Third Party Call control the following figure 3 gives an example of how the confirm direction flags could be applied. User A User B | Controller | | | | | (1) INVITE SDP held a:qos.mandatory.sendrecv | |<----------------------| | | | | | Receive Send | | O<======================O | | Send Receive | | O======================>O | | | | | | (2) 183 w/SDP A conf:send | |---------------------->| | | |(5) INVITE w/SDP A conf:send | |---------------------->| | | Send Receive | | |======================>O | | Receive Send | | O<======================O | (3) PRACK | | |<----------------------|(6)183 w/SDP B conf:send | (4) 200 OK (of PRACK) |<----------------------| |---------------------->| (7) PRACK | | |---------------------->| | | (8)200 OK (of PRACK) | | |<----------------------| | | | |(9) NOTIFY w/SDP B conf:send | |<----------------------| | |(10) 200 OK (of NOTIFY)| | |---------------------->| | | | | | Reservation Reservation | ===========> <=========== | |(20) COMET success:Sendrecv | |<----------------------| |(21) COMET success:Sendrecv | |<----------------------| | Haerens 19 Third Party Call Control for Resource Management February 2001 | (22) 200 OK (of COMET)| | |---------------------->| (23) 200 OK (of COMET)| | |---------------------->| | | |(24) COMET success:Sendrecv | |---------------------->|(25) COMET success:Sendrecv | |---------------------->| | | (26) 200 OK (of COMET)| |(27) 200 OK (of COMET) |<----------------------| |<----------------------| | | | The recipient of the INVITE (UAS) returns a 18x provisional response containing a Content-Disposition of "precondition," and SDP with the qos/security attribute for each stream having a precondition. The UAS would typically include a confirmation with a direction value (either send or recv or sendrecv) requesting whether the sender should confirm both directions (sendrecv) or only one direction (either send or recv). The SDP is a subset of the preconditions indicated in the INVITE. Unlike normal SIP processing, the UAS MUST NOT alert the called user at this point. The UAS now attempts to reserve the qos resources and establish the security associations. The 18x provisional response is received by the UAC. If the 18x contained SDP with mandatory qos/security parameters, the UAC does not let the session proceed until the mandatory preconditions are met. The UAC attempts to reserve the needed resources and establish the security associations. If either party requests a confirmation, a COMET message is sent to that party. The COMET message contains the success/failure indication for each precondition. For a precondition with a direction value of "sendrecv," the COMET indicates whether the sender is able to confirm both directions or only one direction. Upon receipt of the COMET message, the UAC/UAS continues normal SIP call handling, by (for a UAS) alerting the user and sending e.g. a 180-Ringing or 200-OK response. The UAC SIP transaction completes normally. 7. Applicability of the Third Party call control procedures. 7.1 Use in the Open Service Access Architecture 7.2 QoS enabled and assured control establishment. Haerens 20 Third Party Call Control for Resource Management February 2001 8. Security Considerations If the contents of the SDP contained in the 183-Session-Progress are private then end-to-end encryption of the message body can be used to prevent unauthorized access to the content. The security considerations given in the SIP specification apply to the COMET method. No additional security considerations specific to the COMET method are necessary. 9. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] J. Rosenberg and H. Schulzrinne, "Reliability of provisional responses in SIP," Internet Draft, Internet Engineering Task Force, July 2000. Work in progress. [3] W. Marshall et al, "Integration of Resource Management and SIP", draft-manyfolks-sip-resource-01.txt, IETF; June 2000. Work in progress. [4] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, IETF; Mach 1999. [5] G. Camarillo, "Third party call control with SDP preconditions", draft-camarillo-3pcc-qos-00.txt, IETF; July 2000. Work in progress. [6] J. Rosenberg/J. Peterson/H. Schulzrinne/Camarillo, "Third Party Call Control in SIP", draft-rosenberg-sip-3pcc-01.txt, IETF; May 2001. Work in progress. [7] Roach, A., ôEvent Notification in SIPö draft-roach-sip- subscribe-notify-02, November 2000. 10. Acknowledgments The author would like to recognize the comments received from Tom Batsele and Johan Dries from Alcatel Bell. 11. Author's Addresses Frans Haerens Alcatel Bell Francis Welles Plein, 1 B-2080 Antwerp Belgium Phone: +32 3 240 9034 Email: frans.haerens@alcatel.be Haerens 21 Third Party Call Control for Resource Management February 2001 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Haerens 22