[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 RFC 4123

Internet Engineering Task Force                           Hemant Agrawal
INTERNET DRAFT                                             GlobeSpan Inc
                                                          Radhika R. Roy
Category: Informational                                             AT&T
Expires: July, 2001                                        Vipin Palawat
                                                   Opuswave Networks Inc
                                                           Alan Johnston
                                                            MCI WorldCom
                                                           Charles Agboh
                                                                   Ebone
                                                              David Wang
                                                Nuera Communications Inc
                                                            Kundan Singh
                                                     Henning Schulzrinne
                                                     Columbia University


                   SIP-H.323 Interworking Requirements
             <draft-agrawal-sip-h323-interworking-reqs-01.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 SIP-H.323 Interworking Function (SIP-H.323 IWF) that will allow the
interworking between the SIP(Session Initiation Protocol) and H.323
protocols.








[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 1]


Internet draft       SIP-H.323 Interworking Requirements   10 July 2000


Table of Contents


      1.  Introduction ..............................................  3
      2.  Terminology ...............................................  3
      3.  Definitions ...............................................  3
      4.  Functionality within the SIP-H.323IWF .....................  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 (SIP-H.323 IWF) that will allow  the
interworking between the SIP(Session Initiation Protocol) and H.323
protocols.

2.  Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
are to be interpreted as described in RFC 2119 [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 performs interworking between the H.323 and SIP protocols.

3.3. SIP Server

This can be either SIP Proxy, Redirect or Registrar server.

3.4. EndPoint

An endpoint can call and be called. An endpoint is an entity from which
the media originates or terminates. An endpoint can either be H.323
terminal, H.323 Gateway, H.323 MCU[5] or SIP user agent[2].

3.5. Media switching fabric (MSF)

This is an optional logical entity present in the IWF. If present, it
will perform the task of switching media(voice, video, fax etc.) from
one logical connection to other.

4. Functionality within the SIP-H.323 IWF

This section provides the functional requirements of the SIP-H.323
Interworking function.

SIP-H.323 IWF can be architecture in various ways. This may include
Coexistence of H.323 Gatekeeper or SIP Servers with IWF. The
co-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 assumptions made for the optional elements and components




[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page 3]


Internet draft       SIP-H.323 Interworking Requirements   10 July 2000


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 belongs
to both SIP and H.323 networks.

The introduction of IWF redundancy in the network is left for further
discussion.

Therefore, an IWF may  contain the following functions:

a) Call sequence mapping.

b) Address resolution.

c) Terminal Capability 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 be no processing of the media at IWF. For a call between
SIP  and H.323 network, it is assumed that the same transport protocols
(e.g. RTP, TCP, UDP, etc.) will be used in both H.323 and SIP networks
for carrying media.  In most of the cases, media packets should be
flowing directly between the endpoints. Even if the media from one
endpoint terminates at IWF in special scenario, the assumption is made
that this may be simply switched to another endpoint by a media
switching fabric present in the IWF. The conversion of media from one
format to another is out of scope.

This recommandation is going to use two phases in defining the
interworking standard. The first phase will define the basic call
establishment and termination.





[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page 4]


Internet draft       SIP-H.323 Interworking Requirements   10 July 2000

The second phase will include some optional, advanced features, and
services. Both phases have to meet the general requirements specified
in the following sections.

5.  Pre-Call Requirements

The IWF function may have a table of reference for lookup to resolve the
corresponding H.323 and SIP addresses to IP addresses. This may be
accomplished by using the capabilities of either H.323 Gatekeepers, SIP
servers or any other database. Since H.323 Gatekeeper and SIP Server are
not mandatory components of H.323 and SIP systems respectively, the IWF
function may keep the address resolution information within itself,
which may be updated by using the H.323 Gatekeeper, SIP Server, or any
other database.

5.1.  Registration with H.323 Gatekeeper

This is 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 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 higher version of H.323 and SIP may be used in the second
phase.


