Subject: [clue] Comments on draft-romanow-clue-telepresence-requirements-02

From: <[email-masked]>
Date: Wed, 11 May 2011 14:08:42 +0000

Hi,

Below some comments after review of this new draft, and of the earlier discussions.

++
The definition of the middlebox is confusing. In certain cases, a middle box could be initiator/terminator (of media and signaling), for instance when a multipoint telepresence session is initiated by a MCU, and the MCU sends media to the endpoints (kind of "waiting room") until all participants have joined. We could think that in such cases, the MCU acts an endpoint, but this not very satisfying since endpoint as defined in the document seems to be a physical entity rather than a function or a role. 

The document shall be more explicit on the list of stream/endpoint characteristics that the solution shall be able to signal.  This would help to further work on all requirements dealing with these characteristics, and in particularly for the discussion on requirements 4 and 7.
                           
Is there a rationale of having removed a part of the REQMT-11 (previously the REQMT-09 in version 01)? Talking here of the requirement that allowed a remote to make the placement for the local.

The lip sync should be added as a requirement to the solution. Actually, I don't see why it should not be part of the solution.

++ Some requirements that could be added
We could add a requirement for the solution to support a means of describing the role of streams (e.g. whether a media stream corresponds to a speaker image or to presentation slides).

The REQMT-9 deals with interoperability of endpoints having different capabilities (e.g. resolution, CPU, ..), but there is no requirement for a means of supporting this interoperability. This is especially true for multipoint sessions with endpoints having different capabilities (e.g. not the same resolution capability). We could add a requirement for the solution to support a means of describing multiple simultaneous identical streams with different resolutions (e.g. high and low resolution). Note that without such requirement, the solution would implicitly to have a media transcoding on the MCU to adapt a stream to the capability of each endpoint.

As already mentioned by Roni, a requirement on interoperability with legacy endpoints should be added. 

We could add a requirement to support a mechanism allowing correlation between several endpoints, to allow spatial arrangement (as required in REQMT-1 to 3) among several endpoints. Note that it does not intend to replace the solution of multi-stream endpoints, but to add a solution to make multi-stream with several endpoints as an alternative.

++ About wording .
We can see "endpoints" and "telepresence endpoints" in the document (especially between REQMT-9 and REQMT-10). We should always use the same term, else we could think that "endpoint" could designate "legacy endpoint" (in contrast to the explicit term "telepresence endpoint"). IMHO I prefer "telepresence endpoint" wording, more explicit.

The document deals sometime with "audio" and "video", and sometime with the generic word "media". Unless explicitly needed, we should always use the generic term.

Regards,
Stéphane Cazeaux
Orange Labs

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Wed, 11 May 2011 19:47:55 -0700

Greetings,
Thanks for your comments, please see inline

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, May 11, 2011 7:09 AM
> To: [email-masked]
> Subject: [clue] Comments on draft-romanow-clue-telepresence-
> requirements-02
> 
> Hi,
> 
> The definition of the middlebox is confusing. In certain cases, a
> middle box could be initiator/terminator (of media and signaling), for
> instance when a multipoint telepresence session is initiated by a MCU,
> and the MCU sends media to the endpoints (kind of "waiting room") until
> all participants have joined. We could think that in such cases, the
> MCU acts an endpoint, but this not very satisfying since endpoint as
> defined in the document seems to be a physical entity rather than a
> function or a role.

Could you suggest text that will address your concern? Would you be satisfied if we take out the word middle box and just use MCU, which presumably is a well-understood term?
 
> 
> The document shall be more explicit on the list of stream/endpoint
> characteristics that the solution shall be able to signal.  This would
> help to further work on all requirements dealing with these
> characteristics, and in particularly for the discussion on requirements
> 4 and 7.

I think it would be inappropriate to list stream/endpoint characteristics in the requirements. I feel that more specification is part of the solution and that it would constrain the solution to describe which characteristics within the requirements.
> 
> Is there a rationale of having removed a part of the REQMT-11
> (previously the REQMT-09 in version 01)? Talking here of the
> requirement that allowed a remote to make the placement for the local.

