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

[Mary Barnes <[e-mail]>]

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:Christian.Groves@**nteczone.com<[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:internet-drafts@ietf.**org <[e-mail]>>
>>>>> [mailto:internet-drafts@ietf.**org <[e-mail]>
>>>>> <mailto:internet-drafts@ietf.**org <[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<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
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>> ______________________________**_________________
>>>>> clue mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>>
>>>>> ______________________________**_________________
>>>>> clue mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>>
>>>>> ______________________________**_________________
>>>>> clue mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>>
>>>>>
>>>>> ______________________________**_________________
>>>>> clue mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>>
>>>>>
>>>>>
>>>> ______________________________**_________________
>>>> clue mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>
>>>>
>>> ______________________________**_________________
>>> clue mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>
>>>
>> ______________________________**_________________
>> clue mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>
>>
> ______________________________**_________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>