Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Wed, 6 Jun 2012 07:09:25 -0700

Hi Roni,
I'm responding to this a bit late.
I'm confused by your sentence
	This will
	> have a major impact on the transport since if we need three
messages
	> starting with a consumer capabilities this does not work well
with offer
	> answer.
Was not the conclusion from the work done by Flemming and myself (the
SDP usage draft) and discussed in detail at the last ietf meeting that
offer answer is not a good fit for CLUE messages?  Was this not made
evident and agreed upon at that time? Did you think the possibility of
using SDP offer answer for clue messages was still an open issue?

thanks

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Roni even
> Sent: Thursday, May 24, 2012 11:57 AM
> To: Mary Barnes; Christer Holmberg
> Cc: CLUE
> Subject: Re: [clue] Updates to CLUE information transport criteria
from
> May 22 DT meeting
> 
> Hi,
> This is probably my bad English but I understood the subject as
written.
> I will look again at the list including the topics I had since it
looks
> to me that they are not related to the information but more to the
> transport.
> 
> I think that the major issue here is that we need to say what messages
> are used to carry the information is it two or three messages. This
will
> have a major impact on the transport since if we need three messages
> starting with a consumer capabilities this does not work well with
offer
> answer.
> 
> Roni
> 
> ________________________________________
> From: [email-masked] [[email-masked]] on behalf of Mary
> Barnes [[email-masked]]
> Sent: Thursday, May 24, 2012 18:08
> To: Christer Holmberg
> Cc: CLUE
> Subject: Re: [clue] Updates to CLUE information transport criteria
from
> May 22 DT meeting
> 
> Yes, that was the intent - to characterize the requirements for the
> information to be exchanged. Then we can then match those with a
> signaling solution(s) that satisfy the criteria for each of the
> information elements that need to be exchanged.
> 
> Mary.
> 
> On Thu, May 24, 2012 at 3:48 AM, Christer Holmberg
> <[email-masked]> wrote:
> > Hi,
> >
> > At least my intention has been to cover all information that is
going
> to be exchanged.
> >
> > Regards,
> >
> > Christer
> >
> > ________________________________________
> > From: [email-masked] [[email-masked]] On Behalf Of
> Christian Groves [[email-masked]]
> > Sent: Thursday, May 24, 2012 8:15 AM
> > To: CLUE
> > Subject: Re: [clue] Updates to CLUE information transport criteria
> from May 22 DT meeting
> >
> > Hello,
> >
> > I'm a little bit puzzled what the aim of the list/exercise is.
> > Christer's original list appeared to be for determining the criteria
> to
> > select a transport for CLUE. The list below seems now to be on
> > individual data elements? Are we considering only CLUE data elements
> > which I would assume for a CLUE data model? or is the scope broader?
A
> > broader scope appears to be suggested by mentioning information for
> SIP
> > establishment, SDP etc.
> >
> > Some specific comments below:
> >
> > The description of 3) on the expected frequency seems to be mixing
how
> > often something will be sent and expected response time based on
> > signalling. Item 5) covers "delay". Should this be merged with 3) or
> > does the description of 3) need to be revised to remove the delay
> aspect?
> >
> > It would be good to get more information on 8). Are we talking about
a
> > heterogeneous use case or a legacy use case? or?
> >
> > Regards, Christian
> >
> > On 24/05/2012 2:48 AM, Mary Barnes wrote:
> >> Per the thread on timing:
> >> http://www.ietf.org/mail-archive/web/clue/current/msg01346.html
> >> I have incorporated what I think were agreed in terms of the 3
> >> categorizations that Marshall put forth in the item below.  We
would
> >> need to wordsmith the text to be specific to CLUE but I think the
> >> references to things like IPTV provide a useful
> >> reference/rationalization for the values.
> >>
> >> Ideally, if folks can provide any feedback no later than noon on
> >> Friday, May 25th, the folks doing the data model will have
something
> >> to work from.
> >>
> >> Thanks,
> >> Mary.
> >>
> >> On Tue, May 22, 2012 at 11:55 AM, Mary Barnes
> >> <[email-masked]>  wrote:
> >>> Hi all,
> >>>
> >>> This is a summary of updates proposed during today's design team
> >>> meeting, based on Christer's original proposal and Roni's
suggested
> >>> additions:
> >>> http://www.ietf.org/mail-archive/web/clue/current/msg01433.html
> >>>
> >>> Note, this a very important thread of discussion as we really need
> >>> someone to step forward to take on detailing the data model and
> >>> evaluate each of the data elements against this criteria:
> >>>
> >>> 1) Whether signaling intermediaries (e.g. SBGs) need to have
access
> to
> >>>   the information - i.e.. whether information is relevant to
routing
> >>> decisions, policies as to how to route, etc.
> >>>
> >>>   -- Whether the CLUE information and the media description (SDP)
> need
> >>> to be in the same message.
> >>>
> >>> -- Whether the CLUE information and the media description (SDP)
need
> >>> to use the same transport path.
> >>>
> >>>   2) The expected size of the information to be sent (i.e.,
estimate
> of bytes)
> >>>
> >>>   3) The expected frequency of the information to be sent:
> >>     -- 30 msec. This is a video frame. Nothing of significance can
> >> happen faster, and some things, such as video switching, ideally
> would
> >> only take one frame.
> >>     -- 200 msec. This was always viewed as the ideal IPTV channel
> change
> >> time (and a lot of work was done on IGMP to try and get there).
This
> >> also happens to be a rough upper bound on non-noticeable RTTs, and
so
> >> is a rough  limit on how fast you can do things if those things
> >> require some sort of RT handshake / authorization  /
acknowledgement.
> >> It would be good to do many CLUE config changes in this
> >> time range - experience is that users will tolerate 200 msec of
> >> interruption or dead time, if something major changes.
> >>    -- many seconds. Setting up a conference, changing basic
> conference
> >> parameters, etc., can take many seconds. Rebooting equipment can
take
> >> many seconds.
> >>
> >>>   4) Whether the information is sent during session establishment,
> mid-
> >>> session and/or session termination.
> >>>
> >>> -- Information for SIP session establishment
> >>>
> >>> -- Information about CLUE, information about media, information to
> >>> establish media
> >>>
> >>>   5) What delay is acceptable for the information (i.e., CLUE data
> element)
> >>>
> >>> 6) Whether the information is sent as a notification, or whether
> some
> >>> kind of response is needed
> >>>
> >>> -- Does information need to be carried in a request and response
or
> >>>
> >>> -- is it just necessary to be communicated one way
> >>>
> >>>   7) Whether the information needs to be delivered reliably
(either
> >>> using  a reliable transport mechanism, and/or some kind of
> >>> higher-level  acknowledgement)
> >>>
> >>> 8) Whether the information is needed by a non-CLUE entity in order
> to
> >>> participate in a CLUE conference
> >>>
> >>> -- Not sure the intent here. Christer, can you please clarify what
> you
> >>> mean by non-CLUE.  Also, are you talking about some sort of
mapping
> or
> >>> is this a more theoretical question?
> >>>
> >>>
> >>>
> >>> Thanks,
> >>> Mary.
> >> _______________________________________________
> >> clue mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/clue
> >>
> > _______________________________________________
> > clue mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/clue
> > _______________________________________________
> > clue mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/clue
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "Roni Even" <[email-masked]>
Date: Wed, 6 Jun 2012 17:32:05 +0300

Hi Allyn,
I am not aware of such a decision and it will be good if we can decide on
this in the Interim meeting.
Flemming said in Paris that his work is not fully correct, the draft has
errors in the examples. Also there is the draft from Stephane Cazeaux that
suggest SDP.

According to Stephane Cazeaux there are three options. 
1. CLUE in  SDP and offer answer. 
2. Using SIP as the CLUE negotiation protocol. CLUE messages use a second
MIME body and may also have part in SDP
3. Carry SIP messages in a channel negotiated by the CLUE endpoints.

I did not see any decision in the minutes of IETF83

As for my text that you mentioned it is clear to me that if the provider
need to know what the consumer capabilities are before providing an
advertisement it will mean that the first message after establishing a
connection have to describe the consumer capability and this is not what an
OFFER is in RFC3264.

Roni 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Allyn Romanow (allyn)
> Sent: Wednesday, June 06, 2012 5:09 PM
> To: Roni even; Mary Barnes; Christer Holmberg
> Cc: CLUE
> Subject: Re: [clue] Updates to CLUE information transport criteria from
> May 22 DT meeting
> 
> Hi Roni,
> > >> It would be good to do many CLUE config changes in this time range
> > >> - experience is that users will tolerate 200 msec of interruption
> > >> or dead time, if something major changes.

---

From: Mary Barnes <[email-masked]>
Date: Wed, 6 Jun 2012 11:31:20 -0500

There was a hum taken and there was strong consensus that CLUE would NOT do
everything with SDP - that is recorded in the minutes:
http://www.ietf.org/proceedings/83/minutes/minutes-83-clue.txt

