Internet Engineering Task Force Hemant Agrawal
INTERNET DRAFT GlobeSpan Inc
Radhika R. Roy
Category: Informational AT&T
Expires: Januray 10, 2001 Vipin Palawat
Opuswave Networks Inc
Alan Johnston
MCI WorldCom
Charles Agboh
Global TeleSystem Group
David Wang
Nuera Communications Inc
Kundan Singh
Henning Schulzrinne
Columbia University
SIP-H.323 Interworking Requirements
<draft-agrawal-sip-h323-interworking-reqs-00.txt>
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 interworking function (IWF) that will allow the interworking
between the SIP(Session Initiation Protocol) and H.323 networks.
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 1]
Internet draft SIP-H.323 Interworking Requirements 10 July 2000
Table of Contents
1. Introduction .............................................. 3
2. Terminology ............................................... 3
3. Definitions ............................................... 3
4. Functionality within the IWF .............................. 3
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 ............................... 6
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 ........ 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 ................................................ 18
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 10 July 2000
1. Introduction
This document describes the requirements for the logical entity known
as the interworking function (IWF) that will allow the interworking
between the SIP(Session Initiation Protocol) and H.323 networks..
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
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. IWF(InterWorking Function)
It 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 is an optional logical entity present in the IWF. If it is present,
it 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 an architecture 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 shall be no
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 3]
Internet draft SIP-H.323 Interworking Requirements 10 July 2000
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 be no 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 will belong 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 transactions.
d) Opening and closing of media channels.
e) Mapping media algorithms for H.323 and SIP network.
f) Call resource reservation and release.
g) Ability to provide the state of a call.
h) Call state machine.
i) Mid Call signal processing.
j) Service Interoperability Logic.
There should not be processing of 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 should be flowing directly between the
endpoints. Even if the media from one endpoint terminates at IWF in
special scenario, the assumption is made that this may be simply
switched to another endpoint by a media switching fabric present in the
IWF.
We are going to use two phases in defining the interworking standard.
The first phase will define the basic call establishment and
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 4]
Internet draft SIP-H.323 Interworking Requirements 10 July 2000
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 or
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 within itself the address resolution information, which may 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 the latter is present in the network. This
information may be used by H.323 Gatekeeper to direct a call whose
destination is in the SIP network. The registration information to the
H.323 Gatekeeper may be updated at any time. The way in which IWF gets
the information about the SIP side extension is for further study.
IWF can register with one H.323 Gatekeeper only. Registration with
multiple gatekeepers by the IWF is for further study.
The SIP user agent may register with the H.323 Gatekeeper via the IWF.
To achieve this, the IWF should create an H.323 alias address for the
SIP
User agent and bind its own transport address with this alias address
during registration.
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 the latter is present in the SIP network. This
information may be used by the SIP server to direct a call whose
destination is in the H.323 network. The way in which IWF gets the
information about the H.323 side extensions is for further study.
Since SIP does not require a gateway for registration 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.
IWF may register with one or many SIP servers. This is for subsequent
study.
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 5]
Internet draft SIP-H.323 Interworking Requirements 10 July 2000
6. General Interworking Requirements
The IWF shall use the H.323 Version 2.0 [5] and SIP Ver 2.0 [2]. The IWF
should 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 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 or non-default parameters. The default parameters for such
setting should be identified.
b) Release any call related resource on the detection of call
deactivation. SIP Session timers 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 and SIP protocol.
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 and SIP server.
b) Use LDAP or X.500 for keeping address resolution information.
c) Use DNS for address resolution.
d) Use TRIP
6.1.3. Call with H.323 GK
When an H.323 GK is present in the network, the IWF should:
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 6]
Internet draft SIP-H.323 Interworking Requirements 10 July 2000
a) Resolve addresses with the help of H.323 GK.
b) Register itself to forward the SIP extensions supported on SIP side
of IWF.
c) Not be registered with two different H.323 Gatekeepers. This is left
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 (e.g., using TRIP [6]) to forward the
H.323 extensions supported on the H.323 side 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(using H.245) and SIP (using SDP). 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 10 July 2000
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 logical 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 shall:
a) Not process any RTP data.
6.2. Requirements for support of fast connect procedures
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 8]
Internet draft SIP-H.323 Interworking Requirements 10 July 2000
The IWF shall support the fast Start element in H.323.
6.3. Requirements for support of H.245 tunneling
The IWF shall support the H.245 tunneling in Setup message.
6.4. Requirements for support of pregranted ARQ
The IWF shall support the pre-granted ARQ. In this case, the IWF may do
the address resolution from H.323 GK using LRQ/LCF exchange.
6.5. Requirements for support of overlapped sending
The IWF shall support the overlapped sending of dialed digits by using
the INFO method in SIP and Q.931 Setup, Setup Ack and Information
Message in H.323. The support for inband digit transfer (using RTP) in
IWF is out of scope.
The IWF shall support the transfer of digits during a call by using INFO
method in SIP and UserInputIndication in H.245(H.323).
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.
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.
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 9]
Internet draft SIP-H.323 Interworking Requirements 10 July 2000
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 network use RTP for carrying
media. If this is not the case, then a media gateway 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) shall 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.
c) The SIP data fields shall 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
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page 10]
Internet draft SIP-H.323 Interworking Requirements 10 July 2000
Recommendation H.225.0 version 2.0 and H.245 version 4.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 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 invisible support for all audio algorithms
commonly supported by both ITU and IANA.
8.4.2. The IWF may provide invisible 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
not 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 10 July 2000
9. State Machine Requirements
The state machine for IWF will follow the following general guidelines:
9.1. Unexpected messages in a particular state shall 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 Server,
SIP EP, H.323 EP, 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:
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page 12]
Internet draft SIP-H.323 Interworking Requirements 10 July 2000
11.1. All endpoints trying to use IWF are authorized with the respective
H.323 Gatekeepers and SIP servers if they are present in the network.
This is left for further discussion.
11.2. All endpoints trying to make a call using IWF are respectively
permitted to do so from H.323 Gatekeeper and SIP server if it is
present in the network.
Required 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
AnnexG etc.
12.12 Support for fax 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.
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page 13]
Internet draft SIP-H.323 Interworking Requirements 10 July 2000
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
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 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.
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page 14]
Internet draft SIP-H.323 Interworking Requirements 10 July 2000
Items a, b, and 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 addressed in the
interworking between SIP/SDP[2] 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:
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.
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page 15]
Internet draft SIP-H.323 Interworking Requirements 10 July 2000
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).
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 from H.323 terminal to SIP terminal using configuration
of 13.1
H.323 SIP
EP Setup IWF EP
|------------>| INVITE |
| |------------>|
| | 180 RINGING |
| Alerting |<------------|
|<------------| 200 OK |
| Connect |<------------|
|<------------| |
| H.245 | |
|<----------->| ACK |
| |------------>|
| RTP |
|<------------------------->|
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page 16]
Internet draft SIP-H.323 Interworking Requirements 10 July 2000
ii) Simple calls 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 |
|<------------------------->|
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."
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page 17]
Internet draft SIP-H.323 Interworking Requirements 10 July 2000
15. References
[1] Singh/Schulzrinne, "Interworking Between SIP/SDP and H.323", draft-
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.
[6] J.Rosenberg and H.Salama, "Usage of TRIP in Gateways for Exporting
Phone Routes",draft-rs-trip-gw-00.txt, IETF, March 2000.
[7] H.Agrawal, R.R.Roy, V.Palawat, "SIP-H.323 Interworking
Requirements", draft-agrawal-roy-palawat-sip-h323-interworking-reqs-
00.txt, IETF, April 2000.
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. 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 (U.P.) - 201 301
INDIA
Tel: +91-575-4544028/4132 Extn: 121
Fax: +91-575-4544014
Email: hemantag@globespan.net
Radhika R. Roy
AT&T
Room C1-2B03
200 Laurel Avenue S.
Middletown,
NJ 07748,
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page 18]
Internet draft SIP-H.323 Interworking Requirements 10 July 2000
USA
Tel: +1-732-4201580
Fax: +1-732-3681195
Email: rrroy@att.com
Vipin Palawat
Opuswave Networks Inc.
1365, Garden Of Gods Road,
Colorado Springs, CO 80907
USA
Tel: +1-719-955-7427
Fax: +1-719-548-8658
Email: vpalawat@opuswave.com
David Wang
Nuera Communications Inc.
10445 Pacific Center Court
San Diego, CA 92121
USA
Tel: +1 858 625 9220 x 1260
Fax: +1 858 625 2422
Email: dwang@nuera.com
Alan Johnston
MCI WorldCom
100 South Fourth Street
St. Louis, MO 63102
USA
Tel: +1 314 342 73 60
Fax: +1 314 342 8452
Email: alan.johnston@wcom.com
Charles Agboh
Global TeleSystem Group
Terhulsesteenweg 6A,
1560 Hoeilaart
Belgium.
Tel: +3 22 658 42 43,
Fax: +3 22 658 51 18
Email: Charles.Agboh@gtsgroup.com
Kundan Singh
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
Email: kns10@cs.columbia.edu
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page 19]
Internet draft SIP-H.323 Interworking Requirements 10 July 2000
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 20]