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/
