Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by pythonpoole

  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.
  15. In terms of PSTN gateways, Axon can work with many TAPI compliant voice boards (see the NCH website for more info) as well as networked FXO gateways like the Linksys/Sipura/Cisco SPA3000. Skype calls can be handled through NCH's uplink application (costs extra). In my personal opinion however, it is not as stable as it could be and it has not been updated in sometime (i.e. may not even work with recent skype client versions). There are alternative software packages available on the net that can turn Skype into an SIP gateway including the official Skype to SIP gateway service (there is however a fairly hefty licensing cost on a per line per month basis). I don't excplicitly know of any gsm gateways that work with Axon, but if it has a normal analog RJ11 phone port on it, you can probably just use it like a regular landline connection. If not, there may be some compatibility issues.
  16. According to the user Megatech,
  17. Yes, I'm pretty sure under telephony settings you can select a specific OGM for each line to answer with (overriding the default OGM). Note: I haven't used IVM in a loong time, so this functionality may have been changed/removed/moved somewhere else in recent versions.
  18. You can try, although unless you are using a true hardware virtualization technology like Xen, you will probably experience sound break-ups in the conversation as the traditional 'software virtualization' technology will struggle to provide stable performance.
  19. They are pretty similar in functionality.. Express Talk has added support for Video over IP (I'm assuming Zoiper doesn't) as well as external USB phone support.
  20. After you install a Sapi voice, it should appear in the system control panel. If it doesn't, try restarting. In any case, those synthesized voices are not going to be much better than Microsoft sam. If you want a natural sounding voice, you should consider purchasing one of the natural voices from realspeak/nuance, loquendo or AT&T for example. Many of the voices can be purchased for about $30 from nextup.com. These 'natural' voices use speech concatenation to form words and sentences rather than using a tone based synthesizer. So for example, a person records their voice saying 'ap' and 'el'... When you put in apple, the software puts 'ap' and 'el' together to say 'apel'. This sounds considerably better.
  21. Well I don't really know what to suggest. According to the IVM 'sdk', that script should be working fine. I know that I have tested PHP plugins with IVM before (I'm talking year(s) ago though) on previous versions of the software, but I haven't actually done any testing recently. You may need to contact NCH directly about this one, or at least someone else who is making use of plugins.
  22. Ok, the first problem is that it appears you are making a plug-in call directly to a URL (which by default Windows will send to the default web browser). I don't think that will work (or at least I haven't tried) because IVM wouldn't be able to scan the output of the script from the browser, you're basically just telling the web browser to open the php page as if it was a web page. Instead I get IVM to execute PHP from the command line, as if the php script is a Windows executable rather than a web page. In other words, I would install PHP on the local IVM machine and run php.exe as the plugin... i.e.: C:\PHP\php.exe (or whatever your PHP.exe path is) You can then pass arguments to PHP.exe from IVM, including the script name/path to run and any additional parameters (check PHP command line documentation for more details). IVM should then be able to scan the output off the command line. Also, there may be another problem in that IVM may pick up both your print & echo statements, which would most likely cause IVM to get confused by the output. Try commenting out the echos if you encounter further problems.
  23. The issue is that there are many possible causes for echo over VoIP. It may take some trial and error to identify the exact cause of the problem. Here are some possible causes: 1) Echo Cancellation turned off - Express Talk has a built-in Echo Cancellation algorithm to help suppress some of the unwanted effects of Echoing. You can turn it on by selecting 'Use microphone and speaker and turn echo cancellation on' from the Communication Device selection under options. 2) Poor Network connectivity - Run the Network Setup Wizard in Express Talk to help solve network issues and ensure that there is no Firewall or router which is blocking ports that Express Talk is trying to use (by default Express Talk uses UDP 5060 and UDP 8000-16000 last time I checked). Regardless of whether this is causing echo or not, it is important to make sure there is a clear network path for Express Talk or you may encounter several other problems. 3) Feedback Loop - If you are talking to callers on speaker-phone, it is possible their voice is being sent back through the mic which can cause feedback. My understanding is that because VoIP has a larger latency (or delay) than its landline counterpart, this feedback is perceived as an echo. Edit: another one 4) The Service Provider - I have used some VoIP service providers before that had terrible problems with echoing, I eventually had to drop them as a carrier. It is possible the problem may reside on the service end.
  24. You won't. As I pointed out earlier, you cannot use the command-line control interface to poll status requests from Express Talk. In other words, it is entirely a one-way communication system. A possible solution (a bit far-fetched): If you use the Windows API calls for handling GUI elements like textboxes and buttons, you may be able to get the text from Express Talk's status window (you would first need to identify the Window handle of the Express Talk window either by class, or better yet, using it's window 'title' name)
  • Create New...