[VOIPSEC] Interactive Connectivity Establishment (ICE)

[Dan Wing]

> Sorry for my not very clear sentence, I will try to explain 
> what I wanted to say. 
> 
> This is the call flow of  ICE-05:

Note the current specification is ice-06, but let's talk about
this flow.

>           Agent A          TURN,STUN Servers          Agent B
>              |(1) Gather Addresses |                     |
>              |-------------------->|                     |
>              |(2) Offer            |                     |
>              |------------------------------------------>|
>              |                     |(3) Gather Addresses |
>              |                     |<--------------------|
>              |(4) Answer           |                     |
>              |<------------------------------------------|
>              |(5) Media            |                     |
>              |<------------------------------------------|
>              |(6) Media            |                     |
>              |------------------------------------------>|
>              |(7) STUN Checks      |                     |
>              |<------------------------------------------|
>              |(8) STUN Checks      |                     |
>              |------------------------------------------>|
>              |(7) Offer            |                     |
>              |------------------------------------------>|
>              |(8) Answer           |                     |
>              |<------------------------------------------|
>              |(9) Media            |                     |
>              |<------------------------------------------|
>              |(10) Media           |                     |
>              |------------------------------------------>|
> 
> 
>                                  Figure 1
> 
> No problem for me about early media : a terminal can send 
> RTP/RTCP packets as soon as it knows where to send it.

Ok.

> The problem is call establishment. In the case of agent A can 
> receive media at the first try, if agent B doesn't validate 
> this try agent A receives media. A new SDP offer/answer is 
> done. The media channels are cut for agent A. Then new 
> channels are established right. So agent A will see its video 
> session broken for a short period (maybe just 1 sec). But for 
> video communications, it is not very clean to see that. 
>
> So yes, for me the problem comes from RE-INVITE because an 
> user doesn't expect cuts. I think RE-INVITE can be used to 
> forward a call for example. There is a reason why it is no 
> more in the call flow of ICE-06, isn't there ?

Several things need to occur for the problem you're describing
to exhibit itself.  And there is a mechanism defined to avoid
the problem if you find the problem exhibiting itself too often
for your liking.  The conditions that need to occur are:

1. The re-Invite can only causes a change in the path if there 
was more than one viable path between the two endpoints (that 
is, more than one a=candidate line was in the offer or in the 
answer, and more than one were routable), and;

2. Assuming you did have more than one candidate path, and 
assuming that more than one 'worked' (that is, a successful
ICE exchange occured), yes, you could have a more optimal
path selected, and;

3. Assuming that newly-selected path also has different delay 
characteristics than the original path, the receiver's jitter 
buffer will underrun or overrun.  

I believe it's that last case you are describing, but to get
to that point you need the other conditions to be true as 
well.

To avoid hitting problem #3, connectivity preconditions 
<http://www.ietf.org/internet-drafts/draft-ietf-mmusic-connectivity-precon-0
1.txt> 
can be used to ensure ICE connectivity prior to alerting the 
end users.

-d