Subject: [avtext] Taxonomy

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 16 Jul 2013 14:53:26 +0000

(As AVTEXT WG cochair)

The latest version of the taxonomy draft has been submitted

https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonomy/ 

This document was allocated to AVTEXT by dispatch, and we have created a milestone for it in AVTEXT.

This draft is not yet a working group document.

We do expect to spend some significant time discussing the contents in the AVTEXT meeting in Berlin, so please start raising your issues on the AVTEXT list.

Additionally, if there are counter proposals existing that the AVTEXT chairs would not otherwise be aware of, then please identify them to the AVTEXT chairs / list.

Regards

Keith

---

From: Colin Perkins <[email-masked]>
Date: Fri, 19 Jul 2013 21:34:07 +0100

> We do expect to spend some significant time discussing the contents in the AVTEXT meeting in Berlin, so please start raising your issues on the AVTEXT list.

This looks like a very useful document, that will hopefully avoid some confusion in future. Some brief comments:

- Section 2.4.2 incorrectly expands RTCP as "Real-time Transport Control Protocol", and should be "RTP Control Protocol".

- Section 2.6.2, 2nd bullet: it might be useful to explain that multiple RTP sessions can only be multiplexed over a single transport flow if some sort of shim is included in the packets to distinguish the sessions (the referenced draft-westerlund-avtcore-transport-multiplexing describes why this has to be the case in detail, but I think the high-level point is important to cover in this draft too). I also think the term "session multiplexing" is unclear about what is multiplexed, and would prefer it not be used.

- Section 2.9.1: I'm not sure an m= line description the configuration required to decode a media stream. It might be better to say the combination of an m= line, the associated payload format mapping in the associated a=rtpmap: lines, and the payload format parameters in a=fmtp: lines define the configuration required to decode a media stream. Just the m= line is only sufficient for the trivial static payload types.

- Section 2.10: what's the relationship between a "participant" and an "end point"?

- Section 2.11.2: I'm not sure an RTCP CNAME can identify a participant in an RTP multimedia session; the RTCP CNAME describes a synchronisation context, but a participant can generate multiple unsynchronised media streams.

- Section 3.1.1: note that RTP uses NTP-format timestamps, but doesn't require the clock be synchronised to NTP. This section can be mis-read as requiring the use of NTP, rather than just the timestamp format of NTP.

- Section 4: it might be appropriate to highlight the confusion between RTCP SDES and RTP security descriptions, since both are referred to as "SDES" frequently.

-- 
Colin Perkins
http://csperkins.org/

---

From: Bo Burman <[email-masked]>
Date: Sat, 20 Jul 2013 11:38:47 +0000

Thank you for very relevant comments. Corresponding changes will be made in the next draft version.

Cheers,
Bo

Sent from Moxier Mail
(http://www.moxier.com)

----- Ursprungligt meddelande -----
Från: Colin Perkins <[email-masked]>
Till: "[email-masked]" <[email-masked]>
Skickat: 2013-07-19 10:34 em
Ämne: Re: [avtext] Taxonomy

--
Colin Perkins
http://csperkins.org/

_______________________________________________
avtext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/avtext