Subject: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10

From: Magnus Westerlund <[email-masked]>
Date: Fri, 18 Jan 2013 17:06:27 +0100

WG,

I would here by like to announce a two week WG last call that ends on
the 1st of February.

Document is available here:

https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 18 Jan 2013 16:19:31 +0000

Hi,

a few quick comments:

>    F3              Transmitted streams and data MUST be rate
>                    controlled.

Would like to add something along the lines of "and the send rate MUST be reduced when network congestion is detected." I guess that's implied but it doesn't hurt to make it explicit. RMCAT will take care of this eventually, but until then, it's the browser's job.

>    F5              The browser MUST be able to render good quality
>                    audio and video even in the presence of
>                    reasonable levels of jitter and packet losses.
> 
>                    TBD: What is a reasonable level?

I'd suggest "a few percent." Internet protocols in general don't do well when loss is higher than 10% or so.

>    F23             The browser must be able to send short
>                    latency unreliable datagram traffic to a
>                    peer browser.

It may be a good idea to point to RFC5404 here, which has further guidelines about such traffic.

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 18 Jan 2013 16:23:10 +0000

5405

On Jan 18, 2013, at 17:19, "Eggert, Lars" <[email-masked]> wrote:

> RFC5404

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 25 Jan 2013 14:11:10 +0100

> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/

As discussed in an earlier thread, I think that it should be clarified 
how the streams for the small/big video displays in use-case 4.3.3 are 
generated.

To recap, the use case is about a multiparty video (and audio of course) 
communication session using a central node.

At the screen of each endpoint/user, one video is displayed on a large 
surface, with other videos are shown as (live) thumbnails.

Which video to show at the large display surface is depending on speech 
activity; the video form the endpoint with currently talking user(s) is 
shown on the large surface - and this will usually change frequently 
during the session. This selection is handled by the central node which 
has access to all video and audio streams.

I think this is a quite common model, used by many services.

The current draft list three ways to support this use-case (use scalable 
video codecs, transcode in the central node, or use simulcast), but 
there are no requirements that back this up.

We should pick one solution that must be supported, and then derive the 
corresponding requirements.

As said before, I am a proponent for simulcast as solution to this use-case.

Stefan
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Gunnar Hellstrom <[email-masked]>
Date: Fri, 25 Jan 2013 22:28:04 +0100

> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/

In section 4.3.2.1 it is said "

Alice uses her web browser with a service something like Skype to be
able to phone PSTN numbers.

"

I think it is a habit of IETF to not reference brand names.

It can be replaced with  "

Alice uses her web browser with a service that enables her to phone PSTN numbers."

/Gunnar

---

From: Gunnar Hellstrom <[email-masked]>
Date: Fri, 25 Jan 2013 22:51:58 +0100

> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/

We had a good discussion in December on inclusion of the real-time text 
medium.

It was decided to document three alternative implementations with pros 
and cons and after that decide which one to standardize together with 
the two already mentioned media in rtcweb.

The three alternatives were:
1.) An RTP medium similar to audio and video, using RFC 4103 transport.

2.) A semi-reliable data channel with a standardized label.

3.) A web service based protocol, such as BOSH and XEP-0301 for 
real-time text in XMPP with a well specified integration with rtcweb in 
a common application.

For all three cases, there is a need to have a specification for how 
calls with audio, video and real-time text are exchanged with SIP based 
environments, e.g. for interaction with RFC 6443 based emergency services.

Text is a natural part of today's video and audio applications, so all 
use cases look quite meager without it.

  I suggest that we make a rapid mini-investigation on the real-time 
text alternatives and decide which variant to include in a use case.

/Gunnar

---

From: Gunnar Hellstrom <[email-masked]>
Date: Fri, 25 Jan 2013 22:51:58 +0100

/Gunnar

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 26 Jan 2013 09:53:10 +0100

On 01/25/2013 10:51 PM, Gunnar Hellstrom wrote:
> We had a good discussion in December on inclusion of the real-time 
> text medium.
>
> real-time text in XMPP with a well specified integration with rtcweb 
> in a common application.
>
> calls with audio, video and real-time text are exchanged with SIP 
> based environments, e.g. for interaction with RFC 6443 based emergency 
> services.
>

I disagree with this summary on two points:

- I think it's broken to choose between implementation strategies in an 
use case. The use case needs to specify the function that we want to 
achieve.

- I don't recall a declaration by the chairs that text would be included 
in the use cases for RTCWEB.

My memory is flaky, so if you can find the declaration by the chairs, 
I'm happy to let the last point pass.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 29 Jan 2013 18:51:00 +0000

The combination of getting ready for the interim meeting and being sick, I am sorry but won't be able to get this done by deadline but I will still get a review done at later. 

Sorry, Cullen

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Jan 2013 06:46:46 +0900

I have read this document in the past, but never really reviewed it.
It's something of a mess.  Sure, it could use a fairly thorough going
over from an editorial perspective, but that's not what bothers me.

There is just a lot of stuff in here that we haven't resolved.  Some
of this stuff we haven't even discussed, not to mention have concrete
proposals on the table for.

There are a number of open questions in relation to this document.  I
wont repeat those that are actually in the text, which clearly need to
be addressed.  I'm more concerned about those features/requirements
that the working group(s) has/have not shown any signs of providing
answers for.  Here I speak primarily of the items that are on the
agenda at the upcoming interim meeting.  Stream rejection, for
example.

I would suggest that these documents be held in abeyance until we know
the outcome of the interim.  Specifically, whether we are going to
provide technical solutions to the problems under discussion.  (Yes, I
know that it is not uncommon for use case documents to be published
with requirements that are impossible, but it's only 2 weeks.)

Specific comments:

The requirements are all over the place.  They almost look like they
have been shuffled.  For instance, F33 and F23 are almost identical,
but use different wording.  Same for F19 and F29.  F24 and F34.  Oh, I
get it, you are grouping based on the last digit!  Not the most
obvious choice for ordering, or the easiest to review.

   F13             The browser MUST be able to apply spatialization
                   effects to audio streams.

So...this is either pointless in the same vein as the requirement "the
browser MUST be able to control the volume of audio" or it is not
addressed.  I see A13, but that's not happening.  Given where we've
directed effort, I am tempted to suggest that this be removed.

   F14             The browser MUST be able to measure the level
                   in audio streams. (also A14)

As written, this is pointless.  If the audio can be played, the level
can be measured.  Unless the intent is that the browser provide this
information to the application.  In which case, we have the security
implications to consider, when streams are marked as "tainted", this
should not be possible.

F15             The browser MUST be able to change the level
                   in audio streams.

This is a problem for the same reason as above.  AGC is one thing, but
this is unspecific.  Does this apply to inbound and outbound streams?
Is this level control provided to the application or is this a
pointless requirement on browser chrome?  This also has implications
for "tainted" streams, in which case I believe that even level control
should be prevented.

   F7              The browser MUST support fast stream switches.

What does this mean?  There are a number of factors that could be at play here:
1. There are two live streams (inbound or locally sourced) and the
browser must be able to switch from playback of one to the other
quickly.  This should be trivial to implement.  Even then, we need to
be careful that switching can't be to fast for tainted streams.
2. There are two live streams sourced locally and the browser must be
able to switch from transmission of one to the other quickly.  This
does have some limitations if the two streams have different
properties such that this requires signaling.
3. There are two streams where the stream that is being switched in is
remotely sourced and currently inactive.  The browser needs to
activate and begin playback of that stream quickly. This is what is
implied by the use case in Section 4.3.3.

   F19             Streams and data MUST be able to pass through
                   restrictive firewalls.

Suggest rewording, perhaps to use of the term "limited middleboxes"
rather than "restrictive firewalls".  Otherwise, this could be
interpreted as a *requirement* to circumvent local network policy.
F29 seems like a better model, though I note that it is a duplicate of
this.

   F37             The browser MUST be able to send streams and
                   data to a peer in the presence of FWs that only
                   allows http(s) traffic.

This is a more specific version of F19, for which my same comment
applies.  I haven't seen any attempt to provide a solution.  Can this
be removed?

  F22             There should be a way to navigate
                   a DTMF based IVR

Expand on first use: IVR and DTMF.

   F26             It MUST be possible to move from one network
                   interface to another one

For whom must this be possible?  Certainly, the browser is able to
make this choice, but the application has only limited ability to
control this in the current application.  I can imagine perhaps
changing priority values on a=candidate lines based on some guessing
about what interfaces are what, but I have a strong expectation that
this would have zero effect in any ICE implementation.

   F28             The browser MUST support a baseline audio and
                   video codec

No comment.

   F32             There browser MUST support that STUN and TURN
                   servers to use are supplied by other entities
                   than the service provided (i.e. the network
                   provider).

I'm not sure what the "service provided" is in this case.  There is an
application and the browser.  The discovery of local STUN/TURN servers
is surely a browser issue outside of the scope of these requirements.
A note in a solution document that makes the observation that
browser-provided STUN/TURN servers be used in addition to any provided
by the application would be more appropriate.

   A17             For each stream generated, the Web API MUST
                   provide an identifier that is accessible by the
                   application. The identifier MUST be accessible
                   also for a peer receiving that stream and MUST
                   be unique relative to all other stream
                   identifiers in use by either party.

This seems overly specific.  I presume that the intent was to ensure
that streams that originate on a sending browser be identifiable on a
receiving browser.  This actually specifies a solution to that problem
rather than the requirement.  Suggest: The Web API MUST provide a way
to identify streams such that an application is able to match streams
on a sending peer with the same stream on all receiving peers.
Identifier uniqueness requirements derive from that requirement, plus
any additional constraints that you choose to apply (read: SDP).

   A25             It must be possible for the application to
                   refrain from exposing the IP address

Missing something.  "the" IP address.  Which one specifically?  Oh,
you must (MUST) be able to refrain from revealing that information.

Editorial:
A19 is missing: "to", " ".
A20 not only anthropomorphizes the browser, it assigns a gender; how
can be sure it's not a "she"?
Fix the IANA Considerations section, it's not hard.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Jan 2013 14:36:03 -0800

I have a very fundamental question about this document:

What are the Browser and API requirements going to be used for? 

Is the goal to document things we thought might have been nice at the time?

In many cases, the requirements are too vague to easily determine whether subsequent IETF
protocol profiles or W3C API documents actually satisfy the requirements.  But even if they were
made more specific, is there really any intent to evaluate IETF and W3C work based on these requirements?

Section 2 states that normative keywords are to be interpretted as described in RFC 2119.
Since this isn't a protocol specification, does that really make sense?

As an example, requirement F3 states:

"Transmitted streams and data MUST be rate controlled."

While the statement above might make some sense in the context of the "circuit breakers" document, or
perhaps one of the congestion control documents, I don't understand what the MUST means in the context of
this document. 

Does it mean that the specifications are required to define a rate control feature? 
Assuming such a feature is defined, does it mean that browsers are required to implement the feature? 
If implementation is required, is it required that the feature be used? 

Personally, my guess is that the meaning probably does not correspond to any of the above, because this 
is only a use case document, not a protocol or API specification.

But if that is true, why point to the RFC 2119 definition of normative terms? 

In the past, a number of requirements documents have tackled this problem by explicitly
stating that how normative language is to be interpretted, rather than blindly inserting a 
reference to RFC 2119.  For example, RFC 2989 states:

   Please note that the requirements specified in this document are to
   be used in evaluating... protocol submissions.  As such, the
   requirements language refers to capabilities of these protocols; the
   protocol documents will specify whether these features are required,
   recommended, or optional.  For example, requiring that a protocol
   support confidentiality is NOT the same thing as requiring that all
   protocol traffic be encrypted.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Jan 2013 15:04:12 -0800

Putting aside the meaning of the  normative language in the document, and the purpose of the document, here are some thoughts on the requirements contained therein:

 REQ-ID          DESCRIPTION
   ---------------------------------------------------------------
   F1              The browser MUST be able to use microphones and
                   cameras as input devices to generate streams.

[BA] Can I assume that the use of the plural implies a requirement to be able to support multiple sources?
 ----------------------------------------------------------------
   F2              The browser MUST be able to send streams and
                   data to a peer in the presence  of NATs.

[BA] Is this really only about sending streams, but not receiving??

 ----------------------------------------------------------------
   F3              Transmitted streams and data MUST be rate
                   controlled.

[BA] I think we need to be more specific.  Are we talking about support for "congestion control", and if so, are we saying
this should be mandatory to implement or use?  Or is this about "consent"?  Or maybe preventing congestive collapse in some circumstances 
(e.g. circuit breakers)? 
 ----------------------------------------------------------------
   F4              The browser MUST be able to receive, process and
                   render streams and data ("render" does not
                   apply for data) from peers.
   ----------------------------------------------------------------
   F5              The browser MUST be able to render good quality
                   audio and video even in the presence of
                   reasonable levels of jitter and packet losses.

[BA] I am not sure what this means.  Is it implying the need for a strategy to deal with loss in the MTI codec?
For example, is this implying a requirement for codec adaption,
or FEC or re-transmission?  I don't see the purpose of letting the TBD remain here. 
 ----------------------------------------------------------------
   F6              The browser MUST be able to handle high loss and
                   jitter levels in a graceful way.

[BA] What does "graceful" mean?? Is this referring to the resilience of the codec and
loss-strategy (see above), or to enabling the application to adapt to loss?  

 ----------------------------------------------------------------
   F7              The browser MUST support fast stream switches.

[BA] I really am not sure what is meant here.  Are we talking about the ability of a sender to change 
transmission rate quickly (e.g. removing a layer in SVC)?  Or about adding/removing a stream? 

   ----------------------------------------------------------------
   F9              When there are both incoming and outgoing audio
                   streams, echo cancellation MUST be made
                   available to avoid disturbing echo during
                   conversation.

                   QUESTION: How much control should be left to the
                   web application?

[BA] Hadriel's API requirements document talks about the ability to control echo cancellation, which 
makes more sense to me than the above.  Remove the question. 

 ----------------------------------------------------------------
   F10             The browser MUST support synchronization of
                   audio and video.

                   QUESTION: How much control should be left to the
                   web application?

[BA] Synchronization is not necessarily possible or even desirable in all circumstances.
For example, if the video experiences substantial loss, do you really want to delay the audio to sync
with it? So I can understand why it is desirable to support the capability, but is this 
really a MUST?  I would not bother to attempt to answer the question; delete it. 

   ----------------------------------------------------------------
   F13             The browser MUST be able to apply spatialization
                   effects to audio streams.

[BA] What does this mean in practical terms?
 ----------------------------------------------------------------
   F14             The browser MUST be able to measure the level
                   in audio streams.

[BA] See Martin's comments. 
 ----------------------------------------------------------------
   F15             The browser MUST be able to change the level
                   in audio streams.
[BA] See Martin's comments. 

   ----------------------------------------------------------------
   F18             The browser MUST be able to process and mix
                   sound objects (media that is retrieved from
                   another source than the established media
                   stream(s) with the peer(s) with audio streams.

[BA] If this is done, isn't it important to make clear to the user (and perhaps the peer) what is happening? 
Confusing live and recorded media seems like a potential vector for mischief. 

 ----------------------------------------------------------------
   F19             Streams and data MUST be able to pass through
                   restrictive firewalls.

[BA] Do we need this requirement, given that we also have requirements F29 and F37?

   ----------------------------------------------------------------
   F20             It MUST be possible to protect streams and data
                   from wiretapping.

[BA] "Wiretapping" is too vague a phrase to be of much use.  It might make more sense to
talk about security services that should be provided (e.g. confidentiality of media). 

 ----------------------------------------------------------------
   F21             The browser MUST support an audio media format
                   (codec) that is commonly supported by existing
                   telephony services.

                   QUESTION: G.711?

[BA] The Question: line should probably be removed.  

   ----------------------------------------------------------------
   F26             It MUST be possible to move from one network
                   interface to another one
[BA] Are we talking about the ability of an application to control this, or the ability of an application to react to it, or something else?

   ----------------------------------------------------------------
   F29             The browser MUST be able to send streams and
                   data to a peer in the presence of NATs that
                   block UDP traffic.

[BA] Is this just about sending and not receiving?

   ----------------------------------------------------------------
   F35             The browser MUST enable verification, given
                   the right circumstances and by use of other
                   trusted communication, of that  streams and
                   data received have not been manipulated by
                   any party.
[BA] I do not see how such a verification is possible. 

 ----------------------------------------------------------------
   F36             The browser MUST reject incoming media and
                   data, either modified, created or injected,
                   by any entity not trusted by the site.

[BA] Do we really mean "trusted by the site" or "trusted by the browser"? 

 ----------------------------------------------------------------
   F37             The browser MUST be able to send streams and
                   data to a peer in the presence of FWs that only
                   allows http(s) traffic.
   ----------------------------------------------------------------
   F38             The browser MUST be able to collect statistics,
                   related to the transport of audio and video
                   between peers, needed to estimate quality of
                   service.

[BA] Do we mean "Quality of Service" or "Quality of Experience?"

 ----------------------------------------------------------------

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 30 Jan 2013 11:02:00 +0100

Bernard, with your IAB hat on - didn't we do a document describing how 
to do 2119 language in requirements at one time?
(Since the word "requirements" occurs so often in 2119 itself, it's hard 
to google for it)

Failing that, I support adapting the language of RFC 2928 (needs 
adapting, because we're expecting to develop a single specification 
suite rather than evaluating multiple submissions) and inserting it here.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 30 Jan 2013 11:11:05 +0100

> proposals on the table for.

I know that you know this, but just so everyone else remembers: The 
requirements document is a requirements document for both the RTCWEB and 
the WEBRTC work. So some requirements are addressed only in WEBRTC, 
others in RTCWEB.

> with requirements that are impossible, but it's only 2 weeks.)

I'd prefer not to formally do this (Last Calls need to close), but the 
normal procedure is that comments raised during Last Call are addressed 
after the WG Last Call closes. If addressing comments cause major 
changes, a new WG Last Call might be in order.
> directed effort, I am tempted to suggest that this be removed.

In the WEBRTC WG, we've assumed that this is satisfied by saying "audio 
can be sent to the WebAudio API".

> implications to consider, when streams are marked as "tainted", this

Agree that this is relatively pointless; if it can do A14 (report 
level), it can do F14.

> for "tainted" streams, in which case I believe that even level control

I think you're wrong about tainting, but I wonder if this is trivially 
satisfied by the fact that output elements have volume controls (and 
there's always WebAudio as a backup).

> implied by the use case in Section 4.3.3.

Not clear what you intend to say - does it need to be specified further, 
or removed?

The scenario that derives this requirement is 4.3.3.1 "Video 
conferencing system with central server".

   "As the video streams to display can change quite
    frequently (as the conversation flows) it is important that the delay
    from when a video stream is selected for display until the video can
    be displayed is short."

"Short" is not specified further, but in the common case of voice 
activated switching, I think one assumes that you want to see the 
speaker before he's finished his first word.

> F29 seems like a better model, though I note that it is a duplicate of

I saw a note the other day about "we have to specify a limited source 
port range so that our firewall admin will not laugh in our face when we 
ask for enough privilleges to use WebRTC through the firewall". I think 
this section needs to be rethought as "it should be possible to behave 
in a way that will make restrictive firewall admins let things through" 
- this might be as simple(?) as specifying that TURN/TCP MUST be 
supported (and you whitelist the TURN addresses with the firewall 
admin), or might be more complex.

Given the pushing-on-string nature of the requirement, I think it should 
be a SHOULD.

> applies.  I haven't seen any attempt to provide a solution.  Can this

TURN/TLS will satisfy this requirement.

> this would have zero effect in any ICE implementation.

ICE restart satisfies this requirement for the "break before make" case.

> by the application would be more appropriate.

I think that's in JSEP somewhere. I don't see the need to change the 
requirement (although defining or changing the term "the service 
provided" would be good).

> any additional constraints that you choose to apply (read: SDP).

I like the reformulation.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 30 Jan 2013 14:31:12 +0100

> obvious choice for ordering, or the easiest to review.

:-). Fair comment.

> implications to consider, when streams are marked as "tainted", this

This was written well before the "tainted" stuff started to appear; it 
may be that it should not be possible for "tainted" streams (or rather: 
the browser should in any case not be allowed to report to the app).

Many of the reqs have a similar structure: there is an "F" requirement 
on functionality in the browser, and a corresponding "A" requirement 
that exposes this functionality to the application. I'm not sure 
changing that structure would be a big gain.

> for "tainted" streams, in which case I believe that even level control

This (as F14) is intended for the application, as it is associated with 
A15. And the intention was to not limit it to local or remote streams, 
but to allow it for any stream.

> implied by the use case in Section 4.3.3.

This requirement is derived from the "Video conferencing system with 
central server" use-case. The intention was to say something like "if 
the central node asks for an intraframe, the browser should insert it".

> applies.  I haven't seen any attempt to provide a solution.  Can this

I agree that the reqs related to traversal of different FWs and NATs is 
a mess. I think that there originally was only one of them, and that 
we've added more as people have asked for it along the way.

> Expand on first use: IVR and DTMF.

Yes.

> this would have zero effect in any ICE implementation.

The requirement does not go into what is done in the application and 
what is done in the browser. But requirement comes from the use-case 
"Simple Video Communication Service, access change" where the user 
unplugs the Ethernet cable. The session is then supposed to continue on 
WiFi (or cellular). I think that is a fair requirement.

> by the application would be more appropriate.

"service porvided" should be "(communication) service provider". Yes 
perhaps this should be moved to a solution document.  I think it was 
Cullen who pushed for this requirement, but I don't remember the reasoning.

> any additional constraints that you choose to apply (read: SDP).

Agree.

> you must (MUST) be able to refrain from revealing that information.

Reformulation needed.

> Fix the IANA Considerations section, it's not hard.

Thanks.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 30 Jan 2013 14:55:43 +0100

On 2013-01-30 00:04, Bernard Aboba wrote:
> Putting aside the meaning of the  normative language in the document,
> and the purpose of the document, here are some thoughts on the
> requirements contained therein:
>
>   REQ-ID          DESCRIPTION

Yes. And in the use-case "Hockey Game Viewer" multiple cameras are used.

Of course it is both, but it is split up in F2 saying that the browser 
must be able to send to a peer (even if there is NAT('s) present in the 
path and F4 (be able to receive, process and render).

The intention was to put a MUST requirement on that the browser should 
not create congestion (regardless of what the app does).

The TBD could go; my interpretation is that at the very least there 
should be some PLC implemented.

I agree. This is very vague. I think that what was in mind at the time 
was that the browser should not be worse than existing native clients 
during bad network conditions (e.g. strange high level audio sounds that 
comes from decoding erroneous data should not be played). I think this 
req could go.

OK.

You're right: in some cases it is better to not synchronize. But I still 
think the browser MUST support it (even if not used in certain cases).

In practical terms this is already solved by the Web Audio API.

This is derived from the use-case "Multiparty on-line game with voice 
communication". Are you saying that the browser should inform the user 
that the "boom" sound comes from the explosion on the game scene, while 
the voice comes from his friend that is playing the same game? I don't 
see that need.

I agree that the traversal related reqs are messy.

This was discussed a bit, and someone (Harald?) pointed out that 
wiretapping is well defined and can be used.

Yes.

It is not split up between application, browser, STUN/TURN server, it is 
just a requirement on that it should work.

See discussion above.

I was under the impression that DTLS allowed this.

I need to think a bit more about this one.

Perhaps Experience is better.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 30 Jan 2013 15:01:40 +0100

> What are the Browser and API requirements going to be used for?

This is a very good question.

> protocol profiles or W3C API documents actually satisfy the
> requirements.

The requirements are quite vague, but I think that if you read them in 
conjunction with the use-case that introduced them they get a bit more 
specific.

> But even if they were

To me it means that the browser should not congest the network (and this 
is regardless of what the possibly malicious app does).

>     protocol traffic be encrypted.

This makes a lot of sense.

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Wed, 30 Jan 2013 16:21:07 +0000

I find the below statement strange, as there is a process for publishing requirements documents within the W3C, and this isn't it.

Matthew Kaufman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: Wednesday, January 30, 2013 2:11 AM
To: [email-masked]
Subject: Re: [rtcweb] WG Last Call: draft-ietf-rtcweb-use-cases-and-requirements-10

...
I know that you know this, but just so everyone else remembers: The requirements document is a requirements document for both the RTCWEB and the WEBRTC work. So some requirements are addressed only in WEBRTC, others in RTCWEB.
...

---

From: Mary Barnes <[email-masked]>
Date: Wed, 30 Jan 2013 10:32:05 -0600

I agree with Matthew.  The RTCWEB solution documents should be able to
satisfy all the requirements defined in an RTCWEB requirements
document (or there needs to be a clear explanation as to why a
specific requirement isn't satisfied).  I would suggest to at least
put the W3C requirements in an appendix.

Mary.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 30 Jan 2013 18:33:57 +0100

> put the W3C requirements in an appendix.

The split between "F" requirements and "A" requirements was intended for 
that purpose. I see it's not very well explained in the text (to put it 
mildly).

-overview- has more text about the relationship between those two parts; 
luckily, this is in Last Call at the same time, so if that text is not 
sufficient, it's a good time to fix it.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 30 Jan 2013 11:30:22 -0800

> is regardless of what the possibly malicious app does).

[BA]  Today we have three potential approaches that might be relevant to this general concern:

a. Consent.  If a receiver is being inundated, they can refuse to response to ICE keepalives, thereby causing a compliant sender to stop sending. 
b. Circuit breakers.  As I understood it, the goal of this document was to prevent congestive collapse in a number of situations.   However, circuit breakers aren't a complete solution to congestion control, so the resulting behavior might not be considered "fair" and also it wasn't clear to me that high packet loss/low throughput would be avoided in all situations. 
c. Congestion control (RMCAT).  This is a solution to the congestion control problem, not just DDOS or worst-case congestive collapse.  Since it covers more ground it is more of a long-term solution than a or b. 

I would like the requirement to be a bit more specific so that we can be clear which of a, b and/or c address the concern.   Solution a is more of a response to DDOS issues than congestion control per se.   Solution b is designed to address some worst case outcomes, though not necessarily all of them.   Solution c is the long-term solution, but it may not be available within the same time frame as a or b.  

> This makes a lot of sense.

[BA] Feel free to tweak the wording above to the needs of RTCWEB.  IETF Requirements documents are often used for different purposes, so one size doesn't necessarily fit all.  For example, the RFC 2989 language above was created to provide guidelines for selection between competing protocol proposals.  In that particular situation, meeting more requirements was "better" but it wasn't necessarily expected that the "winner" would meet all requirements.  Other WGs have created requirements documents to guide protocol development and enable identification of missing work.  In those situations, it isn't necessarily expected that an initial document set will cover all the bases, though there may be an expectation that major holes will get covered somehow at some point.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 30 Jan 2013 12:02:35 -0800

> Yes. And in the use-case "Hockey Game Viewer" multiple cameras are used.

[BA] OK.  General question:  is this something that needs to be supported in v1.0 (e.g. we need to figure out how multiple source negotiation works immediately) or can it wait until later?  For me, that question is helpful in distinguishing MUSTs (things we need to have to either provide basic capabilities, avoid damage to the Internet, or attain interoperability) from lesser levels like SHOULD (things it would be very useful to have, but perhaps are not needed immediately). 

> The TBD could go; my interpretation is that at the very least there should be some PLC implemented.

[BA] OK.  It might be helpful to be a bit more specific about what might address this requirement, assuming we can come to agreement on it. 

> comes from decoding erroneous data should not be played). I think this 

[BA] I think that this requirement is probably covered adequately by other ones so it can be omitted. 

> think the browser MUST support it (even if not used in certain cases).

[BA] I agree with the "MUST support" formulation.

> the voice comes from his friend that is playing the same game? I don't 

[BA] I agree that it is silly in a game scenario.  But in an emergency call, knowing that the video of a hostage situation isn't live would be pretty important. 

> wiretapping is well defined and can be used.

[BA] If we can refer to a definition this would be helpful in clarifying the requirement.

> just a requirement on that it should work.

[BA] My question is whether existing ICE/STUN/TURN RFCs are sufficient or whether extensions such as ICE Mobility are required to meet this requirement.

> I was under the impression that DTLS allowed this.

[BA] DTLS/SRTP can verify that there is no man-in-the-middle.  But it doesn't address modification by an endpoint that is a media gateway.   Also, there is the replay vs. live issue.  

> I need to think a bit more about this one.

[BA] While the security document advises the use of HTTPS for signaling, it doesn't prohibit use of HTTP.  Also, for media there probably will be scenarios where the client is unauthenticated, even if the server is authenticated (e.g. DTLS/SRTP with asymmetric trust).   My advice is to reformulate this as a requirement for support of {media, signaling} authentication/integrity protection, rather than use. 

One last question, about A25:

[BA] I am assuming we are talking about exposing the originating IP address of media, which can be addressed via TURN.  
If so, this is more of a protocol than an API requirement.  Since the ICE candidates need to exposed in the API in
order to allow them to be signaled, I am not sure how we can avoid exposing those to the application.  Similarly, the
HTTP server can obtain the IP address used by the HTTP client.  Even within SIP, there are VIA headers and contact
headers, so it is not easy to avoid disclosure of the IP address to everyone.  So I think we need to be more clear 
about what we are trying to avoid exposing, and to whom.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Jan 2013 05:54:36 +0900

On 30 January 2013 19:11, Harald Alvestrand <[email-masked]> wrote:
> after the WG Last Call closes. If addressing comments cause major changes, a
> new WG Last Call might be in order.

In which case I would suggest that the last call be concluded with a
decision not to send this document to the IESG.

> In the WEBRTC WG, we've assumed that this is satisfied by saying "audio can
> be sent to the WebAudio API".

Yeah, that doesn't connect with the text of the requirement in any
meaningful fashion.  I do prefer that requirements are testable.  What
test does the above text produce?

> satisfied by the fact that output elements have volume controls (and there's
> always WebAudio as a backup).

If that's the case, it's not clear why this even exists.  BTW, with
tainting, I'm concerned about the granularity of level control
available to applications and mixing of tainted with untainted
sources.

> Not clear what you intend to say - does it need to be specified further, or
> removed?

Yes.

> "Short" is not specified further, but in the common case of voice activated
> switching, I think one assumes that you want to see the speaker before he's
> finished his first word.

Again, as long as it's testable.  (Given reasonable assumptions about
background knowledge, we don't need the full legalese version.)

> TURN/TLS will satisfy this requirement.

This is not always true :)

> ICE restart satisfies this requirement for the "break before make" case.

I know that this happens *in some cases*, but I did not read "break
before make" anywhere.  I happen to be using a device with multiple
interfaces that can operate both in tandem quite happily.  For those,
it's possible to make before break.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Jan 2013 06:00:09 +0900

Regarding requirements on the browser, which I think bears further discussion:

Many requirements are stipulated as "The browser MUST be able to ..."
There is a clear confusion about what these requirements actually mean
from the perspective of where the controls to achieve the requirement
exist.

Some of these are assumed to surface UI such that a user can control
browser behavior, others assume a form of autonomous action on the
part of the browser, and yet others assume that controls are presented
to the application.

This needs to be clarified.

---

From: Gunnar Hellstrom <[email-masked]>
Date: Wed, 30 Jan 2013 22:15:06 +0100

On 2013-01-26 09:53, Harald Alvestrand wrote:
>> It was decided to document three alternative implementations with 
>> pros and cons and after that decide which one to standardize together 
>> with the two already mentioned media in rtcweb.
>>
>> based environments, e.g. for interaction with RFC 6443 based 
>> emergency services.
>>
>> Text is a natural part of today's video and audio applications, so 
>> all use cases look quite meager without it.
>>
> - I think it's broken to choose between implementation strategies in 
> an use case. The use case needs to specify the function that we want 
> to achieve.
Yes, I totally agree, I did not mean to have the discussion on solution 
in the use case document.
>
>
> - I don't recall a declaration by the chairs that text would be 
> included in the use cases for RTCWEB.
I repeat my proposal to do so. This time with a shortened, generally 
expressed use case that is intended to allows any one of the three 
implementation alternatives to be selected.
> I'm happy to let the last point pass.
Yes, I am on my way to do the last point as well. But timing requires 
the addition to the use cases to be handled now.

Thus: Proposal for adding real-time text to the use cases, adjusted to 
be general and minimal:

--------------------------Add real-time text in a general way in use 
case draft-------------------------------------------

4.2.15.Simple Total Conversation service

4.2.15.1.Description

    This use-case has the audio and video communication of the Simple

    Video Communication Service use-case (Section 4.2.1  <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09#section-4.2.1>).

    In addition to this, the users can send and receive real-time text
    in the same call.  While one user types in the real-time text area, it

     is nearly immediately presented to the other user.

    By providing these three media together, the Total Conversation
    service is provided.

    Interworking with SIP calls with the same media set, and with SIP
    based emergency services is also in scope of this use case.

4.2.15.2  <#section-4.3.1.2>.   Derived Requirements

    F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21,

    F39,F40, F41

    A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27

..............

    F39              The browser MUST be able to handle text entry

                    via applications to generate real-time
                    text streams to be included in Total Conversation
                    calls. Real-time text and Total Conversation
                    Services are defined in ITU-T F.700 and F.703.

    F40               The browser MUST be able to send real-time text

                    streams to a peer.

    F41               The browser MUST be able to receive, process and

                      convey real-time text streams from peers to
                     applications.

  

.....

    A27              The Web API MUST provide a mechanisms for  
                    handling real-time text among the streams.  
  ----------------------------------------------------------------

/Gunnar

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 31 Jan 2013 13:30:18 +0100

> test does the above text produce?

I can think of a reasonably easy test that generates the signal (read a 
mono sound from a file to a mediastream using the MediaSource interface, 
feed it to the WebAudio API, apply spatialization effects using the 
WebAudio API), but I'm not sure how you test whether spatialization is 
actually performed correctly. But writing that test should be a W3C matter.
> available to applications and mixing of tainted with untainted

I don't think I understand the problem fully from this description.
Can you write up a note on this issue and send it to the Media Capture 
task force?
That issue seems to belong there.

>> Not clear what you intend to say - does it need to be specified further, or

Specified further (yes) or removed (yes)?

> This is not always true :)

What's the case when it isn't?

> it's possible to make before break.

I don't read "make before break" either, but that's obviously 
preferable. Now that I dig further back into my memory, I think ICE 
restart is supposed to support make-before-break; you don't have to turn 
off the old path before the new has checked out usable.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 31 Jan 2013 16:17:55 +0100

> clarifying the requirement.
RFC 2804 section 3 spends quite a few words on defining the term.

---

From: Barry Dingle <[email-masked]>
Date: Fri, 1 Feb 2013 09:23:34 +1100

The email discussion regarding Real-time Text (RTT) in December last year
showed a real interest in the need to support it in WebRTC/rtcweb.

In addition, there are draft regulations in the USA and in Europe REQUIRING
RTT be supported wherever there is voice communication.

We need to find a way to include RTT in the Use cases and Gunnar's proposal
is a very good start. It does not change any of the existing Use cases as
it is an Additional feature.

I strongly support the inclusion of RTT in the Use cases and Requirements.

Cheers,
/Barry Dingle

On Thu, Jan 31, 2013 at 8:15 AM, Gunnar Hellstrom <
[email-masked]> wrote:

> It was decided to document three alternative implementations with pros and
> cons and after that decide which one to standardize together with the two
> already mentioned media in rtcweb.
>
> 3.) A web service based protocol, such as BOSH and XEP-0301 for real-time
> text in XMPP with a well specified integration with rtcweb in a common
> application.
>
> For all three cases, there is a need to have a specification for how calls
> with audio, video and real-time text are exchanged with SIP based
> Text is a natural part of today's video and audio applications, so all use
> cases look quite meager without it.
>
>  I suggest that we make a rapid mini-investigation on the real-time text
> alternatives and decide which variant to include in a use case.
>
>
> Yes, I totally agree, I did not mean to have the discussion on solution in
> the use case document.
>
>
>
> My memory is flaky, so if you can find the declaration by the chairs, I'm
> happy to let the last point pass.
>
>  Yes, I am on my way to do the last point as well. But timing requires the
> addition to the use cases to be handled now.
>
>
> Thus: Proposal for adding real-time text to the use cases, adjusted to be
> general and minimal:
>
> --------------------------Add real-time text in a general way in use case
> draft-------------------------------------------
>
> 4.2.15.  Simple Total Conversation service****
>
> 4.2.15.1.  Description****
>
> ** **
>
>    This use-case has the audio and video communication of the Simple****
>
>    Video Communication Service use-case (Section 4.2.1 <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09#section-4.2.1>).****
>
> ** **
>
>    in the same call.**** While one user types in the real-time text area, it****
>
>    based emergency services is also in scope of this use case. ****
>
> ** **
>
> 4.2.15.2 <#13c8d510f5a08297_section-4.3.1.2>.  Derived Requirements****
>
> ** **
>
>    F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21,****
>
> ** **
>
>    F39,F40, F41****
>
> ** **
>
>    A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27****
>
> ** **
>
> ..............
>
>    F39             The browser MUST be able to handle text entry****
>
>                    via applications to generate real-time                    text streams to be included in Total Conversation
>                    Services are defined in ITU-T F.700 and F.703. ****
>
>    ----------------------------------------------------------------****
>
>    F40              The browser MUST be able to send real-time text ****
>
>                    streams to a peer.****
>
> ** **
>
>    ----------------------------------------------------------------****
>
>    F41              The browser MUST be able to receive, process and****
>
>                     applications.****
>    ----------------------------------------------------------------****
>
>    ****
>
> **
>
> .....
> **   A27             The Web API MUST provide a mechanisms for ****
>                    handling real-time text among the streams.****
>  ----------------------------------------------------------------****
>
>
>
> /Gunnar
>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 01 Feb 2013 00:07:32 +0100

FWIW, I strongly object to a couple of formalities here:

- I object to making normative reference to F.700 and F.703.
- I object to requiring interworking with emergency services.

If there's strong support in the WG for including the use case, I'm 
willing to go along with that.

(The reason for not wanting to normatively reference F.700 and F.703 is 
that they're very large balls of string, and I have no idea where the 
string may lead; for instance, the definition of "Total Conversation" in 
section A.3.2.3 of F.700 requires font support for all characters in 
ISO-10646-1; I doubt somewhat that the person who wrote that paragraph 
has studied the task of providing such font support - I found that 
particular linkage in a few minutes of scanning the docs.)

On 01/30/2013 10:15 PM, Gunnar Hellstrom wrote:
> 4.2.15.2  <imap://[email-masked]:143/fetch%3EUID%3E.INBOX.IETF.Areas.rai.rtcweb%3E5874#section-4.3.1.2>.   Derived Requirements
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 1 Feb 2013 09:16:47 +0900

On 31 January 2013 21:30, Harald Alvestrand <[email-masked]> wrote:
> I can think of a reasonably easy test that generates the signal (read a mono
> sound from a file to a mediastream using the MediaSource interface, feed it
> to the WebAudio API, apply spatialization effects using the WebAudio API),
> but I'm not sure how you test whether spatialization is actually performed
> correctly. But writing that test should be a W3C matter.

Maybe I'm reading too much into this, but spatialization effects are
used for several reasons: for arrangements of multiple microphones in
the same room, they can be necessary to get proper stereo audio.  In
order to do this based on microphone configuration, you need
signaling.  If all you are looking for is the ability to spatially
separate different speakers, that clarification might help.

...
> Specified further (yes) or removed (yes)?

Yes.  As in pick one and I care little which that is.

> What's the case when it isn't?

Some firewalls use traffic analysis to identify real-time data that
has been tunneled over HTTP CONNECT.

> I don't read "make before break" either, but that's obviously preferable.
> Now that I dig further back into my memory, I think ICE restart is supposed
> to support make-before-break; you don't have to turn off the old path before
> the new has checked out usable.

ICE restart can do that, but there is no guarantee that triggering a
restart will result in a change of network interface.  Further clarity
on the requirement may be necessary to say that it be *possible* to do
this.