Subject: [Wish] Trickle ICE and ICE restart

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 13 Sep 2021 16:32:48 +0200

Hi all,

I have added both trickle ice and ice restart to the js whip client, and
here are my findings while doing so:

1) The trickle-ice-sdpfrag payload seems a bit weird when following
the rfc8840 procedures for generating it:

a=ice-ufrag:v2kP
a=ice-pwd:OyaIFlRkSjK4dnx1KfasyJk1
m=audio RTP/AVP 0
a=mid:0
a=candidate:1387637174 1 udp 2122260223 192.168.0.39 52508 typ host
generation 0 ufrag v2kP network-id 1
a=candidate:3471623853 1 udp 2122194687 192.168.64.1 52509 typ host
generation 0 ufrag v2kP network-id 2

As we are using bundle only, we only send the candidates for the first line
and the procedures in rfc8840 seem to mandate the use "m=audio RTP/AVP 0"
which is quite awkward (not sure what I would need to put if doing a video
only session).

If we could just extend the ABNF grammar, we could just send the candidates
at session level, and maybe even omit the ice-pwd attribute:

a=ice-ufrag:v2kP
a=ice-pwd:OyaIFlRkSjK4dnx1KfasyJk1
a=candidate:1387637174 1 udp 2122260223 192.168.0.39 52508 typ host
generation 0 ufrag v2kP network-id 1
a=candidate:3471623853 1 udp 2122194687 192.168.64.1 52509 typ host
generation 0 ufrag v2kP network-id 2

@Christer Holmberg <[email-masked]>, as the author of the
rfc8840, what do you think?

Surprisingly, the end-of-candidates flag is supported at session level, so
this is valid according to the spec:

a=ice-ufrag:v2kP
a=ice-pwd:OyaIFlRkSjK4dnx1KfasyJk1

a=end-of-candidates

2) There is a potential race condition between 2 PATCH requests, one for
updating candidates and another one for ice restart.

If you send a patch request for adding new remote candidates with ice user
fragment "A", and then you send an ice restart with user fragment "B", it
could be possible that they are processed in reverse order by the media
server, first doing an ice restart to "B" and then, when receiving the
candidates request, doing another request to "A".

We have 3 different ways of solving this:
- Force the client to send the PATCH request sequentially and not allow it
to have 2 in-flight requests (which can cause problems if the first request
is sent while there was poor connectivity and the ice restart is sent just
after the connectivity is restored).
- Force the server to remember past usernames for the client and discard
requests with past usernames. (This is the one I am going to implement)
- Remove the ice-pwd field from the sdp fragment so the server can
differentiate between both.

3) We have not defined the response code/bodies of the patch requests. I
would propose the following:

- For ice candidates, the server must return 204 (no content) status code
and no body
- For ice restarts, the server must return a 200 OK status code with a body
trickle-ice-sdpfrag containing the new username and fragment and
optionally the server candidates.

4) There is a bug in chrome that returns a different value for the ice
username on the ice transport api than the one set on the local description.

Thoughts?

Best regards
Sergio

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 13 Sep 2021 18:02:12 +0200

> If we could just extend the ABNF grammar, we could just send the candidates at
> session level, and maybe even omit the ice-pwd attribute:

Agreed on both counts.  Galene currently ignores both the m-line and the ice-pwd.

> - Force the client to send the PATCH request sequentially and not allow it to
> have 2 in-flight requests (which can cause problems if the first request is
> sent while there was poor connectivity and the ice restart is sent just after
> the connectivity is restored).

I agree, it's important to be able to send a restart at any time.

> differentiate between both.

I think it should be possible for the server to differentiate between the
two before even starting to parse the SDP.  We could use different MIME
types, different HTTP requests, use a custom HTTP header, or add an extra
line at the beginning of the body.

> 4) There is a bug in chrome that returns a different value for the ice username
> on the ice transport api than the one set on the local description.

I think there are more bugs in Chrome :-/

-- Juliusz