RE: [Fwd: I-D ACTION:draft-jennings-midcom-stun-results-00.txt]

At 04:24 AM 2/18/2004, Yutaka Takeda wrote:
>> With ICE, a UAS will first check connectivity to UAC's STUN address.
>> The ICE draft suggests doing so on the initial application request
>> (SIP INVITE e.g.) to keep call set up time low. At this 
>> moment however, 
>> UAC's NAT is not primed yet and the STUN check reports no 
>> connectivity.
>
>My understanding is that the connectivity check is done at the same time
>at both ends. 

I am not sure ICE is now suggesting UAC's connectivity checks and I still see 
race conditions potential in the call flow. For example, UAS may get ICMP errors 
for the connectivity checks before UAC receives 183 and primes its NAT with its 
connectivity checks. 

-jiri

>The UAS (responder) may initiate the connectivity check
>first, the UAS will send 183 Session Progress with SDP (accept message)
>back to the UAC (initiator) without waiting for completion of the connectivity
>check. UAC will start the connectivity check immediately after it receives the
>accept message. Timeout duration of STUN transaction is 9.5 seconds
>which is long enought for UAS to initiate the connectivity check before UAS
>side connectivity check is complete.
>
>BTW, 9.5 seconds seems to me too long. I would like to know if there is
>a specific reason for that.
>
>Yutaka
>
>
>
>> -----Original Message-----
>> From: Jiri Kuthan [mailto:[email protected]]
>> Sent: Saturday, February 14, 2004 8:09 AM
>> To: Jonathan Rosenberg
>> Cc: Midcom
>> Subject: Re: [midcom] [Fwd: I-D 
>> ACTION:draft-jennings-midcom-stun-results-00.txt]
>> 
>> 
>> At 07:46 PM 2/13/2004, Jonathan Rosenberg wrote:
>> >I disgaree.
>> >
>> >Cullen's results show that we are seeing hybrid NATs whose 
>> type depends on whether the random port selected by the 
>> client is allocated already or not. In such a case, if the 
>> client picks an already-allocated port during the detection 
>> phase, it may detect the nat as symmetric, when it fact it 
>> might be port restricted in other cases.
>> >
>> >With ICE, if you happen to be unlucky during a stun 
>> allocation, turn would get used. If you're lucky, and you get 
>> a port-restricted port, then the relay would not be used.
>> 
>> So here is a case which makes me puzzled and possibly needs some
>> extra work: SIP client behind a restrictive NAT. With STUN assumptions
>> it will work (as long as they hold, of course),the client will send 
>> a "primer" packet to UAS and UAS media will come in.
>> 
>> With ICE, a UAS will first check connectivity to UAC's STUN address.
>> The ICE draft suggests doing so on the initial application request
>> (SIP INVITE e.g.) to keep call set up time low. At this 
>> moment however, 
>> UAC's NAT is not primed yet and the STUN check reports no 
>> connectivity.
>> 
>> -jiri
>> 
>> --
>> Jiri Kuthan            http://iptel.org/~jiri/ 
>> 
>> 
>> _______________________________________________
>> midcom mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/midcom
>> 

--
Jiri Kuthan            http://iptel.org/~jiri/