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

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

I agree with everything Paul said, but I just would like to add one point below.

On 04/04/2013 06:50 AM, Paul Kyzivat wrote:
> Emil,
> 
> I appreciate some of what you say. But I also think you sweep some things
> under the rug. See inline.
> 
> On 4/4/13 7:02 AM, Emil Ivov wrote:
>> Hey Marc and thanks for your comments!
>> 
>> Replies inline.
>> 
>> On 02.04.13, 17:45, Marc Petit-Huguenin wrote:
> I read draft-ivov-dispatch-trickle-ice-sip and
> draft-ivov-mmusic-trickle-ice during the preparation of the rfc5245bis
> draft and I have some suggestions that I will be presenting step by step
> below:
> 
> 1. The 180 needs to be reliable
>>> 
>>> Agreed. We'll make the change in the next revision.
>>> 
> 2. Use UPDATE instead of INFO
>>> 
>>> Why?
>>> 
> UPDATE works as well as INFO, and is more SIPish.
>>> 
>>> Well, I'd argue that there are more implementations out there making 
>>> some use of INFO than supporting UPDATE so I am not sure I agree with 
>>> this statement ;)
> 
>> Do you mean more implementations of *trickle ICE* using INFO than UPDATE?
>> Or do you mean that in general there are more implementations of SIP
>> supporting and using INFO than supporting and using UPDATE?
> 
>> I don't have real data, but I have the impression that for a long time
>> most sip implementations have supported UPDATE.
> 
>>> Seriously now. There are several reasons we did not go for UPDATE:
>>> 
>>> 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.

> 
>> 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 
>>> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
>>> 
>> 
> 
> _______________________________________________ mmusic mailing list 
> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
> 

- -- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
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-----