Re: [clue] Subject matter for Monday's call

[Stephan Wenger <[e-mail]>]

On 12.2.2012 10:29 , "Christer Holmberg" <[e-mail]>
wrote:

>
>Hi,
>
>>The general flow is ok and the new point here is that after the
>>advertise config there will always be a new offer answer that will
>>establish the media and can be used for defining the
>> SSRCs of all streams. This is important for static mapping and will
>>also be used to support simulcast which is not supported in CLUE.
>> I also assume that step 1 and 2 will include m-lines for allowing
>>initial audio and video this will allow ICE negotiation and having audio
>>and video early in the process. This is required also for
>>interoperability with non CLUE systems
>
>I guess step 1 and 2 are related to the discussion in the "Scene for
>non-CLUE/single stream devices" thread.

Yes, in the sense that if the negotiation of the CLUE channel fails, then
all you have to work with is the non-CLUE aspects of the OA exchange.

Please see also my reply to Roni's email.

Stephan

>
>Regards,
>
>Christer
>
>
>
>
>
>On Saturday, December 1, 2012, Stephan Wenger wrote:
>Hi all,
>
>Mark, Andy, and myself had a bit of brainstorming how to most
>productively use our time during the Monday morning call.  Due to travel
>and vacation schedule, our coordination was finalized call only late
>Friday.  Which may serve as an explanation, if not as an excuse, for the
>late timing of this email.
>
>In our opinion, the most pressing issue we have with the framework
>document is it being agnostic to the protocol elements used to convey the
>various messages that are part of the framework.  Clearly, the framework
>was written from a perspective where a CLUE protocol channel would be
>established, and (all?) further signaling would be dealt with over that
>channel.  So is, more or less, the call flow doc.  We believe that there
>was sufficient pushback against that idea to make rapid progress based on
>this assumption unlikely.  Accordingly, we believe that we probably best
>spend most of our time by discussing a strawman for a split-up between
>SDP-represented, SIP-ish, Offer-Answer, Š, that type of traditional
>messages, and (XML-coded) messages sent over the CLUE.  The focus of our
>Monday call would be on the initial exchange, rather than any updates
>that may happen during a call.
>
>With reference to the call flow 02 doc
>(https://datatracker.ietf.org/doc/draft-romanow-clue-call-flow/?include_te
>xt=1) that exchange could look as follows:
>
>  1.  Invite from Alice, just like A.1 in call-flow-02
>  2.  200 OK from Bob, A.2
>  3.  CLUE Advertisement Alice A.3, covering geometry stuff, encoding
>groups, etc.
>  4.  CLUE Advertisement Bob A.4; note that 3 and 4 would in practice
>overlap in time
>  5.  CLUE Response from Alice A.5, with the difference that these
>reposes DO NOT have the side effect of initiating any media channel
>related activity; they are pure signaling
>  6.  CLUE Response from Bob, A.6, same remark.. 5 and 6 could overlap in
>time.
>  7.  Re-invite from Alice and Bob, respectively, with media channels as
>CLUE-"negotiated"
>  8.  200 OK from Bob, Alice.  As the endpoints have already established
>their operation points through CLUE, this step will not fail except if an
>entity not involved in the CLUE negotiation intervenes‹i.e. a middle box
>doesn't like that call.
>
>The reason for the existence of step 7, rather than setting up media
>channels as side effect of steps 3 through 6 (as assumed in call flow and
>in the current framework doc) is twofold: easier integration into the
>source base of media codecs that currently use SDP for the selection of
>their parameters, and making middlebox people happy.
>
>The reason for the existence of steps 3 through 6 is our agreement that
>not all useful protocol elements envisioned in the framework can be
>reasonably and meaningfully implemented in SDP extensions.  This is
>certainly true for the geometry stuff.
>
>The reason for keeping an encoding group concept in CLUE is that a
>representation of the information that can be conveyed through individual
>encoding descriptions, encoding groups, and the association of media
>captures with encoding groups (section 7 and 8 of the framework) purely
>through grouped m-lines would lead to bloated (if not exploded :-) SDP,
>quite possibly well beyond a reasonable size (i.e. MTU size); the high
>level of abstraction offered by concepts such as encoding groups,
>simultaneous transmission sets, and so on, makes for a very compact
>representation compared to listing all possible permutations of
>alternative choices in grouped m-lines.
>
>Does such a mechanism make at least initial sense?  Should it be fleshed
>out and put into the framework?
>
>Stephan
>