Re: [clue] Subject matter for Monday's call

[Christian Groves <[e-mail]>]

Hello Stephan and Simon,

Thanks for the clarification/confirmation. This sounds reasonable to me. 
I was a bit thrown by "We believe that there was sufficient pushback 
against that idea to make rapid progress based on this assumption 
unlikely" from your original email.

Regards, Christian

On 2/12/2012 5:06 AM, Stephan Wenger wrote:
> Yes, this is what we thought as a reasonable starting point for a 
> discussion.
> S.
>
>
> From: Simon Pietro Romano <[e-mail] <mailto:[e-mail]>>
> Date: Saturday, 1 December, 2012 09:59
> To: Stephan Wenger <[e-mail] <mailto:[e-mail]>>
> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] 
> <mailto:[e-mail]>>
> Subject: Re: [clue] Subject matter for Monday's call
>
> Hi Stephan,
>
> this flow sounds reasonable to me. Just to make sure that I am not 
> misunderstanding something, let me ask you whether steps 3 through 6 
> are in your mind carried out over an ad hoc created CLUE channel 
> between Alice and Bob.
>
> I keep on thinking that a CLUE channel needs to be established, at 
> least for exchanging spatial information that cannot be 
> straightforwardly inserted into SDP.
> As I said at the meeting in Atlanta, I would envisage the following 
> high-level sequence of interactions:
>
> a. SIP-based COMEDIA negotiation between Alice and Bob, aimed at 
> establishing the CLUE channel (which would be done through steps 1. 
> and 2. of the flow you sketched);
> b. CLUE channel used to exchange XML documents containing CLUE-realted 
> information for which no direct mapping onto SDP has been identified 
> (steps 3 through 6 in your flow);
> c. SIP/SDP used to establish the needed media channel(s), as well as 
> to transport CLUE-related information for which a mapping onto SDP has 
> been identified (steps 7. and 8. in your flow).
>
> Obviously, phases b. and c. above are in some way coupled, since they 
> are both needed in order to provide CLUE entities with the whole 
> picture associated with a telepresence scenario.
>
> Is this interpretation correct?
>
> Cheers,
>
> Simon
>
>
> Il giorno 01/dic/2012, alle ore 17:56, Stephan Wenger ha scritto:
>
>> Hi all,
>>
>> Mark, Andy, and myself had a bit of brainstorming how to most 
>> productively use our time during the Monday morning call. Due to 
>> travel and vacation schedule, our coordination was finalized call 
>> only late Friday. Which may serve as an explanation, if not as an 
>> excuse, for the late timing of this email.
>>
>> In our opinion, the most pressing issue we have with the framework 
>> document is it being agnostic to the protocol elements used to convey 
>> the various messages that are part of the framework. Clearly, the 
>> framework was written from a perspective where a CLUE protocol 
>> channel would be established, and (all?) further signaling would be 
>> dealt with over that channel. So is, more or less, the call flow doc. 
>> We believe that there was sufficient pushback against that idea to 
>> make rapid progress based on this assumption unlikely. Accordingly, 
>> we believe that we probably best spend most of our time by discussing 
>> a strawman for a split-up between SDP-represented, SIP-ish, 
>> Offer-Answer, …, that type of traditional messages, and (XML-coded) 
>> messages sent over the CLUE. The focus of our Monday call would be on 
>> the initial exchange, rather than any updates that may happen during 
>> a call.
>>
>> With reference to the call flow 02 doc 
>> (https://datatracker.ietf.org/doc/draft-romanow-clue-call-flow/?include_text=1) 
>> that exchange could look as follows:
>>
>>  1. Invite from Alice, just like A.1 in call-flow-02
>>  2. 200 OK from Bob, A.2
>>  3. CLUE Advertisement Alice A.3, covering geometry stuff, encoding
>>     groups, etc.
>>  4. CLUE Advertisement Bob A.4; note that 3 and 4 would in practice
>>     overlap in time
>>  5. CLUE Response from Alice A.5, with the difference that these
>>     reposes DO NOT have the side effect of initiating any media
>>     channel related activity; they are pure signaling
>>  6. CLUE Response from Bob, A.6, same remark.. 5 and 6 could overlap
>>     in time.
>>  7. Re-invite from Alice and Bob, respectively, with media channels
>>     as CLUE-"negotiated"
>>  8. 200 OK from Bob, Alice. As the endpoints have already established
>>     their operation points through CLUE, this step will not fail
>>     except if an entity not involved in the CLUE negotiation
>>     intervenes—i.e. a middle box doesn't like that call.
>>
>> The reason for the existence of step 7, rather than setting up media 
>> channels as side effect of steps 3 through 6 (as assumed in call flow 
>> and in the current framework doc) is twofold: easier integration into 
>> the source base of media codecs that currently use SDP for the 
>> selection of their parameters, and making middlebox people happy.
>>
>> The reason for the existence of steps 3 through 6 is our agreement 
>> that not all useful protocol elements envisioned in the framework can 
>> be reasonably and meaningfully implemented in SDP extensions. This is 
>> certainly true for the geometry stuff.
>>
>> The reason for keeping an encoding group concept in CLUE is that a 
>> representation of the information that can be conveyed through 
>> individual encoding descriptions, encoding groups, and the 
>> association of media captures with encoding groups (section 7 and 8 
>> of the framework) purely through grouped m-lines would lead to 
>> bloated (if not exploded :-) SDP, quite possibly well beyond a 
>> reasonable size (i.e. MTU size); the high level of abstraction 
>> offered by concepts such as encoding groups, simultaneous 
>> transmission sets, and so on, makes for a very compact representation 
>> compared to listing all possible permutations of alternative choices 
>> in grouped m-lines.
>>
>> Does such a mechanism make at least initial sense? Should it be 
>> fleshed out and put into the framework?
>>
>> Stephan
>> _______________________________________________
>> clue mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/clue
>
> _\\|//_
> ( O-O )
> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
> Simon Pietro Romano
> Universita' di Napoli Federico II
> Computer Engineering Department
> Phone: [phone] -- Fax: [phone]
> e-mail: [e-mail] <mailto:[e-mail]>
>
> <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli
> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
> oooO
> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
> \ ( ( )
> \_) ) /
> (_/
>
>
>
>
>
>
>
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue