VoiceGuide IVR Software Main Page
Jump to content

Testing SIP Server

Recommended Posts

Hello support,

We have setup a sip server for testing, but have run in to a few issues. See log attached which includes wireshark trace. We are conducting internal calls using Linphone and both inbound and outbound work but no DTMF is being received by VG. Additionally SIP is not registering with our provider for external testing, however Linphone is working for external calls manually using the same setup. 

Thanks in advance for your assistance. 

1201Log.zip

Share this post


Link to post

WireShark traces show that system is not receiving any response to the sent out REGISTER requests:

image.thumb.png.62e4ae94575ba6afe13ebf8221da6bd9.png

ktTel trace shows that Registration details used are: reg_server=https://voippro.com, reg_client=mivatech5, local_alias=mivatech5@49.180.129.124

WireShark trace also shows that the softphone (Linphone) you are using to direct IP call into VoiceGuide is on system at 192.168.2.223

Can you post a WireShark trace of Linphone successful registration with voippro.com for comparison?

 

SECURITY NOTE: Please change the password used on the SIP account after posting any WireShark traces that capture SIP registrations. If password is too simple it can be cracked from the posted WireShark trace.

Share this post


Link to post

Regarding the DTMF: VoiceGuide by default uses RFC 2833, and you can see in INVITE issued from VoiceGuide that VoiceGuide asks that RFC 2833 be used, but Linphone is not confirming that RFC 2833 will be used by it.

Could not see any evidence of DTMF being sent from Linphone.

What mode of sending DTMFs is Linphone set to use?

Have you tried using MicroSIP instead of Linphone?

Share this post


Link to post

Looks like the WireShark capture was started a bit late as it did not capture the beginning of the registration process, but I think that we can see enough to see what the settings should be.

Please try using the below as the <VoIP_Registration> section in VoiceGuide's Config.xml:

<VoIP_Registration>
<Protocol>SIP</Protocol>
<RegServer>sip.voippro.com</RegServer>
<RegClient>mivatech5@sip.voippro.com</RegClient>
<LocalAlias>mivatech5@192.168.2.147</LocalAlias>
<Expires>3600</Expires>
</VoIP_Registration>

VoiceGuide service will need to be restarted after changing the Config.xml in order for VoiceGuide to read in the new Config.xml settings.

If you still encounter problems please post WireShark trace capturing registration attempt.

NOTE: Please change the password used on the SIP account after posting any WireShark traces that capture SIP registrations. If password is too simple it can be cracked from the posted WireShark trace.

Edited by SupportTeam

Share this post


Link to post

Thanks. Some progress with registration, but outbound call not being accepted. Logs attached.

I confirm we update the password each time we post a trace. 

0114.zip

Share this post


Link to post

Attached WireShark does not capture the outgoing call. Please post trace again that captures the outgoing call.

Also, in your current <VoIP_Registration> section is the <RegServer> entry like this:

<RegServer>sip.voippro.com</RegServer>

or like this:

<RegServer>https://sip.voippro.com</RegServer>

?

Please advise what is the current <RegServer> entry in the <VoIP_Registration> section.

 

Also, in the <VoIP_Authentication> section please leave the <Realm> and the <Identity> entries empty.

The provided traces still show the original registration failing. Are incoming calls made through the voippro.com account working?

Share this post


Link to post

sip.voippro.com should resolve to IP address 77.72.174.32

The Linhone traces show that correct IP address is used.

But the traces from  VoiceGuide system show that sip.voippro.com was getting resolved to a different IP address...

Run this in the command line on both systems:

ping sip.voippro.com 

and confirm what IP address is used. If IP address resolved on VoiceGuide system is different then you should determine why that is the case....

Share this post


Link to post

I confirm the IP for sip.voippro.com is resolving correctly (we had entered https, but have removed that).. 

One thing we found during testing is that the sip password caused config loading issues for VG if it contained symbols such as #&. Can it only be letters and numbers? We've updated the password accordingly. 

We've conducted further testing and not having any luck with outbound calls so far, logs attached including wireshark.

0331_1025_vg.zip

Share this post


Link to post

Please do the following. This will show more information in rtf logs:

1. Stop the VoiceGuide service.
2. Stop the Dialogic service.

3. Make the hidden directory C:\ProgramData visible.
4. Go to C:\ProgramData\Dialogic\HMP\cfg
( for older versions of windows go to C:\Program Files\Dialogic\cfg )

