Internet Engineering Task Force Hemant Agrawal INTERNET DRAFT GlobeSpan Inc Radhika R. Roy Category: Informational AT&T Expires: Aug, 2001 Vipin Palawat Cisco Systems Inc Alan Johnston MCI WorldCom Charles Agboh Ebone David Wang Nuera Communications Inc Kundan Singh Henning Schulzrinne Columbia University SIP-H.323 Interworking Requirements 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 obsolete 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 document is a product of the SIP-H.323 Interworking Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mailing list sip-h323@egroups.com. Abstract This document describes the requirements for the logical entity known as the SIP-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between the SIP (Session Initiation Protocol) and H.323 protocols. [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 1] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 Table of Contents 1. Introduction .............................................. 3 2. Terminology ............................................... 3 3. Definitions ............................................... 3 4. Functionality within the SIP-H.323IWF ..................... 4 5. Pre-Call Requirements ..................................... 5 5.1. Registration with H.323 Gatekeeper ................... 5 5.2. Registration with SIP Server ......................... 5 6. General Interworking Requirements ......................... 6 6.1 Basic call Requirements ................................ 6 6.1.1. General Requirements ............................. 6 6.1.2. Address Resolution ............................... 6 6.1.3. Call with H.323 GK ............................... 7 6.1.4. Call with SIP Servers ............................ 7 6.1.5. Call with both H.323 GK and SIP Server ........... 7 6.1.6. Capability negotiation ........................... 7 6.1.7. Opening of logical channels ...................... 8 6.1.8. Handling Media transmission and reception ........ 8 6.2. Requirements for support of fast connect procedures ... 8 6.3. Requirements for support of H.245 tunnelling .......... 9 6.4. Requirements for support of pre granted ARQ ........... 9 6.5. Requirements for support of overlapped sending and mid-call digit transfer..................................9 6.6. Requirements for support of early H.245 ............... 9 6.7. Requirements for H.323 trunking between SIP network ... 9 6.8. Requirements for SIP trunking between H.323 network ... 9 7. Transport ................................................. 9 7.1. Assumptions made for underlying network .............. 9 7.2. Transport Requirements ............................... 10 8. Mapping between SIP and H.323 .............................. 10 8.1. General Procedures ................................... 10 8.2. H.323 Call Signalling (Q.931) and SIP Call Signalling . 11 8.3. H.323 Call Control (H.245) and SIP Call Control (SDP) . 11 8.4. H.323 audio/video codec to SIP media formats .......... 11 8.5. Call sequence ......................................... 11 9. State Machine Requirements ................................ 12 10. Service Interoperability Requirements ..................... 12 11. Security Requirements ..................................... 12 12. Activities planned for next phase ......................... 13 13. Examples and Scenarios .................................... 14 14. Full Copyright Statement .................................. 17 15. References ................................................ 17 16. Acknowledgements .......................................... 18 17. Authors' addresses ........................................ 18 [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 2] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 1. Introduction This document describes the requirements for the logical entity known as the interworking function (SIP-H.323 IWF) that will allow the interworking between the SIP (Session Initiation Protocol) and H.323 protocols. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and indicate requirement levels for the protocol. 3. Definitions 3.1. H.323 Gatekeeper (GK) This is an optional component in H.323 network. If it is present, it MUST perform the address translation, bandwidth control, admission control and zone management. 3.2. Interworking Function (IWF) It performs interworking between the H.323 and SIP protocols. 3.3. SIP Server This can be either SIP Proxy, Redirect or Registrar server. 3.4. EndPoint An endpoint can call and be called. An endpoint is an entity from which the media originates or terminates. An endpoint can either be H.323 terminal, H.323 Gateway, H.323 MCU [5] or SIP user agent [2]. 3.5. Media switching fabric (MSF) This is an optional logical entity present in the IWF. If present, it will perform the task of switching media (voice, video, fax, etc.) from one logical connection to other. 3.6. SIP Side The SIP side of the IWF is the part of the IWF that terminates and originates SIP signaling from and to the SIP network respectively. 3.7. H.323 Side The H.323 side of the IWF is the part of the IWF that terminates and originates H.323 signaling from and to the H.323 network respectively. [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 3] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 4. Functionality within the SIP-H.323 IWF This section provides the functional requirements of the SIP-H.323 IWF. SIP-H.323 IWF can be architectured in various ways. This MAY include coexistence of H.323 Gatekeeper or SIP Server with the IWF. The co-location of the H.323 GK and/or SIP server with the IWF is a matter of implementation and not a protocol issue. There SHALL NOT be any assumptions made for the optional elements and components present in either H.323 or SIP networks. The solution provided here SHALL work for a minimum configuration required for both protocols. There MAY be recommendations for other configurations, which include optional components. For instance, H.323 Gatekeeper is not a mandatory component of H.323 network. So, there SHALL NOT be any assumptions made for the basic interworking which involves H.323 Gatekeeper either co-located with the IWF or existing separately in the H.323 zone. IWF belongs to both SIP and H.323 networks. The introduction of IWF redundancy in the network is left for further discussion. Therefore, an IWF MAY contain the following functions: a) Call sequence mapping. b) Address resolution. c) Terminal Capability exchange. d) Opening and closing of media channels. e) Mapping media algorithms for H.323 and SIP network. f) Registration of SIP and H.323 entities. g) Call resource reservation and release. h) Ability to provide the state of a call. i) Call state machine. j) Mid call signal processing. k) Service interoperability logic. The conversion of media from one format to another is out of scope. There SHOULD NOT be processing of the media at IWF. For a call between SIP and H.323 network, it is assumed that the same transport protocols (e.g. RTP, TCP, UDP, etc.) will be used in both H.323 and SIP networks for carrying media. In most of the cases, media packets SHOULD be flowing directly between the endpoints. Even if the media from one endpoint terminates at IWF in special scenario, the assumption is made [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 4] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 that this will be simply switched to another endpoint by a media switching fabric present in the IWF. This recommandation is going to use two phases in defining the SIP-H.323 interworking standard. The first phase will define the basic call establishment and termination. The second phase will include some optional, advanced features, and services. Both phases have to meet the general requirements specified in the following sections. 5. Pre-Call Requirements The IWF function MAY have a table of reference for lookup to resolve the corresponding H.323 and SIP addresses to IP addresses. This MAY be accomplished by using the capabilities of either H.323 Gatekeepers, SIP servers or any other database. Since H.323 Gatekeeper and SIP Server are not mandatory components of H.323 and SIP systems respectively, the IWF function MAY keep the address resolution information within itself, which may be updated by using the H.323 Gatekeeper, SIP Server, or any other database. 5.1. Registration of IWF with H.323 Gatekeeper In networks where H.323 gatekeeper is present, the IWF SHOULD register with a H.323 Gatekeeper to give the information about SIP side extensions. This information may be any addressing attribute such as transport address, alias address, email-ID, url-ID, etc. The IWF MAY register SIP entities in the H.323 network to allow the H.323 Gatekeeper to perform address resolution for the SIP entities. For example, the IWF may register with the H.323 Gatekeeper on behalf of a SIP user agent:the registration information sent by the IWF to the H.323 Gatekeeper would include the IWF RAS and call signaling addresses and the IWF would bind an H.323 alias address with the SIP user agent sip address. The IWF MAY update the registration information to the H.323 Gatekeeper. The mechanisms by which the IWF gets the information about the SIP side extensions is for further study. The IWF registration with multiple gatekeepers is also left for further study. 5.2. Registration with SIP Server In networks where SIP Servers are present, the IWF SHOULD register with the appropriate SIP server to give the information about H.323 side extensions. This information may be any addressing attribute such as transport address, alias address, email-ID, url-ID, etc. Since SIP does not support a gateway to register it's extensions to the SIP server, the IWF MAY register itself to the SIP server using TRIP[6]. The IWF MAY register itself as a SIP User agent specifying the H.323 side extensions in the REGISTER message. This IWF behavior is for further discussion. [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 5] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 The IWF MAY update the registration information to the SIP Server. The mechanisms by which the IWF gets the information about the H.323 side extensions is for further study. The IWF registration with multiple SIP Server is also left for further study. 6. General Interworking Requirements The IWF SHALL use the H.323 Version 2.0 [5] and SIP Ver 2.0 [2]. The IWF SHALL handle all mandatory features of H.323 Version 2.0 as well as SIP Version 2.0. It SHOULD also provide backward compatibility for earlier versions. The higher version of H.323 and SIP may be used in the second phase. The IWF SHALL provide the seamless interworking of the two protocols. The functioning of IWF should not involve any modification to the H.323 And SIP protocols, but MAY involve specific profiles of these protocols. 6.1. Basic call Requirements 6.1.1. General Requirements The IWF SHOULD: a) Provide default settings, so that the transactions will only be for a change of non-default parameters. The default parameters for such setting should be identified. For example, H.323 [5] and SIP [2], both specifications have defined many default parameters such as ports, timers, etc. b) Release any call related resource on the detection of call deactivation. SIP Session timers [2] MAY be used for this purpose in SIP side. However the methods for detecting call deactivation are for further study. 6.1.2. Address Resolution The IWF SHOULD: a) Support all the addressing schemes of both H.323 (alias address) and SIP (URL) protocols. b) Register itself to H.323 Gatekeeper and SIP Server if they are present in the Network. The IWF MAY: a) Have a look-up table for resolving the addresses. This may be updated from the H.323 GK, SIP server or any other database. b) Use LDAP or X.500 for keeping address resolution information. c) Use DNS for address resolution. d) Use TRIP for the SIP side. [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 6] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 6.1.3. Call with H.323 GK When an H.323 GK is present in the network, the IWF SHOULD: a) Resolve addresses with the help of H.323 GK. b) Register itself to forward the addressing information of SIP side extensions of IWF. c) Not be registered with two different H.323 Gatekeepers. (This is for further discussion.) The IWF MAY: a) Update the newly added SIP extensions to H.323 Gatekeeper. This is left for further discussion. b) Support a SIP user agent to register to a H.323 GK 6.1.4. Call with SIP Server When a SIP Server is present in the network, the IWF SHOULD: a) Resolve addresses with the help of SIP Server. The IWF MAY: a) Register itself with SIP Server (may be using TRIP [6]) to forward the addressing information of H.323 side extensions of IWF. b) Register with many SIP servers. This is left for further discussion. c) Update the newly added H.323 extensions to SIP Server. This is left for further discussion. d) Support a H.323 endpoint (EP) to register to a SIP Server 6.1.5. Call with both H.323 GK and SIP Servers All the requirements of Sections 6.1.3 and 6.1.4 will be met for this case. 6.1.6. Capability negotiation The IWF SHOULD: a) Not make any assumptions about the capabilities of either SIP user agent or H.323 terminal. However, it may indicate a default capability of H.323 terminal or SIP user agent even before exchanging capability with H.323 (in fastStart element or using H.245) and SIP (using Session Description Protocol, SDP [3]). This default capability follows the mandatory capability requirements as defined by the respective protocols. For example, G.711 is mandatory for higher bandwidth networks of H.323. [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 7] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 b) Send all the capability descriptors of H.323 and SDP descriptors of SIP in the best possible way to each other. The algorithm for finding out the maximum mapping of capability descriptors with the corresponding SDP is left for further discussion. c) Provide mapping for common audio formats supported in H.323 with the RTP/AVP formats. The IWF MAY: a) Use OPTIONS message on the SIP side to provide capability negotiations. b) Support re-negotiation of media capabilities. c) Provide mapping for common video/data formats supported in H.323 with the RTP/AVP formats. 6.1.7. Opening of channels The IWF SHOULD: a) Provide support for seamless exchange of messages for opening, reopening, changing and closing of media channels during a call. The procedures for opening, reopening, closing, and changing the existing media sessions during a call are for further discussion. b) Open the channels between the endpoints wherever possible. If this is not possible, then it can optionally be opened at the media switching fabric of IWF. c) Support unidirectional, symmetric bi-directional, and asymmetric bi-directional opening of channels. The IWF MAY: a) Respond to the mode request and/or to the request for reopening and changing an existing logical channel. b) Support the flow control of H.323. 6.1.8. Handle Media transmission and reception The IWF SHOULD: a) Not process any media transport data. Processing a media transport data is not the same as just switching the packets from one UDP port or another. 6.2. Requirements for support of fast connect procedures The IWF SHALL support the fast Start element in H.323. [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 8] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 6.3. Requirements for support of H.245 tunneling The IWF SHALL support the H.245 tunnelling procedures as described in H.323v2. 6.4. Requirements for support of pregranted ARQ The IWF SHOULD support the pre-granted ARQ in support of the GK request. In this case, the IWF may do the address resolution from H.323 GK using LRQ/LCF exchange, or using an internal resolution service or some other external resolution service (standard or proprietary). 6.5. Requirements for support of overlapped sending and mid-call digit transfer The IWF SHOULD support both overlap sending and mid-call digit transfer. The IWF SHOULD support overlap sending using the user part of Request-URI in SIP and Q.931 Setup, Setup Ack and Information Message in H.323. The IWF SHOULD support mechanisms allowing out-of-band DTMF signaling or transport. H.323 has support for DTMF transfer (userInputIndication), however whether DTMF SHOULD be carried in SIP message or in RTP stream [9] or both, with respect to this interworking is for further study. The IWF MAY support the transfer of digits during a call in SIP by using INFO[7] or any other proprietary/standard solution. The interworking between H.245 userInputIndication and SIP INFO method or any other non-INFO method is for further study. The support for in-band digit transfer in IWF is out of scope. 6.6. Requirements for support of early H.245 This is left for further discussion. 6.7. Requirements for H.323 trunking between SIP networks. This is left for next phase. 6.8. Requirements for SIP trunking between H.323 networks. This is left for next phase. 7. Transport 7.1. Assumptions made for underlying network 7.1.1 It should support both the TCP and UDP; i.e. both reliable and non-reliable delivery of messages are supported. [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 9] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 7.1.2 The H.323 and SIP system network can be anywhere. There are no assumptions for the closeness of these networks. 7.1.3 The network does not assure quality-of-service (QOS). The network that supports QOS will be addressed in the next phase. 7.1.4 Signalling messages have no priority over other messages. 7.1.5 The Support for H.323Annex E (H.323 signaling over UDP) is optional. 7.2. Media Transport Requirements 7.2.1. It is assumed that both H.323 and SIP networks use same transport protocols (e.g. RTP, TCP, UDP, etc.) for carrying media. In most of the cases, media packets should be flowing directly between the endpoints. If this is not the case, then a media gateway or media server may be required. 7.2.2. Support for large fan-out. 8. Mapping between SIP and H.323 8.1. General Procedures 8.1.1. A clear mapping between SIP and H.323 messages SHALL be provided which reflects similar meaning in call sequence. 8.1.2. Call message sequence SHALL be maintained in both directions. 8.1.3. The IWF SHALL NOT on its own take any decision related to basic functionality of a call like call setup and call teardown etc. 8.1.4. The messages that do not have a match on the other side SHOULD be terminated on the IWF, and IWF SHOULD take the necessary action on them e.g SIP standard allows a SIP UA to silently discard an ACK for a non-existent call leg. 8.1.5. In case the IWF is required to generate a message on its own in any of the sides, IWF SHOULD use the pre-configured default values for the parameters. 8.1.6. The information elements of the respective messages are to be converted as follows: a) The contents of connection-specific information elements (such as Call Reference Value on H.323) SHOULD be converted to respective information as required by SIP or SDP (such as session ID, call leg and Call-ID.) b) Information elements that are not in use on the H.323 side SHALL be generated by the IWF as required by the SIP protocol and vice versa. [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 10] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 c) The SIP data fields SHOULD be converted into the corresponding ASN.1 user-user information element structure. The user-user information element structure shall be generated according to specifications in Recommendation H.225.0 version 2.0. 8.2 Call Signalling (H.225.0) and SIP Call Signalling 8.2.1. The IWF SHALL conform to the call signalling procedures recommended for the SIP side independent of the H.323 side. 8.2.2. The IWF SHALL conform to the call signalling procedures recommended for the H.323 side independent of the SIP side. 8.2.3. The IWF SHALL terminate the Q.931 Call Signalling Channel between an H.323 endpoint or H.323 Gatekeeper (in case of GK routed signalling) and the IWF on one hand and the SIP call signalling (if any) between the IWF and the SIP endpoint on the other side. 8.2.4. The IWF shall terminate the RAS Channel between H.323 Gatekeeper (if any) and IWF. 8.2.5. Messages for supplementary services (FACILITY, NOTIFY, and the INFORMATION messages) in H.323 side may be processed by the IWF only if the service is supported. 8.3 H.323 Call Control (H.245) and SIP Call Control (SDP) IWF SHOULD try to map the H.245 and SDP to the maximum extent. The list of messages that can be mapped is for further study. 8.4 H.323 media codec to/from SIP media formats 8.4.1. The IWF SHOULD provide transparent support for all audio algorithms commonly supported by both ITU and IANA. 8.4.2. The IWF MAY provide transparent support for all video/data algorithms commonly supported by both ITU and IANA. 8.4.3. Handling of dynamic payload types is for further discussion. 8.5. Call sequence The call sequence on both sides SHOULD be maintained in such a way that neither H.323 terminal nor SIP UA is aware of the IWF presence. The IWF should provide seamless interworking between the call flows of the two protocols. The IWF will not make any modifications to the normal call flows of either protocols. The messages and parameters which do not have direct mapping on the other side are to be generated by the IWF with default parameters in most cases. In brief, the H.323 endpoint SHOULD be aware of the fact it is calling a SIP endpoint and vice versa. [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 11] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 9. State Machine Requirements The state machine for IWF will follow the following general guidelines: 9.1. Unexpected messages in a particular state that can change the state SHOULD be treated as "Error" messages. 9.2. All messages which do not change the state shall be treated as "Non triggering or Informational" messages. 9.3. All messages which expect a change in state shall be treated as "Triggering" messages. For each state, there should be guidelines that classify all possible messages into the above three categories. Apart from this, it is required to specify the processing i.e. action to be taken on the content of the messages in the state machine. This will result in a table given below as an illustration. State : Idle Possible Messages Message Category Action Next state All RAS Msg. Triggering Add Reg.Info. WaitForSetup All Q.931 Msg. Non Triggering All H.245 Msg. Error All Msg. from SIP side 10. Service Interoperability Requirements There should be a set of interoperation scenarios and application priorities. These should be defined from a service provider's point of view so that the resulting solution can be used in a globally deployable network that accommodates both SIP and H.323. This is an item for the second phase, hence it is for further study. 11. Security Requirements A simple security scheme SHOULD be enabled in the IWF. In this scheme the IWF will accept requests from a pre-configured set of SIP Servers, SIP EPs, H.323 EPs, or H.323 GKs only and it will reject all other requests. All other security requirements are for further discussion. Common security mechanisms between the two protocols are required to be identified in the next phase. Assumptions for the endpoints: 11.1. All endpoints trying to use IWF are authorized with the respective H.323 Gatekeepers or SIP servers if they are present in the network. This is left for further discussion. [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 12] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 11.2. All endpoints trying to make a call using IWF are respectively permitted to do so from H.323 Gatekeeper or SIP server if it is present in the network. Desired for IWF: 11.3. Procedures for preventing denial of service security attacks. 11.4. Maintaining persistent data for authorized endpoints for future verifications. 12. Activities planned for next phase 12.1. Simple call supplementary services like call forwarding, call hold and call transfer 12.2. support for extensions of H.245 and SDP for ATM and other transport 12.3. Audio and Video Conferencing 12.4. Session change (re-invite, mode request) 12.5. Security: Authentication, Authorization and privacy 12.6. Billing 12.7. QOS signaling 12.8. Network Management 12.9. Redundancy 12.10. Support for Clearing House 12.11. Interworking with Gateway Location Protocols such as TRIP, H.225 Annex G etc. 12.12. Support for fax (t.38 etc) and other data transfer (t.120 etc) 12.13. Robustness and Stability 12.14. H.323 trunking between SIP networks 12.15. SIP trunking between H.323 networks 12.16. The way in which the H.323 side of the IWF gets the information about the SIP side extension and vice versa for registration purpose 12.17. Registration with multiple gatekeepers or SIP servers by the IWF 12.18. Registration of the IWF itself as a SIP User Agent specifying the H.323 side extension in the REGISTER Message [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 13] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 12.19. Methods for detecting call deactivation by the IWF 12.20. The algorithm and list of messages for finding out the maximum mapping of capability descriptors with corresponding SDP by the IWF 12.21. Support of early H.245 in H.323 by the IWF 12.22. Interoperation scenarios and application priorities for the globally deployable network that accommodates both H.323 and SIP 12.23. Sovereignty over the IWF and relationship between the IWF (H.323 and SIP side) and Border Element of H.323 13. Examples and Scenarios Here are some examples of call scenarios that will show primarily the input and output signaling messages of the IWF for interworking between SIP and H.323. The important point is that the IWF will perform the translation between the signaling messages of SIP and H.323. However, it is not addressed how the mapping will be done in this contribution although it is shown what should be the output signaling message of the IWF for a given input signaling message in the IWF. In performing the mapping, the IWF may have to face the following situations: a) It may appear that there can be one-to-one mapping between the signaling messages; the IWF will perform the translation accordingly. b) All parameters used in each signaling message on one side may not match exactly the corresponding signaling message of the other side. In this situation, some manipulations need to be done by the IWF so that an agreed-upon standard can be created based on common under- standing although all parameters do not exactly match. c) For a given signaling message of a given protocol, there may not be a corresponding signaling message of the other protocol that may appear to be equivalent. The IWF needs to create a mapping between the signaling messages or generate error messages based on common understanding of an agreed upon standard. Items a, b, c as stated above are very critical to creating the interoperability standard between H.323 and SIP; therefore, we would like to address these in separate contributions. It may be mentioned that many problems in those areas have already been addresses in [1]. However, we have addressed the configurations for call scenarios and the input-output messages of the IWF that provide interworking between SIP and H.323. Following are the different configurations for the call scenarios: [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 14] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 13.1. Basic Configuration H.323 EP ---- IWF ---- SIP EP 13.2. Advanced Configurations 13.2.1. Calls using H.323 GK H.323 EP ---- H.323 GK ---- IWF ---- SIP EP 13.2.2. Calls using SIP Server H.323 EP ---- IWF ---- SIP Server ---- SIP EP 13.2.3. Calls using both H.323 GK and SIP Server H.323 EP ---- H.323 GK ---- IWF ---- SIP Server ---- SIP EP 13.2.4. SIP trunking between H.323 Networks H.323 EP ------IWF-------SIP Network ------IWF---------H.323 EP 13.2.5. H.323 trunking between SIP Networks SIP EP --------IWF-------H.323 Network --------IWF---------SIP EP The different call scenarios for the above configurations are: a) Simple Call from H.323 terminal to SIP terminal. b) Call from H.323 terminal to SIP terminal using H.245 tunneling. c) Call from H.323 terminal to SIP terminal using early H.245. d) Call from H.323 terminal to SIP terminal using fast connect procedure. e) Call from H.323 terminal to SIP terminal using overlapped sending. f) Call from H.323 terminal to SIP terminal using pre granted ARQ (for configurations having H.323 GK). g) Simple call from SIP terminal to H.323 terminal. h) Call from SIP terminal to H.323 terminal using H.245 tunneling. i) Call from SIP terminal to H.323 terminal using early H.245. j) Call from SIP terminal to H.323 terminal using fast connect procedure. k) Call from SIP terminal to H.323 terminal using overlapped sending. l) Call from SIP terminal to H.323 terminal using pregranted ARQ (for configuration having H.323 GK). [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 15] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 m) Call from a SIP terminal to SIP terminal using H.323 trunking between two IWFs. n) Call from a H.323 terminal to H.323 terminal using SIP trunking between two IWFs. Some call flow examples for the different configurations and call scenarios are given below: i) Simple calls (without FastStart Element) from H.323 terminal to SIP terminal using configuration of 13.1 (H.323 FastStart method may also be used to show the call of same configuration). H.323 SIP EP Setup IWF EP |------------>| INVITE | | |------------>| | | 180 RINGING | | Alerting |<------------| |<------------| 200 OK | | Connect |<------------| |<------------| | | H.245 | | |<----------->| ACK | | |------------>| | RTP | |<------------------------->| ii) Simple calls (without FastStart) from SIP terminal to H.323 terminal using configuration of 13.1 SIP H.323 EP IWF EP | | | | INVITE | | |------------>| Setup | | |------------>| | | Alerting | | 180 RINGING |<------------| |<------------| Connect | | |<------------| | | H.245 | | 200 OK |<----------->| |<------------| | | ACK | | |------------>| | | RTP | |<------------------------->| [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 16] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 14. Full Copyright Statement Copyright (C) The Internet Society (1999, 2000). 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 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 DISCLAIM 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 FIT-NESS FOR A PARTICULAR PURPOSE." 15. References [1] Singh/Schulzrinne, "Interworking Between SIP/SDP and H.323", draft- singh-sip-h323-00.txt,IETF, January 2000. Work in progress. [2] M. Handley, H.Schulzrinne, E.Schooler, and J.Rosenberg, "SIP:Session Initiation Prtocol", RFC 2543,IETF,March 1999. [3] M. Handley and V. Jacobson, "SDP: Session Description Prtocol", RFC 2327, IETF, April 1998. [4] S. Bradner,"Key words for use in RFCs to indicate requirement levels", RFC 2119,IETF, March 1997. [5] "Packet based multimedia communication systems", Recommendation H.323,ITU-T,Geneva,Switzerland,Feb. 1998. [6] J.Rosenberg and H.Salama, "Usage of TRIP in Gateways for Exporting Phone Routes",draft-rs-trip-gw-00.txt, IETF, March 2000. Work in progress. [7] S. Donovan, "The SIP INFO Method," RFC 2976, IETF, Oct.2000. [8] H.Agrawal, R.R.Roy and V.Palawat, "SIP-H.323 Interworking Requirements", draft-agrawal-roy-palawat-sip-h323-interworking-reqs- 00.txt, IETF, April 2000. Work in progress. [9] H.Schulzrinne and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, IETF, May 2000. [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 17] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 16. Acknowledgements The authors would like to acknowledge the many contributors who debated the SIP-H.323 interworking architecture and requirements on the IETF , SIP and SG16 mailing lists. In particular, we would like to thank Joon Maeng, Dave Walker and Jean-Francois Mule. Contributions to this document have also been made through internet-drafts and discussion with members of SIP, H.323, aHIT!, TIPHON and SG16 forums. 17. Authors' addresses Hemant Agrawal GlobeSpan Inc. A-8, Sector 9, Noida, UP - 201301 INDIA Tel: 91-120-4544028 x 121 Fax: 91-120-4544014 Email: hemantag@globespan.net Radhika R. Roy AT&T Room D3-2C09 200 Laurel Avenue S. Middletown, NJ 07748, USA Tel: 1-732-4201580 Fax: 1-732-3681302 Email: rrroy@att.com Vipin Palawat Cisco Systems Inc. 900, Chelmsford Street Tower II, Floor 14 Cube Number : 1440 Lowell, MA 01851 Tel: 1-978-275-5122 Fax: 1-978-275-5122 Email : vpalawat@cisco.com David Wang Nuera Communications Inc. 10445 Pacific Center Court San Diego, CA 92121 USA Tel: 1-858-6259220 x 1260 Fax: 1-858-6252422 Email: dwang@nuera.com [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 18] Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001 Alan Johnston MCI WorldCom 100 South Fourth Street St. Louis, MO 63102 USA Tel: 1-314- 3427360 Fax: 1-314-3428452 Email: alan.johnston@wcom.com Charles Agboh Ebone Terhulsesteenweg 6A, 1560 Hoeilaart Belgium. Tel: 22-658-4243 Fax: 22-658-5118 Email: Charles.Agboh@ebone.com Kundan Singh Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA Email: kns10@cs.columbia.edu Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA Email: schulzrinne@cs.columbia.edu [Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 19]