Subject: [AVT] SSRC multiplexing (for the SVC draft)

From: Stephan Wenger <[email-masked]>
Date: Wed, 9 Aug 2006 20:41:23 +0300

Folks,

in conjunction with the SVC draft, we discussed RTP multiplexing in  
Montreal once more.  The result was that (at least for a layered  
codec) the preferred mechanism to convey layers is in their own RTP  
session, but if that's not possible (e.g. from a firewall pinhole  
viewpoint), the SSRC multiplexing is preferable over PT  
multiplexing.  So far so good.

I'm anticipating future media codecs with similar constraints as  
SVC.  One example is the Multiview codec extension of H.264, with  
very similar conatrints from a transport viewpoint -- lot's of NAL  
unit streams that have a certain value individually, but more value  
combined.

Which brings us to the question: would be better to document the  
subject of SSRC multiplexing in its own document rather than burying  
it in the SVC payload spec.  That document could be targeted towards  
informational or could end up in this RTP payload writer's guide, or  
even being standard's track (if we were to define signaling  
mechanisms).  It could say (incomplete list)

- what is SSRC multiplexing,
- why RFC 3550 suggests not using it
- don't do it unless you really must
- environments where SSRC mux may be applicable
- don't do it for different media types (i.e. don't ssrc mux audio  
and video) -- carry then in their own session no matter what
- don't do it as a trunking mechanism for identical media types, use  
TCRTP instead
- ...

What do you think: would such a doc be of value, or is it better to  
keep the concept local to SVC (and future payloads with similar  
constraints)?

If this document needs to be written, I can act as an editor, at  
least initially.  However, clearly, I'm not the most suitable person  
for the job -- too pragmatic and mentally not deep enough in the  
ivory tower of the multicast world to care enough about it.  Anyone  
else who would contribute?  I'm thinking mostly of the old hands in  
the WG, and (current and former) WG chairs?

Thanks,
Stephan

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

---

From: "Kalleitner, Franz" <[email-masked]>
Date: Thu, 10 Aug 2006 08:44:59 +0200

dear all,

just another view. recently hierarchical layered encoding is also envisaged for audio i.e. SSAC. hence, any media type applicable for SSRC multiplexing (similar as highlighted for the multiview extension) may profit. to come true, a general solution should be documented.

cheers,
franz

-----Ursprüngliche Nachricht-----
Von: Stephan Wenger [mailto:[email-masked]] 
Gesendet: Mittwoch, 09. August 2006 19:41
An: AVT WG
Betreff: [AVT] SSRC multiplexing (for the SVC draft)

Folks,

Thanks,
Stephan

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 10 Aug 2006 13:37:06 -0400

Stephan Wenger wrote:
> viewpoint), the SSRC multiplexing is preferable over PT multiplexing.
> So far so good.   

Actually, I'm wondering about the motivation for doing this at all.  For
SVC, and presumably for similar future media codecs, there should be
sufficient information in the RTP payload (e.g., for SVC, in the NAL header)
to distinguish between layers.  As far as I can tell, the only reason to
have a media-independent multiplexing mechanism for SVC is to allow a MANE
or other middlebox to be outside an SRTP security context, and yet still
perform useful operations on an encrypted media stream by dropping some of
its packets.

Is this scenario really necessary, given the complexities it imposes?  The
problems are two-fold:

First, how would you associate related SSRCs, and determine which one is
which, given that an RTP session might also be carrying truly unrelated
streams? Remember that presumably the session's RTCP is encrypted as well.

Second, how would you describe and signal ssrc-separated streams in SDP?

--
Jonathan Lennox -- Layered Media
[email-masked]

---

From: "Thomas Schierl" <[email-masked]>
Date: Fri, 11 Aug 2006 12:06:14 +0200

Jonathan, Stephan, All,

First I want to state to Stephan's email that also in my opinion the Multi
View Coding extensions of H.264 (MVC) are a good argument for having more
discussion on layered multicast and RTP multiplexing. It's true that MVC
will be a part of the SVC extensions to H.264 but it shows a different
use-case for layered transmission. But anyway, future codecs like H.265 may
be definitely a reason for a general solution.

Further comments to Jonathan's email inline...

> -----Original Message-----
> From: Jonathan Lennox [mailto:[email-masked]]
> Sent: Thursday, August 10, 2006 7:37 PM
> To: 'Stephan Wenger'; 'AVT WG'
> Subject: RE: [AVT] SSRC multiplexing (for the SVC draft)
> 
> Stephan Wenger wrote:
> > Folks,
> >

I'm not really sure, if security is the only argument. The guidance we got
form the mmusic and avt WG chairs was to define a codec-independent and
generic signaling for layered transmission, which implies the usage of
different RTP multiplexing techniques depending on your use case. Further a
generic signaling only makes sense if codec-unaware entities may benefit
from that. And 'thinning' a stream by using SSRCs has much less complexity
than parsing payload information which may appear in different positions in
a packet. Think of future MANEs being aware of different codecs allowing
layered transmission. A stream handling having 'generic' multiplexing
methods available will for sure lower complexity.

> Second, how would you describe and signal ssrc-separated streams in SDP?

Yes this is definitely a problem. Discussion on
'draft-peterson-rosenberg-avt-rtp-ssrc-demux-00.txt' showed a strong
push-back on signaling SSRC in SDP and formulated the problem, which is a
possible SSRC collision. If this happens SDP will not be able to carry
information about the correct SSRC without having something like a
re-negotiation mechanism.
But I could think of a solution based on a more implicit kind of signaling
as used for SSRC multiplexing in RFC4588. 

Regards,
Thomas

--
Meet us at 

IFA: 1.-6.9.06, Berlin, Germany