Subject: [clue] #11: RTP header extension for Capture ID

From: "clue issue tracker" <[email-masked]>
Date: Mon, 13 Aug 2012 19:33:58 -0000

#11: RTP header extension for Capture ID

 Is an RTP header extension needed to transport a capture ID (per draft-
 lennox-clue-rtp-usage-04)?

-- 
-----------------------------------+---------------------------
 Reporter:  mary.ietf.barnes@…     |      Owner:  clue-chairs@…
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:  milestone1
Component:  charter                |    Version:  1.0
 Severity:  Candidate WG Document  |   Keywords:  RTP
-----------------------------------+---------------------------

Ticket URL: <http://grenache.tools.ietf.org/wg/clue/trac/ticket/11>
clue <http://tools.ietf.org/wg/clue/>

---

From: Mary Barnes <[email-masked]>
Date: Mon, 13 Aug 2012 14:37:26 -0500

Hi all,

I have updated/closed the issues as discussed at the meeting (and captured
in the minutes):  http://www.ietf.org/proceedings/84/minutes/minutes-84-clue

I decided to open a ticket to track this issue since it does require some
mailing list discussion and hopefully, this will trigger that.

The action items from the meeting that are not related to issues are
updates to documents - i.e., new data model document and adding telemedical
use case to the WG use case document.

Mary.

---

From: "Roni Even" <[email-masked]>
Date: Tue, 14 Aug 2012 17:55:16 +0200

Hi,
I am not sure that this is the right description. Both presentation had the header extension as a solution.
The comment by Colin at the meeting was that header extensions are designed so that they may be ignored without affecting the interoperability (see section 4.1 of RFC5285). The major issue raised by Colin is that intermediaries may strip the header extension and the interoperability should not be broken. My understanding is that even if it is negotiated in SDP that does not guarantee that the header extension will not be stripped.
So the question is if it is a reasonable solution according to RFC3550 and RFC5285 and not if it is needed.
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of clue issue tracker
Sent: 13 August, 2012 9:34 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [clue] #11: RTP header extension for Capture ID

 Is an RTP header extension needed to transport a capture ID (per draft-  lennox-clue-rtp-usage-04)?

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

---

From: Mary Barnes <[email-masked]>
Date: Tue, 14 Aug 2012 10:09:06 -0500

You are correct.  I noted that on the call today that question/issue was
not properly stated.  I'll send the notes from the call shortly.

Mary.

On Tue, Aug 14, 2012 at 10:55 AM, Roni Even <[email-masked]> wrote:

> The comment by Colin at the meeting was that header extensions are
> designed so that they may be ignored without affecting the interoperability
> (see section 4.1 of RFC5285). The major issue raised by Colin is that
> intermediaries may strip the header extension and the interoperability
> should not be broken. My understanding is that even if it is negotiated in
> SDP that does not guarantee that the header extension will not be stripped.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Aug 2012 21:38:15 +0200

Hi,

A silly question:

Is there a reason why we can't use the SSRC? Or, can multiple captures share the same SSRC?

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Mary Barnes [[email-masked]]
Sent: Monday, August 13, 2012 10:37 PM
To: CLUE
Subject: [clue] Fwd: #11: RTP header extension for Capture ID

Hi all,

I have updated/closed the issues as discussed at the meeting (and captured in the minutes):  http://www.ietf.org/proceedings/84/minutes/minutes-84-clue

I decided to open a ticket to track this issue since it does require some mailing list discussion and hopefully, this will trigger that.

The action items from the meeting that are not related to issues are updates to documents - i.e., new data model document and adding telemedical use case to the WG use case document.

Mary.

---

From: "Roni Even" <[email-masked]>
Date: Tue, 14 Aug 2012 23:17:42 +0200

Hi Christer,
This works for static SSRCs when the mixer uses its own SSRC. The problem is
in the switching case when using the source SSRC. An example is when a three
camera system has two captures to send to a two monitor system. The three
camera system may send first the left and center camera but when switching
to center and right camera the center camera will switch from right capture
to left capture.
This was discussed in my presentation in CLUE about mapping RTP streams.
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christer Holmberg
Sent: 14 August, 2012 9:38 PM
To: Mary Barnes; CLUE
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID

Hi,

A silly question:

Is there a reason why we can't use the SSRC? Or, can multiple captures share
the same SSRC?

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Mary Barnes
[[email-masked]]
Sent: Monday, August 13, 2012 10:37 PM
To: CLUE
Subject: [clue] Fwd: #11: RTP header extension for Capture ID

Hi all,

The action items from the meeting that are not related to issues are updates
to documents - i.e., new data model document and adding telemedical use case
to the WG use case document.

Mary.

