Jump to content

jlumby

Members
  • Posts

    290
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    Bloomington, MN

Recent Profile Visitors

9,660 profile views

jlumby's Achievements

Newbie

Newbie (1/14)

0

Reputation

  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
×
×
  • Create New...