13 Oct
2006
13 Oct
'06
1:47 p.m.
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
14 Oct
14 Oct
2:09 p.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
17 Oct
17 Oct
7:32 a.m.
Hello!
hmm, i believe i'm handling the re-INVITEs correctly, i've attached the
relevant part of the config.
thx
christian
On Sat, 14 Oct 2006 21:09:38 +0300
Daniel-Constantin Mierla <daniel(a)voice-system.ro> wrote:
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(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
>
15 Oct
15 Oct
7:58 p.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
17 Oct
17 Oct
7:37 a.m.
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(a)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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6512
days inactive
6516
days old
4 comments
3 participants
participants (3)
-
Benko -
Daniel-Constantin Mierla -
Nathan Hawkins