Subject: [rtcweb] RRe: More elbow grease on draft-ietf-rtcweb-rtp-usage, please

From: Bernard Aboba <[email-masked]>
Date: Mon, 22 Apr 2013 16:04:01 -0700

Magnus said:

Yes, there are some issue especially related to more advanced functions
around multi-stream transmission and layered coding where we don't yet
have finished specifications to reference yet. I agree that these have
been known for quite a long time. But from my perspective, the market
hasn't been desiring standardization of these functionalities, everyone
has been happy to have their own private silo of functionality where
things function by convention, rather than specification. I have been
actively working to get going on resolving these things for quite some
time.

[BA] The "market desire" has been growing strongly, now that support for simulcast and
layered coding has become much more common.  Interestingly, many of the implementations have
independently chosen to do things similarly (though not exactly the same way), indicating
that there is a basis for agreement about how things should work.  I am hoping that we will
therefore see more progress, starting with the Berlin meeting. 

Magnus said: 

>From my perspective functionality that isn't mature enough will have to
be thrown out. I fear that will include some of my darlings. But that is
the reality of umbrella standardization is that you have to work with
what you have. For things that aren't ready enough to wait for, then you
publish and revisit later and see if they can be added.

[BA] If there is a clean way to separate "v1.0" functionality from addons, that would be
welcome.  However, in the current RTP usage draft there are open issues that relate to the
interaction of feedback messages and congestion control, which seems like a "v2.0" 
feature (e.g. "v1.0" is circuit-breakers).  Also, there is an interaction between the 
approach to resolution/frame rate change and support for simulcast/layered coding (e.g. 
simulcast/layered coding implementations typically change resolution/frame rate without SDP 
re-negotiation, since the sender or mixer can drop layers/change simulcast encodings).