Subject: [clue] legacy support in requirements

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Wed, 11 May 2011 18:20:29 -0700

Hi, 

You both asked to add a requirement for legacy support. However, the
charter says

"Interoperation with SIP and related standards for audio and video is
required. However, backwards compatibility with existing
non-standards compliant telepresence systems is not required."

On the basis of this, I think it would not be a good requirement to add.
However, there is a requirement, 10, that addresses making it possible
for endpoints with varying capabilities to interoperate in a
telepresence conference.

Regards,

Allyn

---

From: <[email-masked]>
Date: Thu, 12 May 2011 08:49:56 +0200

Hi,

>From previous discussions on the mailing list and at IETF#80 I understood that « non-standards compliant » was referring to solutions that make use of proprietary extensions (e.g. proprietary extensions to SDP or RTCP) while "legacy support" was referring to standard compliant solutions that do not understand the extensions that CLUE will specify (or request other groups to specify). The charter does not exclude the second case and Req# 10 is not specific enough.  From the current text, one could understand that Req#10 applies to clue-compliant devices (i.e. devices that understand clue-defined extensions) with different capabilities, not to devices that do not understand clue extensions...

BC

De : [email-masked] [mailto:[email-masked]] De la part de Allyn Romanow (allyn)
Envoyé : jeudi 12 mai 2011 03:20
À : CAZEAUX Stephane RD-BIZZ-CAE; Roni Even
Cc : CLUE
Objet : [clue] legacy support in requirements

Hi, 

You both asked to add a requirement for legacy support. However, the charter says

"Interoperation with SIP and related standards for audio and video is required. However, backwards compatibility with existing
non-standards compliant telepresence systems is not required."

On the basis of this, I think it would not be a good requirement to add. However, there is a requirement, 10, that addresses making it possible for endpoints with varying capabilities to interoperate in a telepresence conference.

Regards,

Allyn

---

From: Roni Even <[email-masked]>
Date: Thu, 12 May 2011 10:33:19 +0300

Hi,

I have the same view. 

It is important to address the issue where a system with CLUE extension will
try to interoperate with a system that is SIP compliant but do not support
the CLUE extensions.

Roni

From: [email-masked]
[mailto:[email-masked]] 
Sent: Thursday, May 12, 2011 9:50 AM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [clue] legacy support in requirements

Hi,

>From previous discussions on the mailing list and at IETF#80 I understood
that « non-standards compliant » was referring to solutions that make use of
proprietary extensions (e.g. proprietary extensions to SDP or RTCP) while
“legacy support” was referring to standard compliant solutions that do not
understand the extensions that CLUE will specify (or request other groups to
specify). The charter does not exclude the second case and Req# 10 is not
specific enough.  From the current text, one could understand that Req#10
applies to clue-compliant devices (i.e. devices that understand clue-defined
extensions) with different capabilities, not to devices that do not
understand clue extensions...

BC

De : [email-masked] [mailto:[email-masked]] De la part de
Allyn Romanow (allyn)
Envoyé : jeudi 12 mai 2011 03:20
À : CAZEAUX Stephane RD-BIZZ-CAE; Roni Even
Cc : CLUE
Objet : [clue] legacy support in requirements

Hi, 

You both asked to add a requirement for legacy support. However, the charter
says

“Interoperation with SIP and related standards for audio and video is
required. However, backwards compatibility with existing
non-standards compliant telepresence systems is not required.”

On the basis of this, I think it would not be a good requirement to add.
However, there is a requirement, 10, that addresses making it possible for
endpoints with varying capabilities to interoperate in a telepresence
conference.

Regards,

Allyn

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 12 May 2011 10:01:36 +0200

+1

John 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: 12 May 2011 07:50
> Subject: Re: [clue] legacy support in requirements
> 
> Hi,
> 
> From previous discussions on the mailing list and at IETF#80 
> I understood that « non-standards compliant » was referring 
> to solutions that make use of proprietary extensions (e.g. 
> proprietary extensions to SDP or RTCP) while "legacy support" 
> was referring to standard compliant solutions that do not 
> understand the extensions that CLUE will specify (or request 
> other groups to specify). The charter does not exclude the 
> second case and Req# 10 is not specific enough.  From the 
> current text, one could understand that Req#10 applies to 
> clue-compliant devices (i.e. devices that understand 
> clue-defined extensions) with different capabilities, not to 
> devices that do not understand clue extensions...
> 
> BC
> 
>  
> 
> "Interoperation with SIP and related standards for audio and 
> video is required. However, backwards compatibility with existing
> On the basis of this, I think it would not be a good 
> requirement to add. However, there is a requirement, 10, that 
> addresses making it possible for endpoints with varying 
> capabilities to interoperate in a telepresence conference.
> 
>  
> 
> Regards,
> 
> Allyn
> 
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 12 May 2011 09:16:53 -0700

+1

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: Thursday, May 12, 2011 1:02 AM
> To: [email-masked]; Allyn Romanow (allyn); [email-masked];
> [email-masked]
> Cc: [email-masked]
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Mon, 16 May 2011 11:54:18 -0700

HI Bruno and other folks interested in saying something about legacy in the requirements doc-

Thanks for pointing out  the distinction  between proprietary extensions versus standard SIP compliant solutions. Also, I agree with you that Req #10 is aimed at CLUEful players, not devices that do not understand CLUE.

Could you be a bit more specific about what you feel  should be included in "legacy support"?

Roni suggested,

I am also missing a requirement for "legacy" system support like the solution MUST enable a system that does not support the mechanism to select the best set of streams to render (audio + video).

I don't quite get this in that a system that doesn't support the CLUE mechanism cannot select streams, that's the issue. I would assume that the interaction between a non-CLUE and a CLUE system would be the same as between 2 non-CLUE systems - they don't interwork, but CLUE shouldn't make the situation any worse.

It would be great if you could suggest some wording that you would like to have added.

Thanks,

Allyn

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, May 11, 2011 11:50 PM
To: Allyn Romanow (allyn); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [clue] legacy support in requirements

Hi,

BC

Hi, 

Regards,

Allyn

---

From: Roni Even <[email-masked]>
Date: Tue, 17 May 2011 09:24:22 +0300

Hi Allyn,

When the offer includes parameters that the answerer does not understand
there are two options, he can ignore the unknown parameters or reject the
offer. If the answerer ignores the SDP parameters that he does not
understand the remaining parameters should allow him to establish a media
connection that will use the media stream that the offerer wants to be used
in this case. One example is using potential configurations as specified in
the MMUSIC media capability negotiation draft.

Roni

From: Allyn Romanow (allyn) [mailto:[email-masked]] 
Sent: Monday, May 16, 2011 9:54 PM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [clue] legacy support in requirements

HI Bruno and other folks interested in saying something about legacy in the
requirements doc-

Thanks for pointing out  the distinction  between proprietary extensions
versus standard SIP compliant solutions. Also, I agree with you that Req #10
is aimed at CLUEful players, not devices that do not understand CLUE.

Could you be a bit more specific about what you feel  should be included in
“legacy support”?

Roni suggested,

I am also missing a requirement for "legacy" system support like the
solution MUST enable a system that does not support the mechanism to select
the best set of streams to render (audio + video).

I don’t quite get this in that a system that doesn’t support the CLUE
mechanism cannot select streams, that’s the issue. I would assume that the
interaction between a non-CLUE and a CLUE system would be the same as
between 2 non-CLUE systems – they don’t interwork, but CLUE shouldn’t make
the situation any worse.

It would be great if you could suggest some wording that you would like to
have added.

Thanks,

Allyn

To: Allyn Romanow (allyn); [email-masked];

Hi,

BC

Hi, 

Regards,

Allyn

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 17 May 2011 08:34:03 +0200

I would suggest a simple extension of REQ-10 as follows:

OLD:
   REQMT-10:  The solution MUST include a mechanism that makes it
              possible for endpoints with different capabilities to
              interoperate in a telepresence conference.
NEW:
   REQMT-10:  The solution MUST include a mechanism that makes it
              possible for endpoints with different capabilities to
              interoperate in a telepresence conference, including audio/video endpoints that do not support any telepresence extensions.

John

> Behalf Of Allyn Romanow (allyn)
> Sent: 16 May 2011 19:54
> To: [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Thanks for pointing out  the distinction  between proprietary 
> extensions versus standard SIP compliant solutions. Also, I 
> agree with you that Req #10 is aimed at CLUEful players, not 
> devices that do not understand CLUE.
> 
>  
> 
> I am also missing a requirement for "legacy" system support 
> like the solution MUST enable a system that does not support 
> the mechanism to select the best set of streams to render 
> (audio + video).
> 
>  
> 
> I don't quite get this in that a system that doesn't support 
> the CLUE mechanism cannot select streams, that's the issue. I 
> would assume that the interaction between a non-CLUE and a 
> CLUE system would be the same as between 2 non-CLUE systems - 
> they don't interwork, but CLUE shouldn't make the situation any worse.
> 
>  
> 
> To: Allyn Romanow (allyn); 
> [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Tue, 17 May 2011 09:12:54 +0200

Same view

De : Roni Even [mailto:[email-masked]] 
Envoyé : mardi 17 mai 2011 08:24
À : 'Allyn Romanow (allyn)'; CHATRAS Bruno RD-CORE-ISS; CAZEAUX Stephane RD-BIZZ-CAE
Cc : [email-masked]
Objet : RE: [clue] legacy support in requirements

Hi Allyn,

When the offer includes parameters that the answerer does not understand there are two options, he can ignore the unknown parameters or reject the offer. If the answerer ignores the SDP parameters that he does not understand the remaining parameters should allow him to establish a media connection that will use the media stream that the offerer wants to be used in this case. One example is using potential configurations as specified in the MMUSIC media capability negotiation draft.

Roni

From: Allyn Romanow (allyn) [mailto:[email-masked]] 
Sent: Monday, May 16, 2011 9:54 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [clue] legacy support in requirements

Roni suggested,

 

Thanks,

Allyn

Hi,

BC

Hi, 

Regards,

Allyn

---

From: <[email-masked]>
Date: Tue, 17 May 2011 09:16:09 +0200

We don't have to be explicit about the type of media (audio/video)... just write "including endpoints that..." or "including those that..."

> -----Message d'origine-----
> De : Elwell, John [mailto:[email-masked]]
> Envoyé : mardi 17 mai 2011 08:34
> À : Allyn Romanow (allyn); CHATRAS Bruno RD-CORE-ISS; CAZEAUX Stephane
> RD-BIZZ-CAE; [email-masked]
> Cc : [email-masked]
>               interoperate in a telepresence conference, including
> audio/video endpoints that do not support any telepresence extensions.
> 
> 
> John
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 17 May 2011 10:46:10 +0200

Yes, that would be OK too.

John 

> Sent: 17 May 2011 08:16
> To: Elwell, John; [email-masked]; 
> We don't have to be explicit about the type of media 
> (audio/video)... just write "including endpoints that..." or 
> "including those that..."
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 May 2011 09:55:43 -0400

On 5/17/2011 2:24 AM, Roni Even wrote:
> there are two options, he can ignore the unknown parameters or reject
> the offer.

Rejecting the offer in that case is not really kosher.
You are required to ignore parameters you do not understand.

If you reject something because you don't like the parameters it 
contains, then that is an implicit statement that you understand those 
parameters well enough to decide to reject them.

	Thanks,
	Paul

> If the answerer ignores the SDP parameters that he does not
> understand the remaining parameters should allow him to establish a
> media connection that will use the media stream that the offerer wants
> to be used in this case. One example is using potential configurations
> as specified in the MMUSIC media capability negotiation draft.
>
> Roni
>
> *From:*Allyn Romanow (allyn) [mailto:[email-masked]]
> *Sent:* Monday, May 16, 2011 9:54 PM
> *To:* [email-masked];
> *Cc:* [email-masked]
> *Subject:* RE: [clue] legacy support in requirements
>
> versus standard SIP compliant solutions. Also, I agree with you that Req
> #10 is aimed at CLUEful players, not devices that do not understand CLUE.
>
> Could you be a bit more specific about what you feel should be included
> in “legacy support”?
>
> Roni suggested,
>
> solution MUST enable a system that does not support the mechanism to
> select the best set of streams to render (audio + video).
>
> mechanism cannot select streams, that’s the issue. I would assume that
> the interaction between a non-CLUE and a CLUE system would be the same
> as between 2 non-CLUE systems – they don’t interwork, but CLUE shouldn’t
> make the situation any worse.
>
> *From:[email-masked]
> *Sent:* Wednesday, May 11, 2011 11:50 PM
> *To:* Allyn Romanow (allyn); [email-masked];
> [email-masked]
> *Cc:* [email-masked]
> *Subject:* RE: [clue] legacy support in requirements
>
> Hi,
>
>  From previous discussions on the mailing list and at IETF#80 I
> understood that « non-standards compliant » was referring to solutions
> that make use of proprietary extensions (e.g. proprietary extensions to
> SDP or RTCP) while “legacy support” was referring to standard compliant
> solutions that do not understand the extensions that CLUE will specify
> (or request other groups to specify). The charter does not exclude the
> second case and Req# 10 is not specific enough. From the current text,
> one could understand that Req#10 applies to clue-compliant devices (i.e.
> devices that understand clue-defined extensions) with different
> capabilities, not to devices that do not understand clue extensions...
>
> BC
>
> *De :[email-masked] [mailto:[email-masked]] *De la part
> de* Allyn Romanow (allyn)
> *Envoyé :* jeudi 12 mai 2011 03:20
> *À :* CAZEAUX Stephane RD-BIZZ-CAE; Roni Even
> *Cc :* CLUE
> *Objet :* [clue] legacy support in requirements
>
> Hi,
>

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Tue, 17 May 2011 09:16:08 -0500

Paul,

Sometimes protocols allow parameters to be marked mandatory, such that if you don't know them, you reject the transaction.

If marked option, then yeah, toss them and move on.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat (pkyzivat)
Sent: Tuesday, May 17, 2011 9:56 AM
To: [email-masked]
Subject: Re: [clue] legacy support in requirements

	Thanks,
	Paul

> in "legacy support"?
> I don't quite get this in that a system that doesn't support the CLUE
> mechanism cannot select streams, that's the issue. I would assume that
> as between 2 non-CLUE systems - they don't interwork, but CLUE shouldn't
> SDP or RTCP) while "legacy support" was referring to standard compliant

---

From: Stephen Botzko <[email-masked]>
Date: Tue, 17 May 2011 10:34:55 -0400

On Tue, May 17, 2011 at 9:55 AM, Paul Kyzivat <[email-masked]> wrote:

> If you reject something because you don't like the parameters it contains,
> then that is an implicit statement that you understand those parameters well
> enough to decide to reject them.
>

As far as I know, you are always free to reject offers, and it doesn't
really imply anything when you do that..  Whether it is wise is perhaps a
different question.
Stephen Botzko

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 May 2011 11:11:27 -0400

>     contains, then that is an implicit statement that you understand
>     those parameters well enough to decide to reject them.
>
> really imply anything when you do that..  Whether it is wise is perhaps
> a different question.
> Stephen Botzko

Certainly you are always free to reject an offer.
In general I don't know for certain the reason why, and so if I give you 
the benefit of the doubt I will assume you have a valid reason - perhaps 
just policy.

But if the reason you reject the offer is based on your violating a 
spec, then you are non-conforming, whether I can determine you are 
non-conforming or not. Whether being non-conforming is just un-wise, or 
something stronger, is a separate discussion. The IETF does not levy any 
penalties for violating its specs. But sometimes the market does. (And 
sometimes not.) But we don't need to endorse non-conforming behavior in 
our documents.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 May 2011 11:18:05 -0400

In my response below I made an assumption that "unknown parameters" was 
actually talking about "unknown a-lines".

In the case of unknown parameters within other sorts of lines, or even 
unknown parameters *within* a particular a-line that is otherwise known, 
the situation may be different. In such cases, what to do needs to be 
specified as part of the definition of that particular kind of line.

	Thanks,
	Paul

---

From: Roni Even <[email-masked]>
Date: Wed, 18 May 2011 00:20:51 +0300

Paul,
Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for example 
Roni

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Tuesday, May 17, 2011 6:11 PM
> To: Stephen Botzko
> Cc: [email-masked]
> >         there are two options, he can ignore the unknown parameters
> or
> >         reject
> >         the offer.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 May 2011 17:37:14 -0400

> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for example

OK, I looked. It is consistent with what I said.
Either a=group: is understood, or not. If not, its ignored, and not put 
in the answer. Same with a=mid:

If a=group: *is* understood, but some parameter within it is not, there 
are explicit rules for what to do.

AFAICT there are no examples in this document where failure to 
understand an a-line in total (or even in part) results in rejecting the 
offer.

	Thanks,
	Paul

---

From: Roni Even <[email-masked]>
Date: Wed, 18 May 2011 01:05:37 +0300

Paul,
I think we read it differently.
If the answerer does not support the group attribute and the offer had the
fid semantics it may look to the answerer as an offer with multiple m-lines
of the same media tyoe. In this case an implementation might also decide to
refuse the request (e.g., 488 Not Acceptable Here, or 606 Not Acceptable),
because it contains several "m" lines of the same media type.
This is very relevant to the multiple streams case and we should look if we
state this behavior or we will look at providing an approach that will allow
the answerer to choose one m-line that the offerer prefers even of it does
not understand CLUE.

Roni

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, May 18, 2011 12:37 AM
> To: Roni Even
> Cc: 'Stephen Botzko'; [email-masked]
> >>>          When the offer includes parameters that the answerer does
> not
> >>>          understand

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Tue, 17 May 2011 15:39:13 -0700

I thought that we had agreed during the interim, and in meetings and
conversations before the interim, that the requirements is not about
particular protocols that may or may not be use to implement the
solution.

At first I thought you meant "offerer" "answerer" in some generic sense,
but it looks like you mean more specifically to SDP.
AFAIK, we aren't talking in the requirements about SDP in particular.

Thanks,
Allyn

> Roni Even
> Sent: Tuesday, May 17, 2011 3:06 PM
> To: Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
> Behalf
> > Of
> > >>>      If you reject something because you don't like the
> parameters
> > it
> > >> In general I don't know for certain the reason why, and so if I
> give
> > >> you
> > >> non-conforming or not. Whether being non-conforming is just un-
> wise,
> > or
> > >> something stronger, is a separate discussion. The IETF does not
> levy
> > >> any
> > >> sometimes not.) But we don't need to endorse non-conforming
> behavior
> > in
> > >> our documents.
> > >>
> > >> 	Thanks,
> > >> 	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 May 2011 19:44:37 -0400

> because it contains several "m" lines of the same media type.

That is a slightly different story.

Then the reason for rejection is not because it saw an attribute it 
didn't understand - its because it didn't like something it *did* 
understand.

> the answerer to choose one m-line that the offerer prefers even of it does

IMO (lets see if others differ), if a UA receives an offer with at least 
one m-line it is happy with, then it should not reject the call because 
there are others that it does not "understand".

Here "understand" means something different - presumably it does 
understand the direct meaning of the additional m-line, it just doesn't 
understand the *significance* or use of it.

I see little difference to getting to audio m-lines and only wanting 
one, and getting one audio and one video and only supporting audio. In 
general you should not reject an audio/video call just because you only 
support audio.

I think it will behoove clue to strongly recommend that the m-lines in 
an offer be arranged so the first ones are the ones it most wants used 
if not all are.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 May 2011 19:48:16 -0400

> AFAIK, we aren't talking in the requirements about SDP in particular.

Its hard to talk about interoperation with vanilla sip devices without 
saying *something* about how offer/answer will play into it.

I realize something other than SDP may be used for negotiating the 
clue-specific goodies, but at the end of the day there will need to be 
an INVITE and an SDP offer/answer exchange.

(Unless you want to propose reviving SDPng :-)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 May 2011 07:54:56 +0200

Hi,

I agree with Paul.

However, we need to remember that, using feature tags, the OPTIONS method etc, it is possible to figure out what capabilities entities support, before sending SDP offers etc to them.

Regards,

Christer

> Behalf Of Paul Kyzivat
> Sent: 18. toukokuuta 2011 2:45
> To: Roni Even
> Cc: [email-masked]
> > If the answerer does not support the group attribute and 
> the offer had 
> > the fid semantics it may look to the answerer as an offer with 
> > multiple m-lines of the same media tyoe. In this case an 
> > implementation might also decide to refuse the request 
> (e.g., 488 Not 
> > Acceptable Here, or 606 Not Acceptable), because it 
> contains several "m" lines of the same media type.
> 
> Then the reason for rejection is not because it saw an 
> attribute it didn't understand - its because it didn't like 
> something it *did* understand.
> 
> > This is very relevant to the multiple streams case and we 
> should look 
> > if we state this behavior or we will look at providing an approach 
> > that will allow the answerer to choose one m-line that the offerer 
> > prefers even of it does not understand CLUE.
> 
> IMO (lets see if others differ), if a UA receives an offer 
> with at least one m-line it is happy with, then it should not 
> reject the call because there are others that it does not 
> "understand".
> 
> Here "understand" means something different - presumably it 
> does understand the direct meaning of the additional m-line, 
> it just doesn't understand the *significance* or use of it.
> 
> I see little difference to getting to audio m-lines and only 
> wanting one, and getting one audio and one video and only 
> supporting audio. In general you should not reject an 
> audio/video call just because you only support audio.
> 
> I think it will behoove clue to strongly recommend that the 
> m-lines in an offer be arranged so the first ones are the 
> ones it most wants used if not all are.
> 
> 	Thanks,
> 	Paul
> 
> > Roni
> >
> >> Either a=group: is understood, or not. If not, its 
> ignored, and not 
> >> put in the answer. Same with a=mid:
> >>
> >> If a=group: *is* understood, but some parameter within it is not, 
> >> there are explicit rules for what to do.
> >>
> >> understand an a-line in total (or even in part) results in 
> rejecting 
> >> the offer.
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >>>> give you the benefit of the doubt I will assume you have a valid 
> >>>> reason - perhaps just policy.
> >>>>
> >>>> non-conforming or not. Whether being non-conforming is just 
> >>>> un-wise,
> >> or
> >>>> levy any penalties for violating its specs. But sometimes the 
> >>>> market does.
> >> (And

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 18 May 2011 08:25:50 +0200

I agree with Paul's interpretation.

John 

> Sent: 18 May 2011 00:45
> the offer had the
> should look if we
> with at least 
> m-lines in 
> ignored, and not put
> >> the
> >>>> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> >> Of
> >>>> Paul Kyzivat
> >>>>>       If you reject something because you don't like 
> the parameters
> >> it
> >>>> In general I don't know for certain the reason why, and 
> so if I give
> >>>> you
> >>>> non-conforming or not. Whether being non-conforming is 
> just un-wise,
> >> or
> >>>> something stronger, is a separate discussion. The IETF 
> does not levy
> >>>> any
> >>>> sometimes not.) But we don't need to endorse 
> non-conforming behavior
> >> in
> >>>> our documents.
> >>>>
> >>>> 	Thanks,
> >>>> 	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 May 2011 08:36:56 -0400

