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

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Inline.

On 04/03/2013 06:01 AM, Stach, Thomas wrote:
> Some thoughts inline
> 
> Marc Petit-Huguenin wrote: 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.

Right, but PRACK is mandatory anyway for UPDATE, so using accumulated
candidates seems a good idea when using INFO, so there is no need to PRACK the
18x.

Considering this now, INFO may have a slight advantage over UPDATE.

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

Yes.

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

I must say that I do not have a strong argument in favor of this.  It seems
easier from a developer point of view: candidate attributes are implemented
identically with or without trickle, precandidate attributes are only
implemented with trickle.  Also when looking at an SDP, you see immediately
what is what, i.e. with the existing proposal all SDP looks the same, apart
for the end-of-candidates thing.  But as I said, not a strong argument.

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

iQIcBAEBCAAGBQJRXEtMAAoJECnERZXWan7EYQcQAJ+bGQadrLnMpRQ3/p47/o5j
oxkgH/HYzGYT4I8IcPudQfTdP/vQnBlrGA8fiSA9KAI/N5mtwjURsRWYnxbmPq4o
oaBq1xyKW+ALlUgVaylKGldeTguee2pm05VYUnL01cjb/O5cOm9oarETRbpgks72
fT0oS9hIiryBP/NoUcLNZ5QZnvv05huDjTmJw0FiIZFWAmKg9TED8K7bb6dgxs3D
PRpg9Cbhe75LrdUCldbxhTTl5Wpm+XnfgZDAl1CAtBnW/xBlOj+qOZ7Kr0UHc1gv
vrB3fLHxkTNXi7yfWwtQCDhl/EddRs5zhFac5J61wmQ7EITG5HJ6+eDR9eLRRBIl
IHumyztefDvKyQn2KVapNdGV8xCkID1DMsYqtvDjXvbiTmLb0rmi30LzQtqd9v7m
kJ8nyAkmT5hnoRmJwlR4KVXtKCAjQ4QPNVq15OBY65gnK/1nj3BZDu4so7wTBygv
Aev3GWV+53rJV0qFqPVfvZ60oWah5tcnrCp+rSz3iBxzvfV9wMz4jeskimGpctPf
bUxl+GqgHRYZAC4Mz/4xCz4mv9RtmeW05s50y/kUKSr7dd2VwEq/XBq6PCXI108w
bJUjBTqu0C0nulJaPgHScyoPlM6T83/YIp6EOPqsWgJAEj1vo+T55ihVnBZcMne6
SlUrT/Wsep9Xu2hnmFdK
=lrh6
-----END PGP SIGNATURE-----