---------- Forwarded message ----------
From: clue issue tracker
<[email-masked]<mailto:[email-masked]>>
Date: Mon, Aug 13, 2012 at 2:33 PM
Subject: [clue] #11: RTP header extension for Capture ID
To: [email-masked]<mailto:[email-masked]>,
[email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

 Reporter:  mary.ietf.barnes@.     |      Owner:  clue-chairs@.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Aug 2012 16:40:17 -0400

> This was discussed in my presentation in CLUE about mapping RTP streams.

AFAIK it *could* work using SSRC. But then there are different 
constraints on how RTP is used.

For instance, for the switched case it would then be necessary to assign 
an ssrc for the switched capture, and indicate the source via csrc.

It also then means that if a source is moved from one switched capture 
to a different one, the recipient won't know that it is the *same* RTP 
stream. And that affects the number of iframes transmitted, etc.

tradeoffs!

	Thanks,
	Paul

> Ticket URL:<http://grenache.tools.ietf.org/wg/clue/trac/ticket/11>
> clue<http://tools.ietf.org/wg/clue/>
>
>

---

From: Andy Pepperell <[email-masked]>
Date: Wed, 15 Aug 2012 08:48:03 +0100

Hi Christer,

>Is there a reason why we can't use the SSRC? Or, can multiple captures
share the same SSRC?

I don't think I'm disagreeing here with anything that Roni or Paul are
saying, but was thinking that the phrase "use the SSRC" potentially covers
a few different cases...

- If we're talking about declaring SSRC values in advance in SDP, this is
likely to cause scalability issues with CLUE (more so than with, say,
current webrtc implementations) because of the potential for a large number
of CLUE streams in MCU cases.

- The current RTP header extension proposal involves the consumer telling
the provider an ID to use in the RTP header extension for each instantiated
capture, which the consumer can then use to separate the multiple capture
instantiations when they are received. It would clearly be reasonably
straightforward for the CLUE consumer stream choice message to instead
indicate an SSRC here instead of an ID to be put in an RTP header
extension, but as Paul points out, this means that the consumer then loses
the ability to distinguish stream changes within a switched capture (modulo
CSRC usage).

>[Paul]
an ssrc for the switched capture...

Agreed, though I think the SSRC assignment would have to be on the basis of
the switched capture's *instantiation* rather than the switched capture
itself - with the simulcast aspects of CLUE as currently defined, mappings
can't be on the basis of just capture IDs as a consumer may request
multiple instantiations of the same capture from the provider, and so a
simple SSRC <--> capture ID mapping would not be sufficient.

Regards,

Andy

On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat <[email-masked]> wrote:

> AFAIK it *could* work using SSRC. But then there are different constraints
> on how RTP is used.
>
> It also then means that if a source is moved from one switched capture to
> a different one, the recipient won't know that it is the *same* RTP stream.
> And that affects the number of iframes transmitted, etc.
>
> tradeoffs!
>
>         Thanks,
>         Paul
>
>
>  Roni
>>
>> ______________________________**__
>> in the minutes):  http://www.ietf.org/**proceedings/84/minutes/**
>> minutes-84-clue<http://www.ietf.org/proceedings/84/minutes/minutes-84-clue>
>>
>> updates
>> <[email-masked]**<mailto:trac%2Bclue@trac.**tools.ietf.org<[email-masked]>
>> >>
>> To: [email-masked]<**mailto:[email-masked].**org<[email-masked]>
>> >,
>> [email-masked]<**mailto:mary.ietf.barnes@gmail.**com<[email-masked]>
>> >
>> Cc: [email-masked]<mailto:clue@**ietf.org <[email-masked]>>
>>
>>
>> ------------------------------**-----+------------------------**---
>> ------------------------------**-----+------------------------**---
>>
>> Ticket URL:<http://grenache.tools.**ietf.org/wg/clue/trac/ticket/**11<http://grenache.tools.ietf.org/wg/clue/trac/ticket/11>
>> >
>> clue<http://tools.ietf.org/wg/**clue/ <http://tools.ietf.org/wg/clue/>>
>>
>>
>> ______________________________**_________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>
>> ______________________________**_________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>
>>
> ______________________________**_________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: "Roni Even" <[email-masked]>
Date: Wed, 15 Aug 2012 11:19:51 +0200

Andy,

I fail to understand why the consumer needs to define the mapping ID for a
mapping done by the provider

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of Andy
Pepperell
Sent: 15 August, 2012 9:48 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID

Hi Christer,

I don't think I'm disagreeing here with anything that Roni or Paul are
saying, but was thinking that the phrase "use the SSRC" potentially covers a
few different cases...

- The current RTP header extension proposal involves the consumer telling
the provider an ID to use in the RTP header extension for each instantiated
capture, which the consumer can then use to separate the multiple capture
instantiations when they are received. It would clearly be reasonably
straightforward for the CLUE consumer stream choice message to instead
indicate an SSRC here instead of an ID to be put in an RTP header extension,
but as Paul points out, this means that the consumer then loses the ability
to distinguish stream changes within a switched capture (modulo CSRC usage).

>For instance, for the switched case it would then be necessary to assign an
ssrc for the switched capture...

Agreed, though I think the SSRC assignment would have to be on the basis of
the switched capture's *instantiation* rather than the switched capture
itself - with the simulcast aspects of CLUE as currently defined, mappings
can't be on the basis of just capture IDs as a consumer may request multiple
instantiations of the same capture from the provider, and so a simple SSRC
<--> capture ID mapping would not be sufficient.

Regards,

Andy

Hi Christer,

For instance, for the switched case it would then be necessary to assign an
ssrc for the switched capture, and indicate the source via csrc.

It also then means that if a source is moved from one switched capture to a
different one, the recipient won't know that it is the *same* RTP stream.
And that affects the number of iframes transmitted, etc.

tradeoffs!

        Thanks,
        Paul

Roni

-----Original Message-----

Hi,

A silly question:

Regards,

Christer

Hi all,

Mary.

---------- Forwarded message ----------
From: clue issue tracker
<[email-masked] <mailto:[email-masked]>
<mailto:[email-masked]
<mailto:[email-masked]> >>
Date: Mon, Aug 13, 2012 at 2:33 PM
Subject: [clue] #11: RTP header extension for Capture ID
To: [email-masked]<mailto:[email-masked]>,
[email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

---

From: Andy Pepperell <[email-masked]>
Date: Wed, 15 Aug 2012 09:57:36 +0100

Hi Roni,

I'm not sure I understand the point - are you asking why the consumer is
assigning the IDs rather than the provider? or, taking it further, are you
proposing that the provider allocate the IDs?

Andy

On Wed, Aug 15, 2012 at 10:19 AM, Roni Even <[email-masked]> wrote:

> Andy,****
> mapping done by the provider****
>
> Roni****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Andy Pepperell
> *Sent:* 15 August, 2012 9:48 AM
> *To:* [email-masked]
> *Cc:* [email-masked]
>
> *Subject:* Re: [clue] Fwd: #11: RTP header extension for Capture ID****
>
> ** **
>
> Hi Christer,****
>
> ** **
>
> >Is there a reason why we can't use the SSRC? Or, can multiple captures
> share the same SSRC?****
>
> ** **
>
> a few different cases...****
>
> ** **
>
> of CLUE streams in MCU cases.****
>
> ** **
>
> CSRC usage).****
> ** **
> >[Paul]****
> an ssrc for the switched capture...****
>
> ** **
>
> Agreed, though I think the SSRC assignment would have to be on the basis
> of the switched capture's *instantiation* rather than the switched capture
> simple SSRC <--> capture ID mapping would not be sufficient.****
>
> ** **
>
> Regards,****
>
> ** **
>
> Andy****
>
> ** **
>
> ** **
>
> On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat <[email-masked]>
> wrote:****
>
> On 8/14/12 5:17 PM, Roni Even wrote:****
>
> Hi Christer,
> This was discussed in my presentation in CLUE about mapping RTP streams.**
> **
>
> ** **
>
>         Paul****
> ** **
> in the minutes):
> http://www.ietf.org/proceedings/84/minutes/minutes-84-clue
>
> https://www.ietf.org/mailman/listinfo/clue****
>
>
> https://www.ietf.org/mailman/listinfo/clue****
>
> ** **
>

---

From: Roni even <[email-masked]>
Date: Wed, 15 Aug 2012 09:48:31 +0000

Hi Andy,

Yes the provider should allocate the ID since he is defining the captures and the SSRCs

Roni

________________________________
From: [email-masked] [[email-masked]] on behalf of Andy Pepperell [[email-masked]]
Sent: Wednesday, August 15, 2012 11:57
To: Roni Even
Cc: [email-masked]
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID

Hi Roni,

I'm not sure I understand the point - are you asking why the consumer is assigning the IDs rather than the provider? or, taking it further, are you proposing that the provider allocate the IDs?

Andy

On Wed, Aug 15, 2012 at 10:19 AM, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:
Andy,
I fail to understand why the consumer needs to define the mapping ID for a mapping done by the provider
Roni

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andy Pepperell
Sent: 15 August, 2012 9:48 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Hi Christer,

>Is there a reason why we can't use the SSRC? Or, can multiple captures share the same SSRC?

I don't think I'm disagreeing here with anything that Roni or Paul are saying, but was thinking that the phrase "use the SSRC" potentially covers a few different cases...

- If we're talking about declaring SSRC values in advance in SDP, this is likely to cause scalability issues with CLUE (more so than with, say, current webrtc implementations) because of the potential for a large number of CLUE streams in MCU cases.

- The current RTP header extension proposal involves the consumer telling the provider an ID to use in the RTP header extension for each instantiated capture, which the consumer can then use to separate the multiple capture instantiations when they are received. It would clearly be reasonably straightforward for the CLUE consumer stream choice message to instead indicate an SSRC here instead of an ID to be put in an RTP header extension, but as Paul points out, this means that the consumer then loses the ability to distinguish stream changes within a switched capture (modulo CSRC usage).

>[Paul]
>For instance, for the switched case it would then be necessary to assign an ssrc for the switched capture...

Agreed, though I think the SSRC assignment would have to be on the basis of the switched capture's *instantiation* rather than the switched capture itself - with the simulcast aspects of CLUE as currently defined, mappings can't be on the basis of just capture IDs as a consumer may request multiple instantiations of the same capture from the provider, and so a simple SSRC <--> capture ID mapping would not be sufficient.

Regards,

Andy

On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

AFAIK it *could* work using SSRC. But then there are different constraints on how RTP is used.

For instance, for the switched case it would then be necessary to assign an ssrc for the switched capture, and indicate the source via csrc.

It also then means that if a source is moved from one switched capture to a different one, the recipient won't know that it is the *same* RTP stream. And that affects the number of iframes transmitted, etc.

tradeoffs!

        Thanks,
        Paul

Roni

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
Christer Holmberg
Sent: 14 August, 2012 9:38 PM
To: Mary Barnes; CLUE
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID

Hi,

A silly question:

Regards,

Christer

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of Mary Barnes
[[email-masked]<mailto:[email-masked]>]
Sent: Monday, August 13, 2012 10:37 PM
To: CLUE
Subject: [clue] Fwd: #11: RTP header extension for Capture ID

Hi all,

Mary.

---------- Forwarded message ----------
From: clue issue tracker
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
Date: Mon, Aug 13, 2012 at 2:33 PM
Subject: [clue] #11: RTP header extension for Capture ID
To: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>,
[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>

  Reporter:  mary.ietf.barnes@<mailto:mary.ietf.barnes@>.     |      Owner:  clue-chairs@.

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

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

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

---

From: Andy Pepperell <[email-masked]>
Date: Wed, 15 Aug 2012 11:34:17 +0100

Hi Roni,

The main complexities I'd see with that approach is the simulcast aspect -
the provider may have the potential to supply, say, 4 different captures
but the consumer could (encoding groups permitting) ask for 4 different
encodings of the same capture or 1 encoding of each capture, and the SSRC /
header extension ID allocation scheme has to work for all cases.

The only way I can see for this to work would be for the provider's
advertisement to include a header extension ID or SSRC value associated
with each of its encoding groups' constituent potential encodings - that
way the consumer would know from its own capture instantiation <-->
encoding mapping which ID or SSRC the provider would be using. This has
been discussed before and from what I recall (these aren't necessarily my
reasons):

- it's seen as advantageous for the consumer to allocate the IDs so that it
can apply some structure to them (e.g. some sort of hardware routing info)

- it's maybe also advantageous to decouple the consumer-side multi-stream
demultiplexing from encoding groups' [potential] encodings (if this latter
were subject to further / future modifications, for instance in order to
cope with some more complex / flexible encoding cases that have been
discussed, we wouldn't necessarily want to have to revisit the RTP
multi-stream handling).

Is this kind of in line with what you were thinking, or did you some other
thoughts on where / how the provider would allocate and indicate these?

Regards,

Andy

On Wed, Aug 15, 2012 at 10:48 AM, Roni even <[email-masked]> wrote:

>  ------------------------------
> *From:* [email-masked] [[email-masked]] on behalf of Andy
> Pepperell [[email-masked]]
> *Sent:* Wednesday, August 15, 2012 11:57
> *To:* Roni Even
>
> *Cc:* [email-masked]
> *Subject:* Re: [clue] Fwd: #11: RTP header extension for Capture ID
>
>  Hi Roni,
>
> On Wed, Aug 15, 2012 at 10:19 AM, Roni Even <[email-masked]>wrote:
>
>>  Andy,****
>>
>> I fail to understand why the consumer needs to define the mapping ID for
>> a mapping done by the provider****
>>
>> Roni****
>>
>> ****
>>
>>  ****
>> ****
>> ****
>> ****
>> ****
>> ****
>> ****
>> ****
>> ****
>> ****
>> ****
>> This was discussed in my presentation in CLUE about mapping RTP streams.*
>> ***
>>
>> ****
>>
>> ****
>> share
>> ****

