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

[Paul Kyzivat <[e-mail]>]

On 9/14/12 6:29 PM, Roni Even wrote:
> Paul,
> One concern I have is that some of the usages like simulcast are not a CLUE
> issue but are relevant also for non CLUE solutions. So to resolve this use
> case we can mandate using CLUE (as a multi stream signaling) or resolve it
> using SDP. The worst case is if we have two ways to signal without defining
> the interoperability.
>
> I tried to provide in section 4.1
> http://tools.ietf.org/html/draft-even-clue-rtp-mapping-04 a review of some
> of the signaling proposal from AVTcore, AVText and MMSUIC that can address
> some of the scenarios discussed in CLUE in order to have a full picture
> before deciding to put something in CLUE protocol.
>
> I hope that people will look at these documents .

I looked, and it is helpful to have these technologies identified.
But as I said in my last message, it would be more helpful if the 
document could actually *position* the use of simulcast in the context 
of a clue session.

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