IETF Logo Mail Archive

Re: [pntaw] Real-time media over TCP

Bernard Aboba <bernard_aboba@hotmail.com> Mon, 02 September 2013 18:17 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C5521E8085 for <pntaw@ietfa.amsl.com>; Mon, 2 Sep 2013 11:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.713
X-Spam-Level:
X-Spam-Status: No, score=-101.713 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
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 VUPoI9iVo8EF for <pntaw@ietfa.amsl.com>; Mon, 2 Sep 2013 11:17:12 -0700 (PDT)
Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by ietfa.amsl.com (Postfix) with ESMTP id DF73D11E8139 for <pntaw@ietf.org>; Mon, 2 Sep 2013 11:17:11 -0700 (PDT)
Received: from BLU405-EAS183 ([65.55.111.72]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Sep 2013 11:17:11 -0700
X-TMN: [UbhcZvp+j2V0lPlaNY948C4/BFyu3dil]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU405-EAS183E36A927CA42270B6936D93300@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
References: <CAGTXFp92jSzQz05uHngzscz88n=fT_JPbEvQRxgeUUqPVRQUyQ@mail.gmail.com> <52244DD7.1020900@alvestrand.no>
From: Bernard Aboba <bernard_aboba@hotmail.com>
MIME-Version: 1.0 (1.0)
In-Reply-To: <52244DD7.1020900@alvestrand.no>
Date: Mon, 02 Sep 2013 11:17:10 -0700
To: Harald Alvestrand <harald@alvestrand.no>
X-OriginalArrivalTime: 02 Sep 2013 18:17:11.0658 (UTC) FILETIME=[A4B0D4A0:01CEA808]
Cc: "pntaw@ietf.org" <pntaw@ietf.org>
Subject: Re: [pntaw] Real-time media over TCP
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2013 18:17:16 -0000

If the issue is firewall restrictions on UDP, then the data channel is not likely to be a workable option. The question for me is how far we need to go to solve this (e.g. RFC 6062? 6544?). The scenario where both sides are behind UDP blocking firewalls is not common, but it does occur.

On Sep 2, 2013, at 1:37 AM, "Harald Alvestrand" <harald@alvestrand.no> wrote:

> On 08/30/2013 12:12 PM, Victor Pascual Avila wrote:
>> Hi,
>> 
>> Real-time media over TCP has some inherent challenges -- is this
>> something we're planning to discuss here? We did RTP over TCP (+ HTTP
>> CONNECT) in the past and ended up using multiple connections along
>> with application-layer redundancy. I'm wondering whether we'll be able
>> to do the same when moving to WebRTC
> 
> If you really want to go there, I suggest you take a good hard look at either SCTP or TCP Minion (draft-iyengar-minion-concept-01.txt).
> 
> The RTCWeb stack already uses SCTP over DTLS over UDP.
> 
> In either case, I don't think performance of RTP over reliable transport is a firewall-related issue.
> 
> _______________________________________________
> pntaw mailing list
> pntaw@ietf.org
> https://www.ietf.org/mailman/listinfo/pntaw

v2.23.0 | Report a Bug | By Email