Re: [MMUSIC] Trickle ICE for SIP Questions

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

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

On 07/05/2013 03:53 PM, Emil Ivov wrote:
> 
> 
> On 06.07.13, 00:45, Marc Petit-Huguenin wrote: 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?

No, I just am saying that the solution that I propose does not take in account
full-trickle.

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

Right.

> 
>>>>> 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).

You mean TURN?  As long as you do not care about latency, TURN is all you need
as it always works (and that's all we used for a long time, even if it was not
called TURN).  ICE was invented because latency was important - so STUN was
useful - but there is no reliable way to predict if it will work.

> 
> i.e. so far nobody proposed to tunnel the media over SIP :-)
> 
>> You'd be surprised ;)
> 
>> https://java.net/projects/jain-sip-applet-phone

Hmm, I do not see SIP as media transport in this project.  What I meant was
something like transporting the media in a SIP INFO.

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

iQIcBAEBCAAGBQJR11NYAAoJECnERZXWan7ECZwP/0skdKa9lXHs4/ogcAR+IFUA
INllP0esEp62ZtB5jOMJ2HrMEqOdyi/kFS1Ya5MnK+l5UzYnxCwDWIxC8EH/RHkp
k8MoT2W98lcIevlSiF1qZnOw8b8EJjUBbM2uQA0r3wiksRL6McbKF1iCnhhIoFOG
W4i8ap7XJYy2vc5SNUcyWyDboIG6lMt2RFAw0FZiHoCZmtSjQBVJUIxqdrfQ0zvA
gFJLnKLSCAyuk7wtpeQhXvys8I4ZmGBx2J2WRORE1lyoxGJm8C0f3Eh+4IsjMcL3
JKgdRiOIpCjBDvtD4mONp+zsVTc6O5+ngn49ew5yUnqE+IEiysMWFvKzQKuwzFqE
q1OYXU8tY3W+r39qcGy8ov0Eiyuyf7i7O5pcMeRGhDvgQZkFxI9iP2ArSEKUSxOZ
FnWBESZ5Z3HkXbbS1Rw+4RxaMOT7DvJzDvKNbfW08DK4lpifPpcNThIvOlHnoO8u
F6iZpuQ8PHYBw3ZFn2255KvwK3LA8vwcKj2ZYSY7btHBg/gP6PoVK2KNewxp+CDa
kn+8SpETE8BcbirJPKoMVxGFMYBQQBnHx9i7ikpDLOxS8G85M6mRnPQdH3D3Gavg
BBgXp+dvMV4hTKz5Kd9BmACUaxD47RAp3Faplrq/lmDcC3xqsLmqu0/C5UdPR5Jm
CzjedrEUr+QNmpmd/VFU
=sbN1
-----END PGP SIGNATURE-----