Check the proxy and registrar logs. Also check CPU and ram/swap. The logs
may show a lot of call or registration attempts. If the phone are not
registering via the internet close off port 5060.
--
~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip:
You neglected to indicate what type of firewall(s). Local to the server
firewall is important as is the remote firewall.
There are *typically* only 2 things that would make this happen (with
Polycom phones anyway):
1 - DNS. Sounds like you have phones inside / outside. In this instance
you
You can get logs from console cd /var/log/sipxpbx.To yum
update,from Console first do "yum clean all" and then do "yum
update -y"
Regards,
Kumaran T
On 9/17/2012 6:53 PM, IT Manager wrote:
Where
Sounds like you are being bothered from the outside.
/var/log/sipxpbx
Is where logs are.
--
~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: tgrazi...@voice.myitdepartment.net
Fax: 434.465.6833
~~
Linked-In Profile:
Thanks, thats the clue I needed. Here is the process i used to get the dump in
case someone else is curious.
ls /proc/PID/fd/1
Output shows
/proc/PID/fd/1 - pipe:[979841]
Doing a cat on /proc/PID/fd/1 while using kill -3 shows no output.
So then I use lsof to find that other process tied to
Output available here: http://pastebin.com/HB2p4TPR
jmap dump here: http://www.thesummit-grp.com/dump.map
-M
Matt White mwh...@thesummit-grp.com 09/17/12 2:03 PM
Thanks, thats the clue I needed. Here is the process i used to get the dump in
case someone else is curious.
ls /proc/PID/fd/1
Hi Laurie,
I have to agree with Tony here. I've had exactly the same issue you
describe at two different installations, and in every case it turned out to be
sip packets from the Internet, making connections to the SipXecs server, and
running it out of resources. I can't say if the
Utilization issue appears to be jain-sip build specific.
I back rev'd the jain-sip-sdp-1.2.2140.jar to jain-sip-sdp-1.2.2014.jar and CPU
utilization has gone away.
I will resume testing to see how well this version of jain-sip functions with
sipxbridge. 1.2.2014 is still way newer than what
The registrations could be because of bogus registration attempts. BUT if
these are call attempts (not registrations) against the proxy, they will
effectively use resources if the attempts are consistent enough in volume
to effectively eat the resources away until the registrar can't process
Tony, I must now disagree. The script serves to block both registration
attempts and blod call attempts.
Essentially, there is a 'block all access from outside IPs' rule, and the
script adds exceptions for those who have successfully logged in (on port
80/8443, which has a permanent
Then how does your script discern a real sip call from a foreign system? It
must not be allowed since there is no phone registered.
--
~~
Tony Graziano, Manager
Telephone: 434.984.8430
sip: tgrazi...@voice.myitdepartment.net
Fax: 434.465.6833
~~
Linked-In Profile:
Ahhh. We (and the script) do not allow SIP calls from anything other than our
users' SIP endpoints.. It is a closed SIP system, with all 'public' calling
happening via PSTN gateway.
The script is a mid-way point between 'allow everything' and 'allow nothing'.
...Steve...
On 2012-09-17, at
12 matches
Mail list logo
