Internet Engineering Task Force Hemant Agrawal
INTERNET DRAFT GlobeSpan Inc
Radhika R. Roy
Category: Informational AT&T
Expires: Aug, 2001 Vipin Palawat
Cisco Systems 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-02.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 22 Feb 2001
Table of Contents
1. Introduction .............................................. 3
2. Terminology ............................................... 3
3. Definitions ............................................... 3
4. Functionality within the SIP-H.323IWF ..................... 4
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 ............................... 7
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 and
mid-call digit transfer..................................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 ................................................ 17
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 22 Feb 2001
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 [4] 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. Interworking Function (IWF)
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.
3.6. SIP Side
The SIP side of the IWF is the part of the IWF that terminates and
originates SIP signaling from and to the SIP network respectively.
3.7. H.323 Side
The H.323 side of the IWF is the part of the IWF that terminates and
originates H.323 signaling from and to the H.323 network respectively.
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 3]
Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001
4. Functionality within the SIP-H.323 IWF
This section provides the functional requirements of the SIP-H.323 IWF.
SIP-H.323 IWF can be architectured in various ways. This MAY include
coexistence of H.323 Gatekeeper or SIP Server with the IWF. The
co-location of the H.323 GK and/or SIP server with the IWF is a matter
of implementation and not a protocol issue. There SHALL NOT be any
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 NOT be any 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 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 exchange.
d) Opening and closing of media channels.
e) Mapping media algorithms for H.323 and SIP network.
f) Registration of SIP and H.323 entities.
g) Call resource reservation and release.
h) Ability to provide the state of a call.
i) Call state machine.
j) Mid call signal processing.
k) Service interoperability logic.
The conversion of media from one format to another is out of scope.
There SHOULD NOT be 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
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 4]
Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001
that this will be simply switched to another endpoint by a media
switching fabric present in the IWF.
This recommandation is going to use two phases in defining the
SIP-H.323 interworking standard. The first phase will define the basic call
establishment and 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, 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 of IWF with H.323 Gatekeeper
In networks where H.323 gatekeeper is present, the IWF SHOULD register
with a H.323 Gatekeeper to give the information about SIP side extensions.
This information may be any addressing attribute such as transport address,
alias address, email-ID, url-ID, etc.
The IWF MAY register SIP entities in the H.323 network to allow the H.323
Gatekeeper to perform address resolution for the SIP entities. For example,
the IWF may register with the H.323 Gatekeeper on behalf of a SIP user
agent:the registration information sent by the IWF to the H.323 Gatekeeper
would include the IWF RAS and call signaling addresses and the IWF would
bind an H.323 alias address with the SIP user agent sip address.
The IWF MAY update the registration information to the H.323 Gatekeeper.
The mechanisms by which the IWF gets the information about the SIP side
extensions is for further study. The IWF registration with multiple
gatekeepers is also left for further study.
5.2. Registration with SIP Server
In networks where SIP Servers are present, the IWF SHOULD register with
the appropriate SIP server to give the information about H.323 side
extensions. This information may be any addressing attribute such as
transport address, alias address, email-ID, url-ID, etc. Since SIP does
not support a gateway to register it's extensions 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.
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 5]
Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001
The IWF MAY update the registration information to the SIP Server. The
mechanisms by which the IWF gets the information about the H.323 side
extensions is for further study. The IWF registration with multiple SIP
Server is also left for further study.
6. General Interworking Requirements
The IWF SHALL use the H.323 Version 2.0 [5] and SIP Ver 2.0 [2]. The IWF
SHALL 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 of non-default parameters. The default parameters for such setting
should be identified. For example, H.323 [5] and SIP [2], both
specifications have defined many default parameters such as ports,
timers, etc.
b) Release any call related resource on the detection of call deactivation.
SIP Session timers [2] 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 (alias address) and
SIP (URL) 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 or any other database.
b) Use LDAP or X.500 for keeping address resolution information.
c) Use DNS for address resolution.
d) Use TRIP for the SIP side.
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 6]
Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001
6.1.3. Call with H.323 GK
When an H.323 GK is present in the network, the IWF SHOULD:
a) Resolve addresses with the help of H.323 GK.
b) Register itself to forward the addressing information of SIP side
extensions 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 (may be using TRIP [6]) to forward
the addressing information of H.323 side extensions 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 (in fastStart element or using H.245) and SIP (using Session
Description Protocol, SDP [3]). 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 22 Feb 2001
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 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 SHOULD:
a) Not process any media transport data. Processing a media transport
data is not the same as just switching the packets from one UDP port or
another.
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 22 Feb 2001
6.3. Requirements for support of H.245 tunneling
The IWF SHALL support the H.245 tunnelling procedures as described in
H.323v2.
6.4. Requirements for support of pregranted ARQ
The IWF SHOULD support the pre-granted ARQ in support of the GK request.
In this case, the IWF may do the address resolution from H.323 GK using
LRQ/LCF exchange, or using an internal resolution service or some other
external resolution service (standard or proprietary).
6.5. Requirements for support of overlapped sending and mid-call digit
transfer
The IWF SHOULD support both overlap sending and mid-call digit transfer.
The IWF SHOULD support overlap sending using the user part of Request-URI
in SIP and Q.931 Setup, Setup Ack and Information Message in H.323.
The IWF SHOULD support mechanisms allowing out-of-band DTMF signaling or
transport.
H.323 has support for DTMF transfer (userInputIndication), however whether
DTMF SHOULD be carried in SIP message or in RTP stream [9] or both, with
respect to this interworking is for further study.
The IWF MAY support the transfer of digits during a call in SIP by using
INFO[7] or any other proprietary/standard solution. The interworking
between H.245 userInputIndication and SIP INFO method or any other
non-INFO method is for further study.
The support for in-band digit transfer in IWF is out of scope.
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.
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 9]
Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001
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.
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 or media server 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) SHOULD 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.
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 10]
Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001
c) The SIP data fields SHOULD 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.
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 SIP 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 transparent support for all audio
algorithms commonly supported by both ITU and IANA.
8.4.2. The IWF MAY provide transparent 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 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 22 Feb 2001
9. State Machine Requirements
The state machine for IWF will follow the following general guidelines:
9.1. Unexpected messages in a particular state that can change the state
SHOULD 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 Servers, SIP EPs,
H.323 EPs, 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:
11.1. All endpoints trying to use IWF are authorized with the respective
H.323 Gatekeepers or SIP servers if they are present in the network.
This is left for further discussion.
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 12]
Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001
11.2. All endpoints trying to make a call using IWF are respectively
permitted to do so from H.323 Gatekeeper or SIP server if it is present
in the network.
Desired 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
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
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 13]
Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001
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.
Items a, b, 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 addresses in [1].
However, we have addressed the configurations for call scenarios and
the input-output messages of the IWF that provide interworking
between SIP and H.323.
Following are the different configurations for the call scenarios:
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 14]
Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001
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.
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).
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 15]
Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001
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 (without FastStart Element) from H.323 terminal to SIP
terminal using configuration of 13.1 (H.323 FastStart method may also
be used to show the call of same configuration).
H.323 SIP
EP Setup IWF EP
|------------>| INVITE |
| |------------>|
| | 180 RINGING |
| Alerting |<------------|
|<------------| 200 OK |
| Connect |<------------|
|<------------| |
| H.245 | |
|<----------->| ACK |
| |------------>|
| RTP |
|<------------------------->|
ii) Simple calls (without FastStart) 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 |
|<------------------------->|
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 16]
Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001
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."
15. References
[1] Singh/Schulzrinne, "Interworking Between SIP/SDP and H.323", draft-
singh-sip-h323-00.txt,IETF, January 2000. Work in progress.
[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. Work in progress.
[7] S. Donovan, "The SIP INFO Method," RFC 2976, IETF, Oct.2000.
[8] H.Agrawal, R.R.Roy and V.Palawat, "SIP-H.323 Interworking
Requirements", draft-agrawal-roy-palawat-sip-h323-interworking-reqs-
00.txt, IETF, April 2000. Work in progress.
[9] H.Schulzrinne and S. Petrack, "RTP Payload for DTMF Digits, Telephony
Tones and Telephony Signals", RFC 2833, IETF, May 2000.
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 17]
Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001
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 D3-2C09
200 Laurel Avenue S.
Middletown,
NJ 07748,
USA
Tel: 1-732-4201580
Fax: 1-732-3681302
Email: rrroy@att.com
Vipin Palawat
Cisco Systems Inc.
900, Chelmsford Street
Tower II, Floor 14
Cube Number : 1440
Lowell, MA 01851
Tel: 1-978-275-5122
Fax: 1-978-275-5122
Email : vpalawat@cisco.com
David Wang
Nuera Communications Inc.
10445 Pacific Center Court
San Diego, CA 92121
USA
Tel: 1-858-6259220 x 1260
Fax: 1-858-6252422
Email: dwang@nuera.com
[Agrawal,Roy,Palawat,Johnston,Agboh,Wang,Singh and Schulzrinne] [Page 18]
Internet draft SIP-H.323 Interworking Requirements 22 Feb 2001
Alan Johnston
MCI WorldCom
100 South Fourth Street
St. Louis, MO 63102
USA
Tel: 1-314- 3427360
Fax: 1-314-3428452
Email: alan.johnston@wcom.com
Charles Agboh
Ebone
Terhulsesteenweg 6A,
1560 Hoeilaart
Belgium.
Tel: 22-658-4243
Fax: 22-658-5118
Email: Charles.Agboh@ebone.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]