[rtcweb] State of the Forking discussion

[Magnus Westerlund <[e-mail]>]

WG,

I just reviewed the last weeks Forking discussion. This includes the
threads "RTCWeb Forking usecase [was RE:
draft-kaplan-rtcweb-sip-interworking-requirements-00]" and "Media
forking solution for SIP interoperability (without a media gateway)"

As far as I can tell there is not yet even a rough consensus. Therefore
I will attempt to summarize what I personally believe to be the
important points and alternatives in this discussion. Keep in mind that
my assumptions or understanding may be unclear or have errors. So don't
hesitate to challenge what I write.

I think it is important that there are in fact at least two important
questions here.

1. Is forking needed to be supported at all?

2. If it is supported in which form would it supported in.

so lets start looking into the arguments and possibilities for these two
questions. And I do hope that you will read to the end of this mail
which is quite long.

Lets start with the high level functionality part. Is forking needed and
what usage does it have. So forking is all about sending out an
invitation to a media session including an actual media configuration
offer, i.e. SDP Offer, then get more than a single answer to that offer
back. How you deal with these answers as they come in is the difference
between serial and parallel forking. So lets define those.

Parallel forking: For each answer you receive you establish a new actual
media session. Thus if you receive two answers you will have to
different media sessions that are potentially in use at the same time.

Serial forking: The first answer is received and results the
establishment of a media session. At a later point in time a second
answer is received. At that point you take the decision if that second
answer is going to be used to establish a new media session that
replaces the first one. In other words at any given time you will only
have a single media session established based on each offer.

So there has been a number of different views on how one can see on
forking. And I think I will have to bring in a bit reflections on how
this can be done with the current PeerConnection API.

A) No forking is needed: Between WebRTC end-points there is no need for
forking. Instead the application can send out session invitations to the
peers it wants to talk to. These are without any SDP Offer equivalent,
instead end-points that want to communicate they create PeerConnections,
which results in SDP Offers. Thus the communication initiating end-point
becomes the ones that provides SDP answers and get one PeerConnection
per remote end-point that actually want to communicate.

B) We need to have some interworking with SIP: So the fundamental here
is that it needs to be reasonable to interwork with SIP, independent if
one uses a SIP in JS in the application running on the WebRTC enabled
browser, or have signalling gateway in the webserver, or as a remote
WebRTC peer. The issue is that A)'s method of initiating call doesn't
work well with SIP. There is a need to send a SIP Invite with an SDP
Offer and that can result in multiple answers.

To resolve this one could deal with this in a couple of different ways:

B1) Use Iñaki's proposal which forces the WebRTC application to create a
second PeerConnection and then forces an update in the SIP domain with
the second peer-connections Offer. However, it was pointed out that this
doesn't work with SIP Provisional answers, as used by ICE for example,
unless PRACK is supported. The level of PRACK support is reasonable but
far from universal so this would limit the SIP UAs one can interwork
with. However, from WebRTC perspective no forking support is needed. A
single PeerConnection results in one offer and a single answer is
processed.

B2) Require WebRTC to handle replace Answers: So the idea here is that
one changes the PeerConnection API and have underlying functionality so
that at any point in time a new Answer can pushed onto a PeerConnection
and that forces the media session to be reestablished if needed. So if
the ICE candidate list is different an ICE restart happens. This clearly
supports serial forking. It also can create some complexities in the
underlying SDP handling logic if one desires to minimize the media impact.

B3) Local side shared parameters in multiple PeerConnections: The idea
in this proposal is that all PeerConnections generated in a browser
context, like a tab will implicit share the fundamental parameters like
ICE candidates etc for the number of media streams added. So if one
creates a second PeerConnection with the same audio+video MediaStream
object added I will get an offer that is mostly identical to the the
first PeerConnection, thus I can push in the answer from the first
PeerConnection Offer into the second PC object and it will still work.
The downside of this is that it is implicit and it becomes difficult to
determine when it works and when it will fail. It will also be highly
dependent on the application performing the right process to get it to
work. It also causes a sharing of the parameters when not needed or
desired, which primarily is an issue from a security point of view,
especially with SDES keys (see below). The positive is this likely
requires no API changes. This method would also support parallel forking.

B4) Cloning/Factory for PeerConnection: On the API level there will be
explicit support for generating multiple PeerConnections from the same
base. This could either be a factory for PeerConnections or some Object
constructor that clones an existing PeerConnection but that is a W3C
question. By being explicit some of the B3) issues goes away and the
applications can choose when this should happen or not. This also
support parallel forking as the application can deal with each media
session independently. This clearly will have some impact on the API.


Additional considerations:

Shared SDES keys: B2 to B4 will result in that SDES keys from the
Offering party to be used towards all invited parties. This is security
risk as any of the invited parties can spoof the offering side towards
any of the other invited parties. This threat can be resolved by having
the inviter rekey immediately after having received an answer.

Sharing ICE candidates: B3 and B4 and also B2 to some degree will share
the ICE candidates. That has certain implications. One is the positive
in that it minimizes the resource consumption as additional
PeerConnections come at very little extra cost, no need for additional
ICE gathering candidate phases, and also be very quick as no external
communication is required. The downside of this is that the end-points
candidates must always be kept alive as long as some PeerConnection
instance exist. Because the browser never knows when the application may
create an additional PC and expect them to have the same ICE candidates.
It should also be noted that the answering WebRTC end-point will need to
gather candidates for each offer. Otherwise it will become impossible to
create multiple PeerConnections between the same end-points if that is
desired by the application.


I know the above doesn't list all of the pro and cons of the different
alternatives. So please fill in additional arguments. And if I missed
some proposal please add that also if relevant

As you may have noted I the two questions in the above have kind of
floated together. The reason for this is that I think the majority are
fine with having SIP support as long as it doesn't have to high cost or
complexity associated with it. Thus, the question how becomes very
intertwined with forking support yes or no.

So please continue the discussion

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------