\section{Motivation}

Recently, there has been a lot of interest in adding ``master-slave''
(remote-control) signaling protocols to the suite of symmetric
(peer-to-peer) signaling protocols such as SIP and H.323.  This interest
appears to be motivated by two factors, namely the intent to keep end
devices simple and to allow service providers full control over how to
provide services.  Rather than treating these modes as completely
disjoint, we propose to unify them under a common umbrella.  This has a
number of advantages.  For example, many devices will need to operate in
both a peer-to-peer and remote-controlled mode.

\section{Requirements}

\begin{itemize}
\item The client part must be no more complicated than SIP for clients.

\item The protocol(s) must be applicable to a wide range of devices and
applications:
\begin{itemize}
\item media gateways such as CATV modems;
\item interactive voice response (IVR) units;
\item automatic call distribution (ACD) systems;
\item pay phones and similar devices operating in ``hostile'' environments;
\end{itemize} 

\item Maximum re-use of existing protocols, including emerging work on
event notification.

\item Protocols must be suitable for multimedia and application sharing,
not just voice telephony.

\item Support of multicast for ease of scaling, redundancy
and support of conference bus architectures. We can initially assume
host-local or local (LAN) multicast to simplify problems related to the
absence of a reliable multicast protocol.

\item Text-based protocols are preferable for ease of implementation,
upgrade and flexibility.  It might be acceptable to constrain existing
text-based protocols to simplify implementations, for example, by
eliminating line folding, variations in white space, and the like.

\item Re-use of existing security mechanisms, including password and
digest based authentication and true cryptographic authentication.

\end{itemize}

It remains to be determined whether this protocol could also be used
between applications on a single host, e.g., to set up a multimedia
conference consisting of multiple applications coordinated by a single
conference controller \cite{pmm,ietf,vic}.

\section{Architecture}

We distinguish two components, namely the requests sent by the
controller to the media devices and the notifications generated
asynchronously by the media devices. Notifications might include, for example,
\begin{itemize}
\item phone off-hook;
\item digit string dialed;
\item busy signal received;
\item new video application available, with indications of functionality;
\item RTCP source heard for the first time or timed out;
\end{itemize}

Servers can indicate what type of events they are interested in. It may
be advisable to allow both simple event specifications, as in
\begin{verbatim}
dialed *9
RTCPjoin
RTCPleave
\end{verbatim}

Alternatively, clients can multicast events, with servers selecting the
types of messages they are interested in.

Examples of control requests include
\begin{itemize}
\item start receiving data from multicast address $x$;
\item stop sending data;
\item change encoding to G.723.1; 
\item return statistics for source $A$;
\end{itemize}

\end{document}
