Testing SIP Server

01/12/2022 03:06 AM

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

01/12/2022 09:11 PM

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

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.

01/12/2022 11:55 PM

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?

01/13/2022 06:21 AM

Thanks for your assistance, DTMF issue resolved.

Please find wireshark trace attached using Linphone with successful registration and making a call out.

Wireshark_Linphone.zip

01/13/2022 09:20 PM

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 01/13/2022 09:31 PM by SupportTeam

01/14/2022 02:25 AM

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

01/14/2022 02:51 AM

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?

01/14/2022 08:10 AM

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....

03/30/2022 11:34 PM

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

03/31/2022 03:39 AM

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

03/31/2022 04:08 AM

Please find logs attached. We attempted a call out (rather than a call in) is that fine?

Logs.zip

03/31/2022 06:25 AM

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

03/31/2022 10:25 PM

Dialogic RTF logs attached.

Logs.zip

04/01/2022 04:35 AM

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

04/01/2022 05:07 AM

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

04/01/2022 06:08 AM

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

04/01/2022 06:48 AM

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.

04/13/2022 07:46 AM

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

04/13/2022 08:47 AM

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.

04/14/2022 01:21 AM

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

04/14/2022 01:41 AM

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.

04/14/2022 03:52 AM

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.

04/14/2022 07:51 AM

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 .

04/17/2022 12:06 AM

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

04/19/2022 03:12 AM

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

04/19/2022 06:12 AM

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

04/20/2022 12:38 AM

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

04/22/2022 09:50 AM

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.

04/25/2022 01:27 PM

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?

04/25/2022 10:51 PM

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

04/26/2022 02:22 AM

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\"

04/26/2022 02:59 AM

They didn't appear to update from the test call. Attached now.

Logs.zip

04/26/2022 03:37 AM

Is the firewall on your PC/Server set to allow incoming SIP and RTP through?

See the "Firewall Configuration" section on this page: https://www.voiceguide.com/vghelp/source/html/install_v7_dialogichmp.htm

WireShark will see traffic on the network 'before' the Windows' Firewall...

04/27/2022 04:10 AM

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

04/27/2022 04:53 AM

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.

04/27/2022 06:13 AM

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

04/28/2022 12:53 AM

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.

04/28/2022 02:40 AM

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.

04/28/2022 04:10 AM

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.

04/28/2022 06:14 AM

Logs attached. The Wiretrace log shows you what to search for. The first works, the second doesn't.

Logs.zip

05/09/2022 12:29 AM

Any further suggestions we can try? The outbound dialler is key to growing the service.

05/10/2022 09:05 AM

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.

05/10/2022 09:12 AM

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.

05/10/2022 09:22 AM

Testing SIP Server

Recommended Posts

Miva

Share this post

Link to post

SupportTeam

Share this post

Link to post

SupportTeam

Share this post

Link to post

Miva

Share this post

Link to post

SupportTeam

Share this post

Link to post

Miva

Share this post

Link to post

SupportTeam

Share this post

Link to post

SupportTeam

Share this post

Link to post

Miva

Share this post

Link to post

SupportTeam

Share this post

Link to post

Miva

Share this post

Link to post

SupportTeam

Share this post

Link to post

Miva

Share this post

Link to post

SupportTeam

Share this post

Link to post

Miva

Share this post

Link to post

SupportTeam

Share this post

Link to post

SupportTeam

Share this post

Link to post

Miva

Share this post

Link to post

SupportTeam

Share this post

Link to post

Miva

Share this post

Link to post

SupportTeam

Share this post

Link to post

SupportTeam

Share this post

Link to post

SupportTeam

Share this post

Link to post

Miva

Share this post

Link to post

SupportTeam

Share this post

Link to post

Miva

Share this post

Link to post