Subject: [MMUSIC] comments on draft-even-mmusic-application-token-01

From: Paul Kyzivat <[email-masked]>
Date: Sun, 27 Oct 2013 14:35:09 -0400

Hi. Doing my pre-meeting reading. A few comments on this. Otherwise it 
looks good to me.

Many examples use a=appid and a=recv-appid without the colon.

Section 3.1.3:

       appid-attribute = "recv-appID:" token

       ; The base definition of "attribute" is in [RFC4566].

       ; (It is the content of "a=" lines.)

The comments are spurious here - there is no attribute.

ISTM it would be helpful to have an explicit specification of how this 
relates to RTP. IIUC, its something like the following:

- an RTP session MAY have one or more appid tokens
- at any point in time each appid token maps to at most
   one stream (SSRC) within the session.
- *new* appid:ssrc mappings MAY be initialized via SDP
- new appid:ssrc mappings MAY be initialized via receipt
   of the new RTPC SDES message or header extension
- existing appid:ssrc mappings MAY be updated via
   receipt of the new RTCP SDES message or header extension.

I'm not sure about what is supposed to happen if a new O/A defines a 
mapping in conflict with an existing one. I *think* it probably is to be 
ignored.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Sun, 27 Oct 2013 13:59:47 -0700

In addition to absent colons, the examples use a variety of uppercase
and lowercase characters.  Consistency would be helpful, unless the
intent is to highlight the fact that ABNF permits these to be in mixed
case.  (RFC 4566 is silent on the subject, so I assume that a=appid is
equivalent to a=ApPId, following RFC 5234; I'd rather that weren't the
case, but that seems to be the intent at least).

I'm not sure about the assertion regarding 1-1 correspondence between
appid and SSRC.  Putting the fact that SSRC can change aside, I
believe that the intent is to label the source, which can manifest as
multiple SSRCs.

Editorial: This document needs a serious proofread.  The spelling
seems right, but I'm continually being distracted by poor grammar as I
read through.  Doublespacing all the examples is annoying too.

On 27 October 2013 11:35, Paul Kyzivat <[email-masked]> wrote:
> Hi. Doing my pre-meeting reading. A few comments on this. Otherwise it looks
> good to me.
>
> I'm not sure about what is supposed to happen if a new O/A defines a mapping
> in conflict with an existing one. I *think* it probably is to be ignored.
>
>         Thanks,
>         Paul
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 27 Oct 2013 18:11:47 -0400

On 10/27/13 4:59 PM, Martin Thomson wrote:
> appid and SSRC.

Note that I said "at any point in time", and made provision for changing 
the mapping.

Even so, I am also not sure.

> Putting the fact that SSRC can change aside, I

I *thought* that for instance in case of FEC, the original stream and 
the repair stream would have the same appid. But the example showed 
otherwise.

I'd like the model to be spelled out. Then we wouldn't be wondering.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Sun, 27 Oct 2013 19:46:23 -0700

On 27 October 2013 15:11, Paul Kyzivat <[email-masked]> wrote:
> I *thought* that for instance in case of FEC, the original stream and the repair stream would have the same appid. But the example showed otherwise.

That's odd.  I'd have thought that too.

> I'd like the model to be spelled out. Then we wouldn't be wondering.

Yep.  Much better.  All it takes is something like 1 appid = 1 media source.

---

From: "Roni Even" <[email-masked]>
Date: Mon, 28 Oct 2013 16:57:02 +0200

Hi,
The appId is used to map to an SSRC so in the unified plan there can be more
than one RTP stream from a source like simulcast (see the new avtcore
simulcast-03 draft) but there can be an m-line for RTP stream like the CLUE
signaling examples. 
So there should be a different appIDd to the source and repair streams and
the association  is done using SDP group (RFC5956), note that the
association is very flexibly and the example we give is the case when one
repair stream is repairing three source streams from different cameras which
are different sources. This is feasible for a TP system. 
Having this FEC repair stream raises
 The question what is the msid of the repair stream and my thought was that
