[Users] polycom on hold, IN IP4 0.0.0.0 and force_rtp_proxy()

[Benko]

Hmm, actually this parameter is set to 0(default).
However, in practice it still uses the old standard(rfc2543). There's no
media direction parameter in the sdp-message sent by the polycom for
some reason, although the manual states to do so (firmware 2.0.1). Is it
possible to force this somehow?

regards
christian

On Sun, 15 Oct 2006 19:58:33 -0400
Nathan Hawkins <utsl at quic.net> wrote:

> There's an option for the Polycom phones to switch the hold behaviour.
> 
> Set voIpProt.SIP.useRFC2543hold to 0, and it should use RFC3264 rules
> for signalling hold instead of 0.0.0.0.
> 
> 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 at openser.org
> > http://openser.org/cgi-bin/mailman/listinfo/users
>