[Asterisk-Users] Polycom phones, UNREACHABLE

[C F]

I now have the problem solved (or so I think) even without the qualify
in sip.conf.
It happens to be that the problem was just that the firewall would not
allow the packets back in after a specific time. All I had to do was
create trigger rules on the firewall to allow the packets back in
based on the outgoing port numbers. Now I have the Polycoms register
every 300 seconds, and the problem seems to be gone.

On 5/29/05, C F <shmaltz at gmail.com> wrote:
> I'm having the same issues with the polycom phones, as well as with
> Sipura ata's. I am also using on another natted network a sipura ata,
> that I changed the settings on the sipura that might help, and it did
> help, I havn't had an unreachable message since.
> I'm not sure if on the second network the reason it's helped is
> because of: A. the settings I changed. B. The NAT router I'm using. C.
> A combination of both.
> In any case, I think that the setting is what helped me. The setting
> on the sipura are:
> 1. NAT mapping enable = Yes (the same as nat=yes in sip.conf, I believe)
> 2. NAT keep alive enable =yes (the same as qualify=yes in sip.conf, I believe)
> On the Polycoms we have a setting:
> voIpProt.SIP.keepalive.session-Timers
> I'm not sure but I believe if these would be set to 1 is the same as
> setting qualify=yes and the same as the sipura settings above.
> As far as I understand the qualify=yes in sip.conf is meant to figure
> out if the clients are too lagged by sending notify packets to them,
> and if they are make them unreachable. A side effect of this is also
> that it might keep the session alive, in which case if you have
> problems of not being able to reach clients behind nat it will help.
> Although it does help somewhat, these keep alive settings help much
> more when done from the client that is behind NAT, and not from
> asterisk. As is evident with my Sipura ATA that has these settings set
> right.
> I plan on changing the settings I outlined above on that site where I
> have the problems, and I'll post back with the results.
> The other things that could be wrong is that the NAT router (where I
> have the problem I'm using a Westell soho router/modem combo, where I
> don't have the problem I'm using a SMC soho router, the SMC has a much
> better firewall than the Westell since it has a SPI engine in there,
> that's why I suspect that the settings are the problem and not the
> firewall) is the one not allowing the packets in after a while.
>