\documentclass[11pt]{article}
\usepackage{times,i-d,txtpsfig,tight,grammar}
\usepackage[dvips]{changebar}

\author{Schulzrinne/Rosenberg}
\shorttitle{SDP-CNAME}
\filename{draft-schulzrinne-mmusic-cname}
\title{Associating RTP Streams with SIP Sessions}
\wg{}
\expires{November 2002}
\address{Columbia U./dynamicsoft}
\pubdate{\today}
\input{../defs}

\begin{document}
\maketitle
\tableofcontents

\begin{abstract}
For conferencing, dealing with multiple call legs, side bars and other
applications, it is desirable to unambiguously associate media streams
with SIP sessions.  We describe how a new SDP attribute, ``cname'', can
be used to carry the RTCP CNAME SDES attribte across the signaling
association.
\end{abstract}

\section{Introduction}

There are a number of scenarios where a SIP user agent needs to know
which RTP packets belong to which SIP session.  One such scenario is a
conference bridge terminating multiple SIP sessions.  In most cases, the
bridge can direct streams to different transport ports and thus
unambiguously identify the source.  (Indeed, this is probably preferable
as two sources sending to the bridge would not see each others
transmissions and thus could collide in their SSRC values without either
of them noticing.) However, in some circumstances, the number of
destination ports may be limited by firewall constraints, forcing
multiple media streams to share the same port.  In those cases, it is
desirable to be able to unambiguously associate an RTP stream with a SIP
session.

A more realistic case is SIP {\INVITE} forking.  Here, the UAC gets back
multiple 200 OK (or multiple 18x), with all the media being sent to the
same port that was specified in the session description of the {\INVITE}
request.  Thus, there is no way to correlate the media with the SIP
dialogs.  This can be fixed by performing a re-{\INVITE} (or {\UPDATE})
to put the media on a different port.  Having a correlation identifier
would avoid the need for the re-{\INVITE}, and also provide correlation
right away. 

Another application is the initiation of side bar conversations during a
multicast session.  If two participants want to converse, they need to
acquire each other's SIP address, with RTCP as the only common means. 
For H.323, the H323-CADDR RTCP SDES option supports this, but for SIP,
there is no direct equivalent.  However, unlike the other uses, this
identifier should not identify a particular host, but likely a generic
SIP address-of-record.  This contradicts the other uses; thus, it is
likely that this requires a separate mechanism.

\section{Attribute Description}

This document describes a new SDP \cite{draft-ietf-mmusic-sdp-new} value
attribute, namely ``a=cname:''.  The syntax of the parameter follows
that in \cite{draft-ietf-avt-rtp-new}, i.e., it is a user name followed
by either a fully-qualified domain name or an IPv4 or IPv6 address.

The ``cname'' attribute can be either session-level or media-level. 
Media-level should only be necessary if the media agents for a single
SIP session are located on different hosts.

An example is ``alice@for.example.com''.

The parameter is not likely to be useful for multi-source multicast
sessions, but can be used to identify the primary source in a multicast
session.

\section{Alternate Solutions}

As an alternative to the SDP attribute, one could add a new SDES
parameter, say, SIP-CADDR, that identifies the SIP address of the
application controlling the media agent.  This is similar to the
H323-CADDR parameter [where is this standardized?  There is an IANA
registration, but that seems to be it.].  The drawback of that approach
is that it requires modifying media applications.  A more serious
problem is that this does not work well if there are multiple
participants with the same SIP address-of-record.  All of these would
likely have different host names, so that their RTCP CNAMEs will differ,
but the RTP sessions could not be clearly mapped to a particular SIP
session with the SIP-CADDR approach.

A minor advantage of the proposed approach is that RTCP is designed to
be bandwidth-frugal, so that adding parameters should not be done
lightly.  If the SIP-CADDR parameters were to transmitted only
occasionally, it might take a significant amount of time before a newly
established SIP session can be associated with RTP packets.  The CNAME
SDES parameter, on the other hand, is mandatory for every RTCP packet.

It has also been proposed to include the SSRC in the session
description.  This approach has practical problems, in that SSRC
collisions can change the SSRC in mid-session.  Thus, RTP media agent
would need to be able to notify the SIP user agent that the SSRC value
has changed and trigger a re-{\INVITE}.  Some existing user agents can
only be configured at start-up and do not have the ability to
communicate back to the SIP user agent.  Unlike the CNAME, which is the
same for all media sessions, the SSRC will differ between media
sessions, further complicating the implementation.  However, the SSRC
does have the advantage that it is contained in every RTP packet, thus
leading to faster stream association.  The waiting time should be very
small, on the order of a few seconds.

Alternatively, one could include the packet source address as part of
the SDP description.  However, the source address may not be known
precisely (e.g., with multi-homed hosts), may be changed by NATs or may
change during a session, e.g., when a DHCP lease lapses after a period
of inactivity or when the host moves into a new subnet.  Like the SSRC
approach, it is clearly faster than waiting for the RTCP packet.

\section{Limitations}

It is conceivable that over-eager NAT ALGs would rewrite the CNAME
portion of an RTCP packet.  Such action is neither advisable nor
necessary, since CNAMEs are only meant for unique identification.

\section{Authors' Addresses}

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

\bibliographystyle{ieeetr}
\bibliography{string,ansi,itu,i-d,rfc}

\input{../copyright}

\end{document}
