Skip to main content

Session Initiation Protocol (SIP)-H.323 Interworking Requirements
draft-agrawal-sip-h323-interworking-reqs-07

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4123.
Authors Charles Agboh , Henning Schulzrinne
Last updated 2015-10-14 (Latest revision 2004-10-20)
RFC stream Independent Submission
Intended RFC status Informational
Formats
Stream ISE state (None)
Consensus boilerplate Unknown
Document shepherd (None)
IESG IESG state Became RFC 4123 (Informational)
Action Holders
(None)
Telechat date (None)
Responsible AD Jon Peterson
Send notices to (None)
draft-agrawal-sip-h323-interworking-reqs-07
Network Working Group                                     H. Schulzrinne
Internet-Draft                                               Columbia U.
Expires: April 18, 2005                                         C. Agboh
                                                                Motorola
                                                        October 18, 2004

   Session Initiation Protocol (SIP)-H.323 Interworking Requirements
              draft-agrawal-sip-h323-interworking-reqs-07

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 18, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document describes the requirements for the logical entity known
   as the Session Initiation Protocol (SIP)-H.323 Interworking Function
   (SIP-H.323 IWF) that will allow the interworking between SIP and
   H.323.

Schulzrinne & Agboh      Expires April 18, 2005                 [Page 1]
Internet-Draft               SIP-H.323 Req.                 October 2004

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Definitions  . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.   Functionality within the SIP-H.323 IWF . . . . . . . . . . .   6
   5.   Pre-Call Requirements  . . . . . . . . . . . . . . . . . . .   7
     5.1  Registration with H.323 Gatekeeper . . . . . . . . . . . .   7
     5.2  Registration with SIP Server . . . . . . . . . . . . . . .   7
   6.   General Interworking Requirements  . . . . . . . . . . . . .   8
     6.1  Basic Call Requirements  . . . . . . . . . . . . . . . . .   8
       6.1.1  General Requirements . . . . . . . . . . . . . . . . .   8
       6.1.2  Address Resolution . . . . . . . . . . . . . . . . . .   8
       6.1.3  Call with H.323 Gatekeeper . . . . . . . . . . . . . .   8
       6.1.4  Call with SIP Registrar  . . . . . . . . . . . . . . .   8
       6.1.5  Capability Negotiation . . . . . . . . . . . . . . . .   8
       6.1.6  Opening of Logical Channels  . . . . . . . . . . . . .   9
     6.2  IWF H.323 Features . . . . . . . . . . . . . . . . . . . .   9
     6.3  Overlapped Sending . . . . . . . . . . . . . . . . . . . .   9
       6.3.1  DTMF Support . . . . . . . . . . . . . . . . . . . . .  10
   7.   Transport  . . . . . . . . . . . . . . . . . . . . . . . . .  11
   8.   Mapping between SIP and H.323  . . . . . . . . . . . . . . .  12
     8.1  General Requirements . . . . . . . . . . . . . . . . . . .  12
     8.2  H.225.0 and SIP Call Signaling . . . . . . . . . . . . . .  12
     8.3  Call Sequence  . . . . . . . . . . . . . . . . . . . . . .  12
     8.4  State Machine Requirements . . . . . . . . . . . . . . . .  12
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  14
   10.  Examples and Scenarios . . . . . . . . . . . . . . . . . . .  15
     10.1   Introduction . . . . . . . . . . . . . . . . . . . . . .  15
     10.2   IWF Configurations . . . . . . . . . . . . . . . . . . .  15
     10.3   Call Flows . . . . . . . . . . . . . . . . . . . . . . .  15
       10.3.1   Call from H.323 Terminal to SIP UA . . . . . . . . .  16
       10.3.2   Call from SIP UA to H.323 Terminal . . . . . . . . .  16
   11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  17
   12.  Contributors . . . . . . . . . . . . . . . . . . . . . . . .  18
   13.  References . . . . . . . . . . . . . . . . . . . . . . . . .  20
   13.1   Normative References . . . . . . . . . . . . . . . . . . .  20
   13.2   Informative References . . . . . . . . . . . . . . . . . .  20
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  21
        Intellectual Property and Copyright Statements . . . . . . .  22

Schulzrinne & Agboh      Expires April 18, 2005                 [Page 2]
Internet-Draft               SIP-H.323 Req.                 October 2004

