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

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 02 Apr 2013 08:45:02 -0700

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: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 3 Apr 2013 13:01:31 +0000

Some thoughts inline

Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> 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.

>      STUN/Turn
> STUN/TURN
>      STUN/Turn
> STUN/TURN
> 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
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.

> 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
> (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
> -----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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 03 Apr 2013 08:31:27 -0700

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:
> 
> 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 
>> 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 =====>|               | |
> |                         |               |
> 
> 
> 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 =====>|               | |
> |                         |               |
> 
> 
> 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.

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Apr 2013 01:12:50 +0800

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

I'm having difficulty making any sense of the above.

Are you trying to say that you can't use UPDATE for an offer in an early 
dialog without first using completing an earlier o/a with PRACK?

And then, the advantage of using INFO over UPDATE is because it can go 
sooner?

Yes, I guess it might be able to go sooner. But I think you must 
carefully consider the interaction of the trickled O/A revisions (or 
whatever you call them) with the entire O/A state machine. Specifically, 
please look at RFC 6337, and ensure that what is being proposed is well 
defined in all the cases described there.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Apr 2013 01:21:53 +0800

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 03 Apr 2013 11:12:27 -0700

On 04/03/2013 10:12 AM, Paul Kyzivat wrote:
>> candidates seems a good idea when using INFO, so there is no need to
>> PRACK the 18x.
>> 
> Yes, I guess it might be able to go sooner. But I think you must carefully 
> consider the interaction of the trickled O/A revisions (or whatever you
> call them) with the entire O/A state machine. Specifically, please look at
> RFC 6337, and ensure that what is being proposed is well defined in all the
> cases described there.
> 

I completely agree with you, we should try first to see if trickle fits in O/A
before defining extensions like INFO - that was the sense of my original email.

- -- 
Marc Petit-Huguenin

---

From: Emil Ivov <[email-masked]>
Date: Thu, 04 Apr 2013 01:02:10 +0200

Hey Marc and thanks for your comments!

Replies inline.

> 1. The 180 needs to be reliable

Agreed. We'll make the change in the next revision.

> 2. Use UPDATE instead of INFO

Why?

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

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.

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:

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

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.

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/>). 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?

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

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Apr 2013 21:50:52 +0800

Emil,

I appreciate some of what you say.
But I also think you sweep some things under the rug.
See inline.

> some use of INFO than supporting UPDATE so I am not sure I agree with

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.

> possible the way that trickle ICE has been implemented with these other

ISTM that there is likely to be a lot of sip-sip use, perhaps more than 
any other kind, perhaps not. If so, that would argue for something that 
most naturally integrates into existing sip signaling.

> that would really require use of offer/answer. There are however many

Of course it has something to do with O/A. ICE is also exchanged in O/A. 
And the candidates you need to exchange are coupled to what was 
exchanged in O/A.

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?

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.

> for some checks to complete).

You assume that a subsequent offer is used *only* to update trickle ICE. 
There are other reasons for a new offer.

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?

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

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

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

So what do you propose to happen if it *does* prove necessary to do a 
new O/A after trickling has begun? Are you going to put the all the 
trickled candidates into the offer? If not, are you going to require 
that the candidates be identical to what was in the prior offer?

ISTM you must confront this in any case.

	Thanks,
	Paul

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 04 Apr 2013 09:46:40 -0700

I agree with everything Paul said, but I just would like to add one point below.

On 04/04/2013 06:50 AM, Paul Kyzivat wrote:
> Emil,
> 
> I appreciate some of what you say. But I also think you sweep some things
> under the rug. See inline.
> 
> I read draft-ivov-dispatch-trickle-ice-sip and
>> 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?
> 
>>> 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.

It is not the trickle mechanism that my original email tried to fix, but the
mapping between this mechanism and SIP which, as you said yourself, is new so
there is nothing to preserve here.

>>> 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:
> 
>> And the candidates you need to exchange are coupled to what was exchanged
>> in O/A.
> 
>> 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?
> 
>>> 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).
> 
>>> 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.
> 
>>> difference is an added a=sendonly attribute ... how did this ever
>>> happen (in comparison XMPP only sends <hold/>).
> 
>> 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.
> 
>>> 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? Are you going to put the all the trickled
>> candidates into the offer? If not, are you going to require that the
>> candidates be identical to what was in the prior offer?
> 
>> 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)       |               |
> Discovery   | |               |  Connectivity Checks    |               | |
> |<=======================>|               | (5)       |               |
> UPDATE (last cands) |<--------------| |
> 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):
> 
> a=ice-options:trickle a=candidate:1 1 UDP 2130706431 192.0.2.1 3478 typ
> 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
> 
> 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
> 
>>> _______________________________________________ mmusic mailing list 
>>> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>>> 
>> 
> 
> _______________________________________________ mmusic mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
> 

