Unable to configure outbound calls to PSTN

Status
Not open for further replies.
A

ashwinikumar29

New Member
Nov 18, 2019
11
0
1
30
Hi

I have configured FusionPBX on ubuntu machine with two network interfaces -
One interface is connected to WAN/Office LAN and other is connected to SIP LAN network. I created new internal SIP profile so that the freeswitch makes connection to both my network interfaces.
I am able to receive calls on agents SIP client configured in FusionPBX when someone called our support number.
The issue is, I am not able to make that call to the agent mobile number. Also when agent tried calling customer number via SIP Client then that calls get rejected.
I created an outbound routes as well but from the logs it seems like the call from agent gets terminated by treating it as inbound call.

The documentation of FusionPBX does not explain the configuration for calls over PSTN.
It would be great if someone explain me how can I make calls to agent phone number when customer calls the support number and how agent can call the customer number from SIP Client.

I am doing this for the first time and it would be great if someone help me in achieving in this.

Thanks
Ashwini
 
Adrian Fretwell

Adrian Fretwell

Well-Known Member
Aug 13, 2017
1,412
376
83
Most of the time this is caused by the regexp for the condition statement in the outbound route not matching what the user is dialing to make the call. If the dialed digits do not match an outbound route, the call will be classified as internal.

You may have some additional complications with your two NICs, but as long as they are on different subnets and your external profile is pointing to the subnet with access to the WAN, you should not have too much trouble.
 
A

ashwinikumar29

New Member
Nov 18, 2019
11
0
1
30
Adrian Fretwell said:
Most of the time this is caused by the regexp for the condition statement in the outbound route not matching what the user is dialing to make the call. If the dialed digits do not match an outbound route, the call will be classified as internal.

You may have some additional complications with your two NICs, but as long as they are on different subnets and your external profile is pointing to the subnet with access to the WAN, you should not have too much trouble.
Click to expand...

I checked logs but there is nothing that compares regex with outbound route regex. Call from SIP Client to customer number are treated as inbound call and after that it hangs up.

Also, both of my NIC are on different subnet and the external profile is configured with the subnet with access to WAN.


PFA of outbound routes and inbound routes. Let me know if I configured it incorrectly.
 

Attachments

  • outbound_dialplan.png
    outbound_dialplan.png
    41.5 KB · Views: 35
  • inbound_routes.png
    inbound_routes.png
    31.1 KB · Views: 34
  • inbound_internal.png
    inbound_internal.png
    45.5 KB · Views: 30
Adrian Fretwell

Adrian Fretwell

Well-Known Member
Aug 13, 2017
1,412
376
83
So what are to dialing that should make the outbound route?

From looking at your regexp you must have a 9, it can optionally be prefixed with a + and can optionally be followed by a 1, then 10 digits must follow in order to match.
 
A

ashwinikumar29

New Member
Nov 18, 2019
11
0
1
30
I have attached the detailed logs when I tried calling to external number - +9183760XXXXX via SIP client agent - 100.
 

Attachments

  • outbound_logs.txt
    22.4 KB · Views: 12
DigitalDaz

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,043
565
113
You have added something you shouldn't to the Access Control List

2019-11-26 11:38:57.732661 [DEBUG] sofia.c:10208 IP 192.168.6.42 Approved by acl "domains[]". Access Granted.

The domains ACL is only for adding carriers in.
 
A

ashwinikumar29

New Member
Nov 18, 2019
11
0
1
30
Right now, I am doing development so allowed all urls for now. But how this configuration have an impact on making outbound calls? I didn't get that point.
 
DigitalDaz

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,043
565
113
The domains ACL is for carriers so whatever is in there gets treated as in inbound call so that is what is happening, the dumber you are dialing gets treated as a did number, it doesn't find one matching that so it hangs up the call.

Basically, it thinks the extension is a carrier and processes it as such.
 
  • Like
Reactions: Adrian Fretwell
A

ashwinikumar29

New Member
Nov 18, 2019
11
0
1
30
DigitalDaz said:
The domains ACL is for carriers so whatever is in there gets treated as in inbound call so that is what is happening, the dumber you are dialing gets treated as a did number, it doesn't find one matching that so it hangs up the call.

Basically, it thinks the extension is a carrier and processes it as such.
Click to expand...

Okay, I will try this and let you know.
 
A

ashwinikumar29

New Member
Nov 18, 2019
11
0
1
30
I changed my ACL, now when I called external number from SIP Client, the call was treated as outbound call but it gives 403 error now. Attached the logs.
 

Attachments

  • outbound_logs.txt
    70.2 KB · Views: 5
Adrian Fretwell

Adrian Fretwell

Well-Known Member
Aug 13, 2017
1,412
376
83
You appear to now have two capturing groups in the regexp for your outbound route:
Code: 
Dialplan: sofia/internal/100@192.168.6.2 Regex (PASS) [TATA-POE.91d10] destination_number(+9183760XXXXX) =~ /^\+?(91)?(\d{10})$/ break=on-false

Which is probably why you are only sending the digits 91 to your gateway:
Code: 
Dialplan: sofia/internal/100@192.168.6.2 Action bridge(sofia/gateway/950771e9-79ff-41df-9e6f-8999e8eca92f/91)
 
A

ashwinikumar29

New Member
Nov 18, 2019
11
0
1
30
I did that because I want 91 to come together that's why I added bracket. Even after removing the bracket, it still throws 403 Forbidden. Attached logs.
Now, bridge shows the correct number -
Code: 
Dialplan: sofia/internal/100@192.168.6.2 Action bridge(sofia/gateway/950771e9-79ff-41df-9e6f-8999e8eca92f/83760XXXXX)
 

Attachments

  • outbound_logs.txt
    55.2 KB · Views: 2
Adrian Fretwell

Adrian Fretwell

Well-Known Member
Aug 13, 2017
1,412
376
83
The call now looks to being placed correctly on the gateway by 192.168.6.2.

The invite is received by 10.50.185.2 which initially responds with a 100 Trying and then a 403 Forbidden. The clue may be in the Warning header:
Warning: 399 10.50.185.2:5060 "Registration Cache Entry Not Found"

This suggests that the end point you are calling is not registered or possibly does not exist at all on 10.50.185.2
 
A

ashwinikumar29

New Member
Nov 18, 2019
11
0
1
30
Adrian Fretwell said:
The call now looks to being placed correctly on the gateway by 192.168.6.2.

The invite is received by 10.50.185.2 which initially responds with a 100 Trying and then a 403 Forbidden. The clue may be in the Warning header:
Warning: 399 10.50.185.2:5060 "Registration Cache Entry Not Found"

This suggests that the end point you are calling is not registered or possibly does not exist at all on 10.50.185.2
Click to expand...


Can you please elaborate this issue?

My internal configurations are -
I have two network interfaces on ubuntu machine, 10.50 belongs to SIP provider network and 192.168 belongs to our office network.
The 10.50.187.202 IP was configured as external-rtp-ip/external-sip-ip/rtp-ip/sip-ip on FusionPBX by creating another internal SIP profile and also configured the SIP IP - 10.50.185.2 as gateway.
Now, in this case, the agent with extension 100 makes a call to external number +9183760XXXXX.

I really needed some directions to work on.
 

Attachments

  • gateway.png
    gateway.png
    24.2 KB · Views: 17
  • internal_tata.png
    internal_tata.png
    36.4 KB · Views: 17
  • sip_profile.png
    sip_profile.png
    67.4 KB · Views: 15
A

ashwinikumar29

New Member
Nov 18, 2019
11
0
1
30
ashwinikumar29 said:
Can you please elaborate this issue?

My internal configurations are -
I have two network interfaces on ubuntu machine, 10.50 belongs to SIP provider network and 192.168 belongs to our office network.
The 10.50.187.202 IP was configured as external-rtp-ip/external-sip-ip/rtp-ip/sip-ip on FusionPBX by creating another internal SIP profile and also configured the SIP IP - 10.50.185.2 as gateway.
Now, in this case, the agent with extension 100 makes a call to external number +9183760XXXXX.

I really needed some directions to work on.
Click to expand...

Agent also shown as connected on SIP Client. Attached images.
 

Attachments

  • linphone_conf.png
    linphone_conf.png
    120.8 KB · Views: 8
  • linphone_connected.png
    linphone_connected.png
    120.7 KB · Views: 8
DigitalDaz

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,043
565
113
I think at this point you need to speak to your carrier, its the carrier that's rejecting the call. You need to ask them why.
 
  • Like
Reactions: Adrian Fretwell
Adrian Fretwell

Adrian Fretwell

Well-Known Member
Aug 13, 2017
1,412
376
83
I completely agree with DigitalDaz.

I don't understand why you need the second internal profile. You have two networks. 192.168.* for your private LAN and 10.50.* on your WAN or Provider network.

Can you not just set ext-rtp-ip and ext-sip-ip in your internal profile to 192.168.6.2 and ext-rtp-ip and ext-sip-ip in your external profile to 10.50.187.202.
 
A

ashwinikumar29

New Member
Nov 18, 2019
11
0
1
30
No, I cannot. 192.168.* network is on our WAN and 10.50.* is on private LAN provided by carrier. We can only access the PBX server via 192.168.* network. So setting ext-rtp-ip/ext-sip-ip to 10.50.* on external profile won't work because we can not access that network externally. Hope you understand.

@DigitalDaz I will send the below code to our carrier and update the response here.


Code: 
   SIP/2.0 403 Forbidden
   From: "Ashwini"<sip:61211600@10.50.185.2>;tag=6tQUtBpFjm8SN
   To: <sip:83760XXXXX@10.50.185.2>;tag=BN1614993255-0-1574851875-647207415
   Call-ID: c07bc0c2-8ba5-1238-908b-484d7eb5e572
   CSeq: 12871947 INVITE
   Warning: 399 10.50.185.2:5060 "Registration Cache Entry Not Found"
   Reason: SIP;cause=403;text="Subsystem Id: ICALLLEG Cause Code: Forbidden_403"
   Via: SIP/2.0/UDP 10.50.187.202;rport=5060;branch=z9hG4bK9Xgveay1SZeNc
   Content-Length: 0
 
Status
Not open for further replies.
Top Bottom