Well... it's a typical engineering trade-off decision to make...

> On 04 Jun 2015, at 07:45, Marie-Jose Montpetit <mari...@mit.edu> wrote:
> 
> 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
> ma...@mjmontpetit.com
> mari...@mit.edu
> 
> On Jun 3, 2015, at 20:44, Christian Huitema <huit...@microsoft.com> 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
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Reply via email to