Subject: Re: [clue] Questions on basic message flow in the framework

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Sun, 4 Sep 2011 15:21:06 -0700

Hi Roni,

I agree with Paul's notes on this thread, which say there are many ways
to do things, etc.

However, I had a question just in terms of the framework as it is
currently spec'ed. Your sequence of 4 messages confuses me a bit. The
framework suggests a series of 3 messages -
consumer->provider->consumer->provider.  Maybe your 4 messages are also
meant to include the exchange of information in the opposite direction
when the roles are reversed?? But that would be another 3 messages. So
I'm unclear on the sequence you listed.

Thanks,

Allyn

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: Friday, August 26, 2011 9:37 AM
To: 'Marshall Eubanks'; 'Paul Kyzivat'
Cc: [email-masked]
Subject: Re: [clue] Questions on basic message flow in the framework

Hi,

It is not a three message flow but four as far as I understand in order
to achieve a two way communication.

The caller will send his Consumer capability advertisement (as a
consumer) and an SDP for non CLUE interoperability.

The called party will send Consumer capability advertisement and his
Media Capture Advertisement

The calling party will send Media Capture Advertisement  and can send
Consumer config of provider  streams ( what it wants to receive)

The called party will send Consumer config of provider  streams.

I think we need all these messages but should be aware of what it means.

In the past we thought about having initial communication with partial
streams. And get all streams after the full exchange. Maybe we can have
it as an option that can be part of the offer/answer.

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marshall Eubanks
Sent: Friday, August 26, 2011 6:43 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [clue] Questions on basic message flow in the framework

On Fri, Aug 26, 2011 at 10:13 AM, Paul Kyzivat <[email-masked]>
wrote:

On 8/25/11 3:48 PM, Roni Even wrote:

Hi,
This will mean two stage, the initial SIP exchange will require a valid
SDP
for backward interoperability that will open one video, one video and
CLUE
channels and only afterwards the full telepresence sessions will be
added.
We can say that systems that support CLUE will wait for the exchange in
the
CLUE channel to establish media which is a delay.
If we use multi body in the SIP message, we will still need to discuss
how
to have the three message exchange in an offer answer dialog.

The way we chose will also affect my third question about using the
messages
after the initial media channels are running. This is why I was asking
about
maybe we need mode change messages.

There are many ways to accomplish this.

Is your concern the call setup delay while more messages are exchanged?
Or is it other aspects of user experience, such as establishing one
video stream before the others?

Delay due to extra message exchange can be hidden so that the user
experience isn't diminished (much). E.g. the extra message(s) can be
exchanged while "ringing" (on calling side) and before alerting
commences (on called side).

This needs to be looked at but may be acceptable at call setup, which
always seems to take a few seconds.

I am also worried about changes _during the call_, where a few seconds
delay could be bad.

Here is an example (I am going to try and capture the worries I
expressed in QC, and at the interim).

A session starts, with two endpoints separated by (say) 150 msec one way
. There is 

Consumer capability advertisement |----------------------------->

Media Capture Advertisement       <-----------------------------|

Consumer config of provider       |----------------------------->

streams 

That takes roughly 450 msec + a little, which seems OK.

1.) Won't in practice the provider send a SDP file to the consumer,
which in practice the consumer should receive and parse (if only as an
error check), so won't that add ANOTHER round trip ? So, won't that take
600 msec plus a little, which is less OK ? And, won't that also mean
that,

if there is a 1% packet loss, there will be a (1 - (0.99)^4 =)  4%
chance of a problem with these handshakes ? And won't a drop on any of
these 4 messages mean a considerably longer setup delay ? 

And, then 

2.) Suppose, at some point in the session, there is a network blip and
inbound becomes congested. The provider needs to throttle back. The
consumer detects this, says "I need to advertise less bandwidth," sends
a corresponding CCA via UDP. The provider receives this, and sends a new
MCA.

This gets lost in the congestion. Even if three in a row are sent, they
might all be lost, as the link is congested.

So, then there is a timer set. Tick, tick, tick. The consumer will send
more CCAs (presumably) once the timer times out, but nothing comes back.
The consumer can talk to the provider, but it doesn't know it, and it
isn't allowed to except through

