Outgoing Call Gets Disconnected With New Sip

[iTime]

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.

IVR_Callout_logs.zip

[SupportTeam]

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

 

5036169012@sip3.thevoicemanager.com

 

or:

 

5036169012

 

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

[iTime]

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.

 

Thanks.

[SupportTeam]

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

 

Was Windows restarted after HPET was enabled?

[iTime]

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.

 

Thanks.

[SupportTeam]

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.

[iTime]

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!

[iTime]

Hi,

 

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.

[SupportTeam]

OK, Thanks for letting us know this is now resolved,