---

From: "Roni Even" <[email-masked]>
Date: Wed, 15 Aug 2012 14:28:20 +0200

Hi Andy,

I think this is an SDP problem. If you can point me to how to describe
simulcast in SDP the issue can be solved. If not then we need to solve it
for the general case and not only for CLUE

Roni

From: Andy Pepperell [mailto:[email-masked]] 
Sent: 15 August, 2012 12:34 PM
To: Roni even
Cc: Roni Even; [email-masked]
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID

Hi Roni,

The main complexities I'd see with that approach is the simulcast aspect -
the provider may have the potential to supply, say, 4 different captures but
the consumer could (encoding groups permitting) ask for 4 different
encodings of the same capture or 1 encoding of each capture, and the SSRC /
header extension ID allocation scheme has to work for all cases.

The only way I can see for this to work would be for the provider's
advertisement to include a header extension ID or SSRC value associated with
each of its encoding groups' constituent potential encodings - that way the
consumer would know from its own capture instantiation <--> encoding mapping
which ID or SSRC the provider would be using. This has been discussed before
and from what I recall (these aren't necessarily my reasons):

Regards,

Andy

Hi Andy,

Yes the provider should allocate the ID since he is defining the captures
and the SSRCs

Roni

  _____  

From: [email-masked] [[email-masked]] on behalf of Andy
Pepperell [[email-masked]]
Sent: Wednesday, August 15, 2012 11:57
To: Roni Even

Cc: [email-masked]

Hi Roni, 

Andy

Andy,

Roni

Hi Christer,

share the same SSRC?

Regards,

Andy

Hi Christer,

tradeoffs!

        Thanks,
        Paul

Roni

-----Original Message-----

Hi,

A silly question:

Regards,

Christer

Hi all,

Mary.

---------- Forwarded message ----------
From: clue issue tracker

---

From: Andy Pepperell <[email-masked]>
Date: Wed, 15 Aug 2012 16:14:49 +0100

Hi Roni,

I'm not sure of the validity of needing simulcast defined in SDP before we
can start to think about it in CLUE. The messages and mechanisms as
currently defined in CLUE give us simulcast functionality without the need
for SDP additions (which wouldn't necessarily be a good fit for CLUE
anyway, just like the pre-declaration of SSRC values doesn't scale all that
well to all CLUE multi-stream use cases).

>If you can point me to how to describe simulcast in SDP the issue can be
solved.

As above, I don't believe this is a prerequisite at all for us to be able
to make progress in CLUE. Or, alternatively, introducing dependencies on
such general solutions which may or may not be in the pipeline would seem
likely only to impede progress on CLUE (IMHO, of course!).

Regards,

Andy

On Wed, Aug 15, 2012 at 1:28 PM, Roni Even <[email-masked]> wrote:

> Hi Andy,****
> for the general case and not only for CLUE****
>
> Roni****
>
> ** **
>
> *From:* Andy Pepperell [mailto:[email-masked]]
> *Sent:* 15 August, 2012 12:34 PM
> *To:* Roni even
> *Cc:* Roni Even; [email-masked]
>
> Hi Roni,****
> header extension ID allocation scheme has to work for all cases.****
>
> ** **
>
> reasons):****
> - it's seen as advantageous for the consumer to allocate the IDs so that
> it can apply some structure to them (e.g. some sort of hardware routing
> info)****
>
> ** **
>
> multi-stream handling).****
>
> ** **
>
> thoughts on where / how the provider would allocate and indicate these?***
> *
>
> ** **
>
> Regards,****
>
> ** **
>
> Andy****
>
> ** **
>
> On Wed, Aug 15, 2012 at 10:48 AM, Roni even <[email-masked]> wrote:*
> ***
>
> Hi Andy,****
>
> and the SSRCs****
> *To:* Roni Even****
> Hi Roni, ****
> proposing that the provider allocate the IDs?****
>
> ** **
>
> Andy****
>
> ** **
>
> On Wed, Aug 15, 2012 at 10:19 AM, Roni Even <[email-masked]>
> wrote:****
>
> Andy,****
>
> *Cc:* [email-masked]****

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Aug 2012 11:41:34 -0400

[as an individual]

Note: I'm not advocating for either position here - I'm just trying to 
explore the implications of one vs. the other.

On 8/15/12 3:48 AM, Andy Pepperell wrote:
> saying, but was thinking that the phrase "use the SSRC" potentially
> covers a few different cases...
>
> - If we're talking about declaring SSRC values in advance in SDP, this
> is likely to cause scalability issues with CLUE (more so than with, say,
> current webrtc implementations) because of the potential for a large
> number of CLUE streams in MCU cases.

AFAIK the question here is about whether we need an RTP extension to 
carry the capture ID in RTP. And the purpose of this is to correlate it 
with a capture ID carried in the CLUE signaling. I *think* the 
suggestion to use the SSRC just means using it as the capture ID - 
associating an SSRC with each capture in CLUE signaling. Then, since the 
SSRC is already in the RTP, there is no need for an extension to carry 
capture ID.

I don't think there is any *requirement* to carry SSRCs in SDP.

> - The current RTP header extension proposal involves the consumer
> telling the provider an ID to use in the RTP header extension for each
> instantiated capture, which the consumer can then use to separate the
> multiple capture instantiations when they are received. It would clearly
> be reasonably straightforward for the CLUE consumer stream choice
> message to instead indicate an SSRC here instead of an ID

yep

> to be put in an RTP header extension,

but you don't need to put it in an extension. Its already in every RTP 
message.

> but as Paul points out, this means that the
> consumer then loses the ability to distinguish stream changes within a
> switched capture (modulo CSRC usage).

Well, clearly you *can* distinguish stream changes by noting that the 
CSRCs have changed. But what you can't do is determine that a particular 
source stream has moved from one switched capture to another.

