Re: [rtcweb] Requesting a new use case / requirement for draft-ietf-rtcweb-use-cases-and-requirements

Ted Hardie <ted.ietf@gmail.com> Tue, 30 July 2013 14:16 UTC

Return-Path: <ted.ietf@gmail.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 16EB821F9CC8 for <rtcweb@ietfa.amsl.com>; Tue, 30 Jul 2013 07:16:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level:
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
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 alMX8o5IuB0a for <rtcweb@ietfa.amsl.com>; Tue, 30 Jul 2013 07:16:22 -0700 (PDT)
Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id A33AF21F9CC2 for <rtcweb@ietf.org>; Tue, 30 Jul 2013 07:16:16 -0700 (PDT)
Received: by mail-oa0-f53.google.com with SMTP id k14so16039547oag.40 for <rtcweb@ietf.org>; Tue, 30 Jul 2013 07:16:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OKjZlum8PSotxOnS4IBS0LDwNZAIxA75BswloVmWc3o=; b=x1VbzFdQieSWsOqTPjruEsOdJk1m05VKEx5fKPuViLe92gJXKQX8jSrcdHLxzLQLY2 zeyoXktWDSplnDomVnrAOXgFejWmjOArzdKVWdzxSNXqXA6SPOhaLin32cVJJKE8rShm m/OFGig50a2nVBCSs51SEA5/pNQi9fE+dqoWSYLG58h9W9LFHDSgj4C3RfHDn6vmy0Ef h4vwm1DsOmAoJGXi8k/VYkqnAbPMqcYQpIFqdeoc2K3bivS6fLuB/AMQjVIUz7y6VQSX HDpvJHwhbRqV53Co0hsHM3U2OCVx6KQHFM4hceezDSdZ/JEO4shViALNDIIXD2/WwVTL tY0A==
MIME-Version: 1.0
X-Received: by 10.43.67.73 with SMTP id xt9mr21808861icb.99.1375193772391; Tue, 30 Jul 2013 07:16:12 -0700 (PDT)
Received: by 10.42.29.202 with HTTP; Tue, 30 Jul 2013 07:16:12 -0700 (PDT)
In-Reply-To: <CALiegf=uFvE7-H_6a3fwApenUVdp8HAhOhh1f7YWbT0BQFt9Ug@mail.gmail.com>
References: <CALiegf=uFvE7-H_6a3fwApenUVdp8HAhOhh1f7YWbT0BQFt9Ug@mail.gmail.com>
Date: Tue, 30 Jul 2013 16:16:12 +0200
Message-ID: <CA+9kkMCg7VfBnKAgAg3upUyF3DGDXOdHzRbxsZ_TaWKnz1-p9A@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=089e015370964d0af004e2bb40ae
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org
Subject: Re: [rtcweb] Requesting a new use case / requirement for draft-ietf-rtcweb-use-cases-and-requirements
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: Tue, 30 Jul 2013 14:16:23 -0000

This seems to conflate what you want the service to do and how you believe
it ought to operate.  The core use case appears to be a variant of the
"Multiparty video communication" in section 4.2.10.1.  If I understand
correctly, this variant retains the browser behavior in respect to
rendering of peer media, but gets all the audio and video streams from a
single peer (the conferencing server).

This text:

"The conference server must be able to reply a single response accepting
the offer and indicating the browser all the media tracks from other
participants it will send to it. This must be possible without requiring a
new media negotiation round trip, and without requiring that the browser
knows the number of participants in the conference before contacting it."

is not appropriate for a use case.  It's a proposed constraint on the
solution, rather than a description of the use.

regards,

Ted Hardie


On Tue, Jul 30, 2013 at 3:11 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> Hi, I would like to request a new use case / requirement for WebRTC to
> be included in draft-ietf-rtcweb-use-cases-and-requirements:
>
>
>
>
>
> Contacting a conference server
> ---------------------------------------------
>
> The browser must be able to generate a media offer to be sent to a
> conference server, by providing its audio and video information (media
> tracks to be sent by the browser), and the conference server must be
> able to reply a single response accepting the offer and indicating the
> browser all the media tracks from other participants it will send to
> it. This must be possible without requiring a new media negotiation
> round trip, and without requiring that the browser knows the number of
> participants in the conference before contacting it.
>
> Note that in this scenario the browser is the session initiator and
> thus the media description offerer, while the conference server
> provides the media description answer.
>
>
>
>
> Thanks a lot.
>
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>