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

[Benko]

On Tue, 17 Oct 2006 08:08:32 -0400
Nathan Hawkins <utsl at quic.net> wrote:

> I'm testing Polycom 601's with 2.0.1 firmware and Mediaproxy. I
> haven't noticed any problems with hold at all, so I haven't looked
> into whether it's using 0.0.0.0 or not. I supposed it's possible that
> that parameter doesn't actually work, and Mediaproxy just works with
> it.
> 
> I think though, that what you're describing below, where it resumes
> from hold with 0.0.0.0 as the address, is a firmware bug. The Polycom
> should definitely not be doing that. That's going to break all kinds
> of things.

hmm, guess i missunderstood - should the media direction parameter also
be marked when "on hold" is "started" or only at the end when we resume
the call that was on hold? 
Currently, Polycom sets IP 0.0.0.0 at the beginning of the hold, no
media path direction is set. When the call is resumed later, the polycom
sets the correct "sendrecv"-parameter (Which i didn't recognize
earlier, sorry). However, if i understood rfc3264 the polycom should
mark the media stream as sendonly on the beginning of the hold...

To clarify what i'm talking about i've attached the whole sip-debug of
two calls, the first call is sent on hold when a second call comes and
resumed after the second call has ended(1111111801 calls 2222222804
and it answers, then 0891234567 calls 2222222804 and 1111111801
is set on hold and resumed later). Openser runs on .98, which also
serves the rtpproxy. .97 is a asterisk-gateway.

Thanks for the input
Christian




> 
> What firmware version are you running?
> 
> Nathan
> 
> Benko wrote:
> > 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
> 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: polycom_hold2.txt
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20061017/2b06532b/attachment.txt>