Subject: [clue] draft-hansen-clue-sdp-interaction-00

From: Robert Hansen <[email-masked]>
Date: Mon, 18 Feb 2013 20:03:56 +0000

Hi all,

I've posted a new draft which will hopefully have a relatively short 
lifespan on the topic of the interactions between CLUE signalling and 
SDP - as we've discovered when we've tried to define things like call 
flows a lot of the different aspects are dependant on each other, making 
it hard to make a decision. I picked a couple of points that I believe 
aren't so entangled.

Some of these things in it are hopefully uncontroversial but haven't 
always been documented yet, others are likely to provoke more disagreement.

There's no attempt in the draft at defining the SDP or CLUE messages, 
the draft merely discusses what information is needed in each and how 
they should interact.

For -01 I hope to add some diagrams to better illustrate what's going on.

Rob

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Feb 2013 17:11:19 -0500

Hi Rob,

You make good points in this document.
IMO this material fits well in section 4 of the signaling draft.
The xml for the -02 version is posted, so please feel free to put this 
material in there.

With regard to how much to put in SDP, I remain conflicted.
There are advantages to putting all the encoding stuff in SDP, but 
starting to describe what can be sent as well as what can be received in 
O/A may open a can of worms. Certainly that needs to be discussed in the 
larger MMUSIC context, and may be difficult.

Also, other applications that want to make use of that machinery will 
have to invent their own way to discover enough about the available 
encodings to decide which to choose.

An alternative would be to conclude that much of CLUE is independent of 
telepresence - is rather just about negotiating which of a bunch of 
available captures to send and receive, while many of the specific 
attributes (e.g. spatial information) are telepresence specific. Then 
others could use the same machinery, but with different attributes 
specific to their application. In this approach, all the stuff about 
*available* encodings could be viewed as appropriate to the CLUE 
protocol, while the in-use encodings would continue to be part of SDP.

I could go either way on this. Would like to hear what others have to say.

	Thanks,
	Paul (as individual)

On 2/18/13 3:03 PM, Robert Hansen wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 28 Feb 2013 17:39:45 +1100

Hello Rob,

With regards to 4.2, you mention that middleboxes may want to alter the 
SDP without involving themselves in CLUE. Isn't this fought with 
problems if the middleboxes go and change SDP information related to 
Clue without understanding any constraints indicated by CLUE?

Can you give examples of the reference CLUE->SDP? I've currently been 
thinking that as SDP will be used to establish media after the CLUE 
exchange that it would construct the SDP with a reference to the CLUE 
media capture or other construct.

Section 5: I support CLUE and SDP being independent. I'm abit confused 
regarding the "reference to SDP contents". I take it that we're not 
talking about using actual SDP in CLUE rather referring to the 
information indicated by SDP.

Regards, Christian

On 19/02/2013 7:03 AM, Robert Hansen wrote:
> flows a lot of the different aspects are dependant on each other, 
> making it hard to make a decision. I picked a couple of points that I 
> believe aren't so entangled.
>