this three way, so the situation never gets resolved. Meanwhile, up at
Layer 8, the company CEO is getting pissed off. (And, in some parallel
universe, IESG ADs are asking questions about congestion control.) Even
a 1 second timer would mean that the time to recover from _one_ control
packet loss could be 1.5 seconds, which is not good. 

This says to me that either

- providers SHOULD include information about adapting to congestion in
the first handshake, so that the consumer can send an appropriate

config message as needed

or 

- consumers  should be able to send a "squelch" message to the provider,
saying "reduce bandwidth to me now," and let the provider puzzle it out.
This could take the form of (say) a not to exceed bandwidth in the
config message; a subsequent config could be the same except for a
lowered  NTE bandwidth. Obviously, in a really severe problem, you might
want to set that to zero.

or both. 

All of this seems fairly fundamental to me, the sort of thing that needs
to be addressed if we are going to use this 3-way handshake. 

Regards

Marshall

	For instance, there could be multiple O/A exchanges, with
preconditions used to delay the alerting. There could then also be
exchanges over a "clue" stream between the first o/a and the last one
resolving the preconditions.
	
	I don't think its necessary to decide on this mechanism yet.
	
	       Thanks
	       Paul

		Roni

		-----Original Message-----
		From: Allyn Romanow (allyn) [mailto:[email-masked]]
		Sent: Thursday, August 25, 2011 10:08 PM
		To: Roni Even; Andrew Pepperell (apeppere);
[email-masked]
		Subject: RE: [clue] Questions on basic message flow in
the framework
		
		One option would be to establish CLUE through SIP, and
then these
		messages are CLUE messages, not SIP messages.

		-----Original Message-----
		From: [email-masked]
[mailto:[email-masked]] On Behalf

		Of

		Roni Even
		Sent: Thursday, August 25, 2011 12:01 PM
		To: Andrew Pepperell (apeppere); [email-masked]
		Subject: Re: [clue] Questions on basic message flow in
the framework
		
		Hi,
		During the initial discussion on this work one of the
issues was if

		we

		are
		talking about one or two stage signaling. As far as I
remember we
		talked
		about one stage signaling, is this still the case or do
we still keep
		it
		open. This was way I asked about the mapping to SIP and
why I think

		we

		need
		to consider it early to verify if the proposed message
flow works

		with

		one
		stage signaling.
		Regards
		Roni

		-----Original Message-----
		From: [email-masked]
[mailto:[email-masked]] On

		Behalf

		Of

		Andy Pepperell
		Sent: Thursday, August 25, 2011 7:47 PM
		To: [email-masked]
		Subject: Re: [clue] Questions on basic message flow in
the

		framework

			Thanks Charles! To follow up:
			
			 >>[Roni]
			 >>  I was looking at the use cases of 3 to 3
and 3 to 1 and tried

		to

			understand what will be conveyed in the three
messages and how will

		we

		use the information.
		 >>  The first question I had was how this relates to
SIP. At which
		stage
		of the SIP call will the consumer advertize its
capabilities?
		 >[Charles]
		 >I think it is best to focus on the framework a bit
more before
		mapping
		to SIP.
		
		Yes, that's been our approach so far...
		
		 >>[Roni]
		 >>  The third question I had was if these three
messages can be
		repeated
		at any time or do we see a different message to request
a mode

		change.

		 >[Charles]
		 >My understanding, based on the presentation in the
virtual

		meeting,

			is
			that these messages, though shown as an ordered
exchange, could
			theoretically come in any order at any time.
			
			While for the purposes of of producing robust
implementations

		messages

		would need to be handled "in any order at any time",
within the

		model

			as
			proposed there are some constraints -
specifically, a media stream
			provider must not send a media capture
advertisement until it's

		seen

		at

		least one consumer capability advertisement, and a
consumer would

		not

			be
			able to send a stream configuration message
until it's seen at

		least

			one
			media capture advertisement from the provider.
			
			Andy

			On 24/08/2011 21:09, Charles Eckel (eckelcu)
wrote:

			Hi Roni,
			
			Please see inline.

			-----Original Message-----
			From: [email-masked]
[mailto:[email-masked]] On

		Behalf

			Of Roni Even

			Sent: Wednesday, August 24, 2011 6:30 AM
			To: [email-masked]
			Subject: [clue] Questions on basic message flow
