Hi, Again, thanks for your response.
It looks to me like you're saying SipXtapi ignores the STUN response as we haven't yet established an RTP receiver. It sounds like we have a Catch 22 scenario here! In the STUN RFC they talk about a CHANGE-REQUEST field that allows the STUN message to be sent back to another IP address and port. Maybe we can have this sent to the call control component? That way we also don't need to worry about receiving STUN messages mixed in the RTP stream once it has been established. This does sound like a big change to me so maybe it's not so practical. Also, I noticed there have been some bug fixes for STUN. I've tried 9895 but none of those changes visibly affected this problem. Thanks, Alex -----Original Message----- From: Jaroslav Libak [mailto:[EMAIL PROTECTED] Sent: 19 July 2007 22:11 To: Alexander Boreham Cc: logan; [email protected] Subject: Re: [sipxtapi-dev] STUN response ignored on RTP and RTCP ports(in troduced in revision 9386) 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. > As you suggested, this problem can be fixed by using: rtpSocket->enableStun(mStunServer, mStunPort, mStunRefreshPeriodSecs, 0, true) ; but also use rtpSocket->enableTurn(mTurnServer, mTurnPort, mTurnRefreshPeriodSecs, mTurnUsername, mTurnPassword, true) ; otherwise turn wouldnt work. The reason of stun failure is in MpRtpInputAudioConnection::startReceiveRtp: if(numCodecs > 0 && codecArray) During dialtone, numCodecs is 0, thus messageQueue.send(msg); isnt executed, RTP reception doesnt start and STUN response is missed as nobody is reading from socket. This is probably intentional, so that RTP reception doesnt start until call is in alerting state. So we have only one option, that is to wait during dialtone in rtpSocket->enableStun while in SipConnection. Different waiting should be implemented, so that we can wait for both Turn and Stun response in paralel. Jaro _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
