Internet Engineering Task Force Radhika R. Roy Internet Draft AT&T draft-roy-sip-h323-interworking-3pcc-00.txt February 22, 2002 Expires: October 21, 2002 Transparent Third Party Call Control Model for 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 [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. Abstract This contribution describes a generalized interworking mechanism between SIP and H.323 for third party call control where the controller function can reside anywhere within the IP Telephony network. The proposed generalized interworking mechanism offers transparent IP Telephony services between the SIP and H.323 endpoints considering the third party call control function resides in a separate application server. The implementation of the third party call control function on a SIP proxy, SIP endpoint, H.323 GK, H.323 endpoint, MCU, or IWF is a special case of the generalized mechanism proposed in this document. Radhika R. Roy [Page 1] Internet Draft 3pcc Interworking February 22, 2002 Table of Contents 1. Introduction 4 2. Conventions used in this document 4 3. Call Control Applications 4 3.1 First Party Call Control Application 4 3.2 Third Party Call Control Application 5 4. SIP-H.323 Interworking and Third Party Call Control 5 4.1 SIP-H.323 Interworking Architecture 5 4.2 Third Party Call Control Applications 6 5. Third party Call Control in the Context of SIP-H.323 Interworking 6 5.1 SIP Third Party Call Control 7 5.1.1 Implementation of SIP Third Party Call Controller 9 5.1.2 SIP Third party Call Management 10 5.2 H.323 Third Party Call Control 10 5.2.1 Implementation of H.323 Third Party Call Controller 12 5.2.2 H.323 Third Party Call Management 13 5.3 SIP-H.323 Interworking Third Party Call Control 13 5.3.1 Two-Party Call: SIP and H.323 Endpoint 14 5.3.1.2 Third Party Call Control Application in the SIP-based IP Telephony Network 15 5.3.1.2.1 H.323 Endpoint other than human being Known to the Controller Answers the Call Immediately 15 5.3.1.2.1.1 Controller does Not Setup the Call to the H.323 side Priori via IWF 15 5.3.1.2.1.2 Controller Sets Up the Call to the H.323 side Priori via IWF 16 5.3.1.2.2 H.323 Endpoint not Known to the Controller or Entities Represent People 17 5.3.1.2.2.1 Controller Does Not Setup the Call to the H.323 side Priori via IWF 17 5.3.1.2.2.2 Controller Sets Up the Call to the H.323 side Priori via IWF 19 5.3.1.2.3 Fast Connect to the H.323 Endpoint: SIP Endpoint Known/Unknown to the Controller 20 5.3.1.2.3.1 H.323 Endpoint other than human being Known to the Controller Answers the Call Immediately 20 5.3.1.2.4 Tunneling to the H.323 Endpoint: SIP Endpoint Known/Unknown to the Controller 21 5.3.1.3 Third Party Call Control Application in the H.323-based IP Telephony Network 21 5.3.2 Multi-Party Call 22 6. Third Party Call Control Service Transparency for SIP-H.323 Interworking 22 6.1 Location of the Third Party Controller 22 6.1.1 Controller Located in SIP Side 22 6.1.2 Controller Located in the H.323 Side 23 Radhika R. Roy [Page 2] Internet Draft 3pcc Interworking February 22, 2002 6.2 Address Resolution 23 6.3 Accounting, Authentication, and Authorization 23 6.4 Bandwidth Management 24 6.5 Media Control 25 6.6 Discovery 25 6.7 Registration 26 6.8 Policy 26 7. Conclusion 26 8. References 28 Acknowledgments 28 Author's Addresses 28 Intellectual Property Statement 28 Full Copyright Statement 29 Radhika R. Roy [Page 3] Internet Draft 3pcc Interworking February 22, 2002 1. Introduction The work for the third party call control [2] using Session Initiation Protocol (SIP) [3] is in near completion. The third party call control mechanism in H.323 [4] can also be done. The work for SIP-H.323 Interworking standard [5] that is defining the Interowking Function (IWF) for providing transparent communications between the SIP and H.323 users is also progressing. Recently, a mechanism has been defined for interworking of the third party call control [6] between SIP and H.323 using IWF as the controller that can be termed as one of the implementation schemes. We are considering that the third party call control mechanism will be able to reside anywhere within the SIP-based or H.323-based IP Telephony network including the IWF. To provide a generalized solution, we have considered that the third party call control application will reside in a separate application server that provides the transparent services among the SIP and H.323 users. 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 [7]. 3. Call Control Applications The application which is responsible for the call control is known as the call control application. A call control application can be termed as the first party application or third party application depending on how the call is controlled. 3.1 First Party Call Control Application The application which is responsible for call control also becomes a party in the call that is being controlled is termed as the first party application. For example, a first party application will operate locally for the controlled terminal when it is one of the parties in the call. The call control application can use a SIP user agent (UA) or H.323 terminal/endpoint (EP) to initiate a call to another SIP UA or H.323 terminal/EP, and if the call control application and its users become a party for communication in this call that is being controlled, it is termed as the first party call control application. Radhika R. Roy [Page 4] Internet Draft 3pcc Interworking February 22, 2002 3.2 Third Party Call Control Application A third party call control application performs actions on calls, but the controlling application itself is not a party of the controlled call. The third party application is also termed as the controller and allows to set up calls among two or more than two parties. If needed, it can also manage the communication relationship among the communicating parties. It has the ability to perform all of the call control functions that a first party call control application does. The third party application can run on a separate application server, on a SIP proxy, on an H.323 GK, on an MCU, on a SIP terminal, on an H.323 terminal, on an IWF, or on other terminals. Typical third party call control applications are media server, conferencing server, call center, click-to-dial, mid-call announcement, and group control applications. 4. SIP-H.323 Interworking and Third Party Call Control 4.1 SIP-H.323 Interworking Architecture An IWF [5] is used for interconnection between the SIP- and H.323- based IP Telephony network to provide seamless communications among all users. The SIP-side of the IWF works, as if, as a SIP signaling entity while the H.323-side of the IWF works as an H.323 signaling entity. Basically, IWF provides the conversion between the SIP [3] and H.323 [4] signaling protocol. However, media is sent directly between the SIP and H.323 entities directly. Figure 1 shows a high-level configuration for SIP-H.323 Interworking. There can be more that one IWF interconnecting the SIP- and H.323-based IP Telephony network. Similarly, there can be a single or multiple GKs or MCUs in the H.323 system. In the same token, a single or multiple SIP proxies or MCUs can reside in the SIP system. --------- ------- ------ ------- | Proxy | | MCU | | GK | | MCU | ---+----- ---+--- ---+-- ---+--- | | | | SIP | | | | H.323 Endpoints | | | | Endpoints +---+-----------+--+ +---+--------+---+ | SIP-based IP | | H.323-based IP | S1 O-----+ Telephony | +---+ | Telephony +----O H1 S2 O-----+ Network + | I | + Network +----O H2 Radhika R. Roy [Page 5] Internet Draft 3pcc Interworking February 22, 2002 . | |-| W |-| | . Si O-----+ | | F | | +----O Hj | | +---+ | | +------------------+ +----------------+ Figure 1: SIP-H.323 Interworking Architecture It may so happen that both SIP and H.323 IP Telephony services can be owned by a single service provider. In other situations, SIP services are provided by one service provider while H.323 services are provided by another service provider. In the case of multiple service providers, there may have to be some kind of service level agreement (SLA) how the third party calls will be handled and managed. 4.2 Third Party Call Control Applications The third party call control applications are usually installed in the application server. However, they can also be installed in proxies, GKs, and MCUs including IWFs when these entities are equipped with the third party call control application features. There may be some complications when the third party call applications need to initiate calls among multiple parties where some parties may involve both SIP and H.323 users while others may only be either for SIP users or for H.323 users. In those situations, more complicated call scenarios need to be worked out for SIP-H.323 interworking. We will analyze each situation case by case basis. Some of the scenarios may not be addressed now because the SIP standard is yet to work out for all scenarios. However, we are assuming that the third party call control application will maintain the call states for the duration of the call in order to manage the call. 5. Third party Call Control in the Context of SIP-H.323 Interworking We are assuming that the third party call control application that controls and manages calls reside anywhere in the network. However, we are considering a separating application server where the third party call control application resides. It will provide a generalized solution for the SIP-H.323 interworking. In a more complicated scenario, it may so happen that some of the users may have sub-conferencing among the parties of SIP or H.323 users only in addition to the primary conferencing that consists of both SIP and H.323 users. These kinds of scenarios require further work in SIP standard and will not be addressed here. Radhika R. Roy [Page 6] Internet Draft 3pcc Interworking February 22, 2002 We will consider SIP RFC 2543 [3] and H.323 Version [2] for interworking first for the third party interworking. We will then consider the revised SIP RFC 2543-bis07 (or its updated version), if there are any differences that we may need to make. Similarly, the subsequent versions of H.323 will also be considered accordingly as appropriate. However, the third party call control application server capability may be implemented to a SIP proxy, an H.323 GK, an MCU, or an IWF to act as the controller. These solutions will be a matter of implementation of the generalized interworking mechanisms described here. 5.1 SIP Third Party Call Control The SIP third party call control (3pcc) draft [2] provides the baseline how the 3pcc is required to be implemented. If this draft is finalized and accepted, the 3pcc will be implemented using the two types of call flows: Case A. Second entity other than the human being is known to the controller and answers the call immediately and Case B. Endpoints are not known to the controller or the second endpoint can be a human being. Figure 1 (Flow 1 _ Figure 1 [2] and Flow 4 - Figure 4 [2]) shows the flow for Case A when the controller sends an INVITE to the first SIP user and knows that the second SIP entity which will communicate with the first entity will answer the call immediately (e.g., an automata like a media server, conferencing server). A Controller B | | | | INV no SDP | | |<------------------| | | | | | 200 SDP A | | |-----------------> | INV SDP A | | |----------------->| | | | | | 200 SDP B | | |<-----------------| | | | | | ACK | | ACK SDP B |----------------->| |<------------------| | | | | | | RTP | |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | Radhika R. Roy [Page 7] Internet Draft 3pcc Interworking February 22, 2002 |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | | | | | | | | | | | BYE From A | | |-----------------> | BYE From Cont. | | 200 OK |----------------> | |<----------------- | 200 OK | | |<---------------- | | | | | | | Figure 2: SIP Third Party Call Control Flows: Second Entity other than the Human being Known to Controller and Answers Immediately (Flows 1 - Figure 1 [2] and Flow 4 - Figure 4 [2]) The flow in Figure 2 does not require the SDP manipulation by the controller and works for any media types supported by both endpoints. It is assumed that the second endpoint (e.g., Entity B) will be like a media server, conference server or other entity (but not people) that will answer the call immediately. Otherwise, it will have timeout problems because it will cause A to retransmit the 200 OK response periodically. Figure 3 (Flow 3 _ Figure 3 [2] and Flow 4 - Figure 4 [2]) shows the flows when the controller does not know SIP entities or if calls are made to entities that represent people. A Controller B | | | | INV no SDP | | time t = 0 |<------------------| | | | | | 200 SDP A1 | | |-----------------> | | | | | | ACK SDP held | | |<------------------| | | | | | | INV no SDP | | |----------------->| | | | | | 200 SDP B | | |<-----------------| | INV SDP B' | | |<------------------| | | | | | 200 SDP A2 | | |-----------------> | | Radhika R. Roy [Page 8] Internet Draft 3pcc Interworking February 22, 2002 | | | | | ACK SDP A2' | | ACK |----------------->| |<------------------| | | | | | | RTP | |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | | | | | | | | BYE From A | | |-----------------> | BYE From Cont. | | 200 OK |----------------> | |<----------------- | 200 OK | | |<---------------- | | | | | | | Figure 3: SIP Third Party Call Control Flows: Entities are Unknown to the Controller or Second Entity is a Human Being (Flow 3 _ Figure 3 [2] and Flow 4 - Figure 4 [2]) The above flow (Figure 3) solves the timeout problems (it still may happen if re-INVITE is not responded to quickly), does not require the controller to guess the media that will be used by the participants, or does not assume that a device responds properly to an INVITE with SDP on hold. However, the drawbacks of this flow (Figure 3) are: A. Needs to perform SDP manipulations (e.g., takes some SDP and generates another SDP which has the same media composition, but is on hold) by the controller and B. Needs to reorder an SDP X so that its media line match up with those in some other SDP Y. Flows shown in Figures 2 and 3 will indicate that the From field is of the controller and each communicating endpoint will assume that it is in a point-to-point call with the controller. So, the controller will have the complete control of the call. If the controller receives a BYE from an endpoint, it can also create a new BYE and hang up with the other participant. It is interesting to note that the controller can also add, remove, transfer, and so on another endpoint if one endpoint sends BYE after establishment of the call. 5.1.1 Implementation of SIP Third Party Call Controller A SIP user agent (UA) will be sufficient to implement the features of the controller. All UA features may not need to be implemented Radhika R. Roy [Page 9] Internet Draft 3pcc Interworking February 22, 2002 for acting as the controller. A user agent server (UAS) should be sufficient to implement the controller functions [2]. However, it is also possible for the controller to take ownership of a call setup by a different party by acting as a back-to-back UA (B2BUA) and the call flows will be little different than those shown in Figures 2 and 3 when the controller acts as the B2BUA [2]. There can also be SIP proxies in addition to endpoints and controller. The call flows will still remain the same because stateful or stateless proxies will be routing the signaling messages among the endpoints and controllers. If the controller function is implemented to a SIP proxy, the call flows will still remain the same. The only difference may be that some fields within the SIP signaling messages may be modified for routing while it will be functioning as a proxy in addition to the controller role. 5.1.2 SIP Third party Call Management The third party controller itself invites the participants and control the calls for establishment, modify, and terminate the calls. The controller itself becomes the SIP entity and it is desired to register itself. In turn, it is also desired to get access to the SIP REGISTRATION server, possibly through a location server [8-10], to know the actual addresses, as opposed to the logical addresses, of the participants. The controller itself also needs to identify who it is and why it is doing so. SIP [3] provides mechanisms for authentication, but nothing is specified why a third party controller is trying to establish the call. A separate work (e.g., service level agreement [SLA] in the case of multi-carrier environment) is needed at the time of service provisioning that a third party call control is allowed. 5.2 H.323 Third Party Call Control Like SIP, H.323 third party call control application will also have the same capabilities to control and manipulate the call. The important point is that H.245 is used to media control where the capability negotiation is very powerful. The implementation of the third party call control in H.323 is cleaner and straightforward and, unlike SIP, no assumption is required whether an endpoint is human or priori known non-human to avoid the timeout or media control/manipulation problems. However, the complex negotiation takes too many round trips. H.323 EP A Controller H.323 EP B Radhika R. Roy [Page 10] Internet Draft 3pcc Interworking February 22, 2002 | | | | Setup | | |<------------------| | | | | | Connect | | |-----------------> | | | | | | | setup | | |----------------->| | | | | | Connect | | |<-----------------| | | | |H.245 ch. setup | H.245 ch. setup | |-------------------|------------------| | | | | TCS = 0 | | |<------------------| | | TCS Ack | | |------------------>| | | TCS | | |------------------>| | | | TCS | | |----------------->| | | TCS Ack | | |<-----------------| | TCS Ack | | |<------------------| TCS | | TCS |<-----------------| |<------------------| | | TCS Ack | | |------------------>| TCS Ack | | |----------------->| | MSD | | |------------------>| MSD | | |----------------->| | | | | | MSD Ack | | MSD Ack |<-----------------| |<------------------| MSD | | MSD |<-----------------| |<------------------| | | MSD Ack | | |------------------>| MSD Ack | | |----------------->| | | | | OLC | | |------------------>| OLC | | |----------------->| | | OLC Ack | Radhika R. Roy [Page 11] Internet Draft 3pcc Interworking February 22, 2002 | OLS Ack |<-----------------| |<------------------| OLC | | OLC |<-----------------| |<------------------| | | | | | OLC Ack | | |------------------>| OLC Ack | | |----------------->| | | | | | RTP | |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | | | | | | | | CLC | | |------------------>| CLC | | CLC Ack |----------------->| |<----------------- | CLC Ack | | |<-----------------| | Release Complete | | |------------------>| Release Complete | | |----------------->| | | | | | | | | | Figure 4: H.323 Third Party Call Control (TCS = Terminal Capability Set, MSD = Master Slave Determination, OLC = Open Logical Channel, CLC = Close Logical Channel) 5.2.1 Implementation of H.323 Third Party Call Controller The flow of Figure 4 clearly shows that the controller needs to understand H.323 signaling messages. From implementation point of view, a controller at least needs to be aware of H.225.0 Q.931/932 and H.245 signaling messages. Indirectly, it has to act almost like an H.323 endpoint that does not deal with H.225.0 RAS signaling messages and RTP media streams. However, it seems to be prudent to implement H.225.0 RAS in the controller as well so that it can take advantages of the services that GKs provide specially for the large- scale network. If there are GKs, the call flows will still remain the same, but the controller needs to be the aware of the H.225.0 RAS signaling Radhika R. Roy [Page 12] Internet Draft 3pcc Interworking February 22, 2002 messages so that a GK will be able to know there is an H.323 controller at the time of registration. However, this will require additional signaling messages between the controller and the GK should any resources need to be reserved/released (e.g., messages like ARQ/ACF/ARJ and DRQ/DCF/DRJ) in addition to the endpoints and have not been shown in Figure 4. 5.2.2 H.323 Third Party Call Management Like SIP, H.323 third party controller itself also invites the participants and controls the calls for establishment, modification, and termination of the calls. The controller itself becomes the H.323 entity and it is desired to register itself. Like SIP, the controller itself also needs to identify who it is and why it is doing so. H.323 [4] provides mechanisms for authentication. As mentioned earlier, a separate work (e.g., service level agreement [SLA] in the case of multi-carrier environment) is needed at the time of service provisioning that a third party call control is allowed. So, the controller needs to register with a GK in order to participate in the H.323 services. Before registration of the GK, a controller needs to discover who will be the GK. H.323/H.225.0 RAS protocol has discovery and registration services using GRQ/GCF/GRJ and RRQ/RCF/RRJ messages, respectively. The controller can have these services using H.225.0 RAS protocol. In order to set up the communications among the participants, a controller needs to obtain the actual addresses, as opposed to the logical addresses, of the participants before the setup of the call. In addition, a controller may also need to reserve the bandwidth resources for the participants. The controller can use the ARQ/ACF/ARJ and other messages of H.225.0 RAS protocol for registration, admission, address translation, bandwidth reservation, call management, and other purposes. 5.3 SIP-H.323 Interworking Third Party Call Control The third party call controller can be placed anywhere in the SIP- or H.323-based IP Telephony network either as a separate entity or as a part in conjunction with SIP proxy, H.323 GK, MCU, or IWF. We are assuming that there is a single third party call controller that provides seamless services to both SIP and H.323 endpoints. The situation can be such that there are two third party controllers: One in SIP-based IP Telephony network while the other one is in the H.323-based IP Telephony network. In this case, the interworking Radhika R. Roy [Page 13] Internet Draft 3pcc Interworking February 22, 2002 between the two controllers is also needed, and we are not considering this situation in this document. 5.3.1 Two-Party Call: SIP and H.323 Endpoint We are considering the case where two endpoints, one in the SIP- based IP Telephony network while the other one in H.323 side, will be communicating and the controller will help to set up the call between the endpoints. The controller can be located anywhere and there can be many scenarios for interworking based on the location of the controller as follows: A. Third party call controller in the SIP-based IP telephony network (First endpoint in the SIP side while the second endpoint in the H.323 side) A.1 Initially INVITE without SDP sent to the SIP endpoint first (assumption): Second endpoint located in the H.323 side known (may be pre-provisioned with non-human endpoint like media server, conferencing server, or other) to the controller and the controller expects that this entity will answer the call immediately without causing any spurious retransmissions or timeouts in the SIP side A.1.1 If the IWF does not set up the call to the H.323 side priori A.1.2 If the IWF sets up the call to the H.323 side priori A.2 Initially INVITE without SDP sent to the SIP endpoint first (assumption): Second endpoint located in the H.323 side and the answering behavior of the H.323 side is not known (e.g., human user) to the controller so that that the delay for response in the H.323 side should not cause timeout in the SIP side A.2.1 If the IWF does not set up the call to the H.323 side priori A.2.2 If the IWF sets up the call to the H.323 side priori A.3 Initially INVITE without SDP sent to the H.323 endpoint first (assumption): Second endpoint located in the SIP side B. Third party call controller in the H.323-based IP telephony network Radhika R. Roy [Page 14] Internet Draft 3pcc Interworking February 22, 2002 5.3.1.2 Third Party Call Control Application in the SIP-based IP Telephony Network Figure 1 shows that IWF interconnects the SIP- and H.323-based IP Telephony network. We are assuming that the first endpoint resides in the SIP side while the second endpoint is the H.323 side. 5.3.1.2.1 H.323 Endpoint other than human being Known to the Controller Answers the Call Immediately If the behavior of the H.323 endpoint is known to the controller along with its media capabilities, the controller can then deal with the unknown SIP endpoint easily in accordance with its media capabilities that are not known to the controller. 5.3.1.2.1.1 Controller does Not Setup the Call to the H.323 side Priori via IWF The key point of this flow (Figure 5) is that the controller knows that the behavior of the H.323 endpoint will not cause spurious transmissions or timeouts to the SIP side before sending the final response ACK. In addition, when SDP of the SIP endpoint is sent to the controller, the controller will be able to determine whether the media capabilities will be supported by the H.323 endpoint or not. SIP EP A Controller IWF H.323 EP B | | | | | | | | | INVITE no SDP | | | |<------------------| | | | 200 OK SDP A | | | |------------------>| INVITE SDP A | | | |----------------->| Setup | | | |----------------->| | | | Connect | | | |<-----------------| | | | TCS | | | |<---------------->| | | | MSD | | | |<---------------->| | | | OLC | | | |----------------->| | | | OLC Ack | | | |<-----------------| | | | OLC | | | 200 OK SDP B |<-----------------| Radhika R. Roy [Page 15] Internet Draft 3pcc Interworking February 22, 2002 | |<-----------------| | | | ACK | | | ACK SDP B |----------------->| | |<----------------- | | OLC Ack | | | |----------------->| | | | | | RTP | |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| | | | | | | | | Figure 5: H.323 Endpoint other than a Human being: Controller does Not Setup the Call to the H.323 side Priori via IWF The detail description for each message flow may be seen in Appendix A. 5.3.1.2.1.2 Controller Sets Up the Call to the H.323 side Priori via IWF The only benefit of this flow (Figure 6) compared to that of the earlier flow (Figure 5) is that there is a some saving in time to se up the connection in the H.323 side. As a result, the relatively less delay in the call set up time to the H.323 side will help not to cause spurious transmissions or timeouts to the SIP side. SIP EP A Controller IWF H.323 EP B | | | | | | | | | | INVITE no SDP | | | |----------------->| | | | | Setup | | | |----------------->| | | | Connect | | | |<-----------------| | | | TCS = 0 | | | |----------------->| | | | TCS Ack | | | |<-----------------| | | | TCS | | | 200 OK SDP B |<-----------------| | |<-----------------| | | INVITE no SDP | | | |<------------------| | | | 200 OK SDP A | | | |------------------>| INVITE SDP A | | Radhika R. Roy [Page 16] Internet Draft 3pcc Interworking February 22, 2002 | |----------------->| | | | | TCS Ack | | | |----------------->| | | | TCS | | | |----------------->| | | | TCS Ack | | | |<-----------------| | | | MSD | | | |<---------------->| | | | OLC | | | |----------------->| | | | OLC Ack | | | |<-----------------| | | | OLC | | | 200 OK SDP B |<-----------------| | |<-----------------| | | | ACK | | | ACK SDP B |----------------->| | |<----------------- | | OLC Ack | | | |----------------->| | | | | | RTP | |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| | | | | | | | | Figure 6: H.323 Endpoint other than a Human being: Controller Sets Up the Call to the H.323 side Priori via IWF The detail description for each message flow may be seen in Appendix A. 5.3.1.2.2 H.323 Endpoint not Known to the Controller or Entities Represent People If the both SIP and H.323 endpoint are not known to the controller, the flow needs to be carefully handled to manipulate the media capabilities in the SDP of the SIP side. 5.3.1.2.2.1 Controller Does Not Setup the Call to the H.323 side Priori via IWF The controller does not know both endpoints and the flow shown in Figure 7 needs to be manipulated by the controller carefully in the SIP side to have the same common capability to the both sides. The controller must take some SDP and generates another SDP which has the same media composition, but is on hold. The controller may need Radhika R. Roy [Page 17] Internet Draft 3pcc Interworking February 22, 2002 to reorder the SDP B, so that its media lines match up with those in some other SDP B'. However, the advantage of this flow is that it does not cause any spurious transmissions or timeouts. It does not require the controller to guess the media that will be used by the participants. Most importantly, this flow does not assume that a device responds properly to an INVITE with SDP on hold and, consequently, the long call setup time to the H.323 side will not cause any problems to the SIP side. SIP EP A Controller IWF H.323 EP B | | | | | | | | | INVITE no SDP | | | |<------------------| | | | 200 OK SDP A1 | | | |------------------>| | | | ACK SDP held | | | |<------------------| INVITE no SDP | | | |----------------->| | | | | | | | | | | | Setup | | | |----------------->| | | | Connect | | | |<-----------------| | | | TCS=0 | | | |----------------->| | | | TCS Ack | | | |<-----------------| | | | | | | | TCS | | | |<-----------------| | | | TCS Ack | | | |----------------->| | | | TCS | | | |----------------->| | | | TCS Ack | | | |<-----------------| | | | MSD | | | |<---------------->| | | | OLC | | | 200 OK SDP B |<-----------------| | INVITE SDP B' |<-----------------| | |<------------------| | | | 200 SDP A2 | | | |------------------>| ACK SDP A2 | | Radhika R. Roy [Page 18] Internet Draft 3pcc Interworking February 22, 2002 | |----------------->| OLC Ack | | ACK | |----------------->| |<------------------| | | | RTP | |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| | | | | | | | | Figure 7: Both SIP and H.323 Endpoint Unknown to the Controller: Controller Does Not Setup the Call to the H.323 side Priori via IWF The detail description for each message flow may be seen in Appendix A. 5.3.1.2.2.2 Controller Sets Up the Call to the H.323 side Priori via IWF The only benefit of this flow (Figure 8) is that the H.323 side will cause less delay to set up the call compared to that of the flow shown in Figure 7. SIP EP A Controller IWF H.323 EP B | | | | | | INVITE no SDP | | | |----------------->| | | | | Setup | | | |----------------->| | | | Connect | | | |<-----------------| | | | TCS=0 | | | |----------------->| | | | TCS Ack | | | |<-----------------| | | | TCS | | | 200 OK SDP B |<-----------------| | |<-----------------| | | INVITE no SDP | | | |<------------------| | | | 200 OK SDP A1 | | | |------------------>| | | | ACK SDP held | | | |<------------------| INVITE no SDP | | | |----------------->| TCS Ack | | | |----------------->| | | | TCS | | | |----------------->| | | | TCS Ack | Radhika R. Roy [Page 19] Internet Draft 3pcc Interworking February 22, 2002 | | |<-----------------| | | | | | | | MSD | | | |<---------------->| | | | OLC | | | 200 OK SDP B |<-----------------| | INVITE SDP B' |<-----------------| | |<------------------| | | | 200 SDP A2 | | | |------------------>| ACK SDP A2 | | | |----------------->| OLC Ack | | ACK | |----------------->| |<------------------| | | | RTP | |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| | | | | | | | | Figure 8: Both SIP and H.323 Endpoint Unknown to the Controller: Controller Sets Up the Call to the H.323 side Priori via IWF The detail description for each message flow may be seen in Appendix A. 5.3.1.2.3 Fast Connect to the H.323 Endpoint: SIP Endpoint Known/Unknown to the Controller The fast call setup in the H.323 side will reduce the call setup time significantly for all cases what have described earlier (Flows of Figures 5-8). 5.3.1.2.3.1 H.323 Endpoint other than human being Known to the Controller Answers the Call Immediately Figure 9 shows the flow when the fast call setup is made to the H.323 side. It clearly shows that it will reduce the probability of the spurious retransmissions or timeouts to the SIP side. This flow is recommended when it is possible to implement. SIP EP A Controller IWF H.323 EP B | | | | | | | | | INVITE no SDP | | | |<------------------| | | | 200 OK SDP A | | | Radhika R. Roy [Page 20] Internet Draft 3pcc Interworking February 22, 2002 |------------------>| INVITE SDP A | | | |----------------->|Setup (fastStart= | | | | ture, OLC) | | | |----------------->| | | |Connect (fast | | | |Connect=True, OLC)| | | |<-----------------| | | 200 OK SDP B | | | |<-----------------| | | | ACK | | | ACK SDP B |----------------->| | |<----------------- | | | | | | | | | | | | RTP | |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| | | | | | | | | Figure 9: Fast Call Setup to the H.323 side: H.323 Endpoint other than a Human being The other scenarios for the H.323 fast call setup can also be described case by case basis. We will address those flows in separate Internet drafts. 5.3.1.2.4 Tunneling to the H.323 Endpoint: SIP Endpoint Known/Unknown to the Controller These scenarios will also be addressed in separate Internet drafts. However, it may be mentioned that the H.323 tunneling mechanisms will also reduce the overall call setup time. However, it will not reduce the call setup time as much it is done using the fast call setup. 5.3.1.3 Third Party Call Control Application in the H.323-based IP Telephony Network The flow scenarios for this case when the controller is placed to the H.323 side are similar what has been described earlier in the case when the controller is placed in the SIP side. The detail call flows will be described later. Radhika R. Roy [Page 21] Internet Draft 3pcc Interworking February 22, 2002 5.3.2 Multi-Party Call The multi-party call scenarios will be addressed later as SIP's standards for conferencing are still to be addressed while the conferencing standards for H.323 have been completed sometime ago. 6. Third Party Call Control Service Transparency for SIP-H.323 Interworking The third party call control mechanisms proposed here will provide service transparency for both SIP and H.323 endpoints. The controller can be placed in any IP Telephony network whether it uses SIP or H.323 protocol. The functionality of the controller can be implemented over a separate server residing in a SIP- or H.323-based IP Telephony network, SIP Proxy, SIP Endpoint, H.323 GK, H.323 Endpoint, or SIP-H.323 IWF. The transparent third party call control requires several services for working in the SIP-H.323 interworking environment. 6.1 Location of the Third Party Controller 6.1.1 Controller Located in SIP Side The controller can be in either SIP- or H.323-based IP Telephony network. If the controller is in the SIP side of the IP Telephony network, it address will be SIP URL as specified in SIP RFC 2543 [2]. When controller needs to establish calls among the participants of both SIP and H.323 endpoints transparently, its SIP URL needs to be a common address space that can be mapped between SIP URL and H.323 alias address as specified in SIP-H.323 Interworking standard [5]. So, when the controller uses SIP URL of a participant and that participant remains in the H.323 side, the call will be routed via SIP-H.323 IWF. The IWF will then map the SIP URL to the H.323 alias address and route the call to the H.323 endpoint. One interesting problem is that there may be many SIP-H.323 IWFs between SIP and H.323 system and a given IWF is the keeper of addresses of many SIP and H.323 endpoints. A controller being in the SIP side or a SIP proxy on behalf of the controller needs to select the appropriate IWF to route the call. Although the SIP side of an IWF will be able to act as a SIP UA that can register only one SIP URL. SIP does not have the mechanism to register all the addresses that an IWF keeps. So, separate mechanisms [9, 10] are needed for discovery of the IWF and registration of the addresses (SIP URL, H.323 alias address) by the IWF to the location server/SIP proxy. Radhika R. Roy [Page 22] Internet Draft 3pcc Interworking February 22, 2002 6.1.2 Controller Located in the H.323 Side If a controller is in the H.323 side of the network, it will do the similar thing as it has been described when it remains in the SIP side. The controller will use the H.323 alias addresses for both SIP and H.323 participants. For the endpoint that is located in the SIP side, the call will be sent via an IWF that will convert the H.323 alias address to a SIP URL assuming that the alias address will be one of the addresses of the common subset both SIP URLs and H.323 alias addresses as specified in SIP-H.323 Interworking standard [5]. The important difference is that the H.323 side of the IWF will be able to work as the H.323 GW. Unlike SIP, an H.323 GW will also be able to discover the H.323 GK and can register all the H.323 alias addresses to a GK. As a result, a controller itself or a controller with the help of a GK will be able to select the appropriate IWF to route a call to the SIP side. 6.2 Address Resolution The actual addresses of the controller and participants need to be known irrespective of the fact that some parties will be in the SIP side while others will be in the H.323 side of the network. For example, the SIP URL provided in the contact becomes the actual address of the SIP participant. In H.323, the alias address of the H.323 participant becomes the actual address. DNS and/or other mechanisms can be used to map the actual address to the physical address where necessary. However, a SIP-H.323 IWF [5] is used to map between the SIP URL and H.323 alias address when the call is routed from the SIP to the H.323 side and vice versa. 6.3 Accounting, Authentication, and Authorization Participants need to know that they will be asked to accept the call from the third party controller and there should be an established standard mechanism how to perform billing or accounting in addition to authentication and authorization. The key point is that the controller is not a direct party between the communicating endpoints. Rather, it facilitates the communications among the participants. As a result, each party knows that each one is communicating with the controller with a point-to-point logical mode although the media goes directly between the participants. The controller is not a direct party among the participants so far the media is concerned. Radhika R. Roy [Page 23] Internet Draft 3pcc Interworking February 22, 2002 The third party role of the controller raises an important issue how to deal with billing, authentication, and authorization. If both SIP and H.323 system belongs to the same service provider, the situation is not so complicated. If there are different service providers for the SIP- and H.323-based IP Telephony, the situation becomes more complicated. A careful observation will reveal the fact that there is a complete transparency between the SIP and H.323 system because both use the same RTP media stream and both SIP and H.323 endpoints can send RTP media streams directly once the call is set up using two dissimilar SIP and H.323 signaling protocols. It implies that all issues related to the authentication, authorization, and accounting (AAA) need to resolved at the time of call setup. Both SIP and H.323 have their own authentication and authorization mechanisms. An interworking between these two systems for security also needs to be addressed. The SIP-H.323 Interworking [5] is yet to be worked out for this standard. Similar is the case for interworking of the accounting. Once the interworking for security and accounting standard are developed, the same can be used to develop the standard for the third party call control with transparency between SIP and H.323 endpoints. 6.4 Bandwidth Management H.323 has the mechanisms to provide bandwidth reservation for both pre-call setup and call setup time. So, H.323 endpoints can have the opportunity to have the guaranteed bandwidth for the H.323 side of the call. However, there is no standard defined in SIP FRC 2543 [3] how SIP endpoints can have the opportunity to reserve the bandwidth either during the pre-call setup or during the call setup time. As a result, there will be no standard mechanism that will provide complete transparency for both SIP and H.323 endpoints for the third party call control. The subsequent SIP RFC 2543-bis07 (or its updated version) may take care of the bandwidth reservation during the call setup time, but there still new works needs to be done in the SIP side how the bandwidth can be reserved during the pre-call setup time as it is done using ARQ/ACF/ARJ messages in the case of H.225.0 RAS to make the transparent SIP-H.323 interworking. Radhika R. Roy [Page 24] Internet Draft 3pcc Interworking February 22, 2002 6.5 Media Control SIP uses SDP as a message body to manipulate media while H.323 uses H.245 protocol for control of media. However, the third party controller does not have the media information of the participants in priori. A controller needs to initiate communications with each party in such a way, as if, each participate believes that it is in point-to-point communications mode with the controller although media goes directly between the participants bypassing the controller. The above communication mode requires that the controller needs to initiate communications in such a way that will force the participant to respond with its media capabilities although the controller does not know the media capability of the participant priori. In SIP, the controller sends the INVITE message to a participant without SDP and, in turn, the controller responds with its media capability in SDP. Then the controller sends the same SDP of the participant to the other participant. The communication for negotiation of media among the participants is done via the controller. In this way, a controller helps to establish the call so that media can be sent directly between the participants. In H.323, as we have proposed, a controller starts media negotiations by sending the empty terminal capability set (TCS) to the participant. In turn, the participant sends its own TCS and the same TCS of the participant is sent to the other participant. Then the controller helps to negotiate media so that the media can go directly among the participants. The above generic principle of the controller is applicable whether the controller is in the SIP side or in the H.323 side. However, when SDP goes from the SIP side to the H.323 side and vice versa, a mapping needs to be done between SDP and H.245 messages within the IWF as defined in the SIP-H.323 Interworking standard [6]. The important point is that the signaling messages will be going through the controller. That is, the controller's address also needs to be registered to the IWF. There are some issues in discovery of the IWF and registration of the SIP URL with the SIP side of the IWF and the suggested solution has been described in other internet drafts [9, 10]. 6.6 Discovery Like the discovery of the IWFs and GKs in H.323, it is also seen that the discovery of the IWFs and SIP proxies/Location servers is needed in the SIP side if one needs to use the third party call control services transparently across both SIP and H.323 IP Telephony services. The discovery mechanism for IWFs and SIP Radhika R. Roy [Page 25] Internet Draft 3pcc Interworking February 22, 2002 proxies/Location servers can be done as proposed in another Internet draft [9]. 6.7 Registration We have discussed the difficulty of registration of the IWF in SIP. An IWF will be the keeper of 100s and 1000s of SIP URLs. However, a IWF can register only one SIP URL acting as a single SIP UA. Unlike H.323, the IWF can not advertise the SIP URLs of all other endpoints to the SIP proxies/location servers in the SIP side that can be reachable through it. The registration mechanism for IWFs to the SIP proxies/Location servers can be done as proposed in another Internet draft [10]. 6.8 Policy A third party call controller will be able to apply its independent policy to initiate calls to the participants as a third party whether it is located in the SIP-side or in the H.323 side of the IP Telephony network. The policy of the controller will also be dependent whether both SIP- and H.323-side of the IP Telephony network is controlled by the same service provider or different service providers. The accounting, authentication, and authorization services of the third party calls will be highly dependent on the policy of the controller. The detail discussion of the policy of the third party controller will done in separate Internet drafts. 7. Conclusion In this contribution, we have discussed a generalized third party call control mechanism that provides transparent services over the both SIP- and H.323-based IP Telephony network assuming that SIP- H.323 IWFs will be used to provide the mapping between SIP and H.323 signaling messages. The following have been accomplished in this document: 1. We have explained the difference between the first and third party call control. 2. We have described how the third party call management can be done by the third party call controller with the help of SIP REGISTRAR and Location server. 3. We have proposed a third party call control service for H.323 along with the third party call management using H.323 discovery and registration messages. Radhika R. Roy [Page 26] Internet Draft 3pcc Interworking February 22, 2002 4. We have shown how the third party call control entity can offer transparent services interworking between SIP- and H.323-based IP Telephony network whether the controller is placed within the SIP- or H.323-side of the network. The fast call setup of the H.323 side has also been addressed to reveal the fact it helps to reduce the call setup time drastically. H.323 fast call setup time helps the SIP side not to cause spurious retransmissions or timeouts. The H.323 tunneling mechanisms will also help to reduce the call setup time, but as much as it is done in the case of the fast call setup time. 5. We have analyzed that the third party call control function is a generic one and can be implemented over a application separate server, over a SIP proxy, over a SIP endpoint, over an H.323 GK, over an H.323 endpoint, or on a SIP-H.323 IWF based on the cost, performance, and policy decision. 6. We have described the mechanisms for address resolution and media control when the third party call controller establishes the call between the SIP and H.323 endpoints. 7. We have provided solution for discovery and registration related to the IWFs and SIP proxies/Location servers in the SIP side that may be needed to accomplish the transparent services by the third party call controller interworking between SIP- and H.323-side. 8. We have identified the issues related to the bandwidth reservation, accounting, authentication, authorization, policy in the context of the third party call control services. 9. We have described that the call flows (what have been shown in the case of the controller in the SIP side) will be similar if the controller is placed to the H.323 side. 10. Although we have shown the call flows for the two-party case where one endpoint in the SIP side while the other party in the H.323 side, the multiparty call scenarios for SIP-H.323 interworkig can also be done in a similar way as in the case of the two-party scenarios. 11. We have explained that the implementation of the third party call control function in a SIP proxy, SIP endpoint, H.323 GK, H.323 endpoint, MCU, or SIP-H.323 IWF is a special case of the generalized mechanism that has been described in this contribution. Radhika R. Roy [Page 27] Internet Draft 3pcc Interworking February 22, 2002 8. References [1] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996. [2] Rosenberg, J., Peterson, P., Schulzrinne, H., and Cmarillo, G., _Third Party Call Control in SIP,_ draft-rosenberg-sip-3pcc-03.txt, IETF, Work in progress. [3] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [4] "Packet based multimedia communication systems", Recommendation H.323v2, ITU-T, Geneva, Switzerland, February 1998. [5] Agrawal, H., Roy, R. R., Palawat, V., Johnston, A., Agboh, C., Wang, D., Singh, K., and Schulzrinne, H., "SIP-H.323 Interworking ", draft-agrawal-roy-palawat-sip-h323-interworking-reqs- 00.txt, IETF, April 2000. Work in progress. [6] Bhatia, M., _Third Party Call Control in SIP-H.323 Interworking,_ draft-bhatia-sip-h323-interworking-3pcc-00.txt, IETF, April 2000. Work in progress. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. [8] Rosenberg, J., H. Salama, H., Bangalore, M., Shah, D., Kumar, R., _Usage of TRIP in Gateways for Exporting Phone Routes,_ draft- rs-trip-gw-03.txt, IETF, Work in progress. [9] Roy, R. R., _Gateway and Server Discovery Protocol,_ draft-roy- iptel-gw-server-discovery-00.txt, IETF, Work in progress. [10] Roy, R. R., _Gateway and Server Registration Protocol,_ draft- roy-iptel-gw-server-registration-00.txt, IETF, Work in progress. Appendix A: Detail Description for Message Flows TBD Acknowledgments TBD Author's Addresses Radhika R. Roy AT&T Room D3_3C09 200 S. Laurel Avenue Middletown, NJ 07748, USA Phone: +1 732 420 1580 Fax: + 1 732 368 1302 Email: rrroy@att.com Intellectual Property Statement Radhika R. Roy [Page 28] Internet Draft 3pcc Interworking February 22, 2002 AT&T Corp. may own intellectual property applicable to this contribution. AT&T is currently reviewing its licensing intent relative to the Intellectual Property and will notify the IETF when AT&T has made a determination of that intent. Full Copyright Statement 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 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 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Radhika R. Roy [Page 29]