Jaroslav Libak wrote: > Alexander Boreham wrote: >> Hi, >> >> Cheers for the link, it's certainly interesting. It looks to me like this >> problem has previously been found over a year ago and worked around in the >> same way as I proposed. >> >> What is curious is that the problem must have been fixed properly since that >> post (March 06) and then broken again a few months ago. Certainly it has >> been fine for us until a more recent (April 07) build of sipXtapi was >> required! >> >> For now I may just do as the link you sent suggests and set these values. >> > > I investigated this bug, and the problem is, that in > CpPhoneMediaInterface we enable STUN on the OsNatDatagramSocket, but > don't wait for STUN success. Therefore, when SipConnection wants to > construct SDP and asks for IP (getCapabilitiesEx), it gets local IP > address, because the one from STUN is not yet available. > > When working with STUN on sipxtapi level, one should normally enable > STUN, then wait for CONFIG events with STUN success, and then register > lines and start dialing. If this is observed, then NAT mapped IP appears > in SIP REGISTER and INVITE contact. > > The solution to use > rtpSocket->enableStun(mStunServer, mStunPort, mStunRefreshPeriodSecs, 0, > true) ; > > is not entirely correct, as then we would be stuck there indefinitely if > STUN server or port are wrong. enableStun has to be fixed when true is > passed. > > Jaro >
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. Jaro _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
