IVM answers but gives no sound

psykomotor

Hi,

I've been playing around with IVM all day and I've not managed to get it to work. Its quite frustrating !

My setup is IVM AA running on a Dedicated Server (Windows Server 2003 Box - Remotely Hosted). Connection to telephone system is via VOIP, provided by Sipgate. Server is managed via remote desktop and does not feature any form of sound - so running the 'simulation' is not viable. Read on however and it should be apparent this doesn't matter...

What happens is, when I dial in from a landline, The IVM answers the call but no audio is heard. The IVM can hear the end user though because it responds to key presses and will happily record voicemail if I set it up to do that. Just wondered if anyone had any experience of this sort of fault ?

Current 'Debugging' Action Taken :

NAT/Routing/Firewall

Server runs configured IPSec, no other firewall. Direct 10Mbps connection to the internet. 2 Static IP's, not NAT routed.

Tried turning all security/port blocking off via IPSec. No Change. Double checked by using Xlite client on the server, worked fine, IPSec or not.

VOIP Test

Tested system via VOIP Only. (Xlite running on my local machine).

Everything works fine when connected directly via VOIP, Reliable and responsive.

VOIP Provider Integrity - Other Applications

XLite client from previous test then used to recieve a call from a mobile, and a landline.

In both tests bi-directional communication was 100% successful.

Alternative VOIP Providers

Added alternative VOIP Lines. This annoyingly wouldnt work at first due to what I believe to be a separate problem with multiple interface IP's.

No other lines would register correctly, DrayTel and Voiptalk both fail to connect at all (devices dont register with SIP). UPDATED : Got VoipTalk working via Axon - confirm both PSTN and VoIP communication to IVM to be correct. Believe original issue to be solved now - have other problems but will repost about those.

My current feeling is something is incompatible between Sipgate's PSTN system and IVM. UPDATED : This is beyond all reasonable doubt confirmed as the problem now.

Thanks in advance.

pythonpoole

I don't know the exact cause of the problem, but I thought I'd let you know that in the past when I've used Remote Desktop (Microsoft's program), it seems to cause problems with audio devices and software using those audio devices, and those problems aren't restored until you actually go to the physical location and log-in from there. In fact, this is the very reason is why I don't use 'Remote Desktop' any more, and instead use TightVNC which is an extremely small and free app that works just as well as remote desktop, probably better. It's also more customizable.

So I'm not saying it's the problem, but I will say I have had problems with Remote Desktop in the past related to audio faults.

psykomotor

Thanks python,

Yeah - I've seen sound issues from RDP before. I've kinda put the theory on the back seat a bit because of the way it is working correctly over VoIP. I suppose I should mention the server has no audio devices. I am certainly not getting any audio (from IVM simulations, WMP, Anything) via RDP - even though it just uses some strange emulation driver.

I'll look into TightVNC, but I'm quite fussy about consistency so I keep my third-party apps to a bare minimum

Afraid I can't get to it physically though, its about 100 miles away locked up in a data center EDIT : You've given me an idea though, because the server does have remote control hardware which just feeds the VGA signal over the network, which is as good as being there (no RDP or any software, pure hardware implimentation)

DonFritz

psykomotor wrote:

Thanks python,

Yeah - I've seen sound issues from RDP before. I've kinda put the theory on the back seat a bit because of the way it is working correctly over VoIP. I suppose I should mention the server has no audio devices. I am certainly not getting any audio (from IVM simulations, WMP, Anything) via RDP - even though it just uses some strange emulation driver.

I'll look into TightVNC, but I'm quite fussy about consistency so I keep my third-party apps to a bare minimum

Afraid I can't get to it physically though, its about 100 miles away locked up in a data center EDIT : You've given me an idea though, because the server does have remote control hardware which just feeds the VGA signal over the network, which is as good as being there (no RDP or any software, pure hardware implimentation)

The only other thing I thought of was: Do you have MP3s or wavs as your message? I have found some wavs don't work right and don't play audio. Since you don't have a soundcard you could not tell that. Convert to MP3 and try if they are wavs.

Don

psykomotor

Thanks Don,

I have checked the audio being correct via the VoIP - As it turns out, some of them did refuse to play back, but they were deeper into the OGM menu - this is not the fault causing the landline to fail. (Behaviour *should* be identical for PSTN and VoIP anyway, as far as the IVM is concerned, I can't see why it should even want to know whats on the other end, nor should it matter)

I've gone a bit further in trying to work this out an installed Axon for line testing. The VoipTalk account now works, but the DrayTel account still does not. Ive absolutely triple-checked the details on all lines.

This has been absolutely fruitless because IVM won't connect to Axon - Yes I've checked every password and setting, I'm just getting 'Server localhost did not respond to register' - Same error as with the DrayTel line (and previous, VoipTalk). I've tried with many extensions, passwords, at both ends. I've even tried using the proper domain name (This server has two IP's directly connected to the internet, with fully-qualified domain names)

I'm sort of at a loss now, why on earth can't IVM connect to Axon which is running right next to it (so to speak) ?!?

Could this be anything to do with having two network interfaces ? I notice it gives me a private IP ending in .76 (IP1) and a public IP ending .77 (IP2).

By the way, as a note to the developers for Axon, don't use strings as ID's* - use numbers - On the Axon web interface, if you enter a VoIP line with a # in the name, you can't edit or delete it (loses the part after the # at some point in the request). I had to reinstall to reconfigure a line !

*at least, certainly not strings the user can enter.