| TOC |
|
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 15, 2004.
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function (SIP-H.323 IWF) that will allow the interworking between SIP and H.323.
1.
Introduction
2.
Terminology
3.
Definitions
4.
Functionality within the SIP-H.323 IWF
5.
Pre-Call Requirements
5.1
Registration with H.323 Gatekeeper
5.2
Registration with SIP Server
6.
General Interworking Requirements
6.1
Basic Call Requirements
6.1.1
General Requirements
6.1.2
Address Resolution
6.1.3
Call with H.323 Gatekeeper
6.1.4
Call with SIP Registrar
6.1.5
Capability Negotiation
6.1.6
Opening of Logical Channels
6.2
IWF H.323 Features
6.3
Overlapped Sending
7.
Transport
8.
Mapping between SIP and H.323
8.1
General Requirements
8.2
H.225.0 and SIP Call Signaling
8.3
Call Sequence
8.4
State Machine Requirements
9.
Security Considerations
10.
Examples and Scenarios
10.1
Introduction
10.2
IWF Configurations
10.3
Call Flows
10.3.1
Call from H.323 Terminal to SIP UA
10.3.2
Call from SIP UA to H.323 Terminal
11.
Acknowledgments
12.
Contributors
§
Normative References
§
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
The SIP-H.323 Interworking function (IWF) converts between SIP (Session Initiation Protocol) [RFC3261] and the ITU Recommendation H.323 protocol [H.323]. This document describes requirements for this protocol conversion.
| TOC |
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 BCP 14, RFC 2119[RFC2119] and indicate requirement levels for compliant implementations.
| TOC |
- H.323 gatekeeper (GK):
- An H.323 gatekeeper is an optional component in an H.323 network. If it is present, it performs address translation, bandwidth control, admission control and zone management.
- H.323 network:
- In this document, we refer to the collection of all H.323-speaking components as the H.323 network.
- SIP network:
- In this document, we refer to the collection of all SIP servers and user agents as the SIP network.
- Interworking Function (IWF):
- The Interworking Function (IWF) performs interworking between H.323 and SIP. It belongs to both the H.323 and SIP networks.
- SIP server:
- A SIP server can be either a SIP proxy, redirect server, or registrar server.
- Endpoint:
- An endpoint can call and be called. An endpoint is an entity from which the media such as voice, video or fax originates or terminates. An endpoint can be H.323 terminal, H.323 Gateway, H.323 MCU [H.323] or SIP user agent (UA) [RFC3261].
- Media Switching Fabric (MSF):
- The Media Switching Fabric (MSF) is an optional logical entity within the IWF. The MSF switches media such as voice, video or fax from one network association to another.
| TOC |
This section summarizes the functional requirements of the SIP-H.323 interworking function (IWF).
A SIP-H.323 IWF MAY be integrated into an H.323 gatekeeper or SIP server. Interworking SHOULD NOT require any optional components in either the SIP or H.323 network, such as H.323 gatekeepers. IWF redundancy in the network is beyond the scope of this document.
An IWF contain functions from the following list, inter alia:
The IWF SHOULD NOT process media. We assume that the same media transport protocols, such as RTP, are used in both the SIP and H.323 network. Thus, media packets are exchanged directly between the endpoints. If a particular service requires the IWF to handle media, we assume that the IWF simply forwards media packets without modification from one network to the other, using a media switching fabric (MSF). The conversion of media from one encoding or format to another is out of scope for SIP-H.323 protocol translation.
| TOC |
The IWF function MAY use a translation table to resolve the H.323 and SIP addresses to IP addresses. This translation table can be updated by using a H.323 gatekeeper, SIP proxy server or a locally-maintained database.
An IWF MAY provide and update the H.323 gatekeeper with the addresses of SIP UAs. A SIP user agent can make itself known to the H.323 network by registering with an IWF serving as a registrar. The IWF creates an H.323 alias address and registers this alias together with its own network address with the appropriate GK.
The gatekeeper can then use this information to route calls to SIP UAs via the IWF, without being aware that the endpoint is not a "native" H.323 endpoint.
The IWF can register SIP UAs with one or more H.323 gatekeepers.
The IWF can provide information about H.323 endpoints to a SIP registrar. This allows the SIP proxy using this SIP registrar to direct calls to the H.323 end points via the IWF.
The IWF can easily obtain information about H.323 endpoints if it also serves as a gatekeeper. Other architectures require further study.
If the H.323 endpoints are known through E.164 (telephone number) addresses, the IWF can use IGREP [I-D.ietf-iptel-tgrep] or SLP [I-D.zhao-iptel-gwloc-slp] to inform the SIP proxy server of these endpoints.
The IWF only needs to register with multiple SIP registrars if the H.323 terminal is to appear under multiple, different addresses-of-record.
| TOC |
The IWF SHOULD use H.323 Version 2 or later and SIP according to RFC 3261 [RFC3261]. The protocol translation function MUST NOT require modifications or additions to either H.323 or SIP. However, it may not be possible to support certain features of each protocol across the IWF.
The IWF SHOULD provide default settings for translation parameters. The IWF specification MUST identify these defaults.
The IWF MUST release any call-related resource at the end of a call. SIP session timers [I-D.ietf-sip-session-timer] MAY be used on the SIP side.
The IWF SHOULD support all the addressing schemes in H.323, including the H.323 URI [RFC3508], and the "sip", "sips" and "tel" URI schemes in SIP. It SHOULD support the DNS-based SIP server location mechanisms described in [RFC3263] and H.323 Annex O, which details how H.323 uses DNS and, in particular, DNS SRV records.
The IWF SHOULD register with the H.323 Gatekeeper and the SIP registrar when available.
The IWF MAY use any means to translate between SIP and H.323 addresses. Examples include translation tables populated by the gatekeeper, SIP registrar or other database, LDAP, DNS or TRIP.
When an H.323 GK is present in the network, the IWF SHOULD resolve addresses with the help of the GK.
The IWF applies normal SIP call routing and does not need to be aware whether there is a proxy server or not.
The IWF SHOULD NOT make any assumptions about the capabilities of either the SIP user agent or the H.323 terminal. However, it MAY indicate a guaranteed-to-be-supported list of codecs of the H.323 terminal or SIP user agent before exchanging capabilities with H.323 (using H.245) and SIP (using SDP [RFC2327]). H.323 defines mandatory capabilities, SIP currently does not. For example, the G.711 audio codec is mandatory for higher bandwidth H.323 networks.
The IWF SHOULD attempt to map the capability descriptors of H.323 and SDP in the best possible fashion. The algorithm for finding the best mapping between H.245 capability descriptors and the corresponding SDP is left for further study.
The IWF SHOULD be able to map the common audio, video and application format names supported in H.323 to and from the equivalent RTP/AVP [RFC3550] names.
The IWF MAY use the SIP OPTIONS message to derive SIP UA capabilities. It MAY support mid-call renegotiation of media capabilities.
The IWF SHOULD support the 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 study.
The IWF SHOULD open media channels between the endpoints whenever possible. If this is not possible, then the channel can be opened at the MSF of the IWF.
The IWF SHOULD support unidirectional, symmetric bi-directional, and asymmetric bi-directional opening of channels.
The IWF MAY respond to the mode request, to the request for reopening and changing an existing logical channel and MAY support the flow control mechanism in H.323.
The IWF SHOULD support Fast Connect, H.245 tunneling in H.323 Setup messages. If IWF and GK are the same device, pre-granted ARQ SHOULD be supported. If pre-granted ARQ is supported, the IWF MAY perform the address resolution from H.323 GK using the LRQ/LCF exchange.
An IWF SHOULD follow the recommendations outlined in [I-D.ietf-sipping-overlap] when receiving overlapped digits from the H.323 side. If the IWF receives overlapped dialed digits from the SIP network, it MAY use the Q.931 Setup, Setup Ack and Information Message in H.323.
The IWF MAY support the transfer of digits during a call by using the appropriate SIP mechanism and UserInputIndication in H.245 (H.323).
| TOC |
The H.323 and SIP systems do not have to be in close proximity. The IP networks hosting the H.323 and SIP systems do not need to assure quality-of-service (QOS). In particular, the IWF SHOULD NOT assume that signaling messages have priority over packets from other applications. H.323 signaling over UDP (H.323 Annex E) is optional.
| TOC |
The call sequence on both sides SHOULD be maintained in such a way that neither H.323 terminal nor SIP UA is aware of presence of the IWF.
The state machine for IWF will follow the following general guidelines:
For each state, an IWF specification MUST classify all possible protocol messages into the above three categories. It MUST specify the actions taken on the content of the message and the resulting state. Below, is an example of such a table:
State: Idle Possible Messages Message Category Action Next state ------------------------------------------------------------------- All RAS msg. Triggering Add Reg.Info. WaitForSetup All H.245 msg. Error Send 4xx Idle SIP OPTIONS Non Triggering Return cap. Idle SIP INVITE Triggering Send SETUP WaitForConnect
| TOC |
The IWF SHOULD use normal H.323 and SIP security mechanisms, such as S/MIME for SIP and H.235[H.323] for H.323.
The IWF MUST implement procedures to avoid becoming the source of denial-of-service attacks.
Since all data elements in SIP or H.323 have to terminate at the IWF, the resulting security cannot be expected to be end-to-end. Thus, the IWF terminates not only the signalling protocols but also the security in each domain. Thus, users at the SIP or H.323 endpoint have to trust the IWF, like any other gateway, to authenticate the other side correctly. Similarly, they have to trust the gateway to respect integrity of data elements and to apply appropriate security mechanisms on the other side of the IWF.
The IWF MUST NOT indicate that a user on one side has achieved a certain level of trust without the ability to verify that. For example, if the SIP user was not authenticated, it would be inappropriate to use mechanisms on the H.323 side, such as H.323 Annex D, that indicated that the user identity had been authenticated.
If both protocols use certificate based authentication, the IWF SHOULD attempt to pass the certificates, while translating the signaling into the appropriate target format.
An IWF SHOULD NOT accept 'sips' requests since it cannot guarantee end-to-end security on the H.323 side.
| TOC |
We present some examples of call scenarios that will show the signaling messages received and transmitted. The following situations can occur:
Below are some common architectures involving an IWF:
- Basic Configuration:
- H.323 EP -- IWF -- SIP UA
- Calls using H.323 GK:
- H.323 EP -- H.323 GK -- IWF -- SIP UA
- Calls using SIP proxies:
- H.323 EP -- IWF -- SIP proxies -- SIP UA
- Calls using both H.323 GK and SIP proxy:
- H.323 EP -- H.323 GK -- IWF -- SIP proxies -- SIP UA
- SIP trunking between H.323 networks:
- H.323 EP -- IWF -- SIP network -- IWF -- H.323 EP
- H.323 trunking between SIP networks:
- SIP EP -- IWF -- H.323 network -- IWF -- SIP UA
Some call flow examples for two different configurations and call scenarios are given below.
H.323 SIP
EP Setup IWF UA
|------------>| INVITE |
| |------------>|
| | 180 RINGING |
| Alerting |<------------|
|<------------| 200 OK |
| Connect |<------------|
|<------------| |
| H.245 | |
|<----------->| ACK |
| |------------>|
| RTP |
|<.........................>|
SIP H.323
UA IWF EP
| | |
| INVITE | |
|------------>| Setup |
| |------------>|
| | Alerting |
| 180 RINGING |<------------|
|<------------| Connect |
| |<------------|
| | H.245 |
| 200 OK |<----------->|
|<------------| |
| ACK | |
|------------>| |
| RTP |
|<.........................>|
| TOC |
The authors would like to acknowledge the many contributors who discussed 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 by members of the H.323, aHIT!, TIPHON and SG16 forums.
| TOC |
In addition to the editors, the following people provided substantial technical and writing contributions to this document, listed alphabetically:
Hemant Agrawal Telverse Communications 1010 Stewart Drive Sunnyale, CA 94085 USA hagrawal@telverse.com
Alan Johnston MCI WorldCom 100 South Fourth Street St. Louis, MO 63102 USA alan.johnston@wcom.com
Vipin Palawat Cisco Systems Inc. 900 Chelmsford Street Lowell, MA 01851 USA vpalawat@cisco.com
Radhika R. Roy AT&T Room C1-2B03 200 Laurel Avenue S. Middletown, NJ 07748 USA rrroy@att.com
Kundan Singh Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA kns10@cs.columbia.edu
David Wang Nuera Communications Inc. 10445 Pacific Center Court San Diego, CA 92121 USA dwang@nuera.com
| TOC |
| [H.235] | , ITU., "Security and encryption for H-Series (H.323 and other H.245-based) multimedia terminals", Recommendation H.235, February 1998. |
| [H.323] | , ITU., "Packet based multimedia communication systems", Recommendation H.323, April 2003. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 (HTML, XML). |
| [RFC2327] | Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998 (HTML, XML). |
| [RFC3261] | Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. |
| [RFC3263] | Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. |
| [RFC3508] | Levin, O., "H.323 Uniform Resource Locator (URL) Scheme Registration", RFC 3508, April 2003. |
| [RFC3550] | Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003 (TXT, PS, PDF). |
| TOC |
| [I-D.ietf-iptel-tgrep] | Bangalore, M., "A Telephony Gateway REgistration Protocol (TGREP)", draft-ietf-iptel-tgrep-02 (work in progress), July 2003. |
| [I-D.ietf-sip-session-timer] | Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", draft-ietf-sip-session-timer-13 (work in progress), January 2004. |
| [I-D.ietf-sipping-overlap] | Camarillo, G., "Mapping of ISUP Overlap Signalling to the Session Initiation Protocol", draft-ietf-sipping-overlap-03 (work in progress), August 2002. |
| [I-D.levin-iptel-h323-url-scheme] | Levin, O., "H.323 URL scheme definition", draft-levin-iptel-h323-url-scheme-04 (work in progress), November 2001. |
| [I-D.zhao-iptel-gwloc-slp] | Zhao, W. and H. Schulzrinne, "Locating IP-to-Public Switched Telephone Network (PSTN) Telephony Gateways via SLP", draft-zhao-iptel-gwloc-slp-06 (work in progress), February 2004. |
| TOC |
| Henning Schulzrinne | |
| Columbia University | |
| Department of Computer Science | |
| 450 Computer Science Building | |
| New York, NY 10027 | |
| US | |
| Phone: | +1 212 939 7042 |
| EMail: | hgs@cs.columbia.edu |
| URI: | http://www.cs.columbia.edu |
| Charles Agboh | |
| Belgium | |
| EMail: | charles@nero.netwalk.org,cagboh@yahoo.com |
| TOC |
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
Copyright (C) The Internet Society (2004). 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 assignees.
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.
Funding for the RFC Editor function is currently provided by the Internet Society.