[VOIPSEC] Interactive Connectivity Establishment (ICE)

[Olivier GRALL]

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:

          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.

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 ?

Regards,


	
Olivier GRALL
R&D Engineer 	*NeoTIP** S.A.*
4, rue Louis de Broglie
22300 Lannion
France
olivier.grall at neotip.com <mailto:olivier.grall at neotip.com> 	+33 (0)2 96 
48 66 94




Dan Wing a écrit :

>>Thanks a lot for this information. I think I saw this 
>>behaviour on ICE-05 at least on the first call flow. I had a 
>>quick look on the new version ICE-06, the call flow seems to 
>>be really better. A very bad thing was to send media packets 
>>before a new SDP negociation.
>>    
>>
>
>I don't understand your last sentence.  Are you saying it is undesirable to
>send early media, or are you saying ICE doesn't allow you to send early
>media, or are you saying it's undesirable to send a new offer (re-Invite in
>SIP)?
>
>  
>
>>This could involve in large 
>>cuts in the call establishment especially if there is video.
>>
>>New call flow:
>>
>>          Agent A          TURN,STUN Servers          Agent B
>>             |(1) Gather Addresses |                     |
>>             |-------------------->|                     |
>>             |(2) Offer            |                     |
>>             |------------------------------------------>|
>>             |                     |(3) Gather Addresses |
>>             |                     |<--------------------|
>>             |(4) Answer           |                     |
>>             |<------------------------------------------|
>>             |(5) STUN Check       |                     |
>>             |<------------------------------------------|
>>             |(6) STUN Check       |                     |
>>             |------------------------------------------>|
>>             |(7) Offer            |                     |
>>             |------------------------------------------>|
>>             |(8) Answer           |                     |
>>             |<------------------------------------------|
>>             |(9) Media            |                     |
>>             |<------------------------------------------|
>>             |(10) Media           |                     |
>>             |------------------------------------------>|
>>
>>
>>                                 Figure 1
>>
>>The call establishment may be long if it's not the first 
>>address which is good but the third one.  There are timeouts 
>>on STUN checks I think. 
>>    
>>
>
>If the answerer ("Agent B" in the above flow) wants to send media before the
>ICE state machine completes, it can send media.  Of course, if the ICE state
>machine hasn't completed the answerer might not pick a viable path to send
>media until the ICE state machine completes.  But if it selects any path
>that received a STUN Response (message 6 in the above flow), the answerer
>will at least know that path works, even if it might not happen to be the
>best path or the path that is selected in the re-Invite.
>
>...
>  
>
>>I'm sure that NAT problems will still be alive with IPv6 
>>because it permits masking of  network topology. It makes 
>>part of security requirements for a company.
>>    
>>
>
>draft-ietf-v6ops-nap-02.txt might be the ticket.
>
>-d
>
>  
>