SIP Trunk Registration Issue with BTCL (No Response from 10.200.10.4)

FreePBX Providers
,
1

:pushpin: FreePBX Version: 17
:pushpin: Asterisk Version: 21
:pushpin: SIP Protocol Used: PJSIP / Chan_SIP
:pushpin: Firewall/NAT Setup: Mikrotik Router

Issue:
I have successfully configured a SIP trunk with another provider (A), but BTCL (B provider) is not registering. The trunk shows “Rejected”, and logs show “No response from sip:10.200.10.4:5060”.

BTCL Credentials Provided:
Username: [email protected]
SIP Server IP: 10.200.10.4
Port: 5060
SIP Debug Logs:
[2025-02-12 18:47:07] WARNING[2200] res_pjsip_outbound_registration.c: No response received from ‘sip:10.200.10.4:5060’ on registration attempt to ‘sip:[email protected]:5060’, retrying in ‘60’

Asterisk CLI Log:
BTCL/sip:10.200.10.4:5060 BTCL Rejected (exp. 42s)

What I’ve Tried:
Used [email protected] as the username.
Set from domain=ims.btcl.net.bd.
Checked network reachability (ping 10.200.10.4).
Verified firewall rules on Mikrotik (iptables & NAT rules).
Disabled SIP ALG (/ip firewall service-port set sip disabled=yes).

Can someone suggest how to register this trunk correctly?

2

I know nothing about BTCL, but for other IMS systems you would use something like:

Username: +88024110XXXX
SIP Server: ims.btcl.net.bd
Outbound Proxy: sip:10.200.10.4\;lr\;hide
From Domain: ims.btcl.net.bd
From User: (same as Username)

(note backslash semicolon in two places)

If no luck, at the Asterisk command prompt type
pjsip set logger on
wait for a registration retry, and post the Asterisk log for the attempt.

3

Do you have some connection with this provider to be on the same non-public space? Because that IP in the outbound proxy isn’t routable over the public Internet.

4

Sure, but the OP said he could ping it, so I assumed that BTCL is also his ISP.

5

ICMP or UDP ping?

User names containing @ are problematic. In any case, no response indicates a lower level problem, generally packet are not arriving at their destination, in one direction or other, possibly because Via headers are wrong, and rport isn’t being forced. If user names were wrong, there should be a response, probably 403 Forbidden.

6

May be relevant: PBXact Ignoring phones on a specific subnet and therefore they cannot register - #4 by Lutiana

7

So it turns out that Sangoma’s support stuff uses 10.200.xx.yy for something, and when the support VPN is on, they push down a route to this subnet on their end.

So check your routes on the PBX (cli: route -n) and see if this is there:

10.200.0.0 172.16.0.1 255.255.255.0 UG 0 0 0 tun0

If it is, then that would be your problem. Change the SIP server IP (if you can) to something else out side of 10.200.0.0/24 and you should be ok.

8

net-tools is deprecated in current OS’ and replaced by iproute2, so

ip route

if route -n doesn’t work

9

Good point, and just for reference the output for ip route for the support VPN would look like this:

10.200.0.0/24 via 172.16.0.1 dev tun0

10

then you would need to make sure you have a specific route

ip route --help

beween those two networks for traffic to flow

1 Like
11

This is how my network is working.
image

12

I tried ICMP. It’s fine, i have checked all the network issues. The problem is the username with the domain name. I think for the username trunk is not being registered.

13

So you can ping 10.200.10.4 from the PBX? Or were you pinging from the router?

14

From the PBX and also from my lan side I can ping the server ip.

15

I checked the network side, I can reach the SIP server from the PBX and also from my LAN side.

16

Sir, I have already made a bridge on the Mikrotik router.

17

Then sngrep would exposes all the traffic getting to your PBX host machine (but not necessarily through your firewall to your PBX) both SIP and SDP, compare the traffic with what the mikrotik sees

https://help.mikrotik.com/docs/spaces/ROS/pages/8323088/Packet+Sniffer

18

Assuming you are using the Mikrotik device as a router, Mikrotik routers by default have a SIP ALG helper enabled. Have you tried disabling it?

19

You should be trying with a UDP ping.

20

That is not consistent with the “no response” symptom.