I'm having some trouble with Polycom Soundpoint phones. I have had good luck deploying them on a local network, but now I've tried putting some in place which access their * server across the network. The * server is on a public IP and the polycoms are behind a NAT on a cable modem broadband connection. Every so often I get: May 27 16:12:08 NOTICE[29728]: Peer 'Polycom1' is now UNREACHABLE! May 27 16:31:54 NOTICE[29728]: Peer 'Polycom1' is now REACHABLE! (Sometimes the first message says "TOO LAGGED"...) And as you can see these messages are quite a ways apart, not just a few seconds. I have read the archives and found some clues that decreased the frequency of the problem, but have not eliminated it. My configuration for the phones in sip.conf is: defaultexpirey=3600 ; this is required by our VoIP provider rather than 120 [Polycom_1] username=Polycom1 secret=xxxx type=friend canreinvite=no ; specifically recommended in archives nat=yes ; phone is behind a NAT qualify=yes ; I suspected this might help... host=dynamic dtmfmode=rfc2833 context=internal disallow=all allow=ulaw In the sip.cfg file for the phone on it's FTP server, I have set: -server.1.address to the public address of the server -voIpProt.SIP.outboundProxy.address to the public address of the server -nat.ip is not set, as the description doesn't make it look like I want to mess with it... -there are other possible settings in that file that might be helpful, but the descriptions are a bit thin in the manual... I want to deploy more of these phones, but if they are ducking off the server every so often, that makes them unreliable. Does anyone have any ideas what the problem might be? I think if I remove "qualify=yes" from sip.conf it will eliminate the warnings in the log, but I think the phone will still be unreachable for that time period and the problem is just less evident... Thanks! -- -M There are 10 kinds of people in this world: Those who can count in binary and those who cannot.
Actually, it looks like I'm getting this problem on all my phones. When I was testing my phones, most worked pretty well with an occasional complaint from the Polycom. I've moved them now to a different location and the ISP must have different NAT translation going on that make it more difficult to penetrate the NAT. Am I right in guessing that even with qualify=no the problem would still be present (unreachable phones), but it wouldn't show up in the logs? Thanks! On Fri, May 27, 2005 at 11:26:35PM -0400, Michael George wrote:> I'm having some trouble with Polycom Soundpoint phones. I have had good luck > deploying them on a local network, but now I've tried putting some in place > which access their * server across the network. > > The * server is on a public IP and the polycoms are behind a NAT on a cable > modem broadband connection. > > Every so often I get: > May 27 16:12:08 NOTICE[29728]: Peer 'Polycom1' is now UNREACHABLE! > May 27 16:31:54 NOTICE[29728]: Peer 'Polycom1' is now REACHABLE! > > (Sometimes the first message says "TOO LAGGED"...) > > And as you can see these messages are quite a ways apart, not just a few > seconds. > > I have read the archives and found some clues that decreased the frequency of > the problem, but have not eliminated it. My configuration for the phones in > sip.conf is: > > defaultexpirey=3600 ; this is required by our VoIP provider rather than 120 > > [Polycom_1] > username=Polycom1 > secret=xxxx > type=friend > canreinvite=no ; specifically recommended in archives > nat=yes ; phone is behind a NAT > qualify=yes ; I suspected this might help... > host=dynamic > dtmfmode=rfc2833 > context=internal > disallow=all > allow=ulaw > > In the sip.cfg file for the phone on it's FTP server, I have set: > -server.1.address to the public address of the server > -voIpProt.SIP.outboundProxy.address to the public address of the server > -nat.ip is not set, as the description doesn't make it look like I want to > mess with it... > -there are other possible settings in that file that might be helpful, but > the descriptions are a bit thin in the manual... > > I want to deploy more of these phones, but if they are ducking off the server > every so often, that makes them unreliable. > > Does anyone have any ideas what the problem might be? > > I think if I remove "qualify=yes" from sip.conf it will eliminate the warnings > in the log, but I think the phone will still be unreachable for that time > period and the problem is just less evident...-- -M There are 10 kinds of people in this world: Those who can count in binary and those who cannot.
qualify = yes is what is causing the messages. You can assign a value rather than yes. like 1000 or something or you can remove the qualify statement alltogether. The message is just a warning. Eliminating the warning does not eliminate the lag problem. ----- Original Message ----- From: "Michael George" <george@mutualdata.com> To: <asterisk-users@lists.digium.com> Sent: Friday, May 27, 2005 11:26 PM Subject: [Asterisk-Users] Polycom phones, UNREACHABLE> I'm having some trouble with Polycom Soundpoint phones. I have had good > luck > deploying them on a local network, but now I've tried putting some in > place > which access their * server across the network. > > The * server is on a public IP and the polycoms are behind a NAT on a > cable > modem broadband connection. > > Every so often I get: > May 27 16:12:08 NOTICE[29728]: Peer 'Polycom1' is now UNREACHABLE! > May 27 16:31:54 NOTICE[29728]: Peer 'Polycom1' is now REACHABLE! > > (Sometimes the first message says "TOO LAGGED"...) > > And as you can see these messages are quite a ways apart, not just a few > seconds. > > I have read the archives and found some clues that decreased the frequency > of > the problem, but have not eliminated it. My configuration for the phones > in > sip.conf is: > > defaultexpirey=3600 ; this is required by our VoIP provider rather than > 120 > > [Polycom_1] > username=Polycom1 > secret=xxxx > type=friend > canreinvite=no ; specifically recommended in archives > nat=yes ; phone is behind a NAT > qualify=yes ; I suspected this might help... > host=dynamic > dtmfmode=rfc2833 > context=internal > disallow=all > allow=ulaw > > In the sip.cfg file for the phone on it's FTP server, I have set: > -server.1.address to the public address of the server > -voIpProt.SIP.outboundProxy.address to the public address of the server > -nat.ip is not set, as the description doesn't make it look like I want to > mess with it... > -there are other possible settings in that file that might be helpful, but > the descriptions are a bit thin in the manual... > > I want to deploy more of these phones, but if they are ducking off the > server > every so often, that makes them unreliable. > > Does anyone have any ideas what the problem might be? > > I think if I remove "qualify=yes" from sip.conf it will eliminate the > warnings > in the log, but I think the phone will still be unreachable for that time > period and the problem is just less evident... > > Thanks! > > -- > -M > > There are 10 kinds of people in this world: > Those who can count in binary and those who cannot. > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >
Gregory Wiktor - ADCom Corp.
2005-May-31 19:21 UTC
[Asterisk-Users] Polycom phones, UNREACHABLE
I had an odd issue too. Seems that the only fix was, unplug poly, restart asterisk, plug in poly. The registrations would drop. This is behind a non-nat vpn. When I did a provision as opposed to register, it seemed to work better. Asterisk would get abunch of not authorized messages. Greg -----Original Message----- From: asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of C F Sent: Monday, May 30, 2005 11:02 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] Polycom phones, UNREACHABLE 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@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. >_______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users