Re: [rtcweb] TCP vs UDP for media

"Young, Milan" <Milan.Young@nuance.com> Wed, 16 May 2012 01:37 UTC

Return-Path: <Milan.Young@nuance.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 62A1E11E809A for <rtcweb@ietfa.amsl.com>; Tue, 15 May 2012 18:37:58 -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 klBCQQflV0hZ for <rtcweb@ietfa.amsl.com>; Tue, 15 May 2012 18:37:57 -0700 (PDT)
Received: from som-mx-a.nuance.com (som-mx-a.nuance.com [198.71.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id A8E7511E8095 for <rtcweb@ietf.org>; Tue, 15 May 2012 18:37:57 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: As0EAIUDs08KHBQZ/2dsb2JhbABEsWODJ4IVAQEBBDolGgwEAgEIDQEDBAEBAQoUCQcyFAkIAQEEAQ0FCIYKvSOLHIR1YwScFI0SgV8
Received: from unknown (HELO SOM-CAS02.nuance.com) ([10.28.20.25]) by som-mx-a.nuance.com with ESMTP/TLS/AES128-SHA; 15 May 2012 21:22:31 -0400
Received: from SOM-CAS03.nuance.com (10.28.20.26) by SOM-CAS02.nuance.com (10.28.20.25) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 15 May 2012 21:37:55 -0400
Received: from SOM-EXCH04.nuance.com ([fe80::b1be:1c21:d7f8:543c]) by SOM-CAS03.nuance.com ([::1]) with mapi id 14.02.0283.003; Tue, 15 May 2012 21:37:55 -0400
From: "Young, Milan" <Milan.Young@nuance.com>
To: Eric Rescorla <ekr@rtfm.com>, Ralph Giles <giles@thaumas.net>
Thread-Topic: [rtcweb] TCP vs UDP for media
Thread-Index: Ac0y8YFlKfCoI+0LRZ2tsFbI0SJeNwAI96AAAABJd4AABPKcoA==
Date: Wed, 16 May 2012 01:37:54 +0000
Message-ID: <B236B24082A4094A85003E8FFB8DDC3C1A45AFA0@SOM-EXCH04.nuance.com>
References: <B236B24082A4094A85003E8FFB8DDC3C1A45AE47@SOM-EXCH04.nuance.com> <4FB2E8FC.40404@thaumas.net> <CABcZeBPWiGYaD6yBtBzeZMNgnz20JnHTyVHTev71KZagGRiqHw@mail.gmail.com>
In-Reply-To: <CABcZeBPWiGYaD6yBtBzeZMNgnz20JnHTyVHTev71KZagGRiqHw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.28.16.110]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] TCP vs UDP for media
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, 16 May 2012 01:37:58 -0000

Yes, existing web technologies for transport would work fine.  In fact I wrote a demo based on WebSockets, the AudioAPI, and getUserMedia.  But it's a bit cludgy and only transmits PCM audio.

Would my use case for live access to an encoded media stream be a good fit for a revised MediaStreamRecorder?  Would this group the right place to host such an effort?

 Thanks

-----Original Message-----
From: Eric Rescorla [mailto:ekr@rtfm.com] 
Sent: Tuesday, May 15, 2012 4:47 PM
To: Ralph Giles
Cc: Young, Milan; rtcweb@ietf.org
Subject: Re: [rtcweb] TCP vs UDP for media

On Tue, May 15, 2012 at 4:38 PM, Ralph Giles <giles@thaumas.net> wrote:
> On 12-05-15 4:22 PM, Young, Milan wrote:
>
>> I'm wondering if any thought has been given to TCP as a media transport.
>
> Where low latency transmission isn't an issue, one can generally fall 
> back to established TCP-based protocols, like HTTP streaming and 
> websockets, so we haven't really worried about that angle in the 
> context of webrtc.
>
> Recording the stream is a requirement, so probably something could be 
> built using that, merging recordings from each endpoint to fix up any 
> dropped packets.

Agreed. This seems like something that could be done using just
getUserMedia() plus existing Web technologies.

-Ekr