- -- 
Marc Petit-Huguenin

---

From: Emil Ivov <[email-masked]>
Date: Thu, 04 Apr 2013 20:02:21 +0200

Hey Paul,

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

> 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 

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.

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

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.

> another trickle ICE INFO. How do all of these things relate? Is this 

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

> account while doing that.

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

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

> and then agree not to do another one until all trickling for the first 

No, this is not what I was assuming.

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

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

> 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 

No, certainly not.

Does this make sense?

Cheers,
Emil

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Thu, 04 Apr 2013 20:05:18 +0200

Hey Marc,

> there is nothing to preserve here.

I get this. My point was that it would make sense to have it
interoperate easily. Specifically, if I am translating WebRTC into SIP,
I would just be getting individual a=candidate lines from WebRTC. It
would be nice if I could just paste that candidate in a SIP message and
send it through. It would be not so nice if I have to keep a state in
the gateway so that I can regenerate the entire candidate list every
time this happens.

Emil

> iQIcBAEBCAAGBQJRXa5lAAoJECnERZXWan7E710QAN3hWWnsPCQw8iCFPHl6HxZ+
> Q48BfHNKKzHe3n0ApJxeRTm8w2M11nj4J6vC1OdAHpWDEElzeLJjMGExdnLBwxOy
> wHS3jDGgKA9DVw2kBox7IIHMpbOoW2UwCx0lwM3YkwL8q4xrb4F3FmTHA5gAGgks
> P/mXJdRR8DCP1oiWYQELb+QmnuvFgBYbcGBUBy8P+XfL7f04IPTe8Cre6DaXqmVP
> CfAToyeiQKo/WTa5rk7sKr2veqsSPmQ5ZnyyHxMy+K42mrC2CD43bNR+HjfvUa24
> pzZWxGQdNHZymccs0IP/TdP0N2oA4fv+TEVPsGLjHyUdTuObP7PunZvCDWFxls+S
> 3OOnTBILlor1BCUR50LtWPeqhjylFywQLTDHVdiz62b9URdfeQPT8ANJSVsplCpf
> //ep2AbRZEbdRtbfUjpSBs5uTX2N7SjJ50PRX0tqDlZ6E33GVFjjh9R/PHFLUrlV
> BQxN3vuEnXZJzas3j747eaEqDBENYF4RfDjJf237VQ4lFBTQHkkkHA5h5wr+Fl9N
> JKMNyrlTctvEOfJ9A11SCfikySjUuE+ZxMz6Z58teQqqatGWwJpMOlfZdDDHMAUA
> YC0PB2dPT6XbsRs9mhkqovMpzLoL9mlVz7LbKI+8Y9mIfVHNquerJR6x7D5JGGBA
> gmxM38lPaf5NLOzqEeAv
> =I//c

-- 
https://jitsi.org

---

From: Alan Johnston <[email-masked]>
Date: Thu, 4 Apr 2013 14:07:50 -0500

I admit that my first thought was that UPDATE was more appropriate than INFO. 

But the more I think about it, trickling in new candidates is not necessarily a part of O/A, rather it can be thought of as communication between two ICE Agents. For tunneling another protocol using SIP as transport, INFO is the right choice. 

Not every ICE candidate is signaled in SDP - Peer Reflexive Candidates, for example. 

And remember ICE has a second O/A exchange that brings the SDP into line with the chosen candidate pair.

- Alan -

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 04 Apr 2013 17:18:48 -0700

On 04/04/2013 12:07 PM, Alan Johnston wrote:
> But the more I think about it, trickling in new candidates is not
> necessarily a part of O/A, rather it can be thought of as communication
> between two ICE Agents. For tunneling another protocol using SIP as
> transport, INFO is the right choice.
> 

True.  But so why not push the idea further, and use an in-band mechanism to
send the newly discovered candidates?  E.g. the Offerer still sends the full
list of candidates but the Answered uses the same path than a successful
connectivity check to send its candidates as it discovers them, using a new
STUN transaction.  The Offerer will add the candidates received in this new
transactions more or less in the same way Peer Reflexive Candidates are added,
and start connectivity checks in the other direction. The answered will send
its answer only when it has collected all the candidates on its side, making
it identical to non-trickle ICE.

Obviously there is lot of details missing here, but that solution does not
require UPDATE or INFO, or a=ice-options:trickle.  It's probably not
compatible with non-SIP trickle implementations, but perhaps a gateway can
convert candidates in the signaling path to and from candidates in the media path.

- -- 
Marc Petit-Huguenin

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 5 Apr 2013 10:04:09 +0000

inline

Emil Ivov wrote:
>> 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: 
>> 
The answer with any initial candidates needs to be in a 183 not a 180.
In addition, I don't think that the 183 needs to be reliable.
This was not necessary for RFC5245 and could also be avoided for trickle ICE, since the
INFO with the new candidates is already reliably sent. 
If the INFO contains always the complete list of candidates (instead of just a delta), the ICE agents will 
eventually have all candidates even if the 183 with the initial candidates got lost with the initial candidates.
As an optimisation if you don't want to always send the complete list, 
you could just include it in the first INFO and use deltas afterwards.

Regards
Thomas

---

From: Emil Ivov <[email-masked]>
Date: Fri, 05 Apr 2013 20:51:16 +0200

Hey Thomas,

> The answer with any initial candidates needs to be in a 183 not a 180.

Well 5245 actually talks about 18x but I agree that using 183 rather
than 180 would help manage post pick-up latency better.

> INFO with the new candidates is already reliably sent.

Well, it's not only about the candidates (the 183 could actually contain
none of those). However, we'd also need to make sure that things like
the ufrag and password are also received.

> you could just include it in the first INFO and use deltas afterwards.

I like this suggestion and I agree we could add something along those
lines in case PRACK is not user or supported.

Thanks for the tip!
Emil

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 06 Apr 2013 03:10:34 +0800

Note that until at least one provisional response makes it back to the 
UAC it won't be possible for the UAC to send INFOs. (It can't do so 
until there is an early dialog.)

So its possible that if you only send unreliable provisionals then the 
trickling from UAC to UAS may not be happen until the call is established.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 Apr 2013 15:27:05 -0700

On 4 April 2013 17:18, Marc Petit-Huguenin <[email-masked]> wrote:
> send the newly discovered candidates?

That only works if you find a workable path using un-trickled
candidates.  That seems unlikely, except in the half-trickle case.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 05 Apr 2013 16:26:40 -0700

On 04/05/2013 03:27 PM, Martin Thomson wrote:
>> True.  But so why not push the idea further, and use an in-band mechanism
>> to send the newly discovered candidates?
> 
> That only works if you find a workable path using un-trickled candidates.
> That seems unlikely, except in the half-trickle case.
> 

Yes, this is why I said that the Offerer sends the full
list of candidates.  But if the Offerer already knows that the Answerer
supports this way of doing trickle, it just has to send one relayed candidate
in the Offer (can even be the one in the m= line and do not send any
a=candidates lines).  Let's call this 3/4 trickle :-)

- -- 
Marc Petit-Huguenin

---

From: Emil Ivov <[email-masked]>
Date: Sat, 06 Apr 2013 08:02:31 +0200

> trickling from UAC to UAS may not be happen until the call is established.

Great point! So it seems like we are back to mandating PRACK.

What would be the issue with this anyway?

Emil

-- 
https://jitsi.org

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 8 Apr 2013 12:15:14 +0000

I agree, that Paul has a good point.
However, I still do not see a requirement for PRACK. 
I would still like to avoid it due to the big debate during development of ICE that occurred back in IETF64. 

Once the UAS has sent the 183 there is an early dialog. 
Of course the 183 can be lost, such that UAS and UAC are out of sync with respect to the dialog state.

Now, RFC5245 specifies (in case PRACK is not used) that the provisional response is retransmitted 
with the exponential backoff timers. I want to keep this behaviour also for trickle ICE because now 
the UAC will eventually receive one of the retransmissions and could also send trickled candidates.

Interesting is of course what happens with the INFO if the UAC has not yet received a provisional response.
I would expect receipt of a 481 response to the INFO request since the UAC does not yet know about the dialog.
This 481 could trigger at the UAS the immediate retransmission of the provisional response 
in order to establish the early dialog. Then, the INFO could also be retransmitted. 

Regards
Thomas

Emil Ivov wrote:
>> Note that until at least one provisional response makes it back to
>> the UAC it won't be possible for the UAC to send INFOs. (It can't do
>> so until there is an early dialog.)
>> 
>> So its possible that if you only send unreliable provisionals then
>> the trickling from UAC to UAS may not be happen until the call is
>> established. 
> 
>>> Well, it's not only about the candidates (the 183 could actually
>>> contain none of those). However, we'd also need to make sure that
>>> things like the ufrag and password are also received.
>>> 
>>>> If the INFO contains always the complete list of
> candidates (instead of just a delta), the ICE agents will
>>>> eventually have all candidates even if the 183 with the
> initial candidates got lost with the initial candidates.
>>>> As an optimisation if you don't want to always send the complete
>>>> list, you could just include it in the first INFO and use deltas
>>>> afterwards. 
>>> 
>>> I like this suggestion and I agree we could add something along
>>> those lines in case PRACK is not user or supported.
>>> 
>>> Thanks for the tip!
>>> Emil
>>>> 
>>>> 
>>>> Regards
>>>> Thomas
>>>> 
>>> 
>>

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 8 Apr 2013 12:15:16 +0000

Emil,

inline

> the ufrag and password are also received.

Of course you are right.
However, since the INFO can carry arbitrary SDP fragments, you can also include ufrag and password 
and any of the other ICE attributes.
Regards
Thomas

> 
>> If the INFO contains always the complete list of candidates
> (instead of just a delta), the ICE agents will

---

From: Emil Ivov <[email-masked]>
Date: Tue, 09 Apr 2013 00:04:07 +0200

Hey Thomas,

> I would still like to avoid it due to the big debate during development of ICE that occurred back in IETF64. 

For those of us who weren't around back then, it would help if you could
remind exactly what the reasons were. This way we can decide if they
also apply to the trickle ICE case.

> the UAC will eventually receive one of the retransmissions and could also send trickled candidates.

Not necessarily. The UAC may be performing half trickle in which case it
won't be sending anything else.

> in order to establish the early dialog. Then, the INFO could also be retransmitted.

This could indeed work and it could potentially help gain almost up to
an RTT. Anyone has a problem with it?

> and any of the other ICE attributes.

I didn't mean to imply you couldn't, however Paul's comment, discussed
above, killed this approach anyway.

Cheers,
Emil

-- 
https://jitsi.org

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 8 Apr 2013 19:21:46 -0400 (EDT)

> From: Alan Johnston <[email-masked]>
> 
> necessarily a part of O/A, rather it can be thought of as
> communication between two ICE Agents. For tunneling another protocol
> using SIP as transport, INFO is the right choice. 

Ah, yes, I now agree with that -- the trickle-ICE updates are "back
channel" amendments to the original offer/answer transfer, not
additional offer/answer transactions.

Within generic trickle ICE, there is the possibility that additional
candidates are provided "incrementally", that is, each protocol
message includes only the new candidates (and end-of-candidate
indications).  There is also the possibility that additional
candidates are provided "cumulatively", that is, each protocol message
includes all of the previously provided candidates.

We could specify that trickle ICE uses one method or the other, but I
think that we should consider these to be logically equivalent at the
level of generic trickle ICE, and allow the choice between methods to
be done by the usage.  The reason for this is that the decision of
method seems to be heavily dependent on the specifics of the usage.
(Allowing each usage to make its own choice requires that we not allow
cumulative updates to withdraw candidates previously offered, as that
functionality cannot be provided with incremental updates.)

For instance, if updates are carried by an ordered, reliable channel
like TCP, then there is no benefit in sending updates cumulatively.
Similarly if the SIP usage sends updates in UPDATE requests, because
the UAC must serialize UPDATE requests.  But if we carry updates in
INFO messages, and we wish to not require the UAC to serialize them,
then cumulative updates are desirable, as out-of-order receipt of INFO
messages can cause an earlier-sent INFO to be permanently blocked by a
later-sent INFO which reaches the UAS first.

This leads to the point that INFO is preferable to UPDATE because the
UAC does not have to serialize INFOs, which reduces blocking.  (As
Paul notes, we've done a lot of work to define how to properly handle
complex cases involving UPDATE, but that work is needed because
UPDATEs have to be serialized with respect to each other, and with
certain other requests.)

This leads to a broader issue:  Generic trickle ICE needs to define
its expectations regarding reliability, correlation, and sequencing of
updates.  If both generic ICE and its usages were defined in one I-D,
these issues would just be design considerations, but since the
generic specification and the usage specification are separate, these
issues are requirements defined in the generic ICE document and each
usage document has to show how it satisfies the requirements.  That's
hard to do if the requirements aren't explicitly stated.

In particular, if cumulative updating is used, and candidates are
allowed to be withdrawn, the receiver cannot determine wihch of two
updates is "newer" by inspection, updates need to be sequenced by the
transport mechanism.  If incremental updating is used, sequencing is
not relevant.  Similarly, if candidates cannot be withdrawn, the newer
of two cumulative updates has the larger candidate list.

Also, the updates need to be correlated with the "ICE negotiation
context", so if there is an ICE restart, any delayed updates for a
previous context that arrive can be recognized as such and ignored.

