Re: [rtcweb] State of the Forking discussion

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 09 November 2011 19:19 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B69521F8A6C for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 11:19:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.041
X-Spam-Level:
X-Spam-Status: No, score=-7.041 tagged_above=-999 required=5 tests=[AWL=0.958, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Fznx6XGDXCt for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 11:19:26 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C9F0F21F85F1 for <rtcweb@ietf.org>; Wed, 9 Nov 2011 11:19:25 -0800 (PST)
X-AuditID: c1b4fb39-b7b3eae00000252a-22-4ebad23c1739
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 04.5E.09514.C32DABE4; Wed, 9 Nov 2011 20:19:24 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 9 Nov 2011 20:19:24 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Cullen Jennings <fluffy@cisco.com>
Date: Wed, 09 Nov 2011 20:15:43 +0100
Thread-Topic: [rtcweb] State of the Forking discussion
Thread-Index: Acye7ZtFssqkSE/aSpm6Eaf8TOG4fgAJl7he
Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522357173C8@ESESSCMS0356.eemea.ericsson.se>
References: <4EB26945.40607@ericsson.com> <0E287F18-E335-472D-853A-0A1B449D2AD7@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852235A07275@ESESSCMS0356.eemea.ericsson.se>, <D65A44DE-264B-4CF6-9E72-2780D1E531A8@cisco.com>
In-Reply-To: <D65A44DE-264B-4CF6-9E72-2780D1E531A8@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] State of the Forking discussion
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Nov 2011 19:19:27 -0000

Hi,

>>> Much of this I don't feel too strongly about but there is one
>>> thing that I do have a strong opinion on. I don't want to
>>> require PRACK for legacy SIP support because it is has many problems.
>>
>> If you are not using PRACK, you will not be able to receive a "real" answer before 200 OK, at a point where forking will be no issue anymore :)
>>
>
> I think it is a little more subtle than this. The UAC are not guarantee delivery of the 180s without prack but the UAC typically gets them 
> anyways. Note I am fine with things that do support PRACK, I  just don't want  to require it. I also have had good luck with the systems 
> that send the 180 more than once.

I agree. Many systems use SDPs received in unreliable 180s, as if they would have been received in a reliable 180. 

Of course, a UAC can't send a *new* offer before it has received the SDP reliably, so a forking solution that is based on sending a new offer (read: a solution that requires PRACK) would not work.

Regards,

Christer




>> On Nov 3, 2011, at 4:13 AM, Magnus Westerlund wrote:
>>
>>> 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  +46 10 7148287
>>> Färögatan 6                | Mobile +46 73 0949079
>>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
>>>
>> ----------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb