IETF Logo Mail Archive

Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP

Cullen Jennings <fluffy@iii.ca> Thu, 23 April 2015 19:44 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D621B31AC for <rtcweb@ietfa.amsl.com>; Thu, 23 Apr 2015 12:44:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9lha5rPjCza for <rtcweb@ietfa.amsl.com>; Thu, 23 Apr 2015 12:44:32 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836491B31CF for <rtcweb@ietf.org>; Thu, 23 Apr 2015 12:44:26 -0700 (PDT)
Received: from [192.168.4.100] (unknown [128.107.241.181]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 99DA9509C4; Thu, 23 Apr 2015 15:44:24 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <7B9A5F8B-5269-4CB3-8741-976AB7BAA9C6@csperkins.org>
Date: Thu, 23 Apr 2015 13:44:22 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <A368210C-B789-4B8C-A055-BECDF9580856@iii.ca>
References: <CAOJ7v-01DhCKewmC-Cvh4Z-jeOmi=CunisjFWceoPfk2ZM9Wgg@mail.gmail.com> <CABkgnnWvU+aYT9zgwEXCUhaO98y9kPyKwHnT=KXSr8O=knfW8w@mail.gmail.com> <CAPvvaa+SNPY+Ait2c8w9GPT-QfP7LEiuU6ejrokba93k60DdVg@mail.gmail.com> <CABkgnnW6KFuJhswLK97LE6J=9vqkf-cmeRMZOuz516ZryeSRQw@mail.gmail.com> <CAPvvaa+wid8y2h0g2040V8bSr50+rQRzpg-tCTK9EUFmtJrZYw@mail.gmail.com> <CABkgnnUt2fwdOWqTjHUjkUZN_aqAfrBW90Q4Q-EPrid4sCSWQg@mail.gmail.com> <BB960D2D-3176-4D54-8133-7F12B79DCAFA@cisco.com> <CABkgnnWuRYW8w6xCLt2dJVZ1ePxAxZWbyYqrV68cZaA2uHgmGg@mail.gmail.com> <CAOJ7v-3W7+Lfd8DCs_91K_DGaqjdyZ_qtkoQBiSO2pi-j1fuOA@mail.gmail.com> <CABkgnnXOXc+Jq4mSq02_As9ii5g_EpeRnO_sVF+OnZrLoGC9Xg@mail.gmail.com> <CAOJ7v-0niXySrvkPnSGXA5YVe_O5YVvae_8zGsEYtPqpw43UZw@mail.gmail.com> <CABkgnnWzdn9FVO27G7ioz5soLhckseAEEHV+QZJsyiTOD_sYnA@mail.gmail.com> <551A902A.9080402@alvestrand.no> <CABkgnnU+r-8UXXMVKt_eiK_hd3eutWpUXiGQ=KsGrwCxB11cMg@mail.gmail.com> <55361DCA.7000101@ericsson.com> <553621A8.5000400@alvestrand.no> <7B 9A5F8B-5269-4CB3-8741-976AB7BAA9C6@csperkins.org>
To: Colin Perkins <csp@csperkins.org>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/54g_jCGGNs6K0XYKpOhygpaBLu0>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] [Suspected Junk Mail] Endpoints that don't support RTCP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 23 Apr 2015 19:44:33 -0000

> On Apr 22, 2015, at 4:44 PM, Colin Perkins <csp@csperkins.org> wrote:
> 
>> Perpetuating tolerance for the broken behavior of ignoring "MUST send
>> RTCP" seems like a path that doesn't lead to getting rid of the behavior
>> in the end.
> 
> I tend to agree: this seems like something where the gateway ought to handle the interoperability, and synthesise appropriate RTCP. 
> 
> Or, if that's really too onerous, tie into some other consent check that can indicate that the flow is still wanted and not causing problems.

People keep talking about gateway's but I'm talking about endpoints that do ICE and DTLS-SRTP but don't do RTCP. They also don't do video. 

The reason they don't do RTCP is because they don't perceive a value in it. I'm not arguing this is right or wrong, I'm just saying they don't see the value. The point the folks that think this is a good idea make is that if RTCP says there is X jitter, or Y % packet loss, there is nothing they can do with this. They will not stop the call until the audio is so bad that user hangs up. Only the user hanging up stops the call. Thus the only thing RTCP does is cause more congestion. Again, not saying this is right but given that most the audio only RTP I see on the network does not have RTCP, I don't think this is likely to change any time soon.  And I want to say again, for video it is the opposite story, the bulk of the interactive video RTP I see has RTCP.

v2.23.0 | Report a Bug | By Email