W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2012

Re: [Bug 17249] New: SdpType usage must be chosen

From: Justin Uberti <juberti@google.com>
Date: Fri, 1 Jun 2012 09:40:15 -0400
Message-ID: <CAOJ7v-2D+u0JXM69ne8n8zUUS0V=3Q7B1jFvf9X5XrHj1fa3Og@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Cullen Jennings <fluffy@cisco.com>, public-webrtc@w3.org
On Fri, Jun 1, 2012 at 12:40 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> On Thu, May 31, 2012 at 9:17 PM, Justin Uberti <juberti@google.com> wrote:
> > I think I could also go either way, but here are some reasons why we
> might
> > not want to embed the type information in the SessionDescription:
> >
> > Not clear what type should be for Specifically, the
> > PeerConnection.localDescription and .remoteDescription properties (could
> > be the type of the last-supplied SessionDescription, but seems like
> > unnecessary information to store; also could be null/empty string in this
> > case)
> > Use of PRANSWER vs ANSWER feels like an application decision; application
> > may want to either
> >
> > set a local PRANSWER, which means the type property needs to be mutable,
> or
> > we need to pass some param into CreateAnswer (which seems somewhat ad
> hoc in
> > the current draft)
> > apply a received ANSWER as a PRANSWER, which means the type property
> needs
> > to be mutable, or the application needs to munge the received JSON
> string.
> Is it safe to get an answer via createAnswer(PRANSWER) and then
> doSetLocal(ANSWER)
> or createAnswer(ANSWER), setLocal(PRANSWER)? My intuition would have been
> no [queue discussion of when callee.onaddstream() is called], but I'm
> willing
> to be convinced it's safe. If so, though, we should probably explicitly
> state it
> in the spec.

I'm not sure createAnswer needs to know if it's a PRANSWER or ANSWER, as
this is simply a choice by the application to finalize the offer-answer
exchange or not. So with that removed, it's simply a question of whether an
arbitrary answer created by CreateAnswer can be used as a PRANSWER or
ANSWER, and I think that this should be allowed.

My intent was that you could always apply a (pr)answer as either type
(i.e., into setLD/setRD). In fact, some of the serial forking scenarios
depend on the ability of the caller to choose which answer is treated as

> -Ekr
Received on Friday, 1 June 2012 13:48:40 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC