Subject: [rtcweb] Analyzing JSEP

From: Justin Uberti <[email-masked]>
Date: Fri, 27 Jan 2012 17:56:10 -0500

Here are the answers to Magnus' questions from the JSEP standpoint. Please
reply in a new thread regarding specific points.

A) Glare handling: How does the signaling handle situations where both
end-points initiate negotiation, updates or re-negotiate at the same
time (i.e. messages pass each other in-flight between the peers)?

As JSEP is agnostic of signaling protocol, these details are left to the
application and/or the previously mentioned
JSEP-to-your-favorite-signaling-protocol JS library. In other words, the
application can use an existing mitigation strategy from ROAP, Jingle, or
SIP, or if it has special needs, it can implement its own algorithm to
determine who wins (such as perhaps always favoring the server's change, in
a centralized conferencing scenario).

B) Can media clipping occur at the initial media establishment? Can it
occur at re-negotiations? Initially this shouldn't happen as long as
media configuration is in place prior to ICE promotes any candidate
pairs. However, at media re-negotiation this could occur. And when you
split the transport setup from media negotiation it becomes an issue again.

There are various ways media clipping can typically occur at media
establishment:
a) ICE has not completed by the time of the callee's answer
b) when using SDES-SRTP, the race that occurs between the answer's keys (in
signaling) and the ciphertext media
c) when using DTLS-SRTP, DTLS-SRTP is not established by the time of the
callee's answer
d) delays between the callee answering and media transmission starting (if
media transmission does not start at the time of the answer)

JSEP can help with preventing these problems. For (a), JSEP can allow ICE
to start more quickly, by virtue of the fact that candidates can be
supplied as soon as they are gathered (subject to previous discussions
about address privacy); this can also be extended to (c), allowing DTLS to
be brought up while the offer is pending. (The ringtone for the callee
could even be delayed until these protocols complete.) For (d), media
transmission can begin immediately upon the callee's answer, so this is not
an issue.

(b) is not directly addressed in the current JSEP draft, but one could
imagine an application signaling protocol that decoupled callee consent
from the callee's session description, allowing the SRTP keys to be
provided while waiting for the callee's answer. This would simply mean
adding a new API to JSEP that controls when media transmission should start.

Similar issues exist when adding media to an existing session, which can be
handled as shown above with JSEP.

C) Does the glare handling result in periods where either side is
prevented from updating offers? For example is it possible to send a new
offer immediately after sending an answer to the peer's Offer? This
becomes important as we are likely having declarative media stream
information, like the Media Stream ID mapping to SSRCs for each media
stream an end-point intends to send.

In JSEP, it is possible to send an offer while an offer is outstanding,
providing you are willing to handle the complex outcome of the callee
accepting the initial offer. This decision is left up to the application;
if the application chooses to use a signaling protocol that does not permit
re-offers, the application won't have this flexibility (or complexity).

The only invalid states in JSEP involve sending an unsolicited answer, or
replying to an offer with an offer. JSEP's handling of early media requires
more specification, to avoid the final answer from being treated as an
unsolicited answer.

D) Is it possible to provide additional ICE candidate's after the
initial offer? What level of complexities does that incur?

Yes. JSEP allows additional candidates to be provided at any time. However,
when using signaling protocols that do not permit candidates to be sent
after the initial offer, applications will need to choose at what point
they decide to stop gathering candidates and transmit their offer. JSEP
will provide applications with information about the allocation process so
that they can know when all expected candidates have been gathered (and
potentially, when 'enough' candidates have been gathered, e.g. local+turn
for at least 1 interface).

Since candidates are handled separately from the rest of the session
description, some work is required by the application to glue the gathered
candidates into the session description. This could easily be done by the
JS library mentioned above.

E) Is it possible to establish transport session which completes ICE
processing without negotiating any media, or at least without forcing
the user to assign media resource to it (not having to run getUserMedia
in the API)? Some versions of WhatWG API did establish a data channel by
default, which could be one option but other possibilities do exist.

Yes. Using JSEP, the application can establish a "placeholder" session,
i.e. an audio/video session with no mediastreams attached. An offer for
such a session can be done by calling createOffer with the appropriate
hints to enable audio/video. Or, it could create a session with just a data
channel, by adding a DataStream to the session before calling createOffer.

Depending on the callee, this may cause some problems; clients that don't
expect these kinds of placeholder sessions will end up doing ghost rings.

F) How does one support forking, and specifically can one deal with;

 - F1) Parallel forking? I.e. deal with multiple answers to
      a given offer and establish multiple flows?

      This is a signaling protocol issue, and JSEP can handle this however
the application wants to deal with it. JSEP can receive candidates from
multiple endpoints, and proceed with the endpoint that accepts the call.

 - F2) Sequential/Serial Forking? i.e. receive one answer and
      later get a second answer to the same initial offer and
      use that to replace the first?

      This is handled the same way JSEP will deal with early media,
specifically by having some notion of a non-final answer.

G) How does the proposal attempt to improve the time until media is
negotiated and can flow between the peers.

As mentioned in (D), JSEP allows the initial candidates to be transmitted
immediately, with other candidates provided later. It can also bring up ICE
and DTLS while waiting for the remote side to accept.

If the endpoint of the call is known a priori, and it is a compatible
endpoint, the techniques in (E) could be employed to have the call live and
simply waiting for media to be added.

H) What explicit indication or other hints can the upper layer get from
the proposal get that this might be a suitable time to perform a
re-negotiation or is it automatically triggered by the browser core?

Renegotiation will typically need to be done explicitly by the application
when a condition that requires re-signaling occurs (e.g. when a media/data
stream is added/removed/stopped).