Subject: [clue] RTCWEB: using SDP "blob" and O/A model

From: Mary Barnes <[email-masked]>
Date: Thu, 7 Mar 2013 12:08:15 -0600

I really think CLUE folks need to read this thread and understand the issues:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg06612.html

While we aren't defining an API, we are defining a application.  I
think it's important to carefully consider the tradeoffs in terms of
how much is carried in SDP versus how much we can do with a CLUE
specific protocol.

<as an individual>
I really, really think that the more we put in SDP, the less
extensibility we will have for the CLUE application - I  think we
really, really need to carefully weigh the tradeoffs between tightly
coupling the CLUE application to SDP versus minimizing the
interactions and duplication of information.

In one sense, this is a similar problem we faced with SIP
conferencing.  We defined some basic extensions that worked just fine.
But, it would have been a bear to add all the additional functionality
for complex scenarios to SIP.  Instead, we defined XCON, which
decouples the conferencing application from the session
setup/signaling protocol.  XCON is highly extensible and flexible and
provides a rich set of application functionality.  I believe we want
to same with CLUE a

</individual>

Mary.

---

From: Mary Barnes <[email-masked]>
Date: Thu, 7 Mar 2013 12:49:14 -0600

Also (and more relevant to CLUE), please keep in mind that Rob's draft
gets very much into this topic as to the split between CLUE and SDP as
well as advantages/disadvantages:
http://datatracker.ietf.org/doc/draft-hansen-clue-sdp-interaction/

We will discuss this in our first session on Monday.

Thanks,
Mary.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Mar 2013 03:12:11 +0800

I don't fully agree with Mary on this.

First, I don't think that discussion in RTCWEB has much bearing on CLUE.
RTCWEB uses a non-sip signaling model. And it doesn't even call for use 
of SDP in signaling. Rather it only uses SDP for communication between 
the javascript and the browser it runs in. It doesn't require that the 
SDP constructed in one broswer be identical to that seen in the browser 
at the other end. SDP has long been a poor choice for the purpose we use 
it, but we have legacy reasons to continue and efforts to move to SDPng 
failed. It is extremely poor as an abstract conceptual representation 
for an API. So IMO it makes sense to think hard about whether to use it 
in RTCWEB. The argument there is not what to put in SDP and what to do 
another way, it is about whether to use SDP or not.

But CLUE is mostly SIP-based. We are going to be using SDP. For us the 
question is how much to put in SDP and how much to put in the CLUE 
protocol. I don't think the rtcweb arguments are helpful about that.

IMO we should use SDP for the things it does, and perhaps extend it a 
bit for things it *ought* to do, philosophically. SDP O/A is focused on 
two ends negotiating based on what each is prepared to receive. 
Sometimes it talks about what is to be sent, but it isn't so good about 
that. In the end the result of the negotiation defines characteristics 
of what *will* be sent. And that part is important to some middle boxes, 
so we should try hard not to break that.

Clue is focused on presenting a menu of what *could* be *sent* and then 
selecting from that menu what should be sent, and how. It is pretty hard 
to work out what SDP is required until all that is known. So I prefer 
keeping the division that way - the SDP is only used to signal the 
details to support what will be sent, based on what was agreed in the 
clue signaling.

In some cases this may lead to conflicts. For instance, SDP has the 
a=content attribute. In our clue data model and signaling we will have a 
much richer mechanism to describe similar characteristics. IMO we should 
not feel a need to exclusively use SDP for this. I don't know that we 
need to use it at all between clue-aware endpoints, though we ought to 
do as much as we can when talking to legacy endpoints.

So in practice I will probably agree with Mary most of the time about 
what should be in SDP and what should not.

I'll also observe that the less we depend on SDP the less trouble we 
will have making CLUE work in RTCWEB.

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Thu, 7 Mar 2013 13:16:20 -0600