So, we are NOT revisiting that decision.  We do need to consider options 2
& 3 and I know of at least two other options and I'm sure others have
additional variations in mind.

Mary.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 6 Jun 2012 17:38:28 +0000

Mary, Roni,

Could someone summarize the logic behind the CLUE negotiating SIP versus SIP
negotiating CLUE?

That seems like putting the cart before the horse.

I am also wondering how universal that will be, i.e. compatibility with
systems 

that expect SIP to be the main protocol for negotiating other session types,
e.g. 3GPP/IMS.

Seems like interoperability planned from the get-go.

Or am I totally missing something?

Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary
Barnes
Sent: Wednesday, June 06, 2012 12:31 PM
To: Roni Even
Cc: CLUE
Subject: Re: [clue] Updates to CLUE information transport criteria from May
22 DT meeting

So, we are NOT revisiting that decision.  We do need to consider options 2 &
3 and I know of at least two other options and I'm sure others have
additional variations in mind.   

Mary. 

Hi Allyn,

Roni

---

From: Michael Hammer <[email-masked]>
Date: Wed, 6 Jun 2012 17:42:40 +0000

Meant non-interoperability.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Hammer
Sent: Wednesday, June 06, 2012 1:38 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [clue] Updates to CLUE information transport criteria from May
22 DT meeting

Mary, Roni,

Mike

Mary. 

Hi Allyn,

Roni

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 6 Jun 2012 19:59:30 +0200

Hi,

Regarding option 2), I guess using INFO also fits into that?

Regarding option 3), did you mean to say "carry CLUE messages"?  I don't think we are considering defineing a new transport mechanism for the SIP messages, are we? :)

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Mary Barnes [[email-masked]]
Sent: Wednesday, June 06, 2012 7:31 PM
To: Roni Even
Cc: CLUE
Subject: Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting

There was a hum taken and there was strong consensus that CLUE would NOT do everything with SDP - that is recorded in the minutes:  http://www.ietf.org/proceedings/83/minutes/minutes-83-clue.txt

So, we are NOT revisiting that decision.  We do need to consider options 2 & 3 and I know of at least two other options and I'm sure others have additional variations in mind.

Mary.

On Jun 6, 2012 9:34 AM, "Roni Even" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Allyn,

Roni

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> Allyn Romanow (allyn)
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of
> > Roni even
> > From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] on behalf of Mary
> > Barnes [[email-masked]<mailto:[email-masked]>]
> > <[email-masked]<mailto:[email-masked]>> wrote:
> > > Hi,
> > >
> > > From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of
> > Christian Groves [[email-masked]<mailto:[email-masked]>]
> > >> <[email-masked]<mailto:[email-masked]>>  wrote:
> > >>> Hi all,
> > >>>
> > >> [email-masked]<mailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Wed, 6 Jun 2012 21:01:35 +0000

Hi,

The three options that you list are not exactly the ones that are proposed in the I-D. Let me clarify:

Option A proposes the usage of two SDP O/A cycles to enable the exchange of all CLUE information between provider and consumer.

Option B1 and B2 rely on SDP for the advertisement of the capture scenes and the negotiation of media streams, and on a separate CLUE channel for the selection by the consumer of media capture that must be sent by the provider. Difference between B1 and B2 is:
- B1 relies on multiple SDP O/A cycles like option A
- B2 proposes a solution based on single SDP O/A cycle.  

No particular choice is done regarding to transport and format of the CLUE messages in the "CLUE channel" in option B.

Stéphane.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Roni Even
Envoyé : mercredi 6 juin 2012 16:32
À : 'Allyn Romanow (allyn)'; 'Roni even'; 'Mary Barnes'; 'Christer Holmberg'
Cc : 'CLUE'
Objet : Re: [clue] Updates to CLUE information transport criteria from May 22 DT meeting

Hi Allyn,

Roni

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 7 Jun 2012 08:56:17 +0000

In case of single SDP O/A cycle using (RE-)INVITE without SDP, the provider will know consumer capabilities before the negotiation and the legacy interop will be achieved with RFC 3261 compliant entity. Apart from this, CLUE capabilities shall be indicated by provider in contact header of (RE-)INVITE by which consumer knows that provider is a CLUE entity. 

The concern with this approach is how asymmetric video parameters negotiation is not possible between provider and consumer. IMO, it is possible to have achieve in case the asymmetric requirement for the specific codec are spelt out correctly.

