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

Hadriel Kaplan <HKaplan@acmepacket.com> Wed, 21 September 2011 19:28 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 2FA211F0C3E for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 12:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 NpIip0ZOyrlM for <rtcweb@ietfa.amsl.com>; Wed, 21 Sep 2011 12:28:06 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8A11621F86A1 for <rtcweb@ietf.org>; Wed, 21 Sep 2011 12:28:06 -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 15:30:35 -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 15:30:34 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Thread-Topic: [rtcweb] STUN for keep-alive - RTCP-less applications
Thread-Index: AQHMeJTub4qgCfdVkkmpwdeGsRq+9g==
Date: Wed, 21 Sep 2011 19:30:34 +0000
Message-ID: <68121E70-4363-47F8-8761-23728C56D003@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>
In-Reply-To: <4E79D5DF.4050402@ericsson.com>
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: <AC6A39B179B77541AE7FF430B205869A@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 19:28:07 -0000

On Sep 21, 2011, at 8:17 AM, Magnus Westerlund wrote:

> On 2011-09-21 11:02, Hadriel Kaplan wrote:
>> 
>> On Sep 21, 2011, at 4:19 AM, Magnus Westerlund wrote:
>> 
>>> If I interpret this correctly, you are arguing that an RTCWEB 
>>> implementation shall support a remote end-point that doesn't
>>> support RTCP.
>> 
>> Yes, although we could make that allowance/exception for audio only -
>> in fact, G.711 only if it comes down to it.
> 
> Well, I don't know if we can argue that one past the Transport Area
> Director?

Hmmm… how about by pointing out this is RTP over UDP and not TCP, and that we're following RFC 3550, which does not mandate reception of RTCP to continue the session?  I would think a Transport Area AD would know how UDP works. ;)


> I know I can argue 400 bps as an acceptable non congestion
> controlled rate. And that is because that is the equivalent of a full
> backed off TCP connection that sends one full Ethernet frame every 30
> seconds. We probably can argue 4kbps also as an acceptable rate. But
> getting to the next magnitude is more problematic, especially in the
> light that there still exist a reasonable large number of access links
> around the world that don't have more than a few 10kbps in capacity.

Then the call quality will suck and the user will hang up.

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.

-hadriel