in the framework
			
			Hi,
			
			In the interim meeting I mentioned that I that I
support the

		model

			but

			think that there are parameters

			that I would like to add. At the meeting it was
clear to me that

			there

			will be a new revision soon

			that will support parameters at the capture
scene level. Trying

		to

			see

			which parameters I would like

			to see supported I looked at the message flow
and I have some

			questions.

			Andy presented the basic message flow with three
messages:

			1.       Consumer capability advertisement
			
			2.       Provider - media capture advertisement
			
			3.       Consumer configuration of provider
streams.

			I was looking at the use cases of 3 to 3 and 3
to 1 and tried to

			understand what will be conveyed in

			the three messages and how will we use the
information.
			
			The first question I had was how this relates to
SIP. At which

		stage

			of the SIP call will the consumer

			advertize its capabilities?

			I think it is best to focus on the framework a
bit more before

		mapping

		to SIP.

		In the second part, I was then looking at a
telepresence system

		that

		has 3 65" screens where the

		distance between the screens including the frames is 6".
The

		system

			has three cameras, each mounted on

			the center of a screen. The system is facing a
room with three

		rows

			each row sits 6 people and each

			camera is capable of capturing a third of the
room but the

		default

				views of each camera does not

				overlap with the others. The cameras
support zoom and pan (local

			from

			the application).

			The system can decode up to four video streams
where one is

			presentation (H.239 like). The system can

			support an internal 4-way multipoint call, means
that it can

		receive

			the three main video streams from

			one, two or three endpoints.
			
			I think that this is a very standard system,
nothing special.
			
			The telepresence application is willing to
provide all this

			information as part of the consumer

			capability advertisement and according to Andy's
slides the

		message

			include physical factors , user

			preferences and software limitations.
			
			I am now trying to understand what the purpose
of the consumer

			capability advertisement is in order to

			see what information is important to convey.
			
			Is the reason for the consumer capability
advertisement to allow

		the

			provider to propose a better

			media capability advertisement, or is it to
allow the provider

		to

				optimize the content of the media

				streams he is sending based on the
information provided. This

		will

				help with looking at which

				parameters can be used. The slides show
that the information is

		used

			for the capability

			advertisements.

			I viewed it as being primarily for the former,
but using it for

		the

				latter may make sense as well and should
not be excluded. The

		extent

		to

		which the provider actually uses the information is

		implementation

				dependent.

				The third question I had was if these
three messages can be

		repeated

			at any time or do we see a

			different message to request a mode change.

			My understanding, based on the presentation in
the virtual

		meeting,

			is

			that these messages, though shown as an ordered
exchange, could
			theoretically come in any order at any time.
			
			Cheers,
			Charles

			Thanks
			
			Roni Even

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

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

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

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

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

---

From: Roni Even <[email-masked]>
Date: Mon, 05 Sep 2011 01:49:35 +0300

Allyn,

This is for a two way communication since this is what we are talking about
in CLUE (not streaming). I assume that a message can include two information
blocks. For example the second message from the called party will include
his consumer capability adv and his media capture adv if the first message
had the calling party consumer capability adv. If this assumption is not
true than we will need more messages to have a two way communication.

Roni

From: Allyn Romanow (allyn) [mailto:[email-masked]] 
Sent: Monday, September 05, 2011 1:21 AM
To: Roni Even; Marshall Eubanks; Paul Kyzivat
Cc: [email-masked]
Subject: RE: [clue] Questions on basic message flow in the framework

Hi Roni,

I agree with Paul's notes on this thread, which say there are many ways to
do things, etc.

However, I had a question just in terms of the framework as it is currently
spec'ed. Your sequence of 4 messages confuses me a bit. The framework
suggests a series of 3 messages - consumer->provider->consumer->provider.
Maybe your 4 messages are also meant to include the exchange of information
in the opposite direction when the roles are reversed?? But that would be
another 3 messages. So I'm unclear on the sequence you listed.

Thanks,

Allyn

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni
Even
Sent: Friday, August 26, 2011 9:37 AM
To: 'Marshall Eubanks'; 'Paul Kyzivat'
Cc: [email-masked]
Subject: Re: [clue] Questions on basic message flow in the framework

Hi,

