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

["Stach, Thomas" <[e-mail]>]

Some thoughts inline

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.  
There was a large debate in back IETF 64 if ICE should require usage of PRACK.
The conclusion was to go without PRACK, but instead re-transmit the 183 with the answer until 
a STUN onnectivity check was received at the answerer (ice-06 --> ice-07)
Receipt of that connectivity check is the indicator that the the answer arrived at the offerer.
Of course with trickle-ICE things are different since you might not yet have the candidate that will finally work.
However, I think this issue can be resolved using your proposal from further down, i.e. always send the accumulated 
list of candidates instead of just deltas. Consequently, you always have the complete list of candidates even if 
the provisonal response got lost.

> Also 183 seems a 
> better fit than 180,
Yes, (vanilla)ICE specifies to alert the callee and sent the 180 only after connectivity checks were succesful. 
I don't think this should be changed.

> 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.  
I think this is a good idea due to the reasons above. 
It could make interworking easier for a GW to the SIP world with vanilla ICE devices.

> 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.
Why is this?
Do you propose that the UPDATE always includes the complete SDP offer/answer?
My assumption is that just the complete list of candidates is updated using 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.  
I don't see the benefit of using a different attribute name instead of the new end-of-candidates attribute.
I am not objecting, but could you explain the advantage?

> 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