Subject: Re: [avtext] Taxonomy

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Sep 2013 08:27:04 +0200

Hi Colin,

I just wanted to comment on what have and have not been addressed in the
new version of the taxonomy draft. Me and Bo forgot about this email
until after we had done our submission, sorry about that.

On 2013-07-19 22:34, Colin Perkins wrote:
> On 16 Jul 2013, at 15:53, <[email-masked]> wrote:
>> (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.
> 
> 
> 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".

Not addressed, but I have entered it into the source so that it will be
addressed in the next version.

> 
> - 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.

This has been substantially rewritten and split appart. And I agree that
Session multiplexing is not a good term and the new document discusses
both RTP Session based separation of RTP Packet Streams and Multiple RTP
sessions over one Media Transport. See section 3.3.4.2 and 3.4.

> 
> - 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.

Also this has ceased to exist in the form you protested.

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

In most cases a one to one as the end point is this addressable entity
for the media chain and the participant is what is addressable on the
signaling plane. However, this is not always true if we take SIP forking
or other cases where a signalling entity has multiple points of
presence. This will need to be better explored and the place to do it is
likely in the Section 4 rewrite. This section is intended to cover how
the RTP session, transport topologies and signaling interact to cause
difficult situations.

> 
> - 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.

This is now Section 2.2.4.2, however the question remains.

I think I agree that Participant is likely to go to far in the bindings,
however CNAME clearly has an overload functionality of being both an end
point identifier and a synchronization context. I think the
synchronization context is the one that must prevail and the end point
usage discontinued.

For the next version I have removed this bullet. Discussion of
identification is likely needed but likely in a better context. I think
this do applies for exploration in the Section 4 rewrite.

> 
> - 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 3.1.1.1. now says:

   RFC3550 [RFC3550] describes Inter-media synchronization between RTP
   Sessions based on RTCP CNAME, RTP and Network Time Protocol (NTP)
   [RFC5905] formatted timestamps of a reference clock.

> 
> - 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.
> 
> 
> 
No usage of SDES is the submitted draft.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Colin Perkins <[email-masked]>
Date: Sun, 22 Sep 2013 16:58:19 +0100

Hi Magnus,

> until after we had done our submission, sorry about that.

No problem; the new draft looks to address many of my concerns. 

A comment on the latest version: I find it difficult to read in places, due to the excessive use of sub-section numbering.  The might would be easier to read if the 4th level headings were removed, and replaced by prose.

> addressed in the next version.

Okay.

> sessions over one Media Transport. See section 3.3.4.2 and 3.4.

The new version is better. I would suggest that Sections 3.3.4.1 and 3.3.4.2 should also mention how the streams can be explicitly related (i.e., using a common RTCP CNAME, or other means). 

> the RTP session, transport topologies and signaling interact to cause

Decomposed endpoints would be another, presumably. 

> synchronization context is the one that must prevail and the end point

Agree.

> this do applies for exploration in the Section 4 rewrite.

That makes sense.

>   [RFC5905] formatted timestamps of a reference clock.

Better, although an explicit statement that the NTP-format timestamps don't need to be NTP synchronised would still be useful. Also, it might help to reference the clksrc draft?

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