[Wish] Updated proposal for tricke ICE/restart and (maybe) server sent events

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Wed, 10 March 2021 11:35 UTC

MIME-Version: 1.0
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Date: Wed, 10 Mar 2021 12:34:52 +0100
Message-ID: <CA+ag07bs6doWaFQvpvHsHa6F+=LGXa57UkejbK5FZXZCbpdWfA@mail.gmail.com>
To: wish@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c94bd305bd2d0e2d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/wish/rRXzxCT5zh_wuRdG_PHQCzhBdqQ>
Subject: [Wish] Updated proposal for tricke ICE/restart and (maybe) server sent events
Precedence: list

Hi all,

I have been thinking on how we could accommodate some of the feedback
received yesterday at the meeting and implement this in a pure HTTP-like
way.

The publish will be started by sending a HTTP POST to the session creation
URL with the SDP offer, and the server will answer with a HTTP “201
Created” response with “Location” header field pointing to a newly-created
resource and the SDP answer in the body (no change up to here from the
original proposal).

For performing trickle ICE or an ICE restart, the publisher will do an HTTP
PATCH request to the resource URL with a body containing a SDP fragment
("application/trickle-ice-sdpfrag") as specified in RFC8840 with the new
ice candidate or ice ufrag/pwd for ice restarts.

For simplicity terminating the session, the publisher will send a HTTP
DELETE to the resource URL.

The server may terminate the session by using the Immediate Revocation of
Consent  as defined in https://tools.ietf.org/html/rfc7675#section-5.2.

While I don't like long pooling, I acknowledge that we may wish to allow
servers to send back events to the publishing client. In that case I would
prefer to use server sent events as specified in
https://html.spec.whatwg.org/multipage/server-sent-events.html#server-sent-events

The url connecting to the server side event resource for the publication
will be returned in the initial HTTP "201 Create" response with a "Link"
header an a "rel" attribute of  "urn:ietf:params:whip:server-side-events"
(in a similar way as how web push works).

So the http 201 response would look like

Location: https://watever.com/publications/213786HF
Link: <https://watever.com/publications/213786HF/sse>;rel="
urn:ietf:params:whip:server-side-events "

Other extensions could be added by registering new "rel" values on IANA.

Last, as I commented out on the call, I don't see the value of the
signaling plane keepalive and in fact it is something that has caused
issues on our deployments.

Best regards
Sergio

[Wish] Updated proposal for tricke ICE/restart an… Sergio Garcia Murillo