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

[Emil Ivov <[e-mail]>]

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

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.

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:

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

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.

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

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: [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)
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 
https://jitsi.org