> I don't fully agree with Mary on this.
[MB] As an individual and not as a chair I am hoping ;) [/MB]
> RTCWEB uses a non-sip signaling model. And it doesn't even call for use of
> SDP in signaling. Rather it only uses SDP for communication between the
> javascript and the browser it runs in. It doesn't require that the SDP
> constructed in one broswer be identical to that seen in the browser at the
> other end. SDP has long been a poor choice for the purpose we use it, but we
> have legacy reasons to continue and efforts to move to SDPng failed. It is
> extremely poor as an abstract conceptual representation for an API. So IMO
> it makes sense to think hard about whether to use it in RTCWEB. The argument
> there is not what to put in SDP and what to do another way, it is about
> whether to use SDP or not.
>
> question is how much to put in SDP and how much to put in the CLUE protocol.
> I don't think the rtcweb arguments are helpful about that.
>
> IMO we should use SDP for the things it does, and perhaps extend it a bit
> for things it *ought* to do, philosophically. SDP O/A is focused on two ends
> negotiating based on what each is prepared to receive. Sometimes it talks
> about what is to be sent, but it isn't so good about that. In the end the
> result of the negotiation defines characteristics of what *will* be sent.
> And that part is important to some middle boxes, so we should try hard not
> to break that.
>
> selecting from that menu what should be sent, and how. It is pretty hard to
> work out what SDP is required until all that is known. So I prefer keeping
> the division that way - the SDP is only used to signal the details to
> support what will be sent, based on what was agreed in the clue signaling.
>
> much richer mechanism to describe similar characteristics. IMO we should not
> feel a need to exclusively use SDP for this. I don't know that we need to
> use it at all between clue-aware endpoints, though we ought to do as much as
> we can when talking to legacy endpoints.
>
> So in practice I will probably agree with Mary most of the time about what
> should be in SDP and what should not.
>
> I'll also observe that the less we depend on SDP the less trouble we will
> have making CLUE work in RTCWEB.
[MB] <as an individual>  Yes - I totally agree. [/MB]

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Mar 2013 19:39:39 +0000

Hi,

I agree with Paul.

My personal starting point is still that the CLUE signalling should be used for the telepresence application related stuff, like spatial relationship etc.

I also don't think that the RTCWEB outcome affect us, as far as our mechanism is concerned. However, if RTCWEB loses interest in pushing for SDP and/or RTP extensions that we also are interested in, WE may have to become more active in that work.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] on behalf of Paul Kyzivat [[email-masked]]
Sent: Thursday, 07 March 2013 9:12 PM
To: Mary Barnes
Cc: CLUE
Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model

        Thanks,
        Paul

> provides a rich set of application functionality.  I believe we want

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

---

From: Mary Barnes <[email-masked]>
Date: Thu, 7 Mar 2013 13:48:48 -0600

> I also don't think that the RTCWEB outcome affect us, as far as our mechanism is concerned. However, if RTCWEB loses interest in pushing for SDP and/or RTP extensions that we also are interested in…
[MB]
<as individual> I wasn't suggesting that their decision as to the
mechanism would directly impact CLUE.  I'm suggesting that some of the
challenges they are having are due to the fact that they are trying to
use SDP for something that it really wasn't designed or envisioned to
be used for.   I do believe that some of the issues with SDP that they
are encountering that is making folks rethink the RTCWEB decision are
not unlike those that CLUE may have to deal with.  I strongly believe
that decoupling the CLUE application from SDP as much as possible is a
better path than trying to put so much into SDP (which is a *similar*
discussion as is happening in RTCWEB in terms of decoupling the API
from SDP).   I understand that we are using SIP for session setup, so
of course, we will need to use SDP O/A and thus we can't totally
decouple.  As we have been discussing for well over a year, the
challenge is how much of the CLUE application information should be
carried in SDP versus a CLUE specific protocol.
</individual>

<as chair>  We should already be more active in the work and not
expect that we would just use what RTCWEB needs. CLUE requirements
should be considered equal to those of RTCWEB.   I think we also need
to be very thoughtful as to how we make our decisions so we don't end
up a year from now with folks questioning the path we chose.
</chair>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Mar 2013 04:00:19 +0800

Mary reminded me that I failed to indicate if I was speaking as an 
individual or a chair.

I was definitely speaking as an individual.

	Sorry,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Mar 2013 04:07:58 +0800

(as individual)

Perhaps we should talk in rtcweb about what we are doing in clue, and 
suggest that some of the understanding of what the multiple streams 
*mean* in rtcweb should be left as application-specific.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 08 Mar 2013 14:33:35 +1100

Hello,

I think part of the problem may be that when people talk about "CLUE" 
they actually mean different things.

For me there's two aspects: 1) CLUE as a signalling protocol, and 2) how 
to use CLUE in a SIP network.

For 1) I can't see any need to incorporate SDP into the CLUE signalling.
For 2) SDP will be required in SIP networks to establish the CLUE data 
channel. SDP will also be required to establish the media.

It would be good for people to clarify what they mean when they are 
talking about SDP.

I personally think the RTCWEB work is a distraction and likewise the 
RTPMUX work for the CLUE signalling protocol. RTPMUX is important for 
the establishment of media.

Regards, Christian

