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

Hadriel Kaplan <HKaplan@acmepacket.com> Mon, 19 September 2011 11:50 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 75EF121F8B9C for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 04:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.516
X-Spam-Level:
X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 mbcDTwl8dNuO for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 04:50:57 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id CE63321F8B00 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 04:50:56 -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; Mon, 19 Sep 2011 07:53:18 -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; Mon, 19 Sep 2011 07:53:18 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: "Olle E. Johansson" <oej@edvina.net>
Thread-Topic: [rtcweb] STUN for keep-alive - RTCP-less applications
Thread-Index: AQHMdsK4ExBrOYyBMkez82rphd/3ng==
Date: Mon, 19 Sep 2011 11:53:18 +0000
Message-ID: <673BCA71-B624-4DCA-B681-7012E6F9D202@acmepacket.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CEB@XMB-BGL-414.cisco.com> <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>
In-Reply-To: <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net>
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="us-ascii"
Content-ID: <DDE259E3E6F365448C02ADF8ADF5A110@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: Mon, 19 Sep 2011 11:50:57 -0000

I agree with everything you said, including the rephrasing at the end. (and is what I meant - be strict on send, liberal on receive)
:)

-hadriel


On Sep 19, 2011, at 7:29 AM, Olle E. Johansson wrote:

> 
> 19 sep 2011 kl. 13:19 skrev Hadriel Kaplan:
> 
>> 
>> I agree for rtcweb <-> rtcweb, but for going to/from non-rtcweb devices this is a problem.  Unfortunately lots of SIP devices don't generate RTCP.  Undoubtedly going to non-rtcweb will often require gateways of some form or other in the media plane, if for nothing else than ICE termination; but making such gateways generate fake RTCP is asking for the price to go up.  :(
>> 
> That takes us back to the core question: How much should we let the old luggage of SIP affect the architecture of the new shining stuff we're creating here?
> 
> I agree that the SIP world has failed in implementing RTCP. Maybe we should discuss why and see what we can come up with. Some of my observations from working with RTCP in SIP:
> 
> - NAT effects on the RTCP stream is mostly not handled
> - RTCP Bye is not really used 
> - Some devices have a policy/setting that says "Send RTCP every Y minute". Calls under Y minutes doesn't get RTCP, not even a BYE with final status
> - A well-known vendor sends RTCP with time stamps from year 2031
> 
> I think the coupling between actual codec quality and RTCP is missing with the ALAW/ULAW codecs. With more adaptive codecs and of course video, RTCP is becoming a requirement.  The current PSTN-centric mostly ALAW/ULAW SIP devices only needs RTCP to measure quality after the call is over which means that it's not a selling feature.
> 
> So if we rephrase the issue: I think RTCP should be a MUST for rtcweb implementations. However, calls should not fail when communicating with RTP implementations that doesn't send RTCP.