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

[Christian Groves <[e-mail]>]

Hello Mary,

I guess the reason why is the same reason why the media streams will 
likely be set up after CLUE. There could be potentially a large possible 
set of captures/configurations that you want to narrow down before you 
start assigning resources to them. You want to have enough information 
associated with the captures so that an educated decision can be made 
about whether to accept/use one. I don't think its enough just to assume 
that XCON will handle these things.

Regards, Christian

On 2/08/2012 3:48 AM, Mary Barnes wrote:
> (As an individual)
>
> Why is it that you think XCON signaling with come after initial CLUE 
> signaling?  It is certainly possible to get an XCON notification 
> before doing any CLUE signaling.   CLUE will be reusing existing 
> signaling protocols to establish the basic session - that would 
> include using basic SIP conferencing and could include the use of XCON.
>
> Mary.
>
> On Mon, Jul 30, 2012 at 10:24 PM, Christian Groves 
> <[e-mail] <mailto:[e-mail]>> 
> wrote:
>
>     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:
>
>         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: [e-mail] <mailto:[e-mail]>
>         [mailto:[e-mail] <mailto:[e-mail]>]
>         On Behalf Of Christian Groves
>         Sent: 27. juli 2012 06:42
>         To: [e-mail] <mailto:[e-mail]>
>         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
>
>         On 26/07/2012 11:28 PM, Paul Kyzivat wrote:
>
>             [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:[e-mail] <mailto:[e-mail]>]
>                 Sent: Wednesday, July 25, 2012 11:19 PM
>                 To: Xiaojing; [e-mail] <mailto:[e-mail]>
>                 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: [e-mail]
>                 <mailto:[e-mail]>
>                 [mailto:[e-mail]
>                 <mailto:[e-mail]>] On Behalf
>                 Of Xiaojing
>                 Sent: 25. juli 2012 04:40
>                 To: [e-mail] <mailto:[e-mail]>
>                 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: [e-mail]
>                 <mailto:[e-mail]>
>                 [mailto:[e-mail]
>                 <mailto:[e-mail]>]
>                 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-c
>                 ase-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
>                 [e-mail] <mailto:[e-mail]>
>                 https://www.ietf.org/mailman/listinfo/clue
>                 _______________________________________________
>                 clue mailing list
>                 [e-mail] <mailto:[e-mail]>
>                 https://www.ietf.org/mailman/listinfo/clue
>
>             _______________________________________________
>             clue mailing list
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/clue
>
>         _______________________________________________
>         clue mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/clue
>
>
>     _______________________________________________
>     clue mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/clue
>
>