In my presentation in Dallas I had suggested adding RTP (and even HTTP) because as both Mirja and Christian mention some 'applications' are requesting functionalities that are got given elsewhere.
Marie-José Montpetit [email protected] [email protected] On Jun 3, 2015, at 20:44, Christian Huitema <[email protected]> wrote: >> Actually I think I don't agree here. Yes, it's tied closer to the >> application but I >> think for taps this is a (good) example where the interface is at a much >> higher >> level and therefore might have a value to discuss it. However... (see below) > > I don't quite agree either. > > RTP is an extreme example of the split between "generic transport library" > and "application specific transport implementation." There are quite a few > RTP functions that are seldom found in other transports, but are worth > considering: > > 1) The use of timestamps. This is quite fundamental for "real time" > applications that need to synchronize the rendering of different media > streams. > > 2) The tolerance for losses. This requires alignment of transmission units to > "natural" media boundaries such as audio or video frames, or compression > units within video frames. > > 3) The practice of FEC, including variable rate FEC. This is quite common in > video transmission. A given frame will be transmitted as N data packets plus > P redundancy packets, where N and P depend on size and importance of the > frame, e.g. anchor frame versus delta. > > -- Christian Huitema > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