there is none (or all three?)

Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Martin Thomson
> Sent: 28 October, 2013 4:46 AM
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [MMUSIC] comments on draft-even-mmusic-application-token-01
> 
the
> repair stream would have the same appid. But the example showed otherwise.
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 28 Oct 2013 10:17:15 -0700

On 28 October 2013 07:57, Roni Even <[email-masked]> wrote:
> there can be an m-line for RTP stream

I have http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section-3.3
bookmarked, strangely enough, and the third paragraph is fairly clear
about the desired configuration, which is that multiple SSRCs are
grouped into the same m-line.

The issues regarding the use of a single FEC repair stream for
multiple sources is where the "can" part comes in, but I wouldn't have
used that as the starting position for this appid work.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Oct 2013 13:32:39 -0400

Roni,

>   receipt of the new RTCP SDES message or header extension.

including the 2nd point above. Is that true?

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Mon, 28 Oct 2013 19:54:21 +0200

Hi Paul,
One thing I am trying to look at is that we can use the appID to create the
binding to SSRC in the RTP header and RTCP SDES and have the binding to SSRC
in SDP as optional.
This will take way the need to do binding like a=ssrc:xxxx cname:yyyy
srcname:zzz which should be done in the RTCP SDES.
Roni

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 28 October, 2013 7:33 PM
> To: Roni Even; 'Martin Thomson'
> Cc: [email-masked]
> > The appId is used to map to an SSRC so in the unified plan there can
> > be more than one RTP stream from a source like simulcast (see the new
> > avtcore
> > simulcast-03 draft) but there can be an m-line for RTP stream like the
> > CLUE signaling examples.
> > So there should be a different appIDd to the source and repair streams
> > and the association  is done using SDP group (RFC5956), note that the
> > association is very flexibly and the example we give is the case when
> > one repair stream is repairing three source streams from different
> > cameras which are different sources. This is feasible for a TP system.
> >   The question what is the msid of the repair stream and my thought
> > was that there is none (or all three?)
> 
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Martin Thomson

---

From: "Roni Even" <[email-masked]>
Date: Tue, 29 Oct 2013 07:06:01 +0200

Martin,
1. My understanding that unified is only applicable to RTCweb but not a general MMUSIC solution. A singe media stream per m-line that may be grouped  is also a case for MMUSIC. 
2. The motivation for appID is also having multiple media streams (each with a different SSRC) in a single m-line representing a media source. (unified).
3. The FEC example is more a corner case and a question I had about msid and unified but not the motivation for appID
Roni

> From: Martin Thomson [mailto:[email-masked]]
> Sent: 28 October, 2013 7:17 PM
> To: Roni Even
> Cc: Paul Kyzivat; [email-masked]
> bookmarked, strangely enough, and the third paragraph is fairly clear about
> the desired configuration, which is that multiple SSRCs are grouped into the
> same m-line.
> 
> The issues regarding the use of a single FEC repair stream for multiple sources
> is where the "can" part comes in, but I wouldn't have used that as the starting
> position for this appid work.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Oct 2013 11:36:00 -0400

Roni,

I'm still not sure I understand. I'm going to repeat my characterization 
about what I understand one more time:

Can you either confirm the above is correct, or else update it so it is 
correct?

	Thanks,
	Paul

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 29 Oct 2013 21:34:51 +0000

Hi, Paul --

On Oct 29, 2013, at 11:36 AM, Paul Kyzivat <[email-masked]>
 wrote:

> Roni,
> 
> I'm still not sure I understand. I'm going to repeat my characterization about what I understand one more time:
> 
> - an RTP session MAY have one or more aphid tokens

Yes.

>  one stream (SSRC) within the session.

This one isn't right.  An appid maps to at most one *source* -- but in situations where multiple streams (SSRCs) make up one source, in some cases we'll want them to be associated by having them have the same appid.

In particular, I think, RTX and single-stream-repair FEC streams should probably be associated to their primary stream using appid.  (Multi-stream-repair FEC is more complicated, as the draft discusses.  Yes, we probably shouldn't have jumped to the more complicated case so quickly in the examples.)

However, it's not as simple as saying that the same appid applies to all the streams of the source.

The important cases where a single source's streams will be split across multiple appid values are simulcast and MST layered codecs.  An important use case of appid is to disambiguate the various simulcast streams and layers; however, in the taxonomy draft's terminology these are a single source, and Unified puts them into a single m-line.  It's not clear to me yet how Unified is planning to signal these cases (I know Magnus has a proposal, but I haven't read it in detail yet), but appid will need to be able to handle it.

> - *new* appid:ssrc mappings MAY be initialized via SDP

Yes.

>  of the new RTPC SDES message or header extension

Yes.  Only for appid values whose semantics are already specified (without an SSRC mapping) in SDP or elsewhere, however; otherwise there's no semantics to attach them to.  (Early media cases may need more thought here.)

>  receipt of the new RTCP SDES message or header extension.

Yes.

> 
> Can you either confirm the above is correct, or else update it so it is correct?
> 
> 	Thanks,
> 	Paul
> 
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Oct 2013 15:00:47 -0700

> This one isn't right.  An appid maps to at most one *source* -- but in situations where multiple streams (SSRCs) make up one source, in some cases we'll want them to be associated by having them ha…

Thanks Jonathan, I had hoped that this was the intended answer.  It's
the only one that makes any sense.

> In particular, I think, RTX and single-stream-repair FEC streams should probably be associated to their primary stream using appid.  (Multi-stream-repair FEC is more complicated, as the draft discu…

The SDES extension or RTP extension could identify an SSRC as
contributing to multiple sources in those complicated scenarios.  The
simple case is where each SSRC contributes to just a single source.
Maybe that's too much information for an RTP extension, in which case
you could send the appid indications for each source a) when the
contribution commences - i.e., at the start of transmission; and b)
interleaved when there is more than one appid.  That assumes that the
SSRC can't ever stop contributing to a given source, which I think is
a safe assumption.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Oct 2013 18:04:40 -0400

Jonathan,

Thanks for the clarifications. I have more questions.

> This one isn't right.  An appid maps to at most one *source* -- but in situations where multiple streams (SSRCs) make up one source, in some cases we'll want them to be associated by having them ha…

I thought that in RPT terms a source is equivalent to an SSRC.
Are you talking about a "Media Source" according to the taxonomy?

If an appid could only map to *one* ssrc, then changes are easy - when 
you get a new mapping then the old one goes away.

But if an appid can map to multiple SSRCs, then that complicates 
changing the mapping. Getting a mapping of the same appid to a new ssrc 
doesn't necessarily invalidate any old mappings. It might be necessary 
to explicitly unmap it. I don't see how you would do that.

> In particular, I think, RTX and single-stream-repair FEC streams should probably be associated to their primary stream using appid.  (Multi-stream-repair FEC is more complicated, as the draft discu…

I presume it doesn't make sense to give two arbitrary SSRCs the same 
appid. Is there a way to revise/replace this statement with one that is 
correct and says something useful?

> The important cases where a single source's streams will be split across multiple appid values are simulcast and MST layered codecs.  An important use case of appid is to disambiguate the various s…

ISTM that it is important to distinguish valid mappings from invalid ones.

> Yes.  Only for appid values whose semantics are already specified (without an SSRC mapping) in SDP or elsewhere, however; otherwise there's no semantics to attach them to.  (Early media cases may n…

I'm not sure I follow this.

Suppose there was nothing in SDP. But a new appid shows up in RTCP SDES. 
It could (via a common value) tie together a raw stream with an RTX or 
FEC stream. It just doesn't say what it is used for. But putting it in 
SDP doesn't say what it is used for either.

In CLUE, the semantics could be in an Advertisement. (But, if we use an 
SDP label to reference an encoding, then I guess we would need the appid 
in the SDP too in order to tie those together.)

>>   receipt of the new RTCP SDES message or header extension.

I'm still concerned about appid:ssrc mappings in subsequent 
offers/answers. If the first O/A defined one mapping, and a subsequent 
O/A revised that (different ssrc for the same appid) would that mapping 
change take effect?

Would the answer change depending on whether any media has been 
send/received with that ssrc?

Would the answer change depending on whether the mapping has been 
updated via RTCP SDES message or header extension?

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Wed, 30 Oct 2013 00:23:49 +0200

Paul,
Inline
Roni

> Sent: 29 October, 2013 5:36 PM
[Roni Even] This is correct but not important, an m-line can have one or more appIds toke
>    one stream (SSRC) within the session.
[Roni Even] To one media stream - see the taxonomy draft
> - *new* appid:ssrc mappings MAY be initialized via SDP
[Roni Even] Yes
>    of the new RTPC SDES message or header extension
[Roni Even] This is not a may but that is the MUST and we need both SDES and RTP header but the RTP header should have precedence in case of race condition. This is to allow the binding between a media stream in SDP to an SSRC to happen in the RTP when it is used.

>    receipt of the new RTCP SDES message or header extension.
[Roni Even] Yes, RTP header has precedence over SDES in case of race condition.
> > 1. My understanding that unified is only applicable to RTCweb but not a
> general MMUSIC solution. A singe media stream per m-line that may be
> grouped  is also a case for MMUSIC.
> > 2. The motivation for appID is also having multiple media streams (each with
> a different SSRC) in a single m-line representing a media source. (unified).
> > 3. The FEC example is more a corner case and a question I had about
> > msid and unified but not the motivation for appID Roni
> >
> >> I have
> >> http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#section
> >> -
> >> 3.3
> >> multiple sources is where the "can" part comes in, but I wouldn't
> >> have used that as the starting position for this appid work.
> >
> >

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 30 Oct 2013 19:27:23 +0000

> SSRC can't ever stop contributing to a given source, which I think is

Hi, Martin -- there are several separate issues here, which it's good to keep separate.

One is that a set of streams can make up a single source, associated with a single appid, as in RTX and FEC.  Each stream is associated to a single source in this sense, except in multi-stream-repair FEC cases.

However, which source corresponds to an appid can change dynamically.  The primary use case I personally see for this is loudest-speaker switching, where the appid corresponds to a requested loudest speaker.

More controversially, I've also proposed that a single source can satisfy more than one appid at a time -- as in the case when you've requested both my video, and the current loudest speaker video, and right now I'm the current loudest speaker.

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 30 Oct 2013 19:47:22 +0000

> Are you talking about a "Media Source" according to the taxonomy?

Right, yes; I'm trying to follow the taxonomy's terminology distinction.

> If an appid could only map to *one* ssrc, then changes are easy - when you get a new mapping then the old one goes away.
> 
> But if an appid can map to multiple SSRCs, then that complicates changing the mapping. Getting a mapping of the same appid to a new ssrc doesn't necessarily invalidate any old mappings. It might be necessary to explicitly unmap it. I don't see how you would do that.

> I presume it doesn't make sense to give two arbitrary SSRCs the same appid. Is there a way to revise/replace this statement with one that is correct and says something useful?
> 

Hm, that's a good point.

I think the right formulation is that, in the terminology of the latest taxonomy draft, an appid (at any given time) encompasses a single Source Packet Stream and its associated Redundancy Packet Streams.

In all cases I know about, it's possible to differentiate Source Packet Streams from Redundancy Packet Streams by payload type.

There is still an issue of getting the grouping of these streams correct when an appid changes sources, though; this will need a little bit of thought.

> ISTM that it is important to distinguish valid mappings from invalid ones.

Right, I agree.

> Suppose there was nothing in SDP. But a new appid shows up in RTCP SDES. It could (via a common value) tie together a raw stream with an RTX or FEC stream. It just doesn't say what it is used for. But putting it in SDP doesn't say what it is used for either.
> 
> In CLUE, the semantics could be in an Advertisement. (But, if we use an SDP label to reference an encoding, then I guess we would need the appid in the SDP too in order to tie those together.)

My point is that if you receive an appid in RTP that you've never heard of in signaling (whichever signaling you're using), you don't know what it means and can't do anything useful with it.  Thus my early-media analogy -- possibly you can assume that signaling describing the appid is forthcoming.