(You can note that the switched capture associated with SSRC A used to 
have a single CSRC - C. And now switched capture with SSRC B has the 
single CSRC C. But its still a leap of faith to assume that means those 
messages can be treated as a single RTP stream.

>  >[Paul]
>  >For instance, for the switched case it would then be necessary to
> assign an ssrc for the switched capture...
>
> of the switched capture's *instantiation* rather than the switched
> capture itself - with the simulcast aspects of CLUE as currently
> defined, mappings can't be on the basis of just capture IDs as a
> consumer may request multiple instantiations of the same capture from
> the provider, and so a simple SSRC <--> capture ID mapping would not be
> sufficient.

Yes, you are right about that.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Wed, 15 Aug 2012 19:16:51 +0200

Andy,

The CLUE charter is not to replace SDP, so negotiating simulcast is the
requirement you want to address.

There are two questions:

1.       Should CLUE address it if there is no current SDP way (only
document I found was draft-westerlund-avtcore-multistream-and-simulcast-00
expired on January)

2.       Does it require having the consumer define the capture ID.

As for pre-declaration of SSRC , I do not see the problem in the topologies
that use mixer based SSRCs which is very common use today. Saying that there
is a big number is not correct when the mixer/MCU creates the advertisement
to each participant.  I do not have any proof for such case.  I agree that
when the mixer will relay the SSRCs the number can be large and there is no
need to define the SSRCs in the SDP from the mixer since the mixer will not
even know all the SSRCs from all the sources. What we presented is to have
the SSRC for the static case and send a dynamic change with the media (if we
use RTP header extension). The mixer knows which topology it is using and
can decide if to use static mapping and/or dynamic mapping. For most MCUs
today static mapping will be enough and there will be no need to send the
RTP header extension at all.

Roni

From: Andy Pepperell [mailto:[email-masked]] 
Sent: 15 August, 2012 5:15 PM
To: Roni Even
Cc: Roni even; [email-masked]
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID

Hi Roni,

I'm not sure of the validity of needing simulcast defined in SDP before we
can start to think about it in CLUE. The messages and mechanisms as
currently defined in CLUE give us simulcast functionality without the need
for SDP additions (which wouldn't necessarily be a good fit for CLUE anyway,
just like the pre-declaration of SSRC values doesn't scale all that well to
all CLUE multi-stream use cases).

solved.

As above, I don't believe this is a prerequisite at all for us to be able to
make progress in CLUE. Or, alternatively, introducing dependencies on such
general solutions which may or may not be in the pipeline would seem likely
only to impede progress on CLUE (IMHO, of course!).

Regards,

Andy

Hi Andy,

Roni

Hi Roni,

Regards,

Andy

Hi Andy,

Roni

  _____  

Cc: [email-masked]

Hi Roni, 

Andy

Andy,

Roni

Hi Christer,

share the same SSRC?

Regards,

Andy

Hi Christer,

tradeoffs!

        Thanks,
        Paul

Roni

-----Original Message-----

Hi,

A silly question:

Regards,

Christer

Hi all,

Mary.

---------- Forwarded message ----------
From: clue issue tracker

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Aug 2012 12:27:36 -0400

Andy,

There is clearly a terminology problem here. If each capture+encoding 
pair requires a distinct ID, then that ID cannot properly be called a 
"Capture ID".

Suppose a separate capture+encoding-ID is carried as an RTP extension. 
Even so, if the same capture is sent in two encodings in the same RTP 
session, isn't it *necessary* that each have a distinct SSRC? If so, 
that will be a problem if the goal is to pass the source SSRCs through 
switched captures.

	Thanks,
	Paul (as individual)

On 8/15/12 6:34 AM, Andy Pepperell wrote:
> Hi Roni,
>
> The main complexities I'd see with that approach is the simulcast aspect
> - the provider may have the potential to supply, say, 4 different
> captures but the consumer could (encoding groups permitting) ask for 4
> different encodings of the same capture or 1 encoding of each capture,
> and the SSRC / header extension ID allocation scheme has to work for all
> cases.
>
> been discussed before and from what I recall (these aren't necessarily
> my reasons):
>
> info)
> - it's maybe also advantageous to decouple the consumer-side
> multi-stream demultiplexing from encoding groups' [potential] encodings
> (if this latter were subject to further / future modifications, for
> instance in order to cope with some more complex / flexible encoding
> cases that have been discussed, we wouldn't necessarily want to have to
> revisit the RTP multi-stream handling).
>
> Is this kind of in line with what you were thinking, or did you some
> other thoughts on where / how the provider would allocate and indicate
> these?
>
> Regards,
>
> Andy
>
>
> On Wed, Aug 15, 2012 at 10:48 AM, Roni even <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Andy,
>
>     Yes the provider shouldallocate the ID since he is defining the
>     captures and the SSRCs
>
>     Roni
>
>     ------------------------------------------------------------------------
>     *From:* [email-masked] <mailto:[email-masked]>
>     [[email-masked] <mailto:[email-masked]>] on behalf of
>     Andy Pepperell [[email-masked] <mailto:[email-masked]>]
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     I'm not sure I understand the point - are you asking why the
>     consumer is assigning the IDs rather than the provider? or, taking
>     it further, are you proposing that the provider allocate the IDs?
>
>     Andy
>
>
>         Andy,____
>         I fail to understand why the consumer needs to define the
>         mapping ID for a mapping done by the provider____
>
>         Roni____
>
>         ____
>
>         *From:[email-masked] <mailto:[email-masked]>
>         [mailto:[email-masked] <mailto:[email-masked]>]
>         *On Behalf Of *Andy Pepperell
>         <mailto:[email-masked]>
>         *Cc:* [email-masked] <mailto:[email-masked]>
>
>
>         *Subject:* Re: [clue] Fwd: #11: RTP header extension for Capture
>         ID____
>
>         ____
>
>         Hi Christer,____
>
>         ____
>
>          >Is there a reason why we can't use the SSRC? Or, can multiple
>         captures share the same SSRC?____
>
>         ____
>
>         I don't think I'm disagreeing here with anything that Roni or
>         Paul are saying, but was thinking that the phrase "use the SSRC"
>         potentially covers a few different cases...____
>
>         ____
>
>         - If we're talking about declaring SSRC values in advance in
>         SDP, this is likely to cause scalability issues with CLUE (more
>         so than with, say, current webrtc implementations) because of
>         the potential for a large number of CLUE streams in MCU cases.____
>
>         ____
>
>         - The current RTP header extension proposal involves the
>         consumer telling the provider an ID to use in the RTP header
>         extension for each instantiated capture, which the consumer can
>         then use to separate the multiple capture instantiations when
>         they are received. It would clearly be reasonably
>         straightforward for the CLUE consumer stream choice message to
>         instead indicate an SSRC here instead of an ID to be put in an
>         RTP header extension, but as Paul points out, this means that
>         the consumer then loses the ability to distinguish stream
>         changes within a switched capture (modulo CSRC usage).____
>
>         ____
>
>          >[Paul]____
>
>          >For instance, for the switched case it would then be necessary
>         to assign an ssrc for the switched capture...____
>
>         ____
>
>         Agreed, though I think the SSRC assignment would have to be on
>         the basis of the switched capture's *instantiation* rather than
>         the switched capture itself - with the simulcast aspects of CLUE
>         as currently defined, mappings can't be on the basis of just
>         capture IDs as a consumer may request multiple instantiations of
>         the same capture from the provider, and so a simple SSRC <-->
>         capture ID mapping would not be sufficient.____
>
>         ____
>
>         Regards,____
>
>         ____
>
>         Andy____
>
>         ____
>
>         ____
>
>         On Tue, Aug 14, 2012 at 9:40 PM, Paul Kyzivat
>         <[email-masked] <mailto:[email-masked]>> wrote:____
>
>         On 8/14/12 5:17 PM, Roni Even wrote:____
>
>         Hi Christer,
>         This was discussed in my presentation in CLUE about mapping RTP
>         streams.____
>
>         ____
>
>         For instance, for the switched case it would then be necessary
>         to assign an ssrc for the switched capture, and indicate the
>         source via csrc.
>
>         It also then means that if a source is moved from one switched
>         capture to a different one, the recipient won't know that it is
>         the *same* RTP stream. And that affects the number of iframes
>         transmitted, etc.
>
>         tradeoffs!
>
>                  Thanks,
>                  Paul____
>
>             ____
>
>             Roni
>
>             From: [email-masked] <mailto:[email-masked]>
>             [mailto:[email-masked]
>             <mailto:[email-masked]>] On Behalf Of
>             Christer Holmberg
>             From: [email-masked] <mailto:[email-masked]>
>             [[email-masked] <mailto:[email-masked]>] On
>             Behalf Of Mary Barnes
>             [[email-masked] <mailto:[email-masked]>]
>             <[email-masked]
>             <mailto:[email-masked]><mailto:[email-masked]
>             <mailto:[email-masked]>>>
>             To: [email-masked]
>             <mailto:[email-masked]><mailto:[email-masked]
>             <mailto:[email-masked]>>,
>             [email-masked]
>             <mailto:[email-masked]><mailto:[email-masked]
>             <mailto:[email-masked]>>
>             Cc: [email-masked]
>             <mailto:[email-masked]><mailto:[email-masked]
>             <mailto:[email-masked]>>
>
>
>                Reporter: mary.ietf.barnes@ <mailto:mary.ietf.barnes@>.
>                |      Owner:  clue-chairs@.
>             Ticket
>             URL:<http://grenache.tools.ietf.org/wg/clue/trac/ticket/11>
>             [email-masked] <mailto:[email-masked]>
>             [email-masked] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/listinfo/clue____
>
>
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/clue____
>
>         ____
>
>
>
>
>

