[MMUSIC] Trickle ICE for SIP Questions

[Emil Ivov <[e-mail]>]

Hey all,

Christer, Enrico and I are preparing the next version of Trickle ICE for 
SIP. Now that discussions on BUNDLE and the plans seem to be winding 
down, we wanted to run a few questions by the working group.

Q1: Making reliable provisional responses and PRACK mandatory. Obviously 
this would be nice to avoid, so the question is: is there a reasonable 
mechanism to achieve this (and by reasonable, we mean something that 
wouldn't be harder than implementing support for PRACK).

There was some discussion about this back in April and there was a 
suggestion for implementing a 5245-style hack where the answerer 
basically resends the 180 until it knows that it has been received.

5245 uses connectivity checks for this (i.e. it stops 180 
retransmissions when the first connectivity check is received) but we 
don't have that option here since the 180 may contain either none or 
only host candidates so there are strong chances that no binding request 
would be received on them.

Thomas also suggested a second option which would be to also use INFO 
requests with trickled candidates as an indication that 180 was 
received. This however wouldn't work with half trickle so we are 
basically back to vanilla ICE for all (non-re) INVITEs.

Another option would be to mandate an INFO request with 
"end-of-candidates" in response to the 180, but that would be just the 
same as mandating PRACK support.

Thomas also suggested that the answerer can start sending INFOs right 
after it sends its answer in the 180 and then it can just resend the 180 
if the INFOs result in a 481 response.

Personally I think this could potentially be made to work, but it would 
imply a level of complexity that considerably exceeds PRACK support.

Opinions?

Q2: How do we send INFOs? Are they blocking or do we just send them in 
parallel? If the latter, then what happens when an INFO fails because it 
is received out of order? Do we just tell the application to resend the 
candidates asap?

This also leads to the following question:

Q3: What exactly do we send in INFOs? Just the latest batch of freshly 
learned candidates or all candidates we've learned so far? Dale 
suggested that if we do this cumulatively we wouldn't need to worry 
about the case with the out-of-order INFOs from Q2 since the information 
gets resent anyway. A drawback here would obviously be that this adds 
more complexity for trickle ICE users (WebRTC applications specifically)

A third option would be to allow both and leave it to the application.

Comments are most welcome!

Emil

-- 
https://jitsi.org