It is not a three message flow but four as far as I understand in order to
achieve a two way communication.

The caller will send his Consumer capability advertisement (as a consumer)
and an SDP for non CLUE interoperability.

The called party will send Consumer capability advertisement and his Media
Capture Advertisement

In the past we thought about having initial communication with partial
streams. And get all streams after the full exchange. Maybe we can have it
as an option that can be part of the offer/answer.

Roni

 

Hi,
This will mean two stage, the initial SIP exchange will require a valid SDP
for backward interoperability that will open one video, one video and CLUE
channels and only afterwards the full telepresence sessions will be added.
We can say that systems that support CLUE will wait for the exchange in the
CLUE channel to establish media which is a delay.
If we use multi body in the SIP message, we will still need to discuss how
to have the three message exchange in an offer answer dialog.

The way we chose will also affect my third question about using the messages
after the initial media channels are running. This is why I was asking about
maybe we need mode change messages.

Is your concern the call setup delay while more messages are exchanged? Or
is it other aspects of user experience, such as establishing one video
stream before the others?

Delay due to extra message exchange can be hidden so that the user
experience isn't diminished (much). E.g. the extra message(s) can be
exchanged while "ringing" (on calling side) and before alerting commences
(on called side).

This needs to be looked at but may be acceptable at call setup, which always
seems to take a few seconds.

I am also worried about changes _during the call_, where a few seconds delay
could be bad.

Here is an example (I am going to try and capture the worries I expressed in
QC, and at the interim).

A session starts, with two endpoints separated by (say) 150 msec one way .
There is 

streams 

1.) Won't in practice the provider send a SDP file to the consumer, which in
practice the consumer should receive and parse (if only as an error check),
so won't that add ANOTHER round trip ? So, won't that take 600 msec plus a
little, which is less OK ? And, won't that also mean that,

if there is a 1% packet loss, there will be a (1 - (0.99)^4 =)  4% chance of
a problem with these handshakes ? And won't a drop on any of these 4
messages mean a considerably longer setup delay ? 

And, then 

2.) Suppose, at some point in the session, there is a network blip and
inbound becomes congested. The provider needs to throttle back. The consumer
detects this, says "I need to advertise less bandwidth," sends a
corresponding CCA via UDP. The provider receives this, and sends a new MCA.

So, then there is a timer set. Tick, tick, tick. The consumer will send more
CCAs (presumably) once the timer times out, but nothing comes back. The
consumer can talk to the provider, but it doesn't know it, and it isn't
allowed to except through

this three way, so the situation never gets resolved. Meanwhile, up at Layer
8, the company CEO is getting pissed off. (And, in some parallel universe,
IESG ADs are asking questions about congestion control.) Even a 1 second
timer would mean that the time to recover from _one_ control packet loss
could be 1.5 seconds, which is not good. 

- providers SHOULD include information about adapting to congestion in the
first handshake, so that the consumer can send an appropriate

config message as needed

or 

- consumers  should be able to send a "squelch" message to the provider,
saying "reduce bandwidth to me now," and let the provider puzzle it out.
This could take the form of (say) a not to exceed bandwidth in the config
message; a subsequent config could be the same except for a lowered  NTE
bandwidth. Obviously, in a really severe problem, you might want to set that
to zero.

or both. 

All of this seems fairly fundamental to me, the sort of thing that needs to
be addressed if we are going to use this 3-way handshake. 

Regards

Marshall

For instance, there could be multiple O/A exchanges, with preconditions used
to delay the alerting. There could then also be exchanges over a "clue"
stream between the first o/a and the last one resolving the preconditions.

       Thanks
       Paul

Roni

-----Original Message-----
From: Allyn Romanow (allyn) [mailto:[email-masked]]
Sent: Thursday, August 25, 2011 10:08 PM
To: Roni Even; Andrew Pepperell (apeppere); [email-masked]
Subject: RE: [clue] Questions on basic message flow in the framework

One option would be to establish CLUE through SIP, and then these
messages are CLUE messages, not SIP messages.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf

Of

Roni Even

Hi,
During the initial discussion on this work one of the issues was if

we

are
talking about one or two stage signaling. As far as I remember we
talked
about one stage signaling, is this still the case or do we still keep
it
open. This was way I asked about the mapping to SIP and why I think