---

From: Paul Witty <[email-masked]>
Date: Wed, 15 Aug 2012 17:37:29 +0100

Each encoded media stream must have a distinct SSRC. If a source is sent 
in two separate requested captures (i.e. simulcasting of two resolutions 
by a transcoding middle box), then the two encodings of the same capture 
will have distinct SSRCs, but the SSRC of the original encoding of the 
source as a CSRC. If we want to send the same encoding over two 
requested captures (i.e. requesting both a single stream of loudest 
speaker, and left/centre/right streams from a single endpoint, where the 
former will always be one of the latter), we can use multiple instances 
of the RTP extension in the RTP header, one for each of the requested 
captures.

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Aug 2012 13:57:15 -0400

On 8/15/12 12:37 PM, Paul Witty wrote:
> source as a CSRC.

That seems to be in conflict with wanting to send the source SSRC for 
switched captures.

But that is also an arrangement that suggests the SSRC could be used to 
identify the capture+encoding.

> If we want to send the same encoding over two

That is a situation where using the SSRC to identify the 
capture+encoding has a major cost in bandwidth.

	Thanks,
	Paul K

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 15 Aug 2012 20:32:16 +0200

FYI,

There is now a new draft for simulcast:

http://tools.ietf.org/id/draft-westerlund-avtcore-rtp-simulcast-01.txt

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Roni Even [[email-masked]]
Sent: Wednesday, August 15, 2012 8:16 PM
To: 'Andy Pepperell'
Cc: [email-masked]
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID

Andy,
The CLUE charter is not to replace SDP, so negotiating simulcast is the requirement you want to address.
There are two questions:

1.       Should CLUE address it if there is no current SDP way (only document I found was draft-westerlund-avtcore-multistream-and-simulcast-00 expired on January)

As for pre-declaration of SSRC , I do not see the problem in the topologies that use mixer based SSRCs which is very common use today. Saying that there is a big number is not correct when the mixer/MCU creates the advertisement  to each participant.  I do not have any proof for such case.  I agree that when the mixer will relay the SSRCs the number can be large and there is no need to define the SSRCs in the SDP from the mixer since the mixer will not even know all the SSRCs from all the sources. What we presented is to have the SSRC for the static case and send a dynamic change with the media (if we use RTP header extension). The mixer knows which topology it is using and can decide if to use static mapping and/or dynamic mapping. For most MCUs today static mapping will be enough and there will be no need to send the RTP header extension at all.

Roni

Hi Roni,

I'm not sure of the validity of needing simulcast defined in SDP before we can start to think about it in CLUE. The messages and mechanisms as currently defined in CLUE give us simulcast functionality without the need for SDP additions (which wouldn't necessarily be a good fit for CLUE anyway, just like the pre-declaration of SSRC values doesn't scale all that well to all CLUE multi-stream use cases).

>If you can point me to how to describe simulcast in SDP the issue can be solved.

As above, I don't believe this is a prerequisite at all for us to be able to make progress in CLUE. Or, alternatively, introducing dependencies on such general solutions which may or may not be in the pipeline would seem likely only to impede progress on CLUE (IMHO, of course!).

