Jump to content
Vodia PBX forum

jlumby

Members
  • Content count

    290
  • Joined

  • Last visited

Community Reputation

0 Neutral

About jlumby

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    Bloomington, MN

Recent Profile Visitors

9,298 profile views
  1. jlumby

    select returns error 0 in error log

    I did import a domain
  2. 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?
  3. jlumby

    410 Error

    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.
  4. jlumby

    BLF Problems in 4.2

    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.
  5. jlumby

    Is anyone suing the ITSP solution?

    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).
  6. 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.
  7. jlumby

    Memory Leak?

    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).
  8. jlumby

    Changed to CISCO ASA router and NO SOUND

    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.
  9. jlumby

    Changed to CISCO ASA router and NO SOUND

    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.
  10. jlumby

    BLF Problems in 4.2

    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
  11. jlumby

    CS410 Downgrade

    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.
  12. jlumby

    BLF Problems in 4.2

    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.
  13. jlumby

    BLF Problems in 4.2

    So far so good when it comes to the Aastra phones
  14. jlumby

    BLF Problems in 4.2

    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
  15. jlumby

    BLF Problems in 4.2

    I will when it is, however support still has not responded to my email request
×