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

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

From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 1 Jun 2012 07:51:56 -0700
Message-ID: <CABcZeBOQH_i2W4niWo9Sj-zCh53RZH6ZGGa0+LJ6zhfEFSemOw@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Cc: Cullen Jennings <fluffy@cisco.com>, public-webrtc@w3.org
On Fri, Jun 1, 2012 at 6:40 AM, Justin Uberti <juberti@google.com> wrote:
> 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 final.

I haven't worked through this completely, but I wonder if there is an
opportunity to get confused in federated cases. Consider the 1-800-go-fedex
case. I had assumed that the callee would do:

1. PR_ANSWER with one-way media (from the callee to the caller)
2. ANSWER with two-way media.

In that case, if the caller imposes the PR_ANSWER as a final answer, isn't
this going to create an error? Or have I misunderstood.

Regardless, if we decide that they are interchangeable in this respect
IMO we should remove the argument from createAnswer().

Received on Friday, 1 June 2012 14:53:05 UTC

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