Re: [rtcweb] Comments to use-cases/reqs document

Henry Sinnreich <> Tue, 12 July 2011 15:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2919621F8ED2 for <>; Tue, 12 Jul 2011 08:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.986
X-Spam-Status: No, score=-0.986 tagged_above=-999 required=5 tests=[AWL=-2.614, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z20LdCuqLkqB for <>; Tue, 12 Jul 2011 08:56:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5D75721F8EC8 for <>; Tue, 12 Jul 2011 08:56:26 -0700 (PDT)
Received: by yxp4 with SMTP id 4so2515154yxp.31 for <>; Tue, 12 Jul 2011 08:56:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=ZR4M5pRN5bN24PKyFYbJyzs5Wbb60IsEpBuUawS8bFE=; b=pHeRfYou7UiP5MiekuNswXdw8faiuslp2iD5yPMZGFjIothrDneep/PL5b5BrnK+5l O/HXPSZIv7amh+GBxrp63Yu0C5IvBEtBOQY1/8xsAKcWvgaWwb3Xy64Jm+pBbMe17ArF PgKhBJ1oJL3vCcMYHXhpJH/0nHqYTUtSKnicw=
Received: by with SMTP id a17mr69021anj.143.1310486185742; Tue, 12 Jul 2011 08:56:25 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id v9sm13462239anv.30.2011. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jul 2011 08:56:24 -0700 (PDT)
User-Agent: Microsoft-Entourage/
Date: Tue, 12 Jul 2011 10:56:21 -0500
From: Henry Sinnreich <>
To: Harald Alvestrand <>, Stephan Wenger <>
Message-ID: <>
Thread-Topic: [rtcweb] Comments to use-cases/reqs document
Thread-Index: AcxArD5C3J+SPmk77k60BK3v+Cm4CQ==
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Cc: "" <>
Subject: Re: [rtcweb] Comments to use-cases/reqs document
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jul 2011 15:56:27 -0000


The use cases and especially requirements should be kept as simple/minimal
as possible but no more. Actually the most interesting use cases may not be
known at present; a good test if rtcweb is really innovative.
Quite happy that Harald and Cullen seem to keep firm control on this.

As for the video/screens parameters, one of my gripes is the use of
antiquated SDP instead of standard metadata formats for all screens, I/O
devices, etc. 
SDP is a big can of worms to throw out.

Legacy RTP as well, but this seems to be covered for now.

Finally, just to put all my gripes in one place: Why not use HIP with
ICE/HIP instead if SIP-ICE? This is so self evident.

Thanks, Henry

On 7/12/11 10:02 AM, "Harald Alvestrand" <> wrote:

> On 07/12/11 16:35, Stephan Wenger wrote:
>> Hi Harald,
>> If you define "simple" as "minimum functionality", then there should also
>> be a use case "not quite so simple; offer at least the user experience you
>> get from a Skype client today".  That use case may well turn out to be
>> more popular than the "simple" use case according to your definition.
>> However, my preference would be not to assume minimalistic use cases, but
>> rather tune the level of mandation of the requirements.  (So I'm in
>> Stefan's camp -- keeping the number of use cases reasonable)
> I'm all for "reasonable", but my "reasonable" may be different from
> yours.... the sum of all requirements should indeed allow us to build
> equivalents to Skype or Google Talk on top of this platform (except for
> the parts that don't make sense, of course :-) ), but I find it easier
> to talk about auto-zoom to keep head size constant (for instance - at
> least one Skype beta supported that) as a separate use case, not merged
> with the "basic use case".
>> Stephan
>> On 7.12.2011 07:17 , "Harald Alvestrand"<>  wrote:
>>> On 07/12/11 13:58, Stefan Håkansson LK wrote:
>>>>>> All,
>>>>>> some comments to
>>>>>> <
>>>>>> ements/?include_text=1>
>>>>>> 3. The "Video Size Change" use case derives F22; but that is already
>>>>>> derived in "Simple Video Communication Service". I propose to remove
>>>>>> the "Video Size Change" use case.
>>>>> I disagree with this proposal.
>>>>> While the "resizing" requirement is in "simple video communication
>>>>> service" as
>>>>> "The users can change the display sizes during the session", I believe
>>>>> the basic use case does not derive the requirement that the change in
>>>>> video size be communicated to the other party.
>>>>> I would propose the following changes:
>>>>> - Reinstate the text below:
>>>>> 4.2.4.  Video Size Change
>>>>>  Description
>>>>>      Alice and Bob are in a video call in their browsers and have
>>>>>      negotiate a high resolution video.  Bob decides to change the size
>>>>> of
>>>>>      the windows his browser is displaying video to a small size.
>>>>>      Bob's browser regenerates the video codec paramters with Alice's
>>>>>      browser to change the resolution of the video Alice sends to match
>>>>>      the smaller size.
>>>> My preference is always to keep the number of use cases down.
>>> We may have a difference of style here - I prefer to have explicit use
>>> cases that show only a single action or attribute that needs to be
>>> supported, which means that the number of use cases tends to be high.
>>> I think this is especially important for the situation where a WG has to
>>> decide to drop an use case because no agreed-upon implementation can be
>>> found.
>>>>    Could we not just add a sentence to the current "Simple Video
>>>> Communication Service" use case so it reads something like "The users
>>>> can change the sizes of the video displays during the session. Changes
>>>> of the display size are communicated from the displaying browser to the
>>>> one sending the stream so that the video codec parameters can be changed
>>>> accordingly."
>>> As per above - I would prefer the "Simple Video Communication Service"
>>> to be as simple as possible. Even resizing the window locally is more
>>> than "as simple as possible" - the Gtalk video client for my phone
>>> doesn't support that.
>>>> But my preference is not strong - I'm happy to reinsert the use case if
>>>> people think so.
>>>>>  Derived Requirements
>>>>>      F22 ( It SHOULD be possible to modify video codec parameters
>>>>> during a
>>>>>      session.)
>>>> F22 now reads "The browser SHOULD use encoding of streams suitable for
>>>> the current rendering (e.g. video display size) and SHOULD change
>>>> parameters if the rendering changes during the session"
>>>>> - Change the text of F22 to be:
>>>>>     It SHOULD be possible for one party to request a change in video
>>>>> codec parameters, such as size,
>>>>>     during a session, and for the other party to react to this request.
>>>> I think "party" is very vague. What does it mean - the browser, the
>>>> user, the web app?
>>> Since this is the IETF WG - the "party" is the browser, user and web app
>>> together; somehow the desire for a change has to be communicated across
>>> the network, and that's the requirement I think needs to be in the IETF
>>> requirements list.
>>> The corresponding API requirement (which I'm not sure how to formulate -
>>> all this may go on in the browser and need no explicit API) needs to go
>>> into the W3C requirements list.
>>> _______________________________________________
>>> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list