Subject: [AVT] draft-schierl-mmusic-layered-codec

From: Cullen Jennings <[email-masked]>
Date: Fri, 3 Nov 2006 18:24:46 -0800

Few comments ...

I hope others that know more than me look at the SSRC stuff.

It's sort of a NIT but in section 3.2 were you mention that at least  
conceptuality you don't need to encrypt the enhancement layer ...  
this seems like it is probably a stretch in many cases. Imagine video  
where the base had only the DC coefficients of the DCT and the  
enhanced layer had all the other coefficients. The enhancements layer  
would by itself would look weird but clearly have  enough detail to  
understand be somewhat recognizable about what was going on in the  
video. I think I would rephrase to just say the base and enhancement  
layers ma have different security requirements.

On Oct 29, 2006, at 3:32 AM, Thomas Schierl wrote:

>
> Hi all,
>
> A new version of draft-schierl-mmusic-layered-codec on "Signaling  
> of layered
> and multi description media in Session Description Protocol (SDP)" is
> available.  Please review it.  Unfortunately, we ran out of time,  
> thus it is
> somewhat inconsistent and less matured than we would have wished.   
> Anyway,
> there are open questions within the draft, which may require at  
> least a
> quick review.
>
> ftp://ftp.ietf.org/internet-drafts/draft-schierl-mmusic-layered- 
> codec-01.txt
>
> The draft will be presented in mmusic as well as in avt, because of  
> its
> relation to the RTP Payload Format for SVC Video.
>
> ftp://ftp.ietf.org/internet-drafts/draft-wenger-avt-rtp-svc-03.txt
>
> Thanks and see you in San Diego,
> Thomas
>
>
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Thomas Schierl" <[email-masked]>
Date: Sat, 4 Nov 2006 12:13:29 +0100

Yes you are right. This way of encryption is only suitable for preventing
users from reconstructing a reasonable quality of the video. But it does not
allow for hiding all information of the video, thus it may be possible to
reconstruct at least some data based on intra, etc.

We will include a more precise statement in the next version.

Thanks,
Thomas

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Saturday, November 04, 2006 3:25 AM
> To: AVT WG; Thomas Schierl
> Cc: Stephan Wenger; [email-masked]; Jonathan Lennox
> Subject: draft-schierl-mmusic-layered-codec
> 
> 
> Few comments ...
>

---

From: Colin Perkins <[email-masked]>
Date: Sat, 4 Nov 2006 11:27:30 -0800

> I hope others that know more than me look at the SSRC stuff.

It comes from the SVC payload format draft, so I hope that'll be  
discussed in AVT. The idea of multiplexing layers by SSRC is okay,  
but using numeric SSRC values to indicate layering dependency is  
unusual, to say the least. I'd like to understand more on why this  
solution was chosen, and whether the requirements driving it are  
sensible.

Colin

---

From: "Thomas Schierl" <[email-masked]>
Date: Sun, 5 Nov 2006 18:57:34 +0100

Dear Collin,

Not using explicit, numeric values for the SSRC multiplexing was exactly our
aim. The digit following the "a=ssrcmux:" attribute only indicates the count
of different SSRCs used within the RTP session. The assignment of a certain
SSRC to a layer or to a combination of layers is done implicitly. I.e. the
layer of highest importance is assigned to the SSRC with the numeric highest
value within the RTP session. Layers with lower importance are assigned in
decreasing order of importance to SSRC values of decreasing values, whatever
those values may be. 
With having such a constraint, a receiver may first find out which SSRCs are
present in a RTP session. And second, it may execute a simple adaptation on
the media relying on that constraint.
With the approach described above, it becomes further possible to
differentiate between layers or combination of layers based on SSRCs without
negotiating numeric SSRC values.

Best regards,
Thomas

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Saturday, November 04, 2006 8:28 PM
> To: Cullen Jennings
> Cc: AVT WG; Thomas Schierl; Stephan Wenger; [email-masked];
> Jonathan Lennox
> Subject: Re: [AVT] draft-schierl-mmusic-layered-codec
>

---

From: David R Oran <[email-masked]>
Date: Sun, 5 Nov 2006 13:33:12 -0500

> decreasing order of importance to SSRC values of decreasing values,  
I can see how you can do this if all layers are known at the  
beginning of the session. If you have K layers, you generate K SSRCs,  
sort them in order as 32-bit unsigned integers, and then assign the  
layers to the SSRCs in "value" order.

What I don't see is how you can do this if layers can be added mid- 
session, since you can't arrange for a randomly generate SSRC value  
to fall in any particular place in the layer ordering.

---

From: "Thomas Schierl" <[email-masked]>
Date: Sun, 5 Nov 2006 20:04:46 +0100

Comments inline,
Thomas 

> From: David R Oran [mailto:[email-masked]]
> Sent: Sunday, November 05, 2006 7:33 PM
> To: Thomas Schierl
> Cc: 'Colin Perkins'; 'Cullen Jennings'; 'Jonathan Lennox'; 'Stephan
> Wenger'; 'AVT WG'; [email-masked]

Application should know how much layer can show up in the session, since
adding a layer may require new code specific signaling. Thus at beginning
all possible parameters of the session must be available and enough SSRCs
should be reserved within the session.

