Okay, I promised I won't insist, and I don't... still contributing to the tech debate here:
In line - essentially, I'm suggesting RTP-over-TAPS here. BTW and just to be clear, I agree about mentioning RTP in the draft and I agree that it provides important functions! The question is whether RTP's functions should belong to the TAPS "service set" (which in fact is going to be defined in the group's second item, but this depends on the first...). > On 3. jun. 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. Agreed - but that would make sense and work *over* pretty much every transport protocol, right? > 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. ... which just means that RTP has to run over a transport that allows the application to control message boundaries. > 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. ... which is indeed very closely tied to the application, and might not be the kind of thing you want to have in a generic layer, but you could implement it on top? Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
