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

From: Stephan Wenger <[email-masked]>
Date: Sat, 1 Dec 2012 16:56:19 +0000

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

---

From: Simon Pietro Romano <[email-masked]>
Date: Sat, 1 Dec 2012 18:59:07 +0100

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:

> Invite from Alice, just like A.1 in call-flow-02
> 200 OK from Bob, A.2
> CLUE Advertisement Alice A.3, covering geometry stuff, encoding groups, etc.
> CLUE Advertisement Bob A.4; note that 3 and 4 would in practice overlap in time
> 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
> CLUE Response from Bob, A.6, same remark.. 5 and 6 could overlap in time.
> Re-invite from Alice and Bob, respectively, with media channels as CLUE-"negotiated"
> 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.
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 1 Dec 2012 18:06:00 +0000

Yes, this is what we thought as a reasonable starting point for a discussion.
S.

From: Simon Pietro Romano <[email-masked]<mailto:[email-masked]>>
Date: Saturday, 1 December, 2012 09:59
To: Stephan Wenger <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [clue] Subject matter for Monday's call

Hi Stephan,

Cheers,

Simon

Hi all,

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

                            _\\|//_
                                 ( O-O )
                                           e-mail: [email-masked]<mailto:[email-masked]>

---

From: Ron Even <[email-masked]>
Date: Sun, 2 Dec 2012 19:39:58 +0200

Hi,
The general flow is ok and the new point here is that after the advertise
config there will always be a new offer answer that will establish the
media and can be used for defining the SSRCs of all streams. This is
important for static mapping and will also be used to support simulcast
which is not supported in CLUE.
I also assume that step 1 and 2 will include m-lines for allowing initial
audio and video this will allow ICE negotiation and having audio and video
early in the process. This is required also for interoperability with non
CLUE systems
As for step 3 and 4 overlap, this may not always be the case, example is an
endpoint calling to the MCU who may want to see the advertisement first.

Roni

On Saturday, December 1, 2012, Stephan Wenger wrote:

>  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:
>
>    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
>    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.
>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 2 Dec 2012 18:29:11 +0000

Hi,

>The general flow is ok and the new point here is that after the advertise config there will always be a new offer answer that will establish the media and can be used for defining the
> SSRCs of all streams. This is important for static mapping and will also be used to support simulcast which is not supported in CLUE.
> I also assume that step 1 and 2 will include m-lines for allowing initial audio and video this will allow ICE negotiation and having audio and video early in the process. This is required also for interoperability with non CLUE systems

I guess step 1 and 2 are related to the discussion in the "Scene for non-CLUE/single stream devices" thread.

Regards,

Christer

Stephan

---

From: Stephan Wenger <[email-masked]>
Date: Sun, 2 Dec 2012 18:35:34 +0000

On 12.2.2012 10:29 , "Christer Holmberg" <[email-masked]>
wrote:

>
>Hi,
>
>>The general flow is ok and the new point here is that after the
>>advertise config there will always be a new offer answer that will
>>establish the media and can be used for defining the
>> SSRCs of all streams. This is important for static mapping and will
>>also be used to support simulcast which is not supported in CLUE.
>> I also assume that step 1 and 2 will include m-lines for allowing
>>initial audio and video this will allow ICE negotiation and having audio
>>and video early in the process. This is required also for
>>interoperability with non CLUE systems
>

Yes, in the sense that if the negotiation of the CLUE channel fails, then
all you have to work with is the non-CLUE aspects of the OA exchange.

Please see also my reply to Roni's email.

Stephan

>SDP-represented, SIP-ish, Offer-Answer, Š, that type of traditional
>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_te
>xt=1) that exchange could look as follows:
>
>reposes DO NOT have the side effect of initiating any media channel
>related activity; they are pure signaling
>entity not involved in the CLUE negotiation intervenes‹i.e. a middle box
>doesn't like that call.
>
>representation compared to listing all possible permutations of
>alternative choices in grouped m-lines.
>

---

From: Stephan Wenger <[email-masked]>
Date: Sun, 2 Dec 2012 18:45:27 +0000

Hi Roni,
Inline.
S.

From: Ron Even <[email-masked]<mailto:[email-masked]>>
Date: Sunday, 2 December, 2012 09:39
To: Stephan Wenger <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [clue] Subject matter for Monday's call

Hi,
The general flow is ok and the new point here is that after the advertise config there will always be a new offer answer that will establish the media and can be used for defining the SSRCs of all streams. This is important for static mapping and will also be used to support simulcast which is not supported in CLUE.
I also assume that step 1 and 2 will include m-lines for allowing initial audio and video this will allow ICE negotiation and having audio and video early in the process. This is required also for interoperability with non CLUE systems

SW: yes and no. As you wrote, steps 1 and 2 can negotiate media using m-lines for initial media for fast startup, legacy support, and similar purposes.  However, the use of those I consider an optimization that CLUEful systems may or may not implement.  In other words, I think it MUST be possible that only a CLUE channel is established early, but the CLUEful systems reject the initial media channels.  In this case, all the ICE for the "real" media channels is being done in those new steps 7 and 8.  (the likelihood of success for dealing with ICE at that stage rather than early on appears to me to be the same—we are just talking about timing here))  Also, it MUST be possible that , after the CLUE negotiation is done, the initial channels be torn down in favor of those new channels, for example in such cases where certain codecs is only made available to CLUEful applications and not elsewhere, and the originally negotiated channels not using those codecs would be redundant.  It MAY be possible to "overload" the negotiated channels with the new media as negotiated in CLUE, but again, that is an optimization problem.

As for step 3 and 4 overlap, this may not always be the case, example is an endpoint calling to the MCU who may want to see the advertisement first.

True.

Roni

Stephan

---

From: Christian Groves <[email-masked]>
Date: Mon, 03 Dec 2012 15:18:44 +1100

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:
> From: Simon Pietro Romano <[email-masked] <mailto:[email-masked]>>
> To: Stephan Wenger <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> 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.
> 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.
>
>> 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.
>>
>> 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.
>>
>> (https://datatracker.ietf.org/doc/draft-romanow-clue-call-flow/?include_text=1) 
>>     reposes DO NOT have the side effect of initiating any media
>>     channel related activity; they are pure signaling
>>     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.
>>
>> 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 
>> 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.
>>
>> [email-masked] <mailto:[email-masked]>
> e-mail: [email-masked] <mailto:[email-masked]>
>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 4 Dec 2012 11:26:04 -0600

Hi all,

Per the meeting notes that were just posted, this proposal and
concepts will be incorporated into the WG framework document.   So, we
will revisit this topic in the context of the framework document
updates which will hopefully be out within the next couple weeks.

Regards,
Mary
CLUE WG co-chair

On Sat, Dec 1, 2012 at 10:56 AM, Stephan Wenger <[email-masked]> wrote:
> 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.
>
> 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
> 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.
>
> 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.
>
> quite possibly well beyond a reasonable size (i.e. MTU size); the high level
> of abstraction offered by concepts such as encoding groups, simultaneous
> compared to listing all possible permutations of alternative choices in
> grouped m-lines.
>