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

From: Mary Barnes <[email-masked]>
Date: Wed, 1 Aug 2012 12:48:24 -0500

(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 <
[email-masked]> 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: [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
>>
>> 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:[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:internet-drafts@ietf.**org<[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-c<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<http://datatracker.ietf.org/doc/draft-xiao-clue-telemedical-use-case>
>>>> Htmlized:
>>>> http://tools.ietf.org/html/**draft-xiao-clue-telemedical-**use-case-00<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<https://www.ietf.org/mailman/listinfo/clue>
>>>> ______________________________**_________________
>>>> clue mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>
>>>>  ______________________________**_________________
>>> clue mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>
>>>  ______________________________**_________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>
>>
> ______________________________**_________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: Christian Groves <[email-masked]>
Date: Wed, 08 Aug 2012 15:44:39 +1000

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:
> 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 
> <[email-masked] <mailto:[email-masked]>> 
> 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
>
>
>         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
>
>
>         From: [email-masked] <mailto:[email-masked]>
>         [mailto:[email-masked] <mailto:[email-masked]>]
>         On Behalf Of Christian Groves
>         To: [email-masked] <mailto:[email-masked]>
>         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
>                 From: Espen Berger (espeberg)
>                 [mailto:[email-masked] <mailto:[email-masked]>]
>                 To: Xiaojing; [email-masked] <mailto:[email-masked]>
>                 draft-xiao-clue-telemedical-use-case-00.txt
>
>                 From: [email-masked]
>                 <mailto:[email-masked]>
>                 [mailto:[email-masked]
>                 <mailto:[email-masked]>] On Behalf
>                 Of Xiaojing
>                 To: [email-masked] <mailto:[email-masked]>
>                 draft-xiao-clue-telemedical-use-case-00.txt
>
>                 Hi all,
>
>                 From: [email-masked]
>                 <mailto:[email-masked]>
>                 [mailto:[email-masked]
>                 <mailto:[email-masked]>]
>                 draft-xiao-clue-telemedical-use-case-00.txt
>
>
>                 A new version of I-D,
>                 draft-xiao-clue-telemedical-use-case-00.txt
>                 Filename:     draft-xiao-clue-telemedical-use-case
>                 Revision:     00
>                 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:
>                      presentation streams are used for conveying
>                 different information in
>                 _______________________________________________
>                 clue mailing list
>                 [email-masked] <mailto:[email-masked]>
>                 https://www.ietf.org/mailman/listinfo/clue
>                 _______________________________________________
>                 clue mailing list
>                 [email-masked] <mailto:[email-masked]>
>                 https://www.ietf.org/mailman/listinfo/clue
>
>             _______________________________________________
>             clue mailing list
>             [email-masked] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/listinfo/clue
>
>         _______________________________________________
>         clue mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/clue
>
>
>     _______________________________________________
>     clue mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/clue
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Aug 2012 07:12:55 -0700

> that XCON will handle these things.

I'm not sure I understand this.

ISTM that the initial INVITE to set up a CLUE call could contain an 
offer of:
- an initial audio and video stream
- a CLUE protocol stream
- a bfcp stream
- indication of support for the conf event package

As soon as the initial answer is sent, if not sooner, the CLUE stream 
and the bfcp stream can be opened, and a subscribe sent for the conf 
event package. Shortly thereafter, CLUE advertisements can be sent in 
both directions and a first notification for the conf event package can 
be sent.

Then, both the advertisement and the conf event state can be used for 
constructing the CLUE configuration message.

Maybe we should create an enhanced call flow that shows all of that.

	Thanks,
	Paul

>> protocols to establish the basic session - that would include using
>> basic SIP conferencing and could include the use of XCON.
>>
>> Mary.
>>

---

From: Christian Groves <[email-masked]>
Date: Thu, 09 Aug 2012 11:09:48 +1000

Hello Paul,

I think those enhanced call flows are necessary. I think we need to 
understand how the XCON concepts will map to those we've created in 
CLUE. I agree an initial invite can establish a CLUE and BFCP stream and 
conference event package but there are dependencies between the data 
that will be sent across them, i.e. an end point will use some data from 
one protocol to send data in another, i.e. the media information in XCON 
would be dependent on what captures were agreed via CLUE. So whilst they 
can be established at the same time there is actually some sequencing 
needed. AFAIK currently in XCON there is no concept of captures, so no 
ability to describe them.

So coming back to the example to the issue below. If we believe that for 
a description of the endpoint that XCON should be used rather than our 
CLUE description "Attribute" we should state this in the CLUE framework 
draft as an aid to interoperability (although I'm not sure how labelling 
in multiple languages would work?), do we use <users><display-text> or 
<conference-description><display-text> or?

Regards, Christian

On 9/08/2012 12:12 AM, Paul Kyzivat wrote:
> both directions and a first notification for the conf event package 
> can be sent.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Aug 2012 14:10:49 -0700

On 8/8/12 6:09 PM, Christian Groves wrote:
> Hello Paul,
>
> I think those enhanced call flows are necessary.

What do others think? Shall we ask that the call flows (at least some of 
them) include conference event package subscription and notifications 
and bfcp setup and signaling?

I agree that this may be necessary - probably not in every call flow, 
but in cases where the use of those channels is necessary for the use 
case to work. And how often that is depends on how much information we 
defer to those protocols for.

> I think we need to

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Mon, 27 Aug 2012 13:35:28 -0500

No one has responded, so I will chime in.  We will need a detailed call
flow document that shows how the CLUE use cases are realized.  It would be
very useful to have one or two flows that show the SIP details as well as
other protocols that might be involved.  For XCON, we included a flow of
how XCON interacts with the MEDIACTRL protocols in the detailed call flow
document (RFC 6504).  We only did this at the beginning and not for each
and every call flow.

Calls flows are terribly tedious, but they are extremely helpful when folks
are trying to understand the protocol and they are an excellent way to
sanity check things and find gaps, so I don't think we can get away with
not doing them.   I personally think it would add *alot* of value to have
some high level call flows (similar to what Rob did for the tutorial) in
the framework document.  We did this for XCON for the majority of the use
cases (per RFC 5239).  Note, that we had textual descriptions of what
happened at each stage. In CLUE, we have had snippets of these in the
various presentations but I would love someone to step forward and do
these.  These then feed very naturally into the detailed call flow document
that has all the protocol details.

Mary.

On Thu, Aug 9, 2012 at 4:10 PM, Paul Kyzivat <[email-masked]> wrote:

> them) include conference event package subscription and notifications and
> bfcp setup and signaling?
>
> I agree that this may be necessary - probably not in every call flow, but
> in cases where the use of those channels is necessary for the use case to
> work. And how often that is depends on how much information we defer to
> those protocols for.
>
>
>  I think we need to
>> <conference-description><**display-text> or?
>>
>> Regards, Christian
>>
>
>         Thanks,
>         Paul
>
>
>>>>> <[email-masked] <mailto:Christian.Groves@**nteczone.com<[email-masked]>
>>>>> >>
>>>>> wrote:
>>>>>
>>>>> Hello Espen,
>>>>>
>>>>> [mailto:[email-masked] <mailto:[email-masked]>**]
>>>>> <mailto:[email-masked]>**] On Behalf
>>>>> Of Xiaojing
>>>>> <mailto:internet-drafts@ietf.**org <[email-masked]>>
>>>>> [mailto:internet-drafts@ietf.**org <[email-masked]>
>>>>> <mailto:internet-drafts@ietf.**org <[email-masked]>>]