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

Hadriel Kaplan <> Thu, 22 September 2011 10:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BC5021F8C76 for <>; Thu, 22 Sep 2011 03:58:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bSGxSQ5SLTJX for <>; Thu, 22 Sep 2011 03:58:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8378321F8C6B for <>; Thu, 22 Sep 2011 03:58:04 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 22 Sep 2011 07:00:34 -0400
Received: from ([]) by ([]) with mapi id 14.01.0270.001; Thu, 22 Sep 2011 07:00:34 -0400
From: Hadriel Kaplan <>
To: Magnus Westerlund <>
Thread-Topic: [rtcweb] STUN for keep-alive - RTCP-less applications
Thread-Index: AQHMeRbZIKUT9mUbYkyr0iQzRJ1k0w==
Date: Thu, 22 Sep 2011 11:00:32 +0000
Message-ID: <>
References: <> <> <> <> <> <092401cc749b$8fd64940$af82dbc0$@com> <> <> <> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
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 10:58:05 -0000

On Sep 22, 2011, at 3:48 AM, Magnus Westerlund wrote:

> On 2011-09-21 23:19, Hadriel Kaplan wrote:
>> We still don't need RTCP for that - use received RTP sequence number
>> gaps, if necessary. (yeah it assumes symmetric path and bandwidth,
>> and bi-dir media)
> That doesn't really work without RTCP. You are assuming that path load
> is symmetric so that any loss in A-B direction will be correspondingly
> reflected on the flow in B-A direction. That is certainly not a common
> property for IP paths. Thus without RTCP the sender has no knowledge
> about what packet loss rate his flow is seeing.

That would be the part where I said "(yeah it assumes symmetric path and bandwidth, and bi-dir media)".

>> 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.

>> 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.

> 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.