Outgoing call issue

[Jimbob]

Hello,

I have been playing around with Fusionpbx to see if I can get it running. With the help of a few posts and this forum and watching the few youtube vidoes I almost have it running.

The last issue I am stuggling with is an intermittent outbound call problem. I am using sipgate uk to provide the sip trunk and a have followed their asterisk settings guide to set up the gateway in Fusionpbx. Calls inbound work fine. However, I often need to make two call attempts to get the outbound calls to work.

A brief log is shown below:

EXECUTE [depth=0] sofia/internal/1004@tel.domain.com set(outbound_prefix=9)
2023-12-29 14:37:59.483951 91.37% [DEBUG] mod_dptools.c:1671 SET sofia/internal/1004@tel.domain.com [outbound_prefix]=[9]
EXECUTE [depth=0] sofia/internal/1004@tel.domain.com bridge(sofia/gateway/85f528da-ce49-43ed-9b54-b53b8afd7a91/01151234567)
2023-12-29 14:37:59.483951 91.37% [DEBUG] switch_channel.c:1288 sofia/internal/1004@tel.domain.com EXPORTING[export_vars] [domain_name]=[tel.domain.com] to event
2023-12-29 14:37:59.483951 91.37% [DEBUG] switch_channel.c:1288 sofia/internal/1004@tel.domain.com EXPORTING[export_vars] [domain_uuid]=[52d2fc8f-6a56-4f80-9ced-8c8b12cae4f3] to event
2023-12-29 14:37:59.483951 91.37% [DEBUG] switch_channel.c:1288 sofia/internal/1004@tel.domain.com EXPORTING[export_vars] [call_direction]=[outbound] to event
2023-12-29 14:37:59.483951 91.37% [DEBUG] switch_channel.c:1288 sofia/internal/1004@tel.domain.com EXPORTING[export_vars] [call_direction]=[outbound] to event
2023-12-29 14:37:59.483951 91.37% [DEBUG] switch_channel.c:1288 sofia/internal/1004@tel.domain.com EXPORTING[export_vars] [origination_callee_id_name]=[901151234567] to event
2023-12-29 14:37:59.483951 91.37% [DEBUG] switch_ivr_originate.c:2297 Parsing global variables
2023-12-29 14:37:59.483951 91.37% [NOTICE] switch_channel.c:1142 New Channel sofia/external/01151234567 [c50dbbf7-899f-4eb7-bdc7-ba7479a4cf2a]
2023-12-29 14:37:59.483951 91.37% [DEBUG] mod_sofia.c:5110 (sofia/external/01151234567) State Change CS_NEW -> CS_INIT
2023-12-29 14:37:59.483951 91.37% [DEBUG] switch_core_state_machine.c:581 (sofia/external/01151234567) Running State Change CS_INIT (Cur 2 Tot 2)
2023-12-29 14:37:59.483951 91.37% [DEBUG] switch_core_state_machine.c:624 (sofia/external/01151234567) State INIT
2023-12-29 14:37:59.483951 91.37% [DEBUG] mod_sofia.c:97 sofia/external/01151234567 SOFIA INIT
2023-12-29 14:37:59.503923 91.37% [DEBUG] sofia_glue.c:1628 sip:sipconnect.sipgate.co.uk Setting proxy route to sofia/external/01151234567
2023-12-29 14:37:59.503923 91.37% [INFO] sofia_glue.c:1659 sofia/external/01151234567 sending invite call-id: (null)
2023-12-29 14:37:59.503923 91.37% [DEBUG] sofia_glue.c:1662 sofia/external/01151234567 sending invite version: 1.10.10 -release 64bit
Local SDP:
v=0
o=FreeSWITCH 1703836301 1703836302 IN IP4 162.19.xxx.xxx
s=FreeSWITCH
c=IN IP4 162.19.xxx.xxx
t=0 0
m=audio 24378 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=silenceSuppff - - - -
a=ptime:20
a=sendrecv

