Subject: RE: [AVT] Re: RTP/RTCP Port Sharing (SSRC)

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 7 Aug 2001 17:48:45 -0400

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: Tuesday, July 31, 2001 3:22 PM
> To: 'Jonathan Rosenberg'
> Cc: [email-masked]' '; [email-masked]'
> Subject: RE: [AVT] Re: RTP/RTCP Port Sharing (SSRC)
> 
> 
> 
> > > 
> > > It would be nice to have a mechanism which does not rely on 
> > > application
> > > specific capabilities. I don't know if thats possible. I'll 
> > > also note that
> > > if you can have these properties from the application layer, 
> > > I don't need
> > > ranges anymore either. In the case of forked early media, the 
> > > caller can
> > > tell each early media sender to use a specific SSRC. This 
> > > way, each sender
> > > is using a different SSRC. 
> > > 
> > 
> > I guess you could always kludge it with RTCP by inventing 
> > imaginary RTCP
> > receiver (fake an SSRC collision) but that is very nasty and 
> > has another
> > problem. The problem with doing any SSRC collision resolution 
> > entirely at
> > the transport/RTP level is that you lose the ability to correlate
> > media-flows with application sessions in a transport 
> > independent manner.
> > 
> 
> Actually, I guess you could provide the CNAME in the ssrc (or 
> "rtpssrc")
> attribute which would thereby allow you to maintain the session-level
> correlation even when an SSRC collision occurs (which should 
> be resolvable
> using standard RTCP methods). The "rtpssrc" attribute 
> maintains the other
> properties such as the session separation for RTP & RTCP 
> packets and some
> probabilistic protection from blind attacks and systematic 
> errors (where
> appropriate).
> 
> So here would be my new format suggestion:
> 
> rtpssrc-attribute = "x-rtpssrc:" rx-ssrc-mask SP tx-ssrc-info [SP
> tx-ssrc-cname]
> rx-ssrc-mask = *(HEXDIGIT) *("x")
> 	where rx-ssrc-mask is 1-8 characters in length
> tx-ssrc-info = tx-ssrc-seed | "mixer" | "-"
> tx-ssrc-seed = 1*(HEXDIGIT)
> 	where tx-ssrc-seed is 1-8 characters in length
> tx-ssrc-cname = token | quoted-string
> 	[this is the CNAME value used in RTCP reports]
> 
> A tx-ssrc-info value of "mixer" indicates that multiple 
> ssrc's will be sent
> and that receiver must use the same rx-ssrc-mask (or simply 
> "xxxxxxxx") when
> receiving RTP & RTCP packets (and should specify the same 
> rx-ssrc-mask value
> in the reverse SDP if one is generated). A value of "-" 
> indicates that the
> forward SSRC information is not available.
> 
> The "mixer" value should be useful in Single Source Multicast 
> sessions where
> one server does all the RTP/RTCP mixing & distribution and all other
> participants merely send back to the server (as described in 
> that draft).
> The server may request participants to use a certain SSRC 
> port range (to
> separate sessions on the same port pair) but all participants must not
> select a different range in the reverse direction.

Hmm, I suspect you would not use SSRC ranges at all for the multicast group,
only for the recvonly streams towards the mixer. In that case, you don't
need to introduce this mixer flag. 

-Jonathan R.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www1.ietf.org/mailman/listinfo/avt