The IWF shall provide the seamless interworking of the two protocols. The
functioning of IWF should not involve any modification to the H.323 and
SIP protocols, but may involve specific profiles of these protocols.

6.1. Basic call Requirements

6.1.1. General Requirements

The IWF  should:

a) Provide default settings, so that the transactions will only be for a
change 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 protocols.

b) Register itself to H.323 Gatekeeper and SIP Server if they are present
in the Network.

The IWF may:

a) Have a look-up table for resolving the addresses. This may be updated
from the H.323 GK, SIP server and any other database.

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 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 media transport data.

6.2. Requirements for support of fast connect procedures

The IWF shall support the fast Start element in H.323.






[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page 8]


Internet draft       SIP-H.323 Interworking Requirements   10 July 2000


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 etc) 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.

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.







[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 9]


Internet draft       SIP-H.323 Interworking Requirements   10 July 2000


7.2. Media Transport Requirements

7.2.1 It is assumed that both H.323 and SIP networks use  same transport
protocols (e.g. RTP, TCP, UDP, etc.) for carrying media.  In most of the
cases, media packets should be flowing directly between the endpoints.
If this is not the case, then a media gateway 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 Recommendation
H.225.0 version 2.0 and H.245 version 4.0.









[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page 10]


Internet draft       SIP-H.323 Interworking Requirements   10 July 2000


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 Annex G etc.

12.12 Support for fax(t.38 etc) and other data transfer(t.120 etc)

12.13 Robustness and Stability

12.14 H.323 trunking between SIP networks

12.15 SIP trunking between H.323 networks







[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 under-
standing although all parameters do not exactly match.

c) For a given signaling message of a given protocol, there may not
be a corresponding signaling message of the other protocol that may
appear to be equivalent. The IWF needs to create a mapping between
the signaling messages or generate error messages based on common
understanding of an agreed upon standard.






[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 inter-
operability 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. In particular, we would like to thank Joon
Maeng, Dave Walker and Jean-Francois Mule.  Contributions to this document
have also been made through internet-drafts and discussion with members of
SIP, H.323, aHIT!, TIPHON and SG16 forums.

17.  Authors' addresses

        Hemant Agrawal
        GlobeSpan Inc.
        A-8, Sector 9,
        Noida, UP - 201301
        INDIA
        Tel: 91-120-4544028 x 121
        Fax: 91-120-4544014
        Email: hemantag@globespan.net

        Radhika R. Roy
        AT&T
        Room C1-2B03
        200 Laurel Avenue S.
        Middletown,
        NJ 07748,
        USA
        Tel: 732-4201580
        Fax: 732-3681195
        Email: rrroy@att.com




[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page 18]


Internet draft       SIP-H.323 Interworking Requirements   10 July 2000


        Vipin Palawat
        Opuswave Networks Inc.
        1365, Garden Of Gods Road,
        Colorado Springs, CO 80907
        USA
        Tel: 719-955-7427
        Fax: 719-548-8658
        Email: vpalawat@opuswave.com

        David Wang
        Nuera Communications Inc.
        10445 Pacific Center Court
        San Diego, CA 92121
        USA
        Tel:  858 625 9220 x 1260
        Fax:  858 625 2422
        Email: dwang@nuera.com

        Alan Johnston
        MCI WorldCom
        100 South Fourth Street
        St. Louis, MO 63102
        USA
        Tel:  314 342 73 60
        Fax:  314 342 8452
        Email: alan.johnston@wcom.com

        Charles Agboh
        Ebone
        Terhulsesteenweg 6A,
        1560 Hoeilaart
        Belgium.
        Tel:  22 658 42 43,
        Fax:  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


        Henning Schulzrinne
        Dept. of Computer Science
        Columbia University
        1214 Amsterdam Avenue, MC 0401
        New York, NY 10027
        USA
        Email: schulzrinne@cs.columbia.edu




[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne][Page 19]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/