> However, we need to remember that, using feature tags, the OPTIONS method etc, it is possible to figure out what capabilities entities support, before sending SDP offers etc to them.

That can work in some cases, but its difficult to use in general.
Forking or otherwise routing calls to different UAs can make it 
problematic to poll a device before calling it. And it can just be 
inconvenient to the point that callers won't want to do it.

IMO one should strive to arrange so that the call works the first time, 
with possibly some negotiation after to reach the most optimal 
configuration of that call.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 May 2011 14:50:42 +0200

Hi, 

>>>I agree with Paul.
>>>
>>>However, we need to remember that, using feature tags, the 
>>>OPTIONS method etc, it is possible to figure out what 
>>>capabilities entities support, before sending SDP offers etc to them.
>> 

>Forking or otherwise routing calls to different UAs can make 
>it problematic to poll a device before calling it.

I have presented a solution to handle forking and routing calls to different UAs :)

>And it can just be inconvenient to the point that callers won't want to do it.

Sure. But, in scenarios with intermediaries they can also take care of it.

>IMO one should strive to arrange so that the call works the 
>first time, with possibly some negotiation after to reach the 
>most optimal configuration of that call.

I agree. I do have a feeling it may not work, though. Because, it's not only about the number of m- lines etc, it is also about usage of multiplexing etc WITHIN an m- line.

Regards,

Christer

> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of Paul Kyzivat
> attribute it 
> >> IMO (lets see if others differ), if a UA receives an offer with at 
> >> least one m-line it is happy with, then it should not 
> reject the call 
> >> because there are others that it does not "understand".
> >>
> >> understand the direct meaning of the additional m-line, it just 
> >> doesn't understand the *significance* or use of it.
> >>
> >> one, and getting one audio and one video and only 
> supporting audio. 
> >> In general you should not reject an audio/video call just 
> because you 
> >> only support audio.
> >>
> >> I think it will behoove clue to strongly recommend that 
> the m-lines 
> >> in an offer be arranged so the first ones are the ones it 
> most wants 
> >> used if not all are.
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >>> Roni
> >>>
> >>>>>>>            When the offer includes parameters that 
> the answerer 
> >>>>>>> does
> >>>> not
> >>>>>>>            understand
> >>>>>>> really imply anything when you do that..  Whether it 
> is wise is
> >>>>>> perhaps
> >>>>>>> a different question.
> >>>>>>> Stephen Botzko
> >>>>>>
> does not

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Wed, 18 May 2011 08:41:05 -0500

Paul,

I would agree that if the offer-answer model semantic is that here are
several options and any subset of options is acceptable.

However, if there is any grouping involved such that you need to have a
video and audio feed integrated to make sense then watch out.

For example, I wouldn't want to end up with the result of a man's video
paired with a woman's voice.  That could be rather comical.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat (pkyzivat)
Sent: Tuesday, May 17, 2011 7:45 PM
To: Roni Even
Cc: [email-masked]
Subject: Re: [clue] legacy support in requirements

	Thanks,
	Paul

>> If a=group: *is* understood, but some parameter within it is not,
there
Behalf
parameters
give
un-wise,
levy
behavior

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 May 2011 13:08:30 -0400

> paired with a woman's voice.  That could be rather comical.

Well, SDP defines that you should ignore what you don't understand and 
operate on what is left.

So someone constructing an SDP with grouping issues such as you define 
ought to keep in mind that this could happen, and set things up so that 
something reasonable happens. You can't expect the dumb legacy device to 
figure out much.

For your example, the result may be far from ideal, but it still is 
likely to be better than no call at all. And if not, there is always the 
option of hanging up. But better, presumably the offer could have been 
constructed in a way that produced a better result.

	Thanks,
	Paul

---

From: Roni Even <[email-masked]>
Date: Wed, 18 May 2011 21:13:21 +0300

Hi,
I think this is a good example. 
It is very easy to select between two different media types, like accept
audio and reject video like Paul gives as an example. Once you have two or
more media lines with the same media type like multiple video line you can
hope that the first video line will be used by an endpoint that do not
support multiple video lines but I am not aware that this behavior is
defined in any document.
In the case of grouping once you ignore the grouping lines you are left with
a list of m-lines and I think this is why RFC 5888 say that other things may
happen.

Anyhow we are discussing solution while my point is that we will need as a
requirement to address the case of a call from a CLUE aware endpoint to a
non CLUE aware endpoint. Even if the consensus will be to have the preferred
video in the first video m-line.

Regards
Roni

> From: Mike Hammer (hmmr) [mailto:[email-masked]]
> Sent: Wednesday, May 18, 2011 4:41 PM
> To: Paul Kyzivat (pkyzivat); Roni Even
> Cc: [email-masked]
> > If the answerer does not support the group attribute and the offer
> had
> the
> > state this behavior or we will look at providing an approach that
> will
> allow
> least

---

From: Roni Even <[email-masked]>
Date: Wed, 18 May 2011 21:15:23 +0300

Paul,
I am not saying you are wrong, I am just saying that RFC 5888 says that you
may also encounter a case where the answerer will reject the call.
Roni

> Sent: Wednesday, May 18, 2011 8:09 PM
> To: Mike Hammer (hmmr)
> Cc: Roni Even; [email-masked]
> >> This is very relevant to the multiple streams case and we should
> look
> > if we
> >> the answerer to choose one m-line that the offerer prefers even of
> it
> > does
> >> not understand CLUE.
> >
> doesn't

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 May 2011 20:27:07 +0200

Hi Roni, 

>I am not saying you are wrong, I am just saying that RFC 5888 says that you may also encounter a case where the answerer will reject the call.

In my opinion the call would be rejected even without the presence of the do-not-understand elements, because the rejection decission is based on what IS understood.

(Of course, some implementiations may reject things based on the presence of do-not-understand elements, but that is not standardized behavior.)

If you want to mandate someone to understand something, you need to place an associated option-tag in the Require header field.

Regards,

Christer

> > However, if there is any grouping involved such that you need to 
> > have
> a
> ought to keep in mind that this could happen, and set things up so 
> that something reasonable happens. You can't expect the dumb legacy 
> device to figure out much.
> 
> likely to be better than no call at all. And if not, there is always 
> the option of hanging up. But better, presumably the offer could have 
> been constructed in a way that produced a better result.
> 
> 	Thanks,
> 	Paul
> 
> > Mike
> >
> >
> >>> Either a=group: is understood, or not. If not, its ignored, and 
> >>> not
> > put
> >>>>> the benefit of the doubt I will assume you have a valid reason - 
> >>>>> perhaps just policy.
> >>>>>
> >>>>> But if the reason you reject the offer is based on your 
> >>>>> violating
> a

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Wed, 18 May 2011 14:42:49 -0500

Paul,

Murphy's Law says that if it is possible to put something together the
wrong way, 
probability says it will go the wrong way sooner or later.  LTC Murphy
had a 
young enlisted guy that always found that wrong way to do things.
System-wise, 
the black-swan events occur unless you do your best to design them out.

Machines are often designed so that there is exactly one way to do it.

We want flexibility in software, but sometimes too much is not so good.
Hopefully, proper operation of the protocol won't look like an error.

Mike

-----Original Message-----
From: Paul Kyzivat (pkyzivat) 
Sent: Wednesday, May 18, 2011 1:09 PM
To: Mike Hammer (hmmr)
Cc: Roni Even; [email-masked]
Subject: Re: [clue] legacy support in requirements

figure out much.

	Thanks,
	Paul

had
will
least
doesn't

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Wed, 18 May 2011 22:10:30 +0200

I think there should be a requirement stating that a clue endpoint must
send an initial SDP offer that can be understood by a existing SIP
native endpoint. If not we will limit the endpoints a CLUE endpoint can
call. 

That should include a basic user experience for the legacy endpoint, for
instance the default audio and video stream from the CLUE endpoint. 

Regards 

-Espen 

-----Original Message-----
Mike Hammer (hmmr)
Sent: 18. mai 2011 21:43

Paul,

Mike

-----Original Message-----
From: Paul Kyzivat (pkyzivat) 
Sent: Wednesday, May 18, 2011 1:09 PM
To: Mike Hammer (hmmr)
Cc: Roni Even; [email-masked]
Subject: Re: [clue] legacy support in requirements

figure out much.

	Thanks,
	Paul

had
will
least
doesn't

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 May 2011 19:37:50 -0400

> Hopefully, proper operation of the protocol won't look like an error.

Mike,

I don't understand the point you are trying to make in the context of 
this conversation.

This started out as a discussion of whether it was acceptable to reject 
an offer because it contains stuff (for the sake of argument lets 
restrict it to a-lines for now) the the answerer doesn't understand/know 
anything about.

Clearly its *possible* for a UA to do that. And since a UA can reject 
things for policy reasons, it may be undecidable whether it rejected 
because of the unknown lines or for some more justifed reason.

But still, I think we can *expect* a UA to refrain from doing that.

That doesn't mean they all will. But when they don't, its a bug, not a 
valid implementation choice.

	Thanks,
	Paul

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Thu, 19 May 2011 08:51:36 -0500

Paul,

What I am trying to say is that Telepresence is all about the end-user
experience, and that with multiple microphones, speakers, cameras,
displays, and data feeds there is more complexity and chance to screw
that up.  And a key point is that spatial relationships are significant
to the user experience.  As a result, more rigor is needed to design the
system to ensure that backward compatible means that legacy systems are
handled as such.

I am not sure if the protocol design is far enough along to analyze
whether correct protocol operation still results in bad user experience,
but would suggest that if certain key concepts like spatial awareness
are not understood, then that leg needs to devolve to a known legacy
state and handled by the MCU as such.  That might mean tagging some
parameters as mandatory to understand to force the determination and not
leave it ambiguous.

I believe some current systems treat legacy systems differently and
don't expect them to behave like ones that understands the dynamic
speaker controls.

Mike

-----Original Message-----
From: Paul Kyzivat (pkyzivat) 
Sent: Wednesday, May 18, 2011 7:38 PM
To: Mike Hammer (hmmr)
Cc: Roni Even; [email-masked]
Subject: Re: [clue] legacy support in requirements

Mike,

anything about.

	Thanks,
	Paul

> ought to keep in mind that this could happen, and set things up so
that
the
look
it
rejecting

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 May 2011 10:08:12 -0400

Mike,

> don't expect them to behave like ones that understands the dynamic

I suspect we are talking past each other and are not really in disagreement.

I expect that the clue specs, whatever they turn out to be, will require 
support for a bunch of existing sip/sdp mechanisms that are generally 
optional and not widely implemented in lower end devices.

If so, then if we have two clueful systems attempting to connect, we 
will be in the realm of negotiating using syntax that both understand. 
In that case, this discussion of how to behave when something *isn't* 
understood is moot. Rather that situation will arise when we have a 
clueful system attempting to connect to a clueless system, or visa 
versa. That is where my focus is in this discussion.

Further into the future, perhaps we will have clue_v2, clue_v3, etc. In 
that case, we may again be into a situation where we have a clue_v1_ful 
system that doesn't understand something coming from a clue_v2_ful 
system. When designing any new protocol for clue_v1, we should keep in 
mind to specify how to handle that which isn't understood in order to 
support that future scenario.

	Thanks,
	Paul

---

From: Stephen Botzko <[email-masked]>
Date: Thu, 19 May 2011 10:10:40 -0400

In line
Stephen Botzko

On Thu, May 19, 2011 at 9:51 AM, Mike Hammer (hmmr) <[email-masked]> wrote:

> I agree that it is important for CLUE systems to be able to detect if the
far end is CLUEless.

> I think that it is always possible to deliver a bad user experience with
correct protocol.

Though I agree that we have to make sure the desired interoperable
experience is fully enabled, and that we should stick to concepts / modes of
operation that are well understood.

> Not sure what the relevance of dynamic speaker controls is here??  Though
maybe it doesn't matter, as I agree that telepresence systems will generally
want to adjust their operation when connecting to a legacy system.

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Thu, 19 May 2011 09:11:03 -0500

OK, so you do have some mechanism to discover that the other is clueful.

That eases my concerns.

Mike

-----Original Message-----
From: Paul Kyzivat (pkyzivat) 
Sent: Thursday, May 19, 2011 10:08 AM
To: Mike Hammer (hmmr)
Cc: Roni Even; [email-masked]
Subject: Re: [clue] legacy support in requirements

Mike,

> don't expect them to behave like ones that understands the dynamic

I suspect we are talking past each other and are not really in
disagreement.

	Thanks,
	Paul

have
not
>>>>>>>>              When the offer includes parameters that the
answerer
violating
>>>>>>> penalties for violating its specs. But sometimes the market
does.

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Thu, 19 May 2011 09:18:21 -0500

Stephen,

I was thinking of when you could have more participants than displays
and that what gets mapped where is dynamic and may depend on speaker.
That might be handled by some other mechanism, but you need starting
point to know if an endpoint can handle such signaling.

Mike

From: Stephen Botzko [mailto:[email-masked]] 
Sent: Thursday, May 19, 2011 10:11 AM
To: Mike Hammer (hmmr)
Cc: Paul Kyzivat (pkyzivat); [email-masked]
Subject: Re: [clue] legacy support in requirements

In line
Stephen Botzko

On Thu, May 19, 2011 at 9:51 AM, Mike Hammer (hmmr) <[email-masked]>
wrote:

Paul,

I agree that it is important for CLUE systems to be able to detect if
the far end is CLUEless.  

	I am not sure if the protocol design is far enough along to
analyze
	whether correct protocol operation still results in bad user
experience,
	but would suggest that if certain key concepts like spatial
awareness
	are not understood, then that leg needs to devolve to a known
legacy
	state and handled by the MCU as such.  That might mean tagging
some
	parameters as mandatory to understand to force the determination
and not
	leave it ambiguous.

Though I agree that we have to make sure the desired interoperable
experience is fully enabled, and that we should stick to concepts /
modes of operation that are well understood.

	I believe some current systems treat legacy systems differently
and
	don't expect them to behave like ones that understands the
dynamic
	speaker controls.

Not sure what the relevance of dynamic speaker controls is here??
Though maybe it doesn't matter, as I agree that telepresence systems
will generally want to adjust their operation when connecting to a
legacy system.  

	Mike

	-----Original Message-----

	
	On 5/18/2011 3:42 PM, Mike Hammer (hmmr) wrote:
	> the black-swan events occur unless you do your best to design
them
	out.
	> We want flexibility in software, but sometimes too much is not
so
	good.
	
	Mike,
	
	I don't understand the point you are trying to make in the
context of
	this conversation.
	
	This started out as a discussion of whether it was acceptable to
reject
	an offer because it contains stuff (for the sake of argument
lets
	restrict it to a-lines for now) the the answerer doesn't
understand/know
	
	anything about.
	
	Clearly its *possible* for a UA to do that. And since a UA can
reject
	things for policy reasons, it may be undecidable whether it
rejected
	because of the unknown lines or for some more justifed reason.
	
	But still, I think we can *expect* a UA to refrain from doing
that.
	
	That doesn't mean they all will. But when they don't, its a bug,
not a
	valid implementation choice.
	
	       Thanks,
	       Paul
	
	>> I would agree that if the offer-answer model semantic is that
here
	are
	>> However, if there is any grouping involved such that you need
to have
	>> For example, I wouldn't want to end up with the result of a
man's
	> video
	that
	> something reasonable happens. You can't expect the dumb legacy
device
	to
	the
Behalf
	>>> fid semantics it may look to the answerer as an offer with
multiple
	>> m-lines
	>>> of the same media tyoe. In this case an implementation might
also
	>> decide to
	>>> refuse the request (e.g., 488 Not Acceptable Here, or 606
Not
	>> Acceptable),
attribute it
	>>> This is very relevant to the multiple streams case and we
should
	look
	it
	>> IMO (lets see if others differ), if a UA receives an offer
with at
	> least
	>>
	>> one m-line it is happy with, then it should not reject the
call
	> because
does
	>> I see little difference to getting to audio m-lines and only
wanting
	>> one, and getting one audio and one video and only supporting
audio.
	In
	>> general you should not reject an audio/video call just
because you
	> only
m-lines
	in
	>> an offer be arranged so the first ones are the ones it most
wants
	used
	>>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2
for
	> example
	>>>> Either a=group: is understood, or not. If not, its ignored,
and not
	rejecting
	>>>>>> From: [email-masked]
[mailto:[email-masked]] On
answerer
	>> does
	>>>> not
	>>>>>>>             understand
	>>>>>>>             there are two options, he can ignore the
unknown
the
	>> parameters
	>>>> it
	>>>>>>>         contains, then that is an implicit statement
that you
	>>>>>>> As far as I know, you are always free to reject offers,
and it
	>>>>>> doesn't
	>>>>>>> really imply anything when you do that..  Whether it is
wise is
	>>>>>> In general I don't know for certain the reason why, and
so if I
violating
	> a
	>>>>>> spec, then you are non-conforming, whether I can
determine you
	are
	>>>>>> non-conforming or not. Whether being non-conforming is
just
does not
	>> levy
	>>>>>> any
	>>>>>> penalties for violating its specs. But sometimes the
market does.
	>>>>>> sometimes not.) But we don't need to endorse
non-conforming

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 May 2011 11:10:21 -0400

> OK, so you do have some mechanism to discover that the other is clueful.

No mechanisms have yet been specified.

I certainly think the existing requirements at least imply such discovery.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 20 May 2011 10:27:00 +0200

> Sent: 19 May 2011 15:08
[JRE] And furthermore, we might have a conference comprising a number of CLUEful endpoints and a number of CLUEless endpoints. We would ideally like to be in a position where the CLUEful endpoint users can share a telepresence experience, and yet the CLUEless endpoint users can still participate meaningfully in the conference.

John

> >>> However, if there is any grouping involved such that you 
> need to have
> >> a
> >> something reasonable happens. You can't expect the dumb 
> legacy device
> > to
> >>
> >> figure out much.
> >>
> the offer
> >>>> fid semantics it may look to the answerer as an offer 
> with multiple
> >>> m-lines
> >>>>>>>>          contains, then that is an implicit 
> statement that you
> >>>>> understand
> >>>>>>>> As far as I know, you are always free to reject 
> offers, and it
> >>>>>>> doesn't
> >>>>>>> But if the reason you reject the offer is based on 
> your violating
> >> a

---

From: Stephen Botzko <[email-masked]>
Date: Fri, 20 May 2011 06:11:39 -0400

in-line
Stephen Botzko

On Fri, May 20, 2011 at 4:27 AM, Elwell, John <
[email-masked]> wrote:

> [JRE] And furthermore, we might have a conference comprising a number of
> CLUEful endpoints and a number of CLUEless endpoints. We would ideally like
> to be in a position where the CLUEful endpoint users can share a
> telepresence experience, and yet the CLUEless endpoint users can still
> participate meaningfully in the conference.

> John
[SB]Agreed

---

From: Songhaibin <[email-masked]>
Date: Wed, 25 May 2011 06:43:40 +0000

> Elwell, John
> Sent: Friday, May 20, 2011 4:27 PM
> To: Paul Kyzivat; Mike Hammer (hmmr)
> Cc: [email-masked]
> to be in a position where the CLUEful endpoint users can share a telepresence
> experience, and yet the CLUEless endpoint users can still participate
> meaningfully in the conference.
> 
> John
> 

I think this is out of the scope of CLUE WG.
> > support that future scenario.

I think this will be in the scope of CLUE WG, of course, in the future.

-Haibin

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 May 2011 08:40:30 -0400

Songhaibin,

> I think this is out of the scope of CLUE WG.

Can you be more precise? Exactly what do you think is out of scope?

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 25 May 2011 15:59:47 +0200

> From: Songhaibin [mailto:[email-masked]] 
> Sent: 25 May 2011 07:44
> To: Elwell, John; Paul Kyzivat; Mike Hammer (hmmr)
> Cc: [email-masked]
> On Behalf Of
[JRE] I don't know why you say that. In fact it is covered in the use cases draft, section 4.5.

John

---

From: Songhaibin <[email-masked]>
Date: Thu, 26 May 2011 01:50:03 +0000

Hi John and Paul,