On 8/03/2013 7:07 AM, Paul Kyzivat wrote:
>>> My personal starting point is still that the CLUE signalling should 
>>> be used for the telepresence application related stuff, like spatial 
>>> relationship etc.
>>>
>>> I also don't think that the RTCWEB outcome affect us, as far as our 
>>> mechanism is concerned. However, if RTCWEB loses interest in pushing 
>>> for SDP and/or RTP extensions that we also are interested in, WE may 
>>> have to become more active in that work.
>> [MB]

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 09 Mar 2013 00:00:56 +0800

Hi Christian,

> to use CLUE in a SIP network.

OK. I'll agree with you that these are conceptually different things, 
and that we we have not been keeping them distinct. I think one reason 
is that we aren't entirely sure where to draw the line between them.

> For 1) I can't see any need to incorporate SDP into the CLUE signalling.

AFAIK nobody is proposing the "incorporate SDP into the CLUE signaling".

But we are considering omitting some things from the CLUE signaling 
because they will instead be signaled in SDP. And also, there is a need 
to couple the CLUE signaling to the SDP - at least to correlate a 
capture-encoding in a Configure to an m-line in the SDP. (And maybe some 
correlation between the Advertisement and the SDP as well.)

> It would be good for people to clarify what they mean when they are

AFAIK SDP is well defined - except when we are talking about 
hypothetical extensions to it.

> I personally think the RTCWEB work is a distraction

It is distracting, but IMO it is an important and relevant distraction.
We don't want the two groups to invent two new wheels when one would do.
And we want clue to be able to work with RTCWEB endpoints.

As messy as it has become, ISTM that the two groups are exploring a 
similar set of new functionalities for RTP from different perspectives. 
I have hope that this will lead to a clearer understanding than if we 
did it independently.

> and likewise the

I don't understand your point here. You are saying the RTPMUX is 
important but its a distraction???

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 12 Mar 2013 09:11:16 +1100

Hello Paul,

Please see my response below.

Regards, Christian

On 9/03/2013 3:00 AM, Paul Kyzivat wrote:
> because they will instead be signaled in SDP. And also, there is a 
> need to couple the CLUE signaling to the SDP - at least to correlate a 
> capture-encoding in a Configure to an m-line in the SDP. (And maybe 
> some correlation between the Advertisement and the SDP as well.)
[CNG] Omitting? IS there something in the framework that is thought can 
be omitted?
> hypothetical extensions to it.
[CNG] OK my last sentence could have had a few extra words in it. I'm 
sure people know what SDP is. I was referring to that when people use 
the term SDP with CLUE it would be good to be more specific, i.e. SDP to 
correlate captures with stream etc.
> similar set of new functionalities for RTP from different 
> perspectives. I have hope that this will lead to a clearer 
> understanding than if we did it independently.

> important but its a distraction???
[CNG] Yes. The CLUE protocol can/should happily exist without the need 
for RTPMUX. Of course as the framework points out there are real world 
limitation on ports. Endpoints implementing CLUE may also want to 
implement RTPMuxing. We should be able to finish the CLUE work even if 
RTPmux work is ongoing.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Mar 2013 08:25:01 -0400

<hat type="individual"/>

I think this is a very useful taxonomy, and it seems like this group should
focus on (1), at least initially.  CLUE is about providing metadata on how
a set of media streams relate to one another, so we should aspire to clean
layering here.  The CLUE protocol (1) should be mostly independent of SDP,
as suggested by the last presentation yesterday.

For example, ISTM that one very positive outcome here would be if it were
possible for me to write an RTCWEB web app for telepresence, where the
browser hands me a collection of media streams and a data channel, then I
use CLUE over the data channel to figure out how to render those streams
(and tell the far side about my streams).

--Richard

On Thu, Mar 7, 2013 at 10:33 PM, Christian Groves <
[email-masked]> wrote:

> Hello,
>
> I think part of the problem may be that when people talk about "CLUE" they
> actually mean different things.
>
> RTPMUX work for the CLUE signalling protocol. RTPMUX is important for the
> establishment of media.
>
> Regards, Christian
>
>
>> suggest that some of the understanding of what the multiple streams *mean*
>> in rtcweb should be left as application-specific.
>>
>>     Thanks,
>>     Paul
>>
>>> <christer.holmberg@ericsson.**com <[email-masked]>>
>>> wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> I agree with Paul.
>>>>
>>>> My personal starting point is still that the CLUE signalling should be
>>>> used for the telepresence application related stuff, like spatial
>>>> relationship etc.
>>>>
>>>> mechanism is concerned. However, if RTCWEB loses interest in pushing for
>>>> SDP and/or RTP extensions that we also are interested in, WE may have to
>>>> become more active in that work.
>>>>
>>> [MB]
>>>> ______________________________**__________
>>>>> http://www.ietf.org/mail-**archive/web/rtcweb/current/**msg06612.html<http://www.ietf.org/mail-archive/web/rtcweb/current/msg06612.html>
>>>>>
>>>> ______________________________**_________________
>>>> 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: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Mar 2013 20:29:38 +0800