Regards,

Andy

On Wed, Aug 15, 2012 at 1:28 PM, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,
I think this is an SDP problem. If you can point me to how to describe simulcast in SDP the issue can be solved. If not then we need to solve it for the general case and not only for CLUE
Roni

From: Andy Pepperell [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 15 August, 2012 12:34 PM
To: Roni even
Cc: Roni Even; [email-masked]<mailto:[email-masked]>

Hi Roni,

The main complexities I'd see with that approach is the simulcast aspect - the provider may have the potential to supply, say, 4 different captures but the consumer could (encoding groups permitting) ask for 4 different encodings of the same capture or 1 encoding of each capture, and the SSRC / header extension ID allocation scheme has to work for all cases.

The only way I can see for this to work would be for the provider's advertisement to include a header extension ID or SSRC value associated with each of its encoding groups' constituent potential encodings - that way the consumer would know from its own capture instantiation <--> encoding mapping which ID or SSRC the provider would be using. This has been discussed before and from what I recall (these aren't necessarily my reasons):

- it's seen as advantageous for the consumer to allocate the IDs so that it can apply some structure to them (e.g. some sort of hardware routing info)

- it's maybe also advantageous to decouple the consumer-side multi-stream demultiplexing from encoding groups' [potential] encodings (if this latter were subject to further / future modifications, for instance in order to cope with some more complex / flexible encoding cases that have been discussed, we wouldn't necessarily want to have to revisit the RTP multi-stream handling).

Is this kind of in line with what you were thinking, or did you some other thoughts on where / how the provider would allocate and indicate these?

Regards,

Andy

On Wed, Aug 15, 2012 at 10:48 AM, Roni even <[email-masked]<mailto:[email-masked]>> wrote:

Hi Andy,

Roni

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Andy Pepperell [[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 15, 2012 11:57
To: Roni Even

Hi Roni,

Andy

Hi Christer,

Regards,

Andy

tradeoffs!

        Thanks,
        Paul

Roni

-----Original Message-----

Hi,

A silly question:

Regards,

Christer

Hi all,

Mary.

---------- Forwarded message ----------
From: clue issue tracker

---

From: Paul Witty <[email-masked]>
Date: Thu, 16 Aug 2012 14:44:06 +0100

> That seems to be in conflict with wanting to send the source SSRC for 
If there is a middle box doing a transcode of a stream (for whatever 
reason, such as resolution / codec / bandwidth / packet loss 
resilience), we shouldn't preserve SSRC, because the SSRC uniquely 
identifies a media sender.  By including the SSRC of the original stream 
in the transcoded stream as a CSRC, we can then forward on RTCP 
information, such as SDES, from the original sender to all receivers of 
the transcoded stream, to ensure no information is lost.  We still send 
the source SSRC (as a CSRC), but make it clear that this is a transcode, 
and therefore properties such as encryption state which are tied to an 
SSRC are not incorrectly applied to the transcoded stream.
>
> But that is also an arrangement that suggests the SSRC could be used 
> to identify the capture+encoding.
Potentially yes, by the consumer declaring the mapping of SSRC to media 
stream properties (which capture is being shown, what are the bounds on 
resolution/bandwidth etc).  However, this requires everyone along the 
chain to agree on the SSRC for a particular stream, otherwise we have to 
rewrite the SSRC at some point.

In the switched multipoint case, this would mean that the switching 
point would have to rewrite the SSRC of an incoming media stream before 
forwarding it on, as it would be sending out a stream with a constant 
SSRC, consisting of the un-transcoded media from multiple sources with 
different SSRCs, suggesting falsely that the outgoing media stream is 
being generated as one continuous stream.
> capture+encoding has a major cost in bandwidth.
Indeed; we can't use the same SSRC for two streams over the same RTP 
session, so the only way to send the same media to two captures would be 
to send it twice.

-- 

Paul W

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Aug 2012 11:14:29 -0400

On 8/16/12 9:44 AM, Paul Witty wrote:
> identifies a media sender.

I'm no expert, but it is my impression that its permissible to have a 
transcoder that preserves the SSRC.

Can someone who is an expert confirm or deny this?

> By including the SSRC of the original stream

I wasn't thinking of the *consumer* declaring this.
I was thinking that this would be part of the advertisement.
But it does require some changes since the SSRC would need to be 
associated with the capture+encoding. I haven't thought through how that 
might be accomplished.

> being generated as one continuous stream.

I don't understand enough of RTP to know if that is valid.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Thu, 16 Aug 2012 18:35:06 +0200

Paul,
Look at my rtp mapping draft, an intermediary may keep the original SSRC
from the source or create an SSRC and have the source SSRC in the CSRC
field.
A transcoder will usually use his own SSRC since it is a different stream
from a different source (the transcoder)
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: 16 August, 2012 5:14 PM
To: [email-masked]
Subject: Re: [clue] Fwd: #11: RTP header extension for Capture ID

On 8/16/12 9:44 AM, Paul Witty wrote:
>>> Each encoded media stream must have a distinct SSRC. If a source is 
>>> sent in two separate requested captures (i.e. simulcasting of two 
>>> resolutions by a transcoding middle box), then the two encodings of 
>>> the same capture will have distinct SSRCs, but the SSRC of the 
>>> original encoding of the source as a CSRC.
>>

> By including the SSRC of the original stream in the transcoded stream 
> as a CSRC, we can then forward on RTCP information, such as SDES, from 
> the original sender to all receivers of the transcoded stream, to 
> ensure no information is lost. We still send the source SSRC (as a 
> CSRC), but make it clear that this is a transcode, and therefore 
> properties such as encryption state which are tied to an SSRC are not 
> incorrectly applied to the transcoded stream.
>>
> Potentially yes, by the consumer declaring the mapping of SSRC to 
> media stream properties (which capture is being shown, what are the 
> bounds on resolution/bandwidth etc). However, this requires everyone 
> along the chain to agree on the SSRC for a particular stream, 
> otherwise we have to rewrite the SSRC at some point.

I wasn't thinking of the *consumer* declaring this.
I was thinking that this would be part of the advertisement.
But it does require some changes since the SSRC would need to be associated
with the capture+encoding. I haven't thought through how that might be
accomplished.

> point would have to rewrite the SSRC of an incoming media stream 
> before forwarding it on, as it would be sending out a stream with a 
> constant SSRC, consisting of the un-transcoded media from multiple 
> sources with different SSRCs, suggesting falsely that the outgoing 
> media stream is being generated as one continuous stream.

>>> If we want to send the same encoding over two requested captures 
>>> (i.e. requesting both a single stream of loudest speaker, and 
>>> left/centre/right streams from a single endpoint, where the former 
>>> will always be one of the latter), we can use multiple instances of 
>>> the RTP extension in the RTP header, one for each of the requested 
>>> captures.
>>
> session, so the only way to send the same media to two captures would 
> be to send it twice.

	Thanks,
	Paul

---

From: Paul Witty <[email-masked]>
Date: Thu, 16 Aug 2012 19:29:17 +0100

> from the source or create an SSRC and have the source SSRC in the CSRC
Keeping the original SSRC should be preferred where possible - rewriting 
SSRCs results in the need to reauthenticate SRTP packets, as well as 
rewrite RTCP sender reports & SDES.  Rewriting two distinct streams to 
the same SSRC should definitely be avoided in my opinion, to ensure that 
within a single SSRC the sequence numbers, timestamps, encryption 
parameters all stay consistent, as well as other codec-specific features 
such as long term reference frames.
> from a different source (the transcoder)
Agreed.  I'd say should this should be upgraded from usually to always, 
to ensure there aren't two different streams (with independent sequence 
number, timestamp, encryption domains) with the same SSRC existing 
anywhere in the system.

-- 

Paul W

---

From: Paul Witty <[email-masked]>
Date: Thu, 16 Aug 2012 19:37:05 +0100

On 16/08/12 16:14, Paul Kyzivat wrote:
>>>> sent
I'm not an expert either, but I can see that, if there's no possibility 
of the original stream being seen on the opposite side of the 
transcoding device, and all the RTCP is terminated at the transcoding 
device (to prevent sender reports being sent which give incorrect facts 
about the transcoded stream, and to ensure the original encoder of the 
media doesn't receive misleading feedback), it would be possible.  I 
can't see why it would be desirable, however.
> associated with the capture+encoding. I haven't thought through how 
> that might be accomplished.
If the consumer asks for one stream at 720p, and one stream at CIF, it 
needs to know in advance of receiving the media, and without examining 
the media (as it may not be capable of decoding), which of the two 
streams being sent are which.  This can't be done in the advertisement, 
because the provider only offers the ability to do multiple streams, and 
doesn't know exactly what the consumer will request, and so can't 
provide enough information in advance for the consumer to know which is 
which; the consumer has to do some level of saying "this identifier 
(whether multiplexing ID, or SSRC) matches this request".  The 
identifiers may be pre-allocated by the provider, but the consumer has 
to either tell the provider for each requested stream what identifier it 
would like the provider to use, or the provider can, in response to the 
request, give the consumer the mapping from identifier to requested stream.

-- 

Paul W

---

From: Colin Perkins <[email-masked]>
Date: Fri, 17 Aug 2012 14:51:04 +0300

On 16 Aug 2012, at 18:14, Paul Kyzivat wrote:
> I'm no expert, but it is my impression that its permissible to have a transcoder that preserves the SSRC.
> 

You could implement the transcoder as two back-to-back RTP endpoints and so two separate RTP sessions, where the SSRC used by the transcoder just happens to be the same in each session. 

Alternatively, you could implement the transcoder as an RFC 3550-style translator. That could maintain the SSRC of the transcoded stream, but would need to rewrite RTCP to match the transcoding operation [RFC3550 section 7.2] since there would be a common RTP session across the RTP translator.

-- 
Colin Perkins
http://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Aug 2012 10:47:05 -0400

> Alternatively, you could implement the transcoder as an RFC 3550-style translator. That could maintain the SSRC of the transcoded stream, but would need to rewrite RTCP to match the transcoding ope…

Thanks Colin!

The latter is probably what I was thinking of. I gather this is a fairly 
mainstream mechanism, rather than being something weird.

	Thanks,
	Paul

---

From: Paul Witty <[email-masked]>
Date: Fri, 17 Aug 2012 16:17:22 +0100

On 17/08/12 15:47, Paul Kyzivat wrote:
>> You could implement the transcoder as two back-to-back RTP endpoints 
>> and so two separate RTP sessions, where the SSRC used by the 
>> transcoder just happens to be the same in each session.
>>
>> Alternatively, you could implement the transcoder as an RFC 
>> 3550-style translator. That could maintain the SSRC of the transcoded 
>> stream, but would need to rewrite RTCP to match the transcoding 
>> operation [RFC3550 section 7.2] since there would be a common RTP 
>> session across the RTP translator.
>
> Thanks Colin!
>
> The latter is probably what I was thinking of. I gather this is a 
> fairly mainstream mechanism, rather than being something weird.
>

I'm not sure mainstream is the right word; I don't believe I've ever 
seen an implementation of such.

A translator like this wouldn't work if a stream is being transcoded to 
two simulcasted streams; as at least one of them should have a new SSRC, 
which to me seems like a good reason that every transcode should be 
given a new SSRC.

-- 

Paul W

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Aug 2012 11:28:22 -0400

I'm going to defer to Colin on this.

	Thanks,
	Paul K

---

From: Colin Perkins <[email-masked]>
Date: Sun, 19 Aug 2012 13:10:32 +0300

On 17 Aug 2012, at 18:17, Paul Witty wrote:
>> The latter is probably what I was thinking of. I gather this is a fairly mainstream mechanism, rather than being something weird.
>> 
> 
> I'm not sure mainstream is the right word; I don't believe I've ever seen an implementation of such.

It's a long-standing part of the standard, and we've seen implementations in the past. I doubt it's a popular approach though, since rewriting RTCP is non-trivial. 

> A translator like this wouldn't work if a stream is being transcoded to two simulcasted streams; as at least one of them should have a new SSRC, which to me seems like a good reason that every transcode should be given a new SSRC.

Which makes it essentially an RTP mixer, or a back-to-back endpoint. Both would work, of course, but are visible in the session, whereas a pure RTP translator is not.

-- 
Colin Perkins
http://csperkins.org/