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 _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
