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

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Sep 2012 18:52:15 -0400

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-callflow/

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, [email-masked] 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
>
>

---

From: Mary Barnes <[email-masked]>
Date: Mon, 10 Sep 2012 18:25:38 -0500

I think this would be an excellent thing to review at tomorrow's design
team meeting.  I believe walking through this will be extremely insightful.

Thanks,
Mary.

On Mon, Sep 10, 2012 at 5:52 PM, Paul Kyzivat <[email-masked]> wrote:

> https://datatracker.ietf.org/**doc/draft-kyzivat-clue-**
> telemedical-callflow/<https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callflow/>
>
> 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.)
>
> 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.
>
> will have time to talk about it at tomorrow's design team meeting, and/or
> at the interim next week.
>
>         Thanks,
>         Paul
>
>> A new version of I-D, draft-kyzivat-clue-**telemedical-callflow-00.txt
>> Filename:        draft-kyzivat-clue-**telemedical-callflow
>> Revision:        00
>> URL:             http://www.ietf.org/internet-**
>> drafts/draft-kyzivat-clue-**telemedical-callflow-00.txt<http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-callflow-00.txt>
>> Status:          http://datatracker.ietf.org/**doc/draft-kyzivat-clue-**
>> telemedical-callflow<http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callflow>
>> Htmlized:        http://tools.ietf.org/html/**draft-kyzivat-clue-**
>> telemedical-callflow-00<http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-00>
>>
>>
>> Abstract:
>>     [I-D.xiao-clue-telemedical-**use-case].  More detail will be added
>>     later.
>>
>>
>>
>>
>> The IETF Secretariat
>>
>>
>>
> ______________________________**_________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 11 Sep 2012 13:18:30 +0200

Hi Paul,
I suggest to reference
http://tools.ietf.org/html/draft-westerlund-avtcore-max-ssrc-02 in the
initial offer proposing how many RTP streams can be sent and received
simultaneously in the offered RTP session.

For example: the offerer can send up to 6 RTP streams and Receive up to 4.
This will help with providing a better advertisements form both sides

     m=video 49200 RTP/AVP 99
     a=rtpmap:99 H264/90000
     a=max-send-ssrc:{*:6}
     a=max-recv-ssrc:{*:4}

Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: 11 September, 2012 12:52 AM
To: CLUE
Subject: Re: [clue] New Version Notification for
draft-kyzivat-clue-telemedical-callflow-00.txt

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

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, [email-masked] wrote:
> 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
>     [I-D.xiao-clue-telemedical-use-case].  More detail will be added

_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Sep 2012 09:26:03 -0400

Roni,

OK. I'll put a section in the doc for now with TO-DOs.
This is something to address when the message contents are described.

	Thanks,
	Paul

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Tue, 11 Sep 2012 13:56:41 +0000

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.  

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

* The expert endpoints does not send a Configure message to the MCU. Is this intentional or not?

Cheers

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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'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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Sep 2012 11:50:57 -0400

> * 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 messag…

That is a good idea. I'll do it.

> * 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-parameter…

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

---

From: Xiaojing <[email-masked]>
Date: Wed, 12 Sep 2012 09:34:55 +0000

Hi Espen,

Your idea of sending an empty advertisement when there is no other participant in the meeting is great.
And I think if there is an empty advertisement, then there should be a corresponding empty configuration to maintain the one-to-one relationship between them.

Best regards,
Lennard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Espen Berger (espeberg)
Sent: Tuesday, September 11, 2012 9:57 PM
To: Paul Kyzivat; CLUE
Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt

My comments 

Cheers

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Wed, 12 Sep 2012 14:23:32 +0200

Paul,
In my view the first invite include the audio and video to and from the MCU.
The MCU may send back a fixed slide as video with the conference information
or a loop back to verify the connectivity and on the audio the MCU may send
an announcement and mute afterwards. So there may be more than one offer
answer even without CLUE.

The configure message from the MCU and advertisement from the MCU may be
delayed (this may be an MCU application decision since the conference may be
pre-configured to a certain mode by the organizer). This is similar to a
later offer answer for establishing the conference mode.

As for a second (or n-th) offer answer what I believe is that it may be
needed or not depending also on what was exchanged in the last offer answer
state before a change in the configuration. My view is that the important
issue is the consistency between the SDP state and the CLUE state.

There is also the issue of the middle box topology that may require an offer
answer (http://tools.ietf.org/html/draft-even-clue-rtp-mapping-04 )

Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: 11 September, 2012 5:51 PM
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.

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

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

> identical. (The latter point won't have obvious impact until more 
> detail is filled in.)
>

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Fri, 14 Sep 2012 14:36:28 +0000

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:[email-masked]] 
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

