Jump to content


  • Posts

  • Joined

  • Last visited


Contact Methods

  • MSN
  • Website URL
  • ICQ

Profile Information

  • Gender
  • Location
  • Interests
    Computer Software Development/Design<br />VoIP Technology, PBX Systems & IVR Attendants<br />

Recent Profile Visitors

11,374 profile views

pythonpoole's Achievements


Einstein (7/7)



  1. It depends if you have set IVM to use hardware or software hangup detection. It's been a while since I've used IVM, but if software detection mode is enabled, it means IVM has to be constantly listening for those off-hook tones and listen to them repeatedly to confirm that it has heard a hang-up/off-hook signal. Hardware based detection (if it works) will almost always outperform software detection. In this case, the actual modem/telephony board will detect when the caller hangs-up and signal to IVM much faster than IVM would be able to detect the disconnection itself. The biggest issue with hang-up detection is that there are so many different telephony standards around the world today, you're lucky that it recognizes the hang-up at all. Some parts of North America don't even have hang-up tones, as soon as the other party hangs-up, the local party goes straight back to dialtone ready for a new call. In most of North America, the hang-up is followed by a reorder tone that sounds kind of like a busy signal which is eventually followed by a loud off-hook warning tone. In the UK it's different, and in Australia it's different even still. It's even more complicated by the fact that the hardware or software detecting the hang-up is usually listening for tones at a specific volume level, and any adapters or other devices between the modem and the phone jack can cuase the sound to be just ever so slightly softer or louder than expected and cause a failure in detection. -- So to cut a long story short: - Issues with detecting disconnections are probably the most common problems in the telephony world, you're not alone - Different countries and regions use different standards that your modem/software may not support in terms of detecting hang-ups - You can try switching between hardware and software detection and tweaking the settings to see if you are able to improve peformance a bit - Hardware detection (if it works for your setup) usually outperforms software detection
  2. Wingmiester, I'm pretty sure your problem is unrelated, although I don't have a solution for you - sorry (it sounds like a bug though). The khz refers to the sampling rate/frequency which is essentially the sound quality. Since most telephone systems today run on 8khz audio, many Text To Speech developers make two versions of their 'natural' voices; a 22-44khz voice for desktop applications and an 8 khz voice for phone applications. Normally there is no issue with using a 22khz (or higher quality) voice in IVM or any other telephony system, but the 8khz voices sometimes sound better because they are specifically designed to perform best over the phone.
  3. You're not the only two who have contacted me /posted about this problem, and all of the cases have appeared in a very recent timeframe. I'm willing to bet that something was changed in Axon recently which is causing this to happen (I'll have to put this down to a bug because as far as I can tell there is nothing wrong with your dialplan setups).
  4. A "404 Not Found" SIP error is just like a webpage 404 error. It means the number you are dialing is not found to be a valid/existing extension or is not a valid phone number. The error is typically generated by the service provider, not the client... However, if Axon is not set to use your outbound SIP service as the default dialing plan, you will find that Axon will actually route your calls internally. In this case, dialing an external number would produce a 404 error because Axon does not recognize the number in its internal database of extensions. You need to make sure that you have selected the correct default dialing plan in Axon.
  5. Judging by your other question, I think you are using the Mac OS X version. The OS X port is slightly different, and from what I've seen, does contain some minor bugs that the Windows version does not. I will say though that the mac version really does not have the large userbase that the windows version has, so it takes a lot longer to find and fix these bugs. The OS X port also hasn't been around that long relative to the Win version so it's still in the 'testing the waters' phase I would say.
  6. Well it might not be as much as a bug as just a matter of system priority. I gather you are using Mac OS X, but for just about any operating system the same principle applies. Different applications can typically be given higher priority than others in the 'Z-order', this means that if a low priority application tells the OS to bring it to the front, the OS may decide that it should still appear behind another application that has a higher Z-order priority. All this means is Express Talk probably has a low (default) priority and that for whatever reason iTerm considers itself to be higher in the food-chain. NCH could probably bump up the priority a bit considering a phone call is pretty important, but I wouldn't really call this a 'bug'.
  7. Well you say you have a DSL connection with 10 mbit of bandwidth, but you don't specify what your "uplink" bandwidth is (I'm assuming you gave the downlink). Remember that in this case the uplink bandwidth is the most important because you are not very concerned with what the third party says to you, just what you say to them. The thing is, I also have a 10 mbit downlink... but I only have a 1 mbit uplink. That means I can only make 10% of the outbound calls I could make with a 10 mbit uplink! So, as you can see, it is very important to know what your uplink connection is rated at. Also, the audio codec you use will also play a large role in bandwidth. GSM uses only about 5 kbps each way, but the more commonly used G.711 codec (higher quality) uses about 80 kbps! Finally I just want to add that some users in the past have complained about a bug causing IVM to have difficulty with more than 3 concurrent voip calls, I don't know whether this bug has been squashed.
  8. Well It shouldn't sound like 4 kHz, but I would expect it to sound like 8 kHz as this is the telephony standard for now (except for some proprietary VoIP services like Skype). If you have a 22 or 44 kHz sound file and you down-sample it to 8 kHz, I find that it sounds a lot worse than if the original composition was made for 8 kHz playback (This is also true for text to speech and why many TTS companies will offer both a 22 and 8 kHz version of their voices). Lastly, if you are using the GSM codec, you will get cell-phone like quality & audio compression. You will find that using the G.711 codec which is basically uncompressed, provides much better quality audio. There is a trade-off however... If I remember correctly, GSM only uses about 5 kbps of bandwidth whereas G.711 uses something like 80 kbps (and I think that's just 1 way, x2 for up & down bandwidth).
  9. Or 4. This forum community is not very active, and a significant majority of the (small) userbase are novices and probably don't know the answer. Normally I would help out, but I haven't used Axon in over a year now and I have never experienced this error before. 1. Check to make sure the dialplan appears under 'Dialing Plans' on the Axon web config (I assume you've got this far) 2. Make sure you select a default dialplan (If I remember correctly, there used to be a drop down menu at the bottom of the dialing plans page 3. Make sure the dial plans are not excluding the extension you are dialing from 4. If Axon allows you to chose a dialplan for each extension now, make sure the correct dialplan is chosen Can't really suggest much else.
  10. You can click the drop-down box to see a brief history of incoming and outgoing calls. Unfortunately (despite me bringing this to the attention of NCH staff multiple times), Express Talk is severely lacking of a call log/history feature.
  11. A Delclined error is very vague, it just means the call was rejected for some reason. Keep in mind that the service provider can choose to generate whatever error code they want, so 'declined' can mean something different from provider to provider, so it is up to us to try and guess what the problem is. I'm thinking it could mean: - Insufficient funds / account balance negative - Username/password combination is incorrect - You are not authorized to dial that kind of number - The dialed number is not formatted correctly - The callee decided to screen and reject your call - General call failure, perhaps service-wide
  12. I agree that it is annoying. The change was made some time ago. Basically Axon went from a completely free product to something with a $$$ price tag literally overnight.. and I don't believe there was any added functionality to Axon other than more limitations. I expressed my opinions about this to the NCH staff, but it appears my words fell on deaf ears. I have since moved from Axon to Asterisk.
  13. Like DJ said, I know of other customers using Grandstream FXOs without any issues. In fact (from what I hear), it is easier to configure than the 'officially supported' SPA3000/SPA3102. There is however no guide for Axon available that I know of.
  14. Sometimes you can program this into the dialplan of the IP Phone or ATA adapter you are using, and this can be much easier than trying to come up with a round-about method in Axon. For example, almost any Linksys/Sipura ata adapter (e.g. the PAP2T) will have have a built-in dialplan option that gives you high levels of control over what numbers can be dialed, how they can be dialed, and how they should be processed before sending them to the SIP server (Axon). You could for example restrict calling to some numbers but not others (e.g. everything but 911), or you could make it a 'hot-line' phone, or just prevent any outbound dialing at all.
  • Create New...