Subject: [avtext] New work to implement unified plan

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 1 Aug 2013 12:46:26 +0000

(As WG cochair)

The MMUSIC WG agreed to adopt the unified plan as defined in 

https://datatracker.ietf.org/doc/draft-roach-mmusic-unified-plan/

for RTCWEB usage. 

How many of the resultant deliverables will be generally applicable rather than specific to RTCWEB usage is up to the individual working groups.

At RTCWEB, Adam had a slide that identified the following as being pointed in the direction of AVTEXT:

"Harmonize AppID handling with early media correlation token"

In order to charter new work, we need to persuade the working group, and the AD to accept the new work. For that we need some definition of what the work is about. To be reasonably quick about this we need to do this via the list rather than wait for Vancouver.

It would be nice if we could use the list to generate a scope or abstract of the suggested deliverable, for what we think AVTEXT should be doing based on the above.

Adam, Roni or Jonathan, can you provide some input.

Regards

Keith

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 1 Aug 2013 10:43:06 -0400

[As co-author of the AppID individual draft; this is my personal opinion.]

The purpose of this work is to create RTP/RTCP mechanisms by which RTP streams can be corrolated to external signaling information, in particular (for the Unified plan) to correlate them with the constituent m-line sections of an SDP BUNDLE group.

The current proposals envision using an RTP header extension, as well as (in the AppID proposal) an RTCP SDES item.

This correlation needs to be done in terms other than the streams' SSRC values, both for reasons of dynamicity (as the stream that satisfies a particular application usage can change, potentially quickly and frequently) and also due to race conditions involving early media in an SDP offer/answer (as RTP traffic can out-race an answer).

The solution needs to be designed to handle the details of the Unified plan, in particular how Unified describes and negotiates scenarios where multiple RTP streams jointly encode a single media source, such as RTX, FEC, MST layering, and simulcast. 

The solution shouldn't be exclusive to the Unified plan, however; in particular, there's a desire that it be useful for the CLUE working group as well.

On Aug 1, 2013, at 2:46 PM, "DRAGE, Keith (Keith)" <[email-masked]> wrote:

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

--
Jonathan Lennox
[email-masked]

---

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 2 Aug 2013 09:36:01 +0200

My understanding was AppID is sender based and the correlator is receiver
driven. Both solve correlation of the incoming packet to a particular
m=line but the latter also solves early media clipping scenarios

We need a combination of both if i am not wrong

Cheers
Suhas

On Thu, Aug 1, 2013 at 4:43 PM, Jonathan Lennox <[email-masked]> wrote:

> The purpose of this work is to create RTP/RTCP mechanisms by which RTP
> streams can be corrolated to external signaling information, in particular
> (for the Unified plan) to correlate them with the constituent m-line
> sections of an SDP BUNDLE group.
>
> The current proposals envision using an RTP header extension, as well as
> (in the AppID proposal) an RTCP SDES item.
>
> This correlation needs to be done in terms other than the streams' SSRC
> values, both for reasons of dynamicity (as the stream that satisfies a
> particular application usage can change, potentially quickly and
> frequently) and also due to race conditions involving early media in an SDP
> offer/answer (as RTP traffic can out-race an answer).
>
> The solution needs to be designed to handle the details of the Unified
> plan, in particular how Unified describes and negotiates scenarios where
> multiple RTP streams jointly encode a single media source, such as RTX,
> FEC, MST layering, and simulcast.
>
> The solution shouldn't be exclusive to the Unified plan, however; in
> particular, there's a desire that it be useful for the CLUE working group
> as well.
>
> > How many of the resultant deliverables will be generally applicable
> rather than specific to RTCWEB usage is up to the individual working groups.
> >
> > In order to charter new work, we need to persuade the working group, and
> the AD to accept the new work. For that we need some definition of what the
> work is about. To be reasonably quick about this we need to do this via the
> list rather than wait for Vancouver.
> >
> > It would be nice if we could use the list to generate a scope or
> abstract of the suggested deliverable, for what we think AVTEXT should be
> doing based on the above.
> >

---

From: "Roni Even" <[email-masked]>
Date: Fri, 2 Aug 2013 11:30:41 +0300

Hi,

We mentioned this as an open issue in our presentation in MMUSIC. 

At first look it seems we can use receiver driven correlator (appId) in SDP
offer answer and it will work for RTCweba and CLUE, but we need to look
carefully at FEC, RTX, MST layering and simulcast support  to verify that
using receiver driven assignment works. 

Roni 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Suhas Nandakumar
Sent: 02 August, 2013 10:36 AM
To: Jonathan Lennox
Cc: [email-masked]
Subject: Re: [avtext] New work to implement unified plan

