M. Bhatia Internet-Draft NexTone Communications draft-bhatia-sip-h323-interworking-3pcc-00.txt Oct 16, 2001 Expires: Apr 15, 2002 Third Party Call Control in SIP-H.323 Interworking 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. This Internet-Draft will expire on [Apr 15, 2002]. Abstract This document discusses third party call control in a SIP-H.323 Interworking environment. Third party call control refers to the ability of one entity to create a call in which communications is actually between other parties [1]. The SIP-H.323 Interworking function is discussed in [4]. Here we discuss how the Interworking entity can function as a controller for third party call control, as well as an party to it. 1. Introduction The basic scenarios of third party call control (3pcc) for SIP are discussed in [1,8]. H.323 can be used to implement such a scenario on the gatekeeper using the gatekeeper controlled call routing and pausing mechanisms described in [5]. The basic scenarios of SIP-H.323 Interworking (IWF) are described in [4]. It defines the logical entity known as the SIP-H.323 Interworking Function (IWF) that will allow the interworking between the SIP (Session Initiation Protocol) [3] and H.323 protocols [5,6,7]. IWF includes call sequence mapping, message parameter mapping, translation between H.245 and SDP, state machines, and handling of different call procedures. 2. Definitions controller: the entity which sets up a call relationship between two parties. This has the same meaning as in [1]. A, B: Peers of the controller in a call setup using third party call call control. A will be understood to be on leg 1 of the call, which is set up first and B to be on the leg 2 of the call which is bridged with leg 1 subsequently. 3. Background In general, the application logic of third party call control is completely implemented on the controller, and the parties involved (A,B) are completely unaware of it. For example the approach described in [1] suggests two call flows (referred as "flow 1" and "flow 3" in this document), where the controller sets up calls to two parties A and B, and then bridges the calls together. The basic technique used to do this is the INVITE method without SDP. Another approach described in [8] uses the REFER method [2]. The similarity between the two approaches is that they allow the controller to facilitate information (e.g SDP) exchange between the two parties without getting involved in the details of what gets exchanged. In this document we focus on the case where the third party call control logic is based on the IWF. We extend from the call flows ("flow 1" and "flow 3") in [1]. The IWF mode allows either of A or B to be a SIP or an H.323 endpoint. This leads to two scenarios in general: A (SIP) <---> IWF <---> B (H.323) A (H.323) <---> IWF <---> B (SIP) In addition "flow 1" may be applied at either the beginning of a call or in the middle of existing calls, where the IWF may have an ongoing call with either A or B, which it is bridging with the other party. In general this ongoing call may be on hold or connected to a music server. For describing our flows, we mostly use those described in [4]. All additional flows we use are described in the auxiliary flows in section 6. In addition the flows described in section 6 are also useful when the IWF acts as a party (A or B) in third party call control. 4. Structure of document Call flows in this document are essentially divided into two categories: (1) Call flows where IWF acs as the controller. Here we extend from "flow 1" and "flow 3" specified in [1]. (Section 5) (2) Auxiliary call flows. Although the call flows described in the first category may appear independent, they depend on the call flows in this category when either of A or B is also an instance of IWF. In these situations the controller may be an IWF gateway or a SIP Proxy or even an H.323 gatekeeper. (Section 6) In general while presenting call flows here, we have taken a lot of liberty in excluding messages which may complicate the depiction of the call flow. The reader is assumed to be familiar with basic IWF functions and mapping described in [4]. For example, H.323 messages like H.225 Alerting, Call Proceeding, H.245 Master Slave Determination etc are not depicted in any call flows even though they may be utmost necessary for them to happen. 5. IWF is the 3pcc controller 5.1 "flow 1" from 3pcc draft[1]: 5.1.1 Case 1.A: Beginning of call to B, assuming B will immediately accept the call. The first leg in the flow (A) is assumed to be a SIP UA. The INVITE to A may be at the start of a call to A or in the middle of an already ongoing call to A. If A happens to be an instance of IWF, we may either Flow 3 or Flow 5 happening when looking at the flow from A's viewpoint. A (SIP) IWF B (H.323) | | | | | | | INV no SDP | | |<-------------------| | | | | | 200 OK SDP | | |------------------->| | | | | | | Setup | | |----------------->| | | | | | Connect | | |<-----------------| | | | | | TCS | | |<---------------->| | | | | | OLCs | | |<---------------->| | | | | ACK SDP | | |<-------------------| | | | | Figure 1: Flow 1.A (3pcc) 5.1.2 Case 1.B: Middle of call to B, assuming the call is connected completely and H.245 is already done on the H.323 leg (leg 2). The first leg in the flow (A) is assumed to be a SIP endpoint. The INVITE to A may be at the start of a call to A or in the middle of an already ongoing call to A. If A happens to be an instance of IWF, we may either Flow 3 or Flow 5 happening when looking at the flow from A's viewpoint. A (SIP) IWF B (H.323) | | | | | | | INV no SDP | | |<-------------------| | | | | | 200 OK SDP | | |------------------->| | | | | | | TCS | | |<---------------->| | | | | | OLCs | | |<---------------->| | | | | ACK SDP | | |<-------------------| | | | | Figure 2: Flow 1.B (3pcc) 5.1.3 Case 1.C: Beginning or middle of call to B, assuming B will immediately accept the call. The first leg in the flow (A) is assumed to be an H.323 endpoint. A (H.323) IWF B (SIP) | | | | | | | Setup | | |<-------------------| | | | | | Connect | | |------------------->| | | | | from this point we use Flow 1.B: | | | | | INV no SDP | | |----------------->| | | | | | 200 OK SDP | | |<-----------------| | | | | TCS | | |<------------------>| | | | | | OLCs | | |<------------------>| | | | ACK SDP | | |----------------->| | | | | | | Figure 3: Flow 1.C (3pcc) 5.1.4 Case 1.D: Middle of call to A, assuming the call is connected completely and H.245 is already done on the H.323 leg. The first leg in the flow (A) is assumed to be an H.323 endpoint. A NULL TCS may have been sent to A as part of the call re-routing and pausing mechanisms described in [5] at the beginning of the call flow. The INVITE to B may be the start of a new call to B or in the middle of an ongoing call between IWF and B. A (H.323) IWF B (SIP) | | | | | | | TCS | | |<-------------------| | | | | | OLC | | |------------------->| | | | | | | INVITE SDP | | |----------------->| | | | | | 200 OK SDP | | |<-----------------| | | | | OLC ACK | | |<-------------------| | | | ACK | | |----------------->| | | | | OLC | | |<-------------------| | | | | | OLC ACK | | |------------------->| | | | | Figure 4: Flow 1.D (3pcc) 5.2 "flow 3" from 3pcc draft[1]: Flow 3 from the 3pcc draft[1] is used in the general scenario where no assumption can be made about the nature of A or B or of the state of the call (beginning or middle of call). In each case, leg 1 (leg 2) may be either SIP (H.323) or H.323 (SIP). 5.2.1 Case 2.A: The first leg in the flow (A) is assumed to be a SIP UA. The INVITE to A may be the start of a new call or in the middle of an ongoing call between A and IWF. The Setup and Connect depicted in the flow are necessary only when the IWF is initiating a new call to B. A (SIP) IWF B (H.323) | | | | | | | INV no SDP | | |<-------------------| | | | | | 200 OK SDP | | |------------------->| | | | | | ACK Held/Music SDP | | |<-------------------| | | | Setup | | |----------------->| | | | | | Connect | | |<-----------------| | | | From here we use flow 1.D: | | TCS | | |<---------------->| | | | | | OLC | | |<-----------------| | | | | INV SDP | | |<-------------------| | | | | | 200 OK SDP | | |------------------->| | | | | | | OLC Ack | | |----------------->| | | | | ACK | | |<-------------------| | | | | | | OLC | | |----------------->| | | | | | OLC Ack | | |<-----------------| | | | Figure 5: Flow 2.A (3pcc) (uses Flow 1.D) 5.2.2 Case 2.B: The first leg in the flow (A) is assumed to be an H.323 endpoint. A (H.323) IWF B (SIP) | | | | | | | Setup | | |<-------------------| | | | | | Connect | | |------------------->| | | | | | TCS | | |------------------->| | | | | | TCS NULL | | |<-------------------| | | | | From this point we use Flow 1.B: | | | | | INV no SDP | | |----------------->| | | | | | 200 OK SDP | | |<-----------------| | | | | TCS | | |<-------------------| | | | | | OLCs | | |<------------------>| | | | ACK SDP | | |----------------->| | | | Figure 6: Flow 2.B (3pcc) (uses Flow 1.B) 6. Auxiliary Call Flows: Although the call flows described in the first category may appear independent, they depend on the call flows in this category when either of A or B is also an instance of IWF. 6.1 SIP/H.323 Call flows with INVITE no SDP in middle of call A (SIP) IWF B (H.323) | | | | | | | INV no SDP | | |------------------->| | | | | | 200 OK SDP | | |<-------------------| | | | | | ACK SDP | | |------------------->| | | | | From here, we use Flow 1.D: | | | | | TCS | | |----------------->| | | | | | Close OLCs | | |<---------------->| | | | | | OLC | | |<-----------------| | | | | INVITE SDP | | |<-------------------| | | | | | 200 OK SDP | | |------------------->| | | | | | | OLC Ack | | |----------------->| | | | | ACK | | |<-------------------| | | | | | | OLC | | |----------------->| | | | | | OLC Ack | | |<-----------------| | | | Figure 7: Flow 3, INVITE no SDP in middle of call (uses Flow 1.D) 6.2 SIP/H.323 Call flows with REFER in beginning of call (REFER with no call context): A (SIP) IWF B (H.323) | | | | | | | REFER | | |------------------->| | | | | from this point Flow 2.A: | | | | | | | INV no SDP | | |<-------------------| | | | | | 200 OK SDP | | |------------------->| | | | | | ACK Held/Music SDP | | |<-------------------| | | | Setup | | |----------------->| | | | | | Connect | | |<-----------------| | | | | | TCS | | |<---------------->| | | | | | OLC | | |<-----------------| | | | | INV SDP | | |<-------------------| | | | | | 200 OK SDP | | |------------------->| | | | | | | OLC Ack | | |----------------->| | | | | | OLC | | |----------------->| | | | | | OLC Ack | | |<-----------------| | | | | ACK SDP | | |<-------------------| | | | | Figure 8: Flow 4, REFER from SIP, beginning of call (uses Flow 2.A) 6.3 SIP/H.323 Call flows using INVITE no SDP in beginning of call A (SIP) IWF B (H.323) | | | | | | | INV no SDP | | |------------------->| | | | | | | Setup | | |----------------->| | | | | | Connect | | |<-----------------| | | | | | TCS | | |<-----------------| | | | | | TCS Gen | | |----------------->| | | | | | OLC | | |<-----------------| | | | | 200 OK SDP | | |<-------------------| | | | | | ACK SDP | | |------------------->| | | | TCS | | |----------------->| | | | | | OLC Acks/OLJs | | |----------------->| | | | Figure 9: Flow 5, INVITE no SDP from SIP, beginning of call 6.4 SIP/H.323 Call flows with REFER in middle of call (REFER inside an existing call context) A (SIP) IWF B (H.323) | | | | | | | REFER | | |------------------->| | | | | | | TCS Gen | | |----------------->| | | | | | OLC | | |<-----------------| | | | | INVITE SDP | | |<-------------------| | | | | | 200 OK SDP | | |------------------->| | | | | | ACK | | |<-------------------| | | | TCS | | |----------------->| | | | | | OLC Acks/OLJs | | |----------------->| | | | Figure 10: Flow 6, REFER from SIP, middle of call (uses Flow 5) 6.5 SIP/H.323 Call flows with INVITE SDP in middle of call A (SIP) IWF B (H.323) | | | | | | | INV SDP | | |------------------->| | | | | | | TCS | | |----------------->| | | | | | OLCs | | |<---------------->| | | | | 200 OK SDP | | |<-------------------| | | | | | ACK | | |------------------->| | | | | | | | Figure 11: Flow 7, INVITE SDP in middle of call 6.6 SIP/H.323 Call flows with TCS in middle of call A (H.323) IWF B (SIP) | | | | | | | TCS | | |------------------->| | | | | | | REFER | | |----------------->| | | | | | INV SDP+Replaces | | |<-----------------| | | | | OLCs | | |<------------------>| | | | | | | 200 OK SDP | | |----------------->| | | | | | ACK | | |<-----------------| | | | Figure 12: Flow 8, TCS in middle of call (uses Flow 7) 6.7 SIP/H.323 Call flows using Setup no/failed fast start A (H.323) IWF B (SIP) | | | | | | | Setup | | |------------------->| | | | | | | INV no SDP | | |----------------->| | | | | | 200 OK SDP | | |<-----------------| | | | | Connect | | |<-------------------| | | | | | TCS | | |<------------------>| | | | | | OLCs | | |<------------------>| | | | ACK SDP | | |----------------->| | | | | | | Figure 13: Flow 9, Setup no fast start 7. References [1] Rosenberg/Peterson/Schulzrinne/Camarillo, "Third Party Call Control in SIP" Internet Draft, Internet Engineering Task Force, Mar 2002. Work in progress. [2] Sparks, R. "The Refer Method", Internet Draft, Internet Engineering Task Force, Sep 2001. Work in progress. [3] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [4] Agrawal, H., "SIP-H.323 Interworking", Internet Draft, Internet Engineering Task Force, Sep 2001. Work in progress. [5] "Packet based multimedia communication systems", Recommendation H.323 Version 2,ITU-T,Geneva,Switzerland,Feb. 1998. [6] "Call Signaling Protocols and Media Stream Packetization for Packet Based Multimedia Communications Systems", Recommendation H.225.0 Version 2, ITU-T, Geneva, Switzerland, March 1997. [7] "Control protocol for multimedia communication", Recommendation H.245.0 Version 3, ITU-T, Geneva, Switzerland, Feb. 1998. [8] Bhatia, M., "3pcc using the REFER method", Internet Draft, Internet Engineering Task Force, Sep 2001. Work in progress. Author's Address Medhavi Bhatia NexTone Communications 9700 Great Seneca Highway Rockville, MD 20874 EMail: mbhatia@nextone.com Expires: Apr 15, 2002 Third Party Call Control in SIP-H.323 Interworking