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

Magnus Westerlund <> Thu, 22 September 2011 07:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5624221F8D64 for <>; Thu, 22 Sep 2011 00:45:57 -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 aeXE3Z9vD7yX for <>; Thu, 22 Sep 2011 00:45:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5962721F8D60 for <>; Thu, 22 Sep 2011 00:45:56 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c47ae000000b17-86-4e7ae84a3451
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 34.99.02839.A48EA7E4; Thu, 22 Sep 2011 09:48:26 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 22 Sep 2011 09:48:20 +0200
Message-ID: <>
Date: Thu, 22 Sep 2011 09:48:14 +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 07:45:57 -0000

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.

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

> Really, the user will hang up if call quality sucks.  We don't need
> to be smarter than humans.

Well, the complications with G.711 is that there can be quite
significant loss before you don't understand anything.

But, if I interpret correctly
for reasonably long paths we will in fact talk about such high packet
loss rates the call will be use less.

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.

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.


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: