It seems not STUN related. My guess was that an over zealous firewall was in the middle and messing around with SDP
On 05/31/2011 05:24 AM, George Niculae wrote: > On Mon, May 30, 2011 at 11:38 PM, Todd Hodgen<[email protected]> wrote: >> I recently had a customer complaining about MOH not working for them, for >> both extension to extension calls, as well as calls via the ITSP. They had >> the old STUN server configured on the system, which did not work, which I >> had not noticed. As I started trying to resolve the MOH issues, a simple >> reset caused the ITSP trunks to not work. MOH still did not work. After >> resolving the STUN service, the MOH started working again. >> >> >> >> It seemed odd to me that there would be a relationship between STUN and MOH. >> >> >> >> I’ve noticed there is a current JIRA - >> http://track.sipfoundry.org/browse/XX-9581 >> >> >> >> This might be totally unrelated, but you might want to check that you have >> STUN configured to see if it resolves the issue. >> >> >> >> Anyone able to validate if there is a relationship between STUN working and >> Music On Hold? Baffled. >> > Todd, thanks for the pointer. I looked in attached sipXproxy logs and > I seen lots of errors like > > "2011-05-23T08:58:18.436279Z":706634:NAT:ERR:2.ha.ttplservices.com::B6A7DB90:SipXProxy:"StunClient::getPublicIpAddress > failed to obtain mapping from server stun.ezuce.com" > > Don't know for sure but I assume this is also happening in > http://track.sipfoundry.org/browse/XX-9581 - as Joegen pointed out > srtp contains some weird IPs. Joegen, do you think this is STUN > related? > > Thanks, > George > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