5. Backup existing RtfConfigWin.xml,
6. Replace it with attached RtfConfigWin.xml (if it is .ZIPed then unzip it first)
7. Shutdown and restart Windows.

8. Ensure Dialogic and VoiceGuide services are fully started.
9. Place a call into the system.
10. .ZIP up Dialogic RTF logs in Dialogic's \log\ subdirectory.
11. Please post the .ZIPed up logs here.

 

New RtfConfigWin attached below:

RtfConfigWin.xml

 

Share this post


Link to post

Please .ZIP up Dialogic RTF logs in Dialogic's \log\ subdirectory an post those as well.

Share this post


Link to post

It looks like in your <VoIP_Registration> section the <LocalAlias> field is being set.

Please try changing it from:

mivatech5@139.216.79.236

to:

mivatech5@139.216.79.236:5060

 

Share this post


Link to post

Call stays on the monitor this time, but no call coming through to the destination phone and no call in the SIP account log. 

 

Here's config setup we are using:

<VoIP_Registrations>

<VoIP_Registration>
<Protocol>SIP</Protocol>
<RegServer>sip.voippro.com</RegServer>
<RegClient>mivatech5@sip.voippro.com</RegClient>
<LocalAlias>mivatech5@139.216.79.236:5060</LocalAlias>
<Expires>3600</Expires>
</VoIP_Registration>

</VoIP_Registrations>

<VoIP_Authentications>

<VoIP_Authentication>
<Display>voippro</Display>
<Realm></Realm>
<Identity></Identity>
<AuthUsername>mivatech5</AuthUsername>
<AuthPassword>********</AuthPassword>
</VoIP_Authentication>

</VoIP_Authentications>

 

Test calls made with the requested update and logs attached. 

Logs.zip

Share this post


Link to post

WireShark trace shows a successful SIP REGISTER.

 

But looks like the number that is being dialed by the system is not a well formed SIP IP number...

Looks like the number that is dialed is:

0000161412611619@voippro

the part after the "@" needs to be resolvable to an  IP address.

you should probably change it to :

0000161412611619@sip.voippro.com

ws_miva_220401.png

Share this post


Link to post

Have you tried calling into this system?

Before trying to dial out of the system it's best to first confirm that system can accept incoming calls.

Share this post


Link to post

The inbound side is answering, however we are still experiencing a few issues. 

Issue 1: Sometimes when we stop the VG service, we are unable to restart it. I've attached logs of this experience "Logs Failed Starts".

Issue 2: We are using a VPN client to connect to one of the data sources (SIP is not running through the VPN). Rebooting server, VG starts and answers calls fine. We start the VPN and calls work for a short while and then stop. We reduced the config VoIP Expires to 60 and if we restart the VG service after starting the VPN, this appears to fix the issue. However if the VPN disconnects or is stopped, inbound calls stop being detected. We reconnect the VPN, restart VG and this works again or we often experience Issue 1 and have to reboot.  

Issue 3: Outbound calls are not working through the SIP provider. We've added a second provider and tried both without success. I put through a number of test calls, both inbound with a dial and conference (blind) and using the outbound dialer. Most appeared to fail straight away, however at the very end after restarting VPN and VG, one seemed to work but I couldn't hear anything on the line. 

If you think we should open multiple threads, please just let me know.  

Thanks in advance for your assistance. 

Logs_Failed_Starts.zip

Logs_Outbound_&_Calls_Stop.zip

RTFLogs.zip

Share this post


Link to post

Please try stopping and starting the Dialogic service before starting VoiceGuide.

Easiest way to do this is to just always also stop the Dialogic service after stopping the VoiceGuide service.

See if this resolves the issue on your system.

What is the server brand/model used?

 

Looks like you are using Windows 10 on this system. You will need to ensure that this system never goes into 'Sleep' or any other power saving modes that would stop system from working. It's best to use a Server version of Windows if deploying a system that needs to be active 24/7.

 

It also looks like you are trying to use both Twilio and Voippro trunks on our system.

Suggest to begin with only working with one trunk to begin with (Twilio) and get that working before trying ot get another trunk working as well.

Can you configure system it to just use Twilio trunk, and then make a test call into and out of system and post all traces. We can then confirm that the SIP Registration works ok and calls are received and made ok.

Share this post


Link to post

The server is a Dell OptiPlex 3080. We've removed the Voippro trunks, stopped and restarted VG and Dialogic. I believe we've disabled all sleep related functions but will double check. 

