Internet Engineering Task Force Gonzalo Camarillo Internet draft Ericsson July 2000 Expires January 2000 Third party call control with 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 how to perform third party call control in SIP when SDP preconditions are used. There are no new SIP extensions needed to accomplish this. The mechanism outlined is illustrated with an example in order to help understand it. 1. Introduction In third party call control the entity creating, modifying and terminating the session might not be involved in the media exchange. The controller uses SIP [1] to create sessions between other participants. Third party call control in SIP is addressed by [2] already. However, sessions that make use of SDP preconditions [3] are not taken into account. The next section describes the issues found when these two mechanisms are used together. 2. Third party call control and SDP preconditions In unicast sessions there is a number of media streams flowing between two entities. In order to perform resource reservation it is necessary to know the session descriptions from both parties. When Camarillo 1 Third party call control with SDP preconditions third party call control is performed the information needed to establish the QoS required is not available from the beginning. The following call flow shows how the exchange of SDPs between both parties can be performed. 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 2 Third party call control with SDP preconditions The controller INVITEs A in (1). At this point of time there is no information available about codecs to be used port numbers or IP addresses. The SDP of this INVITE just contains SDP preconditions and the media stream types (audio, video, etc...). INVITE (3) contains the SDP received from A. This INVITE is sent to B. When B responses with (4) 183 it is ready to perform resource reservation. However, B will not start resource reservation until the PRACK (7) is received. This allows BĘs SDP to be sent to A in (5). This way both parties have all the information needed to perform resource reservation. The PRACK matching (2) is sent at (5). This PRACK is not sent before because it is used to send BĘs SDP to A. The controller does not get this information until (4). When the preconditions from B to the controller and from A to the controller are met two COMETs are received (9) and (11). At this point of time is up to the controller to let the session establishment go on sending a COMET to A (13). When A accepts joining the session (15), a COMET (16) is sent to B so B is alerted. 3. Example This example shows how a transcoding device can be implemented using the mechanism described previously. Transcoding devices are sometimes needed between two clients that do not have any common codec. This is a common situation when clients using a low rate access are involved in the communication. A commonly used codec such as PCM is not supported by the client because there are not 64 kbps available, and the low rate codec used for this concrete access is too expensive (IPR issues) to be supported by a normal client. Hopefully, a low rate codec that could be implemented "for free" will be available for all the clients in a future, making transcoding devices unnecessary. The mechanism used in this example allows the addition of a transcoding device in the media path by the caller. This addition is transparent to the callee. The transcoding device is modelled as a dial-up bridge in [4]. A client INVITEs the transcoding device, newsession@transcoder.provider3.com, and the transcoding device responses with a URL (in a contact header) that identifies the transcoding session: session3371@transcoder.provider3.com In this example, there are two media streams: audio and video. The audio media stream goes through the transcoding device while the video stream goes directly between A and B. This video stream illustrates how some media streams can traverse a certain path and others can traverse a different one. Camarillo 3 Third party call control with SDP preconditions A wants to establish a session containing audio and video with B. A and B do not have common audio codecs. This has been discovered before with, for instance, an unsuccessful INVITE. A invokes transcoding services from T. In the call flows SDP TA represent TĘs SDP between T and A. SDP TB represents TĘs SDP between T and B. The transcoder lists all the codecs that it supports in (10) because it responses to an INVITE without codec information. In (2) the transcoder just lists codec 0 because it is a subset of what A sent in the INVITE (1). After the establishment of a session between A and T (8), the call flow is the same as in the previous section. Therefore, INVITE (1) in the previous section corresponds to INVITE (9) in this section. A T B | (1) INVITE SDP A | | |------------------>| | | (2) 183 SDP TA | | |<------------------| | | (3) PRACK | | |------------------>| | |(4) 200 OK (PRACK) | | |<------------------| | | (5) COMET | | |------------------>| | | (6) 200 OK (COMET)| | |<------------------| | |(7) 200 OK (INVITE)| | |<------------------| | | (8) ACK | | |<------------------| | | (9) INVITE | | |------------------>| | | (10) 183 SDP TB | | |<------------------| | |(11) INVITE SDP TB | | |------------------------------------->| | (12) 183 SDP B | | |<-------------------------------------| |(13) PRACK SDP B | | |------------------>| | |(14) 200 OK (PRACK)| | |<------------------| | | (15) PRACK | | |------------------------------------->| |(16) 200 OK (PRACK)| | |<-------------------------------------| | (17) COMET | | |<-------------------------------------| |(18) 200 OK (COMET)| | |------------------------------------->| Camarillo 4 Third party call control with SDP preconditions | (19) COMET | | |<------------------| | |(20) 200 OK (COMET)| | |------------------>| | | (21) COMET | | |------------------>| | |(22) 200 OK (COMET)| | |<------------------| | |(23) 200 OK (INVITE) | |<------------------| | | (24) COMET | | |------------------------------------->| |(25) 200 OK (COMET)| | |<-------------------------------------| |(26) 200 OK (INVITE) | |<-------------------------------------| | (27) ACK | | |------------------>| | | (28) ACK | | |------------------------------------->| | | | A T B Message details (1) INVITE sip:newsession@transcoder.provider3.com SIP/2.0 Via: SIP/2.0/UDP ws1234.provider1.com:5060 Require: 100rel From: UserA To: Transcoder Call-ID: 12345678@ws1234.provider1.com CSeq: 1 INVITE Contact: UserA Content-Type: application/sdp Content-Length: 154 v=0 o=UserA 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 (2) SIP/2.0 183 Session Progress Via: SIP/2.0/UDP ws1234.provider1.com:5060 Require: 100rel RSeq: 112233 From: UserA Camarillo 5 Third party call control with SDP preconditions To: Transcoder ;tag=314159 Call-ID: 12345678@ws1234.provider1.com CSeq: 1 INVITE Contact: Transcoder Content-Type: application/sdp Content-Length: 167 v=0 o=Transc 2891234526 2891234526 IN IP4 transcoder.provider3.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 (3) PRACK sip:session3371@transcoder.provider3.com SIP/2.0 RAck: 112233 1 INVITE Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA To: Transcoder ;tag=314159 Call-ID: 12345678@ws1234.provider1.com CSeq: 2 PRACK (4) SIP/2.0 200 OK Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA To: Transcoder ;tag=314159 Call-ID: 12345678@ws1234.provider1.com CSeq: 2 PRACK (5) COMET sip:session3371@transcoder.provider3.com SIP/2.0 Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA To: Transcoder ;tag=314159 Call-ID: 12345678@ws1234.provider1.com CSeq: 3 COMET Content-Type: application/sdp Content-Length: 152 v=0 o=UserA 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 Camarillo 6 Third party call control with SDP preconditions a=qos:success sendrecv (6) SIP/2.0 200 OK Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA To: Transcoder ;tag=314159 Call-ID: 12345678@ws1234.provider1.com CSeq: 3 COMET (7) SIP/2.0 200 OK Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA To: Transcoder ;tag=314159 Call-ID: 12345678@ws1234.provider1.com CSeq: 1 INVITE Contact: Transcoder Content-Type: application/sdp Content-Length: 133 v=0 o=Transc 2891234526 2891234526 IN IP4 transcoder.provider3.com s=Session SDP c=IN IP4 10.0.0.3 t=0 0 m=audio 30000 RTP/AVP 0 (8) ACK sip:session3371@transcoder.provider3.com SIP/2.0 Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA To: Transcoder Call-ID: 12345678@ws1234.provider1.com CSeq: 1 ACK Contact: UserA (9) INVITE sip:session3371@transcoder.provider3.com SIP/2.0 Via: SIP/2.0/UDP ws1234.provider1.com:5060 Require: 100rel From: UserA To: Transcoder Call-ID: 87654321@ws1234.provider1.com CSeq: 1 INVITE Contact: UserA Content-Type: application/sdp Content-Length: 156 v=0 o=UserA 2891234526 2891234526 IN IP4 ws1234.provider1.com Camarillo 7 Third party call control with SDP preconditions s=Session SDP c=IN IP4 0.0.0.0 t=0 0 m=audio 0 RTP/AVP a=qos:mandatory sendrecv confirm (10) SIP/2.0 183 Session Progress Via: SIP/2.0/UDP ws1234.provider1.com:5060 Require: 100rel RSeq: 223344 From: UserA To: Transcoder ;tag=123456 Call-ID: 87654321@ws1234.provider1.com CSeq: 1 INVITE Contact: Transcoder Content-Type: application/sdp Content-Length: 169 v=0 o=Transc 2891234526 2891234526 IN IP4 transcoder.provider3.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 confirm (11) INVITE sip:UserB@ws4321.provider2.com SIP/2.0 Via: SIP/2.0/UDP ws1234.provider1.com:5060 Require: 100rel From: UserA To: UserB Call-ID: 11223344@ws1234.provider1.com CSeq: 1 INVITE Contact: UserA Content-Type: application/sdp Content-Length: 268 v=0 o=UserA 2891234526 2891234526 IN IP4 ws1234.provider1.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 confirm m=video 20000 RTP/AVP 31 c=IN IP4 10.0.0.1 a=rtpmap:31 H261/90000 a=qos:mandatory sendrecv confirm (12) Camarillo 8 Third party call control with SDP preconditions SIP/2.0 183 Session Progress Via: SIP/2.0/UDP ws1234.provider1.com:5060 Require: 100rel RSeq: 334455 From: UserA To: UserB ;tag=112233 Call-ID: 11223344@ws1234.provider1.com CSeq: 1 INVITE Contact: UserB Content-Type: application/sdp Content-Length: 246 v=0 o=UserB 2891234526 2891234526 IN IP4 ws4321.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 m=video 40000 RTP/AVP 31 a=rtpmap:31 H261/90000 a=qos:mandatory sendrecv confirm (13) PRACK sip:session3371@transcoder.provider3.com SIP/2.0 RAck: 223344 1 INVITE Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA To: Transcoder ;tag=123456 Call-ID: 87654321@ws1234.provider1.com CSeq: 2 PRACK Content-Type: application/sdp Content-Length: 162 v=0 o=UserA 2891234526 2891234526 IN IP4 ws1234.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 (14) SIP/2.0 200 OK Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA To: Transcoder ;tag=123456 Call-ID: 87654321@ws1234.provider1.com CSeq: 2 PRACK (15) Camarillo 9 Third party call control with SDP preconditions PRACK sip:UserB@ws4321.provider2.com SIP/2.0 RAck: 334455 1 INVITE Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA To: UserB ;tag=112233 Call-ID: 11223344@ws1234.provider1.com CSeq: 2 PRACK (16) SIP/2.0 200 OK Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA To: UserB ;tag=112233 Call-ID: 11223344@ws1234.provider1.com CSeq: 2 PRACK (17) COMET sip:UserA@ws1234.provider1.com SIP/2.0 Via: SIP/2.0/UDP ws4321.provider2.com:5060 To: UserA From: UserB ;tag=112233 Call-ID: 11223344@ws1234.provider1.com CSeq: 1 COMET Content-Type: application/sdp Content-Length: 226 v=0 o=UserB 2891234526 2891234526 IN IP4 ws4321.provider2.com s=Session SDP c=IN IP4 10.0.0.2 t=0 0 m=audio 40002 RTP/AVP 8 a=qos:success sendrecv m=video 40000 RTP/AVP 31 a=rtpmap:31 H261/90000 a=qos:success sendrecv (18) SIP/2.0 200 OK Via: SIP/2.0/UDP ws4321.provider2.com:5060 To: UserA From: UserB ;tag=112233 Call-ID: 11223344@ws1234.provider1.com CSeq: 1 COMET (19) COMET sip:UserA@ws1234.provider1.com SIP/2.0 Via: SIP/2.0/UDP transcoder.provider3.com:5060 To: UserA From: Transcoder ;tag=123456 Call-ID: 87654321@ws1234.provider1.com Camarillo 10 Third party call control with SDP preconditions CSeq: 1 COMET Content-Type: application/sdp Content-Length: 159 v=0 o=Transc 2891234526 2891234526 IN IP4 transcoder.provider3.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 (20) SIP/2.0 200 OK Via: SIP/2.0/UDP transcoder.provider3.com:5060 To: UserA From: Transcoder ;tag=123456 Call-ID: 87654321@ws1234.provider1.com CSeq: 1 COMET (21) COMET sip:session3371@transcoder.provider3.com SIP/2.0 Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA To: Transcoder ;tag=123456 Call-ID: 87654321@ws1234.provider1.com CSeq: 3 COMET Content-Type: application/sdp Content-Length: 152 v=0 o=UserA 2891234526 2891234526 IN IP4 ws1234.provider2.com s=Session SDP c=IN IP4 10.0.0.2 t=0 0 m=audio 40002 RTP/AVP 8 a=qos:success sendrecv (22) SIP/2.0 200 OK Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA To: Transcoder ;tag=123456 Call-ID: 87654321@ws1234.provider1.com CSeq: 3 COMET (23) SIP/2.0 200 OK Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA Camarillo 11 Third party call control with SDP preconditions To: Transcoder ;tag=123456 Call-ID: 87654321@ws1234.provider1.com CSeq: 1 INVITE Contact: Transcoder Content-Type: application/sdp Content-Length: 135 v=0 o=Transc 2891234526 2891234526 IN IP4 transcoder.provider3.com s=Session SDP c=IN IP4 10.0.0.3 t=0 0 m=audio 30002 RTP/AVP 0 8 (24) COMET sip:UserB@ws4321.provider2.com SIP/2.0 Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA ;tag=112233 To: UserB Call-ID: 11223344@ws1234.provider1.com CSeq: 3 COMET Content-Type: application/sdp Content-Length: 248 v=0 o=UserA 2891234526 2891234526 IN IP4 ws1234.provider1.com s=Session SDP t=0 0 m=audio 30002 RTP/AVP 0 8 c=IN IP4 10.0.0.3 a=qos:success sendrecv m=video 20000 RTP/AVP 31 c=IN IP4 10.0.0.1 a=rtpmap:31 H261/90000 a=qos:success sendrecv (25) SIP/2.0 200 OK Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA ;tag=112233 To: UserB Call-ID: 11223344@ws1234.provider1.com CSeq: 3 COMET (26) SIP/2.0 200 OK Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA To: UserB ;tag=112233 Call-ID: 11223344@ws1234.provider1.com CSeq: 1 INVITE Contact: UserB Camarillo 12 Third party call control with SDP preconditions Content-Type: application/sdp Content-Length: 178 v=0 o=UserB 2891234526 2891234526 IN IP4 ws4321.provider2.com s=Session SDP c=IN IP4 10.0.0.2 t=0 0 m=audio 40002 RTP/AVP 8 m=video 40000 RTP/AVP 31 a=rtpmap:31 H261/90000 (27) ACK sip:session3371@transcoder.provider3.com SIP/2.0 Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA To: Transcoder ;tag=123456 Call-ID: 87654321@ws1234.provider1.com CSeq: 1 ACK (28) ACK sip:UserB@ws4321.provider2.com SIP/2.0 Via: SIP/2.0/UDP ws1234.provider1.com:5060 From: UserA To: UserB ;tag=112233 Call-ID: 11223344@ws1234.provider1.com CSeq: 1 ACK 4. Open issues This document uses the following SDP format in an INVITE to indicate that preconditions are needed without providing a session description: v=0 o=UserA 2891234526 2891234526 IN IP4 ws1234.provider1.com s=Session SDP c=IN IP4 0.0.0.0 t=0 0 m=audio 0 RTP/AVP a=qos:mandatory sendrecv confirm IP address, port number and codec type are not provided. It is assumed that the if the caller includes SDP preconditions in the INVITE, the callee requests confirmation of preconditions met (COMET from caller to callee) in the 183 response. However, the callee might rely on other mechanisms such as RSVP ResvConf messages to confirm that there are available resources for the session. A means in the INVITE for forcing the callee to ask for COMET from the caller is needed. Camarillo 13 Third party call control with SDP preconditions The usage of the direction-tag in COMET indicating success is not clear in [3]. This document uses always "a=qos:success sendrecv". 5. Acknowledgements The author would like to thank Jan Holler for his input on this document. 6. References [1] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, IETF; Mach 1999. [2] J. Rosenberg/J. Peterson/H. Schulzrinne, "Third Party Call Control in SIP", draft-rosenberg-sip-3pcc-00.txt, IETF; March 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] H. Schulzrinne/J. Rosenberg, "SIP Call Control Services", draft- ietf-mmusic-sip-cc-01.txt, IETF; June 1999. Expired draft. 7. Author's Address 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 14