\title{Meta Signaling using SIP and SDP}
\begin{document}
\begin{abatract}
When carrying signaling for circuit-switched telephony services over IP,
there is a need for establishing signaling sessions between two or more
signaling end points.  This note describes a mechanism how SIP and SDP
can be used to establish signaling sessions between such signaling end
points.
\end{abstract}

\section{Introduction}

Traditionally, out-of-band signaling for PSTN (public switched telephone
networks) has been carried on dedicated lines, typically DS-0 or
T-1/E-1.  Such out-of-band signaling systems are all packet-based, using
a network architecture specific to signaling.  (In this note, we are
only concerned about out-of-band signaling and this qualifier is
implied.  In-band signaling is still commonly used for PBX trunks, but
the approach described here is not directly applicable.) The most common
signaling protocol are ISUP and TCAP, part of the SS7 suite of
protocols, but there are a number of other protocols in use as well,
such as TUP and a range of signaling protocols for mobile networks, such
as IS-41 or the protocols used by GSM.  In addition, many of these
protocols, in particular, ISUP, have a variety of national flavors which
differ slightly in their capabilities, use of parameters and other
details.

As indicated, telephony signaling, while packet-based, has used its own
protocol stack, completely different from either IP or OSI.  Thus, it is
possible to carry PSTN signaling across IP at a variety of levels.  For
ISUP, for example, one could carry MTP (roughly, the link through
network layer) or only the ISUP elements themselves.  In addition, it is
not yet clear which transport protocol, UDP, TCP or some new reliable
transport protocol, will be used to carry the signaling packets at
whatever layer.

Finally, two signaling end points need to agree on a number of other
transport issues, such as the use of a secure transport or network
layer, and the use of QoS-enhancing mechanisms such as DiffServ or
resource reservation.

Thus, rather than simply setting up a transport connection, signaling
end points need to establish a rather complex and typically long-lived
session between them.  As for telephony signaling itself, end points
could use either in-band or out-of-band mechanisms to negotiate the
parameters of this session.  In this note, we propose an out-of-band
mechanism.  We believe it to be more flexible, avoiding to have to
burden the signaling transport with a myriad of details that are only
relevant at the beginning of a session.  Also, since the transport
protocol itself may need to be negotiated, one would have to agree on a
default protocol and then switch to the actual transport protocol.

This note describes how SIP \cite{ietf-mmusic-sip} and SDP \cite{rfc}
can be used to set up signaling sessions between signaling end points. 
In common parlance, this functionality is referred to as meta-signaling. 
(Other signaling systems, such as Q.2931 for B-ISDN, are also used for
both signaling and meta-signaling.) Using SIP for meta-signaling allows
the re-use of functionality such as authentication, proxying and
redirection and the in-session change of signaling end points.

\section{Use of SIP}

No changes to SIP are required to use it as a meta-signaling protocol. 
The naming of end points is for further study.  It may be desirable to
name signaling trunks or simply the signaling protocol, as in {\tt
trunk17@isup1.example.com} or {\tt isup@example.com}.  There is no
automatic discovery of signaling end points.  This is unlikely to be
necessary since signaling gateways don't typically establish signaling
associations with a random gateway.  It may be possible to use the
gateway location protocol being developed within the IETF IPTEL WG to
locate gateways, if that should prove to be interest.

\section{Use of SDP}
\label{sec:sdp}

Signaling protocols are defined as a media type within the class
``application''.  Table~\ref{tab:app} defines a first set of signaling
types. 

\begin{table}[htbp]
\begin{tabular}
signaling protocol & media type & version\\
\hline
ISUP, international (Q.763, Q.764) & isup & \\
ETSI ISUP                          & isup & etsi\\
ANSI ISUP T.113                    & isup & ansi\\
Bellcore ISUP GR394                & isup & bellcore-gr394\\
Bellcore ISUP GR317                & isup & bellcore-gr317\\
ITU TUP Q.724                      & tup  & \\
ITU DSS1 Q.931                     & q931 & \\
ANSI ISDN T1.607                   & q931 & ansi\\
ETSI DSS ETS 300 403               & q931 & etsi\\
\end{tabular}
\end{table}

Currently, only one parameter, {\sf spversion} (signaling protocol
version), is defined.  That parameter can assume the values ``ansi'', ``etsi'',
``itu'' (implied if not given).

An example of an SDP payload is shown below:

\begin{verbatim}
v=0 2890844526 2890842807 IN IP4 192.x.x.x
e=techsupport@example.com
t=0
c=IN IP4 isup.example.com
m=application 27910 udp isup
a=spversion:ANSI
\end{verbatim}

The IP addresses indicate the other side can connect to.  Several
signaling sessions may be listed in the same SDP body.

\section{IANA Considerations}

This note defines additional SDP media types and parameters in
Section~\ref{sec:sdp}.  Additional values of these parameters may be
registered with IANA.  Each such registration must refer to the standard
defining the protocol, typically issued by the ITU, a regional or a
national standardization body such as ETSI or ANSI.  It must also
identify the version of the specification being used.

\section{Security Considerations}

Use of the mechanism described in this note may increase the security of
signaling associations, as currently, such associations rely strictly on
physical security rather than authentication or encryption.  Otherwise,
the security considerations for SIP apply.

\end{document}

