jlumby
-
Posts
290 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by jlumby
-
-
I an running PBXnSIP version 3.4.3202 Win32, and in the error log it keeps showing "select returns error 0" What is causing this error, and what does it mean?
-
I know that mid way into the 4.2 releases a 410 error was added as a feature to deal with out of sequence CSeq numbers as a result of a PBX restart. The problem was it did not fix things for Aastra, and it created problems for others like Grandstream, and Yealink. I am wondering if there are any plans to remove it from future versions since it seems to be doing more harm than good.
-
Just checking to see if there has been any more progress on this. I am currently testing 4.2.0.3961 and it has the advantage of the cseq numbers staying in sequence as long as the PBX is not restarted (this was a problem in the original 4.2 release, and fixed about half way through), however when the PBX is rebooted, Aastra, Grandstream, and Yealink BLFs stop working when the get the 410 error from the PBX. I know this was added as an attempt to fix Aastra BLFs after a reboot, however it has not, and it has created a new problem with Yealink, and Grandstream (that accept out of sequence cseq numbers). I was wondering if we could find a middle ground where the PBX does not send a 410 after a reboot, however the cseq numbers stay in order as long as the PBX is not rebooted. I feel this is the best compromise so far.
-
Not that I am aware of, I have heard a lot of people throw numbers around, however I have not heard anything over 200 simultaneous calls. I have heard others say that they stop at 60 (especially if there is transcoding going on).
-
As for the version, we haven't yet tested version 4 thoroughly. Do you think that the problem can be solved by upgrading?
In my personal experience, 3.4 is the most stable/reliable version available. I have tried various versions of 4 and I am not ready to take the leap. 4 has a ton of cool new features, however I have found it to be very buggy as well. The biggest issue that is holding me back from upgrading is it seems like 1 out of every few hundred calls has no audio. It is very difficult to reproduce for a packet capture, however in downgrading back to 3.4 the problem completely goes away. I am continuing to follow the V4 release sequence, and will probably revisit it in a few months, unless I hear of the no audio issue has been fixed on the forum.
-
I have seen this exact situation in 3.4 when there is a denial of service attack. Run a packet capture to see if you have someone hammering your PBX from the outside with registration requests. If so, then block them at the firewall. The problem is that the service will not recover on it's own after the source is blocked at the firewall, you will then need to restart the service, and you will be good to go (until the next attack).
-
But it was registering correctly just 5 minutes before switching from the regular Linksys WAG router. This started to happen when using the CISCO ASA 5500.
Thanks.
I see that you have the firewall set to allow the traffic, how about the port forward rules so that it knows where to send the traffic that is allowed by the firewall? You are correct, the ASA should have no effect on internal extension to extension calling. Sip inspection is usually enabled as one of the global inspection policies. Do you have the config of the ASA. The ASDM is pretty useless at showing the config as a whole.
-
I first guess is that the ATA has problems detecting what ports should be open. AFAIK the ATA monitors the traffic and then makes a decision which ports should be opened for RTP. This would mean that you dont have to explicitly set them up IMHO.
Is the PBX still running on a public IP address (routable, in the DMZ)? Maybe there something went wrong during the migration.
Correct, the ASA does sip inspection, so as long as 5060 is open, then it will dynamically open the RTP ports as needed. Make sure you have sip inspection turned on. What IOS version are you running on the ASA? I would recommend something at least as new as 8.22 My guess is it is a configuration issue. I know tons of people using ASA firewalls with SIP, and they work wonderfully.
-
Does the "410 Gone" include the "Retry-After" header?
Correct, it does include Retry-After: 60
I have also noticed that after a PBX reboot, Yealink phone BLFs stop functioning. This was not an issue prior to this 4.2.0.3956 build.
To sum everything up, while the PBX has not been rebooted, BLFs on all phones seem to work perfectly, however after a reboot Yealink, and Aastra BLFs do not work. In previous versions 4.1 and earlier, only the Aastra BLFs were effected by a reboot, now the Yealink ones are as well. I am attaching a packet capture to show 2 occasions of 2 different Aastra subscriptions, and the 410 that the PBX is sending back.
-
I have a CS410 that is running 4 I have had so many issues with it, I would like to downgrade it to 3.4 Is there a way to do this, since the web interface will not allow it if I upload 3.4 to it, when you reboot, it is still at 4.
-
I went on a little further to test to see if the BLFs worked after a PBX reboot. I see that the PBX replies to the subscribe with a 410 Gone now. It was worth a try, however unfortunately, the phone just gives up when it gets the 410 Gone message, so it is probably not worth having that portion in the code.
-
So far so good when it comes to the Aastra phones
-
There are couple of issues in this area. We have fixed one and there is one more pending. We are working with Polycom (& Aastra) to resolve this issue.
The problem with your statement is that starting with the first version of 4.2 the CSeq number would decriment without the PBX being restarted. This goes against the SIP RFC. Here is a packet capture that shows it happening without the PBX being restarted. This is purely a PBXnSIP problem, and the only reason that some models of phones do not have an issue with it is because they are not strictly holding the PBX to the RFC.
-
was the issue resolved ? if yes please post a link
I will when it is, however support still has not responded to my email request
-
Yes, this is a know problem with the Aastra phones. They register using SUBSCRIBE, and then when the PBX restarts it sends a SUBSCRIBE again as if nothing happened. The PBX then sends NOTIFY with "fresh" CSeq numbers which are really out of order from the device perspective.
We'll try to send a 410 Gone code when we receive a "fresh" (as from the PBX point of view) subscription. That should solve the problem; hopefully it does not break anything with other devices...
I have been aware of the issue you describe as occuring in all versions of PBXnSIP, however this is a new issue that only exists in 4.2 releases. The difference is that the BLFs get stuck after their first use, and the PBX is not rebooted. Each time the phones are reset, the BLFs light once, and get stuck again.
-
With this latest version that you posted, the BLFs light up on the Aastra, however they just like the previous post about the Polycom BLFs getting stuck, the Aastra BLFs get stuck as well. I did a packet capture, and I found that the PBX was sending the Notify to the phone, however the phones were rejecting it and responding with 500 CSeq out of order. I tried rebooting the phones, and the same issue happened during the first call after the reboot.
-
Windows
-
I have been following the 4.2 releases to see when issues with BLFs will get fixed up. With the early releases of 4.2 I noticed that the BLFs on phones woulg get stuck in their first state. I then noticed that in later releases the issue got resolved for some phones such as Yealink, however Aastra still had the stuck BLF issue. Now with the latest release of 4.2.0.3950 the BLFs do not light at all on any of the phones I have tested. I did a packet capture, and noticed that the PBX responds to the subscribe with a "489 Bad Event" error. Please let me know if there are any builds in the near future that will clean this issue up. I am looking for a very nice stable version of 4 that I can recommend. The problem is I do not feel that V4 has accomplished that yet. I was very happy with the stability of 3.4.0.3202 however lack of DoS protection and some memory issues was it's only shortcoming. I feel like with version 4 these 2 shortcomings of V3 were fixed, however many new issues were introduced.
-
I have had issues with the older versions starting if they got clogged up with CDR records. I adjusted the variable down to only keep them for 2d instead of the default of 30d and I have never had any issues since. The down side is once the system is clogged up, I am not sure if you can just delete them (I think I turned it down to 2d with no success). I love a perfectly clean server, so I ended up formatting/rebuilding from scratch, and the CDRs have been kept in check ever since
-
I have never been able to get it to work for me either
-
The issue exists on the Aastra phones. It did not exist in 4.1, however it does exist in 4.2
-
when you call to a hunt group and answer the BLF and the web status says the phone is alerting.
V4.x
I have been seeing similar issues testing the latest version of 4. I am seeing on Aastra phones that once the BLF indicates that it is in the connected, or the alerting state, they get stuck there permanently. I did not have this issue with early versions of 4.
-
I have a couple of customers that are long time PBXnSIP users. They were running fine in version 3. I upgraded them to version 4 to gain DoS protection. At that time, they started noticing that occasionally they would get calls with no audio. For the most part they wrote it off as someone hanging up on them. However they just discovered that it is happening every now and then with extension to extension calls. The extension to extension calls are not going through any kind of NAT, and their network topology has not changed since they were running V3 perfectly. One is running Cisco phones, and the other is running Aastra. The only thing that has changed is the PBX is now at version 4. To have this happening to 2 completely unrelated customers makes me suspect something in V4. Are there any changes in settings that V4 has that I should be aware of that might do this, or is anyone else experiencing this? It does not happen very often, only 1-2 calls out of every 500, so it is very difficult to replicate in order to capture while it is happening.
On a possibly unrelated note, I noticed that Version 4 generates a whole lot of emails that have the subject line of: User disconnects call. The body contains the line stating that "One side of the call between X and Y did not receive media for Z seconds and the other side of the call disconnected the call." The funny thing is I am sure that most of these are incorrect. The reason I know this is because I can generate it every time I page to a paging group where the only member is a cyberdata paging gateway (which paging by definition should have 1 way audio), or by faxing. The faxes always go through, however I believe the PBX stops getting traditional media, switches to T.38, and therefore thinks it is not getting media, when really all that happened is that it is getting T.38 instead of traditional audio.
Please let me know your experiences/ideas
-
With version 3 I was able to dial in remotely and toggle a service flag on or off. Now with version 4 I cannot seem to do this anymore. Is there a way to do so? It still works fine when dialing it internally, however if I call in, and place the call to the service flag using the credentials of an extension that has permissions to modify the service flag, it says I am not able to place the call.
select returns error 0 in error log
in General Setup
Posted
I did import a domain