1.  Introduction

   The SIP-H.323 Interworking function (IWF) converts between SIP
   (Session Initiation Protocol) [RFC3261] and the ITU Recommendation
   H.323 protocol [H.323].  This document describes requirements for
   this protocol conversion.

Schulzrinne & Agboh      Expires April 18, 2005                 [Page 3]
Internet-Draft               SIP-H.323 Req.                 October 2004

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 BCP 14, RFC 2119
   [RFC2119] and indicate requirement levels for compliant
   implementations.

Schulzrinne & Agboh      Expires April 18, 2005                 [Page 4]
Internet-Draft               SIP-H.323 Req.                 October 2004

3.  Definitions

   H.323 gatekeeper (GK): An H.323 gatekeeper is an optional component
      in an H.323 network.  If it is present, it performs address
      translation, bandwidth control, admission control and zone
      management.
   H.323 network: In this document, we refer to the collection of all
      H.323-speaking components as the H.323 network.
   SIP network: In this document, we refer to the collection of all SIP
      servers and user agents as the SIP network.
   Interworking Function (IWF): The Interworking Function (IWF) performs
      interworking between H.323 and SIP.  It belongs to both the H.323
      and SIP networks.
   SIP server: A SIP server can be either a SIP proxy, redirect server,
      or registrar server.
   Endpoint: An endpoint can call and be called.  An endpoint is an
      entity from which the media such as voice, video or fax originates
      or terminates.  An endpoint can be H.323 terminal, H.323 Gateway,
      H.323 MCU [H.323] or SIP user agent (UA) [RFC3261].
   Media Switching Fabric (MSF): The Media Switching Fabric (MSF) is an
      optional logical entity within the IWF.  The MSF switches media
      such as voice, video or fax from one network association to
      another.

Schulzrinne & Agboh      Expires April 18, 2005                 [Page 5]
Internet-Draft               SIP-H.323 Req.                 October 2004

4.  Functionality within the SIP-H.323 IWF

   This section summarizes the functional requirements of the SIP-H.323
   interworking function (IWF).

   A SIP-H.323 IWF MAY be integrated into an H.323 gatekeeper or SIP
   server.  Interworking SHOULD NOT require any optional components in
   either the SIP or H.323 network, such as H.323 gatekeepers.  IWF
   redundancy in the network is beyond the scope of this document.

   An IWF contain functions from the following list, inter alia:

   o  Mapping of the call setup and teardown sequences;
   o  Registering H.323 and SIP endpoints with SIP registrars and H.323
      gatekeepers;
   o  Resolving H.323 and SIP addresses;
   o  Maintaining the H.323 and SIP state machines;
   o  Negotiating terminal capabilities;
   o  Opening and closing media channels;
   o  Mapping media coding algorithms for H.323 and SIP networks;
   o  Reserving and releasing call-related resources;
   o  Processing of mid-call signaling messages;
   o  Handling of services and features.

   The IWF SHOULD NOT process media.  We assume that the same media
   transport protocols, such as RTP, are used in both the SIP and H.323
   network.  Thus, media packets are exchanged directly between the
   endpoints.  If a particular service requires the IWF to handle media,
   we assume that the IWF simply forwards media packets without
   modification from one network to the other, using a media switching
   fabric (MSF).  The conversion of media from one encoding or format to
   another is out of scope for SIP-H.323 protocol translation.

Schulzrinne & Agboh      Expires April 18, 2005                 [Page 6]
Internet-Draft               SIP-H.323 Req.                 October 2004

5.  Pre-Call Requirements

   The IWF function MAY use a translation table to resolve the H.323 and
   SIP addresses to IP addresses.  This translation table can be updated
   by using a H.323 gatekeeper, SIP proxy server or a locally-maintained
   database.

5.1  Registration with H.323 Gatekeeper

   An IWF MAY provide and update the H.323 gatekeeper with the addresses
   of SIP UAs.  A SIP user agent can make itself known to the H.323
   network by registering with an IWF serving as a registrar.  The IWF
   creates an H.323 alias address and registers this alias together with
   its own network address with the appropriate GK.

   The gatekeeper can then use this information to route calls to SIP
   UAs via the IWF, without being aware that the endpoint is not a
   "native" H.323 endpoint.

   The IWF can register SIP UAs with one or more H.323 gatekeepers.

