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

"Olle E. Johansson" <oej@edvina.net> Mon, 19 September 2011 11:27 UTC

Return-Path: <oej@edvina.net>
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 7B5B121F8BA7 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 04:27:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.24
X-Spam-Level:
X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 YfB06D4cTmgS for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 04:27:33 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id E265421F8BA0 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 04:27:32 -0700 (PDT)
Received: from [192.168.40.44] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 06C50754BCE4; Mon, 19 Sep 2011 11:29:49 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=us-ascii
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <2B265ADC-44C3-48CC-95A6-B90ED6E42FA7@acmepacket.com>
Date: Mon, 19 Sep 2011 13:29:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D7982AF-7478-4AFD-9F39-ED04A43FEF53@edvina.net>
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>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
X-Mailer: Apple Mail (2.1244.3)
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:27:33 -0000

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. 

/O

> -hadriel
> 
> 
> On Sep 19, 2011, at 2:35 AM, Olle E. Johansson wrote:
> 
>> 
>> 18 sep 2011 kl. 23:10 skrev Harald Alvestrand:
>> 
>>> I don't think we want to support RTCP-less applicaitons; if saying "no" to them helps them not occur (it doesn't always help...)
>> 
>> No, we don't want to support applications without RTCP. +1.
>> 
>> /O