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

From: [email-masked]
Date: Tue, 31 Jul 2012 09:34:12 +0800

Hi there,

Some comments about the telemedical use case as below：
1. Transmission of the multiple presentation streams
1.1. To transmit the multiple presentation streams assembly
To use some medical data collection system to collect the multiple medical 
data and organize them into one presentation stream like ppt for 
transmission.
In this method the remote site can only receive the presentation stream 
without any modification.
But this method can just use the protocols already existed without any 
extra modification.
1.2.  To transmit the multiple presentation streams separately
To transmit the multiple presentation streams separately without any 
combination.
In this method the local site and remote site can choose the presentation 
streams or change the display structure as they wish.

2. Description of the multiple presentation streams
None description is needed in transmission method mentioned in 1.1 above. 
In method in 1.2 we need some method to describe  the presentation stream 
type.
2.1. In this method we can use the different sessions with different ports 
to distinguish the multiple presentation streams. But this needs two sites 
consult the ports firstly.
2.2. Or we can add new value definition to the already existed field like 
content or add new field to describe the presentation type attribute like 
X-Ray.

3. The scenario mentioned in the draft
        The scenario mentioned in this telemedical draft illustrates the 
usage of the telepresence during the urgent medical service like surgical 
operation combined with the imitate education. 
        There are still some common medical services such as physical 
examination or diagnosis should be considered for these are more usual.
        FYI I have wrote something about the common medical usage please 
refer below. 
 
The second usage that the telepresence system could be used in the medical 
service is the common medical service. 
In this user case, the local site in figure 9 could be the diagnosis site 
where the assistant can make a check for the patient using some medical 
data collection equipments such as blood pressure monitor, blood sugar 
measuring instrument, MRI or endoscope, etc. The medical data collected by 
these medical equipments can be created into different presentation 
streams using different methods like using the document camera to capture 
these medical data or using a PC or touch control panel to record these 
data. After that the telepresence system may use the PC or touch control 
panel to control the display of the presentation streams. Some 
presentations screens are in the local site to show the presentation 
steams created in local and/or remote site. Main screen and camera set(s) 
in the diagnosis site show the experts from the same or different remote 
site. 
The remote site is where the experts could diagnose the patient according 
to the medical data showed by the presentation streams. There are one or 
more main screen and camera sets in the expert site. One of the main 
screens may display the view of the diagnosis site and the others can show 
the views from the other expert site. The presentation screen(s) exist in 
the remote site to show the medical data in some display structure 
organized by the multiple presentation streams. The touch control panel 
can be used to control the display structure about the presentation 
steams. The document camera may be existed in the remote site to create 
the remote presentation steams. 

Thank you and BRs

[email-masked] 
发件人:  [email-masked]
2012-07-26 21:43
请答复 给
[email-masked]

收件人
[email-masked]
抄送

主题
clue Digest, Vol 20, Issue 40

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/clue

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send clue mailing list submissions to
                 [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
                 https://www.ietf.org/mailman/listinfo/clue
or, via email, send a message with subject or body 'help' to
                 [email-masked]

You can reach the person managing the list at
                 [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of clue digest..."
Today's Topics:

   1. Re: Design Team meeting - July 24th, 2012 (Mary Barnes)
   2. Re: FW: New Version                Notification            for
      draft-xiao-clue-telemedical-use-case-00.txt (Xiaojing)
   3. Re: Can we close Ticket #9 axis of capture? (Duckworth, Mark)
   4. Re: FW: New Version                Notification            for
      draft-xiao-clue-telemedical-use-case-00.txt (Paul Kyzivat)
   5. Re: Can we close Ticket #9 axis of capture? (Paul Kyzivat)

-----来自 Mary Barnes <[email-masked]> 的消息，在 Wed, 25 Jul 
2012 16:04:03 -0500 -----
收件人:
Paul Kyzivat <[email-masked]>
抄送:
[email-masked]
主题:
Re: [clue] Design Team meeting - July 24th, 2012
I think it would be a good idea if we could do a dry run - we wouldn't 
need to run through all the charts just practice how we'll do handoffs 
between presentations so things will go smoothly.  I have setup a doodle - 
the only times I possibly have are Sunday morning or Monday morning:
http://doodle.com/vqffmgkgptscq3bp

Mary. 

On Mon, Jul 23, 2012 at 5:46 PM, Paul Kyzivat <[email-masked]> 
wrote:
On 7/23/12 5:40 PM, Mary Barnes wrote:

It was mentioned on one of the calls that we should try to run through
the material live in Vancouver. I'm not sure how feasible that is. For
me, Sunday morning or Monday morning (before main CLUE meeting) are the
only time options that I have.  Monday morning is likely more feasible
as the secretariat would already have projectors in rooms and we could
just use the room where we will have the CLUE WG session.  That's not
ideal for me as I have to chair the DISPATCH WG meeting during the last
session and have the IAB plenary that night.

It was "wishful thinking" on my part, while realizing it might not be 
feasible.

What I was thinking of was after the social sunday night. But I already 
have a conflict then, though I could probably break it if need be.

We had better make the run through tomorrow be a good one!

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

-----来自 Xiaojing <[email-masked]> 的消息，在 Thu, 26 Jul 2012 
06:51:37 +0000 -----
收件人:
"Espen Berger (espeberg)" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题:
Re: [clue] FW: New Version Notification for 
draft-xiao-clue-telemedical-use-case-00.txt
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

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. 

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,

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
_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue

-----来自 "Duckworth, Mark" <[email-masked]> 的消息，在 Thu, 
26 Jul 2012 05:21:05 -0700 -----
收件人:
"[email-masked]" <[email-masked]>
主题:
Re: [clue] Can we close Ticket #9 axis of capture?
Hi Christian,

Your proposal seems reasonable to me, it seems to be a bit more clear and 
exact than the current text.
I'd like to see more people express support for this change before I add 
it to the framework.  Does anybody else agree with this change?

Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christian Groves
> Sent: Tuesday, July 24, 2012 9:28 PM
> To: [email-masked]
> Subject: Re: [clue] Can we close Ticket #9 axis of capture?
> 
> Hello Mark,
> 
> I don't know if there was no consensus there just didn't appear to any
> conclusion. There appeared to be the following points:
> - I think both John and I found the name confusing
> - There was also discussion regards to the placement of the second 
point, i.e.
> that it should lie between the point of capture and the area of capture.
> - John had a point about the action if the attribute is included in 
error.
> - Paul proposed possibly making a single attribute with two values.
> 
> So taking into above what I would propose would be:
> 
> Point on line of capture: {(X,Y,Z)}
> 
> A field with a single Cartesian (X, Y, Z) point value (virtual or
> physical) which describes a position in space of a second point on the 
optical axis
> of the capturing device; the first point being the Point of Capture (see 
above).
> This point MUST lie between the Point of Capture and the Area area of 
capture.
> 
> The Point on Line of Capture MUST be ignored if the Point of Capture is 
not
> present for this capture device.  When the Point on Line of Capture 
attribute is
> specified, it must include X, Y and Z coordinates.  These coordinates 
MUST NOT
> be identical to the Point of Capture coordinates.
> If the Point on Line of Capture is not specified, no assumptions are 
made about
> the optical axis of the capturing device.
> 
> John or Paul may have something to add/modify.
> 
> Regards, Christian
> 
> On 24/07/2012 10:50 PM, Duckworth, Mark wrote:
> >
> > We recently added an attribute in the framework to address Ticket #9
> > Axis of capture description
> > <http://trac.tools.ietf.org/wg/clue/trac/ticket/9>.  There were some
> > suggestions and discussion on the email list about changing some
> > details of the text.  But it seems there was no consensus to change
> > anything.  So can we close this ticket and keep the text as is?
> > Personally, that is my preference.
> >
> > Mark
> >
> >
> >
> > _______________________________________________
> > clue mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/clue
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

-----来自 Paul Kyzivat <[email-masked]> 的消息，在 Thu, 26 Jul 2012 
09:28:32 -0400 -----
收件人:
[email-masked]
主题:
Re: [clue] FW: New Version Notification for 
draft-xiao-clue-telemedical-use-case-00.txt
[as individual]

On 7/26/12 2:51 AM, Xiaojing wrote:
> 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
>
> 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.

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.

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

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
>
>
> -----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,
>
> 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
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

-----来自 Paul Kyzivat <[email-masked]> 的消息，在 Thu, 26 Jul 2012 
09:43:28 -0400 -----
收件人:
[email-masked]
主题:
Re: [clue] Can we close Ticket #9 axis of capture?
On 7/26/12 8:21 AM, Duckworth, Mark wrote:
> Hi Christian,
>
> Your proposal seems reasonable to me, it seems to be a bit more clear 
and exact than the current text.
> I'd like to see more people express support for this change before I add 
it to the framework.  Does anybody else agree with this change?

WFM

                 Thanks,
                 Paul

> Mark
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Christian Groves
>> Sent: Tuesday, July 24, 2012 9:28 PM
>> To: [email-masked]
>> Subject: Re: [clue] Can we close Ticket #9 axis of capture?
>>
>> Hello Mark,
>>
>> I don't know if there was no consensus there just didn't appear to any
>> conclusion. There appeared to be the following points:
>> - I think both John and I found the name confusing
>> - There was also discussion regards to the placement of the second 
point, i.e.
>> that it should lie between the point of capture and the area of 
capture.
>> - John had a point about the action if the attribute is included in 
error.
>> - Paul proposed possibly making a single attribute with two values.
>>
>> So taking into above what I would propose would be:
>>
>> Point on line of capture: {(X,Y,Z)}
>>
>> A field with a single Cartesian (X, Y, Z) point value (virtual or
>> physical) which describes a position in space of a second point on the 
optical axis
>> of the capturing device; the first point being the Point of Capture 
(see above).
>> This point MUST lie between the Point of Capture and the Area area of 
capture.
>>
>> The Point on Line of Capture MUST be ignored if the Point of Capture is 
not
>> present for this capture device.  When the Point on Line of Capture 
attribute is
>> specified, it must include X, Y and Z coordinates.  These coordinates 
MUST NOT
>> be identical to the Point of Capture coordinates.
>> If the Point on Line of Capture is not specified, no assumptions are 
made about
>> the optical axis of the capturing device.
>>
>> John or Paul may have something to add/modify.
>>
>> Regards, Christian
>>
>> On 24/07/2012 10:50 PM, Duckworth, Mark wrote:
>>>
>>> We recently added an attribute in the framework to address Ticket #9
>>> Axis of capture description
>>> <http://trac.tools.ietf.org/wg/clue/trac/ticket/9>.  There were some
>>> suggestions and discussion on the email list about changing some
>>> details of the text.  But it seems there was no consensus to change
>>> anything.  So can we close this ticket and keep the text as is?
>>> Personally, that is my preference.
>>>
>>> Mark
>>>
>>>
>>>
>>> _______________________________________________
>>> clue mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> _______________________________________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/clue
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.