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

[Marc Petit-Huguenin <[e-mail]>]

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