Re: Proposed update to API spec for JSEP

On 03/19/2012 03:01 AM, Cullen Jennings wrote:
>
> I've been working on a proposal for how to change the API spec to be
> inline with JSEP. I have attached the proposed change to this email
> along with a diff. These are far from perfect and some more would need
> to be done but ... I think they get the main structure and are enough to
> start talking about if we want to use this a starting point for the
> Editor draft.
>
> Have a look at section 4.1 and review it from the point of view of, is
> this close enough to start using as the editor draft.

I would really like to have an example in the spec as well. The one from 
the JSEP draft [1] could be used, but I some comments regarding it.

For example, no media is included in the offer since the offer is 
created before addStream() is called. I believe it can be fixed by 
moving the creation of the offer to maybeSignal() since then we're 
guaranteed to have both a MediaStream and candidates at that time. (Diff 
below.)

     ...
     // if we're the caller, create and install our offer,
     // and start candidate generation
     if (isCaller) {
-     offer = pc.createOffer(null);
-     pc.setLocalDescription(SDP_OFFER, offer);
       pc.startIce();
     }
   }

   function maybeSignal(isCaller) {
     // only signal once we have a local stream and local candidates
     if (localStreams.size() == 0 || !hasCandidates) return;
     if (isCaller) {
+     offer = pc.createOffer(null);
+     pc.setLocalDescription(SDP_OFFER, offer);
-     offer = pc.localDescription;
       signalingChannel.send(JSON.stringify({ "type": "offer",
                                              "sdp": offer }));
     } else {
       // if we're the callee, generate, apply, and send the answer
       answer = pc.createAnswer(pc.remoteDescription, null);
       pc.setLocalDescription(SDP_ANSWER, answer);
       signalingChannel.send(JSON.stringify({ "type": "answer",
                                              "sdp": answer }));
     }
   }
   ...

Looking at the basic signaling model used in the example, can the B-side 
really call setRemoteDescription() with the offer directly when the 
offer arrives? If that means that media can start flowing from B to A, 
then A won't know how to map incoming media to MediaStream objects 
(including label initialization) before it has processed B's answer. For 
example, if many rtp streams arrive, are those tracks in one MediaStream 
or separate MediaStream objects?

BR
Adam

[1] http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-00#section-8

Received on Tuesday, 20 March 2012 16:56:01 UTC