For the SIP usage, a considerable amount of sequencing and correlation
is provided by the CSeq values:  A trickle ICE update INFO must have a
CSeq higher than the message containing the offer/answer that started
the corresponding ICE context, and will have a CSeq lower than the
offer/answer that starts the next ICE context.  Similarly, CSeq
sequences INFOs.

Other usages may need other mechanisms to provide this information.

One matter that I haven't seen discussed is how trickle ICE ensures
that both UAs always test the same candidate pair at the same time.
Even if we assume that the transport of updates is quick and reliable,
slight differences in timing at the two UAs could cause them to choose
(at some moment) different pairs to test.  Since vanilla ICE seems to
have been constructed to prevent this, this seems to me that it might
be a problem and must be investigated and documented.

Dale

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 9 Apr 2013 10:15:48 +0000

Emil,

inline

> -----Ursprüngliche Nachricht-----
> Von: Emil Ivov [mailto:[email-masked]] 
> Gesendet: Dienstag, 09. April 2013 00:04
> An: Stach, Thomas
> Cc: Paul Kyzivat; [email-masked]
> Betreff: Re: AW: [MMUSIC] 
> draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-
> ice - PRACK not mandatory
> 
> Hey Thomas,
> 
> > I would still like to avoid it due to the big debate during 
> development of ICE that occurred back in IETF64. 
> 

The main arguments were complexity and lack of implementation. 

Excerpt from the MMUSIC minutes at http://www.ietf.org/proceedings/64/

   The -06 version of ICE solves the race condition noted during the 62nd
   IETF meeting using a mechanism based on PRACK and UPDATE.  There was a
   heated discussion of this mechanism, with many people complaining that
   PRACK and UPDATE are complex and difficult to implement, and requesting
   an alternative ICE formulation which doesn't require them. Others noted
   that this mechanism was discussed in a previous working group session,
   and suggested that the complexity argument was overblown. There was no
   resolution to this discussion in the meeting, and after a review of the
   issues, an ad-hoc meeting was scheduled to discuss the issues in detail
   later in the week (notes from the side meeting were sent to the mailing
   list on 14th November 2005).
Which is here --> http://www.ietf.org/mail-archive/web/mmusic/current/msg03829.html

More on "The Problem with PRACK" is here and the following thread.
http://www.ietf.org/mail-archive/web/sip/current/msg13221.html

Regards Thomas
> > Of course the 183 can be lost, such that UAS and UAC are 
> out of sync with respect to the dialog state.
> > 
> > with the exponential backoff timers. I want to keep this 
> behaviour also for trickle ICE because now 
> > Interesting is of course what happens with the INFO if the 
> UAC has not yet received a provisional response.
> > I would expect receipt of a 481 response to the INFO 
> request since the UAC does not yet know about the dialog.
> > This 481 could trigger at the UAS the immediate 
> retransmission of the provisional response 
> >>>>> The answer with any initial candidates needs to be in a 
> 183 not a
> >>>>> 180. 
> >>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Apr 2013 21:28:50 +0800

> also apply to the trickle ICE case.

My argument was that without a reliable provisional the UAS can't be 
certain that the UAC has established an early dialog, and without that 
the UAC can't trickle using INFO.

Thinking further, *if* the UAS keeps retransmitting the unreliable 
provisional until it receives some ICE messages then things may work. 
But in the case of trickle ICE this might effectively mean that it must 
keep retransmitting until it receives an INFO with additional 
candidates, because none of the initial candidates may be usable.

	Thanks,
	Paul

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 9 Apr 2013 14:17:37 +0000

Dale,

this is an excellent analysis and I agree completely.

Regards
Thomas

---

From: "Stach, Thomas" <[email-masked]>
Date: Wed, 10 Apr 2013 07:18:45 +0000

inline

> Von: Paul Kyzivat [mailto:[email-masked]] 
> Gesendet: Dienstag, 09. April 2013 15:29
> An: Emil Ivov
> Cc: Stach, Thomas; [email-masked]
> >> I would still like to avoid it due to the big debate 
> during development of ICE that occurred back in IETF64.
> >
> candidates, 

... or if the UAS receives a 200 OK (instead of 481) for an INFO request. 
That would also indicate that the 18X was received and the early dialog was established.

Regards
Thomas

> because none of the initial candidates may be usable.
> 
> 	Thanks,
> 	Paul
> 
> >> Now, RFC5245 specifies (in case PRACK is not used) that 
> the provisional response is retransmitted
> >>>>>> The answer with any initial candidates needs to be in 
> a 183 not a
> >>>>>> 180.
> >>>>>