we

need
to consider it early to verify if the proposed message flow works

with

one
stage signaling.
Regards
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On

Behalf

Of

Andy Pepperell
Sent: Thursday, August 25, 2011 7:47 PM
To: [email-masked]
Subject: Re: [clue] Questions on basic message flow in the

framework

Thanks Charles! To follow up:

 >>[Roni]
 >>  I was looking at the use cases of 3 to 3 and 3 to 1 and tried

to

understand what will be conveyed in the three messages and how will

we

use the information.
 >>  The first question I had was how this relates to SIP. At which
stage
of the SIP call will the consumer advertize its capabilities?
 >[Charles]
 >I think it is best to focus on the framework a bit more before
mapping
to SIP.

 >>[Roni]
 >>  The third question I had was if these three messages can be
repeated
at any time or do we see a different message to request a mode

change.

 >[Charles]
 >My understanding, based on the presentation in the virtual

meeting,

is
that these messages, though shown as an ordered exchange, could
theoretically come in any order at any time.

While for the purposes of of producing robust implementations

messages

would need to be handled "in any order at any time", within the

model

as
proposed there are some constraints - specifically, a media stream
provider must not send a media capture advertisement until it's

seen

at

least one consumer capability advertisement, and a consumer would

not

be
able to send a stream configuration message until it's seen at

least

one

Andy

On 24/08/2011 21:09, Charles Eckel (eckelcu) wrote:

Hi Roni,

Please see inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On

Behalf

Of Roni Even

Sent: Wednesday, August 24, 2011 6:30 AM
To: [email-masked]
Subject: [clue] Questions on basic message flow in the framework

Hi,

In the interim meeting I mentioned that I that I support the

model

but

that I would like to add. At the meeting it was clear to me that

there

that will support parameters at the capture scene level. Trying

to

see

to see supported I looked at the message flow and I have some

questions.

Andy presented the basic message flow with three messages:

3.       Consumer configuration of provider streams.

I was looking at the use cases of 3 to 3 and 3 to 1 and tried to

the three messages and how will we use the information.

The first question I had was how this relates to SIP. At which

stage

I think it is best to focus on the framework a bit more before

mapping

to SIP.

In the second part, I was then looking at a  telepresence system

that

distance between the screens including the frames is 6". The

system

the center of a screen. The system is facing a room with three

rows

camera is capable of capturing a third of the room but the

default

overlap with the others. The cameras support zoom and pan (local

from

the application).

The system can decode up to four video streams where one is

support an internal 4-way multipoint call, means that it can

receive

I think that this is a very standard system, nothing special.

The telepresence application is willing to provide all this

capability advertisement and according to Andy's slides the

message

I am now trying to understand what the purpose of the consumer

Is the reason for the consumer capability advertisement to allow

the

media capability advertisement, or is it to allow the provider

to

streams he is sending based on the information provided. This

will

parameters can be used. The slides show that the information is

used

for the capability

advertisements.

I viewed it as being primarily for the former, but using it for

the

latter may make sense as well and should not be excluded. The

extent

to

implementation

dependent.

The third question I had was if these three messages can be

repeated

My understanding, based on the presentation in the virtual

meeting,

is

that these messages, though shown as an ordered exchange, could
theoretically come in any order at any time.

Cheers,
Charles

Thanks

Roni Even

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 4 Sep 2011 19:06:48 -0400

Allyn, Roni;

On Sun, Sep 4, 2011 at 6:49 PM, Roni Even <[email-masked]> wrote:

> Allyn,****
> true than we will need more messages to have a two way communication.****
>
> **
>

I still think that there is likely to be lower level communications (such as
RTCP or SIP) going on that we may not care too much about in
the CLUE protocols, but which will still add to the setup / convergence
time, and so we need to be aware of.

Regards
Marshall

> **
>
> Roni****
>
> ** **
>
> *From:* Allyn Romanow (allyn) [mailto:[email-masked]]
> *Sent:* Monday, September 05, 2011 1:21 AM
> *To:* Roni Even; Marshall Eubanks; Paul Kyzivat
> *Cc:* [email-masked]
>
> *Subject:* RE: [clue] Questions on basic message flow in the framework****
>
> ** **
>
> Hi Roni,****
>
> ** **
>
> I agree with Paul’s notes on this thread, which say there are many ways to
> do things, etc.****
>
> spec’ed. Your sequence of 4 messages confuses me a bit. The framework
> suggests a series of 3 messages – consumer->provider->consumer->provider.
> another 3 messages. So I’m unclear on the sequence you listed.****
>
> ** **
>
> Thanks,****
>
> Allyn****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Roni Even
> *Sent:* Friday, August 26, 2011 9:37 AM
> *To:* 'Marshall Eubanks'; 'Paul Kyzivat'
> *Cc:* [email-masked]
> *Subject:* Re: [clue] Questions on basic message flow in the framework****
>
> ** **
>
> Hi,****
>
> achieve a two way communication.****
>
> ** **
>
> and an SDP for non CLUE interoperability.****
>
> Capture Advertisement****
>
> Consumer config of provider  streams ( what it wants to receive)****
>
> The called party will send Consumer config of provider  streams.****
>
> ** **
>
> I think we need all these messages but should be aware of what it means.**
> **
>
> as an option that can be part of the offer/answer.****
>
> ** **
>
> Roni****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Marshall Eubanks
> *Sent:* Friday, August 26, 2011 6:43 PM
> *To:* Paul Kyzivat
> *Cc:* [email-masked]
> *Subject:* Re: [clue] Questions on basic message flow in the framework****
>
> ** **
>
> ** **
>
> wrote:****
> On 8/25/11 3:48 PM, Roni Even wrote:****
>
> Hi,
> maybe we need mode change messages.****
>
> ** **
>
> (on called side).****
> ** **
> always seems to take a few seconds.****
>
> ** **
>
> delay could be bad.****
> ** **
> Here is an example (I am going to try and capture the worries I expressed
> in QC, and at the interim).****
>
> ** **
>
> There is ****
> ** **
> Consumer capability advertisement |----------------------------->****
>
> ** **
>
> Media Capture Advertisement       <-----------------------------|****
>
> ** **
>
> Consumer config of provider       |----------------------------->****
>
> streams ****
>
> ** **
>
> That takes roughly 450 msec + a little, which seems OK.****
>
> ** **
>
> 1.) Won't in practice the provider send a SDP file to the consumer, which
> in practice the consumer should receive and parse (if only as an error
> check), so won't that add ANOTHER round trip ? So, won't that take 600 msec
> plus a little, which is less OK ? And, won't that also mean that,****
>
> if there is a 1% packet loss, there will be a (1 - (0.99)^4 =)  4% chance
> of a problem with these handshakes ? And won't a drop on any of these 4
> messages mean a considerably longer setup delay ? ****
>
> ** **
>
> And, then ****
>
> ** **
>
> ****
> ** **
> might all be lost, as the link is congested.****
>
> ** **
>
> more CCAs (presumably) once the timer times out, but nothing comes back. The
> allowed to except through****
>
> universe, IESG ADs are asking questions about congestion control.) Even a 1
> second timer would mean that the time to recover from _one_ control packet
> loss could be 1.5 seconds, which is not good. ****
>
> ** **
>
> This says to me that either****
>
> ** **
>
> first handshake, so that the consumer can send an appropriate****
>
> config message as needed****
>
> ** **
>
> or ****
>
> ** **
>
> to zero.****
> ** **
> or both. ****
> ** **
> be addressed if we are going to use this 3-way handshake. ****
>
> ** **
>
> Regards****
>
> Marshall****
>
> ** **
>
>  ****
>
> For instance, there could be multiple O/A exchanges, with preconditions
> used to delay the alerting. There could then also be exchanges over a "clue"
>        Paul****
> ** **
> Roni****
> messages are CLUE messages, not SIP messages.****
>
> From: [email-masked] [mailto:[email-masked]] On Behalf****
>
> Of****
>
> Roni Even
> During the initial discussion on this work one of the issues was if****
>
> we****
>
> are
> open. This was way I asked about the mapping to SIP and why I think****
>
> we****
>
> need
> to consider it early to verify if the proposed message flow works****
>
> with****
>
> one
> stage signaling.
> Regards
> Roni****
>
> From: [email-masked] [mailto:[email-masked]] On****
>
> Behalf****
>
> Of****
>
> Andy Pepperell
> Subject: Re: [clue] Questions on basic message flow in the****
>
> framework****
>
>
>  >>  I was looking at the use cases of 3 to 3 and 3 to 1 and tried****
>
> to****
>
> understand what will be conveyed in the three messages and how will****
>
> we****
>
> use the information.
> at any time or do we see a different message to request a mode****
>
> change.****
>
>  >[Charles]
>  >My understanding, based on the presentation in the virtual****
>
> meeting,****
>
> is
> While for the purposes of of producing robust implementations****
>
> messages****
>
> would need to be handled "in any order at any time", within the****
>
> model****
>
> as
> provider must not send a media capture advertisement until it's****
>
> seen****
>
> at****
>
> least one consumer capability advertisement, and a consumer would****
>
> not****
>
> be
> able to send a stream configuration message until it's seen at****
>
> least****
>
> one
> On 24/08/2011 21:09, Charles Eckel (eckelcu) wrote:****
>
> Hi Roni,
>
> Please see inline.****
>
> From: [email-masked] [mailto:[email-masked]] On****
>
> Behalf****
>
> Of Roni Even****
>
> In the interim meeting I mentioned that I that I support the****
>
> model****
>
> but****
>
> think that there are parameters****
>
> that I would like to add. At the meeting it was clear to me that****
>
> there****
>
> will be a new revision soon****
>
> that will support parameters at the capture scene level. Trying****
>
> to****
>
> see****
>
> which parameters I would like****
>
> to see supported I looked at the message flow and I have some****
>
> questions.****
>
> I was looking at the use cases of 3 to 3 and 3 to 1 and tried to****
>
> understand what will be conveyed in****
>
> The first question I had was how this relates to SIP. At which****
>
> stage****
>
> of the SIP call will the consumer****
>
> advertize its capabilities?****
>
> I think it is best to focus on the framework a bit more before****
>
> mapping****
>
> to SIP.****
>
> In the second part, I was then looking at a  telepresence system****
>
> that****
>
> has 3 65" screens where the****
>
> distance between the screens including the frames is 6". The****
>
> system****
>
> has three cameras, each mounted on****
>
> the center of a screen. The system is facing a room with three****
>
> rows****
>
> each row sits 6 people and each****
>
> camera is capable of capturing a third of the room but the****
>
> default****
>
> views of each camera does not****
>
> overlap with the others. The cameras support zoom and pan (local****
>
> from****
>
> the application).****
>
> The system can decode up to four video streams where one is****
>
> presentation (H.239 like). The system can****
>
> support an internal 4-way multipoint call, means that it can****
>
> receive****
>
> the three main video streams from****
>
> The telepresence application is willing to provide all this****
>
> information as part of the consumer****
>
> capability advertisement and according to Andy's slides the****
>
> message****
>
> include physical factors , user****
>
> I am now trying to understand what the purpose of the consumer****
>
> capability advertisement is in order to****
>
> Is the reason for the consumer capability advertisement to allow****
>
> the****
>
> provider to propose a better****
>
> media capability advertisement, or is it to allow the provider****
>
> to****
>
> optimize the content of the media****
>
> streams he is sending based on the information provided. This****
>
> will****
>
> help with looking at which****
>
> parameters can be used. The slides show that the information is****
>
> used****
>
> for the capability****
>
> advertisements.****
>
> I viewed it as being primarily for the former, but using it for****
>
> the****
>
> latter may make sense as well and should not be excluded. The****
>
> extent****
>
> to****
>
> which the provider actually uses the information is****
>
> implementation****
>
> dependent.****
>
>
>
> The third question I had was if these three messages can be****
>
> repeated****
>
> at any time or do we see a****
>
> different message to request a mode change.****
>
> My understanding, based on the presentation in the virtual****
>
> meeting,****
>
> is****
>
> Charles****
> Roni Even****
> https://www.ietf.org/mailman/listinfo/clue****
>
>
> https://www.ietf.org/mailman/listinfo/clue****
>
>
> https://www.ietf.org/mailman/listinfo/clue****
>
>
> https://www.ietf.org/mailman/listinfo/clue****
>
>
> https://www.ietf.org/mailman/listinfo/clue****
>
> ** **
>