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

[Ron Even <[e-mail]>]

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
As for step 3 and 4 overlap, this may not always be the case, example is an
endpoint calling to the MCU who may want to see the advertisement first.

Roni

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_text=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
>