> I'm still concerned about appid:ssrc mappings in subsequent offers/answers. If the first O/A defined one mapping, and a subsequent O/A revised that (different ssrc for the same appid) would that mapping change take effect?
> 
> Would the answer change depending on whether any media has been send/received with that ssrc?
> 
> Would the answer change depending on whether the mapping has been updated via RTCP SDES message or header extension?

My inclination would be to say that if you've ever sent a mapping for an appid in RTP/RTCP, don't put an appid:ssrc mapping into subsequent offer/answer messages.  From a receiver point of view, this is equivalent to saying that appid:ssrc mappings in SDP are ignored if you've received mappings in RTP/RTCP.

I don't think RTP and RTCP should be distinguished in this respect.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Oct 2013 15:24:48 -0700

> However, which source corresponds to an appid can change dynamically.  The primary use case I personally see for this is loudest-speaker switching, where the appid corresponds to a requested loudes…

This is the one that I didn't see as needing appid.  I'm comfortable
with the fact that a single appid can have multiple SSRCs.  That's
fairly easy.

I'm concerned now that this is conflating this other need, namely the
need to track a thing that migrates between SSRCs (or groups thereof)
over time.  Conflation like this complicates things.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Oct 2013 08:51:03 -0700

> [Roni Even] This is correct but not important, an m-line can have one or more appIds toke

Historically there was a 1:1 relationship between m-lines and RTP 
sessions. But now we have Bundle, which is changing that relationship. 
And I think AppId can be involved in understanding the relationship.

An RTP implementation will be looking at what arrives in RTP packets, 
and trying to do the correlation with information from SDP. I am trying 
to clarify the relationships.

So this statement, on its own may be somewhat simplistic, is a 
foundation for the following points. I think the "namespace" for AppIds 
must be an RTP session.

> [Roni Even] To one media stream - see the taxonomy draft

OK, good. Everybody seems to be agreeing on this. I suggest being very 
explict, so no future reader is confused.

> [Roni Even] This is not a may but that is the MUST and we need both SDES and RTP header but the RTP header should have precedence in case of race condition. This is to allow the binding between a m…

My point with the MAY was that the sender might not use this mechanism.
There are two mechanisms:
- SDP a=appid
- RTCP SDES & RTP header (IIUC these are two parts of one mechanism)

They are both optional to use.

At least that is what I understand.

> [Roni Even] Yes, RTP header has precedence over SDES in case of race condition.

I'm not sure what "precedence" means here. Doesn't each update the state 
when it is received?

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Thu, 31 Oct 2013 18:37:35 +0200

Hi guys,
I am not sure about having the same appId for multiple media streams
One example you gave is FEC. Assume that we have a "unified" offer with a simulcast source with two simulcast configuration (low res and high res) each will have a different appId and one repair stream for both. What appID to use.
Same applies for layered codec when you have a base layer enhancement layer and one repair stream (this is even more realistic than the simulcast case)
Roni

> Sent: 30 October, 2013 12:01 AM
> To: Jonathan Lennox
> Cc: Paul Kyzivat; Roni Even; <[email-masked]>
> >> - at any point in time each appid token maps to at most  one stream
> >> (SSRC) within the session.
> >
> > This one isn't right.  An appid maps to at most one *source* -- but in
> situations where multiple streams (SSRCs) make up one source, in some cases
> we'll want them to be associated by having them have the same appid.
> 
> Thanks Jonathan, I had hoped that this was the intended answer.  It's the only
> one that makes any sense.
> 
> > In particular, I think, RTX and single-stream-repair FEC streams
> > should probably be associated to their primary stream using appid.
> > (Multi-stream-repair FEC is more complicated, as the draft discusses.
> > Yes, we probably shouldn't have jumped to the more complicated case so
> > quickly in the examples.)
> 
> The SDES extension or RTP extension could identify an SSRC as contributing to
> multiple sources in those complicated scenarios.  The simple case is where
> each SSRC contributes to just a single source.
> Maybe that's too much information for an RTP extension, in which case you
> could send the appid indications for each source a) when the contribution
> commences - i.e., at the start of transmission; and b) interleaved when there is
> more than one appid.  That assumes that the SSRC can't ever stop contributing
> to a given source, which I think is a safe assumption.