Subject: Re: [avtext] Taxonomy

From: Peter Thatcher <[email-masked]>
Date: Wed, 23 Jul 2014 07:13:50 -0700

On the issues of media source/sink, here are a few ideas, and perhaps
a proposal.

If we name #3 (the set of RTP streams), then we can simple give #2 the
name of "#3 sender" or "#3 receiver", whatever #3 ends up being. I
have two ideas for what #3  could be:

Idea #1:  Logical Stream

Basically, use the phrase people often already use to describe this thing.

Logical Stream: Combination of RTP streams into one logical thing
Logical Stream Sender: The "source" of the logical stream
Logical Stream Receiver: The "sink" of the logical stream

Pros: People already use this term a lot; pretty clear what it means.
Cons:  If you say "stream", it's not clear if it's a logical stream or
RTP stream.

Idea #2:  RTP Track

Borrow the word that WebRTC uses.

RTP Track: Combination of RTP streams into one logical thing
RTP Track Sender: The "source" of the RTP track.
RTP Track Receiver: The "sink" of the RTP track.

This matches almost perfectly with the WebRTC taxonomy.  In WebRTC,
there is an RtpSender and an RtpReceiver which sends and receives
tracks, which are logical source/sink of media sent and received as
the combinations of multiple RTP streams.

Pros:  Short name with no ambiguity with "stream"; matches WebRTC very well
Cons:  Need to be clear when talking about an "RTP track" and a "WebRTC track".

The more I think about it, the more I like #2, and I'd like to propose
it as an option.

What does everyone think?

> Hi,
> In today’s AVTEXT session, the following issues related to the
> taxonomy draft were discussed.
>
> 1. MST/SST: I suggest new terminology focused on Single/Multiple
> Transport (rather than RTP Session) combined with Single/Multiple RTP
> Stream.
> MRMT (Multiple RTP Streams over Multiple Transports)
> MRST (Multiple RTP Streams over Single Transport)
> SRST (Single RTP Stream over Single Transport)
>
> 2. There is no term for referring to a media source or sink. Endpoint
> comes to mind, but that is fundamentally different in -taxonomy.
> Terminal is another possibility, but is generally not used in RTP
> (outside H.323). Another possibility is simply ‘media source/sink’, if
> the usage is not expected to be very high. This issue came up in
> drafting text for the BUNDLE RTP mid, which applies to all RTP streams
> between a pair of media sources/sinks.
>
> 3. There is no term for referring to the set of RTP streams between a
> media source and sink. Transport comes to mind, but that is
> fundamentally different in -taxonomy. Channel is another possibility,
> but is generally not used in RTP. Another possibility is simply ‘RTP
> streams between media source/sink X/Y’, if the usage is not expected
> to be very high. This issue came up in drafting text for the BUNDLE
> RTP mid, which applies to all RTP streams between a pair of media
> sources/sinks.
>
> Mo

---

From: Alex Eleftheriadis <[email-masked]>
Date: Wed, 23 Jul 2014 19:10:11 +0000

"Stream set" alone might work. "Logical stream" suggests that there is a higher-level abstraction that operates as a single stream (which does not appear to apply here). The word "track" is very much associated with multi-track audio, QuickTime, etc., and definetely things that live on a file/tape. 

For the acronyms, as long as the word "transport" does not create confusion, they look workable -- their long-hand version may indeed be preferrable but that would be an editorial choice. 

--A

On Jul 23, 2014, at 5:13 PM, Peter Thatcher <[email-masked]> wrote:

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

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 23 Jul 2014 15:18:39 -0400

In defense of "track", it's the word used in WebRTC, and it's led to
(as far as I have seen) zero confusion with multi-track audio,
QuickTime, or file/tape.  Plus, it would be fully an "RTP Track", just
like we have an "RTP Stream", and "track" would just be short-hand.

---

From: Alex Eleftheriadis <[email-masked]>
Date: Wed, 23 Jul 2014 21:55:53 +0000

You are right (personal bias). Still it may be missing the aggregation aspect.