On 8/11/2012 6:50 PM, Mo Zanaty (mzanaty) wrote:
Michael Welzl <michawe@ifi.uio.no> wrote:
...piggybacking ACKs on RTP payload... Randell Jesup <randell-ietf@jesup.org> wrote: ...use header extensions as an alternate channel for RTCP... Several implementations do either or both of these things, in proprietary ways obviously. I think both should be standardized, although this may be an unpopular view in AVT.
I *may* agree, though I also agree it may be unpopular. I've had to do it because of using SBCs configured not to pass RTCP at all and didn't like RTCP on the RTP port, and I needed it for PLI/etc. But that was a rare homegrown (though ISP-wide) SBC; even misconfigured SBCs typically support RTCP-mux I imagine. And I did it before RTCP-mux was defined, and was part of why I supported RTCP-mux. Once you start pushing enough data to double the normal packet rate, the per-packet overhead can get to be a problem, especially if you're on a low-bandwidth link. Instead of (say) 30 video + 50 audio packets per second, you have an additional 80. Sending them in header extensions would save around 20Kbps, perhaps a little more - marginal if you have 250Kbps or up, but significant if you have (say) 128Kbps, and already are losing around 25Kbps to overhead. My old phones would run 30fps down to total bandwidth of as low as 60-80kbps, though it was running QCIF down that low (plus iLBC 20ms - 15Kbps+overhead, so video payload got as low as 40, even 30Kbps). At those bitrates, 20Kbps is huge. I'll admit given RTCP-mux (and assuming nothing interferes with negotiation of it!), the argument is largely one of efficiency in bandwidth and packet-rate. And this is much less of an issue if you're not sending circa 1 feedback message per packet. I assume this would fall in CORE.
Note that there is no standardized generic ACK. I just submitted an errata to the RFC 4585 ABNF to clarify that "ack" (without parameters) is invalid since there is no generic ACK. There is only "ack rpsi" which is specific to H.263 Annex N, and "ack app" which is proprietary.
I think there was a generic ACK in an earlier draft, but it was removed (I think a hole in the code list was left to avoid breaking people working with the draft).
Beyond ACK, many other types of RTCP feedback would benefit from the efficiency of piggybacking in RTP header extensions. (NACK, ECN, FIR, TMMBR, PLI, SLI, etc.) So a general mechanism for all RTCP feedback may be more useful than a single mechanism for ACKs.
Quite true. The toughest part is to define when such a thing should be used over RTCP-mux. It would make using other header extensions tricky (though possible), and it would imply a circa up to 20, 30, perhaps in a few cases 100ms delay in sending feedback (avg circa 1/2 that; less if they can piggyback on other RTP streams). If there's "important" data you could send a direct RTCP and not wait. -- Randell Jesup randell-ietf@jesup.org