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

Colin Perkins <csp@csperkins.org> Wed, 21 September 2011 21:33 UTC

Return-Path: <csp@csperkins.org>
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 A069711E8106 for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 14:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.554
X-Spam-Level:
X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 jUwPxEvIvHpb for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 14:33:48 -0700 (PDT)
Received: from anchor-msapost-3.mail.demon.net (anchor-msapost-3.mail.demon.net [195.173.77.166]) by ietfa.amsl.com (Postfix) with ESMTP id BCA9511E80FB for <rtcweb@ietf.org>; Wed, 21 Sep 2011 14:33:48 -0700 (PDT)
Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.30]) by anchor-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R6USk-00055t-n0; Wed, 21 Sep 2011 21:36:14 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com>
Date: Wed, 21 Sep 2011 22:36:11 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <77ADCDD1-E397-4FF6-B572-BA23167CEF9A@csperkins.org>
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> <4E79 D5DF.4050402@ericsson.com> <68121E70-4363-47F8-8761-23728C56D003@acmepacket.com> <9348BF4A-8674-4888-9DDC-C734FB935A28@csperkins.org> <7B9A57BB-A585-487D-9655-D835C527059B@acmepacket.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
X-Mailer: Apple Mail (2.1084)
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:33:49 -0000

No, as it says, you stop sending if you can't adjust and the loss rate is too high. And, sure, the user will probably hang-up anyway if the quality is bad, but it's worthwhile having a sanity check to drop the call if they don't, whether implemented based on RTCP reports or otherwise.

Colin



On 21 Sep 2011, at 22: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)
> 
> 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/