REQMT-9: CLUE must support different models of where layout decisions are made - local and remote.
* Local does the placement
	+ Remote tells local what streams it has (content type, anything else?? What exactly? [to be
	filled in]
	+ Local tells the remote which streams it wants
* Remote does the placement
	+ Local tells the remote what its displays are, what its receive positions are, how many 	streams it can receive
	+ Remote specifies the placement for the local 

Changed to

The solution MUST support a layout model in which the local telepresence system does the layout
* Remote tells local properties of available captured/coded media (such as: max video resolutions, spatial placements of capture devices, capabilities of codecs, inter-codec dependencies,...)
* Local, based on its knowledge of rendering systems, tells the remote which streams it wants

After considering this in some detail, a number of people felt it was better to have the local do the placement and no one supported having remote do the placement, so it was removed.

> 
> The lip sync should be added as a requirement to the solution.
> Actually, I don't see why it should not be part of the solution.

It is good to know your opinion. As there are some people who favor including it, and others who feel it is implementation specific and not a requirement. This will have to be resolved. It will be discussed during the interim meeting tomorrow.

> We could add a requirement for the solution to support a means of
> describing the role of streams (e.g. whether a media stream corresponds
> to a speaker image or to presentation slides).

Yes, this is information that it would be good to send - I think this is covered in Reqmt 4. 
> 
> The REQMT-9 deals with interoperability of endpoints having different
> capabilities (e.g. resolution, CPU, ..), but there is no requirement
> for a means of supporting this interoperability. This is especially
> true for multipoint sessions with endpoints having different
> capabilities (e.g. not the same resolution capability). We could add a
> requirement for the solution to support a means of describing multiple
> simultaneous identical streams with different resolutions (e.g. high
> and low resolution). Note that without such requirement, the solution
> would implicitly to have a media transcoding on the MCU to adapt a
> stream to the capability of each endpoint.
> 

This is contrary to the charter, as per my note to you and Roni. It can be discussed during interim meeting
> 
> We could add a requirement to support a mechanism allowing correlation
> between several endpoints, to allow spatial arrangement (as required in
> REQMT-1 to 3) among several endpoints. Note that it does not intend to
> replace the solution of multi-stream endpoints, but to add a solution
> to make multi-stream with several endpoints as an alternative.

I'm sorry, I don't quite understand this suggestion. 

> 
> ++ About wording .
> We can see "endpoints" and "telepresence endpoints" in the document
> (especially between REQMT-9 and REQMT-10). We should always use the
> same term, else we could think that "endpoint" could designate "legacy
> endpoint" (in contrast to the explicit term "telepresence endpoint").
> IMHO I prefer "telepresence endpoint" wording, more explicit.

Okay, I see your point. But I would suggest changing 9 to say "endpoints" since this and the Layout definition are the only two places where "telepresence endpoint" is used. Are you okay with this?

> 
> The document deals sometime with "audio" and "video", and sometime with
> the generic word "media". Unless explicitly needed, we should always
> use the generic term.
> 
Okay

Regards,
Allyn
> 
> Regards,
> Stéphane Cazeaux
> Orange Labs
> 
> 
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

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

> > to a speaker image or to presentation slides).
[JRE] I am concerned about adding requirements for which we appear to have solutions already, unless those solutions are inappropriate or need to be extended for use in a telepresence environment. In this particular case, we already have the SDP a=content attribute (RFC 4796), so it is unclear to me what else we would need.

> think this is covered in Reqmt 4. 
[JRE] REQMT-4 is very vague (as I think has been mentioned before), so it probably needs to be tightened up. However, the role of streams is something I think we already have a solution for, so does not need to be mentioned in a reworded REQMT-4.

John

---

From: <[email-masked]>
Date: Thu, 12 May 2011 08:40:10 +0000

Hi,

Some answers inline.

Regards,
Stephane.

-----Message d'origine-----
De : Allyn Romanow (allyn) [mailto:[email-masked]] 
Envoyé : jeudi 12 mai 2011 04:48
À : CAZEAUX Stephane RD-BIZZ-CAE; [email-masked]
Objet : RE: [clue] Comments on draft-romanow-clue-telepresence-requirements-02

Greetings,

[SC] I suggest removing the sentence "In contrast to an endpoint [...] nor the final terminator". 

[SC] My concern here is that without a list, we cannot figure out if all requirements are consistent, or if the later solution will fulfil all requirements. 

Changed to

[SC] When the remote is a MCU, it makes sense that remote does the placement, especially for multipoint sessions with segment switching and/or video mixing policies (e.g. in segment switching policy, the MCU does places on the same screen - the left one for instance - for all endpoints so that participants will all look in the same direction). 

[SC] My suggestion is to have a mean to setup kind of "virtual" endpoint made of several endpoints. Note that this suggestion is obviously limited to multipoint sessions with a MCU that will treat this correlation, and then consider correlated endpoints as if they were devices of a same endpoint.
Such configurations will be feasible, but with proprietary implementations (e.g. static configuration in MCU to declare correlated endpoints). Having a standard mean would be nice.

[SC] OK.

Okay

Regards,
Allyn

---

From: <[email-masked]>
Date: Thu, 12 May 2011 13:55:21 +0200

Are we sure that the values currently defined in RFC4796 are sufficient to cover all TP scenarios? If, not we may have to issue an RFC to create new values as I noticed that the registration policy for new values is 'Specification Required'.

We may indeed conclude that some of the requirements are already fulfilled and do not require further standardization work but I don't see this as a problem.

BC

> De : [email-masked] [mailto:[email-masked]] De la part de
> Elwell, John
> Envoyé : jeudi 12 mai 2011 10:00
> À : Allyn Romanow (allyn); CAZEAUX Stephane RD-BIZZ-CAE; [email-masked]
> Objet : Re: [clue] Commentson draft-romanow-clue-telepresence-
> requirements-02
> 
> [JRE] I am concerned about adding requirements for which we appear to
> have solutions already, unless those solutions are inappropriate or
> need to be extended for use in a telepresence environment. In this
> particular case, we already have the SDP a=content attribute (RFC 4796),
> so it is unclear to me what else we would need.
> 
> >
> [JRE] REQMT-4 is very vague (as I think has been mentioned before), so
> it probably needs to be tightened up. However, the role of streams is
> something I think we already have a solution for, so does not need to
> be mentioned in a reworded REQMT-4.
> 
> John

