[Wish] Implementation report for draft-ietf-wish-whip-00

[Juliusz Chroboczek <[e-mail]>]

Hi,

Lorenzo and I have just shown interoperability between his client and my
server.  Lorenzo's client was almost perfect, the only issue was that he
was sending ICE candidates to the wrong endpoint.  I haven't implemented
ICE restarts yet.

A few preliminary conclusions.

1. Even in its current early form, the draft is good enough to implement.

2. Asymmetric ICE (blocking ICE at the server, trickle at the client) was
   surprisingly easy to implement and works quite well.  The only issue we
   noticed is that since the ICE candidates are sent to the resource
   endpoint, the client must buffer ICE candidates until it receives the
   initial answer.  I think this deserves to be mentioned explicitly.

3. The draft lacks guidance about error handling; for example, it doesn't
   tell me what to do if appling the offer fails (500?), if I cannot parse
   an offer or an iCE candidate (400?), or if I receive an unexpected HTTP
   method or content-type.

   A couple tricky ones:
   
     - what is the error to return when I receive an ICE candidate for
       a PeerConnection that used to exist but has been closed?  I'm
       currently doing 404, which means the client cannot easily
       distinguish between this case and that of a wrong value for the
       resource endpoint.

     - what happens if a candidate is followed by random non-JSON garbage?
       Is that an error?  If so, MUST I return an error or MAY I return an
       error?  I'm currently just ignoring the garbage.

4. Detection of failed clients, as mentioned in a previous message.  It's
   a tricky issue, and needs to be specified precisely or people will get
   it wrong.

5. As somebody already mentioned, the draft lacks guidance about
   authentication.  I've implemented HTTP Basic on the WHIP endpoint, and
   I'm not sure what I should do on the resource endpoint: require HTTP
   Basic in the same realm as on the WHIP endpoint, require HTTP Basic in
   a different realm, or assume that the resource endpoint is a well-kept
   secret with enough entropy to not require authentication.

   Authentication is pretty much application-specific, so I think we'll
   need to be careful to provide precise guidance to the client without
   overly constraining the server.

-- Juliusz