Please find outbound test call attached. We tried blind conference and an outbound dialer. The conference stayed up until timeout but no call connected or rang at the other end. The dialer dropped the call straight away. 

I checked Twilio log and the outbound call request is not showing there.

Logs attached.

Logs.zip

Share this post


Link to post

To start off, it looks like the SIP Registration is not working as expected on this system.

HMP is issuing a SIP Register request but is getting no response back of any sort.

See attached screenshot from your WireShark trace. See how there are no responses at all from the SIP Trunk provider (Twilio).

Are you using IP based routing/authentication to have incoming calls arrive at your system?

Recommend contacting your SIP Trunk provider (Twilio) and resolving this issue first. Forwarding them this screenshot should assist them in identifying what is happening.

 

SECURITY NOTE: Please change the password used on the SIP account after posting any WireShark traces that capture successful SIP registrations. If password is too simple it can be cracked from the posted WireShark trace. Recommend using SIP passwords that are at least 16 characters long and are a mix of random upper-case and lower-case letters, numbers, and special characters.

 

image.thumb.png.bd4dff77d823b206d59979ca44dcc4e0.png

Share this post


Link to post

VoiceGuide traces show that for the SIP Authentication a user with username "mivamss" was specified:

110515.951   9                     LoadConfigXml voip authentication read into idx=0: realm:, identity:, username:mivamss, ******

"mivamss" name was not used in the "407 Proxy Authentication Required" response from Twilio, so looks like HMP could not match up the authentication entry with the 407 request, and hence could not proceed with any response.

Suggest contacting Twilio to see why your username was not set in Twilio's 407 response.

image.thumb.png.c9cd18b179e1d78ac88a55694d2cc19e.png

Share this post


Link to post

It looks like the CallerID set when placing the outgoing call is not specified in a valid SIP URI format.

ktTel trace shows:

972 110655.426  7280   3   1 NOTE  Dial_CallerIDToSend not a valid sip uri: [mivamss] clearing Dial_CallerIDToSend. (and Dial_CallerIDToSend does not contain 'From:/Contact:')

