Re: [rtcweb] 5 tuples and rmcat-cc-requirements-01

Eric Rescorla <ekr@rtfm.com> Wed, 01 January 2014 15:41 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0102F1AE32B for <rtcweb@ietfa.amsl.com>; Wed, 1 Jan 2014 07:41:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHBozjVx57LN for <rtcweb@ietfa.amsl.com>; Wed, 1 Jan 2014 07:41:36 -0800 (PST)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 7999F1AE30D for <rtcweb@ietf.org>; Wed, 1 Jan 2014 07:41:36 -0800 (PST)
Received: by mail-wi0-f176.google.com with SMTP id hq4so18005938wib.3 for <rtcweb@ietf.org>; Wed, 01 Jan 2014 07:41:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ecCCLLYCEvB7YKGNbRiB0oQ6JhdKXiURAH/au+bEC20=; b=afo9jWDotXXw8At9DLMCqpO66oMxVvIZx7zt7WNCp81jYuaDKQj9U7c/WS3dKTn2ZO eOBoWb7qwzYW/n+5YNxmV7M1ErY3vFIyH93+dwOX4w2OtKVmtudJA6A3XJG0sEUlXCXj IQ6jJ6B8D7UQ9k7MzfM0mFyFONcPdJa4XNtimwpFJgAELn5p6qumaPJxFVVDlmFu7bfk vZoMBHh+Nw+tPe+1igHE9XbhqQFJ3vQ3fOPggHeb38ieIzq2Usg+gjZPmtj0xpdGezk2 CYpL7r6UykcYOJiPRv2UGCG4eYCebXWQF1+j0akOS9fn5Xrl036q7Hzc90lUzGSDLSAw XEDg==
X-Gm-Message-State: ALoCoQk4gRo/a1aCR4K9ZoQNgAPTzavw2A0LnbfmW5S6APzsrG9/rdZFyNqeEMG4Ux1nCwNH4n1Q
X-Received: by 10.194.240.41 with SMTP id vx9mr1474888wjc.70.1388590889425; Wed, 01 Jan 2014 07:41:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.54.194 with HTTP; Wed, 1 Jan 2014 07:40:49 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B1C432187@ESESSMB209.ericsson.se>
References: <CAA93jw7FDddn2n23fm=rdUsDyGakNfyLkJDgNjoC43fSc4GnSA@mail.gmail.com> <CABkgnnUR1ARiMRTKwieQmNz3qg=RiagF=zdo6LYf02pQaz+7nQ@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C432187@ESESSMB209.ericsson.se>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 1 Jan 2014 07:40:49 -0800
Message-ID: <CABcZeBNv1AyVmj2we=wBZjOSNnt-P0HbQdK91TsMxnstzrOadg@mail.gmail.com>
To: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] 5 tuples and rmcat-cc-requirements-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 01 Jan 2014 15:41:38 -0000

Is there some reason why people are avoiding the obvious avenue
of creating an API to control BUNDLE? We already need one for
BUNDLE-only anyway.

-Ekr


On Tue, Dec 31, 2013 at 10:55 PM, Stefan Håkansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> On 01/01/14 02:47, Martin Thomson wrote:
>> On 29 December 2013 16:02, Dave Taht <dave.taht@gmail.com> wrote:
>>> In current implementations, is it possible to force flows onto
>>> different tuples? What are the other flaws in suggesting or requiring
>>> a different tuple?
>>
>> There are quite a few ways to achieve this, depending on your
>> configuration.  All will require some fair amount of SDP cracking.
>>
>> If you have browsers at both ends, try creating two RTCPeerConnection
>> objects on each, and treat one pair as audio and the other video.  You
>> can do this by telling the answerer that audio (or video) is not
>> wanted in the offer (set port zero for the unwanted component).
>> offer.sdp.replace(/m=audio \d+ /, 'm=audio 0 ') should be done before
>> sending the offer out (I don't know whether you can pass this to
>> setLocalDescription safely, so I wouldn't).
>
> One way of doing it without any SDP cracking would be to create two
> different MediaStream's out of the one obtained from getUserMedia; one
> with the audio MediaStreamTrack only, and one with the video one.
>
> Then use one of them with one PeerConnection, and the other with another
> PeerConnection, and assemble into a MediaStream with audio and video at
> the receiving end.
>
> (And this becomes more straightforward if we move to adding tracks and
> not streams to PeerConnection)
>
> If you want to use one PeerConnection only, I think the simplest way
> would be to remove bundle from the SDP offer - either before setLocal or
> before sending the offer to the remote endpoint.
>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb