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. Thanks again, Alex -----Original Message----- From: logan [mailto:[EMAIL PROTECTED] Sent: 19 July 2007 14:03 To: Alexander Boreham; [email protected] Subject: Re: [sipxtapi-dev] STUN response ignored on RTP and RTCP ports(introduced in re vision 9386) Hello, See if this helps - http://list.sipfoundry.org/archive/sipx-dev/msg04452.html. Thanks. Best Regards, Hitesh ----- Original Message ----- From: "Alexander Boreham" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, July 19, 2007 5:09 PM Subject: Re: [sipxtapi-dev] STUN response ignored on RTP and RTCP ports(introduced in re vision 9386) Hi, I have an update on this. If I change the CpPhoneMediaInterface::createRtpSocketPair method to pass true into the bReadFromSocket parameter of the call to OsNatDatagramSocket::enableStun, then the SDP is populated correctly with the STUN response. I can't see where any listeners are set up if the value is set to false, although again with this problem I don't know the code well so probably missed something. Perhaps the parameter should be passing in true rather than false? Thanks, Alex -----Original Message----- From: Alexander Boreham Sent: 19 July 2007 11:28 To: '[email protected]' Subject: STUN response ignored on RTP and RTCP ports (introduced in revision 9386) Hi, Sorry to report another problem but this is also causing issues. The changes made in revision 9386 have caused STUN failures on the RTP and RTCP ports. The SIP call control port still receives STUN responses correctly. I've made many Wireshark traces and can see that the STUN requests are correctly made to the server and that the correct STUN responses are received back but sipXtapi doesn't use the responses on the media ports. Looking back through the changes and trying old builds I found the point at which this issue started to occur. Here's a link to the change list: http://scm.sipfoundry.org/viewsvn/sipX?view=rev&sortby=date&revision=9386 I've started to look into it but thought that maybe somebody would have an idea of the problem already. Presumably one of the changes has caused the STUN response messages to be dropped, maybe because we haven't yet negotiated a codec. Any help to track this down would be appreciated! Thanks, Alex ===== Alex Boreham Development Engineer Redwood Technologies Limited The Redwood Building, Broad Lane, Bracknell, Berkshire, RG12 9GU, U.K. Registered in England No. 2817863 T +[44] (0)1344 304 344 F +[44] (0)1344 304 345 E [EMAIL PROTECTED] W www.redwoodtech.com ===== Email Disclaimer The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this email are subject to the limitations of Redwood Technologies Limited's standard terms and conditions of contract. _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/ _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
