Internet Engineering Task Force Network Working Group
Internet Draft H. Schulzrinne
Columbia U.
C. Agboh (ed.)
KPNQwest
draft-agrawal-sip-h323-interworking-reqs-05.txt
June 28, 2003
Expires: December 2003
Session Initiation Protocol (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 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
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
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.
H. Schulzrinne et. al. [Page 1]
Internet Draft SIP-H.323 Requirements June 28, 2003
1 Introduction
The SIP-H.323 Interworking function (IWF) converts between SIP
(Session Initiation Protocol) [1] and the ITU Recommendation H.323
protocol [2]. This document describes requirements for this protocol
conversion.
2 Terminology
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 [3].
3 Definitions
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 [2] or SIP user agent
(UA) [1].
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.
4 Functionality within the SIP-H.323 IWF
This section summarizes the functional requirements of the SIP-H.323
interworking function (IWF).
H. Schulzrinne et. al. [Page 2]
Internet Draft SIP-H.323 Requirements June 28, 2003
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:
o Mapping of the call setup and teardown sequences;
o Registering H.323 and SIP endpoints with SIP registrars and
H.323 gatekeepers;
o Resolving H.323 and SIP addresses;
o Maintaining the H.323 and SIP state machines;
o Negotiating terminal capabilities;
o Opening and closing media channels;
o Mapping media coding algorithms for H.323 and SIP networks;
o Reserving and releasing call-related resources;
o Processing of mid-call signaling messages;
o Handling of services and features.
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.
5 Pre-Call Requirements
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.
5.1 Registration with H.323 Gatekeeper
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
H. Schulzrinne et. al. [Page 3]
Internet Draft SIP-H.323 Requirements June 28, 2003
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.
5.2 Registration with SIP Server
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 [8] or SLP [9] 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.
6 General Interworking Requirements
The IWF SHOULD use H.323 Version 2 or later and SIP according to RFC
3261 [1]. 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.
6.1 Basic Call Requirements
6.1.1 General Requirements
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 [10] MAY be used on the SIP side.
6.1.2 Address Resolution
H. Schulzrinne et. al. [Page 4]
Internet Draft SIP-H.323 Requirements June 28, 2003
The IWF SHOULD support all the addressing schemes in H.323, including
the H.323 URI [4], and the "sip", "sips" and "tel" URI schemes in
SIP. It SHOULD support the DNS-based SIP server location mechanisms
described in [5] 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.
6.1.3 Call with H.323 Gatekeeper
When an H.323 GK is present in the network, the IWF SHOULD resolve
addresses with the help of the GK.
6.1.4 Call with SIP Registrar
The IWF applies normal SIP call routing and does not need to be aware
whether there is a proxy server or not.
6.1.5 Capability Negotiation
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 [6]). 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
[7] names.
The IWF MAY use the SIP OPTIONS message to derive SIP UA
capabilities. It MAY support mid-call renegotiation of media
capabilities.
6.1.6 Opening of Logical Channels
H. Schulzrinne et. al. [Page 5]
Internet Draft SIP-H.323 Requirements June 28, 2003
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.
6.2 IWF H.323 Features
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.
6.3 Overlapped Sending
An IWF SHOULD follow the recommendations outlined in [11] 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).
7 Transport
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.
8 Mapping between SIP and H.323
8.1 General Requirements
o The call message sequence of both protocols MUST be
maintained.
H. Schulzrinne et. al. [Page 6]
Internet Draft SIP-H.323 Requirements June 28, 2003
o The IWF MUST NOT set up or tear down calls on its own.
o Signaling messages that do not have a match for the
destination protocol SHOULD be terminated on the IWF, with the
IWF taking the appropriate action for them. For example, SIP
allows a SIP UA to silently discard an ACK request for a non-
existent call leg.
o If the IWF is required to generate a message on its own, IWF
SHOULD use pre-configured default values for the message
parameters.
o The information elements and header fields of the respective
messages are to be converted as follows:
- The contents of connection-specific information elements,
such as Call Reference Value for H.323, is converted to
similar information required by SIP or SDP such as the SDP
session ID and the SIP Call-ID.
- The IWF generates protocol elements that are not available
from the other side.
8.2 H.225.0 and SIP Call Signaling
o The IWF MUST conform to the call signaling procedures
recommended for the SIP side regardless of the behavior of the
H.323 elements.
o The IWF MUST conform to the call signaling procedures
recommended for the H.323 side regardless of the behavior of
the SIP elements.
o The IWF serves as the endpoint for the Q.931 Call Signaling
Channel to either an H.323 endpoint or H.323 Gatekeeper (in
case of GK routed signaling). The IWF also acts as a SIP user
agent client and server.
o The IWF also establishes a RAS Channel to the H.323 GK, if
available.
o The IWF SHOULD process messages for H.323 supplementary
services (FACILITY, NOTIFY, and the INFORMATION messages) only
if the service itself is supported.
8.3 Call Sequence
The call sequence on both sides SHOULD be maintained in such a way
H. Schulzrinne et. al. [Page 7]
Internet Draft SIP-H.323 Requirements June 28, 2003
that neither H.323 terminal nor SIP UA is aware of presence of the
IWF.
8.4 State Machine Requirements
The state machine for IWF will follow the following general
guidelines:
o Unexpected messages in a particular state shall be treated as
"error" messages.
o All messages which do not change the state shall be treated as
"non-triggering" or informational messages.
o All messages which expect a change in state shall be treated
as "triggering" messages.
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
9 Security Considerations
The IWF SHOULD use normal H.323 and SIP security mechanisms.
The IWF MUST implement procedures to avoid becoming the source of
denial-of-service attacks.
10 Examples and Scenarios
10.1 Introduction
We present some examples of call scenarios that will show the
signaling messages received and transmitted. The following situations
can occur:
H. Schulzrinne et. al. [Page 8]
Internet Draft SIP-H.323 Requirements June 28, 2003
o Some signaling messages can be translated one-to-one.
o In some cases, parameters on one side do not match those on
the other side.
o Some signaling messages do not have an equivalent message on
the other side. In some cases, the IWF can gather further
information and the signal on the other side. In some cases,
only an error indication can be provided.
10.2 IWF Configurations
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
10.3 Call Scenarios
Some possible call scenarios for the above configurations are:
o Simple call from H.323 terminal to SIP UA;
o Call from H.323 terminal to SIP UA using H.245 tunneling;
o Call from H.323 terminal to SIP UA using early H.245;
o Call from H.323 terminal to SIP terminal using H.323 fast
connect procedure;
o Call from H.323 terminal to SIP terminal using overlapped
sending;
o Call from H.323 terminal to SIP terminal using pre-granted ARQ
(for configurations having a H.323 GK);
H. Schulzrinne et. al. [Page 9]
Internet Draft SIP-H.323 Requirements June 28, 2003
o Simple call from SIP UA to H.323 terminal;
o Call from SIP UA to H.323 terminal using H.245 tunneling.
o Call from SIP UA to H.323 terminal using early H.245;
o Call from SIP UA to H.323 terminal using H.323 fast connect
procedure;
o Call from SIP UA to H.323 terminal using overlapped sending;
o Call from SIP UA to H.323 terminal using pre-granted ARQ (for
configuration having H.323 GK);
o Call from SIP UA to SIP UA using H.323 trunking between two
IWFs;
o Call from a H.323 terminal to another H.323 terminal using SIP
trunking between two IWFs.
10.4 Call Flows
Some call flow examples for two different configurations and call
scenarios are given below.
10.4.1 Call from H.323 Terminal to SIP UA
H.323 SIP
EP Setup IWF UA
|------------>| INVITE |
| |------------>|
| | 180 RINGING |
| Alerting |<------------|
|<------------| 200 OK |
| Connect |<------------|
|<------------| |
| H.245 | |
|<----------->| ACK |
| |------------>|
| RTP |
|<.........................>|
10.4.2 Call from SIP UA to H.323 Terminal
H. Schulzrinne et. al. [Page 10]
Internet Draft SIP-H.323 Requirements June 28, 2003
SIP H.323
UA IWF EP
| | |
| INVITE | |
|------------>| Setup |
| |------------>|
| | Alerting |
| 180 RINGING |<------------|
|<------------| Connect |
| |<------------|
| | H.245 |
| 200 OK |<----------->|
|<------------| |
| ACK | |
|------------>| |
| RTP |
|<.........................>|
11 Normative References
[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002.
[2] International Telecommunication Union, "Visual telephone systems
and equipment for local area networks which provide a non-guaranteed
quality of service," Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, 2003.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[4] O. Levin, "H.323 URL scheme registration with IANA," internet
draft, Internet Engineering Task Force, Nov. 2002. Work in progress.
[5] J. Rosenberg and H. Schulzrinne, "Session initiation protocol
(SIP): locating SIP servers," RFC 3263, Internet Engineering Task
Force, June 2002.
[6] M. Handley and V. Jacobson, "SDP: session description protocol,"
RFC 2327, Internet Engineering Task Force, Apr. 1998.
[7] H. Schulzrinne, "RTP profile for audio and video conferences with
minimal control," RFC 1890, Internet Engineering Task Force, Jan.
1996.
H. Schulzrinne et. al. [Page 11]
Internet Draft SIP-H.323 Requirements June 28, 2003
12 Informative References
[8] M. B. et. al, "A telephony gateway REgistration protocol
(TGREP)," internet draft, Internet Engineering Task Force, Mar. 2003.
Work in progress.
[9] W. Zhao and H. Schulzrinne, "Locating IP-to-Public switched
telephone network (PSTN) telephony gateways via SLP," internet draft,
Internet Engineering Task Force, Aug. 2002. Work in progress.
[10] S. Donovan and J. Rosenberg, "Session initiation protocol
extension for session timer," internet draft, Internet Engineering
Task Force, Nov. 2002. Work in progress.
[11] G. Camarillo et al., "Mapping of of integrated services digital
network (ISUP) overlap signalling to the session initiation
protocol," internet draft, Internet Engineering Task Force, Feb.
2003. Work in progress.
13 Acknowledgments
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.
14 Contributors and Editor Addresses
The following people provided substantial technical and writing
contributions to this document, listed alphabetically:
Charles Agboh
Belgium
Email: charles@nero.netwalk.org,cagboh@yahoo.com
Hemant Agrawal
Telverse Communications
1010 Stewart Drive
Sunnyale, CA 94085
USA
Email: hagrawal@telverse.com
Alan Johnston
MCI WorldCom
100 South Fourth Street
St. Louis, MO 63102
H. Schulzrinne et. al. [Page 12]
Internet Draft SIP-H.323 Requirements June 28, 2003
USA
Email: alan.johnston@wcom.com
Vipin Palawat
Cisco Systems Inc.
900 Chelmsford Street
Lowell, MA 01851
USA
Email: vpalawat@cisco.com
Radhika R. Roy
AT&T
Room C1-2B03
200 Laurel Avenue S.
Middletown, NJ 07748
USA
Email: rrroy@att.com
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
Email: schulzrinne@cs.columbia.edu
Kundan Singh
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
Email: kns10@cs.columbia.edu
David Wang
Nuera Communications Inc.
10445 Pacific Center Court
San Diego, CA 92121
USA
Email: dwang@nuera.com
H. Schulzrinne et. al. [Page 13]
Table of Contents
1 Introduction ........................................ 2
2 Terminology ......................................... 2
3 Definitions ......................................... 2
4 Functionality within the SIP-H.323 IWF .............. 2
5 Pre-Call Requirements ............................... 3
5.1 Registration with H.323 Gatekeeper .................. 3
5.2 Registration with SIP Server ........................ 4
6 General Interworking Requirements ................... 4
6.1 Basic Call Requirements ............................. 4
6.1.1 General Requirements ................................ 4
6.1.2 Address Resolution .................................. 4
6.1.3 Call with H.323 Gatekeeper .......................... 5
6.1.4 Call with SIP Registrar ............................. 5
6.1.5 Capability Negotiation .............................. 5
6.1.6 Opening of Logical Channels ......................... 5
6.2 IWF H.323 Features .................................. 6
6.3 Overlapped Sending .................................. 6
7 Transport ........................................... 6
8 Mapping between SIP and H.323 ....................... 6
8.1 General Requirements ................................ 6
8.2 H.225.0 and SIP Call Signaling ...................... 7
8.3 Call Sequence ....................................... 7
8.4 State Machine Requirements .......................... 8
9 Security Considerations ............................. 8
10 Examples and Scenarios .............................. 8
10.1 Introduction ........................................ 8
10.2 IWF Configurations .................................. 9
10.3 Call Scenarios ...................................... 9
10.4 Call Flows .......................................... 10
10.4.1 Call from H.323 Terminal to SIP UA .................. 10
10.4.2 Call from SIP UA to H.323 Terminal .................. 10
11 Normative References ................................ 11
12 Informative References .............................. 12
13 Acknowledgments ..................................... 12
14 Contributors and Editor Addresses ................... 12
H. Schulzrinne et. al. [Page 1]