\documentclass[11pt]{article}
\usepackage{i-d}

\pubdate{July 17, 1998}
\address{Columbia University}
\expires{January 17, 1999}
\filename{draft-ietf-schulzrinne-mediagw-00}
\title{Protocols for the Media Gateway - Controller Interface}
\author{H.Schulzrinne}
\shorttitle{mediagw}
\shortauthor{Schulzrinne}
\wg{Personal}
\begin{document}
\maketitle

\status{}

\section{Abstract}

This document discusses the services provided by a protocol between a
media gateway and a gateway controller. It concludes that the
requirements fit those of general event notification protocol and a
third party call control mechanism. As such, we propose that two
separate protocols, each of which either exist or are under
development, be used for this function.

\section{Introduction}

There has been a recent interest in development of large-scale
Internet telephony gateways, capable of supporting tens of thousands
of lines. To support this level of scalability, some implementors have
decided to split the call control and media functions into two
separate devices. The call control device contains the ``smarts'',
processing the signaling on both the IP side and telephony side, while
the media device supports the necessary speech encoding and decoding
functions and packetization.

As the two devices are physically separate, a protocol is necessary to
convey information between them. The Simple Gateway Control Protocol
(SGCP) \cite{draft-ietf-huitema-sgcp} has been proposed for this
purpose. SGCP is a simple textual protocol, similar to the Session
Initiation Protocol (SIP) \cite{draft-ietf-mmusic-sip}, but engineered
for this specific application.

In this draft, we briefly review the features provided by SGCP. We
note that these features incorporate both event notification and third
party call control mechanisms. 

\section{SGCP Features}

SGCP provides a number of key features:

\begin{enumerate}
\item Control gateways can request notification of events from media
gateways. Any number of control gateways can ask for notification from
a single media gateway.
\item The events which can be notified include on and off hook, dialed
digits, matching of dialed digits to a numbering plan, fax and modem
tones, continuity test results, etc.
\item The control gateways can also instruct the media gateways to
play a variety of tones, or ``swap'' connections (to support call
waiting) when an event occurs.
\item The control gateways can instruct the media gateways to add,
change, and remove IP connections to each circuit on the media
gateway.
\item At the termination of the call, the media gateway informs the
call gateway of the statistics of its IP connection.
\end{enumerate}

The model is that of an extremely stupid media gateway, which passes
basic circuit event information to a smart controller which makes all
call control decisions and passes connection decisions back to the
media gateway.

\section{Equivalence to Existing Protocols}

We observed that SGCP is a combination of two protocols: (1) an event
notification protocol, and (2) a third party call control protocol. 

SGCP allows a control gateway to subscribe to events present at a
media gateway, such as dialed digit string match, tones, etc. When
these events occur, the media gateway delivers them to those gateways
which have subscribed. This is precisely the service provided by
protocols such as the Event Notification Protocol (ENP)
\cite{draft-reddy-enp-protocol} and
\cite{draft-cohen-gena-p-base}. However, whereas SGCP defines events
very specific to the particular model defined therein, ENP defines
events according to an XML syntax. This allows for easy definition of
new events which may be more appropriate for different levels of
separation of control between media and control gateways. As ENP (or
equivalent protocols) allows for notification of events related to
other services, such as email, presence, web editing, etc., a call
controller based on ENP could more easily provide services based on an
integration of these components. For example, a new service might
allow a caller on a line to have a call routed to a user at an IP
terminal when logged in, a PSTN line otherwise. A controller
providing this service would need to subscribe to both media gateway
attributes and presence attributes. Having a single framework for both
notifications eases this integration.

Secondly, we note that SGCP provides functions for basic third party
call control. It allows a control gateway to setup, change, and
teardown connections between generic endpoints reachable through the
media gateway. These endpoints can be TDM circuits or IP hosts. We
note that this function is very similar to that supported by the PINT
protocol \cite{draft-ietf-pint-sip}. The only difference is that in
SGCP, the endpoints can be either IP or PSTN terminals, whereas in
PINT, they are only PSTN. However, the PINT protocol itself is based
on the Session Initiation Protocol (SIP) \cite{draft-ietf-mmusic-sip},
which is used for establishing multimedia sessions between IP
terminals. Thus, using the PINT protocol for services which involve
non-PSTN endpoints will likely require little or no extensions. As
such, it seems inefficient to design a new protocol to fufill the
third party call control requirements presented in SGCP. Using SIP
would allow a server to provide both PINT and SGCP like functions
without an additional protocol suite.

\section{Conclusion}

In general, we feel that the Internet protocols have been successful
largely due to their generality and wide applicability. Instead of
defining a new service, laying out interfaces, and then writing a new
protocol for each interface, the Internet protocols have been designed
to provide generic functions. More complex services can be built by
using these generic functions in tandem. We feel that this design rule
applies to the media gateway to control gateway interface as
well. Rather than designing a protocol to fill this very specific
need, using two more general protocols (an event notification and a
third party call control protocol) would provide much greater
flexibility and extensibility.

\section{Security Considerations}

Security considerations are not discussed in this document.

\section{Author's Addresses}

\begin{verbatim}
Henning Schulzrinne 
Columbia University 
M/S 0401 
1214 Amsterdam Ave. 
New York, NY 10027-7003 
email: schulzrinne@cs.columbia.edu 
\end{verbatim}


\bibliographystyle{ieeetr}
\bibliography{rfc,i-d}

\end{document}


