Sounds to me like we know we want to cover some of the unique features/components of RTP without having to go to the trouble of wedging a full description of the protocol (as in the other section) into the doc, a task complicated by the fact that RTP assumes a more fluid separation of responsibility among itself, its undertransport(s), and its specific application than is the case with other protocols.
So I would suggest the following: we have an abbreviated RTP section in this document that (1) points out this difference as potentially architecturally interesting (which itself might be input to the third charter item) and (2) enumerates only those features which are unique to RTP among protocols treated in the document. (Varun, as current pen-holder on the RTP section, does this make sense to you?) Cheers, Brian Sent from my iPhone > On 04 Jun 2015, at 09:37, Michael Welzl <[email protected]> wrote: > > Well... it's a typical engineering trade-off decision to make... > > >> On 04 Jun 2015, at 07:45, Marie-Jose Montpetit <[email protected]> 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 >> [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 >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
