\documentclass[11pt]{article}
\usepackage{times}
\usepackage{graphics}
\usepackage{ifthen}
\usepackage{i-d}
\usepackage{html}
\usepackage{txtpsfig}
\usepackage{tight}
\usepackage{html}
\usepackage[dvips]{changebar}
\usepackage{multibib}
\newcites{norm,inform}{Normative References,Informative References}

\title{Session Initiation Protocol (SIP)-H.323 Interworking Requirements}
\author{H. Schulzrinne, C. Agboh (ed.)}
\shorttitle{SIP-H.323 Requirements}
\filename{draft-agrawal-sip-h323-interworking-reqs-05}
\wg{Network Working Group}
\expires{December 2003}
\address{Columbia U., KPNQwest}
\pubdate{\today}
\input{../defs}

\begin{document}
\maketitle
\begin{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.
\end{abstract}
\tableofcontents

\section{Introduction}

The SIP-H.323 Interworking function (IWF) converts between SIP (Session
Initiation Protocol) \citenorm{rfc3261} and the ITU Recommendation H.323
protocol \citenorm{H.323}.  This document describes requirements for
this protocol conversion.

\section{Terminology}

The key words ``{\MUST}'', ``{\MUSTNOT}'', ``{\REQUIRED}'',
``{\SHALL}'', ``{\SHALLNOT}'', ``{\SHOULD}'', ``{\SHOULDNOT}'',
``{\RECOMMENDED}'', ``{\MAY}'', and ``{\OPTIONAL}'' in this document are
to be interpreted as described in RFC 2119 \citenorm{rfc2119}.

\section{Definitions}

\begin{description}
\item[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.

\item[H.323 network:] In this document, we refer to the collection of
all H.323-speaking components as the H.323 network.

\item[SIP network:] In this document, we refer to the collection of all
SIP servers and user agents as the SIP network.

\item[Interworking Function (IWF):] The Interworking Function (IWF)
performs interworking between H.323 and SIP. It belongs to both the
H.323 and SIP networks.

\item[SIP server:] A SIP server can be either a SIP proxy, redirect
server, or registrar server.

\item[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
\citenorm{H.323} or SIP user agent (UA) \citenorm{rfc3261}.

\item[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.

\end{description}

\section{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 {\SHOULDNOT} 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: 

\begin{itemize}
\item Mapping of the call setup and teardown sequences;

\item Registering H.323 and SIP endpoints with SIP registrars and H.323
gatekeepers;

\item Resolving H.323 and SIP addresses;

\item Maintaining the H.323 and SIP state machines;

\item Negotiating terminal capabilities;

\item Opening and closing media channels;

\item Mapping media coding algorithms for H.323 and SIP networks;

\item Reserving and releasing call-related resources;

\item Processing of mid-call signaling messages;

\item Handling of services and features.
\end{itemize}

The IWF {\SHOULDNOT} 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.

\section{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.

\subsection{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.

\subsection{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 \citeinform{draft-ietf-iptel-tgrep} or
SLP \citeinform{draft-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.

\section{General Interworking Requirements}

The IWF {\SHOULD} use H.323 Version 2 or later and SIP according to RFC
3261 \citenorm{rfc3261}.  The protocol translation function {\MUSTNOT}
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.

\subsection{Basic Call Requirements}

\subsubsection{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 \citeinform{draft-ietf-sip-session-timer} {\MAY} be
used on the SIP side.

\subsubsection{Address Resolution}

The IWF {\SHOULD} support all the addressing schemes in H.323, including
the H.323 URI \citenorm{draft-levin-iptel-h323-url-scheme}, and the
``sip'', ``sips'' and ``tel'' URI schemes in SIP.  It {\SHOULD} support
the DNS-based SIP server location mechanisms described in
\citenorm{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.

\subsubsection{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. 

\subsubsection{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. 

\subsubsection{Capability Negotiation}

The IWF {\SHOULDNOT} make any assumptions about the capabilities of
either the SIP user agent or the H.323 terminal.  However, it {\MAY}
indicate a guaranteed-to-be-supported list of codecs of the H.323
terminal or SIP user agent before exchanging capabilities with H.323
(using H.245) and SIP (using SDP \citenorm{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
\citenorm{rfc1890} names.

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

\subsubsection{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.

\subsection{IWF H.323 Features}

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

%INSTEAD The IWF should support Fast Connect and H.245 Tunnelling.  The IWF may support Extended Fast Connect, as defined in ITU-T Recommendation H.460.6.  When Fast Connect and Extended Fast Connect are not utilized, the IWF should exchange H.245 capabilities and perform logical channel signaling with the H.323 entity prior to tranmitting a CONNECT to the H.323 entity or 200 message to the SIP entity.

\subsection{Overlapped Sending}

An IWF {\SHOULD} follow the recommendations outlined in
\citeinform{draft-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).

\section{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 {\SHOULDNOT} assume
that signaling messages have priority over packets from other
applications.  H.323 signaling over UDP (H.323 Annex E) is optional.

\section{Mapping between SIP and H.323}

\subsection{General Requirements}

\begin{itemize}
\item The call message sequence of both protocols {\MUST} be maintained.

\item The IWF {\MUSTNOT} set up or tear down calls on its own.

\item 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. 

\item If the IWF is required to generate a message on its own, IWF
{\SHOULD} use pre-configured default values for the message parameters.

\item The information elements and header fields of the respective
messages are to be converted as follows:

\begin{itemize}
\item 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
\header{Call-ID}.

\item The IWF generates protocol elements that are not available from
the other side.

\end{itemize}
\end{itemize}

\subsection{H.225.0 and SIP Call Signaling}

\begin{itemize}
\item The IWF {\MUST} conform to the call signaling procedures
recommended for the SIP side regardless of the behavior of the H.323
elements.

\item The IWF {\MUST} conform to the call signaling procedures
recommended for the H.323 side regardless of the behavior of the SIP
elements.

\item 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.

\item The IWF also establishes a RAS Channel to the H.323 GK, if
available.

\item The IWF {\SHOULD} process messages for H.323 supplementary
services (FACILITY, NOTIFY, and the INFORMATION messages) only if the
service itself is supported.

\end{itemize}

\subsection{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. 

\subsection{State Machine Requirements}

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

\begin{itemize}
\item Unexpected messages in a particular state shall be treated as
``error'' messages.

\item All messages which do not change the state shall be treated as
``non-triggering'' or informational messages.

\item All messages which expect a change in state shall be treated as 
``triggering'' messages.
\end{itemize}

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:

\begin{verbatim}
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
\end{verbatim}

\section{Security Considerations}

The IWF {\SHOULD} use normal H.323 and SIP security mechanisms.

The IWF {\MUST} implement procedures to avoid becoming the source of
denial-of-service attacks.

\section{Examples and Scenarios}

\subsection{Introduction}

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

\begin{itemize}
\item Some signaling messages can be translated one-to-one.

\item In some cases, parameters on one side do not match those on the
other side. 

\item 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.

\end{itemize}

\subsection{IWF Configurations}

Below are some common architectures involving an IWF:

\begin{description}
\item[Basic Configuration:] H.323 EP  -- IWF -- SIP UA

\item[Calls using H.323 GK:] H.323 EP -- H.323 GK -- IWF -- SIP UA

\item[Calls using SIP proxies:] H.323 EP -- IWF -- SIP proxies -- SIP UA

\item[Calls using both H.323 GK and SIP proxy:]
H.323 EP -- H.323 GK -- IWF -- SIP proxies -- SIP UA

\item[SIP trunking between H.323 networks:]
H.323 EP -- IWF -- SIP network -- IWF -- H.323 EP

\item[H.323 trunking between SIP networks:]
SIP EP -- IWF -- H.323 network -- IWF -- SIP UA

\end{description}

\subsection{Call Scenarios}

Some possible call scenarios for the above configurations are:

\begin{itemize}
\item Simple call from H.323 terminal to SIP UA;

\item Call from H.323 terminal to SIP UA using H.245 tunneling;

\item Call from H.323 terminal to SIP UA using early H.245;

\item Call from H.323 terminal to SIP terminal using H.323 fast connect
procedure;

\item Call from H.323 terminal to SIP terminal using overlapped sending;

\item Call from H.323 terminal to SIP terminal using pre-granted ARQ (for 
configurations having a H.323 GK);

\item Simple call from SIP UA to H.323 terminal;

\item Call from SIP UA to H.323 terminal using H.245 tunneling.

\item Call from SIP UA to H.323 terminal using early H.245;

\item Call from SIP UA to H.323 terminal using H.323 fast connect procedure;

\item Call from SIP UA to H.323 terminal using overlapped sending;

\item Call from SIP UA to H.323 terminal using pre-granted ARQ (for 
configuration having H.323 GK);

\item Call from SIP UA to SIP UA using H.323 trunking between
two IWFs;

\item Call from a H.323 terminal to another H.323 terminal using SIP
trunking between two IWFs.

\end{itemize}

\subsection{Call Flows}

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

\subsubsection{Call from H.323 Terminal to SIP UA}

\begin{verbatim}
     H.323                        SIP
      EP    Setup   IWF           UA
       |------------>|    INVITE   |
       |             |------------>|
       |             | 180 RINGING |
       |   Alerting  |<------------|
       |<------------|   200 OK    |
       |  Connect    |<------------|
       |<------------|             |
       |   H.245     |             |
       |<----------->|    ACK      |
       |             |------------>|
       |            RTP            |
       |<.........................>|
\end{verbatim}

\subsubsection{Call from SIP UA to H.323 Terminal}

\begin{verbatim}
   SIP                        H.323
    UA           IWF            EP
    |             |             |
    |   INVITE    |             |
    |------------>|   Setup     |
    |             |------------>|
    |             |  Alerting   |
    | 180 RINGING |<------------|
    |<------------|   Connect   |
    |             |<------------|
    |             |    H.245    |        
    |     200 OK  |<----------->|
    |<------------|             |
    |     ACK     |             |
    |------------>|             |    
    |            RTP            |
    |<.........................>|
\end{verbatim}

\bibliographystylenorm{ieeetr_url}
\bibliographynorm{string,rfc,itu,i-d}
\bibliographystyleinform{ieeetr_url}
\bibliographyinform{string,rfc,i-d,itu,ansi}

\section{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.

\section{Contributors and Editor Addresses}

The following people provided substantial technical and writing
contributions to this document, listed alphabetically:

\begin{flushleft}
Charles Agboh\\
Belgium\\
Email: \textsf{charles@nero.netwalk.org,cagboh@yahoo.com}
\end{flushleft}

\begin{flushleft}
Hemant Agrawal\\
Telverse Communications\\
1010 Stewart Drive\\
Sunnyale, CA 94085\\
USA\\
Email: \textsf{hagrawal@telverse.com}
\end{flushleft}

\begin{flushleft}
Alan Johnston\\
MCI WorldCom\\
100 South Fourth Street\\
St. Louis, MO 63102\\
USA\\
Email: \textsf{alan.johnston@wcom.com}
\end{flushleft}

\begin{flushleft}
Vipin Palawat\\
Cisco Systems Inc.\\
900 Chelmsford Street\\
Lowell, MA  01851\\
USA\\
Email: \textsf{vpalawat@cisco.com}
\end{flushleft}

\begin{flushleft}
Radhika R. Roy\\
AT\&T\\
Room C1-2B03\\
200 Laurel Avenue S.\\
Middletown, NJ 07748\\
USA\\
Email: \textsf{rrroy@att.com}
\end{flushleft}        

\begin{flushleft}
Henning Schulzrinne\\
Dept. of Computer Science\\
Columbia University\\
1214 Amsterdam Avenue, MC 0401\\
New York, NY 10027\\
USA\\
Email: \textsf{schulzrinne@cs.columbia.edu}
\end{flushleft}

\begin{flushleft}
Kundan Singh\\
Dept. of Computer Science\\
Columbia University\\
1214 Amsterdam Avenue, MC 0401\\
New York, NY 10027\\
USA\\
Email: \textsf{kns10@cs.columbia.edu}
\end{flushleft}

\begin{flushleft}
David Wang\\
Nuera Communications Inc.\\
10445 Pacific Center Court\\
San Diego, CA 92121\\
USA\\
Email: \textsf{dwang@nuera.com}
\end{flushleft}

\input{copyright}
\end{document}
