Jump to content

jlumby

Members
  • Posts

    290
  • Joined

  • Last visited

Everything posted by jlumby

  1. 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?
  2. 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.
  3. 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.
  4. 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).
  5. 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.
  6. 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).
  7. 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.
  8. 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.
  9. 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. retry.zip
  10. 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.
  11. 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.
  12. So far so good when it comes to the Aastra phones
  13. 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. cseq.zip
  14. I will when it is, however support still has not responded to my email request
  15. 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.
  16. 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.
  17. 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.
  18. 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
  19. I have never been able to get it to work for me either
  20. The issue exists on the Aastra phones. It did not exist in 4.1, however it does exist in 4.2
  21. 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.
  22. 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
  23. 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.
×
×
  • Create New...