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

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.
   - Applying a received OFFER as an ANSWER also requires mutating the type
   property (recall this approach can be used for doing glareless adds of
   streams)
   - Can't create SessionDescription object simply from SDP string;
   SessionDescription serializes to/from { type: x, sdp: y } JSON object

The main downside of having type/sdp separate means the app needs to
manually write out the { type, sdp } tuple when sending a SD, and pass both
parameters into the setLocal/RemoteDescription function when received a SD.
The main upside is that the application can easily change the type if
needed.

On Thu, May 31, 2012 at 2:49 PM, Cullen Jennings <fluffy@cisco.com> wrote:

>
> My simple answer is the SessionDescription gets used a few places - often
> you need the type info when the SessionDescription is consumed. Any time
> SessionDescription is produced, it is trivial for browser to add the type
> info. It's really no extra work for browser to put it in the
> SessionDescription. If the browser does not, then the application has to
> keep track of it. So in the name of make it easier for the JS programmer,
> and no real extra work for browsers, my preference is put type in
> SessionDescription. If the application wants to keep track of the type
> outside of the SessionDescription, it certainly can do that even if the
> type is in the SessionDescription.
>
> My more complex answer is that I think it was a design mistake in SDP that
> one can't tell if the type of the SDP from just looking at the SDP. Putting
> it in SessionDescription helps correct that mistake and makes it easier for
> the browser to produce reasonable error messages if the wrong type of SDP
> is passed in. Detecting error and reporting rational error messages is
> going to be hard and this will help.
>
> My 2 cents - and of course either will work - both would be bad.
>
>
>
> On May 30, 2012, at 8:15 AM, bugzilla@jessica.w3.org wrote:
>
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=17249
> >
> >           Summary: SdpType usage must be chosen
> >           Product: WebRTC Working Group
> >           Version: unspecified
> >          Platform: All
> >        OS/Version: All
> >            Status: NEW
> >          Severity: normal
> >          Priority: P2
> >         Component: WebRTC API
> >        AssignedTo: public-webrtc@w3.org
> >        ReportedBy: harald@alvestrand.no
> >                CC: public-webrtc@w3.org
> >
> >
> > At the moment (May 30), the spec contains:
> >
> > [Constructor (DOMString description)]
> > interface SessionDescription {
> >    attribute SdpType   type;
> >    attribute DOMString sdp;
> >    stringifier DOMString ();
> > };
> >
> > and in PeerConnection:
> >
> >    void        setLocalDescription (SdpType action, SessionDescription
> > description);
> >    void        setRemoteDescription (SdpType action, SessionDescription
> > description);
> >
> > The SdpType should either be a property of a SessionDescription or an
> argument
> > to to Set*Description, not both.
> >
> > Either we get an argument in favour of one or the other, or we should
> flip a
> > coin.
> >
> > --
> > Configure bugmail:
> https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
> > ------- You are receiving this mail because: -------
> > You are on the CC list for the bug.
> > You are the assignee for the bug.
> >
>
>
>