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

[Emil Ivov <[e-mail]>]

Hey Paul,

On 04.04.13, 15:50, Paul Kyzivat wrote:
>>> 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 ;)
> 
> Do you mean more implementations of *trickle ICE* using INFO than 
> UPDATE? Or do you mean that in general there are more implementations of 
> SIP supporting and using INFO than supporting and using UPDATE?
> 
> I don't have real data, but I have the impression that for a long time 
> most sip implementations have supported UPDATE.

That was mostly a joke about which of the two feels more "SIPish". I was
referring to non-standard use of SIP INFO for things such as DTMF and
how there's probably more implementations supporting that, than
implementations that do UPDATE.

>> 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.
> 
> ISTM that there is likely to be a lot of sip-sip use, perhaps more than 
> any other kind, perhaps not. 

Well I don't know about this. I know of very few SIP deployments that
even use ICE, let alone trickle ICE. As noted, the mechanism has existed
forever and has not been considered for SIP. ISTM that the only reason
we are even considering it now is because trickle is needed by RTCWEB
and because we didn't want to standardize trickle in general without
making sure we have a way to also make it work with SIP.

> If so, that would argue for something that 
> most naturally integrates into existing sip signaling.

I have nothing against natural integration as long as it doesn't just
mean "doing things the natural level of complexity that we are used to
getting with SIP, SDP and O/A". I'd like to point out no issues have
been raised for the INFO approach. The UPDATE proposal is just an
alternative way of doing the same thing, not a solution to a problem we
are having.

>> 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:
> 
> Of course it has something to do with O/A. 

I insist that it doesn't. It has exactly the same relationship to O/A as
peer-reflexive candidate discovery: it happens elsewhere and
intermediaries are notified about it post factum.

> ICE is also exchanged in O/A. 
> And the candidates you need to exchange are coupled to what was 
> exchanged in O/A.

Yes of course, but that's not the point I am making. The O/A exchanged
helped create agents and set their state. Now they have a life of their
own: they do checks by themselves, they discover peer-reflexive
candidates by themselves, and with trickle they can also discover other
kinds of candidates.

> Suppose you do one O/A exchange including ICE candidates, and then one 
> or both sides starts to trickle candidates with INFO. Then one side 
> sends a new offer, that changes the m-lines in some way. Presumably it 
> will also contain some ICE candidates. And then the other side sends 
> another trickle ICE INFO. How do all of these things relate? Is this 
> even legal?

It sounds to me like this would simply be an ICE restart and that the
second ICE INFO shouldn't happen (unless it is the result of a race
condition but that can easily be detected and ignored).

> Certainly you can set down a set of protocol rules so that it becomes 
> well defined. But you are going to need to take the SIP O/A rules into 
> account while doing that.

Sure. I don't think we really need a set of new rules though.

>> 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).
> 
> You assume that a subsequent offer is used *only* to update trickle ICE. 

Not at all. What I am saying is that doing trickle with O/A  would give
you a ton of new offers and answers and handling those would be very
problematic.

> There are other reasons for a new offer.

Of course, and when they are needed, those could just be ICE restarts.

> Or are you assuming some constraints such as that first you do an O/A, 
> and then agree not to do another one until all trickling for the first 
> one has been completed?

No, this is not what I was assuming.

>> 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.
> 
> That doesn't work so well for those intermediaries that gate media, and 
> so won't let anything through (including ICE) until they have seen the 
> address in signaling and opened the gate for it.

There are a few cases here:

1. Intermediaries that gate media unconditionally would just put
themselves in the c= line which would cause an ICE mismatch and that
will be the end of it (with or without trickle).

2. Intermediaries that try to be intelligent and work with ICE, by
adding relayed candidates or anything like this can be in one of the two
following cases:
a) they don't support trickle, in which case they should remove the
a=ice-options:trickle token and cause a fallback to vanilla ICE.
b) they know about trickle in which case they would look into INFO
messages.

I agree the above may need more discussion, but I simply don't think
that doing consecutive O/As with UPDATEs would just work out of the box
for any of the problematic situations.

>> 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/>).
> 
> It is called idempotence.
> 
> This presumes that you implement this by first finding the difference 
> and then applying it to your current state, rather than just setting out 
> to apply the entire new specification to your current state.

Yup sure. The problem is that it exposes you to a number of situations
that you probably wouldn't need to handle otherwise (not idempotence
itself, but doing the diffing in O/A in general and trickle ICE in
particular). For example, when implementing this I'd have to make sure I
am prepared to take a candidate update offer that also places streams on
hold, changes codec sets (which would also mean that I'd have to
recalculate pacing timers for checks that are already in progress), adds
new streams, disables existing ones, etc., etc. All this while my checks
are already in progress.

Yet, I would need to worry about none of these if I simply take trickle
ICE for what it is: agent-to-agent communication that has no impact on
the state of O/A.

> There are pros/cons to both ways, and its not surprising that people are 
> most comfortable with the one most familiar to them.
> 
>> 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?
> 
> So what do you propose to happen if it *does* prove necessary to do a 
> new O/A after trickling has begun? 

An ICE restart.

> Are you going to put the all the 
> trickled candidates into the offer?

This is an implementation choice. If the agent is capable of reusing
already obtained candidates, then they could certainly include them in
the new offer and speed up the process.

> If not, are you going to require 
> that the candidates be identical to what was in the prior offer?

No, certainly not.

Does this make sense?

Cheers,
Emil

> 
> ISTM you must confront this in any case.
> 
> 	Thanks,
> 	Paul
> 
>> 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
>>>
>>
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 
https://jitsi.org