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

[Simon Pietro Romano <[e-mail]>]

Hi Mary,

I'll be glad to contribute to this work. 
Simon

Mary Barnes <[e-mail]> ha scritto:

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 <[e-mail]> wrote:

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


        Thanks,
        Paul



On 9/08/2012 12:12 AM, Paul Kyzivat wrote:

On 8/7/12 10:44 PM, Christian Groves wrote:

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.


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

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



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


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


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


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