My understanding was AppID is sender based and the correlator is receiver
driven. Both solve correlation of the incoming packet to a particular m=line
but the latter also solves early media clipping scenarios

Cheers

Suhas

The current proposals envision using an RTP header extension, as well as (in
the AppID proposal) an RTCP SDES item.

This correlation needs to be done in terms other than the streams' SSRC
values, both for reasons of dynamicity (as the stream that satisfies a
particular application usage can change, potentially quickly and frequently)
and also due to race conditions involving early media in an SDP offer/answer
(as RTP traffic can out-race an answer).

The solution needs to be designed to handle the details of the Unified plan,
in particular how Unified describes and negotiates scenarios where multiple
RTP streams jointly encode a single media source, such as RTX, FEC, MST
layering, and simulcast.

The solution shouldn't be exclusive to the Unified plan, however; in
particular, there's a desire that it be useful for the CLUE working group as
well.

On Aug 1, 2013, at 2:46 PM, "DRAGE, Keith (Keith)"
<[email-masked]> wrote:

> How many of the resultant deliverables will be generally applicable rather
than specific to RTCWEB usage is up to the individual working groups.
>
> It would be nice if we could use the list to generate a scope or abstract
of the suggested deliverable, for what we think AVTEXT should be doing based
on the above.

--
Jonathan Lennox
[email-masked]

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 2 Aug 2013 04:48:15 -0400

The specific requirement, as I understand it, is that when a new sendrecv or recvonly m-line section is offered (either in an initial offer, or when a new m-line is added), the receiver needs to specify sufficient information for correlation so it can correctly map the media for that m-line if it outraces the answer.

This doesn't necessarily imply that all app-ids must always and only be set by a receiver.  But of course, simplicity is a virtue, so it's better to prefer a simpler rule if possible.

On Aug 2, 2013, at 10:30 AM, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:

Hi,
We mentioned this as an open issue in our presentation in MMUSIC.
At first look it seems we can use receiver driven correlator (appId) in SDP offer answer and it will work for RTCweba and CLUE, but we need to look carefully at FEC, RTX, MST layering and simulcast support  to verify that using receiver driven assignment works.

Roni

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Suhas Nandakumar
Sent: 02 August, 2013 10:36 AM
To: Jonathan Lennox
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [avtext] New work to implement unified plan

My understanding was AppID is sender based and the correlator is receiver driven. Both solve correlation of the incoming packet to a particular m=line but the latter also solves early media clipping scenarios

Cheers
Suhas

On Thu, Aug 1, 2013 at 4:43 PM, Jonathan Lennox <[email-masked]<mailto:[email-masked]>> wrote:
[As co-author of the AppID individual draft; this is my personal opinion.]

On Aug 1, 2013, at 2:46 PM, "DRAGE, Keith (Keith)" <[email-masked]<mailto:[email-masked]>> wrote:

> [email-masked]<mailto:[email-masked]>
--
Jonathan Lennox
[email-masked]<mailto:[email-masked]>

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

--
Jonathan Lennox
[email-masked]<mailto:[email-masked]>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 2 Aug 2013 01:56:23 -0700

I agree with Roni that an examination of FEC, RTX, SST/MST layering and simulcast layering will be necessary to understand app-id usage scenarios (and implications for a MANE). 
As an example, if the app-id is chosen by each receiver in a conference independently, then a MANE may need to rewrite the app-id before sending the media (as it may do with the SSRC).  

From: [email-masked]
To: [email-masked]; [email-masked]
Date: Fri, 2 Aug 2013 11:30:41 +0300
CC: [email-masked]
Subject: Re: [avtext] New work to implement unified plan

Hi,We mentioned this as an open issue in our presentation in MMUSIC. At first look it seems we can use receiver driven correlator (appId) in SDP offer answer and it will work for RTCweba and CLUE, but we need to look carefully at FEC, RTX, MST layering and simulcast support  to verify that using receiver driven assignment works.  Roni  From: [email-masked] [mailto:[email-masked]] On Behalf Of Suhas Nandakumar
Sent: 02 August, 2013 10:36 AM
To: Jonathan Lennox
Cc: [email-masked]
Subject: Re: [avtext] New work to implement unified plan My understanding was AppID is sender based and the correlator is receiver driven. Both solve correlation of the incoming packet to a particular m=line but the latter also solves early media clipping scenarios We need a combination of both if i am not wrong CheersSuhas On Thu, Aug 1, 2013 at 4:43 PM, Jonathan Lennox <[email-masked]> wrote:[As co-author of the AppID individual draft; this is my personal opinion.]

Jonathan Lennox
[email-masked]