> From: Elwell, John [mailto:[email-masked]]
> Sent: Wednesday, May 25, 2011 10:00 PM
> To: Songhaibin; Paul Kyzivat; Mike Hammer (hmmr)
> Cc: [email-masked]

IMHO, the interworking with the CLUEless endpoints may mostly rely on the existing standard for video conference, which will not be re-invented in this WG. The CLUEful endpoints/MCU(maybe not all of them) need to understand the existing standard in order to connect. What kind of signaling or parameters MUST be communicated between the CLUEful endpoints or between CLUEful endpoint and CLUEful MCU, for the interworking with CLUEless endpoints? Can they also be done by the internal implementation in MCU or the endpoint?

By the way, I am not an expert on telepresence, maybe the question seems stupid.

Thanks,
-Haibin

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 26 May 2011 07:47:40 +0530

It is good to support legacy video (clueless) devices  with clueful
devices in the standard manner. There MUST be requirement to clarify how
to interop with clueless devices. But it should not be mandated for all
clueful devices to support clueless devices. It is possible to have two
solution

1) clueful device solution
2) Interop solution for clueful and clueless solution.

IMO, it is better for few devices (endpoint) compliance to solution 1
only, few other devices (middle-boxes) support both of the solutions by
which end-to-end interop is feasible. 

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Songhaibin
Sent: Thursday, May 26, 2011 7:20 AM
To: Elwell, John; Paul Kyzivat (pkyzivat); Mike Hammer (hmmr); Paul
Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [clue] legacy support in requirements

Hi John and Paul,

> > > > I expect that the clue specs, whatever they turn out to be, will

> > > > require support for a bunch of existing sip/sdp mechanisms that
> > are generally
> > > > clueful system attempting to connect to a clueless system, or 
> > > > visa versa. That is where my focus is in this discussion.

IMHO, the interworking with the CLUEless endpoints may mostly rely on
the existing standard for video conference, which will not be
re-invented in this WG. The CLUEful endpoints/MCU(maybe not all of them)
need to understand the existing standard in order to connect. What kind
of signaling or parameters MUST be communicated between the CLUEful
endpoints or between CLUEful endpoint and CLUEful MCU, for the
interworking with CLUEless endpoints? Can they also be done by the
internal implementation in MCU or the endpoint?

By the way, I am not an expert on telepresence, maybe the question seems
stupid.

Thanks,
-Haibin

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 25 May 2011 22:22:22 -0400

Hi Haibin

Some ways of structuring the CLUE protocol might be very difficult for
existing endpoints to deal with.  Other ways might be more "legacy
friendly", in the sense that the ability to negotiate a CLUEless call
between a CLUEd endpoint and a normal SIP endpoint would be straightforward.

I think the intent of the requirement is to make sure the protocol design
takes the second path.

The challenge is that AFAIK there is are no guarantees in SIP itself that
assure any interoperability between the SIP endpoints.  For example, there
is nothing in the SIP RFCs that mandate common codecs. Since compliant SIP
endpoints might not interoperate anyway, you can not guarantee that a CLUE
endpoint can interoperate with them either.  However, I think the intent is
important, so we should try to craft wording that captures it.

Regards,
Stephen Botzko

On Wed, May 25, 2011 at 9:50 PM, Songhaibin <[email-masked]> wrote:

> > [JRE] I don't know why you say that. In fact it is covered in the use
> cases draft,
> > section 4.5.
> >
> > John
>
> IMHO, the interworking with the CLUEless endpoints may mostly rely on the
> existing standard for video conference, which will not be re-invented in
> this WG. The CLUEful endpoints/MCU(maybe not all of them) need to understand
> the existing standard in order to connect. What kind of signaling or
> parameters MUST be communicated between the CLUEful endpoints or between
> CLUEful endpoint and CLUEful MCU, for the interworking with CLUEless
> endpoints? Can they also be done by the internal implementation in MCU or
> the endpoint?
>
>

---

From: Songhaibin <[email-masked]>
Date: Thu, 26 May 2011 03:52:35 +0000

Hi Stephen,

I just would like to dig out that if there is much work to do from the protocol perspective to make the CLUE "legacy friendly", or it can be  just an implementation issue.

I understand that the intent is important, and I also think that the second path makes more sense:)

BR,
-Haibin

From: Stephen Botzko [mailto:[email-masked]] 
Sent: Thursday, May 26, 2011 10:22 AM
To: Songhaibin
Cc: Elwell, John; Paul Kyzivat; Mike Hammer (hmmr); [email-masked]
Subject: Re: [clue] legacy support in requirements

Hi Haibin

Some ways of structuring the CLUE protocol might be very difficult for existing endpoints to deal with.  Other ways might be more "legacy friendly", in the sense that the ability to negotiate a CLUEless call between a CLUEd endpoint and a normal SIP endpoint would be straightforward.

I think the intent of the requirement is to make sure the protocol design takes the second path.

The challenge is that AFAIK there is are no guarantees in SIP itself that assure any interoperability between the SIP endpoints.  For example, there is nothing in the SIP RFCs that mandate common codecs. Since compliant SIP endpoints might not interoperate anyway, you can not guarantee that a CLUE endpoint can interoperate with them either.  However, I think the intent is important, so we should try to craft wording that captures it.

Regards,
Stephen Botzko

Thanks,
-Haibin

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 May 2011 09:34:06 -0400

Haibin,

(speaking as individual)

IMO the key issue here is likely to be how to structure the initial 
invite from a CLUEful device. Hopefully it will be structured so that 
when processed by a CLUEless device that ignores all it doesn't 
understand, what remains will "make sense" to devices that could 
plausibly interoperate.

Invites *from* a CLUEless device to a CLUEful device should be less 
trouble. Then it should be straightforward for the clueful device to 
recognize the situation and take appropriate action.

	Thanks,
	Paul

On 5/25/2011 11:52 PM, Songhaibin wrote:
> On Wed, May 25, 2011 at 9:50 PM, Songhaibin<[email-masked]>  wrote:
> Hi John and Paul,
>

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 26 May 2011 12:08:16 -0700

Roni, Paul, John-
Would you care to suggest the wording you would like to see as a
requirement for legacy interoperability? That would be helpful.

Thanks,
Allyn

> Sent: Wednesday, May 18, 2011 11:13 AM
> To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
....
> requirement to address the case of a call from a CLUE aware endpoint
to
have
multiple
> > >>>>> really imply anything when you do that..  Whether it is wise
is

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 27 May 2011 08:21:46 +0200

Allyn,

I already made a proposal:
http://www.ietf.org/mail-archive/web/clue/current/msg00221.html

John

> Sent: 26 May 2011 20:08
> To: Roni Even; Paul Kyzivat (pkyzivat); Elwell, John
> Cc: [email-masked]
> > Anyhow we are discussing solution while my point is that we 
> will need
> > as a
> > > > of the same media tyoe. In this case an implementation 
> might also
> > > decide to
> > > >>>> the benefit of the doubt I will assume you have a 
> valid reason
> -
> > > >>>> perhaps
> > > >>>> just policy.
> > > >>>>

---

From: Stephen Botzko <[email-masked]>
Date: Fri, 27 May 2011 06:53:17 -0400

Do you think that the language in requirement 10 means "SIP capabilities"?
Or something else?

I am thinking that issue is really about the signaling/protocol design
itself, and isn't directly related to how many screens and cameras a system
might have.

Stephen Botzko

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 27 May 2011 13:03:03 +0200

I thought requirement 10 would cover both (signalling/protocol capabilities as well as user interface capabilities).

John

> Sent: 27 May 2011 11:53
> To: Elwell, John
> Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat 
> (pkyzivat); [email-masked]
> Do you think that the language in requirement 10 means "SIP 
> capabilities"?  Or something else?
> 
> I am thinking that issue is really about the 
> signaling/protocol design itself, and isn't directly related 
> to how many screens and cameras a system might have.
> 
> Stephen Botzko
> 
> 
> On Fri, May 27, 2011 at 2:21 AM, Elwell, John 
> <[email-masked]> wrote:
> 
> 
> 	Allyn,
> 	
> 	> > non CLUE aware endpoint. Even if the consensus will 
> be to have the
> 	> > preferred
> 	> > > I would agree that if the offer-answer model 
> semantic is that here
> 	> > are
> 	> > > For example, I wouldn't want to end up with the 
> result of a man's
> 	> > video
> 	> > > > refuse the request (e.g., 488 Not Acceptable 
> Here, or 606 Not
> 	> > > Acceptable),
> 	> > > one m-line it is happy with, then it should not 
> reject the call
> 	> > because
> 	> > > general you should not reject an audio/video call 
> just because you
> 	> > only
> 	> > > support audio.
> 	> > >
> 	> > > an offer be arranged so the first ones are the 
> ones it most wants
> 	> > used
> 	> > > if not all are.
> 	> > >
> 	> > >   Thanks,
> 	> > >   Paul
> 	> > >
> 	> > > > Roni
> 	> > > >
> 	> > > >>> Look at 
> http://tools.ietf.org/html/rfc5888#section-9.4.2 for
> 	> > > example
> 	> > > >>> Roni
> 	> > > >>
> 	> > > >>>>>           there are two options, he can 
> ignore the unknown
> 	> > > >> parameters
> 	> > > >>>> or
> 	> > > >>>>>           reject
> 	> > > >>>>>           the offer.
> 	> > > >>>>>       You are required to ignore parameters 
> you do not
> 	> > > understand.
> 	> > > >>>>>

---

From: Stephen Botzko <[email-masked]>
Date: Fri, 27 May 2011 07:15:59 -0400

I'm not sure that the language actually covers that (it seems ambiguous).

What do you think about changing "endpoints with different capabilities" to
"disparate devices"?

Stephen

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Fri, 27 May 2011 13:22:40 +0200

I think it would be clearer to formulate two different requirements 

1)      Two solution must provide a mechanism that make it possible for
endpoints with different capabilities to interoperate, e.g.
interoperability between a 2 camera/screens and 3 camera/screens
endpoint.

2)      Two solution must provide a mechanism that make it possible for
endpoints that are CLUE aware to interoperate with CLUE-less endpoints. 

Cheers 

-Espen 

Sent: 27. mai 2011 13:16

I'm not sure that the language actually covers that (it seems
ambiguous).

What do you think about changing "endpoints with different capabilities"
to "disparate devices"?

Stephen

On Fri, May 27, 2011 at 7:03 AM, Elwell, John
<[email-masked]> wrote:

I thought requirement 10 would cover both (signalling/protocol
capabilities as well as user interface capabilities).

John

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 27 May 2011 14:28:16 +0200

I can live with Steve's proposal. I also don't mind separating the requirements, but I don't think we should refer to CLUE in the requirement - the RFC will live a long time after CLUE is finished and closed down. So if we want to separate the requirements, I would propose:

REQMT-10:  The solution MUST include a mechanism that makes it possible for endpoints with different capabilities to interoperate in a telepresence conference.
REQMT-10bis:  The solution MUST include a mechanism that makes it possible for endpoints without support for telepresence extensions to participate in a telepresence conference with those that do.

John

> From: Espen Berger (espeberg) [mailto:[email-masked]]
> Sent: 27 May 2011 12:23
> To: Stephen Botzko; Elwell, John
> Cc: [email-masked]
> 1)      Two solution must provide a mechanism that make it
> interoperate, e.g. interoperability between a 2
> camera/screens and 3 camera/screens endpoint.
>
> 2)      Two solution must provide a mechanism that make it
> possible for endpoints that are CLUE aware to interoperate
> with CLUE-less endpoints.
>
>
>
> Cheers
>
>
>
> -Espen
>
>
>
> Behalf Of Stephen Botzko
> What do you think about changing "endpoints with different
> capabilities" to "disparate devices"?
>
> Stephen
>
>
>
> I thought requirement 10 would cover both
> (signalling/protocol capabilities as well as user interface
> capabilities).
>
> John
>
>
>
> >       > > > >> If a=group: *is* understood, but some
> parameter within
> >       > it is not,
> >       > > > there

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 May 2011 08:51:01 -0400

That works for me

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Fri, 27 May 2011 07:58:45 -0500

Looks good to me too.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Elwell, John
Sent: Friday, May 27, 2011 8:28 AM
To: Espen Berger (espeberg); Stephen Botzko
Cc: [email-masked]
Subject: Re: [clue] legacy support in requirements

I can live with Steve's proposal. I also don't mind separating the
requirements, but I don't think we should refer to CLUE in the
requirement - the RFC will live a long time after CLUE is finished and
closed down. So if we want to separate the requirements, I would
propose:

REQMT-10:  The solution MUST include a mechanism that makes it possible
for endpoints with different capabilities to interoperate in a
telepresence conference.
REQMT-10bis:  The solution MUST include a mechanism that makes it
possible for endpoints without support for telepresence extensions to
participate in a telepresence conference with those that do.

John

---

From: Stephen Botzko <[email-masked]>
Date: Fri, 27 May 2011 08:59:50 -0400

I am ok with it, we might wordsmith it slightly to remove the capability
word.  It has become overloaded.

Stephen Botzko

On Fri, May 27, 2011 at 8:51 AM, Paul Kyzivat <[email-masked]> wrote:

>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>
>>> Of
>>>
>>>> Roni Even
>>>>> I would agree that if the offer-answer model semantic is that here
>>>>>
>>>> are
>>>>
>>>>> For example, I wouldn't want to end up with the result of a man's
>>>>>
>>>> video
>>>>
>>>>>> If the answerer does not support the group attribute
>>>>>>
>>>>> and the offer
>>>
>>>> had
>>>>> the
>>>>>
>>>>>> refuse the request (e.g., 488 Not Acceptable Here, or 606 Not
>>>>>>
>>>>> Acceptable),
>>>>>
>>>>>> state this behavior or we will look at providing an
>>>>>>
>>>>> approach that
>>>
>>>> will
>>>>> allow
>>>>>
>>>>>> the answerer to choose one m-line that the offerer
>>>>>>
>>>>> prefers even of
>>>
>>>> it
>>>>
>>>>> does
>>>>>
>>>>>> not understand CLUE.
>>>>>>
>>>>>
>>>>> one m-line it is happy with, then it should not reject the call
>>>>>
>>>> because
>>>>
>>>>> I see little difference to getting to audio m-lines and
>>>>>
>>>> only wanting
>>>
>>>>> general you should not reject an audio/video call just because you
>>>>>
>>>> only
>>>>
>>>>> support audio.
>>>>>
>>>>> an offer be arranged so the first ones are the ones it most wants
>>>>>
>>>> used
>>>>
>>>>> if not all are.
>>>>>
>>>>>        Thanks,
>>>>>        Paul
>>>>>
>>>>> Roni
>>>>>>
>>>>>>>> Look at http://tools.ietf.org/html/rfc5888#section-9.4.2 for
>>>>>>>>
>>>>>>> example
>>>>>
>>>>>>  Roni
>>>>>>>>
>>>>>>>
>>>>> put
>>>>>>> If a=group: *is* understood, but some parameter within
>>>>>>>
>>>>>> it is not,
>>>
>>>> there
>>>>>
>>>>>>>>>>           there are two options, he can ignore the unknown
>>>>>>>>>>
>>>>>>>>> parameters
>>>>>>>
>>>>>>>> or
>>>>>>>>>
>>>>>>>>>>           reject
>>>>>>>>>>           the offer.
>>>>>>>>>>       You are required to ignore parameters you do not
>>>>>>>>>>
>>>>>>>>> understand.
>>>>>
>>>>>>
>>>>>>>>        contains, then that is an implicit statement that you
>>>>>>>>>>
>>>>>>>>> understand
>>>>>>>
>>>>>>>>> In general I don't know for certain the reason why,
>>>>>>>>>
>>>>>>>> and so if I
>>>
>>>> give
>>>>>
>>>>>>  you
>>>>>>>> something stronger, is a separate discussion. The
>>>>>>>>>
>>>>>>>> IETF does not
>>>
>>>> levy
>>>>>
>>>>>>  any

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 May 2011 09:02:00 -0400

> REQMT-10bis:  The solution MUST include a mechanism that makes it possible for endpoints without support for telepresence extensions to participate in a telepresence conference with those that do.

How about the following variant of that:

REQMT-10bis:  The solution MUST make it possible for endpoints without 
support for telepresence extensions to participate in a telepresence 
session with those that do.

I dropped "mechanism" because its unlikely to be a new mechanism that 
makes this possible. (That would require changes to the legacy systems.) 
Rather it will need to be the manner of using existing mechanisms.

And I changed "telepresence conference" to "telepresence session" 
because this ought to work point-point as well as for conferences.
(But we probably need more definition work here, since neither 
telepresence-conference nor telepresence-session is currently defined.)

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 27 May 2011 15:54:35 +0200

Yes, I like Paul's changes.

John

> Sent: 27 May 2011 14:02
> > I can live with Steve's proposal. I also don't mind
> separating the requirements, but I don't think we should
> refer to CLUE in the requirement - the RFC will live a long
> time after CLUE is finished and closed down. So if we want to
> separate the requirements, I would propose:
> >
> > REQMT-10:  The solution MUST include a mechanism that makes
> it possible for endpoints with different capabilities to
> > REQMT-10bis:  The solution MUST include a mechanism that
> makes it possible for endpoints without support for
> telepresence extensions to participate in a telepresence
> conference with those that do.
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Fri, 27 May 2011 19:35:54 +0530

Paul,

I have the doubt whether this requirement has to be "MUST" or "SHOULD"
because CLUE (telepresence) end-point may not like to interop with
simple audio end-point (SIP UA). It may be just policy not to received
audio-call in CLUE endpoint because of better utilization of costly
resources. Please let me know your opinion here. 

Apart from this doubt, I like your requirement proposal.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Elwell, John
Sent: Friday, May 27, 2011 7:25 PM
To: Paul Kyzivat (pkyzivat); [email-masked]
Subject: Re: [clue] legacy support in requirements

John

> separating the requirements, but I don't think we should refer to CLUE

> in the requirement - the RFC will live a long time after CLUE is 
> finished and closed down. So if we want to separate the requirements, 
> I would propose:
> >
> it possible for endpoints with different capabilities to interoperate 
> in a telepresence conference.
> makes it possible for endpoints without support for telepresence 
> extensions to participate in a telepresence conference with those that

> do.

> makes this possible. (That would require changes to the legacy 
> systems.) Rather it will need to be the manner of using existing 
> mechanisms.
>
> >> possible for endpoints with different capabilities to interoperate,

> >> e.g. interoperability between a 2 camera/screens and 3 
> >> camera/screens endpoint.
> >>
> >> possible for endpoints that are CLUE aware to interoperate with 
> >> CLUE-less endpoints.
> >>
> >>
> >>
> >> Cheers
> >>
> >>
> >>
> >> -Espen
> >>
> >>
> >>
> >>> Cc: Allyn Romanow (allyn); Roni Even; Paul Kyzivat (pkyzivat); 
> >>> [email-masked]
> >>
> >>> I am thinking that issue is really about the signaling/protocol 
> >>> design itself, and isn't directly related to how many screens and 
> >>> cameras a system might have.
> >>>
> >>> Stephen Botzko
> >>>
> >>>
> >>>        >  >  requirement to address the case of a call from a CLUE

> >>> aware endpoint
> >>>        >  >  >  video and audio feed integrated to make sense then

> >>> watch out.
> >>>        >  >  >  paired with a woman's voice.  That could be rather

> >>> comical.
> >>>        >  >  >  >  fid semantics it may look to the answerer as an

> >>> offer with
> >>>        >  >  >  >>  Either a=group: is understood, or not. If not,

> >>> its ignored, and

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 27 May 2011 16:10:26 +0200

The requirement is on the solution. The solution must provide this capability, even though some deployments might not wish to use it.

John

> From: Parthasarathi R (partr) [mailto:[email-masked]]
> Sent: 27 May 2011 15:06
> To: Elwell, John; Paul Kyzivat (pkyzivat); [email-masked]
> Behalf Of
> refer to CLUE
> interoperate,
> > >>>        >  Would you care to suggest the wording you
> would like to
> > >>> see as a
> > >>>        >  requirement for legacy interoperability? That
> would be
> > >>> helpful.
> > >>>        >
> > >>>        >  Thanks,
> > >>>        >  Allyn
> > >>>        >
> > >>>        >  >  >  >  This is very relevant to the
> multiple streams
> > >>> case and we should
> > >>>        >  >  look
> > >>>        >  >  >  if we
> > >>>        >  >  >  IMO (lets see if others differ), if a
> UA receives
> > >>> an offer with at
> > >>>        >  >  >  least
> > >>>        >  >  >
> > >>>        >  >  >  >>  AFAICT there are no examples in
> this document
> > >>> where failure to

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Fri, 27 May 2011 08:39:04 -0700

Hi John, 
Your suggestion is

The solution MUST include a mechanism that makes it
              possible for endpoints with different capabilities to
              interoperate in a telepresence conference, including
audio/video endpoints that do not support any telepresence extensions.

I have redone the requirements so that the reqmt for heterogeneous
devices as in the use case, which was reqmt 10, is now more specific.
So, we would not piggy back legacy on the hetereogeneity requirement.

 Assuming this now refers only to the interaction of CLUE and non-CLUE,
the problem is that they don't interoperate in a telepresence sense- the
purpose for the WG.

Therefore, I would ask you to be more specific about the legacy
requirement. I should think that the general meaning would be along the
lines of that CLUE would not break any existing interworking - however
this is general, and it would be good to make it more specific.

I think it would be really helpful if you Paul and Roni, and others if
they wish, could suggest some new text to more specifically cover what
you have in mind which has been discussed in detail on the list.

Thanks,
Allyn

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Thursday, May 26, 2011 11:22 PM
To: Allyn Romanow (allyn); Roni Even; Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [clue] legacy support in requirements

Allyn,

John

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 27 May 2011 18:28:05 +0200

I was quite happy with the refinements that Paul suggested, which I hope help. Unfortunately I will not be available during the next couple of weeks, so I will have to leave it to others to help arrive at appropriate words.

John 

> Sent: 27 May 2011 16:39
> To: Elwell, John; Roni Even; Paul Kyzivat (pkyzivat)
> Cc: [email-masked]
> ignored, and

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 May 2011 13:16:06 -0400

I intentionally wrote SHOULD/MUST because I was uncertain which one to 
use. It bears discussion.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 May 2011 13:24:44 -0400

Allyn,

It seems that what I suggested is the latest preference. Here it is 
again. I think it is a new requirement in addition to the existing REQMT-10:

===========================
REQMT-XYZ:  The solution SHOULD/MUST make it possible for endpoints 
without support for telepresence extensions to participate in a 
telepresence session with those that do.
===========================

I dropped "mechanism" from John's because its unlikely to be a new 
mechanism that makes this possible. (That would require changes to the 
legacy systems.) Rather it will need to be the manner of using existing 
mechanisms.

And I don't know if this ought to be SHOULD/MUST. I could go either way 
on that, but if its SHOULD, then we ought to add some words on what the 
criteria are for not doing it.

	Thanks,
	Paul

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 27 May 2011 10:31:04 -0700

Hi Paul,
The summation of the protocol work designed by CLUE is referred to as
"solution".  A CLUE-less device is a device without the solution.
Therefore, I propose to replace "telepresence extensions" (which is
undefined, and could refer to telepresence extension not defined by CLUE)
with "solution".  Thereafter, 10bis reads:

REQMT-10bis:  The solution MUST make it possible for endpoints without
support for the solution to participate in a telepresence
session with those that do.

On 5.27.2011 06:02 , "Paul Kyzivat" <[email-masked]> wrote:

>>closed down. So if we want to separate the requirements, I would propose:
>>

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 27 May 2011 10:33:14 -0700

As for SHOULD/MUST:
I'm in favor of SHOULD, and the criteria would "if it can be done without
adding excessive call setup delay, i.e. more than one round-trip time.
Stephan

On 5.27.2011 10:24 , "Paul Kyzivat" <[email-masked]> wrote:

>> I was quite happy with the refinements that Paul suggested, which I
>>hope help. Unfortunately I will not be available during the next couple
>>of weeks, so I will have to leave it to others to help arrive at
>>appropriate words.
>>
>> John
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 May 2011 13:33:34 -0400

> use. It bears discussion.

OOPS - I didn't. (I had started to, in a proposal I was writing before I 
saw John's and liked it.) But I just sent a new revision that defers the 
SHOULD/MUST decision.

	Sorry,
	Paul

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Fri, 27 May 2011 10:36:59 -0700

Great! I must've missed seeing this before I responded to John.
This works for me.

Allyn

> Sent: Friday, May 27, 2011 10:25 AM
> To: Elwell, John
> Cc: Allyn Romanow (allyn); Roni Even; [email-masked]
> >>>> non CLUE aware endpoint. Even if the consensus will be to have
the

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 May 2011 13:37:48 -0400

> adding excessive call setup delay, i.e. more than one round-trip time.

I'm ok with that - at least the "excessive" part, but maybe not the i.e.
(IMO it would not be unreasonable if it took two o/a cycles in the same 
INVITE, maybe even three. If it took two separate INVITEs then it seems 
pretty unreasonable.)

	Thanks,
	Paul

> On 5.27.2011 10:24 , "Paul Kyzivat"<[email-masked]>  wrote:
>
>> Allyn,
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 May 2011 13:42:53 -0400

Stephan,

> session with those that do.

I appreciate what you are trying to accomplish, but I'm not too fond of 
the result. I think it would be unwise to formally define the term 
"solution" to have this meaning - its too general a word to co-opt.

I would be ok with something like telepresence-solution. But whatever it 
is, it should then be added to the definitions.

	Thanks,
	Paul

> On 5.27.2011 06:02 , "Paul Kyzivat"<[email-masked]>  wrote:
>
>>
>>

---

From: Roni Even <[email-masked]>
Date: Fri, 27 May 2011 21:33:57 +0300

Hi Haibin,
We are not talking about the solution at the moment. The solution is
probably a mixture protocol and implementation.  If (and this is a question)
we do a new protocol or extension to a current protocol it should allow EPs
that support the protocol or extension to establish a media connection with
EPS who do not. Still it will be implmenation dependent if the "CLUE" EPs
will try to establish such a connection.
Roni

> Sent: Thursday, May 26, 2011 6:53 AM
> To: Stephen Botzko
> Cc: [email-masked]
> I just would like to dig out that if there is much work to do from the
> protocol perspective to make the CLUE "legacy friendly", or it can be
> just an implementation issue.
> 
> The challenge is that AFAIK there is are no guarantees in SIP itself
> that assure any interoperability between the SIP endpoints.  For
> example, there is nothing in the SIP RFCs that mandate common codecs.
> Since compliant SIP endpoints might not interoperate anyway, you can
> not guarantee that a CLUE endpoint can interoperate with them either.
> However, I think the intent is important, so we should try to craft
> wording that captures it.
> 
> Regards,
> Stephen Botzko
> 
> 
> visa
> the existing standard for video conference, which will not be re-
> invented in this WG. The CLUEful endpoints/MCU(maybe not all of them)

---

From: Roni Even <[email-masked]>
Date: Fri, 27 May 2011 21:36:58 +0300

Looks OK to me
Roni

> Sent: Friday, May 27, 2011 4:02 PM
> To: [email-masked]
> possible for endpoints with different capabilities to interoperate in a
> telepresence conference.
> systems.)

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 27 May 2011 13:07:38 -0700

Ok.

How about:

"Telepresence Extensions": The protocol extensions beyond non-telepresence
SIP specified by the CLUE WG.  (The protocol and architecture docs may
wish to include something like "as defined herein")

"Solution": Telepresence Extensions specification(s) and their
implementation.

Stephan 

On 5.27.2011 10:42 , "Paul Kyzivat" <[email-masked]> wrote:

>>>>possible
>>>>>>         >   >   >   >   This is very relevant to the multiple
>>>>>>streams
>>>>>> case and we should
>>>>>>         >   >   look
>>>>>>         >   >   >   if we
>>>>>>         >   >   >   IMO (lets see if others differ), if a UA
>>>>>>receives
>>>>>> an offer with at
>>>>>>         >   >   >   least
>>>>>>         >   >   >
>>>>>>         >   >   >   I see little difference to getting to audio
>>>>>>m-lines
>>>>>> and
>>>>>>         >   only wanting
>>>>>>         >   >   >   I think it will behoove clue to strongly
>>>>>>recommend
>>>>>> that
>>>>>>         >   the m-lines
>>>>>>         >   >   in
>>>>>>         >   >   >   >>   AFAICT there are no examples in this
>>>>>>document
>>>>>> where failure to
>>>>>>         >   >   >   >>>>>             When the offer includes
>>>>>>         >   >   >   >>>>>         Rejecting the offer in that case
>>>>>>is
>>>>>> not really kosher.
>>>>>>         >   >   >   >>>>>         If you reject something because
>>>>>>you
>>>>>> don't like the
>>>>>>         >   >   >   parameters
>>>>>>         >   >   >   >>   it
>>>>>>         >   >   >   >>>>   Certainly you are always free to reject
>>>>>>an
>>>>>> offer.
>>>>>>         >   >   >   >>>>   In general I don't know for certain the
>>>>>>reason
>>>>>> why,
>>>>>>         >   and so if I
>>>>>>         >   >   >   give
>>>>>>         >   >   >   >>>>   you
>>>>>>         >   >   >   >>>>   the benefit of the doubt I will assume
>>>>>>you have
>>>>>> a
>>>>>>         >   valid reason
>>>>>>         >   -
>>>>>>         >   >   >   >>>>   perhaps
>>>>>>         >   >   >   >>>>   just policy.
>>>>>>         >   >   >   >>>>
>>>>>>         >   >   >   >>>>   something stronger, is a separate
>>>>>>discussion.
>>>>>> The
>>>>>>         >   IETF does not
>>>>>>         >   >   >   levy
>>>>>>         >   >   >   >>>>   any

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 May 2011 16:23:22 -0400

> wish to include something like "as defined herein")

I like that!

> "Solution": Telepresence Extensions specification(s) and their

I would still hate to see such a narrow definition of that word in any 
broad context. It would be way too confusing.

I think it would be ok in a narrow context - say a paragraph, or a 
section of a document.

	Thanks,
	Paul

> Stephan
>
>
> On 5.27.2011 10:42 , "Paul Kyzivat"<[email-masked]>  wrote:
>
>> Stephan,
>>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 May 2011 08:08:12 +0200

Hi,

The text looks good, but could we replace "by the CLUE WG" with "by RFC XXXX", and at some point we/IANA will replace XXXX with a number.

Because, I assume the definition is going to live after the WG?

Regards,

Christer

