Minutes for RTCWEB at IETF-92
minutes-92-rtcweb-1

RTCWEB Minutes, IETF 92
Chairs:  Sean Turner, Cullen Jennings, Ted Hardie
Scribes:  Keith Drage, Xavier Marjou, Roni Even, Stephan Wenger

March 25, 2015 and March 26, 2015
Recorded Sessions:
http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF92_RTCWEB&chapter=chapter_0
http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF92_RTCWEB_II&chapter=chapter_0
Jabber Logs: https://www.ietf.org/jabber/logs/rtcweb/2015-03-25.html
https://www.ietf.org/jabber/logs/rtcweb/2015-03-26.html

Action items:

Chairs:
Document Authors

Draft minutes

Note taker:
Keith Drage and Xavier Marjou
Roni Evan and Stephan Wenger

rtcweb notes 3/26/2015

Use front mikes only

Agenda bash
Swap return before SDP, OK

WGLC resolutions: (Chairs) 0 to 5 minutes
Chair slides -- vacat

(other) Open Issues in Security Arch Draft (MT & MW) 15 minutes
MUST SHA-256, MAY SHA-1 with intention to turn it off later
Bernhard: Existing implementations can do more.
Russ: Why not “SHOULD NOT” SHA-1?
EKR: SHA-1 for interop with legacy, what’s the problem with SHA-1?
MT: Collision.
EKR: No.
Bernard: Legacy device, support for SHA1 no-brainer.  Do we need SHA-512?
MT: Don’t need to say anything about SHA-512.
EKR: Minimum profile SHA_256 and SHA-1.

No conclusion, take to list

Turn-only
MT: asserted issue is closed
Magnus: Was this not documented?
EKR: Add documentation to explain what browsers could do to alleviate problem.
Ted: Descriptive text ok, “example cases: if in private browsing, then…”
Justin: Notion of “private browsing” is not what this is, let’s not overload
terms. Ted: Problems happens only with not recommended VPNs.  We patch a bug
that someone else introduced.  Application problem. Adam: Private browsing is
something else.  Real privacy requires a lot more than hiding IP address.
Jonathan L.: Argues for application. MT: This is because people are using VPN
to get to netflix. Bernard: SRTP MKI: do not use Bernard: negotiation: do not
use Bernard: one association DTLS non muxed case: do not use

Justin to produce text

draft-ietf-rtcweb-transports: (HTA) 20 minutes
http proxy
uncontroversial
per-media-type bundling
Harald: draft says what mailing list consensus is (Justin, EKR)
Jonathan: punt to 1.1?
Cullen: from transport viewpoint we can have more than one bundle
Harald: it’s allowed to reject more than one bundle group.
Harald: text says “may support”
Magnus: fine with that.  Should be reflected up the stack (more than 1 bundle
group) Justin: argues for a simple mechanism in 1.0 Adam: same Harald:
conclusion: text in -08 says roughly what it should say, but there is
uncertainty and review is needed JSEP/Transport/Bundle and suggest changes on
list

Proposed addition to transport
RETURN reference (Schwarz doc):
Ted: later

SRTP-DTLS over ICE
Justin: 5764 is clear.
Harald: Justin to send text
Bernard: forking?  Multiple ICE transports
Harald: components are scooped by ICE
Bernard: no

No conclusion

Keith: pointed out that even if github is used, all discussion needs to happen
on list not in github tracker. Chairs: text proposals on github ok, formal
discussion and decisions made on list only

draft-schwartz-rtcweb-return-04: (Schwartz) 10 minutes

slide “Same turn-server twice”
Martin:that’s ok
Cullen: how do we discover this?  Security
ben: out of scope
Cullen: need to answer
Ben: tram WG owns discovery,
Cullen: so they are working on stuff that has big security issues
Cullen: more security issues
Alan Johnson: how to use two turn-server into one .  Leave that to app
Justin: don’t want to use the same proxy.
Justin: decision to adopt text as WG item

Very rough consensus for adoption of draft as WG item
Cullen as individual: formally objected to way this done
Confirm on the list

draft-nandakumar-rtcweb-sdp-07: (Nandakumar) 10 minutes

not discussed

RTCWEB Wednesday 25th March 2015
==================================

Chairs:  Cullen Jennings, Sean Turner, Ted Hardie

Administrivia
--------------

Presenter: Chairs

Slides: http://www.ietf.org/proceedings/92/slides/slides-92-rtcweb-5.pdf

Chair Doc Review
-----------------

Presenter: Chairs

Slides: http://www.ietf.org/proceedings/92/slides/slides-92-rtcweb-5.pdf

Keith Drage: asked about gateways document.

Cullen: Not on the slides.

Keith: Indicated it is a normative dependency of 3GPP RTCWEB usage.

Action item Cullen : add the gateway draft to the deps draft

Justin Uberti; [Something about martinsen-mmusic-ice-dualstack-fairness]

W3C Security Issue
-------------------

Presenter: Eric Rescorla

Martin Thomson: Had some discussion within Google on how permissions are
managed in browsers, Basic principle that needs to be applied is some
flexibility on how permissions are presented. At same time need the APIs
permissive of variations in security. Therefore, needs to be less strict
guidance in the specifications. Discussion is continuing.

Wendy Seltzer: Join W3C trust and communities permissions group.

Eric Rescorla: In ??? no way to give a temporary permission at all.

Wendy: Would like to see option to turn it off.

Harald Alvestrand: Not about how browser and user interact, it is about how the
browser and the javascript interact.

Harald: Could do with constraints. May be easy to do and not slow things up,
question is whether it makes sense to do it.

Eric: Arguing for removing this text from the IETF draft.

Ted Hardie: Call attention to the fact that still have settings in browser for
handling for this.

Keith Drage: Asked whether community outside the room was aware of this.

Ted (as chair): Can we take this to the list without a new WGLC.

Magnus: What other changes are needed to this document. More changes than this
one, which would need further WGLC.

Paul Kyzivat (via Jabber): as a browser user I want the ability to choose "one
time" or "persistent".

Justin Uberti:

Chairs:

Presenter: Martin Thomson

Slide 1
Slide 2

Addressed remaining open issue in security-arch document.

Implementations do not follow this guidance in section 4.1.1.

Slide 3

Proposed to remove text. Add a note.

Justin Uberti: Where will this live.

Martin Thomson: Suggested media capture screenshare work in W3C.

Justin Uberti: People unconvinced by text. As long as it lives somewhere.

Martin Thomson: Now have two places to point at.

Keith Drage: Text on screen does not make sense. If saying something about
additional requirements, then need to say that they may be developed at some
point in the future.

Martin Thomson: Agreed. This will not be the final text.

Bernard Aboba: Should go back over the comments from WGLC. None of this that
came after WGLC ended up in the document.

Chair: Going through WGLC will be dealt with as 1st item on Thursday session.

Javascript Session Establishment Protocol
-----------------------------------------

draft-ietf-rtcweb-jsep-09

Slides: http://www.ietf.org/proceedings/92/slides/slides-92-rtcweb-0.pdf

Presenter: Eric Rescorla / Justin Uberti

Slide 1
Slide 2
Slide 3
Slide 4: Issue #114

Suhas: Clarification question

Peter Thatcher: If remote side does one and the other does not, what happens.

Eric Rescorla: Will still get some tracks. Might be some crazy endpoints that
want something different.

Martin Thomson: Maybe an API issue, but if fail the track some implementations
will report they have moved into stable state.

Slide 5

Christer Holmberg: Indicated that are not subsetting offer / answer but are
supersetting it.

Slide 6
Slide 7

Christer Holmberg: Is this only the initial offer?

Eric Rescorla: Only the initial offer and only an example.

Slide 8
Slide 9

Keith Drage: Clarify whether informative or normative and what happens with
something that is not listed.

Slide 10

Jonathan Lennox: c line should probably detect a mismatch and fail.

Justin Uberti: Comes under class of what sort of semantic processing should
occur.

Cullen Jennings: One of the great things about ICE is that when c line is
messed up, things still work. If not going to use, then why check it.

Paul Kyzivat (via Jabber): syntax of attributes presents issues. The abnf of
4566 doesn't specify syntax of particular attributes. 4566bis does. if were to
reference 4566bis, must syntax of unsupported attributes be checked? I think
must enumerate a set of attributes for which syntax must be checked.

Slide 11:

Justin Uberti presenting.

Magnus Westerlund: AS has no defined offer / answer semantics, defined for
declarative use. Was going to check some of this when called to mic. CT should
not be ignored, this is the total for the stream.

Roni Even: Each line of media level can total more than the cT. If nothing
happening on one media stream can take that for another. What happens when
individual streams go above is implementation dependent. Also TIAS is being
used by conference systems today in offer / answer.

Martin Thomson: This may be a distinction between the browsers. If set CT to
total then most of time may not be using all that bandwidth.

Magnus Westerlund: CT ???

Randell Jesup (via Jabber): AS is a maximum, not the amount used at any point. 
CT is the limit for all (at a given point).  I agree with Lennox/MT/Roni.  some
streams are very bursty (screen share, data channels)

Keith Drage: Need to be clear what trying to do here. Is there a clear RTCWEB
reason for fixing this, or is it regarded as a general problem with the
underlying specs, in which case should be fixed in MMUSIC.

Cullen Jennings: Thinks OK for RTC WEB to mandate some of this. Just saying
what one has to implement.

Jonathan Lennox: If trying to say things like AS does not make sense at session
level, then thinks these should go back to MMUSIC.

Mo Zanaty: Does not think there is an issue here with regard to b=. Should
focus on what is useful for RTCWEB. Being used to control send bandwidth of
browser - specify this in remote description. Not relevant for getting local
descriptions.

Jonathan Lennox: Getting into case where offer / answer broke semantics of SDP.
Need to see what offer / answer says about CT. Does not remember what offer
answer says about CT.

Magnus Westerlund: ???

Cullen Jennings: In offer answer indicates bandwidth the offerer would like to
receive. In MUX draft deal with case that bundle breaks CT. Coming round to
other specs already get this right.

Slide 12: Issue #5
Slide 13
Slide 14

Martin: Thomson: If know decoder limits are less than one of these, do we allow
PT in place of *.

Justin: OK

Martin Thomson: Therefore per codec is OK.

Magnus Westerlund:

Justin: Definition of q values is fairly vague. Cases where might emit stream.
Not clear whether should be satisfying as many q values as possible, or just
the highest value q.

Martin Thomson: Magnus is saying: Have a range of things one can do, but a
narrower range of what you prefer. (Martin) would prefer with what Magnus is
proposing as too many extra preference stuff.

Harald Alvestrand: There is a proposal in JSEP repository from Harald. Made his
head hurt. This proposal has two nice properties, is clear what it does, and
allows to add more knives in the future.

Cullen: When investigated Haralds proposal lots of corner cases where it did
not work where it is hard to fix. DOes not think these work for the transcoder
case.

Mo Zanaty: Need to understand what this means from the browser.

Justin: Whatever is in receiver remote description will control what the
browser sends.

Eric Rescorla: Just for understanding then if this going to work properly with
video tag then need to ... How to get app...

Justin: Not an API service to do this yet.

Eric: WHat does "intersect" mean?

Magnus Westerlund: Can accept this. Question: Are allowed to use the step value.

Justin: Martin Thomson shaking his head.

Martin Thomson: There are decoders out there that only work in 8, 16 ...
increments. Is concerned about the API impacts of this as Eric Rescorla was.

Magnus Westerlund: Worry is that when one comes webrtc compatible endpoints
they may give more information that allowed by this.

Randell Jesup (via Jaber): I support this, with Martin's comment about
payload/codec specifiers.  This will work and many other bits can be handled by
applications (and maybe use of RTPSenders/etc)

Martin Thomson: Which options here: Ignore, reject the SDP.

Justin: Receive the highest q value and ignore everything else.

Chairs: Resolve current open issue as proposed on slide with addition of what
happens when receive different q values as clarified above. Consider more
complex things in the future.

Slide 15: Issue #72

Eric Rescorla presenting.

Ted Hardie: Seems like the only logical thing to do and should fix it this way.

Christer Holmberg: Need to make sure is aligned with the sctp-sdp draft. If
receive answer that and switch roles...

Martin Thomson: This is fine.

Justin: May be things that blow up if don't get actpass in the offer.

CHrister: If starting new one then roles can be renegotiated.

Slide 16: Issue #76
Slide 17

Presenter: Justin

Martin Thomson: Is oK with this, but to be clear No way to coerce the browser
into state where it has media on hold.

Slide 18: Issue #119

Peter Thatcher: Just affecting SDP offer. Browser could reject SDP that has
more than one bundle group?

Justin: If remote send multiple bundle groups then have to honour that. JSEP
endpoint will only generate one bundle group.

Christer Holmberg: No matter how many bundle groups one is offered one always
has option of rejecting an individual bundle group.

Peter Thatcher: Can one reject all except one bundle group.

Justin: Need to talk about that more. That would imply JSEP is profiling bundle.

Harald: This is crossing transports. If say must not accept more than one
bundle group have locked oneself in.

Cullen Jennings: Use case for multiple bundle groups. Would not want to rule
out cases like this.

Martin Thomson: Supporting some use of receipt of multiple bundle groups, at
least in future.

Paul Kyzivat (via Jabber): if you end up with two bundle groups, then jsep must
decide which one to use for subsequently added tracks.

Eric Rescorla: Have we decided what happens if JSEP modifies...

Justin: We do do that.

Jonathan Lennox: Sad to see that certain things can only be achieved by a
remote offer and not by a local offer.

Cullen Jennings: Preferred Martin's of must support at least one and may
support than one.

Discussion should continue on the list.

WebRTC Forward Error Correction Requirements
--------------------------------------------

draft-ietf-rtcweb-fec-00: (Uberti) 30 minutes

Slides: http://www.ietf.org/proceedings/92/slides/slides-92-rtcweb-1.pdf

Slide 1
Slide 2
Slide 3
Slide 4
Slide 5

Colin Perkins: Have no real opinion, but for 2198 redundancy but do not really
need to use a redundant encoding.

Slide 6

Jonathan Lennox: ???

Justin: Might be a subset of a more general problem.

Colin Perkins: RTP usage draft say must implement circuit breakers. If not
implemented, then if quality is dreadful then stop.

Cullen: Need to say in FEC that if implement FEC then also need implement
congestion control.

Colin Perkins: 2198 already has words in security considerations about this.

Magnus Westerlund: ???

Justin: FEC only send when conditions warrant it.

Jonathan Lennox: Maybe gateways should be mandated to ensure rtCP is sent.

Colin Perkins: Please read the RTP usage draft.

Jonathan Lennox: Treat this as if never get RTCP then should trigger circuit
breakers.

IETF-92 RTCWEB

1/ Chairs slides (Cullen Jennings)
There's the draft-jennings-rtcweb-deps draft which has the list of dependencies
and their status, please send corrections to it. About 50% of our normative
dependencies are in RFCs or publication request. So that's a big difference
from last time. A lot of stuff still in progress. Most of them are moving along
Want to draw attention to martinsen-mmusic-ice-dualstack fairness draft : still
in individual item and because of its interaction with ICE, people should keep
an eye on it. But that was the only one. Any question on any of those ones, on
when we are? Keith Drage: Which slide is the gateway draft on? Cullen: not on
there, not a normative dependency of the current APIs from the W3C. Keith:
would like to stress that there is a normative dependency from 3GPP documents
using RTCWEB, so we would like to be carried forward. Cullen: ok, send me
comment on that Justin Uberti: A comment on the dualstack-fairness. Because of
some of the rules we have adopted in transport regarding which v6 address we
use, I think the problem is not as currently described in the draft. So it's
nto a critical thing to be solved for achi-sec because of specific set of
addresses for IPv6

2/ Security Architecture Issue

2.1/ Permissions (Eric Rescorla)
The security architecture document has a requirement on the W3C specifications.
It describes the conditions under which persistent permission grants can be
given to access the media. The first thing it says is it only gives permanent
permissions grants over HTTPS and the second thing it says is that there needs
to be affordance in the media API ask for persistent permissions otherwise you
have to grant temporary permissions per session. No browsers implements this
and the W3C API does not contain any affordance for doing so. Chrome basically
grants ephemeral permissions if you are an HTTP URL and permanent permission if
you are an HTTPS Origin. Firefox grants ephemeral permission if you are on
HTTP, and for HTTPS it gives you the option, with basically an invisible
drop-down, to select the proper permission... we are probably make this
drop-down easier to see because we have people who complain about the target
prompt in Firefox and not Chrome. So The question on the mailing list was
raised by me: Should we update the WebRTC API to have this affordance or should
we remove this requirement in the security architecture document? So this
morning, Justin, Martin and me discussed about this and came to the conclusion
that this we should modify the IETF document to remove this requirement and
probably at some point we'll come up with some software guidance for the W3C
document about on asking the user persistent permission or, conversely, by the
way, this becomes persistent. @Martin Thomson: To expand on that, I got some
discussion with people from Google on how permissions are managed in browsers.
We need to have some flexibility with respect how individual browsers presents
security UX because they may have different way of communicating to the users,
different security postures in general, or they want to experiment various ways
to present UX and manage security. And at the same time we want the API
permissive of variation in the security UX. So that's more or less the
agreement we naturally come to, which suggested less strict guidance in the
specifications. We do hope we can get some arrangement on how we present to the
UX... EKR: we need to do something here, because right now we are in
contradiction Wendy Seltzer: I want to invite people interested in permissions
questions to join us the W3C Trust and Permissions community group where we
trying to bring best-practices on permissions... Cullen: Wendy, you sort of
representing the concerns of users for this type of system. Would you want to
see our spec demand permission at one time because right now you grant the
permission permanently and if you don't give it at all, it's nearly impossible
to remove it. EKR: there's no way to give temporary permission in Chrome. In
Firefox you can give temporary even on HTTPS. Cullen: I think the question is
if we should say something, for the user privacy point of view whether it's an
option to grant a temporary permission or an option to go into your settings
later and revoke permissions. EKR: every browsers supports that, it exists
Harald Alvestrand: with W3C hat on. This is not about how the user and the
browser interact, but how the JavaScript and the browser interact. EKR: when I
wrote this text I thought the browser would provide 2 permissions, you remember
Adam Barth. The idea was . Nobody does this. Harald: the API does not allow JS
to tell the browser whether or not the permission should be permanent. EKR:
that's correct. Harald: I was looking through the cases and I found I could do
this with a delay below constraints and I could argue successfully about 6
postures the JS could ask for. It may be easy to do. The question is whether we
need to do it, given at this present stage in the experimentation that nobody
has asked for it. EKR: to be clear I was thinking to remove the text from the
IETF draft.. Ted Hardie, as indiv: basically do what you say, but pay attention
to the fact that when the change is made that there's still gonna be
mechanisms, in the browser, further studies for doing this will take place. Not
2119 normative language. Keith Drage: Has this been raised on the list because
there's no slides. EKR : yes, raised about 2 weeks ago on the rtcweb &
public-webrtc lists. Wendy: the web-application wg has in its charter
application and permission topics. Ted: we obviously need to take this back to
the list. Do the group think we need a full new WGLC? Magnus Westerlund: I
start with my old comments. I think that there's more than that comment that is
needed to be discussed. Ted: In effect, we have already finished the WGLC; you
propose to re-open? Magnus : yes because of other issues Paul Kyzivat: as a
browser user, I want to be able to use "one-time" or "persistent" Ted: From
what Harald said, do you want the JS to use that, and that's a very different
question. Justin Uberti: that's just an implementation question for the
browser. Should there be an API saying "hey, I want get this permanently or
temporary", ... that's probably not a solution to this issue. Ted: So Magnus,
raise you other comments to the list. Based on that we'll see if we need to do
another WGLC. But we're moving it out the publication request state.

2.2/ Screensharing (Martin Thomson)
Discussion on the '[[OPEN ISSUE: This section does not have WG consensus...]]'
related to screen sharing. RFC Editor, fix it for us please :-) There are
implementations on such things, but they don't follow that guidance. Proposal:
Not a problem related to the network, this work is being done in W3C. we (i.e.
IETF RTCWEB) defer to that work, we remove the text in this document, but we do
add a note that screensharing is out-of-scope of the document, there may be
additional future requirements, but not in the details at this point. Justin:
where is the new doc if we remove it from this doc? Martin: media capture
screen share, a W3C document that has been adopted now. Justin: the reason I'm
asking it is that there are a lot of people are unconvinced by a wider screen
sharing extension. Keith: "some additional requirements may apply" do not make
sense. Martin: text in my slide is only indicative, effectively. Martin: I
think we can solve that pretty quickly and have another last call. Bernard
Aboba: There were other things during the WGLC; they did not end anywhere as
far as I know; like session resumption DTLS. All the stuff which happened after
WGLC, none of it appeared in the document. Cullen: propose to go over these
items during our next meeting; we give a chance to people to do it on the list,
make some slides and we can discuss them.

3/ JSEP (EKR and Justin Uberti)
#Slide "Some Changes since last draft."
Some non controversial like change TCP/TLS to UDP/DTLS in RTP profile names.
Some need review

#Slide "Issue #114 Policy controls for RTCP-MUX"
Two policies : one for bundle, one for rtp-tcp-mux.
Conclusion on names: "require" and "negotiate"
This raises the question what the answerer must answer.
Peter Thatcher: if you reject the track, you reject all the tracks?
EKR: it may be hard failing
Martin: there's bunch of reasons you might end up with m lines having 0

#Slide "SDP: The Good Parts"
Goal: do not define SDP, but give guidance, philosophy
Christer Holmberg: not a subset, supersetting offer/answer (e.g. provisional
answer); good to show how these part are treated different from RFC3264

#Slide fill in gaps
describe what we're trying to accomplish
In many cases, sdp is not very clear. so  when necessary, fill the gap in such
cases

#Slide "Contradict in rare cases"
For example, "k=" lines or accepting "stack" profiles
but we'll ask for consensus for such things
Colin Perkins: k= should be make in the RFC.
Keith: Can you clarify what is informative or normative?

#Slide "Processing lines in received SDP"
Basically the sketchy version of what we try to follow the principles I just
told you about Jonathan: "c=" to check that there is no middlebox that did
understand ICE. If yes should fail. Cullen: things great with ICE is that even
if c line is bad, your call still works, so I'm not exactly sure. EKR: Jonathan
takes an issue on this EKR: trickle issue. Martin will raise issue on github.

#Slide b= SDP
Lengthy discussion on CT, AT and TIAS...
Magnus: TIAS only has declarative mean, no offer/answer semantic
Roni Even: what is important is the precision you need on the limit (as or TIAS
may not be important except if you want precise values) Justin: for audio
bandwidth value in AS might be very higher than with TIAS. Cullen: to answer
Keith's question, I don't think we change the original spec, we just give more
information on their use when a browser use them. Mo : spec should make clear
that CT is the sum of all (remote and local senders) Jonathan: CT originally
written for multicast, O/A changed that, CT means all the things Magnus: I
think it would Cullen: RFC 3264:  indicate the bandwidth the offerer the would
like to receive Most document should probably be all right. Ted: 15' left.
Should we continue on this or move to next topic? Cullen, Justin: propose this
text and see if people can refine it.

Slide "#5 : imageattribute"
how to express what the maximal resolution you can receive
Martin: per codec would be ok? Justin : yes
Magnus: why you can't use the q list to express what you need?
Justin,: q value's definition is fairly vague: you can imagine different things
with it. Magnus: the purpose of q value is to indicate "this value works for
me". Martin: I would rather do what Justin Proposed. Harald: I have tried to do
what Magnus suggested. Justin's properties has nice properties. Cullen: I think
we need something like list, solves every need we have Martin: I would like to
have only what we have on the #5 slide here. Then we can discuss the API
separately. Randell Jesup: I support this. Magnus: my worry, when you come to
webrtc compatible endpoints, it might send you more information. I will send a
text later Martin: the other endpoint might not be a browser and might send
imageattribute q values Justin: I have a proposal taking into account the
highest q value present Martin: that's interoperable, that's fine Ted: that
will be the current resolution of the document.

Slide: "Issue#72 DTLS role for re-offer"
want to preserve the roles.
Ted Hardie: I think this is the only way, we must accept it.
Christer: we need to make sure it is aligned. The other endpoint may not be a
browser, he can do whatever o/a allows home to do. Justin: they may also be
over without actpass Jonathan: describe what you want to do

Slide "#76 Handling Stopped Tracks"
We said we could add a new bit of SDP
Proposal: instead do nothing,  “A” won't know how to remove it's track, but
provided “B” continues to ignore A's video stream, it works. Martin: I agree.

Slide "#119 How many BUNDLE groups are there?"
proposal always only 1 Bundle group
P. Thatcher: ? if application performs SDP mungin with more than one bundle? 
Justin: that's implementation dependant. Peter: a browser could reject it?
Justin: yes. Peter: what if the remote answer contains multiple Bundles?
Christer: you always have the option to reject the bundle group. Harald: this 
part interferes with the transport document. Cullen: you may want main video in
a group and thumbnails at lower quality in another group Martin: propose we
must support one bundle group, we may support more than one. I don't want to
say we just support one. EKR: what happens if JSEP modifies the bundle group:
Justin: I propose we don't do that Justin: propose to jam in the first bundle
group if multiple ones. Ted, The authors should write what they propose on the
list and we'll have more discussion on the list.

4/ FEC in WEBRTC (Justin Uberti)
No need for FEC at transport level for DataChannel, free to do it at
application level We'll have basic FEC, not cross streams FEC. Open-issues: -
Should we support XOR FEC for audio? Issue this multipacket protection adds a
significant delay, no good for real time application. Nobody needs something
else different from RFC2198 - Security considerations. How do deal with legacy
devices that do not generate RTCP for audio RTP?

Thursday,  =============================================================

Open Issues in Security Arch Draft (MT & MW) 15 minutes

Slide 1  MTI lag for a=fingerprint– MUST SHA-256 MAY SHA-1 revise SHA-1 policy
to MUST NOT later.

Russ – why not say SHOULD NOT use SHA-1.
Martin: SHA-1 only for validation not sending
Bernard: SHA-1 for backward compatibility this is for validation
Cullen: we need to support backward computability or update the old RFCs.
No conclusion yet on this

TURN only slides:
Justin: document this knob that will allow the browser to force to TURN only
mode. Ted: concerns to leave too much for the users to make decision so define
when it should be the default mode. Cullen: if you worry about privacy, the
application should do it by stripping addresses that you do not want to
disclose. Adam: IP address is not the only information need to worry about
privacy.

Conclusion: need text to reflect that the browsers should do. Justin will
produce text.

draft-ietf-rtcweb-transports: (HTA) 20 minutes

jsep does not support “all video bundled, all audio bundled”. So changed to
may. Required support for multiple bundled groups Jonathan: the API will
support it Harald: transport should be consistent with jsep. Cullen: if you get
an offer with multiple bundle group it is allowed by bundle. Harald: in jsep –
do not support multiple groups Cullen: not sure that it was agreed. Transport
should support it Harald : change for must support one bundle and multiple
bundle. suggest must support one and may support multiple

EKR : non jsep can send an offer with multiple bundle group

Justin: it make sense to bundle audio and video. And may have others bundles.
So jsep should receive but send one bundle.

Adam: leave it and not say more about it.

Conclusion : the text is correct but need review of transport, bundle and jsep
for consistency and comment on the list

SRTP-DTLS over ICE – 5 tuple
 Conclusion: Justin  will send text after MMUSIC Friday

 draft-schwartz-rtcweb-return-04:

It is now return 05

Cullen: need to understand the auto discovery since it may be security issues
like Man In The Middle Alan: we need to see how to work with two TURN servers.
Security need to be addressed but this is a controlled environment.

Ted: want more discussion
Justin: want to adopt

HUM for adoption Weakly in favor