Skip to main content

Minutes IETF114: wish: Wed 13:30

Meeting Minutes WebRTC Ingest Signaling over HTTPS (wish) WG
Date and time 2022-07-27 17:30
Title Minutes IETF114: wish: Wed 13:30
State Active
Other versions markdown
Last updated 2022-08-16


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
  • Adam - 405 is the right way to do this, but the wording needs some


  • 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

  • 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
  • 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

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