5.2  Registration with SIP Server

   The IWF can provide information about H.323 endpoints to a SIP
   registrar.  This allows the SIP proxy using this SIP registrar to
   direct calls to the H.323 end points via the IWF.

   The IWF can easily obtain information about H.323 endpoints if it
   also serves as a gatekeeper.  Other architectures require further
   study.

   If the H.323 endpoints are known through E.164 (telephone number)
   addresses, the IWF can use IGREP [I-D.ietf-iptel-tgrep] or SLP
   [I-D.zhao-iptel-gwloc-slp] to inform the SIP proxy server of these
   endpoints.

   The IWF only needs to register with multiple SIP registrars if the
   H.323 terminal is to appear under multiple, different
   addresses-of-record.

Schulzrinne & Agboh      Expires April 18, 2005                 [Page 7]
Internet-Draft               SIP-H.323 Req.                 October 2004

6.  General Interworking Requirements

   The IWF SHOULD use H.323 Version 2 or later and SIP according to RFC
   3261 [RFC3261].  The protocol translation function MUST NOT require
   modifications or additions to either H.323 or SIP.  However, it may
   not be possible to support certain features of each protocol across
   the IWF.

6.1  Basic Call Requirements

6.1.1  General Requirements

   The IWF SHOULD provide default settings for translation parameters.
   The IWF specification MUST identify these defaults.

   The IWF MUST release any call-related resource at the end of a call.
   SIP session timers [I-D.ietf-sip-session-timer] MAY be used on the
   SIP side.

6.1.2  Address Resolution

   The IWF SHOULD support all the addressing schemes in H.323, including
   the H.323 URI [RFC3508], and the "sip", "sips" and "tel" URI schemes
   in SIP.  It SHOULD support the DNS-based SIP server location
   mechanisms described in [RFC3263] and H.323 Annex O, which details
   how H.323 uses DNS and, in particular, DNS SRV records.

   The IWF SHOULD register with the H.323 Gatekeeper and the SIP
   registrar when available.

   The IWF MAY use any means to translate between SIP and H.323
   addresses.  Examples include translation tables populated by the
   gatekeeper, SIP registrar or other database, LDAP, DNS or TRIP.

6.1.3  Call with H.323 Gatekeeper

   When an H.323 GK is present in the network, the IWF SHOULD resolve
   addresses with the help of the GK.

6.1.4  Call with SIP Registrar

   The IWF applies normal SIP call routing and does not need to be aware
   whether there is a proxy server or not.

6.1.5  Capability Negotiation

   The IWF SHOULD NOT make any assumptions about the capabilities of
   either the SIP user agent or the H.323 terminal.  However, it MAY

Schulzrinne & Agboh      Expires April 18, 2005                 [Page 8]
Internet-Draft               SIP-H.323 Req.                 October 2004

   indicate a guaranteed-to-be-supported list of codecs of the H.323
   terminal or SIP user agent before exchanging capabilities with H.323
   (using H.245) and SIP (using SDP [RFC2327]).  H.323 defines mandatory
   capabilities, SIP currently does not.  For example, the G.711 audio
   codec is mandatory for higher bandwidth H.323 networks.

   The IWF SHOULD attempt to map the capability descriptors of H.323 and
   SDP in the best possible fashion.  The algorithm for finding the best
   mapping between H.245 capability descriptors and the corresponding
   SDP is left for further study.

   The IWF SHOULD be able to map the common audio, video and application
   format names supported in H.323 to and from the equivalent RTP/AVP
   [RFC3550] names.

   The IWF MAY use the SIP OPTIONS message to derive SIP UA
   capabilities.  It MAY support mid-call renegotiation of media
   capabilities.

6.1.6  Opening of Logical Channels

   The IWF SHOULD support the seamless exchange of messages for opening,
   reopening, changing and closing of media channels during a call.  The
   procedures for opening, reopening, closing, and changing the existing
   media sessions during a call are for further study.

   The IWF SHOULD open media channels between the endpoints whenever
   possible.  If this is not possible, then the channel can be opened at
   the MSF of the IWF.

   The IWF SHOULD support unidirectional, symmetric bi-directional, and
   asymmetric bi-directional opening of channels.

   The IWF MAY respond to the mode request, to the request for reopening
   and changing an existing logical channel and MAY support the flow
   control mechanism in H.323.

6.2  IWF H.323 Features

   The IWF SHOULD support Fast Connect, i.e., H.245 tunneling in H.323
   Setup messages.  If IWF and GK are the same device, pre-granted ARQ
   SHOULD be supported.  If pre-granted ARQ is supported, the IWF MAY
   perform the address resolution from H.323 GK using the LRQ/LCF
   exchange.

6.3  Overlapped Sending

   An IWF SHOULD follow the recommendations outlined in

Schulzrinne & Agboh      Expires April 18, 2005                 [Page 9]
Internet-Draft               SIP-H.323 Req.                 October 2004

   [I-D.ietf-sipping-overlap] when receiving overlapped digits from the
   H.323 side.  If the IWF receives overlapped dialed digits from the
   SIP network, it MAY use the Q.931 Setup, Setup Ack and Information
   Message in H.323.

   The IWF MAY support the transfer of digits during a call by using the
   appropriate SIP mechanism and UserInputIndication in H.245 (H.323).

6.3.1  DTMF Support

   An IWF SHOULD support the mapping between DTMF and possibly other
   telephony tones carried in signaling messages.

Schulzrinne & Agboh      Expires April 18, 2005                [Page 10]
Internet-Draft               SIP-H.323 Req.                 October 2004

7.  Transport

   The H.323 and SIP systems do not have to be in close proximity.  The
   IP networks hosting the H.323 and SIP systems do not need to assure
   quality-of-service (QOS).  In particular, the IWF SHOULD NOT assume
   that signaling messages have priority over packets from other
   applications.  H.323 signaling over UDP (H.323 Annex E) is optional.

Schulzrinne & Agboh      Expires April 18, 2005                [Page 11]
Internet-Draft               SIP-H.323 Req.                 October 2004

8.  Mapping between SIP and H.323

8.1  General Requirements

   o  The call message sequence of both protocols MUST be maintained.
   o  The IWF MUST NOT set up or tear down calls on its own.
   o  Signaling messages that do not have a match for the destination
      protocol SHOULD be terminated on the IWF, with the IWF taking the
      appropriate action for them.  For example, SIP allows a SIP UA to
      silently discard an ACK request for a non-existent call leg.
   o  If the IWF is required to generate a message on its own, IWF
      SHOULD use pre-configured default values for the message
      parameters.
   o  The information elements and header fields of the respective
      messages are to be converted as follows:
      *  The contents of connection-specific information elements, such
         as Call Reference Value for H.323, is converted to similar
         information required by SIP or SDP such as the SDP session ID
         and the SIP 'Call-ID'.
      *  The IWF generates protocol elements that are not available from
         the other side.

8.2  H.225.0 and SIP Call Signaling

   o  The IWF MUST conform to the call signaling procedures recommended
      for the SIP side regardless of the behavior of the H.323 elements.
   o  The IWF MUST conform to the call signaling procedures recommended
      for the H.323 side regardless of the behavior of the SIP elements.
   o  The IWF serves as the endpoint for the Q.931 Call Signaling
      Channel to either an H.323 endpoint or H.323 Gatekeeper (in case
      of GK routed signaling).  The IWF also acts as a SIP user agent
      client and server.
   o  The IWF also establishes a RAS Channel to the H.323 GK, if
      available.
   o  The IWF SHOULD process messages for H.323 supplementary services
      (FACILITY, NOTIFY, and the INFORMATION messages) only if the
      service itself is supported.

8.3  Call Sequence

   The call sequence on both sides SHOULD be maintained in such a way
   that neither H.323 terminal nor SIP UA is aware of presence of the
   IWF.

8.4  State Machine Requirements

   The state machine for IWF will follow the following general
   guidelines:

Schulzrinne & Agboh      Expires April 18, 2005                [Page 12]
Internet-Draft               SIP-H.323 Req.                 October 2004

   o  Unexpected messages in a particular state shall be treated as
      "error" messages.
   o  All messages which do not change the state shall be treated as
      "non-triggering" or informational messages.
   o  All messages which expect a change in state shall be treated as
      "triggering" messages.

   For each state, an IWF specification MUST classify all possible
   protocol messages into the above three categories.  It MUST specify
   the actions taken on the content of the message and the resulting
   state.  Below, is an example of such a table:

   State: Idle

   Possible Messages   Message Category   Action         Next state
   -------------------------------------------------------------------
   All RAS msg.        Triggering         Add Reg.Info.  WaitForSetup
   All H.245 msg.      Error              Send 4xx       Idle
   SIP OPTIONS         Non Triggering     Return cap.    Idle
   SIP INVITE          Triggering         Send SETUP     WaitForConnect

