Subject: [clue] FW: New Version Notification for draft-xiao-clue-telemedical-use-case-00.txt

From: Xiaojing <[email-masked]>
Date: Wed, 25 Jul 2012 02:40:17 +0000

Hi all,

I've submitted a telemedical use case, which addresses the use of Telepresence into medical scenarios.

I think this use case is valid to add another application field where Telepresence can be used.
So I'd like to suggest adding this use case into the current use case document.

Also, along with this use case, some new requirements might come up, e.g. the requirement to support multiple presentation streams, which might be considered into the requirement draft.

Best regards,
Lennard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 09, 2012 11:13 AM
To: Xiaojing
Cc: Roni even
Subject: New Version Notification for draft-xiao-clue-telemedical-use-case-00.txt

A new version of I-D, draft-xiao-clue-telemedical-use-case-00.txt
has been successfully submitted by Lennard Xiao and posted to the
IETF repository.

Filename:	 draft-xiao-clue-telemedical-use-case
Revision:	 00
Title:		 Use Case for Telemedical with Multi-streams
Creation date:	 2012-07-06
WG ID:		 Individual Submission
Number of pages: 5
URL:             http://www.ietf.org/internet-drafts/draft-xiao-clue-telemedical-use-case-00.txt
Status:          http://datatracker.ietf.org/doc/draft-xiao-clue-telemedical-use-case
Htmlized:        http://tools.ietf.org/html/draft-xiao-clue-telemedical-use-case-00

Abstract:
   This memo presenst a telemedicine use case where multiple
   presentation streams are used for conveying different information in
   parallel to the main video from the surgery room

The IETF Secretariat

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Wed, 25 Jul 2012 15:18:31 +0000

Thanks for sharing the use case. I had a similar use case in mind, advanced lecture type calls mainly focusing on P2P with multiple presentation streams.  

My assumption for an advanced use case like this is each capture has at least a description field, e.g. 'x-ray' or  'CT-scan', that can be used by a manual operator to start and stop what to receive. This use case explains why we need descriptions for both capture-scenes and captures. 

Questions
* Do you assume manual or automatic selection of presentation streams? 
* How do you decide which presentation streams are important? What if you offer three presentation streams and I can only receive one, how do I decide which of them to receive? 
* Have you identified additional meta-information to the CLUE framework needed to describe the information you have in mind writing up the use case. 

Regards 

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiaojing
Sent: 25. juli 2012 04:40
To: [email-masked]
Subject: [clue] FW: New Version Notification for draft-xiao-clue-telemedical-use-case-00.txt

Hi all,

Best regards,
Lennard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 09, 2012 11:13 AM
To: Xiaojing
Cc: Roni even
Subject: New Version Notification for draft-xiao-clue-telemedical-use-case-00.txt

Abstract:

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

---

From: Xiaojing <[email-masked]>
Date: Thu, 26 Jul 2012 06:51:37 +0000

Hi Espen,

Please see my response inline.

Regards,
Lennard

