Since the on-hold is signaled with 0.0.0.0, it must not be changed by nathelper. Maybe the polycom didn't toggle the on-hold. Make sure that you handle properly the re-INVITEs, since they follow loose_route(). Just check the following config, it may help abit:
http://voip-info.org/wiki/view/OpenSER+And+RTPProxy
Cheers, Daniel
On 10/13/06 20:47, Benko wrote:
Hello!
I'm having a issue with NAT and rtpproxy. Usually my setup works fine with natted clients, the Connection Information is overwritten with the IP of the rtpproxy and audio passes through in both directions. However, today i came across a problem where the Polycom 501 sets a outgoing ip of 0.0.0.0 instead of the private ip after resuming a call that was on hold(actually, the other party is invited again) - and the force_rtp_proxy ()-command on openser left the ip untouched instead of overwriting it with the rtpproxy-ip. As a result the person that was on hold had audio but the polycom user(with the "wrong" ip) hadn't.
The false ip left aside, is it expected behaviour of force_rtp_proxy to not touch 0.0.0.0?
Just out of curiosity - does someone know the "on hold"-problem with polycoms?
thx christian
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users