> [CNG] Omitting? IS there something in the framework that is thought can

There have been some proposals that information about encodings might be 
entirely in SDP. There has been no decision to go that way, but it is a 
possibility.

[snip]

> implement RTPMuxing. We should be able to finish the CLUE work even if

OK, good point. I agree this is possible.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Mar 2013 19:44:37 +0800

On 3/12/13 8:25 PM, Richard Barnes wrote:
> <hat type="individual"/>
>
> I think this is a very useful taxonomy, and it seems like this group
> should focus on (1), at least initially.  CLUE is about providing
> metadata on how a set of media streams relate to one another, so we
> should aspire to clean layering here.  The CLUE protocol (1) should be
> mostly independent of SDP, as suggested by the last presentation yesterday.
>
> For example, ISTM that one very positive outcome here would be if it
> were possible for me to write an RTCWEB web app for telepresence, where
> the browser hands me a collection of media streams and a data channel,
> then I use CLUE over the data channel to figure out how to render those
> streams (and tell the far side about my streams).

Yes!!! That has been one of my objectives.

But that also implies that clue's use of SDP be compatible with 
RTCWEB's. And that too cuts two ways:

- whatever RTCWEB requires in SDP in order to properly set up
   media streams in the browser must be consistent with the
   way CLUE uses SDP.

- any "extra" SDP that CLUE might use had better be settable/
   gettable by the javascript in the browser.

Of course the signaling the rtcweb app does *might* not be sip (e.g. 
might be jingle) and *might* not contain actual SDP, but if not then the 
web server will generally need to map it SIP/SDP, so it amounts to the 
same thing.

	Thanks,
	Paul

> --Richard
>
>
> On Thu, Mar 7, 2013 at 10:33 PM, Christian Groves
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hello,
>
>     I think part of the problem may be that when people talk about
>     "CLUE" they actually mean different things.
>
>     For me there's two aspects: 1) CLUE as a signalling protocol, and 2)
>     how to use CLUE in a SIP network.
>
>     For 2) SDP will be required in SIP networks to establish the CLUE
>     data channel. SDP will also be required to establish the media.
>
>     RTPMUX work for the CLUE signalling protocol. RTPMUX is important
>     for the establishment of media.
>
>     Regards, Christian
>
>
>         Perhaps we should talk in rtcweb about what we are doing in
>         clue, and suggest that some of the understanding of what the
>         multiple streams *mean* in rtcweb should be left as
>         application-specific.
>
>              Thanks,
>              Paul
>
>             <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>
>                 Hi,
>
>                 I agree with Paul.
>
>                 My personal starting point is still that the CLUE
>                 signalling should be used for the telepresence
>                 application related stuff, like spatial relationship etc.
>
>                 I also don't think that the RTCWEB outcome affect us, as
>                 far as our mechanism is concerned. However, if RTCWEB
>                 loses interest in pushing for SDP and/or RTP extensions
>                 that we also are interested in, WE may have to become
>                 more active in that work.
>
>             [MB]
>                 __________________________________________
>                 From: [email-masked]
>                 <mailto:[email-masked]> [[email-masked]
>                 <mailto:[email-masked]>] on behalf of Paul
>                 Kyzivat [[email-masked]
>                 <mailto:[email-masked]>]
>                     http://www.ietf.org/mail-__archive/web/rtcweb/current/__msg06612.html
>                     <http://www.ietf.org/mail-archive/web/rtcweb/current/msg06612.html>
>
>                 _________________________________________________
>                 clue mailing list
>                 [email-masked] <mailto:[email-masked]>
>                 https://www.ietf.org/mailman/__listinfo/clue
>                 <https://www.ietf.org/mailman/listinfo/clue>
>
>
>
>         _________________________________________________
>         clue mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/clue
>         <https://www.ietf.org/mailman/listinfo/clue>
>
>
>     _________________________________________________
>     clue mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/clue
>     <https://www.ietf.org/mailman/listinfo/clue>
>
>
>
>