---

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

Bruno,

No, I am not sure the values already standardized are sufficient, but I am trying to tease out whether the requirement is about RFC 4796 or something else entirely. Also, if it is about RFC 4796, whether there is some telepresence-specific requirement that might give rise to the need for more standardized values. Although the proposed requirement does little harm, there is little point in overloading the list of requirements with irrelevances.

John

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: 12 May 2011 12:55
> To: Elwell, John; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: [clue] Commentson 
> draft-romanow-clue-telepresence-requirements-02
> 
> Are we sure that the values currently defined in RFC4796 are 
> sufficient to cover all TP scenarios? If, not we may have to 
> issue an RFC to create new values as I noticed that the 
> registration policy for new values is 'Specification Required'.
> 
> We may indeed conclude that some of the requirements are 
> already fulfilled and do not require further standardization 
> work but I don't see this as a problem.
> 
> BC
> 
> 
> 
>

---

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

Please see inline.

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
> Sent: Thursday, May 12, 2011 1:00 AM
> To: Allyn Romanow (allyn); [email-masked];
[email-masked]
> Subject: Re: [clue] Commentson
> [JRE] I am concerned about adding requirements for which we appear to
have solutions already, unless
> those solutions are inappropriate or need to be extended for use in a
telepresence environment. In
> this particular case, we already have the SDP a=content attribute (RFC
4796), so it is unclear to me
> what else we would need.

That is true, and I think that is an important thing to keep in mind for
the solution. The requirement seems valid to me, and hopefully we
ultimately meet the requirement by using RFC 4796.

Cheers,
Charles

> [JRE] REQMT-4 is very vague (as I think has been mentioned before), so
it probably needs to be
> tightened up. However, the role of streams is something I think we
already have a solution for, so
> does not need to be mentioned in a reworded REQMT-4.
> 
> John

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 12 May 2011 18:16:04 +0200

> From: Charles Eckel (eckelcu) [mailto:[email-masked]] 
> Sent: 12 May 2011 17:12
> To: Elwell, John; Allyn Romanow (allyn); 
[JRE] This seems reasonable to me - if we think there is a chance we might want something different from or an extension of RFC 4796, it does no harm to have the requirement.

John

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 12 May 2011 17:01:52 -0700

Hi John and all,
A similar thing came up during the interim today.. whether requirements are supposed to only be about functionality that is not already included in existing IETF protocols?

I guess this is the difference between a user group trying to solve a problem and experts in RAI intimately aware of all the problems that have already been solved and the mechanisms available for implementing functionality.

I am concerned that if you consider requirements in light of what can and cannot be accomplished with the usual RAI protocols, that you are in danger of not focusing on the problem and overly constraining the solution prematurely. I think that we must of course consider how to implement the solution (when we have it) with existing RAI standards.

But, you may see it differently?

Thanks,
Allyn

.

> From: Elwell, John [mailto:[email-masked]]
> Sent: Thursday, May 12, 2011 5:37 AM
> To: [email-masked]; Allyn Romanow (allyn);
> Subject: RE: [clue] Commentsondraft-romanow-clue-telepresence-
> requirements-02
> 
> Bruno,
> 
> No, I am not sure the values already standardized are sufficient, but I
> am trying to tease out whether the requirement is about RFC 4796 or
> something else entirely. Also, if it is about RFC 4796, whether there
> is some telepresence-specific requirement that might give rise to the
> need for more standardized values. Although the proposed requirement
> does little harm, there is little point in overloading the list of
> requirements with irrelevances.
> 
> John
> 
>

---

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

Allyn,

I have already indicated (in response to Charles) that I don't object to adding this particular requirement. Of course, you have to draw the line somewhere, and avoid flooding the document with lots of requirements that are already met by existing protocols, thereby masking the "real" requirements. If there is some doubt as to whether this requirement is already sufficiently met, I am happy to include it. Part of the reason for my original comment was to tease out what the proposer really meant, and whether it is indeed similar to what is addressed by RFC 4796.

John 

> From: Allyn Romanow (allyn) [mailto:[email-masked]] 
> Sent: 13 May 2011 01:02
> To: Elwell, John; [email-masked]; 
> Subject: the nature of requirements
> 
> Hi John and all,
> A similar thing came up during the interim today.. whether 
> requirements are supposed to only be about functionality that 
> is not already included in existing IETF protocols?
> 
> I guess this is the difference between a user group trying to 
> solve a problem and experts in RAI intimately aware of all 
> the problems that have already been solved and the mechanisms 
> available for implementing functionality.
> 
> I am concerned that if you consider requirements in light of 
> what can and cannot be accomplished with the usual RAI 
> protocols, that you are in danger of not focusing on the 
> problem and overly constraining the solution prematurely. I 
> think that we must of course consider how to implement the 
> solution (when we have it) with existing RAI standards.
>