Schulzrinne & Agboh      Expires April 18, 2005                [Page 13]
Internet-Draft               SIP-H.323 Req.                 October 2004

9.  Security Considerations

   Since the IWF whose requirements have been described in this document
   combines both SIP and H.323 functionality, security considerations
   for both of these protocols apply.

   The eventual security solution for interworking MUST rely on the
   standard mechanisms in RFC3261 [RFC3261] and H.323, without extending
   them for the interworking function.  Signaling security for H.323 is
   described in H.235 [H.235].

   Since all data elements in SIP or H.323 have to terminate at the IWF,
   the resulting security cannot be expected to be end-to-end.  Thus,
   the IWF terminates not only the signalling protocols but also the
   security in each domain.  Thus, users at the SIP or H.323 endpoint
   have to trust the IWF, like any other gateway, to authenticate the
   other side correctly.  Similarly, they have to trust the gateway to
   respect integrity of data elements and to apply appropriate security
   mechanisms on the other side of the IWF.

   The IWF MUST NOT indicate that a user on one side has achieved a
   certain level of trust without the ability to verify that.  For
   example, if the SIP user was not authenticated, it would be
   inappropriate to use mechanisms on the H.323 side, such as H.323
   Annex D, that indicated that the user identity had been
   authenticated.

   An IWF MUST NOT accept 'sips' requests unless it can guarantee that
   the H.323 side use equivalent H.235 [H.235] security mechanisms.
   Similarly, the IWF MUST NOT accept H.235 sessions unless it succeeds
   in using SIP-over-TLS (sips) on the SIP side of the IWF.

Schulzrinne & Agboh      Expires April 18, 2005                [Page 14]
Internet-Draft               SIP-H.323 Req.                 October 2004

10.  Examples and Scenarios

10.1  Introduction

   We present some examples of call scenarios that will show the
   signaling messages received and transmitted.  The following
   situations can occur:

   o  Some signaling messages can be translated one-to-one.
   o  In some cases, parameters on one side do not match those on the
      other side.
   o  Some signaling messages do not have an equivalent message on the
      other side.  In some cases, the IWF can gather further information
      and the signal on the other side.  In some cases, only an error
      indication can be provided.

10.2  IWF Configurations

   Below are some common architectures involving an IWF:

   Basic Configuration: H.323 EP  -- IWF -- SIP UA
   Calls using H.323 GK: H.323 EP -- H.323 GK -- IWF -- SIP UA
   Calls using SIP proxies: H.323 EP -- IWF -- SIP proxies -- SIP UA
   Calls using both H.323 GK and SIP proxy: H.323 EP -- H.323 GK -- IWF
      -- SIP proxies -- SIP UA
   SIP trunking between H.323 networks: H.323 EP -- IWF -- SIP network
      -- IWF -- H.323 EP
   H.323 trunking between SIP networks: SIP EP -- IWF -- H.323 network
      -- IWF -- SIP UA

10.3  Call Flows

   Some call flow examples for two different configurations and call
   scenarios are given below.

Schulzrinne & Agboh      Expires April 18, 2005                [Page 15]
Internet-Draft               SIP-H.323 Req.                 October 2004

10.3.1  Call from H.323 Terminal to SIP UA

        H.323                        SIP
         EP    Setup   IWF           UA
          |------------>|    INVITE   |
          |             |------------>|
          |             | 180 RINGING |
          |   Alerting  |<------------|
          |<------------|   200 OK    |
          |  Connect    |<------------|
          |<------------|             |
          |   H.245     |             |
          |<----------->|    ACK      |
          |             |------------>|
          |            RTP            |
          |<.........................>|

10.3.2  Call from SIP UA to H.323 Terminal

      SIP                        H.323
       UA           IWF            EP
       |             |             |
       |   INVITE    |             |
       |------------>|   Setup     |
       |             |------------>|
       |             |  Alerting   |
       | 180 RINGING |<------------|
       |<------------|   Connect   |
       |             |<------------|
       |             |    H.245    |
       |     200 OK  |<----------->|
       |<------------|             |
       |     ACK     |             |
       |------------>|             |
       |            RTP            |
       |<.........................>|

Schulzrinne & Agboh      Expires April 18, 2005                [Page 16]
Internet-Draft               SIP-H.323 Req.                 October 2004

