[Wish] Trickle ICE and ICE restart

[Sergio Garcia Murillo <[e-mail]>]

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 <[e-mail]>om>, 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