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

["Roni Even" <[e-mail]>]

Paul,
Simulcast means that the sender can send one or more encodings of the same
source depending on what the receiver wants. This is the issue that was
raised in the discussion about individual encodes.
Roni

-----Original Message-----
From: Paul Kyzivat [mailto:[e-mail]] 
Sent: 14 September, 2012 11:45 PM
To: Roni Even
Cc: 'Espen Berger (espeberg)'; 'CLUE'
Subject: Re: [clue] New Version Notification for
draft-kyzivat-clue-telemedical-callflow-00.txt

On 9/14/12 6:22 PM, Roni Even wrote:
> Hi Paul,
> http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-01
> describes how to do simulcast without CLUE. Now if you also describe 
> in CLUE the encoding (which I am not sure is needed for this case) you 
> should have the SDP correlated with CLUE, this will require the offer 
> answer after the CLUE configuration like I proposed in previous email.
> If the SDP description is there  you can switch with re-invite without 
> CLUE (you will need to re-invite to signal the port)

Maybe we are talking about different things.

ISTM that offering multiple encodings for a capture is not the same as
simulcasting the capture in multiple encodings. AFAIK the simulcast means
that you are sending out both, and people can decide which they want to
receive. The advertisement says you could send one or the other or both. The
configure then determines which you actually send, which again could be one
or the other or maybe both. ISTM you only have a simulcast situation when
you advertise both and the receiver configures both.

I guess simulcasting two resolutions is more expensive than sending just
one. So I don't see why we would do it unless the receiver wants both.

It would be helpful to have some discussion of where simulcast has a role
within CLUE. Maybe as part of the RTP document you and Jonathan are working
on.

	Thanks,
	Paul

> Roni
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: 14 September, 2012 9:13 PM
> To: Roni Even
> Cc: 'Espen Berger (espeberg)'; 'CLUE'
> Subject: Re: [clue] New Version Notification for 
> draft-kyzivat-clue-telemedical-callflow-00.txt
>
> On 9/14/12 3:36 PM, Roni Even wrote:
>> Paul,
>> Try to analyze it assuming that each resolution is using a different 
>> transport address, so you must use SDP to switch in which case why 
>> not define simulcast in SDP and not in CLUE.
>
> This is really into the "what goes where", which is a good discussion 
> to have!
>
> I guess what you are describing means that there are two alternate 
> encodings available for this capture. They could map to two different
m-lines in sdp.
> But what would cause them both to be listed in the SDP?
>
> This can work if the SDP is determined by the advertisement, and 
> covers all possible configurations that might be configured from that 
> advertisement. So then, if both are in an SDP offer that corresponds 
> to that advertisement, then the SDP answer can choose which of those 
> to accept. That is in effect doing a configuration, or part of it. For 
> that to work, the advertisement that explains what those mean would 
> have to be sent before the SDP offer, so that it would be available to 
> make the decision about what to accept in the answer.
>
> And then if later there is a desire to switch to the other resolution, 
> then I guess an SDP offer would be sent in the other direction, 
> changing which of the two m-lines has a non-zero port.
>
> It sounds like this can be made to work, though the devil is in the
details.
> It will require a lot of analysis of when advertisements must be sent 
> relative to offers. Based on above, an advertisement MAY/MUST?
> be followed by an offer. And apparently the offer must be sufficient 
> for any configuration of that advertisement. I'm worried that this may 
> require the offerer to consume more resources than are required for most
configurations.
>
> 	Thanks,
> 	Paul
>
>> Roni
>>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[e-mail]]
>> Sent: 14 September, 2012 7:01 PM
>> To: Roni Even
>> Cc: 'Espen Berger (espeberg)'; 'CLUE'
>> Subject: Re: [clue] New Version Notification for 
>> draft-kyzivat-clue-telemedical-callflow-00.txt
>>
>> On 9/14/12 1:25 PM, Roni Even wrote:
>>> Paul,
>>> I can think of an example for SDP only with no CLUE but it depends 
>>> how simulcast is implemented. A switch from high res to low res of 
>>> the same capture (example room view) without a change in the CLUE 
>>> Roni
>>
>> OK. I can sort of see that. Maybe.
>>
>> Does this fall into the category of something where there are 
>> alternatives within a single config?
>>
>> But I would have thought that the high and low res versions of the 
>> same capture would be represented in clue signaling by advertising 
>> two possible encodings for the same capture, and then configuring the 
>> capture with one or the other. If so, then there would be a config 
>> message associated with the change.
>>
>> 	Thanks,
>> 	Paul
>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:[e-mail]]
>>> Sent: 14 September, 2012 5:44 PM
>>> To: Roni Even
>>> Cc: 'Espen Berger (espeberg)'; 'CLUE'
>>> Subject: Re: [clue] New Version Notification for 
>>> draft-kyzivat-clue-telemedical-callflow-00.txt
>>>
>>> I agree with this. One comment below.
>>>
>>> On 9/14/12 12:15 PM, Roni Even wrote:
>>>> Hi Paul,
>>>> Other examples
>>>>
>>>> 1. want to add a transport connection when adding a new RTP stream 
>>>> (example opening a presentation stream during the call or changing 
>>>> the presentation
>>>> stream) will require a  re-invite. In general every change in the 
>>>> transport connection whether adding a new one when not SSRC 
>>>> multiplexing or changing the connection (transfer the call or some 
>>>> of the media streams without the CLUE channel) 2. Changing the 
>>>> codec used
>>>> (H.26 to H.264 or audio codec) may require a re-invite.
>>>> 3. When an MCU wants to change the common mode of a call when a 
>>>> party is added or dropped.
>>>>
>>>> There are more use cases.
>>>>
>>>> I see there are two types of requirements for re-invite.
>>>>
>>>> The first is during call setup in a point to point and multipoint 
>>>> call where the first invite is used to negotiate CLUE support and 
>>>> address interoperability with non-CLUE systems. After going the 
>>>> negotiation of the CLUE state there will be a need for a re-invite 
>>>> to correlate the CLUE and SDP states.
>>>>
>>>> The second during the call is when there is a change in the CLUE 
>>>> state that MAY require a correlation with the SDP state or even 
>>>> just an SDP state change like changing codec or addressing network 
>>>> or application issues that do not change the CLUE state.
>>>
>>> I think we don't yet know if there will be anything that makes sense 
>>> to change in SDP without some corresponding change in advertisement 
>>> or
>> config.
>>> If there is, it must be something for which there are alternative 
>>> ways to accomplish the configuration. I'm not sure what that might 
>>> be, but in principle I see it could happen.
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>>> Roni
>>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On 
>>>> Behalf Of Espen Berger (espeberg)
>>>> Sent: 14 September, 2012 4:36 PM
>>>> To: Paul Kyzivat
>>>> Cc: CLUE
>>>> Subject: Re: [clue] New Version Notification for 
>>>> draft-kyzivat-clue-telemedical-callflow-00.txt
>>>>
>>>> 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-ca
>>>>> l
>>>>> l
>>>>> f
>>>>> l
>>>>> 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-
>>>> c
>>>> a
>>>> l
>>>> lflow-
>>>> 00.txt
>>>>>> Status:
>>>> http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-call
>>>> f
>>>> l
>>>> o
>>>> w
>>>>>> Htmlized:
>>>> http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-
>>>> 0
>>>> 0
>>>>>>
>>>>>>
>>>>>> 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
>>>>
>>>>
>>>
>>>
>>
>>
>
>