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

[Paul Kyzivat <[e-mail]>]

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?
>
> That seems like putting the cart before the horse.

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.

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

I think so.

	Thanks,
	Paul

> Mike
>
> *From:*[e-mail] [mailto:[e-mail]] *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:
> 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" <[e-mail]
> <mailto:[e-mail]>> wrote:
>
> 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
>
>
>  > -----Original Message-----
>  > From: [e-mail] <mailto:[e-mail]>
> [mailto:[e-mail] <mailto:[e-mail]>] 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,
>  > 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: [e-mail] <mailto:[e-mail]>
> [mailto:[e-mail] <mailto:[e-mail]>] 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: [e-mail] <mailto:[e-mail]>
> [[e-mail] <mailto:[e-mail]>] on behalf of Mary
>  > > Barnes [[e-mail] <mailto:[e-mail]>]
>  > > 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
>  > > <[e-mail]
> <mailto:[e-mail]>> wrote:
>  > > > Hi,
>  > > >
>  > > > At least my intention has been to cover all information that is
>  > going
>  > > to be exchanged.
>  > > >
>  > > > Regards,
>  > > >
>  > > > Christer
>  > > >
>  > > > ________________________________________
>  > > > From: [e-mail] <mailto:[e-mail]>
> [[e-mail] <mailto:[e-mail]>] On Behalf Of
>  > > Christian Groves [[e-mail]
> <mailto:[e-mail]>]
>  > > > 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
>  > > >> <[e-mail] <mailto:[e-mail]>>
> 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
>  > > >> [e-mail] <mailto:[e-mail]>
>  > > >> https://www.ietf.org/mailman/listinfo/clue
>  > > >>
>  > > > _______________________________________________
>  > > > clue mailing list
>  > > > [e-mail] <mailto:[e-mail]>
>  > > > https://www.ietf.org/mailman/listinfo/clue
>  > > > _______________________________________________
>  > > > clue mailing list
>  > > > [e-mail] <mailto:[e-mail]>
>  > > > https://www.ietf.org/mailman/listinfo/clue
>  > > _______________________________________________
>  > > clue mailing list
>  > > [e-mail] <mailto:[e-mail]>
>  > > https://www.ietf.org/mailman/listinfo/clue
>  > > _______________________________________________
>  > > clue mailing list
>  > > [e-mail] <mailto:[e-mail]>
>  > > https://www.ietf.org/mailman/listinfo/clue
>  > _______________________________________________
>  > clue mailing list
>  > [e-mail] <mailto:[e-mail]>
>  > https://www.ietf.org/mailman/listinfo/clue
>
>
>
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue