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/