2023-12-29 14:37:59.503923 91.37% [DEBUG] switch_core_state_machine.c:40 sofia/external/01151234567 Standard INIT
2023-12-29 14:37:59.503923 91.37% [DEBUG] switch_core_state_machine.c:48 (sofia/external/01151234567) State Change CS_INIT -> CS_ROUTING
2023-12-29 14:37:59.503923 91.37% [DEBUG] switch_core_state_machine.c:624 (sofia/external/01151234567) State INIT going to sleep
2023-12-29 14:37:59.503923 91.37% [DEBUG] switch_core_state_machine.c:581 (sofia/external/01151234567) Running State Change CS_ROUTING (Cur 2 Tot 2)
2023-12-29 14:37:59.503923 91.37% [DEBUG] sofia.c:7493 Channel sofia/external/01151234567 entering state [calling][0]
********NORMALLY A LONG PAUSE AT THIS POINT********
2023-12-29 14:37:59.503923 91.37% [DEBUG] switch_core_state_machine.c:640 (sofia/external/01151234567) State ROUTING
2023-12-29 14:37:59.503923 91.37% [DEBUG] mod_sofia.c:158 sofia/external/01151234567 SOFIA ROUTING
2023-12-29 14:37:59.503923 91.37% [DEBUG] switch_ivr_originate.c:67 (sofia/external/01151234567) State Change CS_ROUTING -> CS_CONSUME_MEDIA
2023-12-29 14:37:59.503923 91.37% [DEBUG] switch_core_state_machine.c:640 (sofia/external/01151234567) State ROUTING going to sleep
2023-12-29 14:37:59.503923 91.37% [DEBUG] switch_core_state_machine.c:581 (sofia/external/01151234567) Running State Change CS_CONSUME_MEDIA (Cur 2 Tot 2)
2023-12-29 14:37:59.503923 91.37% [DEBUG] switch_core_state_machine.c:659 (sofia/external/01151234567) State CONSUME_MEDIA
2023-12-29 14:37:59.503923 91.37% [DEBUG] switch_core_state_machine.c:659 (sofia/external/01151234567) State CONSUME_MEDIA going to sleep
2023-12-29 14:37:59.523921 91.37% [DEBUG] sofia.c:7493 Channel sofia/external/01151234567 entering state [calling][0]
2023-12-29 14:38:59.003924 93.20% [NOTICE] switch_ivr_originate.c:3816 Hangup sofia/external/01151234567 [CS_CONSUME_MEDIA] [NO_ANSWER]
2023-12-29 14:38:59.003924 93.20% [INFO] mod_dptools.c:3635 Originate Failed. Cause: NO_ANSWER
2023-12-29 14:38:59.003924 93.20% [NOTICE] switch_channel.c:5012 Hangup sofia/internal/1004@tel.domain.com [CS_EXECUTE] [NO_ANSWER]
2023-12-29 14:38:59.003924 93.20% [DEBUG] mod_hash.c:293 Usage for tel.domain.com_outbound is now 0
2023-12-29 14:38:59.003924 93.20% [DEBUG] switch_core_session.c:2979 sofia/internal/1004@tel.domain.com skip receive message [APPLICATION_EXEC_COMPLETE] (channel is hungup already)

The Fusionpbx gateways settings are as follows:

Gateway: 441151234567
Username: *********
Password: *********
From user: *********
From domain: sipconnect.sipgate.co.uk
Proxy: sipconnect.sipgate.co.uk
Expire Seconds: 600
Register: True
Retry Seconds: 30
Register Transport: udp
Register Proxy: sipconnect.sipgate.co.uk
Outbound Proxy: sipconnect.sipgate.co.uk
Caller ID In From: False
Ping: 20
contact in ping: True
Domain: tel.domain.com
Context: public
Enabled: True
Description: sipgate

The OS is Debian 12 and Fusionpbx is version 5.1.0

Any thoughts on what might need adjusting would be apprciated. I have tried adjusting the gateway settings one by one but nothing seems to resolve this issue so far.

 

[Adrian Fretwell]

This kind of thing is difficult to diagnose without a packet capture. It is possible that on some attempts at the call you may be exceeding the MTU which will result in packet fragmentation.

I notice your Nottingham STD code, look me up I'm Nottingham side of Newark. PM me for my email address, if you want to email a packet capture I will look at it for you.

Cheers Adrian.

 

[Jimbob]

Thank you for the offer of assistance Adrian.

Rather than bothering you over the holiday period I stuck at it and found the issue after learning a couple of sngrep commands. Sipgate was trying to connect to Fusion PBX on udp port 5060, but the external profile was set to port 5080. After a few tweeks to the gateway, adjusting the external sip profile to udp port 5060 and sending FusionPBX server down for a reboot, I got it working.

One question I did want to ask on this forum was that I have also adjusted to internal sip profile to get it off udp port 5060. I assumed that I would have to change the internal sip profile from udp port 5060 to free that port for the external profile, but I don't know if this may have a been a mistake and I perhaps should have just left both the external and internal profiles running on sip udp port 5060?

 

[Adrian Fretwell]

You need to use a different port per SIP profile or you can use the same port but on a different IP address.

Generally people protect 5080 (the gateways port) differently in the firewall and/or ACL so you may need to look at that. Using 5060 for your gateways is no problem the port is really only a number. So maybe move your internal/internal TLS to 5062/5063 - again make sure you adjust the firewall rules accordingly.

 

[Jimbob]

Thanks Adrian. The fusion install script opened ports 5060 to 5091 so I didn't need to adjust the firewall on the server. Do these ports normally get closed down some more on a voip server? I have already had to block a few ip addresses that were having a look at the server!

One other thing I did adjust, in case anyone else is trying to get Sipgate working with Fusion PBX, was following:

-A INPUT -p udp -m udp --dport 15000:32768 -j ACCEPT

I don't know if it was necessary, but Sipgate listed an upper udp port range starting a 15000 somewhere on their website, so I increased the open port range slightly from the FusonPBX installer iptables script.

 

[Adrian Fretwell]

Whatever RTP ports Sipgate use should not have a bearing in the RTP ports that you use, the ports are negotiated together with the codec in the SDP body.

Also if you do want to change the port range to other than default, /etc/freeswitch/autoload_configs/switch.conf.xml will need editing as well as the firewall.

 

[Jimbob]

Thanks Adrian, very helpful.