Re: [rtcweb] Comments on use case draft

Stephan,

thanks for very good input! I have made some answers below, and look 
forward to your, and the group's, feedback to them.

Br,
Stefan

On 2011-08-28 22:07, Stephan Wenger wrote:
> Hi,
>
> I have a couple of comments related to
> draft-ietf-rtcweb-use-cases-and-requirements-03.txt.
>
> 1. There are a number of editorial issues that need to be addressed; I
> will communicate those to the editors in private.
>
> 2. Section 4.2.1.1: in a typical system, self-view is enabled well before
> connection establishment, not after.  For obvious reasons: you want to
> check your grooming before establishing a videoconference session (or
> taking a video call).

That is right. We might re-phrase it a bit. But what we really was after 
was the flexibility for the web app to display, or not, a self view (and 
to add and remove it at any time).

>
> 3. Section 4.2.4.1.: QoS related issues do not only occur in "roaming"
> scenarios; therefore, I would suggest to make the description of this use
> case independent from the "previous one" (4.2.3), and rather refer to
> 4.2.1.

The reason for pointing at 4.2.3 was to say that QoS capabilities for 
different accesses should be possible to use. If we refer to 4.2.1 this 
is much more unclear. The users in 4.2.1 may very well be in a situation 
where there is no possibility to offer QoS.

>
> 4. Section 4.2.6.1: This use case is not described in sufficient detail.
> At least two scenarios are possible.  First, both front and rear camera
> send individual video streams (potentially at different resolutions), and
> the PIP mixing happens in the receiving browser.  This would be a user
> interface issue and no mechanisms need to be specified in the IETF beyond
> being bale to send more than one video stream (though there may be need
> for related API work).  Second, the PIP mixing happens in the sending
> phone, and only one stream is being sent.  In this case, I believe not
> even API work is necessary.

We were after the first case (two independent video streams). That is 
also the requirement derived from this use case.

> Suggest to reconsider whether this use case is relevant enough for being
> kept.  Multi-camera systems being able to send coded samples from both
> cameras simultaneously are rather exotic today (only telepresence rooms
> come to my mind).

I have a different view. The average device (smartphone, tablet) is to a 
higher and higher degree equipped with two cameras. I think it should be 
possible to use both.

>
> 5. Section 4.2.7.1.: Why are the sending peers restricted to mono audio?
> Spatial arrangement is not very complex for stereo as well...

That is a very valid comment. Should we just remove 'mono' and be silent 
on that aspect?

>
> 6. Section 4.2.9.1.: What's really necessary here is a mechanism that
> allows a user to tell a browser that VERY tight cross-signal sync and VERY
> low delay is required, which may trigger different jitter buffer handling
> and such.  Beyond that, I believe that audio codec negotiation may be
> helpful.  Audio professionals (like musicians) are somewhat more picky
> when it comes to these technology selections than normal users.  I would
> not be surprised if we would learn that there is a real market requirement
> for uncompressed or lossless audio if this use case takes off.

I think there is a lot to be investigated for this use case really. I 
got the tip that this research group as Stanford: 
https://ccrma.stanford.edu/groups/soundwire/
has done a lot and have a lot of real-life experience. Probably we 
should get in contact with them. As you suspect, they seem to use 
uncompressed audio.

>
> Section 4.3.3.1: I have a number of issues with this use case.
>
> First, in contrast to most other use cases, this one enters solution space
> quite prominently.  That wouldn't be an issue for me if the solution my
> employer is favoring were mentioned here, but it is not :-(.  To cure my
> immediate concern, one suggestion would be to remove references to
> simulcast and/or add references to spatial scalability.  However, perhaps
> it's better to describe the behavior of the multipoint system in terms of
> user experience rather than technology choice.

I think this is a valid point. Let's see if we can come up with something.

>
> Second, why is audio mixed to stereo and not to something else, such as
> 5.1?

Right. It should not say "stereo", but something like "stereo, 5.1, or 
similar".

>
> Third, the security stuff is not in any way technically bound to the rest
> of the use case, so I would farm it out into its own use case, and/or
> mention it as a "generic" feature... Remarks like "it is essential that
> the communication cannot be eavesdropped" would apply to pretty much all
> use cases, right?

I guess that depends. If you have a leisure conversation, maybe you do 
not care that much. This was a case where we could clearly say that "not 
being eavesdropped" is essential.

But we could say something about it already in the very first use case 
(the most basic one), and derive the requirement already there. Perhaps 
we could say that the conversation in that use case is about planning a 
bank robbery:)

>
> 7. Missing use case:
>
> It is my understanding that for regulatory compliance, in many developed
> countries, there will be a need for an E911 type of service *IF* the
> solution allows to "dial" an E.164 phone number.  I remember a controversy
> involving SKYPE in ca. 2005, and also having read about recent FCC
> hearings about this issue; for example,
> http://www.broadbandlawadvisor.com/2011/07/articles/voip/fcc-seeks-comment-
> on-extending-e911-rules-to-oneway-outboundonly-voip-improve-location-capabi
> lity-of-inteconnected-voip/.
> If there is a reasonable expectation that a webrtc service with outbound
> dialing capability in E.164 number-space requires E911 handling, then it
> does not make sense to stick our collective heads in the sand and ignore
> the issue.  I believe there is such an expectation; surely during the
> lifetime of an webrtc solution, but probably even during its introducer
> phase.
> If E911 is relevant in this sense, then this issue needs to be addressed
> in section 4.3.1, 4.3.2, and perhaps 4.2.5.
> I understand that the editors did not address those use cases yet based on
> (presumably) lack of consensus, but I fear that IETF consensus is not the
> only relevant factor here.

Use cases 4.3.1 and 4.3.2 do say that you should be able to dial E.164 
using the rtcweb standard IMO. But we never really discussed to what 
extent this means E911 must be supported, and in turn what requirements 
it puts on the rtcweb standard. One aspect is of course location; but 
this is in a web browser context handled by the W3C geolocation WG 
(http://www.w3.org/2008/geolocation/).

>
> (I could mention "legal intercept" in the same context, but suggest to
> focus on emergency calls first, because a) they are easier to handle, b)
> more widely applicable, and c) generally agreed to be a useful thing, and
> therefore not quite as politically loaded.)
>
> Stephan
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb