VoiceGuide IVR Software Main Page
Jump to content

Outgoing Call Gets Disconnected With New Sip

Recommended Posts

Hello Support,


We have created a new IVR server with a new SIP provider. During testing have we found out outgoing calls are all resulted in "Disconnected" state, while incoming calls are successful.

We have set up a technical session with the SIP provider, but before having a meeting with them, I wanted to hear from the expert.


Please see the attached logs: the Wireshark shows "401 Unauthorized" but not really sure if this was the cause because that displays even during "waiting for call" state.


Your help is much appreciated in advance.


Thank you.


Share this post

Link to post

Have you tried setting the CallerID on the outgoing call to either:








the SIP switch that is processing outgoing call may be using the CallerID ("From:" header) to determine which user is making this call, and then requests authorization for that user.


You could also speak with the SIP service provider to see if they have other options for authenticating outgoing calls (source IP address etc)



Also, Please enable HPET timer on this system and then restart Windows.

Run this command in Administrator Command Prompt:


bcdedit /set useplatformclock true



ktTel trace shows:

016 144820.766  2944     WARN  HPET not enabled. Enable HPET timer and restart Windows. QueryPerformanceFrequency 536870912MHz (quad=10054682722613874)
017 144820.766  2944     WARN  command to enable HPET: bcdedit /set useplatformclock true

Share this post

Link to post

Thanks for the suggestions.


The SIP provider mentioned their "new" system does require "From" information in header, and mentioned there is no other option for this.

Rather, they suggested provision of service over Static IP, which we will try. (I will keep you posted if there is any issues)


And for the "HPET" message, we were surprised because running "HPETTool64.exe /t" command returned "HPET is supported and enabled..." message earlier. I ran the suggested command and it looks good now.



Share this post

Link to post
we were surprised because running "HPETTool64.exe /t" command returned "HPET is supported and enabled..."


Was Windows restarted after HPET was enabled?

Share this post

Link to post

Yes, several times.


BTW, yesterday we re-installed HMP driver recommended by Dialogic for Windoes 2016, which is a bit later version than what your site offers.

I will also let you know if there is any possible issue with this new version.



Share this post

Link to post

Is this system running on VmWare ESXi platform ?


Can you please confirm if HPET is enabled at VmWare level:


To enable HPET:

  1. Open the .vmx file for the virtual machine using a text editor.
  2. Change hpet0.present to TRUE.

Using the vSphere Client:

  1. Click the Configuration tab.
  2. Click Advanced Settings.
  3. Select the VMkernel.Boot.timerEnableHPET option in Advanced Settings.

Share this post

Link to post

It is running on VmWare ESXi (as recommended by you).

And I believe HPET is enabled after I ran the command; I get the following now:



008 131904.443 1028 ktTel_HMP30vista DLL v7.5.15, created: Nov 23 2017, 12:35:53

009 131904.443 1028 start at 1222 131904.443
010 131904.443 1028 ------------------------------------------------------------------------------
011 131904.443 1028 TelDriver_Initialize [C:\Program Files (x86)\VoiceGuide\][] tts:[ATT DTNV1.4 Audrey16][]
012 131904.444 1028 szOSName: Microsoft Windows Server 2016, szOSVersion: 10.0, szOSBuild: 14393, szOSType: , szOSSvcPack: 0
013 131904.444 1028 Dialogic ® Host Media Processing (HMP) Software Release 3.0 Service Update 375 : 375
014 131904.444 1028 target: DialogicHMP
015 131904.444 1028 target: DialogicHMPvista
016 131904.444 1028 HPET enabled. QueryPerformanceFrequency 14.32MHz (quad=14318180)
017 131904.445 1028 Dialogic Service state is: Running
018 131904.445 1028 EcStream_InitAtStartup address of ecrx_store=0952E178, sizeof(ecrx_store)=1845600
019 131904.447 1028 CTelProxy::Initialize CreateTTSPort call


Thank you.

We will now continue testing with Static IP environment as soon as our service provider changes their trunk setting and keep you posted.


Thank you!

Share this post

Link to post



I just wanted to follow up on this issue that the Static IP solution worked with the SIP trunk; it does not care about the header information anymore.


Thanks for all your support again.

Share this post

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now