Subject: [MMUSIC] SSRC in SDP

From: "Ed Luff" <[email-masked]>
Date: Thu, 12 Jun 2003 14:33:49 -0400

The Synchronization Source (SSRC) is passed in the RTP and RTCP headers,
which uniquely identifies a particular media stream.

There are some good benefits to including the Synchronization Source
(SSRC) within the SDP, including the prevention of uncontrolled barge-in
or eavesdropping (within the network) and multiplexing media streams
over the same receiving port.  The only downside that I have come across
is the need for the application to appropriately handle the possibility
of two clients generating the same random SSRC, which seems minor in
nature. 

Instead of having each session oriented protocol (SIP, RTSP, MGCP and
H.323) include support through an extension, would it not be a good idea
simply to have the SSRC included within the SDP?  I have seen proposals
in H.323 and RTSP, where the extension is a bit messy, as the clients
must signal their support of the extension in the call setup...

I have included some references and information below, which support the
need for SSRC signaling.

Thoughts?

Ed

- "SDP Security Descriptions for Media Streams",
<draft-ietf-mmusic-sdescriptions-00.txt>, February 2003.

- "How to make Real-Time Streaming Protocol (RTSP) traverse Network
Address Translators (NAT) and interact with Firewalls",
<draft-ietf-mmusic-rtsp-nat-00.txt>, February 2003.

- H.323 has proposed the use of signaling the SSRC in the H.245
signaling channel.  The primary purpose is for multiplexing media
streams over the same receiving port.  The proposal is shown below.

H2250LogicalChannelParameters	::=SEQUENCE
{.
		willUseSSRC                    NULL OPTIONAL,
		ssrc		              INTEGER(0..4294967295)
OPTIONAL
}
	H2250LogicalChannelAckParameters	::=SEQUENCE
	{          .
		ssrc		             INTEGER(0..4294967295)
OPTIONAL
	}

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Fri, 13 Jun 2003 17:06:49 -0400

> of two clients generating the same random SSRC, which seems minor in

Using the SSRC to prevent barge-in and eavesdropping seems weak. There are
also good reasons why multiplexing media streams of often not a good idea:
the RTP specification goes into details. 

> must signal their support of the extension in the call setup...

How do you handle collisions if the SSRC is included in the SDP? I would
expect there to be the need for some interaction with the signalling
protocol.

-- 
Colin Perkins
[email-masked]

---

From: Mark Baugher <[email-masked]>
Date: Mon, 16 Jun 2003 13:38:52 -0700

Ed,

>I have included some references and information below, which support the

I think that including the SSRC is a necessary evil for SRTP.  Ideally, we 
would not need to interfere with normal RTP processing in this way by 
requiring that the SSRC be pre-determined.  But the SSRC is used for the 
lookup of the SRTP cryptographic context and for computation of the 
initialization vector.  I think we would prefer to avoid forcing SSRC 
determination prior to session commencement when possible.

Mark