Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt

[Mary Barnes <[e-mail]>]

On Fri, Sep 14, 2012 at 9:36 AM, Espen Berger (espeberg) <[e-mail]
> wrote:

> My main point is that the initial INVITE can be sufficient for a call with
> CLUE negotiated media stream.
>
> One of the exceptions we have discussed is the requirement to upgrade
> bandwidth to allow for three camera/screen scenarios, which is typically
> not something you allocate in the network before you really knows it's
> needed. In this case the re-INVITE is optional and there a clear user story
> to explain why and when we want to do it.
>
> I think necessary, and useful, to write down user stories to explain why a
> SIP re-INVITE is needed.  With user stories it's much easier to discuss how
> to solve actual problems with protocols.
>
[MB] Absolutely.  I think we need to start with what Alice and Bob want to
do and then work down to what signaling is required to achieve that.  [/MB]

>
> Cheers
>
> -Espen
>
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: 11. september 2012 17:51
> To: Espen Berger (espeberg)
> Cc: CLUE
> Subject: Re: [clue] New Version Notification for
> draft-kyzivat-clue-telemedical-callflow-00.txt
>
> On 9/11/12 9:56 AM, Espen Berger (espeberg) wrote:
> > My comments
> >
> > * It's natural that the MCU send an empty advertisement when the
> classroom dials in as the first participant. If not, the classroom does not
> now if the conference is empty. The configuration message can be delayed,
> since you are mainly indicating that you do not want to receive media.
>
> That is a good idea. I'll do it.
>
> > * I think the MCU can delay its initial configure message until the
> classroom and surgery has done the configure message. With only two
> participant in the conference, you do not have to configure each endpoint
> to send media until the MCU knows someone request the media and also know
> the media restrictions.
> >
> > * What is the purpose for the second INVITE from the classroom, where
> the text says 'to cover both configurations'. The initial SIP INVITE can be
> sufficient for payload numbers, bw, codec-parameters. Based on the
> draft-romanow-clue-call-flow document the main example for a re-invite is
> to increase or decrease bandwidth allocation.
>
> I assumed a consistent approach to first invites - that they are vanilla
> and minimal, and so aren't sufficient to support the actual CLUE call.
>
> I have assumed that the invite with o/a to get things *right* is done
> *after* the Configure messages have been exchanged, when the needs are
> fully known. There is a chance for glare here - with both sides trying to
> initiate the o/a. I assumed for this flow that this doesn't happen - either
> one side waits for the other to go first, or else the timing results in one
> side sending first and that this then causes the other side to omit its own
> attempt because it is no longer needed.
>
> Because the two sides make independent choices of what to receive, and
> these may not be symmetric, it is necessary to consider both configurations
> to decide what to offer. Or else, one side sends an offer sufficient for
> itself, and then the other side may have to both answer and then make a new
> offer to add things it needs.
>
> This needs more discussion. I didn't sense any consensus or even common
> understanding of the issues and tradeoffs.
>
> > * The expert endpoints does not send a Configure message to the MCU. Is
> this intentional or not?
>
> I'm having trouble remembering what I was thinking. :-) I think the note
> "Defer config till get request" is a mistake, and the expert should go
> ahead and send a Configure. I'll fix it.
>
>         Thanks,
>         Paul
>
> > Cheers
> >
> > -Espen
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of Paul Kyzivat
> > Sent: 11. september 2012 00:52
> > To: CLUE
> > Subject: Re: [clue] New Version Notification for
> > draft-kyzivat-clue-telemedical-callflow-00.txt
> >
> > I just submitted in initial version of a new callflow draft.
> > A more useful link for it is:
> >
> > https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callfl
> > ow/
> >
> > This is complementary to draft-romanow-clue-call-flow.
> >
> > I've focused on a particular use case rather than a generic one. I've
> chosen the telemedical use case, and a special case of that use case.
> > Some of the interesting things about this case are that it includes an
> > MCU, and more than two endpoints. And those endpoints are not all
> > identical. (The latter point won't have obvious impact until more
> > detail is filled in.)
> >
> > And for now I've considered only the ladder diagram of sip and clue
> messages. That leaves a lot out. I expect it to be expanded to include the
> content of those messages. But before getting to that there are already a
> bunch of issues to sort out, that will impact what goes in those messages.
> >
> > I don't have any illusions that this version is "correct". It is just a
> starting point to discuss the issues. So please send comments. Maybe we
> will have time to talk about it at tomorrow's design team meeting, and/or
> at the interim next week.
> >
> >       Thanks,
> >       Paul
> >
> > On 9/10/12 6:34 PM, [e-mail] wrote:
> >>
> >> A new version of I-D, draft-kyzivat-clue-telemedical-callflow-00.txt
> >> has been successfully submitted by Paul H. Kyzivat and posted to the
> >> IETF repository.
> >>
> >> Filename:     draft-kyzivat-clue-telemedical-callflow
> >> Revision:     00
> >> Title:                CLUE Telemedical Use Case Callflow
> >> Creation date:        2012-09-11
> >> WG ID:                Individual Submission
> >> Number of pages: 8
> >> URL:
> http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-callflow-00.txt
> >> Status:
> http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callflow
> >> Htmlized:
> http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-00
> >>
> >>
> >> Abstract:
> >>      This is the beginning of an example call flow for an instantiation
> of
> >>      the use case described in the telemedical use case
> >>      [I-D.xiao-clue-telemedical-use-case].  More detail will be added
> >>      later.
> >>
> >>
> >>
> >>
> >> The IETF Secretariat
> >>
> >>
> >
> > _______________________________________________
> > clue mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/clue
> >
>
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue
>