> Sent: 27. toukokuuta 2011 23:23
> To: Stephan Wenger
> Cc: [email-masked]
> > "Telepresence Extensions": The protocol extensions beyond
> > non-telepresence SIP specified by the CLUE WG.  (The protocol and
> > architecture docs may wish to include something like "as defined
> > herein")
>
> I like that!
>
> I would still hate to see such a narrow definition of that
> word in any broad context. It would be way too confusing.
>
> I think it would be ok in a narrow context - say a paragraph,
> or a section of a document.
>
>       Thanks,
>       Paul
>
> > Stephan
> >
> >
> >>> The summation of the protocol work designed by CLUE is
> referred to
> >>> as "solution".  A CLUE-less device is a device without
> the solution.
> >>> undefined, and could refer to telepresence extension not
> defined by
> >>> CLUE)
> >>> REQMT-10bis:  The solution MUST make it possible for endpoints
> >>> without support for the solution to participate in a telepresence
> >> I appreciate what you are trying to accomplish, but I'm
> not too fond
> >> of the result. I think it would be unwise to formally
> define the term
> >> I would be ok with something like telepresence-solution.
> But whatever
> >> it is, it should then be added to the definitions.
> >>
> >>    Thanks,
> >>    Paul
> >>
> separating the
> >>>>> requirement - the RFC will live a long time after CLUE
> is finished
> >>>>> and closed down. So if we want to separate the requirements, I
> >>>>> would
> >>>>> propose:
> >>>>>
> >>>>> possible for endpoints without support for telepresence
> extensions
> >>>>> to participate in a telepresence conference with those that do.
> >>>>
> >>>> REQMT-10bis:  The solution MUST make it possible for endpoints
> >>>> I dropped "mechanism" because its unlikely to be a new mechanism
> >>>> that makes this possible. (That would require changes to
> the legacy
> >>>> systems.)
> >>>>>> interoperate, e.g. interoperability between a 2 camera/screens
> >>>>>> and 3 camera/screens endpoint.
> >>>>>>
> (pkyzivat);
> signaling/protocol
> >>>>>>> design itself, and isn't directly related to how many screens
> >>>>>>> and cameras a system might have.
> >>>>>>>
> >>>>>>> Stephen Botzko
> >>>>>>>
> >>>>>>>
> >>>>>>>          >    Would you care to suggest the wording
> you would like
> >>>>>>> to see as a
> >>>>>>>          >    requirement for legacy
> interoperability? That would
> >>>>>>> be helpful.
> >>>>>>>          >
> >>>>>>>          >    Thanks,
> >>>>>>>          >    Allyn
> >>>>>>>          >
> >>>>>>>          >    >    Anyhow we are discussing solution
> while my point
> >>>>>> is that we
> >>>>>>>          >    will need
> >>>>>>>          >    >    as a
> >>>>>>>          >    >    requirement to address the case of
> a call from a
> >>>>>>> CLUE aware endpoint
> >>>>>>>          >    to
> >>>>>>>          >    >    a
> >>>>>>>          >    >    >    several options and any
> subset of options is
> >>>>>>> acceptable.
> >>>>>>>          >    >    >    However, if there is any
> grouping involved such
> >>>>>>> that you need to
> >>>>>>>          >    >    >    video and audio feed
> integrated to make sense
> >>>>>>> then watch out.
> >>>>>>>          >    >    >    paired with a woman's voice.
> That could be
> >>>>>>> rather comical.
> >>>>>>>          >    >    >
> >>>>>>>          >    >    >    Mike
> >>>>>>>          >    >    >
> >>>>>>>          >    >    >
> >>>>>>>          >    >    >    >    If the answerer does not
> support the group
> >>>>>>> attribute
> >>>>>>>          >    >    >    >    fid semantics it may
> look to the answerer
> >>>>>>> as an
> >>>>>>>          >    >    >    >    of the same media tyoe.
> In this case an
> >>>>>>> implementation
> >>>>>>>          >    >    >    >    because it contains
> several "m" lines of the
> >>>>>>> same media type.
> >>>>>>>          >    >    >    Then the reason for rejection
> is not because it
> >>>>>>> saw an
> >>>>>>>          >    attribute it
> >>>>>>>          >    >    >    didn't understand - its
> because it didn't like
> >>>>>>> something it *did*
> >>>>>>>          >    >    >    understand.
> >>>>>>>          >    >    >
> >>>>>>>          >    >    >    >    This is very relevant to
> the multiple
> >>>>>>> streams
> >>>>>>> case and we should
> >>>>>>>          >    >    look
> >>>>>>>          >    >    >    if we
> >>>>>>>          >    >    >    >    state this behavior or
> we will look at
> >>>>>>> providing an
> >>>>>>>          >    approach that
> >>>>>>>          >    >    >    will
> >>>>>>>          >    >    >    allow
> >>>>>>>          >    >    >    >    the answerer to choose
> one m-line that the
> >>>>>>> offerer
> >>>>>>>          >    prefers even of
> >>>>>>>          >    >    it
> >>>>>>>          >    >    >    does
> >>>>>>>          >    >    >    >    not understand CLUE.
> >>>>>>>          >    >    >
> >>>>>>>          >    >    >    IMO (lets see if others
> differ), if a UA
> >>>>>>> receives
> >>>>>>> an offer with at
> >>>>>>>          >    >    >    least
> >>>>>>>          >    >    >
> >>>>>>>          >    >    >    Here "understand" means
> something different -
> >>>>>>> presumably it does
> >>>>>>>          >    >    >    understand the direct meaning
> of the additional
> >>>>>>> m-line, it just
> >>>>>>>          >    >    doesn't
> >>>>>>>          >    >    >    one, and getting one audio
> and one video and
> >>>>>>> only
> >>>>>>>          >    supporting audio.
> >>>>>>>          >    >    In
> >>>>>>>          >    >    >    general you should not reject
> an audio/video
> >>>>>>> call
> >>>>>>> just because you
> >>>>>>>          >    >    only
> >>>>>>>          >    >    >    support audio.
> >>>>>>>          >    >    >
> >>>>>>>          >    >    >    >>    Subject: Re: [clue]
> legacy support in
> >>>>>>> requirements
> >>>>>>>          >    >    >    >>    OK, I looked. It is
> consistent with what I
> >>>>>>> said.
> >>>>>>>          >    >    >    >>    Either a=group: is
> understood, or not. If
> >>>>>>> not,
> >>>>>>>          >    >    >    >>    understand an a-line in
> total (or even in
> >>>>>>> part) results in
> >>>>>>>          >    >    >    >>>>    Subject: Re: [clue]
> legacy support in
> >>>>>>> requirements
> >>>>>>>          >    >    >    >>>>    On 5/17/2011 10:34
> AM, Stephen Botzko
> >>>>>>>          >    >    >    >>>>>          On 5/17/2011
> 2:24 AM, Roni Even
> >>>>>>>          >    >    >    >>>>>              When the
> offer includes
> >>>>>>>          >    >    >    >>>>>          You are
> required to ignore
> >>>>>>>          >    >    >    >>>>>          those
> >>>>>>>          >    >    >    >>>>>    As far as I know,
> you are always free
> >>>>>>> to reject
> >>>>>>>          >    >    >    >>>>>    really imply
> anything when you do that..
> >>>>>>> Whether it is wise
> >>>>>>>          >    is
> >>>>>>>          >    >    >    >>>>    perhaps
> >>>>>>>          >    >    >    >>>>>    a different question.
> >>>>>>>          >    >    >    >>>>>    Stephen Botzko
> >>>>>>>          >    >    >    >>>>
> >>>>>>>          >    >    >    >>>>    Certainly you are
> always free to reject
> >>>>>>> an
> >>>>>>> offer.
> >>>>>>>          >    >    >    >>>>    In general I don't
> know for certain the
> >>>>>>> reason
> >>>>>>> why,
> >>>>>>>          >    and so if I
> >>>>>>>          >    >    >    give
> >>>>>>>          >    >    >    >>>>    you
> >>>>>>>          >    >    >    >>>>    the benefit of the
> doubt I will assume
> >>>>>>> you have
> >>>>>>> a
> >>>>>>>          >    valid reason
> >>>>>>>          >    -
> >>>>>>>          >    >    >    >>>>    perhaps
> >>>>>>>          >    >    >    >>>>    just policy.
> >>>>>>>          >    >    >    >>>>
> >>>>>>>          >    >    >    >>>>    But if the reason you
> reject the offer is
> >>>>>>> based on your
> >>>>>>>          >    >    violating
> >>>>>>>          >    >    >    a
> >>>>>>>          >    >    >    >>>>    spec, then you are
> non-conforming,
> >>>>>>> whether I can
> >>>>>>>          >    determine you
> >>>>>>>          >    >    are
> >>>>>>>          >    >    >    >>>>    non-conforming or
> not. Whether being
> >>>>>>> non-conforming is just
> >>>>>>>          >    >    >    un-wise,
> >>>>>>>          >    >    >    >>    or
> >>>>>>>          >    >    >    >>>>    something stronger,
> is a separate
> >>>>>>> discussion.
> >>>>>>> The
> >>>>>>>          >    IETF does not
> >>>>>>>          >    >    >    levy
> >>>>>>>          >    >    >    >>>>    any
> >>>>>>>          >    >    >    >>>>    penalties for
> violating its specs. But
> >>>>>>> sometimes the market
> >>>>>>>          >    >    does.
> >>>>>>>          >    >    >    >>    (And
> >>>>>>>          >    >    >    >>>>    sometimes not.) But
> we don't need to
> >>>>>>> endorse
> >>>>>>> non-conforming
> >>>>>>>          >    >    >    behavior
> >>>>>>>          >    >    >    >>    in
> >>>>>>>          >    >    >    >>>>    our documents.
> >>>>>>>          >    >    >    >>>>
> >>>>>>>          >    >    >    >>>>         Thanks,
> >>>>>>>          >    >    >    >>>>         Paul
> >>>>>>>          >    >    >    >>>>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 May 2011 12:06:31 +0200

Hi,

I would like to keep the MUST. Because, otherwise it will be very easy to drop interoperability: we define a mechanism that works for CLUEful devices, then note that it will take a couple of more messages to make it work with legacy, and then simply decide to drop the legacy interoperability requirement for that case.

I do not think we need to mandate that the signalling always look identical, but I still think that the requirement for interoperability shall be a MUST, and we shall aim for a solution that works as good as possible for all cases.

Regards,

Christer

> Sent: 27. toukokuuta 2011 20:38
> To: Stephan Wenger
> Cc: [email-masked]
> > I'm in favor of SHOULD, and the criteria would "if it can be done
> > without adding excessive call setup delay, i.e. more than
> one round-trip time.
> > Stephan
>
> (IMO it would not be unreasonable if it took two o/a cycles
> in the same INVITE, maybe even three. If it took two separate
> INVITEs then it seems pretty unreasonable.)
>
>       Thanks,
>       Paul
>
>
> >> mechanism that makes this possible. (That would require changes to
> >> the legacy systems.) Rather it will need to be the manner of using
> >> existing mechanisms.
> >>
> >> And I don't know if this ought to be SHOULD/MUST. I could
> go either
> >> way on that, but if its SHOULD, then we ought to add some words on
> >> what the criteria are for not doing it.
> >>
> >>    Thanks,
> >>    Paul
> >>
> >>> hope help. Unfortunately I will not be available during the next
> >>> couple of weeks, so I will have to leave it to others to
> help arrive
> >>> at appropriate words.
> >>>
> >>> John
> >>>
> >>>>                 interoperate in a telepresence conference,
> >>>> including audio/video endpoints that do not support any
> telepresence extensions.
> >>>>
> >>>>    Assuming this now refers only to the interaction of CLUE and
> >>>> non-CLUE, the problem is that they don't interoperate in a
> >>>> telepresence
> >>>> sense- the
> >>>> purpose for the WG.
> >>>>
> >>>> requirement. I should think that the general meaning
> would be along
> >>>> the lines of that CLUE would not break any existing
> interworking -
> >>>> however this is general, and it would be good to make it more
> >>>> specific.
> >>>>
> >>>> I think it would be really helpful if you Paul and Roni,
> and others
> >>>> if they wish, could suggest some new text to more specifically
> >>>> cover what you have in mind which has been discussed in
> detail on the list.
> >>>>
> >>>> Thanks,
> >>>> Allyn
> >>>>
> >>>>
> >>>>
> >>>>>> the preferred video in the first video m-line.
> >>>>>>
> >>>>>> Regards
> >>>>>> Roni
> >>>>>>
> >>>>>>
> >>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 May 2011 09:06:07 -0400

OK by me.

	Thanks,
	Paul