Re: [rtcweb] Review request for RTCWeb standard signaling protocol

On Tue, Oct 18, 2011 at 7:19 AM, Tim Panton <tim@phonefromhere.com> wrote:

>
>
> The example I gave had _no_ negotiation, no back and forth, because the
> application's webserver was
> told all the capabilities in advance, (at login in my example), it simply
> _decided_ based on
> it's view of the union of the capabilities of the two ends. It then
> informed them of the choice
> (which may have been asymmetric by the way) and told them to get on with
> it.
>
>
The working group decided very early on to require a mandatory-to-implement
codec to ensure that there were no negotiation failures.  If the web server
always selects the mandatory to implement codec, then this should work.  It
may be sub-optimal (a better codec might have been available for this
session), but it would cause a complete connection.

The issue comes when you use a pair of codec sets from time T and run the
intersection algorithm at some later time.  The risk is that the overall
resource set available at one or more of the nodes may have changed, and
this can have an impact on its ability or preferences.  The classic example
is battery life on mobiles.  If I send you a capability set when I have a
fully charged battery, it may include computationally expensive algorithms
that take a lot of energy; those might be lower preference or elided from
the set after hours of game play in which I drew the battery down.

I also note that this is not really protocol free, it's just that the format
by which the API results are returned to the webserver running the
intersection algorithm are not standard; there's still a (private) protocol
in use.

regards,

Ted

> To the extent that there was a 'negotiation',  it took place in a single
> thread on the web server,
> with no propagation delays or locks needed.
>
>
> >
> > Well, if we can avoid these complexities, let us find out (e.g.
> Pre-defined some constraints etc.).
> >
> > Or, if an API is good enough exposing all the codec parameters and
> offer/answer signaling can be avoided, let us find it out.
>
> Offer - Answer really only crops up because there is a requirement (which I
> personally put very low on our priorities) to be able
> to interop with legacy video phones without  needing a media gateway.
>
> Tim.
>
> >
> > BR/Radhika
> >
> > -----Original Message-----
> > From: Tim Panton [mailto:tim@phonefromhere.com]
> > Sent: Tuesday, October 18, 2011 9:26 AM
> > To: Roy, Radhika R USA CIV (US)
> > Cc: Saúl Ibarra Corretgé; Ravindran Parthasarathi; rtcweb@ietf.org
> > Subject: Re: [rtcweb] Review request for RTCWeb standard signaling
> protocol
> >
> >
> > On 18 Oct 2011, at 14:08, Roy, Radhika R USA CIV (US) wrote:
> >
> >> Hi, Saúl
> >>
> >> Is there a way to do negotiations with different codec types and
> different features of a given codec without using a signaling protocol
> between the two functional entities?
> >>
> >> BR/Radhika
> >
> > No, you always need  a transport to get the supported codec description
> list from one end to the other.
> > What you don't have to specify is the protocol that the transport uses,
> or the decision making process that each end uses to select the capabilities
> it wants to employ in this instance of this web app.
> >
> > Here is an example that illustrates how it could work in a 'protocol
> free' way.
> >
> > User A could query the browser for the codec description list at the
> start of a web game session, the web app could upload that to the session
> storage on the game server.
> > User B does the same thing.
> > At some point later users A and B encounter each other in the game. - the
> server _already_knows_ the capabilites of their respective browsers and
> instructs them to do an ice negotiation to find a transport between them.
> > Once that is done it informs them _both_ of it's codec selection - which
> may be based on their game status.
> >
> > The video session proceeds as part of the game until the 2 users part, at
> which point the session is torn down.
> >
> >
> > I'm by no means saying that this is the _only_ way connections can be
> made, just that if we get this API right we can do things this way.
> > Tim.
> >
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>