11.  Acknowledgments

   The authors would like to acknowledge the many contributors who
   discussed the SIP-H.323 interworking architecture and requirements on
   the IETF, SIP and SG16 mailing lists.  In particular, we would like
   to thank Joon Maeng, Dave Walker and Jean-Francois Mule.
   Contributions to this document have also been made by members of the
   H.323, aHIT!, TIPHON and SG16 forums.

Schulzrinne & Agboh      Expires April 18, 2005                [Page 17]
Internet-Draft               SIP-H.323 Req.                 October 2004

12.  Contributors

   In addition to the editors, the following people provided substantial
   technical and writing contributions to this document, listed
   alphabetically:

   Hemant Agrawal
   Telverse Communications
   1010 Stewart Drive
   Sunnyale, CA 94085
   USA
   hagrawal@telverse.com

   Alan Johnston
   MCI WorldCom
   100 South Fourth Street
   St. Louis, MO 63102
   USA
   alan.johnston@wcom.com

   Vipin Palawat
   Cisco Systems Inc.
   900 Chelmsford Street
   Lowell, MA  01851
   USA
   vpalawat@cisco.com

   Radhika R. Roy
   AT&T
   Room C1-2B03
   200 Laurel Avenue S.
   Middletown, NJ 07748
   USA
   rrroy@att.com

   Kundan Singh
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY 10027
   USA
   kns10@cs.columbia.edu

Schulzrinne & Agboh      Expires April 18, 2005                [Page 18]
Internet-Draft               SIP-H.323 Req.                 October 2004

   David Wang
   Nuera Communications Inc.
   10445 Pacific Center Court
   San Diego, CA 92121
   USA
   dwang@nuera.com

Schulzrinne & Agboh      Expires April 18, 2005                [Page 19]
Internet-Draft               SIP-H.323 Req.                 October 2004

13.  References

13.1  Normative References

   [H.235]    International Telecommunication Union, "Security and
              encryption for H-Series (H.323 and other H.245-based)
              multimedia terminals", Recommendation H.235, February
              1998.

   [H.323]    International Telecommunication Union, "Packet based
              multimedia communication systems", Recommendation H.323,
              July 2003.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2327]  Handley, M. and V. Jacobson, "SDP: Session Description
              Protocol", RFC 2327, April 1998.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M. and E. Schooler,
              "SIP: Session Initiation Protocol", RFC 3261, June 2002.

   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263, June
              2002.

   [RFC3508]  Levin, O., "H.323 Uniform Resource Locator (URL) Scheme
              Registration", RFC 3508, April 2003.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R. and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

13.2  Informative References

   [I-D.ietf-iptel-tgrep]
              Bangalore, M., "A Telephony Gateway REgistration Protocol
              (TGREP)", draft-ietf-iptel-tgrep-03 (work in progress),
              March 2004.

   [I-D.ietf-sip-session-timer]
              Donovan, S. and J. Rosenberg, "Session Timers in the
              Session Initiation Protocol (SIP)",
              draft-ietf-sip-session-timer-15 (work in progress), August
              2004.

   [I-D.ietf-sipping-overlap]

Schulzrinne & Agboh      Expires April 18, 2005                [Page 20]
Internet-Draft               SIP-H.323 Req.                 October 2004

              Camarillo, G., "Mapping of ISUP Overlap Signalling to the
              Session Initiation Protocol",
              draft-ietf-sipping-overlap-03 (work in progress), August
              2002.

   [I-D.levin-iptel-h323-url-scheme]
              Levin, O., "H.323 URL scheme definition",
              draft-levin-iptel-h323-url-scheme-04 (work in progress),
              November 2001.

   [I-D.zhao-iptel-gwloc-slp]
              Zhao, W. and H. Schulzrinne, "Locating IP-to-Public
              Switched Telephone Network (PSTN) Telephony Gateways  via
              SLP", draft-zhao-iptel-gwloc-slp-06 (work in progress),
              February 2004.

Authors' Addresses

   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027
   US

   Phone: +1 212 939 7042
   EMail: hgs@cs.columbia.edu
   URI:   http://www.cs.columbia.edu

   Charles Agboh
   Viables Industrial Estate
   Basingstoke, UK  RG22 4PD
   UK

   EMail: cagboh1@motorola.com

Schulzrinne & Agboh      Expires April 18, 2005                [Page 21]
Internet-Draft               SIP-H.323 Req.                 October 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), 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 FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Schulzrinne & Agboh      Expires April 18, 2005                [Page 22]