> > After further investigation, I found out, that visual assist didn't > correctly show me who calls OsNatDatagramSocket::markStunFailure > therefore I thought it is never called. But it is called by > OsNatAgentTask::markStunFailure, thus mStunState.status will be set to > NAT_STATUS_FAILURE and OsNatDatagramSocket::enableStun will be > unblocked. However the delay 500ms in enableStun should be decreased to > something like 100ms for faster response in case STUN hostname is wrong. > > Alternative solution would be to add a parameter to > OsNatDatagramSocket::getMappedIp specifying whether we want to wait if > STUN mapped IP is not yet available and if STUN is enabled and nat > status is unknown. This solution could fix problems in many places > simultaneously, and prevent them from occuring again. >
After more investigation, I discovered that OsNatDatagramSocket::getMappedIp is indeed waiting for STUN success or failure in a loop, but we get a STUN failure, because nobody is reading anything from the RTP socket at the time that loop is running. Thus STUN failure timer fires, even though we have STUN responses queued up in buffer. STUN response can be received only if somebody is reading from the socket. I discovered a problem with r9386 some time ago, it caused too slow transition from dialtone call state. That was because we were waiting until STUN failure timer fires. But I didnt discover the cause until now. Jaro _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