-----Original Message-----
From: Espen Berger (espeberg) [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2012 11:19 PM
To: Xiaojing; [email-masked]
Subject: RE: [clue] FW: New Version Notification for draft-xiao-clue-telemedical-use-case-00.txt

[Xiao Jing] I share the same thinking on the description field with you. The different presentations need to be identified from each other. A straightforward way is to add description tags to them. 

Questions
* Do you assume manual or automatic selection of presentation streams? 
[Xiao Jing] In my initial thinking, in the use case it is the surgeon and endpoint users who decide which presentation streams to be sent and displayed. Thus it is necessary to identify the presentations.
* How do you decide which presentation streams are important? What if you offer three presentation streams and I can only receive one, how do I decide which of them to receive? 
[Xiao Jing] I assume that the users can differentiate the streams and then decide which to receive. In this case, if the user knows exactly what the stream is about, he can decide without additional information from the provider. But I also think we can introduced kind of priority concept into it. The "content" attribute could be a good place to include this idea. In my memory, Christian and Paul are working on this issue, and I'll try to inform them to take this into consideration. 
* Have you identified additional meta-information to the CLUE framework needed to describe the information you have in mind writing up the use case. 
[Xiao Jing] In this early stage, I'm just trying to draw concern about the necessity of having multiple presentation streams. I think the current framework can cover all the new requirements coming up with this use case at ease. 

Regards 

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xiaojing
Sent: 25. juli 2012 04:40
To: [email-masked]
Subject: [clue] FW: New Version Notification for draft-xiao-clue-telemedical-use-case-00.txt

Hi all,

Best regards,
Lennard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 09, 2012 11:13 AM
To: Xiaojing
Cc: Roni even
Subject: New Version Notification for draft-xiao-clue-telemedical-use-case-00.txt

Abstract:

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2012 09:28:32 -0400

[as individual]

> [Xiao Jing] I share the same thinking on the description field with you. The different presentations need to be identified from each other. A straightforward way is to add description tags to them.

I think a textual description is the place to start.
It would be hard to start defining a machine-processable enumeration of 
application-specific categories.

We already have the proposal for such a mechanism.
This use case simply reinforces the need for that mechanism.

> [Xiao Jing] In this early stage, I'm just trying to draw concern about the necessity of having multiple presentation streams. I think the current framework can cover all the new requirements coming…

I'm not sure whether 'priority' has been brought up on this public list 
or not.

But it is my thought that we need a numeric priority value per capture, 
that can be used by the recipient when it doesn't have the resources to 
render even the smallest entry from each scene. *That* would provide a 
way for the receiving equipment to provide a default rendering. Some 
endpoints might also provide a gui for the end users to manually 
configure based on descriptions.

The numeric priority could be used to indicate that the presentation is 
more important than the speaker, or visa versa. And it can be used to 
indicate a relative priority among presentations. Etc.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 27 Jul 2012 14:41:47 +1000

Hello Paul,

I think have a enumeration for very specific capabilities woul dbe hard 
but I think there may be some common ones to many conferencing / 
telepresence scenarios. In the discussion of this topic I think that 
perhaps the "description" attribute we have today may be too broad. I 
was thinking it would be used for something like "Teleconference Room 2, 
Beijing" but it seems there's proposals to use this for functional level 
things like "speaker etc".

Regards, Christian

On 26/07/2012 11:28 PM, Paul Kyzivat wrote:
>> Subject: RE: [clue] FW: New Version Notification for 
>> draft-xiao-clue-telemedical-use-case-00.txt
>>
>> Thanks for sharing the use case. I had a similar use case in mind, 
>> advanced lecture type calls mainly focusing on P2P with multiple 
>> presentation streams.
>>
>> My assumption for an advanced use case like this is each capture has 
>> at least a description field, e.g. 'x-ray' or  'CT-scan', that can be 
>> used by a manual operator to start and stop what to receive. This use 
>> case explains why we need descriptions for both capture-scenes and 
>> captures.
>>
>> [Xiao Jing] I share the same thinking on the description field with 
>> you. The different presentations need to be identified from each 
>> other. A straightforward way is to add description tags to them.
>
> It would be hard to start defining a machine-processable enumeration 
> of application-specific categories.
>
>> [Xiao Jing] In my initial thinking, in the use case it is the surgeon 
>> and endpoint users who decide which presentation streams to be sent 
>> and displayed. Thus it is necessary to identify the presentations.
>> * How do you decide which presentation streams are important? What if 
>> you offer three presentation streams and I can only receive one, how 
>> do I decide which of them to receive?
>> [Xiao Jing] I assume that the users can differentiate the streams and 
>> then decide which to receive. In this case, if the user knows exactly 
>> what the stream is about, he can decide without additional 
>> information from the provider. But I also think we can introduced 
>> kind of priority concept into it. The "content" attribute could be a 
>> good place to include this idea. In my memory, Christian and Paul are 
>> working on this issue, and I'll try to inform them to take this into 
>> consideration.
>> * Have you identified additional meta-information to the CLUE 
>> framework needed to describe the information you have in mind writing 
>> up the use case.
>> [Xiao Jing] In this early stage, I'm just trying to draw concern 
>> about the necessity of having multiple presentation streams. I think 
>> the current framework can cover all the new requirements coming up 
>> with this use case at ease.
>
> I'm not sure whether 'priority' has been brought up on this public 
> list or not.
>
> But it is my thought that we need a numeric priority value per 
> capture, that can be used by the recipient when it doesn't have the 
> resources to render even the smallest entry from each scene. *That* 
> would provide a way for the receiving equipment to provide a default 
> rendering. Some endpoints might also provide a gui for the end users 
> to manually configure based on descriptions.
>
> The numeric priority could be used to indicate that the presentation 
> is more important than the speaker, or visa versa. And it can be used 
> to indicate a relative priority among presentations. Etc.
>
>     Thanks,
>     Paul
>
>> Regards
>>
>> -Espen
>>
>>
>> Subject: [clue] FW: New Version Notification for 
>> draft-xiao-clue-telemedical-use-case-00.txt
>>
>> Hi all,
>>
>> Also, along with this use case, some new requirements might come up, 
>> e.g. the requirement to support multiple presentation streams, which 
>> might be considered into the requirement draft.
>>
>> Best regards,
>> Lennard
>>
>> Subject: New Version Notification for 
>> draft-xiao-clue-telemedical-use-case-00.txt
>>
>>
>> URL: 
>> http://www.ietf.org/internet-drafts/draft-xiao-clue-telemedical-use-case-00.txt
>> Status: 
>> http://datatracker.ietf.org/doc/draft-xiao-clue-telemedical-use-case
>> Htmlized: 
>> http://tools.ietf.org/html/draft-xiao-clue-telemedical-use-case-00
>>
>>
>> Abstract:

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Jul 2012 09:30:36 -0400

[as individual]

On 7/27/12 12:41 AM, Christian Groves wrote:
> telepresence scenarios.

Well, the thinking behind reusing the 'content' attribute was that there 
is already an IANA registry defined for it, so that extensions for new 
values can be made.

But I think it would be hard to get agreement to add values for the 
various kinds of instrumentation in an operating room. :-)

> In the discussion of this topic I think that

I think there is a difference between descriptions of scenes and 
descriptions of individual captures within a scene.

For scenes, things like the following make sense to me:
- Teleconference Room 2, Beijing
- Presentations from Teleconference Room 2, Beijing
- Operating Room, General Hospital
- Instrumentation from Operating Room, General Hospital

For individual captures, things like the following make sense to me:

- Seats 1&2, Seats 3&4, Seats 5&6
- Shared Application
- Patient Full View
- Patient Close Up
- Surgeon
- Heart Monitor

I do see some difficulty in describing virtual scenes used for synthetic 
captures. There is general agreement that they should be in a different 
scene from the room they originate from, because they don't share the 
same coordinate space. But does every presentation capture have its own 
scene, or do they share?

Also, does the scene for presentations have an explicit relationship to 
the scene for a room? Sometimes I think they do, such as with the 
operating room instrumentation, that clearly originates from the same 
room even if it doesn't have the same coordinate space. In other cases, 
maybe not.

If we have a multi-site conference, there might be a single presentation 
'floor' that all the participants contend for. The content of the 
capture is switched - with the source determined by who has the floor. 
But maybe this is simply an artifact of a conference with an MCU. 
Presumably there is a virtual scene from the MCU containing 
switched/mixed captures, etc. representing the complete collection of 
rooms. And similarly there are then one or more scenes representing 
switched presentations.

For now the best I can see is to allow free text, and let some best 
practice develop.

	Thanks,
	Paul

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Mon, 30 Jul 2012 13:46:01 +0000

Hi Christian 

If a consumer want to learn about information that's on the level of " like "Teleconference Room 2, Beijing"  I think its natural to look into conference event package or XCON. 

In the medical case the description attribute will have values like "x-ray" or "CT-scan", "Operation", which is needed since other captures attributes will have the same values. 

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 27. juli 2012 06:42
To: [email-masked]
Subject: Re: [clue] FW: New Version Notification for draft-xiao-clue-telemedical-use-case-00.txt

Hello Paul,

I think have a enumeration for very specific capabilities woul dbe hard but I think there may be some common ones to many conferencing / telepresence scenarios. In the discussion of this topic I think that perhaps the "description" attribute we have today may be too broad. I was thinking it would be used for something like "Teleconference Room 2, Beijing" but it seems there's proposals to use this for functional level things like "speaker etc".

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Tue, 31 Jul 2012 13:24:30 +1000

Hello Espen,

The issue that I see is that the conference event package or XCON would 
come after the initial CLUE signalling. You may want to chose captures 
based on this high level information before XCON etc is established. 
However I think the main point is that we need to be a little more 
detailed when we describe the use of these fields if people are even now 
proposing different uses.

Regards, Christian

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Tue, 31 Jul 2012 11:31:38 +0000

Hi Christian

The usage of the description field was originally discussed for use cases when an endpoint provider can offer two or more capture sources with similar capabilities. For conferences scenarios the assumption is that CLUE needs to be used together with another protocol for getting information about who is in the conference and handling operations to a conference resource. XCON is a good candidate for this.  

I agree that there might be challenges with information arriving in different order and how to link CLUE and XCon information together. Another observation is that we have limited concrete examples where we try out CLUE concepts in parallel with existing IETF standards to see how they relates and can be used together. 

Cheers 

-Espen 

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: 31. juli 2012 05:24
To: Espen Berger (espeberg)
Cc: [email-masked]
Subject: Re: [clue] FW: New Version Notification for draft-xiao-clue-telemedical-use-case-00.txt

Hello Espen,

The issue that I see is that the conference event package or XCON would come after the initial CLUE signalling. You may want to chose captures based on this high level information before XCON etc is established. 
However I think the main point is that we need to be a little more detailed when we describe the use of these fields if people are even now proposing different uses.

Regards, Christian

On 30/07/2012 11:46 PM, Espen Berger (espeberg) wrote:
> Subject: Re: [clue] FW: New Version Notification for 
>>> at least a description field, e.g. 'x-ray' or  'CT-scan', that can 
>>> be used by a manual operator to start and stop what to receive. This 
>>> use case explains why we need descriptions for both capture-scenes 
>>> and captures.
>>>
>>> [Xiao Jing] In my initial thinking, in the use case it is the 
>>> surgeon and endpoint users who decide which presentation streams to 
>>> be sent and displayed. Thus it is necessary to identify the presentations.
>>> * How do you decide which presentation streams are important? What 
>>> if you offer three presentation streams and I can only receive one, 
>>> how do I decide which of them to receive?
>>> [Xiao Jing] I assume that the users can differentiate the streams 
>>> and then decide which to receive. In this case, if the user knows 
>>> exactly what the stream is about, he can decide without additional 
>>> good place to include this idea. In my memory, Christian and Paul 
>>> are working on this issue, and I'll try to inform them to take this 
>>> into consideration.
>>> framework needed to describe the information you have in mind 
>>> writing up the use case.
>>> http://www.ietf.org/internet-drafts/draft-xiao-clue-telemedical-use-
>>> c
>>> ase-00.txt
>>> Status: