Minutes IETF97: rtcweb
minutes-97-rtcweb-00

Minutes IETF 97
Seoul, November 14th, 16th, and 18th, 2016
Chairs:  Ted Hardie, Cullen Jennings, Sean Turner
Presentations: https://datatracker.ietf.org/meeting/97/proceedings
Jabber logs: https://www.ietf.org/jabber/logs/rtcweb/2016-11-14.html ,
https://www.ietf.org/jabber/logs/rtcweb/2016-11-16.html,
https://www.ietf.org/jabber/logs/rtcweb/2016-11-18.html

Meetecho Recordings:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_RTCWEB&chapter=chapter_1
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_RTCWEB_II&chapter=chapter_1
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF97_RTCWEB_III&chapter=chapter_1

Agenda for Day 1
The group reviewed progress since the last update, and then dived into a review
of JSEP
(https://www.ietf.org/proceedings/97/slides/slides-97-rtcweb-sessa-jsep-00.pdf)

Upon review:

There were no objections to RtpTransceiver.currentDirection/.direction split.

There were no objections to changing the ICE pool size after calling
setLocalDescription.

For making MID (and maybe RID) be generated securely (counter/random), it was
decided that MID and RID can use different mechanisms but they each have to be
secure.

There were no objections to cleaning up simulcast language

There was no support for "receiving simulcast", and much support instead for
leaving it off the table.

On the topic of PT-based SSRC latching: We need a PR by Wednesday.  Some want
to remove SSRC latching.  Others want to make the "route to the first one" a
state you can't get into. RTP routing in general: Colin and Jonathan and Cullen
and Christer will come back on Wednesday with an answer of the question of
"what documents should define demux" (BUNDLE, JSEP, etc).

For createOffer invalidation: most seem to agree that createOffer invalidates
the results of all previous calls to createOffer.  But Justin wants to make
sure it doesn't break anything.  Harald and Peter and EKR will make a "study
team" to figure this out and propose something on Wednesday.

Decision around re-offering with more codecs:  leave the spec as-is, make a
separate issue for incoming offers that have different codecs, and maybe add an
API for offering more codecs someday, but not now.

Decision for non-square pixels: WebRTC endoints don't need to support sending
non-square pixels, but SHOULD receive/render them, and could send them if it
chose.   And change "highest q=" to "first".

Decision for removeTrack: it sets the RtpSender.track to null to stop sending
immediately and be reversible, and also sets the transceiver direction to
removing sending (sendreccv => recvonly or sendonly => inactive)

Day 2

For JSEP, the group reviewed the updated proposals based on Day 1 issues,
especially the question of when an offer is invalidated
(https://www.ietf.org/proceedings/97/slides/slides-97-rtcweb-options-for-invalidating-offers-00.pdf).
 The group in the room ultimately accepted a proposal based on option D,
subject to PR language.  The group also   reviewed the FEC draft,
draft-copeland-rtcweb-p2p-idp, and the IP handling draft.  The FEC draft
(https://www.ietf.org/proceedings/97/slides/slides-97-rtcweb-fec-00.pdf) was
uncontroversial .  The IP handling draft proposal garned a good bit of
discussion on implicit consent models, especially in the case where no media
flow could be used as a proxy .  For the resolution of this issue, please see
day 3
(https://www.ietf.org/proceedings/97/slides/slides-97-rtcweb-ip-address-handling-00.pdf).

Day 3

# Overview draft (chairs)

We want to publish it now to remove it from blocking other specs in RFC Editor
Q.  No objections. WGLC will start soon.

# Security draft (chairs)

Plan to WGLC in beginning of year.

# IP Handling Topic - Martin

Goal is to get this done before IETF 98

Martin did not change mode 1,2,3,4, it is from latest version of draft. EKR
pointed the text seemed wrong. Live editing ensued.

Justin pointed out that where we put the justification in the text is sort of
editorial.

The end result is roughly that Mode 2 is default and Mode 1 is only used if
there is consent. How to get consent is not defined by the spec but potential 
mechanism is to tie this consent to getUserMedia consent.

Magnus would like it to be clear that Mode 4 includes TURN relays.

Justin plans to make a pass over doc moving to MUST / SHOULD / MAY style
language.

Justin suggested that if consent is not obtained, then use Mode 2. EKR good
with that.

Plan going forward. PR will get filed by Martin. Justin will go back to list
with this PR.

No one in room objected to the wording or plan to take it to list