STUN transaction timeout

Jonathan Rosenberg wrote:
> > BTW, 9.5 seconds seems to me too long. I would like to know 
> if there is
> > a specific reason for that.
> 
> Typical value for transaction timeouts on public Internet. 
> SIP uses an 
> even larger number, 32s. STUN is quite aggressive by comparison.
> 
> Also, note that with ICE, the clients will use the "default" 
> media path 
> - generally through a relay - until the connectivity checks yield 
> something better. So you'll still get media flowing even if 
> the checks 
> take much longer.

Thanks for the reply, although I am not clear about this yet...

I understand we can grab a guaranteed media path through a relay for
immediate connection, however, I believe there may be a service
that can not afford the relay server, or even it could afford it, it is 
desired that a client find the best path to be used ASAP.

In connectivity check, STUN packets are used right on a media path. 
Target transport addresses have already been ready to receive the
STUN packets by the time a client initiates connectivity checks.

To me, if there is considerable amount of delay, that is simply
propagation delay on the media path, any other signal transactions 
are not involved. If this is correct, the media path taking such a long 
time would not be a good one to be used especially for a phone 
conversation. Any other factors for the delay you are aware of?

One thing I thought..
May be we can measure the propagation delay with STUN packet
and put this factor into logic to determine the best path, leaving the
timeout spec as is, so that client does not chose a path taking
more than a specified amount of time (e.g. 2 seconds) for a phone 
conversation.

Yutaka