Subject: [MMUSIC] Some more APPID questions

From: Harald Alvestrand <[email-masked]>
Date: Sun, 03 Nov 2013 19:22:00 +0100

On reviewing the appid document and some of the mail on it.. some questions.

I understand that an appid can serve multiple purposes; FEC binding and
loudest-speaker selection being two examples.

Some of these give information that is completely outside the context of
RTP / SDP, so they have to be application specified. Others are within
the RTP/SDP ecosystem.
Thus:

- Can one SSRC have mulitple appids?
This seems necessary for those multiple functions to work at the same
time without treading on each other, but isn't stated explicitly in the
draft.

- What's the uniqueness criterion for appids?
It would seem logical to have them unique at the source, but at least in
one case (recv-appid), it is given by the destination. Are we depending
on statistical uniqueness, or is the uniqueness governed by some other
mechanism?

I'll send off these 2 questions now, in order to make the thread be
focused....

-- 
Surveillance is pervasive. Go Dark.

---

From: "Roni Even" <[email-masked]>
Date: Sun, 3 Nov 2013 23:49:51 +0200

Hi Harald,
The current draft is still not mature enough and the presentation will have
some information which is not there and some of the text in the 00 version
that is not in the 01 version may come back.

An SSRC can have multiple appIds example is in a three camera system one
appID for active speaker which is now the left camera having a different
appID

The uniqueness of appID should be per media packet stream.

Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Harald Alvestrand
> Sent: 03 November, 2013 8:22 PM
> To: mmusic
> Subject: [MMUSIC] Some more APPID questions
> 
RTP /
> SDP, so they have to be application specified. Others are within the
RTP/SDP
> ecosystem.
> This seems necessary for those multiple functions to work at the same time
> without treading on each other, but isn't stated explicitly in the draft.
> 
one
> case (recv-appid), it is given by the destination. Are we depending on
statistical
> uniqueness, or is the uniqueness governed by some other mechanism?
> 
focused....
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Martin Thomson <[email-masked]>
Date: Sun, 3 Nov 2013 14:04:56 -0800

> The uniqueness of appID should be per media packet stream.

You mean "packet stream"?

http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-03#section-2.1.10

Because I don't think that that is particularly useful.

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 03 Nov 2013 23:30:35 +0100

> The uniqueness of appID should be per media packet stream.
so if you have

ssrc A: appid 45
ssrc B: appid 27

this means exactly the same thing as

ssrc A: appid 45
ssrc B: appid 45

?

This seems to create issues when you have a single appid that is moving
around between SSRCs.

---

From: "Roni Even" <[email-masked]>
Date: Mon, 4 Nov 2013 00:32:32 +0200

> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: 04 November, 2013 12:31 AM
> To: Roni Even; 'mmusic'
> Subject: Re: [MMUSIC] Some more APPID questions
> 
> > The current draft is still not mature enough and the presentation will
> > have some information which is not there and some of the text in the
> > 00 version that is not in the 01 version may come back.
> >
> > An SSRC can have multiple appIds example is in a three camera system
> > one appID for active speaker which is now the left camera having a
> > different appID
> >
[Roni Even] This is not allowed, the appId is unique per media stream or
what you call SSRC
> This seems to create issues when you have a single appid that is moving
around
> between SSRCs.

---

From: "Roni Even" <[email-masked]>
Date: Mon, 4 Nov 2013 00:35:11 +0200

around
> between SSRCs.
[Roni Even] The mapping from AppID to SSRC should be in SDES or RTP header
extension, example is appID 45 that can be first SSRC A and then SSRC B if
appId represent the active speaker.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 04 Nov 2013 01:24:59 +0100

> appId represent the active speaker. 

But if uniqueness of appids is per SSRC, then SSRC B might already be
using appid 45 for something else.

If we're using an appid for some property that can jump around between
SSRCs, the uniqueness of that appid must be guaranteed over the whole
context it's jumping around inside, I think. I'm worried if I can't
figure out what that context is.

---

From: "Roni Even" <[email-masked]>
Date: Mon, 4 Nov 2013 10:02:01 +0200

Harald,

If you map appID:45 to SSRC B also in RTP header and afterwards have
appID:45 map to SSRC A it means that you replaced SSRC B with SSRC A for
appId 45. The example is if appId 45 is the active speaker and it starts
from left camera with SSRC B and changes to right camera with SSRC A.

What is allowed is to have appID 45 and appID 27 both map to SSRC A. example
is appID 45 is active speaker and appID 27 is left camera and left camera is
the current active speaker.

Roni

> Sent: 04 November, 2013 2:25 AM
> To: Roni Even; 'mmusic'
> >>> The current draft is still not mature enough and the presentation
> >>> will have some information which is not there and some of the text
> >>> in the
> > [Roni Even] The mapping from AppID to SSRC should be in SDES or RTP
> > header extension, example is appID 45 that can be first SSRC A and
> > then SSRC B if appId represent the active speaker.
> >
> 
using
> appid 45 for something else.
> 
context
> it's jumping around inside, I think. I'm worried if I can't figure out
what that
> context is.

---

From: "Roni Even" <[email-masked]>
Date: Mon, 4 Nov 2013 10:17:48 +0200

Yes, packet stream.
They keep changing the names. 
Roni

> From: Martin Thomson [mailto:[email-masked]]
> Sent: 04 November, 2013 12:05 AM
> To: Roni Even
> Cc: Harald Alvestrand; mmusic

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 04 Nov 2013 12:54:38 +0100

> the current active speaker.

Roni,

we are not communicating; I may not have expressed myself clearly.

my question was "what's the scope of uniqueness for appIDs?"

That is - within what context can I assume that two appIDs are different
if they serve different purposes or identify different things - and what
control point inside that context guarantees the uniqueness?

I can imagine much confusion resulting from collision of appIDs, and
want to know how I can be sure it won't happen.

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 4 Nov 2013 15:57:05 +0000

AppIDs need to be unique with an RTP session in order to work for the use cases we've identified so far.

There may be use cases that would like to define them to be unique more broadly -- presumably within a multimedia session, across several RTP sessions -- and enforcing that wouldn't break anything about the mechanism, I think, if it turns out to be useful.

It's the responsibility of the signaling mechanism that negotiates the AppID values to ensure uniqueness.  The current draft is a little vague on how you do this in SDP, because we haven't quite figured out how much AppID values should be receiver-selected vs. sender-selected.  (Sender-selected makes more sense conceptually, but doesn't solve the Bundle early-media race condition with an offered recvonly stream.)