Do you have a telephone number associated with this trunk ? That number (and rest of it's SIP URI) may need to be used her, and a corresponding matching authentication entry set.

 

Alternatively, setting up IP based authentication with the SIP trunk provider may be the simplest approach .

Share this post


Link to post

Thanks. Yes we have telephone numbers associated with the trunk. How do we setup the Callerid, is this done with RVs in the script?

Share this post


Link to post

Are you able to make outbound calls when just loading the outgoing cal into the Dialer?

ie. Not 'tromboned' transfer call, but just a single outgoing call?

 

For information on how to set call options on simple outgoing VoIP calls please see: https://www.voiceguide.com/vghelp/source/html/dial_voip.htm

and for information on how to set headers in outgoing legs of a transferred call see "Dial and Conference on VoIP" section on this page https://www.voiceguide.com/vghelp/source/html/modxfer.htm

Share this post


Link to post

Outbound calls with dialer are not working. Only inbound calls are working, they are being sent to the IP address of the IVR server. 

We added callerid (of a number on the SIP account) and tested outbound via dialer, logs attached. 

Logs.zip

Share this post


Link to post

Hello support,

 

I think I'm going backwards. The IVR is not receiving any inbound calls, I've restarted and also restarted Dialogic and VG and I thought I put everything back to the way it was, without success.

Trace shows Twilio is responding with 403 Forbidden. Cause: There is an ACL on your trunk and you are sending us INVITE requests from an IP address not on that ACL.

However I've confirmed our external IP is in their ACL list. It's also the same address they have been sending us calls on previously. I did a lookup and confirmed it is still the same. I'm not aware of anything else changing.  

Hoping logs may shed some light on what has happened. 


Thanks. 

Logs.zip

Share this post


Link to post

With the way Twilio Elastic Trunks work currently, you only set the IP based Authentication.

Do not set any 'Credentials' at all. Do not even create any Credentials in Twilio's "Credential List" section.

See attached screenshots.

Then you will need to ensure that all your networking devices between the server running VoiceGuide and your internet provider equipment will route all IP packets from the IP addresses listed in Twilio's "Networking Information' page towards the server running VoiceGuide, and then the Firewall on that server must let those IP addresses through to allow those packets to reach VoiceGuide.

The SIP REGISTER packets issued by VoiceGuide if you have the Registration entry set up in Config.xml will result in **TEMPORARY** routes being set up in your networking devices' NAT tables - but those NAT entries will time out once the SIP REGISTERs stop being resent. So you need to hard set the routes in whatever networking devices you have on site through which the SIP traffic will go.

You do need to set any Registration or Authentication entries in VoiceGudie's Config.xml at all.

Twilio right now uses IP based authentication only, and it looks like even setting Credentials will stop it working altogether...(?)

 

And on outgoing calls you also need to set the CallerID in the Call Options field. Like this:

<CallerID>+6125551111@yourtrunkname.pstn.twilio.com</CallerID>

where +6125551111 is to be replaced by whatever telephone number is associated with this trunk.

Otherwise you will see the "Invalid Caller ID" reply from Twilio in WireShark.

Best if that caller ID point to your nearest Twilio POP. As you are in Sydney, Australia the address would be:

<CallerID>+6125551111@yourtrunkname.pstn.sydney.twilio.com</CallerID>

and the number to be dialed should also go through your nearest POP. So in your case when using Sydney, Australia the number would be dialed using:

+6125552222@yourtrunkname.pstn.sydney.twilio.com

And of course replace "yourtrunkname" with the name of your trunk.

Screenshot 2022-04-22 at 19-00-03 Elastic SIP Trunking Twilio.png

Screenshot 2022-04-22 at 19-09-12 Elastic SIP Trunking Twilio.png

Screenshot 2022-04-22 at 19-14-40 Elastic SIP Trunking Twilio.png

Share this post


Link to post

Thanks for the update. I was able to remove the VoIP Authorisation but when I remove VoIP Registration entries, inbound calls stop coming through. I assume this means the NAT is not correctly setup. Would this also stop outbound calls from working?

Share this post


Link to post

Hi Support, 

We can see invites from Twilio coming in to the server, but the IVR is not answering. We've removed all the entries for VoIP registration and authentication. I've included both the wiretrace log which shows the incoming invites, and the config file. Can you please confirm we have configured it correctly and how we should proceed.

Thanks,

Ben

 

Logs.zip

Share this post


Link to post

Please .ZIP up and post the ktTel trace log as well as Dialogic's RTF log that captures the incoming call attempt.

We can the see what is happening on this system and advise.

The Dialogic RTF log files are in directory: "C:\Program Files (x86)\Dialogic\log\"

Share this post


Link to post

Inbound is now working with no Registration in the config, however outbound is still not playing nice. We've added the callerid to the options and also tried variations on the outbund number without any success. Logs attached.

Logs.zip

Share this post


Link to post

There are a number of calls in the traces so not sure which one we are supposed to be looking at.

Looks like on the outbound calls captured the numbers specified do not have the "+" in front of them.

With Twilio both the number dialed and the Caller ID must have the "+" at the front. ie:

+61893472719@mivamss.pstn.sydney.twilio.com

and similar for the CallerID.

Share this post


Link to post

Sorry was trying a number of different number formats, I did try with the + multiple times as well. However here is an example, correctly formatted as above. The wiretrace log shows the VG module you need to look for. Those other calls are coming in from an unknown IP address, appear to be malicious SIP attempts. The only calls to examine are the ones that run through our MSS script. 

Logs.zip

Share this post


Link to post

Looking through Wiretrace after conducting various outbound call attempts and Wiretrace has no SIP requests that correspond with these outgoing call requests. Inbound calls show up, as do the responses to them.

I've tried turning the server firewall off and retesting but no SIP entries in Wiretrace log for the ethernet adaptor or VPN. Wiretrace sees nothing relating to outbound calls. I've turned off VPN and retested, same result. As a confirmation of this, Twilio logs also show nothing relating to outbound call requests from our IVR.  

Tested both the script based dial & conference module and the outbound call loader with same results, no SIP requests showing in Wiretrace. 

Is there anything else we can try? Really need to get the outbound calls working as this is a replacement for an ISDN server that is about to stop working as it comes to end of life in a few days. 

Share this post


Link to post

Update: Changed the dial and conference to a blind transfer and that works. We are able to connect the inbound caller to another number, which resolves our most pressing issue. We still need to be able to use the outbound call loader, but replacing the ISDN can now proceed. 

 

So remaining issue is to get the Outbound Call Loader working. Currently no SIP traffic is showing in Wiretrace for these calls. 

Share this post


Link to post

Can you please stop both the VoiceGuide and Dialogic services and then start them both, start WireShark , and make two calls - one that uses the transfer that works and the second that uses the transfer that you are having problems with. Then post the latest vgEngine trace and the ktTel and WireShark traces. We can then see what is happening on this system.

 

Share this post


Link to post

The outgoing leg of the 'Blind Dial and Connect' to +61284045998@mivamss.sip.sydney.twilio.com is rejected by the SIP trunk provider.

The SIP Trunk Provider (Twilio) is replying with a "403 Forbidden", and the call is then dropped (see screenshot below)

Usually Twilio provides error details in the "403 Forbidden" reply but looks like in this case there is no further information.

Twilio offers logs to let you better see what happened on each call. Log into your Twilio account and go to: https://www.twilio.com/console/sip-trunking/logs/calls

The "Trunk Terminating" direction calls are the calls from your system out to the external number. Find the problem call and click on that Calls SID link to see more details about what happened. You can also the click on the "Debug Event SID" to get more verbose information. SIP PCAP Log is also available there to let you confirm that this is the same call.

If you can post a screenshot of page shown when you click the "Debug Event SID" link then we should see what the issue is.

 

image.thumb.png.9fa5a593ef70b59d9ef5c50d909dbb18.png

 

 

Share this post


Link to post

Also, we would recommend changing the number associated with this service. ie. recommend that you buy a  new number form Twilio and associate that new number with your trunk, and stop using the old one.

In cases where IP ACL + 'CallerID' type authentication is used for making outgoing calls we recommend changing the number used as the "CallerID" before posting any traces from your system on any public forum.

Share this post


Link to post

More questions:

Can you dial the +61284045998 number OK from other normal phones?

Can you dial the +61284045998 number when just loading it into the VoiceGuide Dialer? (make sure to set the <CallerID> in the Call Options). ie. Have no other calls on system and just load one outgoing call to +61284045998@mivamss.sip.sydney.twilio.com

Have you deleted al the Credential List entries?

Share this post


Link to post

Twilio's documentation says that "403 Forbidden responses to your INVITE" is caused by:

"sending us INVITE requests from an IP address not on that ACL"

or

"There is a Credentials List on your trunk, and your INVITE’s Authentication Digest is incorrect due to wrong username/password "

See:  https://www.twilio.com/docs/sip-trunking/troubleshooting#problem2

 

The ACL (Access Control List) is created on this page:

"Elastic SIP Trunking" -> "Manage" -> "IP access control lists"

and the ACL is then assigned to trunk in that trunk's "Termination" configuration page.

Share this post


Link to post

We've gone with another SIP provider for outbound calls and I'm happy to report we have got that working.  

 

However, twice now the IVR service has shut down, and it appears to be related to a memory issue. I've attached logs from one of the instances.

 

vg75_MIVA7_2022-05-22_01-11-59.zip

Share this post


Link to post

Please .ZIP and post the ktTel trace from that day (22nd May), and from the day when the second instance occurred.

Share this post


Link to post

Please update system to this version of VoiceGuide:

[deleted]

Looks like there was an issue with a SIP Header component on some calls sent into this system that were not handled correctly. This new version should handle this case.

Edited by SupportTeam
link removed. changes are now included in main release version

Share this post


Link to post

In both problem cases the incoming calls that were the issue were sent to the system from a local address, not from the main VoIP provider used for this system.

On the 25th May the problem call showed the FROM header of: 10001@139.216.79.236 and TO header of: 80018042038478@139.216.79.236

On the 22nd the problem call showed the FROM header of: 101@139.216.79.236 and TO header of: 101@139.216.79.236

And the problem header was later on in the headers sent on those calls.

The other 2500+ calls that the traces captured arriving from Twilio during the trace time were all handled with no problems.

Share this post


Link to post

Traces show many strange calls on this system - that hangup immediately when answering them is attempted. The problem was caused by one of those calls.

See attached list.

Looks like your router/firewall is allowing external SIP INVITES from sources other then your incoming calls SIP provider (Twilio) - opening this system to hacking attempts that we see here in the traces from 22nd and 25th May.

This Twilio document lists what IP addresses Twilio uses and you should only allow initiated SIP connections from those addresses:

https://www.twilio.com/docs/sip-trunking/ip-addresses

WireShark should be able to show from what IP addresses the other calls arrive from. If IP addresses are getting spoofed you may want to setup a VPN connection to Twilio.

 

suspect_calls_may_22_25.txt

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
×