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

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:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> 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.

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.
>>
>> - --
>> 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)
>>
>> iQIcBAEBCAAGBQJRWvz6AAoJECnERZXWan7Ez6YQAIP3FzJHMD+X135/jr2ZpUYO
>> J3Ogf/JfoOC8Wwwe+btmWG3KuLMnaqzmQnmJNpdypyaEQN6ExK+giMZ136D/R8JH
>> MVwdL5T+NMRZSLfJwgkDK+gnZgJx8aKfIycB3RRQWgY1tXNuQhPyZsE20V5k2Rli
>> 6vz6sJ9eN4p4e7WhKRSuc9+IhLYAkAmPTRd6JVhF6aHGED8PMNI/AYNo+SJuwaJh
>> uDXoUPuox1W/zN9DocsTdeNo3rK0gLT59WHHmHEcMpyyjsjjcUm0RYHt0NIhaQ+0
>> snpKFx5akZWUMN8R+IqmXnMVIYlXxVkHxLJFbAYLRYOUFGDJJp22p13i14WvSF4r
>> mM7mVDuWIBd9DBIB6UH4PGKcU9gPhXif+37S2gB5LNofVgOBvvt4jcHPMxgII8Wm
>> eybWcfc1YseKhqsJq4DqJ0cc3vnxfyL0rfb22uB/E82cErLz6fyxjKJhGhuqyyKR
>> FAWXXjxKMfQOsThMlobvDjMR2oTyjz8IZc65MdOU+bQHy2SSPVxQjX6xMVSVR4yr
>> Z66GZsJkdg5mw0h6scS+T4dbF+/4a6tUG/0hCTvhaI3vyULmBf/YLg5VdodP1HzJ
>> GUIDFEzR9whKt0+nkwAumLPpHmTbIF7VuWg/YZmbq5tqY2n4gpuUDfCk7pusuBRb
>> yk3C5OOf2RWXhf6ekDuf
>> =jzXd
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>