> 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
