Re: [rtcweb] STUN for keep-alive - RTCP-less applications

Magnus Westerlund <> Thu, 22 September 2011 12:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2D0521F8C45 for <>; Thu, 22 Sep 2011 05:28:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.523
X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XHR2kHNX-uYj for <>; Thu, 22 Sep 2011 05:28:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BD31A21F8C1E for <>; Thu, 22 Sep 2011 05:28:05 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c47ae000000b17-77-4e7b2a6cfafd
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 83.A1.02839.C6A2B7E4; Thu, 22 Sep 2011 14:30:36 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 22 Sep 2011 14:30:35 +0200
Message-ID: <>
Date: Thu, 22 Sep 2011 14:30:29 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Hadriel Kaplan <>
References: <> <> <> <092401cc749b$8fd64940$af82dbc0$@com> <> <> <> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.1
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "<>" <>, Colin Perkins <>
Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Sep 2011 12:28:06 -0000

On 2011-09-22 13:00, Hadriel Kaplan wrote:
> On Sep 22, 2011, at 3:48 AM, Magnus Westerlund wrote:
>> On 2011-09-21 23:19, Hadriel Kaplan wrote:
>>> But anyway, there is no means of "dialing-down" G.711.  It's not 
>>> adaptive.  Or are we saying the sender should start skipping
>>> samples and hope the receiver does PLC?
>> Well, switch to a lower bandwidth codec.
> That's not really possible in the PSTN. :( One could drop it to AMR
> or G.729 in some cases, but those are under royalty so I doubt an
> rtcweb browser will do them.

Yes, I agree that there will be cases where one doesn't have a choice
between hanging up. But, I think that must be part of the map.

>>> Really, the user will hang up if call quality sucks.  We don't
>>> need to be smarter than humans.
>> However, that is still not the only issue here. I agree that as
>> long as there is a human in the other end listening to the flow
>> that is fine.
>> But if you don't have a human listening the premise of RTCWEB is
>> that you will be able to establish data flows across a path that is
>> in fact not connected to the rendering element in the other end.
>> Thus no user will detect the high packet loss and turn of the flow.
>> It will continue and be a DoS attack on the congested link because
>> this flow takes significantly more than its fair share.
>> That is my issue.
> Right, but as I said previously, if the concern is a malicious
> server/JS, it can do it anyway even with congestion control. If the
> concern is just that the far-end is dead or terminated the call but
> the local side didn't get the memo, we can solve that other ways.

For the first part, I think we will need some protection against this
case, especially opening high bandwidth flows. Having a startup rate of
64 kbps is likely working in so many network that it isn't unreasonable.

And when it comes to open new PeerConnections, one protection from the
browser side is to have a memory of what media rates that was last used.
So if one open a new connection after terminating one that was limited
to 20kbps just seconds before, then you are very conservative when
starting a new peerConnection.

On the last issue, do you have a suggestion for how to achieve this that
isn't RTCP?

>> We are coming back to the most difficult trade-offs for RTCWEB.
>> Legacy interoperability vs Security. We have several different
>> aspects which makes legacy interoperability with a too simple
>> device a big security risk.
>> Media transmission consent -> Requiring ICE support Path Overload
>> DoS concerns -> Requiring Congestion Control for both media and
>> data. RTCWEB deployment model and concerns for privacy and
>> confenditality -> Media security (what level is still not agreed
>> on)
>> All of the above are clear barriers against legacy
>> interoperability.
> Yup.  I don't doubt we'll need some form of media-plane gateway
> either in the web server or separate to interop with legacy - I'm
> just trying to keep it from becoming so expensive and complicated
> that it would be cheaper/easier/better to use SIP softclients or
> plugins instead.

I understand and support that we shouldn't have unnecessary
complications for legacy interop. However, but I don't see it being done
by compromising security to the level where RTCWEB can't be deployed
even for browser to browser usage.


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: