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

Hadriel Kaplan <HKaplan@acmepacket.com> Wed, 21 September 2011 21:17 UTC

Return-Path: <HKaplan@acmepacket.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 5740111E8159 for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 14:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Level:
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599]
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 dhq8BQIdSWvI for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 14:17:26 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 784AA11E80AA for <rtcweb@ietf.org>; Wed, 21 Sep 2011 14:17:26 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 21 Sep 2011 17:19:55 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.150]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 21 Sep 2011 17:19:54 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Colin Perkins <csp@csperkins.org>
Thread-Topic: [rtcweb] STUN for keep-alive - RTCP-less applications
Thread-Index: AQHMeKQ0revNZCpKZk2vREKrpukpxg==
Date: Wed, 21 Sep 2011 21:19:54 +0000
Message-ID: <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852233EDB2F0@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648D0F@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB3E5@ESESSCMS0356.eemea.ericsson.se> <4E70D2E6.1000809@alvestrand.no> <CABcZeBORi5NLSsztnMfkwL43p9oKG9mi6e1WWOaiafAO_DpTVg@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FA3@ESESSCMS0356.eemea.ericsson.se> <CABcZeBO9hUSYZhLrcfbaK9HLGXq-q1EvqWOy6-gAN5xom6Z2-A@mail.gmail.com> <092401cc749b$8fd64940$af82dbc0$@com> <CABcZeBPgRD6kb2gg=m9NckSa1wrzwzJS6527nYqFG34b0cjfgQ@mail.gmail.com> <4E765E4A.3050801@alvestrand.no> <7532C74D-D0D7-474D-80C7-61C07E9290AA@edvina.net> <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acme packet.com> <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net> <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com> <4E799E18.30000@ericsson.com> <855B9078-A81F-45D9-B12F-46CC46C15B60@acmepacket.com> <4E79D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org>
In-Reply-To: <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <2D9CE48B683F3C4AB37CF3715E2CB2AA@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] STUN for keep-alive - RTCP-less applications
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, 21 Sep 2011 21:17:27 -0000

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)

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?

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

-hadriel


On Sep 21, 2011, at 4:34 PM, Colin Perkins wrote:

> On 21 Sep 2011, at 20:30, Hadriel Kaplan wrote:
>> 
>> BTW, are you suggesting that even with G.711, that rtcweb do some form of congestion control based on the RTCP packets?  At that point we're not even talking about RTP/AVP for PCMU/PCMA then are we?  This is some new profile, not AVP.
> 
> 
> Well, the AVP spec [RFC3551, page 5] does say:
> 
>      If best-effort service is being used, RTP receivers SHOULD monitor
>      packet loss to ensure that the packet loss rate is within
>      acceptable parameters.  Packet loss is considered acceptable if a
>      TCP flow across the same network path and experiencing the same
>      network conditions would achieve an average throughput, measured
>      on a reasonable timescale, that is not less than the RTP flow is
>      achieving.  This condition can be satisfied by implementing
>      congestion control mechanisms to adapt the transmission rate (or
>      the number of layers subscribed for a layered multicast session),
>      or by arranging for a receiver to leave the session if the loss
>      rate is unacceptably high.
> 
>      The comparison to TCP cannot be specified exactly, but is intended
>      as an "order-of-magnitude" comparison in timescale and throughput.
>      The timescale on which TCP throughput is measured is the round-
>      trip time of the connection.  In essence, this requirement states
>      that it is not acceptable to deploy an application (using RTP or
>      any other transport protocol) on the best-effort Internet which
>      consumes bandwidth arbitrarily and does not compete fairly with
>      TCP within an order of magnitude.
> 
> 
> -- 
> Colin Perkins
> http://csperkins.org/
> 
> 
>