> * 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-parameter…

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

---

From: Mary Barnes <[email-masked]>
Date: Fri, 14 Sep 2012 09:50:44 -0500

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

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

> > * 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.
>
> 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
> draft-romanow-clue-call-flow document the main example for a re-invite is
> to increase or decrease bandwidth allocation.
>
> 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
> 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
> "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
> >
> http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-callflow-00.txt
> >> Status:

---

From: "Roni Even" <[email-masked]>
Date: Fri, 14 Sep 2012 18:15:25 +0200

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.

Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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.

Cheers 

-Espen 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: 11. september 2012 17:51
To: Espen Berger (espeberg)
Cc: CLUE
Subject: Re: [clue] New Version Notification for

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Sep 2012 11:32:08 -0400

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

My thinking is that all of the reinvite/o/a's are potentially optional: 
if the existing SDP is compatible with new advertisement/configuration 
than the o/a can be omitted. But in principle the SDP might need to 
change. So to start I put those in. When the details are filled in the 
redundant ones can be omitted.

But one thing I wanted to explore is the timing relationship between 
advertisements/configs and O/As. I see a number of possibilities:

- each config *may* demand an SDP change. If so, we need to decide if:
   * the SDP change must precede the config change
   * the SDP change must follow the config change
   * additions to the SDP must precede the config change,
     and deletions from the SDP must follow the config change

- config changes never require SDP changes because there is requirement
   that SDP be compatible with *any* possible configuration of the
   advertisement. Each advertisement *may* demand an SDP change.
   If so, we need to decide if: (alternatives analogous to those above)

ISTM that different configurations of the same advertisement can demand 
widely divergent sets of resources. So I think it must be configurations 
that drive SDP changes.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Sep 2012 11:44:25 -0400

I agree with this. One comment below.

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Sep 2012 11:48:12 -0400

On 9/14/12 11:32 AM, Paul Kyzivat wrote:
>> 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.

I forgot to mention - yes, I agree that the callflow requires 
explanatory text for *why* the messages are there, and in the order they 
are. It was more than I had time to do in the first version.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Fri, 14 Sep 2012 19:25:19 +0200

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

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 14 September, 2012 5:44 PM
To: Roni Even
Cc: 'Espen Berger (espeberg)'; 'CLUE'
Subject: Re: [clue] New Version Notification for

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

> typically not something you allocate in the network before you really
knows it's needed.
>> 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, 
> 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.
>>
>> 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.
> 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 
> 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
>>
>> https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callf
>> l
>> ow/
>>
>> 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 
> already a bunch of issues to sort out, that will impact what goes in those
messages.
> 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, 
>>>       This is the beginning of an example call flow for an 
>>> instantiation
> of

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Sep 2012 13:00:54 -0400

> capture (example room view) without a change in the CLUE

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

---

From: "Roni Even" <[email-masked]>
Date: Fri, 14 Sep 2012 21:36:48 +0200

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

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 14 September, 2012 7:01 PM
To: Roni Even
Cc: 'Espen Berger (espeberg)'; 'CLUE'
Subject: Re: [clue] New Version Notification for

On 9/14/12 1:25 PM, Roni Even wrote:
> 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

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

>> (example opening a presentation stream during the call or changing 
>> the presentation
>> 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
>>
>> In this case the re-INVITE is optional and there a clear user story 
>> draft-romanow-clue-call-flow document the main example for a 
>> re-invite is to increase or decrease bandwidth allocation.
>>
>> *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
>> Because the two sides make independent choices of what to receive, 
>> and these may not be symmetric, it is necessary to consider both 
>> 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.
>>>
>>>> A new version of I-D, 
>>>> has been successfully submitted by Paul H. Kyzivat and posted to 
>>>> the IETF repository.
>>>>
>> http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-ca
>> l
>> lflow-
>> 00.txt
>>>> Status:
>> http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callfl
>> o
>> w
>>>> Htmlized:

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Sep 2012 15:13:08 -0400

> 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

---

From: "Roni Even" <[email-masked]>
Date: Sat, 15 Sep 2012 00:22:05 +0200

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)

Roni

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 14 September, 2012 9:13 PM
To: Roni Even
Cc: 'Espen Berger (espeberg)'; 'CLUE'
Subject: Re: [clue] New Version Notification for

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

>> 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
>
> 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 
>>> multiplexing or changing the connection (transfer the call or some 
>>> of the media streams without the CLUE channel) 2. Changing the codec 
>>> used
>>> 3. When an MCU wants to change the common mode of a call when a 
>>> party is added or dropped.
>>>
>>> negotiation of the CLUE state there will be a need for a re-invite 
>>> to correlate the CLUE and SDP states.
>>>
>> 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
>>>
>>> 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.
>>> 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
>>>
>>>
>>> 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.
>>> be sufficient for payload numbers, bw, codec-parameters. Based on 
>>> the draft-romanow-clue-call-flow document the main example for a 
>>> 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.
>>>
>>> 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.
>>>
>>>> https://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-cal
>>>> l
>>>> f
>>>> l
>>>> ow/
>>>>
>>>> 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.)
>>>>
>>> we will have time to talk about it at tomorrow's design team 
>>> meeting, and/or at the interim next week.
>>>>
>>>> 	Thanks,
>>>> 	Paul
>>>>

---

From: "Roni Even" <[email-masked]>
Date: Sat, 15 Sep 2012 00:29:55 +0200

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 .

Roni

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 14 September, 2012 9:13 PM
To: Roni Even
Cc: 'Espen Berger (espeberg)'; 'CLUE'
Subject: Re: [clue] New Version Notification for

	Thanks,
	Paul

media.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Sep 2012 17:45:23 -0400

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

---

From: "Roni Even" <[email-masked]>
Date: Sat, 15 Sep 2012 01:00:02 +0200

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:[email-masked]] 
Sent: 14 September, 2012 11:45 PM
To: Roni Even
Cc: 'Espen Berger (espeberg)'; 'CLUE'
Subject: Re: [clue] New Version Notification for

On 9/14/12 6:22 PM, Roni Even wrote:
> 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)

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.

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

>> 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!
>
m-lines in 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.
>
> 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.
>
details.
> be followed by an offer. And apparently the offer must be sufficient 
> for any configuration of that advertisement. I'm worried that this may 
configurations.
>> same capture would be represented in clue signaling by advertising 
>> two possible encodings for the same capture, and then configuring the 
>>>> of the media streams without the CLUE channel) 2. Changing the 
>>>> codec used
>>>> 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 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
>>>>
>>>>
>>>> endpoint to send media until the MCU knows someone request the 
>>>> media and also know the media restrictions.
>>>>>
>>>> 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 
>>>>> 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.)
>>>>>
>>>> starting point to discuss the issues. So please send comments. 
>>>> Maybe we will have time to talk about it at tomorrow's design team 
>>>> 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:
>>>>>>          [I-D.xiao-clue-telemedical-use-case].  More detail will 
>>>>>> be
> added
>>>>>>          later.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The IETF Secretariat
>>>>>>
>>>>>>
>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Sep 2012 18:01:59 -0400

> 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

---

From: Mary Barnes <[email-masked]>
Date: Fri, 14 Sep 2012 17:03:46 -0500

This is a really important point.  I totally agree that we need to consider
that what CLUE needs or might define at the SDP level should be usable for
non-CLUE endpoints for interoperability.  This may put some limitations and
restrictions on the decisions we make as to what is carried in SDP versus
in CLUE application level signaling.

Mary.

On Fri, Sep 14, 2012 at 5:29 PM, Roni Even <[email-masked]> wrote:

> encodings
> any

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Sep 2012 10:04:41 +0200

Hi,

It is not only about non-CLUE endpoints - it is also about intermediaries.

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: 15. syyskuuta 2012 1:04
To: Roni Even
Cc: CLUE
Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-00.txt

This is a really important point.  I totally agree that we need to consider that what CLUE needs or might define at the SDP level should be usable for non-CLUE endpoints for interoperability.  This may put some limitations and restrictions on the decisions we make as to what is carried in SDP versus in CLUE application level signaling.

Mary.
On Fri, Sep 14, 2012 at 5:29 PM, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:
Paul,

Roni

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 14 September, 2012 9:13 PM
To: Roni Even
Cc: 'Espen Berger (espeberg)'; 'CLUE'
Subject: Re: [clue] New Version Notification for

        Thanks,
        Paul

> From: Paul Kyzivat [mailto:[email-masked]<mailto:[email-masked]>]
>> From: Paul Kyzivat [mailto:[email-masked]<mailto:[email-masked]>]
>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
>>> Of Espen Berger (espeberg)
>>> From: Paul Kyzivat [mailto:[email-masked]<mailto:[email-masked]>]
media.
>>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
>>>> Behalf Of Paul Kyzivat
>>>> On 9/10/12 6:34 PM, [email-masked]<mailto:[email-masked]> wrote:
>>>>>
>>>>> A new version of I-D,
>>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>

_______________________________________________
clue mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clue