Thanks
Partha 

>[email-masked]
>Sent: Thursday, June 07, 2012 2:32 AM
>To: [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>Cc: [email-masked]
>Option A proposes the usage of two SDP O/A cycles to enable the exchange
>of all CLUE information between provider and consumer.
>
>Option B1 and B2 rely on SDP for the advertisement of the capture scenes
>and the negotiation of media streams, and on a separate CLUE channel for
>the selection by the consumer of media capture that must be sent by the
>provider. Difference between B1 and B2 is:
>No particular choice is done regarding to transport and format of the
>CLUE messages in the "CLUE channel" in option B.
>
>
>Stéphane.
>
>De : [email-masked] [mailto:[email-masked]] De la part de
>Roni Even Envoyé : mercredi 6 juin 2012 16:32 À : 'Allyn Romanow
>(allyn)'; 'Roni even'; 'Mary Barnes'; 'Christer Holmberg'
>Cc : 'CLUE'
>I am not aware of such a decision and it will be good if we can decide
>on this in the Interim meeting.
>errors in the examples. Also there is the draft from Stephane Cazeaux
>that suggest SDP.
>
>2. Using SIP as the CLUE negotiation protocol. CLUE messages use a
>second MIME body and may also have part in SDP 3. Carry SIP messages in
>a channel negotiated by the CLUE endpoints.
>
>connection have to describe the consumer capability and this is not what
>an OFFER is in RFC3264.
>
>Roni
>
>
>> Of Allyn Romanow (allyn)
>with
>> > From: [email-masked] [[email-masked]] on behalf of
>> > Mary Barnes [[email-masked]]
>> > >>     -- 30 msec. This is a video frame. Nothing of significance
>> > >> can happen faster, and some things, such as video switching,
>> > >> ideally
>> > would
>> > >> only take one frame.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 10 Jun 2012 21:13:41 +0200

On 6/6/12 7:38 PM, Michael Hammer wrote:
> Mary, Roni,
>
> Could someone summarize the logic behind the CLUE negotiating SIP versus
> SIP negotiating CLUE?
>

Why?

In the end, we want a "regular" sip session, with media streams 
negotiated using SDP O/A. But we also want to exchange a lot of other 
information about what those streams contain, or could contain.

This is not radically different, conceptually, from xcon, or mediactrl.

We also have a desire for backward compatibility between a clue device 
and a generic sip voice and/or video device. So the initial INVITE 
should not be to weird for a conventional device to cope with.

*If* both ends turn out to support clue, then we need a mechanism to 
exchange the additional information. Exactly what that is remains to be 
settled.

> that expect SIP to be the main protocol for negotiating other session
> types, e.g. 3GPP/IMS.
>

I think so.

	Thanks,
	Paul

> Mike
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Mary Barnes
> *Sent:* Wednesday, June 06, 2012 12:31 PM
> *To:* Roni Even
> *Cc:* CLUE
> *Subject:* Re: [clue] Updates to CLUE information transport criteria
> from May 22 DT meeting
>
> There was a hum taken and there was strong consensus that CLUE would NOT
> do everything with SDP - that is recorded in the minutes:
> So, we are NOT revisiting that decision. We do need to consider options
> 2 & 3 and I know of at least two other options and I'm sure others have
>  > From: [email-masked] <mailto:[email-masked]>
> [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of
>  > Allyn Romanow (allyn)
>  > > From: [email-masked] <mailto:[email-masked]>
> [mailto:[email-masked] <mailto:[email-masked]>] On Behalf
>  > Of
>  > > Roni even
>  > > From: [email-masked] <mailto:[email-masked]>
> [[email-masked] <mailto:[email-masked]>] on behalf of Mary
>  > > Barnes [[email-masked] <mailto:[email-masked]>]
>  > > <[email-masked]
> <mailto:[email-masked]>> wrote:
>  > > > Hi,
>  > > >
>  > > > From: [email-masked] <mailto:[email-masked]>
> [[email-masked] <mailto:[email-masked]>] On Behalf Of
>  > > >> <[email-masked] <mailto:[email-masked]>>
> wrote:
>  > > >>> Hi all,
>  > > >>>
>  > > >> [email-masked] <mailto:[email-masked]>
>  > > > [email-masked] <mailto:[email-masked]>
>  > > > [email-masked] <mailto:[email-masked]>
>  > > [email-masked] <mailto:[email-masked]>
>  > > [email-masked] <mailto:[email-masked]>
>  > [email-masked] <mailto:[email-masked]>