# WISH at IETF 114 Maintenance (avtcore) Working Group   {#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