Re: [rtcweb] DRAFT Agenda for RTCWEB

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Dale R. Worley
> Sent: Friday, March 01, 2013 7:59 AM
> To: Ejzak, Richard P (Richard)
> Cc: [e-mail]
> Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB
> 
> > From: "Ejzak, Richard P (Richard)" <[e-mail]>
> >
> > Since multiplexing of the data channel with RTP media has been shown
> > as a desirable feature of BUNDLE (and most of its variants), I would
> > suggest that this be treated as a significant advantage for BUNDLE
> > (and similarly capable variants) over any proposal without it.
> > Cullen's "Plan A" is preferred over Plan B precisely because it has an
> > incremental muxing advantage.
> 
> As far as I can tell from my analysis
> (http://tools.ietf.org/html/draft-worley-sdp-bundle-04#section-8),
> SCTP-over-DTLS can be demuxed from RTP and STUN quite easily.  (This
> comes from RFC 5764 section 5.1.2.)  And SCTP can be demuxed from the
> rest as long as you control the range of SCTP ports used.  (And since
> the ports aren't actually to route the packets to the receiver (the
> underlying UDP does that), you have freedom in choosing SCTP ports.)
> 
> So I don't see anything blocking Plan A as compared to Plan B.  Of
> course, we have to *do* a bundle technique, but we've got a large
> library of possibilities now and can look at the fundamental design
> questions in context.

The analysis should also examine impact of port-based QoS on 
multiplexing data over the same port as audio.  Even audio and
video often prefer different drop precedence.  I know the general
consensus is to just supply more bandwidth, yet we consume all 
available bandwidth much like disk space, memory, and CPU/GPU 
cycles.

-d