WISH at IETF 114 Maintenance (avtcore) Working Group

Notes by Spencer Dawkins, who apologizes in advance ...

WHIP is just resolving comments on wish-whip-04 in this meeting

Sergio started with wontfix issues from GitHub

• each wontfix is explained in the presentation

• No objections to Sergio's list in the room

ICE and NAT Support

• Is it legal for a server to support Trickle ICE but not ICE
  restarts?
• Adam - 405 is the right way to do this, but the wording needs some
  tuning

TURN/STUN

• May also server configuration in response to authenticated OPTIONS
• What if the resource doesn't require AUTH?

• Adam - text is a little backwards. 501 means "I don't know what
  you're talking about"

• Why is this optional? Seems trivial to implement

• Jonathan - but you could support this for other reasons - if you
  support PATCH for any reason you shouldn't return the "I don't
  understand PATCH" error, even if you support neither ice-restart nor
  trickle

• Juliusz - first generate offer. Either you understand the option, or
  you don't, with two different behaviors for clients. What happens if
  we have a restricted network? I want to recommend a configuration.

• Sergio - don't think that's possible
• Juliusz - not giving enough guidancde to implementers - suggestion
  is to mandate on server side
• Sergio - cannot mandate server side in the specification. I don't
  want to support ...
• Juliusz - what happens when the server and client don't work?
• Adam - point raised on the list was that it may require resources to
  provide URLs - not realistic for servers. If a client sees that this
  is happening, they should tell the user
• Cullen - no reason we can't mandate server behavior. If a fully
  compliant client and server can't interoperate, that's not a great
  situation
• Take it to the list to finish the discussion if one behavior should
  be recommended by the draft.

"Passive" Setup

• RFC 5763 advises to use "actpass" - not doing that is a bad idea
• The answer is mandated to use passive - no reason the offer can't be
  actpass, following the standard

ICE servers known too late to be useful

• Candidates from server could be sufficient to establish the ICE
  connection

Multiple streams/tracks handling

• WHIP is limited to two tracks (audio and video), but the draft
  doesn't contain this restriction
• proper behavior is that the client should stop sending the stream
• Adam - 406 is a failure for content negotiation. 422 might work,
  otherwise, probably 400
• Jonathan - some user extensions might be difficult to deploy. Does
  the client know how the server is expecting audio only?

Register "whip" in IETF URN sub-namespace

• No discussion
• Talking to IANA, being proactive

Next steps

• Update draft
• Publish revision
• WGLC again?
• Sean - changing 2119 requirements, so thinking WGLC. When can you
  have a revision ready? Looks like September for WGLC of new version

Steps after the next steps

• Adam - suggest that we get field experience before doing more work
  on the protocol.
• Sergio - I agree with Adam that we need to get field experience
  (although I do have ideas for further work in this space)
• Sean - will go dormant after WGLC + IESG comments

Sergio - WHEP draft in 6 minutes

• wanted to present here to get feedback
• WHEP draft is basically s/WHIP/WHEP/g for egress
• Not in scope for WHIP WG at this time
• List of reasons to do WHEP in the slides
• Recharter WHIP working group after whip draft to do egress?
• Slide on WHEP protocol operation
• Discussion here to continue on the mailing list