Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice

[Emil Ivov <[e-mail]>]

Hey Marc,

On 04.04.13, 18:46, Marc Petit-Huguenin wrote:
>>>> 1. Trickle ICE is not a new mechanism. It has been out there with XMPP 
>>>> for almost 8 years and it is now also part of WebRTC. SIP is the late 
>>>> arriver here and SIP implementations of trickle ICE are more likely to 
>>>> have to adapt to existing working systems than the other way around.
>>>> We therefore believed that it would be a good think to preserve as much
>>>> as possible the way that trickle ICE has been implemented with these
>>>> other protocols.
> 
> It is not the trickle mechanism that my original email tried to fix, but the
> mapping between this mechanism and SIP which, as you said yourself, is new so
> there is nothing to preserve here.

I get this. My point was that it would make sense to have it
interoperate easily. Specifically, if I am translating WebRTC into SIP,
I would just be getting individual a=candidate lines from WebRTC. It
would be nice if I could just paste that candidate in a SIP message and
send it through. It would be not so nice if I have to keep a state in
the gateway so that I can regenerate the entire candidate list every
time this happens.

Emil

>>> ISTM that there is likely to be a lot of sip-sip use, perhaps more than
>>> any other kind, perhaps not. If so, that would argue for something that
>>> most naturally integrates into existing sip signaling.
>>
>>>> 2. We do not need to use offer answer. The exchange of trickled 
>>>> candidates has nothing to do with offer/answer. It is simply 
>>>> communication between ICE agents, pretty much the way connectivity 
>>>> checks are. Trickled candidates are actually quite similar to 
>>>> peer-reflexive candidates in that they are learned outside of the 
>>>> offer-answer exchange. So, in other words, there is no reason
>>>> whatsoever that would really require use of offer/answer. There are
>>>> however many reasons not to:
>>
>>> Of course it has something to do with O/A. ICE is also exchanged in O/A.
>>> And the candidates you need to exchange are coupled to what was exchanged
>>> in O/A.
>>
>>> Suppose you do one O/A exchange including ICE candidates, and then one or
>>> both sides starts to trickle candidates with INFO. Then one side sends a
>>> new offer, that changes the m-lines in some way. Presumably it will also
>>> contain some ICE candidates. And then the other side sends another
>>> trickle ICE INFO. How do all of these things relate? Is this even legal?
>>
>>> Certainly you can set down a set of protocol rules so that it becomes
>>> well defined. But you are going to need to take the SIP O/A rules into
>>> account while doing that.
>>
>>>> 3. Glare and blocking. Alice INVITEs Bob with an ICE offer. Bob
>>>> answers. Both do full trickle. One O/A exchange has completed so now
>>>> either of them can re-Offer. Obviously, if both are trickling, there's
>>>> a pretty good chance for glare to occur. Also, after Bob sends a
>>>> re-offer with trickled candidates, and then immediately learns of new
>>>> candidates, it will not be able to immediately send them because it
>>>> needs to first obtain an answer from Alice. Alice on the other hand may
>>>> have nothing to say at the moment, but she may be giving it some
>>>> thought (i.e. waiting for some checks to complete).
>>
>>> You assume that a subsequent offer is used *only* to update trickle ICE.
>>> There are other reasons for a new offer.
>>
>>> Or are you assuming some constraints such as that first you do an O/A,
>>> and then agree not to do another one until all trickling for the first
>>> one has been completed?
>>
>>>> 4. Constantly updating the state of the offer answer machine. Oh my
>>>> ... I get goose bumps only thinking about it. Every time new candidates
>>>> are sent, new offers and answers will be exchanged. Clients would need
>>>> to make sure that their view of the O/A state is properly updated and
>>>> not only that but we would also need to make sure that:
>>>>
>>>> 5. All media aware intermediaries will also have to track the deluge
>>>> of offers and answers and update their own states. It should be
>>>> perfectly fine for such intermediaries to see the first offer and then
>>>> the updated ICE offer. And that's that.
>>
>>> That doesn't work so well for those intermediaries that gate media, and
>>> so won't let anything through (including ICE) until they have seen the
>>> address in signaling and opened the gate for it.
>>
>>>> 6. ... And all this diffing. To me difs, are one of the worst parts of 
>>>> the O/A model. Analysing thousands of bytes just to find that the only 
>>>> difference is an added a=sendonly attribute ... how did this ever
>>>> happen (in comparison XMPP only sends <hold/>).
>>
>>> It is called idempotence.
>>
>>> This presumes that you implement this by first finding the difference and
>>> then applying it to your current state, rather than just setting out to
>>> apply the entire new specification to your current state.
>>
>>> There are pros/cons to both ways, and its not surprising that people are
>>> most comfortable with the one most familiar to them.
>>
>>>> Adding the same thing for trickle would make for extremely complicated
>>>> code. You'd have to be prepared to update ICE state, remap your
>>>> streams, add new ones, change codecs, and basically redo your entire
>>>> session while trickling. Toe me it sounds like of of this is not even
>>>> possible. Why would we lock ourselves into something like this?
>>
>>> So what do you propose to happen if it *does* prove necessary to do a new
>>> O/A after trickling has begun? Are you going to put the all the trickled
>>> candidates into the offer? If not, are you going to require that the
>>> candidates be identical to what was in the prior offer?
>>
>>> ISTM you must confront this in any case.
>>
>>> Thanks, Paul
>>
>>>> Pretty much everyone in RAI agrees that SDP and O/A is something we
>>>> are just stuck with and that it would be great if we weren't. Well in
>>>> this case we aren't. So why would we do it? Unless we overlooked some 
>>>> substantial issue with INFO and that issue is resolved by use of O/A
>>>> and UPDATE, then I think it would really be best for everyone not to go
>>>> there :)
>>>>
>>>> Cheers, Emil
>>>>
>>
>> Here's the call flow:
>>
>> STUN/Turn                                                STUN/TURN Servers
>> Alice                      Bob          Servers |               |
>> |               | |<--------------|                         |
>> | |   Candidate   |                         |               | |   Discovery
>> |                         |               | (1)       |-------------->|
>> INVITE (Offer)          |               | |
>> |------------------------>|               | (2)       |               |
>> 183 (Answer) |-------------->| |               |<------------------------|
>> | |               | PRACK                   |               | |
>> |------------------------>|               | |               |
>> 200 PRACK |               | |               |<------------------------|
>> | |               |                         |               | (3)       |
>> |     UPDATE (more cands) |   Candidate   | |
>> |<------------------------|               | (4)       |               |
>> 200 UPDATE |               | |               |------------------------>|
>> Discovery   | |               |  Connectivity Checks    |               | |
>> |<=======================>|               | (5)       |               |
>> UPDATE (last cands) |<--------------| |
>> |<------------------------|               | (6)       |               |
>> 200 UPDATE |               | |               |------------------------>|
>> | |               |                     180 |               | |
>> |<------------------------|               | |               |  Connectivity
>> Checks    |               | |               |<=======================>|
>> | |               |                         |               | |
>> |             200 INVITE  |               | |
>> |<------------------------|               | |               |
>> |               | |               |    5245 SIP re-INVITE   |
>> | |               |------------------------>|               | |
>> |            200 reINVITE |               | |
>> |<------------------------|               | |               |
>> |               | |               |                         |
>> | |               |<===== MEDIA FLOWS =====>|               | |
>> |                         |               |
>>
>>
>> 3. Use accumulated candidate list
>>
>> As far as I understand the documents, the candidates are sent as soon as
>> they are discovered.  I think that it would be better to send an
>> accumulated list of candidates instead of the delta list of candidates.
>> The priority calculation and the elimination of redundant candidates do not
>> need to know the complete list of candidate to work, but sending the
>> accumulated list instead of a delta could permit in the future to remove
>> candidates, if we find a need to do so.  This also removed the need for
>> sdpfrag.
>>
>> But the most important reason is for the next step.
>>
>>
>> 4. Replace end-of-candidates attribute by precandidate attributes
>>
>> There is currently an end-of-candidates attribute that is sent to signal
>> the end of the candidate gathering phase.  I think it is better to do it
>> the opposite way, i.e. to send candidates as they are discovered under a
>> different attribute name, and then to send all the candidates only when the
>> gathering phase is done.  Here's the partial SDPs exchanged in the call
>> flow in 2) but skipping one update (examples are from RFC 5245):
>>
>> (1) Alice sends all the candidates after the end of the gathering phase 
>> (half-trickle).  She also signals that she supports trickle.
>>
>> a=ice-options:trickle a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ
>> host
>>
>> (2) Bob knows that Alice supports half trickle, so he sends only the host 
>> candidates, which is all he has so far, but using the attribute
>> precandidate instead of candidate.  He sends them in a reliable 183:
>>
>> a=ice-options:trickle a=precandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ
>> host a=precandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host
>>
>> If Bob supported ICE but not trickle, he would have answered with its
>> complete list of candidates.
>>
>> (3) Bob discovers some candidates, but there is more to come, so it sends
>> a accumulated list of precandidates:
>>
>> a=ice-options:trickle a=precandidate:1 1 UDP 2130706431 10.0.1.1 8998 typ
>> host a=precandidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
>> 10.0.1.1 rport 8998 a=precandidate:1 1 UDP 2130706431 10.0.1.2 8998 typ
>> host
>>
>> (4)  Alice responds with the same SDP than in (1)
>>
>> (5) Bob receives the last batch of candidates, so now it sends an SDP 
>> containing the all the candidates, as if it did not understand trickle.:
>>
>> a=ice-options:trickle a=candidate:1 1 UDP 2130706431 10.0.1.1 8998 typ
>> host a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
>> 10.0.1.1 rport 8998 a=candidate:1 1 UDP 2130706431 10.0.1.2 8998 typ host
>>
>> (6) Alice sends back the same SDP.  Because Bob use candidate attributes 
>> instead of precandidate, she knows that she has all the candidates, as if 
>> end-of-candidates was received.
>>
>>>> _______________________________________________ mmusic mailing list 
>>>> [e-mail] https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>
>>
>> _______________________________________________ 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)
> 
> iQIcBAEBCAAGBQJRXa5lAAoJECnERZXWan7E710QAN3hWWnsPCQw8iCFPHl6HxZ+
> Q48BfHNKKzHe3n0ApJxeRTm8w2M11nj4J6vC1OdAHpWDEElzeLJjMGExdnLBwxOy
> wHS3jDGgKA9DVw2kBox7IIHMpbOoW2UwCx0lwM3YkwL8q4xrb4F3FmTHA5gAGgks
> P/mXJdRR8DCP1oiWYQELb+QmnuvFgBYbcGBUBy8P+XfL7f04IPTe8Cre6DaXqmVP
> CfAToyeiQKo/WTa5rk7sKr2veqsSPmQ5ZnyyHxMy+K42mrC2CD43bNR+HjfvUa24
> pzZWxGQdNHZymccs0IP/TdP0N2oA4fv+TEVPsGLjHyUdTuObP7PunZvCDWFxls+S
> 3OOnTBILlor1BCUR50LtWPeqhjylFywQLTDHVdiz62b9URdfeQPT8ANJSVsplCpf
> //ep2AbRZEbdRtbfUjpSBs5uTX2N7SjJ50PRX0tqDlZ6E33GVFjjh9R/PHFLUrlV
> BQxN3vuEnXZJzas3j747eaEqDBENYF4RfDjJf237VQ4lFBTQHkkkHA5h5wr+Fl9N
> JKMNyrlTctvEOfJ9A11SCfikySjUuE+ZxMz6Z58teQqqatGWwJpMOlfZdDDHMAUA
> YC0PB2dPT6XbsRs9mhkqovMpzLoL9mlVz7LbKI+8Y9mIfVHNquerJR6x7D5JGGBA
> gmxM38lPaf5NLOzqEeAv
> =I//c
> -----END PGP SIGNATURE-----
> 

-- 
https://jitsi.org