Re: [rtcweb] STUN for keep-alive

sisalem <sisalem@iptel.org> Wed, 14 September 2011 15:09 UTC

Return-Path: <sisalem@iptel.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 E0A1421F8B71 for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 08:09:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 o6blsZJvzytx for <rtcweb@ietfa.amsl.com>; Wed, 14 Sep 2011 08:09:11 -0700 (PDT)
Received: from mail.iptel.org (smtp.iptel.org [213.192.59.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4144F21F8B61 for <rtcweb@ietf.org>; Wed, 14 Sep 2011 08:09:11 -0700 (PDT)
Received: by mail.iptel.org (Postfix, from userid 103) id 6A8FC37054B; Wed, 14 Sep 2011 17:11:19 +0200 (CEST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.iptel.org with ESMTPSA id D859E37053D
Message-ID: <4E70C415.20000@iptel.org>
Date: Wed, 14 Sep 2011 17:11:17 +0200
From: sisalem <sisalem@iptel.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <7F2072F1E0DE894DA4B517B93C6A05852233EDB21D@ESESSCMS0356.eemea.ericsson.se> <1D062974A4845E4D8A343C653804920206648CB0@XMB-BGL-414.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233EDB264@ESESSCMS0356.eemea.ericsson.se> <C3759687E4991243A1A0BD44EAC8230339CA72C234@BE235.mail.lan> <4E70C27A.9040805@jesup.org>
In-Reply-To: <4E70C27A.9040805@jesup.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] STUN for keep-alive
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, 14 Sep 2011 15:09:12 -0000

  as far as I remember this was more thought for multicast sessions. for 
unicast the interval was 5 seconds (+-50%)

cheers

On 9/14/11 5:04 PM, Randell Jesup wrote:
> On 9/14/2011 7:45 AM, Jonathan Lennox wrote:
>> Christer Holmberg writes:
>>> Well, it depends on the amount of outgoing media traffic, but in 
>>> cases where you only receive media you would still need to send 
>>> keep-alives.
>> Remember, RTCWeb is (probably) mandating RTP/RTCP mux.  I'd need to 
>> do some math to be certain, but I'm pretty sure that in almost all 
>> normal circumstances, the RTCP regular reporting interval should be 
>> significantly smaller than the STUN keepalive interval.
>
> Agreed; I think it would require a bizarre session setup (RR=0) to 
> force the RTCP interval out far enough to cause problems.  (Don't 
> forget to include the +- 50% in the calculation.)
>
> RFC 3556:
>
>       o  If RR is zero, then the proportion of participants that are
>          senders can never be greater than RS/(RS+RR), and therefore
>          non-senders never get any RTCP bandwidth independent of the
>          number of senders.
>
>
> Obviously, RR values near 0 could also cause a problem.  A statement 
> about not using RR values that would result in RTCP intervals greater 
> than N should be enough I think.
>
> BTW: Have we mandated that RTP & RTCP be muxed always to all 
> destinations, or that it must be supported and offered?  If you're 
> talking to a legacy device that doesn't mux, what happens?
>