---

From: Colin Perkins <[email-masked]>
Date: Sun, 5 Nov 2006 11:05:30 -0800

On 5 Nov 2006, at 10:33, David R Oran wrote:
> beginning of the session. If you have K layers, you generate K  
> SSRCs, sort them in order as 32-bit unsigned integers, and then  
> assign the layers to the SSRCs in "value" order.
>

You'd presumably choose non-randomly, but even that could be  
disrupted by other sources which might randomly (or maliciously)  
choose the same number, and force a change according to the SSRC  
collision detection rules.

Colin

---

From: "Thomas Schierl" <[email-masked]>
Date: Sun, 5 Nov 2006 20:55:15 +0100

> Sent: Sunday, November 05, 2006 8:06 PM
> To: David R Oran
> Cc: Thomas Schierl; 'Cullen Jennings'; 'Stephan Wenger'; 'AVT WG';
> 'Jonathan Lennox'; [email-masked]

In the SVC payload format draft in section 6.2, we proposed a random
mechanism using SSRC subspaces. Anyway, you are right with the collision
problem. For that reason we propose to use this mechanism within
single-sender scenarios only. A further reason for that is that you cannot
differentiate between senders by the implicitly assigned SSRCs. 

Thomas

---

From: Colin Perkins <[email-masked]>
Date: Sun, 5 Nov 2006 11:59:08 -0800

On 5 Nov 2006, at 11:55, Thomas Schierl wrote:
> single-senps://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Sun, 5 Nov 2006 11:59:08 -0800

> differentiate between senders by the implicitly assigned SSRCs.

How do you prevent SSRC clashes with receivers? Restricting this to  
single-sender sessions doesn't help.

Colin

der scenarios only. A further reason for that is that you  
> cannot

How do you prevent SSRC clashes with receivers? Restricting this to  
single-sender sessions doesn't help.

Colin

---

From: "Thomas Schierl" <[email-masked]>
Date: Sun, 5 Nov 2006 21:11:40 +0100

> Sent: Sunday, November 05, 2006 8:59 PM
> To: Thomas Schierl
> Cc: 'David R Oran'; 'Cullen Jennings'; 'Stephan Wenger'; 'AVT WG'; Ye-
> [email-masked]; 'Jonathan Lennox'

By using these SSRC subspaces per layer, form which the SSRC is chosen. If
you have SSRC clashes with receivers, you need to select another SSRC from
the subspace. 

Thomas

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Mon, 6 Nov 2006 09:31:48 -0800

> By using these SSRC subspaces per layer, form which the SSRC 
> is chosen. If you have SSRC clashes with receivers, you need 
> to select another SSRC from the subspace. 
> 
> Thomas

The above sounds like a generic extension to RFC3550. Seems like SVC
payload format draft along with this draft require an update to RFC3550.
Am I correct?

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 6 Nov 2006 09:43:23 -0800

> payload format draft along with this draft require an update to  

I think you're not.  It's certainly not our intention.  When you, as  
the media sender, detect SSRC collision, you need to select a new  
SSRC from a smaller numbering space than usual to keep the model  
working, but it's still a random selection.  The spirit of the  
algorithm is IMHO not violated.  The smaller numbering space is  
fairly large, 2^26 when the maximum numbers of layers is employed;  
larger, when fewer layers are in use.    All this is completely under  
media sender control, and an implementation issue.

Stephan

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Mon, 6 Nov 2006 13:18:44 -0800

>differentiate between senders by the implicitly assigned SSRCs.

You can use CNAME to identify the senders and it might be possible to use it to address multi sender scenarios.

I am also not comfortable with loose SSRC value rules in a payload format draft.

Both drafts look somewhat incompelte as they are not addressing multi sender scenarios. Having a solution for multi sender scneario and applying (optimizing)  it for single sender scenario would be a better approach.

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 6 Nov 2006 14:51:07 -0800

Hi Hari,

It's true that multi-sender support and SSRC mux are currently  
mutually exclusive.  But that does not mean that we do not support  
multi-sender scenarios.  Mixer-based translation works perfectly well  
for multi-sender scenarios.  So we have already followed your  
suggestion of having a working general solution, and an optimized one  
for single sender scenarios.  We have not been not successful in  
finding a model that would preserve the application space we  
introduced SSRC mux for (MANEs outside the security context), and at  
the same time allows multiple senders.

Making use of CNAME sounds like an interesting idea.  What a MANE  
would need to do is to monitor SRs to figure out the mapping between  
an SSRC value that appears in the stream and the sender (where an  
implied mapping would be: one sender == one scalable bitstream).   
That should work.  Perhaps we need to document this and call the  
whole SSRC mux problem done.  Need to think this through, though.

Stephan

On  6 Nov2006, at 13:18 , Desineni, Harikishan wrote:

> You can use CNAME to identify the senders and it might be possible  
> to use it to address multi sender scenarios.
> Both drafts look somewhat incompelte as they are not addressing  
> multi sender scenarios. Having a solution for multi sender scneario  
> and applying (optimizing)  it for single sender scenario would be a  
> better approach.
>