Subject: [avtext] Proposed RTP Taxonomy updates

From: Bo Burman <[email-masked]>
Date: Wed, 11 Jun 2014 08:52:33 +0000

Dear all,

Based on my interpretation of the mailing list discussions, these are the edits that are planned for the next version:

*         Re-structure the entire document such that alternate usages, describing existing terms using Taxonomy wording, are separated out into their own (alphabetically sorted) sub-sections, making it possible to find them through the table of contents

*         Remove any sub-section level 4 numbering possibly remaining after the above change

*         Change the term "Packet Stream" to "RTP Stream" throughout the document, since "Packet Stream" is too unspecific

*         Remove all topologies discussion in section 4 to avoid any conflict or multiple description of topologies, even if informational.

*         In the above, keep one informational figure that depicts one example of the terms Communication Session, Multimedia Session, RTP Session, and End Point, and move that figure, as an example, to the Concepts sub-section on Communication Entities.

*         Clarify in Synchronization Context section that CNAME is not an End Point identifier

*         In that same section, point out that although RTP uses NTP-format timestamps, they don't need to be NTP synchronized to be useful. Also reference draft-ietf-avtcore-clksrc.

*         Add a new relation section with an explicit explanation of RTP duplication as of RFC 7198, preferably with a figure.

*         Remove the statement that a CLUE Media Capture is identified via indexed notation, since it is incorrect.

*         Make it clear in the characteristics of RTP Stream that the SSRC identifier of a single RTP Stream can change, but only as a result of SSRC collision or a clock rate change (referring RFC 7160)

*         Clarify that multiple 6190 packet streams from a single Media Source can be present in a single RTP Session, despite what is said in 6190 section 1.2.2

*         Remove the current discussion on and definition of MST-SS/MS and SST-SS/MS

*         Mention that an "End Point" is typically a single "host"

Unless there are objections, I plan to submit an updated draft including the above changes during next week.

Comments and questions are welcome!

Cheers,
Bo

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Jun 2014 11:25:46 -0700

Bo said: 
·        
Remove the current discussion on and definition of MST-SS/MS and SST-SS/MS
Why is this being removed?  Personally, I thought it was useful.

---

From: Emil Ivov <[email-masked]>
Date: Wed, 11 Jun 2014 21:33:11 +0300

On 11.06.14, 21:25, Bernard Aboba wrote:
> Bo said:
>
>
> ·Remove the current discussion on and definition of MST-SS/MS and SST-SS/MS
>
>

+1

-- 
https://jitsi.org

---

From: Alex Eleftheriadis <[email-masked]>
Date: Wed, 11 Jun 2014 18:47:21 +0000

+1

On Jun 11, 2014, at 9:33 PM, Emil Ivov <[email-masked]> wrote:

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

---

From: Bo Burman <[email-masked]>
Date: Tue, 17 Jun 2014 08:53:28 +0000

My misunderstanding from previous discussions in that case; I will definitely not remove it if it is felt useful!

> -----Original Message-----
> From: Alex Eleftheriadis [mailto:[email-masked]]
> Sent: den 11 juni 2014 20:47
> To: Emil Ivov
> Cc: Bernard Aboba; Bo Burman; [email-masked]
> Subject: Re: [avtext] Proposed RTP Taxonomy updates
> 
> +1
> 
> >> *Remove the current discussion on and definition of MST-SS/MS and SST-SS/MS
> >>
> >>

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 17 Jun 2014 14:14:18 +0000

(Speaking as an individual.)

My argument — which may be what you were remembering — was that this distinction was useful, but secondary.

In my view, the primary distinction is between single-stream encoding and multi-stream encoding (whatever term we end up using for this) — i.e., whether scalable media is encoded as one RTP packet stream, or several.

Following up to that is the decision about how these RTP packet streams are allocated to RTP sessions, if you're using a multi-stream encoding, and how correlation is done to indicate the association between the streams.  And this is definitely an important discussion to have, and we need good terminology for it.

That said, I think the term “MST-SS” — if that’s meant to expand to “Multi-Session Transmission - Single Stream” — doesn’t make any sense, because a single RTP packet stream can only be in a single RTP session.  I think the distinction people are trying to make with this term is whether streams in multiple sessions are correlated by giving them the same SSRC, or whether they have some other correlation mechanism?  But if so, we need a better term for this.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 17 Jun 2014 10:43:05 -0400

I had the same question about MST-SS. But as I understand it, this is to mean a single stream per session, not the same SSRC for every session. 

> On Jun 17, 2014, at 10:14 AM, "Jonathan Lennox" <[email-masked]> wrote:
>

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 17 Jun 2014 14:46:50 +0000

Oh, I see — MST-SS means multiple packet streams, and multiple sessions, but a 1:1 mapping between streams and sessions (as opposed to having more packet streams than sessions, and mapping multiple streams into each session).

I guess that’s a useful distinction, though it’s getting a bit into the weeds.  I don’t think MST-SS is a good name for this, though.

---

From: Bo Burman <[email-masked]>
Date: Tue, 17 Jun 2014 14:48:18 +0000

Yes, you are right Bernard. That is my preferred interpretation.

I would like to interpret MST-SS to mean multiple RTP streams, spread across multiple RTP Sessions, with the restriction that there can only be a single RTP Stream _per RTP Session_. In that case, you can potentially use the RTP Session identifier (whatever that is, up to some RTP-external signaling) to distinguish the different RTP Streams in the MST and could even possibly ignore what SSRC they use.

So, I'd like to think of -SS/MS to be _scoped_ by the preceding SST/MST, in terms of semantics. That way, all four alternatives make sense to me.

Regarding identification and relation:

SST-SS: Trivial, a single RTP Stream from a single Media Source.

SST-MS: Multiple RTP Streams in a single RTP Session are distinguished by their SSRCs, and (I guess?) each such SST-stream would correspond to a single-stream encoding of a single Media Source.

MST-SS: A single RTP Stream in each of multiple RTP Sessions, where each such single RTP Stream could be from any one of potentially multiple Media Sources, and the method to relate which RTP Streams belong to a common Media Source is (currently) unknown. If there is only a single Media Source, there is no problem to relate the RTP Streams because they all belong to the same Media Source. 

MST-MS: Multiple (one or more) RTP Streams in each of multiple RTP Sessions, where each RTP Stream could be from any one of potentially multiple Media Sources, and the method to relate which RTP Streams belong to a common Media Source is (currently) unknown.

Cheers,
Bo

> From: Jonathan Lennox [mailto:[email-masked]]
> Sent: den 17 juni 2014 16:47
> To: Bernard Aboba
> Cc: Bo Burman; [email-masked]
> Oh, I see - MST-SS means multiple packet streams, and multiple sessions, but a 1:1 mapping between streams and
> sessions (as opposed to having more packet streams than sessions, and mapping multiple streams into each session).
> 
> I guess that's a useful distinction, though it's getting a bit into the weeds.  I don't think MST-SS is a good name for this,
> though.
> 
> >> My argument - which may be what you were remembering - was that this distinction was useful, but secondary.
> >>
> >> In my view, the primary distinction is between single-stream encoding and multi-stream encoding (whatever term we
> end up using for this) - i.e., whether scalable media is encoded as one RTP packet stream, or several.
> >>
> >> Following up to that is the decision about how these RTP packet streams are allocated to RTP sessions, if you're using a
> multi-stream encoding, and how correlation is done to indicate the association between the streams.  And this is
> definitely an important discussion to have, and we need good terminology for it.
> >>
> >> That said, I think the term "MST-SS" - if that's meant to expand to "Multi-Session Transmission - Single Stream" -
> doesn't make any sense, because a single RTP packet stream can only be in a single RTP session.  I think the distinction
> people are trying to make with this term is whether streams in multiple sessions are correlated by giving them the same
> SSRC, or whether they have some other correlation mechanism?  But if so, we need a better term for this.
> >>