Re: [MMUSIC] Trickle ICE for SIP Questions

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/05/2013 02:59 PM, Emil Ivov wrote:
> On Fri, Jul 5, 2013 at 7:28 PM, Marc Petit-Huguenin <[e-mail]>
> wrote: Hi,
> 
> I did not receive much comments on my proposal to use STUN packets to
> carry the new ICE candidates.  To summarize, instead of using the SDP in an
> INFO and or UPDATE transaction, the new candidates can be sent on the same
> path that the media will use by default (i.e. using the candidate that is
> copied in the m= and c= line).  Because this candidate is chosen to always
> succeed (using a TURN server), the candidate will always reach their
> destination.  This will remove any problem in the signaling path, because
> it is no longer used to update the candidates.
> 
>> Here's my take: Default candidates are not guaranteed to work.

Sorry, my summary was incorrect.  It is assumed that half-trickle is used (for
the same reason than in draft-ivov-mmusic-trickle-ice-sip section 3), so the
offerer sends the full set of candidates.

>> Also, you only get to place one candidate as default. What if your peer
>> is IPv6 only and you chose an IPv4 candidate?

With the offerer full set of candidates, it is easy to find the IPv6 TURN
candidate.

> Or, what if you are both on the same LAN with
>> limited Internet connectivity? Or what if the service you use doesn't 
>> even have a TURN server?

Then what about sending the answerer candidates using all the offerer
candidates available, but in reversed priority order?

>> I am sure we can come up with many other similar situations.
> 
>> The only transport that's guaranteed to work prior to ICE is signalling.
>> There's nothing else that's as reliable as this. (If there was then we
>> probably wouldn't even need ICE in the first place).

ICE is less about reliability than about latency, i.e. so far nobody proposed
to tunnel the media over SIP :-)

> 
>> Emil
> 
>> -- https://jitsi.org
> 
> 
> Thanks.
> 
> On 07/03/2013 07:13 AM, Emil Ivov wrote:
>>>> 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
>>>> 
> 
> 
> _______________________________________________ mmusic mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/mmusic
> 

- -- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJR10yBAAoJECnERZXWan7EmtYP+wa1qTpgQNYZpZc5T+/f9+j7
QJRnTlcU7aIiCX2wDHUILbUk4YCiOh8wKHf7OiLbtAKYlgq+98KyQuViVeiRoVGl
qpRQnE+Y1SjqY/jVVc4UwJvEeP2TbW5ARmUG/bqN/dLQzNyhyJeBmBIMzYTpmxl7
SJ1M8xB5Emn8d03zb7jdUtTcy0HqN4a88R3HZqmVWH4M+wRWKVZlq4RGbpiy03Or
WKc4VFUsuQnRGMZbmkG3EGrEJEhA+kCAthKY1+EORSO6sIUYQVxq58pRmuF8DTgm
h7MO6Qtco8dJsVqgT2HQ9BZiQ60XP6X+xUPIIjJ3cHaZfjqxC6oSUKo+FXpP9Gaq
euoEbKdxiA9D37CN2vMWpcLqk0GUOE+7uJ8QVWMfYWTVWCZE1XO9uVhYnNkYtcNN
15zmqvzTRrv0qQlCzgLSfeXpBAcsv46GZdqd/HKcczlgutFil7QNFyKAJD9njNLg
VeO5nWs5Koqn8cug+GlBG/dFNTdFss/0vlX6HsBdyqIpWKPdf4gwueAS3QVieUEb
cMFKOUzThLpOgTkkhzJQuY9N6ynBiF8Cn1t1cPJQZksMtuKRjRJo5BKHOfwLufk4
fgLJOuUEJkcklrrBIbqRfpfERGQ4aFZMxvWN3LO3vx4a3bL4/M8kGst871MWMR1S
EEdIVr/mOjJMEimq9cjK
=bnR1
-----END PGP SIGNATURE-----