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

[Paul Kyzivat <[e-mail]>]

I just replied to a later message before dealing with this one. :-(

Using UPDATE (in normal sip o/a discipline) means that the hard learned 
knowledge of how to make o/a work in complex cases can be reused.

Conversely, adding INFO as a way to extend the existing O/A mechanism 
with some additional variations is likely to introduce great additional 
complexity.

	Thanks,
	Paul

On 4/2/13 11:45 PM, 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
>
> In section 6 of trickle-ice-sip, the Answer is carried by a 180 response,
> which can be lost before the INFO request is received.  The 180 will probably
> be resent later, but that still does not look right to send new candidates
> without be sure that the first batch of candidates have been received.  PRACK
> seems the right solution to this issue.  Also 183 seems a better fit than 180,
> at least until all the candidates are sent, but that's not really important.
> That gives us this call flow:
>
>
>       STUN/Turn                                                STUN/TURN
>         Servers          Alice                      Bob          Servers
>            |               |                         |               |
>            |<--------------|                         |               |
>            |   Candidate   |                         |               |
>            |   Discovery   |                         |               |
>            |-------------->|     INVITE (Offer)      |               |
>            |               |------------------------>|               |
>            |               |      183 (Answer)       |-------------->|
>            |               |<------------------------|               |
>            |               | PRACK                   |               |
>            |               |------------------------>|               |
>            |               |               200 PRACK |               |
>            |               |<------------------------|               |
>            |               |                         |               |
>            |               |  INFO (more candidates) |   Candidate   |
>            |               |<------------------------|               |
>            |               |  Connectivity Checks    |               |
>            |               |<=======================>|   Discovery   |
>            |               | INFO (more candidates)  |<--------------|
>            |               |<------------------------|               |
>            |               |                     180 |               |
>            |               |<------------------------|               |
>            |               |  Connectivity Checks    |               |
>            |               |<=======================>|               |
>            |               |                         |               |
>            |               |          200 OK         |               |
>            |               |<------------------------|               |
>            |               |                         |               |
>            |               |    5245 SIP re-INVITE   |               |
>            |               |------------------------>|               |
>            |               |          200 OK         |               |
>            |               |<------------------------|               |
>            |               |                         |               |
>            |               |                         |               |
>            |               |<===== MEDIA FLOWS =====>|               |
>            |               |                         |               |
>
>
> 2. Use UPDATE instead of INFO
>
> UPDATE works as well as INFO, and is more SIPish.
>
> 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
>