Re: [MMUSIC] Trickle ICE for SIP Questions

[Emil Ivov <[e-mail]>]

On 06.07.13, 00:45, Marc Petit-Huguenin wrote:
> -----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.

Are you suggesting that we would always need to do half trickle, even 
when we know the other party has support for trickle and can switch to full?
>
>>> 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?

Even then, endpoint dependent filtering (which seems to be the default 
these days) requires that both ends start sending packets simultaneously 
for server-reflexive addresses to work.

In the case above the trickled candidates wouldn't be able to reach the 
offerer because it wouldn't be sending anything toward the answerer.

>>> 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 believe it's always been about both. (Otherwise we would have probably 
stopped at STUN).

> i.e. so far nobody proposed
> to tunnel the media over SIP :-)

You'd be surprised ;)

https://java.net/projects/jain-sip-applet-phone

Emil
>
>>
>>> 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-----
>

-- 
https://jitsi.org