Internet Engineering Task Force Hemant Agrawal INTERNET DRAFT GlobeSpan Inc Radhika R. Roy Category: Informational AT&T Expires: October 10, 2000 Vipin Palawat Wipro Technologies 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 docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working docu- ments 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 interworking function (IWF) that will allow for interworking between the SIP and H.323 system. Agrawal, Roy, and Palawat [Page 1] Internet draft SIP-H.323 Interworking Requirements 10 April 2000 Table of Contents 1. Introduction .............................................. 3 2. Terminology ............................................... 3 3. Definitions ............................................... 3 4. Functionality within the IWF .............................. 3 5. Pre-Call Requirements ..................................... 4 5.1. Registration with H.323 Gatekeeper ................... 4 5.2. Registration with SIP Server ......................... 5 6. Resource Management ....................................... 5 6.1. Resource Allocation and Reservation .................. 5 6.2. Resource Control ..................................... 5 7. General Interworking Requirements ......................... 6 7.1. Performance Requirements .............................. 6 7.2. Basic call Requirements ............................... 6 7.2.1. Address Resolution ............................... 6 7.2.2. Call with H.323 GK ............................... 7 7.2.3. Call with SIP Servers ............................ 7 7.2.4. Call with both H.323 GK and SIP Server ........... 8 7.2.5. Capability negotiation ........................... 8 7.2.6. Opening of logical channels ...................... 8 7.2.7. Handling Media transmission and reception ........ 9 7.3. Requirements for support of fast connect procedures ... 9 7.4. Requirements for support of H.245 tunnelling .......... 9 7.5. Requirements for support of pre granted ARQ ........... 9 7.6. Requirements for support of overlapped sending ........ 9 7.7. Requirements for support of early H.245 ............... 9 8. Transport ................................................. 10 8.1. Assumptions made for underlying network .............. 10 8.2. Transport Requirements ............................... 10 9. Mapping between SIP and H.323 .............................. 10 9.1 General Procedures .................................... 10 9.2. H.323 Call Signalling (Q.931) and SIP Call Signalling . 11 9.3. H.323 Call Control (H.245) and SIP Call Control(SDP) .. 11 9.4. H.323 audio/video codec to SIP media formats .......... 11 9.5. Call sequence ......................................... 11 10. State Machine Requirements ................................ 12 11. Security Requirements ..................................... 12 12. Current Issues ............................................ 12 13. Activities planned for next phase ......................... 13 14. Examples and Scenarios .................................... 13 15. Full Copyright Statement .................................. 16 16. References ................................................ 16 17. Acknowledgements .......................................... 17 18. Authors' addresses ........................................ 17 Agrawal, Roy, and Palawat [Page 2] Internet draft SIP-H.323 Interworking Requirements 10 April 2000 1. Introduction This document describes requirements to be placed on the SIP-H.323 Interwoking function (IWF). This will become the guidelines for any Gateway converging the ITU-T H.323 and IETF SIP. 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 [1] and indi- cate requirement levels for the protocol. 3. Definitions 3.1. H.323 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. IWF Interworking function which allows interworking between the H.323 and SIP system. 3.3. SIP Server This can be either SIP proxy or SIP redirect server. 3.4. Endpoint This is an entity from which the media originates or finally terminates. This can either be H.323 terminal or SIP user agent. 3.5. Media switching fabric (MSF) This will be a logical entity present in the IWF, which will perform the task of switching RTP from one logical port to other. 4. Functionality within the IWF This section provides the functional requirements of the SIP-H.323 interworking function. IWF can be architectured in various ways. This may include the coexistence of H.323 Gatekeeper or SIP servers with IWF. The location of the H.323 GK and/or SIP server in conjunction with the IWF is a matter of implementation and not a protocol issue. There will be no assumptions made for the optional elements and components present in either H.323 or SIP networks. The solution provided here will work for a minimum configuration required for both the protocols. There will be recommendations for other configurations, which includes optional components. Agrawal, Roy, and Palawat [Page 3] Internet draft SIP-H.323 Interworking Requirements 10 April 2000 For instance, H.323 Gatekeeper is not a mandatory component of H.323 network. So, there will be no assumptions made for the basic interworking which involves H.323 Gatekeeper either co-located with IWF or exists separately on H.323 zone. The introduction of IWF redundancy in the network is left for further discussion. Therefore, an IWF is assumed to contain the following functions: a) Call sequence mapping. b) Address resolution. c) Terminal Capability transactions. d) Opening and closing of media channels. e) Mapping media codecs for H.323 and SIP network. f) Resource reservation and release. g ) Ability to provide the state of resources. h) Call state machine. i) Out of band signal processing. There will be no processing on the media data at IWF. It is assumed that both H.323 and SIP network uses RTP as a transport for carrying media. In most of the cases RTP will be directly between the endpoints. Even if the media from one endpoint terminated at IWF in special scenario, the assumption is made that this will be simply switched to other endpoint by a media switching fabric present in the IWF. The inclusion of Network Management for IWF is left for further discussion. 5. Pre-Call Requirements The IWF function shall have a table of reference for look up to resolve the corresponding H.323 and SIP addresses to IP addresses. This can either be accomplished by using the capabilities of H.323 Gatekeeper and SIP servers. Since H.323 Gatekeeper and SIP Server are not mandatory components of H.323 and SIP systems respectively, the IWF function may keep the information for address resolution within itself, which can be updated by using the H.323 Gatekeeper, SIP Server or any other database. 5.1. Registration with H.323 Gatekeeper This is done to give the information about SIP side extensions of IWF to H.323 Gatekeeper if it is present in the network. This information will be used by H.323 Gatekeeper to direct the call whose destination is in the SIP network. The registration information may be updated at any time to the H.323 Gatekeeper. The way in which IWF gets the information of SIP side extension is for further study. IWF can register with one H.323 Gatekeeper only. The registration with multiple GKs by the IWF is for further study. Agrawal, Roy, and Palawat [Page 4] Internet draft SIP-H.323 Interworking Requirements 10 April 2000 5.2. Registration with SIP Server This is done to give the information about H.323 side extensions of the IWF to the SIP Server if it is present in the SIP network. This information will be used by the SIP server to direct the call whose destination is in H.323 network. The way in which IWF gets the information of H.323 side extensions is for further study. IWF may register with one SIP server only. IWF may register with many SIP servers. This is for further discussion. 6. Resource Management Resources for a call is the memory, processing time slot, logical ports and other call related data within the IWF. Resources in the IWF are to be managed with respect to resource reservation and resource control. This resource reservation is done for both signalling and media switching fabric on a per call basis. 6.1. Resource Allocation and Reservation The IWF shall: 6.1.1 Support reservation of logical ports for signalling and media switching fabric for use by a particular call and support their subsequent release (which may be implicit or explicit). 6.1.2 Allow release in a single exchange of message, of all resources associated with a particular call. 6.1.3 Support release of resources if IWF detects that the call is no longer active. The detection of call inactivity is for further discussion. 6.1.4 Support the reservation and release of resources for opening, reopening, changing and closing of media channels during the call. The procedures for opening, reopening, closing and changing the existing media sessions during a call is for further discussion. The IWF may: 6.1.5 Support the reservation by priority based on the order of capability descriptors. 6.1.6 Support the reporting of resource reservation and connection completion. 6.2. Resource Control The IWF shall: Agrawal, Roy, and Palawat [Page 5] Internet draft SIP-H.323 Interworking Requirements 10 April 2000 6.2.1 Support the prereservations for a particular call. These reservations can be made before a call comes at IWF. 6.2.2 Support the restrictions that can be imposed on a particular endpoint for the use of resources. 6.2.3 Support the prereservation of resources for a particular endpoint. 6.2.4 Support the reporting for out of resource. 6.2.5 Support the denial of additional resource required during a call for opening, reopening, closing and changing of sessions. 6.2.6 Support for force release of the resources associated with a call. 7. General Interworking Requirements The gateway shall use the H.323 Version 2.0 [5] and SIP Ver 2.0 [2]. The gateway should handle all mandatory features of H.323 Version 2 as well as SIP Version 2.0. It should also provide backward compatibility for earlier versions. The IWF will 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. 7.1. Performance Requirements 7.1.1. Minimizing the message exchange. 7.1.2. Recommended maximum processing delay at IWF. The figure for maximum delay is left for further discussion. 7.1.3. Guidelines for the peak calling time. This is left for further discussion. 7.1.4. There should be default settings, so that the transactions will only be for a change or non-default parameters. 7.2. Basic call Requirements 7.2.1. Address Resolution The IWF shall: 7.2.1.1. Support all the addressing schemes of both H.323 and SIP protocol. Agrawal, Roy, and Palawat [Page 6] Internet draft SIP-H.323 Interworking Requirements 10 April 2000 7.2.1.2. Register itself to H.323 Gatekeeper and SIP Server if they are present in the Network. 7.2.1.3. have a look up table for resolving the addresses. This may be updated from the H.323 GK and SIP server. The IWF may: 7.2.1.4. Use LDAP or X.500 for keeping the address resolution information. 7.2.1.5. Use DNS for address resolution. 7.2.2. Call with H.323 GK The IWF shall: 7.2.2.1. Resolve addresses with the help of H.323 GK when it is present in the network. 7.2.2.2. Register itself to forward the SIP extensions supported on SIP side of IWF. 7.2.2.3. not register with two different H.323 Gatekeepers. This is left for further discussion. The IWF may: 7.2.2.4. Update the newly added SIP extentions to H.323 Gatekeeper. This is left for further discussion. 7.2.3. Call with SIP Server The IWF shall: 7.2.3.1. Resolve addresses with the help of SIP Server if it is present in the network. 7.2.3.2. Register itself with SIP Server to forward the H.323 extentions supported on H.323 side of IWF. The IWF may: 7.2.3.3. Register with many SIP servers. This is left for further discussion. 7.2.3.4. Update the newly added H.323 extensions to SIP Server. This is left for f urther discussion. Agrawal, Roy, and Palawat [Page 7] Internet draft SIP-H.323 Interworking Requirements 10 April 2000 7.2.4. Call with both H.323 GK and SIP Server All the requirements of Section 7.2.2 and Section 7.2.3 will be met for this case. 7.2.5. Capability negotiation The IWF shall: 7.2.5.1. not make any assumptions for 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 doing capability exchange with H.323(using H.245) and SIP (using SDP). This default capability is the mandatory capability requirements as defined by the respective protocols. For example, G.711 is mandatory for higher bandwidth networks of H.323. 7.2.5.2. pass on all the capability descriptors of H.323 and SDP from SIP in the maximum 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. 7.2.5.3. Provide mapping for common audio/video formats supported in H.323 with the RTP/AVP formats. The IWF may: 7.2.5.4. use OPTIONS message on the SIP side to do capability negotiations. 7.2.5.5. supports extensions of H.245 and SDP for ATM and other transport. 7.2.5.6. support re-negotiation of codec 7.2.6. Opening of logical channels The IWF shall: 7.2.6.1. open the channels between the endpoints only wherever possible. If it is not possible, then it can be opened at the media switching fabric of IWF. 7.2.6.2. support unidirectional, symmetric bi-directional, and asymmetric bi-directional opening of channels. The IWF may: 7.2.6.3. respond to the mode request and/or to the request for reopening and changing an existing logical channel . Agrawal, Roy, and Palawat [Page 8] Internet draft SIP-H.323 Interworking Requirements 10 April 2000 7.2.6.4. support the flow control of H.323. 7.2.7. Handling Media transmission and reception The IWF shall: 7.2.7.1. Not process RTP data going in and out from media switching fabric. The IWF may: 7.2.7.3. Collect the statistics of media flow for the particular call. The parameters for collection of statistics is left for further discussion. 7.2.7.4. Use the media flow statistics to maintain the QOS. 7.3. Requirements for support of fast connect procedures The IWF shall support the fastStart element. 7.4. Requirements for support of H.245 tunneling The IWF shall support the H.245 tunneling in Setup message. 7.5. Requirements for support of pregranted ARQ The IWF shall support the pregranted ARQ. In this case, the IWF may do the address resolution from H.323 GK using LRQ/LCF exchange. 7.6. Requirements for support of overlapped sending The IWF shall support the overlapped sending of dialed digits. 7.7. Requirements for support of early H.245 This is left for further discussion. Agrawal, Roy, and Palawat [Page 9] Internet draft SIP-H.323 Interworking Requirements 10 April 2000 8. Transport 8.1. Assumptions made for underlying network 8.1.1 It should support both the TCP and UDP i.e. both reliable and non-reliable delivery of messages is supported. 8.1.2 The network of H.323 and SIP system can be anywhere. There are no assumptions for the closeness of these networks. 8.1.3 The network is not assuring QOS. 8.1.4 There is no priority of signalling messages over other messages. 8.2. Transport Requirements 8.2.1 It is assumed that both H.323 and SIP network uses RTP for carrying media. If this is not the case then a media gateway is required. 8.2.2 Support for large fan-out. 9. Mapping between SIP and H.323 9.1. General Procedures 9.1.1. A clearer mapping between SIP and H.323 messages shall be provided which reflects similar meaning in call sequence. 9.1.2. The call message sequence shall be maintained in both the directions. 9.1.3. The IWF shall not take any decision on its own related to basic functionality of a call like call setup and call teardown etc. 9.1.4. The messages, which do not have a match on the other side, should be terminated on the IWF, and IWF should take the necessary action on them. 9.1.5. In case the IWF is required to generate a message on its own in any of the side, IWF should use the pre-configured default values for the parameters. 9.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) shall be converted to respective Agrawal, Roy, and Palawat [Page 10] Internet draft SIP-H.323 Interworking Requirements 10 April 2000 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. c) The SIP data fields are converted into the corresponding ASN.1 user-user information element structure. The user-user information element structure shall be generated according to the specification in Recommendation H.225.0 and H.245. 9.2 Call Signalling (H.225.0) and SIP Call Signalling 9.2.1. The IWF shall conform to the call signalling procedures recommended for the SIP side independent from the H.323 side. 9.2.2. The IWF shall conform to the call signalling procedures recommended for the H.323 side independent from the SIP side. 9.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 call signalling (if any) between the IWF and the SIP endpoint on the other side. 9.2.4. The IWF shall terminate the RAS Channel between H.323 Gatekeeper (if any) and IWF. 9.2.5. Messages for supplementary services (FACILITY, NOTIFY, and the INFORMATION messages) in H.323 side are to be processed by the IWF, only if the service is supported. 9.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. 9.4 H.323 audio/video codec to SIP media formats The IWF should: 9.4.1. provide invisible support for all audio/video algorithms supported by either ITU or IANA. 9.4.2. Handling of dynamic payload types is for further discussion. 9.5. Call sequence The call sequence should be maintained in such a way on both sides of IWF so that neither H.323 terminal nor SIP UA is aware of the IWF presence. The IWF should provide seamless interworking between the call Agrawal, Roy, and Palawat [Page 11] Internet draft SIP-H.323 Interworking Requirements 10 April 2000 flows of the two protocols. The IWF will not do 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 of the cases. In brief, the H.323 endpoint should not be aware of the fact it is calling a SIP endpoint and vice versa. 10. State Machine Requirements The state machine for IWF will follow the following general guidelines: 10.1. Unexpected messages in a particular state are treated as "Error" messages. 10.2. All messages which do not change the state are treated as "Non triggering or Informational" messages. 10.3. All messages which expect a change in state are treated as "Triggering" m essages. For each state, there should be guidelines that classify all possible messages into above three categories. Apart from this, it is required to specify the processing i.e. action to be taken in the state machine on the contents of the message. This will result into 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 Triggering 11. Security Requirements All the security requirements are for further discussion. Assumptions for the endpoints: 11.1. All endpoints trying to use IWF are authorized with respective H.323 Gatekeeper and SIP server if it is present in the network. 11.2. All endpoints trying to make a call using IWF are respectively admitted to do so from H.323 Gatekeeper and SIP server if it is present in the network. Agrawal, Roy, and Palawat [Page 12] Internet draft SIP-H.323 Interworking Requirements 10 April 2000 Required for IWF: 11.3 Procedures for preventing denial of service security attacks. 11.4 Maintaining a persistence data for authorized endpoints for future verifications. 12. Current Issues 12.1. There will be no network management functionality. This is left for further discussion. 12.2 There will be no redundancy for IWF in the network. This is left for further discussion. 12.3 There will be no tone detection from RTP streams. This is left for further discussion. 12.4 The supplementary services are planned for next phase of the draft. 12.5 The conferencing is planned for next phase of the draft. 13. Activities planned for next phase 13.1 Simple call supplementary services like call forwarding, call hold and call transfer. 13.2 Conferencing. 13.3 Session change (re-invite, mode request). 13.4 Security: Authentication, Authorization and privacy 13.5 QOS signalling. 13.6 Network Management. 13.7 Redundancy. 14. Examples and Scenarios We are providing 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, we have not addressed how the mapping will be done in this contribution although we have shown what should be the output signaling message of the IWF for a given input signaling message in the IWF. Agrawal, Roy, and Palawat [Page 13] Internet draft SIP-H.323 Interworking Requirements 10 April 2000 In performing the mapping, the IWF may have to face the following situations: a. It may so appear that there can be one-to-one mapping between the signaling messages and the IWF will perform the translation accordingly. b. All parameters used in each signaling message one side may not match exactly to 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 understanding 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, and c as stated above are very critical to create the interoperability standard between H.323 and SIP and we like to address these in separate contributions. It may be mentioned that many problems in those areas have already been addressed in the interworking between SIP/SDP and H.323 document [1]. However, we have addressed the configurations for call scenarios and the input-output messages of the IWF that are required to provide interoperability between SIP and H.323. Following are the different configurations for the call scenarios: 14.1. Basic Configuration H.323 EP ---- IWF ---- SIP EP 14.2. Advanced Configurations 14.2.1. Calls using H.323 GK H.323 EP ---- H.323 GK ---- IWF ---- SIP EP 14.2.2. Calls using SIP Server H.323 EP ---- IWF ---- SIP Server ---- SIP EP 14.2.3. Calls using both H.323 GK and SIP Server H.323 EP ---- H.323 GK ---- IWF ---- SIP Server ---- SIP EP The different call scenarios for above configurations are: a) Simple Call from H.323 terminal to SIP terminal. Agrawal, Roy, and Palawat [Page 14] Internet draft SIP-H.323 Interworking Requirements 10 April 2000 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 pre granted ARQ (for configuration having H.323 GK). Some call flow examples for the different configurations and call scenarios are given below: i) Simple call from H.323 terminal to SIP terminal using configuration of 14.1 H.323 SIP EP Setup IWF EP |------------>| INVITE | | |------------>| | | 180 RINGING | | Alerting |<------------| |<------------| 200 OK | | Connect |<------------| |<------------| | | H.245 | | |<----------->| ACK | | |------------>| | RTP | |<------------------------->| ii) Simple call from SIP terminal to H.323 terminal using configuration of 14.1 Agrawal, Roy, and Palawat [Page 15] Internet draft SIP-H.323 Interworking Requirements 10 April 2000 SIP H.323 EP IWF EP | | | | INVITE | | |------------>| Setup | | |------------>| | | Alerting | | 180 RINGING |<------------| |<------------| Connect | | |<------------| | | H.245 | | 200 OK |<----------->| |<------------| | | ACK | | |------------>| | | RTP | |<------------------------->| 15. 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 oth-ers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and dis- tributed, 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 Stan- dards 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 FIT- NESS FOR A PARTICULAR PURPOSE." 16. References [1] Singh/Schulzrinne, "Interworking Between SIP/SDP and H.323", draft- Agrawal, Roy, and Palawat [Page 16] Internet draft SIP-H.323 Interworking Requirements 10 April 2000 singh-sip-h323-00.txt,IETF, January 2000. [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. 17. 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. Contributions to this document have also been made through internet-drafts and discussion with members of SIP, H.323 and SG16 forums. 18. Authors' addresses Hemant Agrawal GlobeSpan Inc. A-8,Sector 9, Noida (U.P.) - 201 301 INDIA Tel: +91-1191-4544028 Extn: 121 Fax: +91-1191-4544014 Email: hemantag@globespan.net Radhika R. Roy AT&T Room C1-2B03 200 Laurel Avenue S. Middletown, NJ 07748, USA Tel: +1-732-4201580 Fax: +1-732-3681195 Email: rrroy@att.com Vipin Palawat Wipro Technologies 271, Sri Ganesha Complex, Hosur Main Road, Madiwala, Bangalore - 560 068 (Karnataka) INDIA Agrawal, Roy, and Palawat [Page 17] Internet draft SIP-H.323 Interworking Requirements 10 April 2000 Tel: +91-80-5539134 Extn: 407 Fax: +91-80-5539701/702 Email: vipin.palawat@wipro.com Agrawal, Roy, and Palawat [Page 18]