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

["Espen Berger (espeberg)" <[e-mail]>]

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