Hey.
We’re using FreePBX 13.0.190.19 - I know - it’s outdated, we will make a huge upgrade next month.
I’d like to know how to call to SIP URI. Right know when we’re trying to call to xxx@domain or xxx@ip it doesn’t work (no response).
I’ve checked the logs and I think I know what’s the issue. When we’re calling, FreePBX (or maybe our device) adds @192.168.2.141 (our internal FreePBX IP address) to our SIP URI address. So it basically can’t call.
How can we fix this issue? Do we need to make separate extension or maybe change something in the configuration?
Changing features.redial_via_local_sip_server.enable to 1 or 0 doesn’t work.
Cheers.
Ok I’ve created a custom extention SIP/[email protected] and enabled “Allow Anonymous inbound SIP Calls” and now I think I have a connection.
I’ll check tomorrow and I will close the thread if the issue is solved.
Allowing anonymous calls is a serious security vulnerability. It should not only be unnecessary for an outbound call, it shouldn’t affect them at all. What error did you hear (or see in the log) when you had it off?
A good test SIP URI is [email protected].
Tbh I didn’t check the connection without allowing anonymous calls. I’ve read about it in a topic about SIP URI calls - someone said that it should be enabled.
I’ve disabled that option and I will check the connection tomorrow. Thanks for the feedback!
Little fun fact, all SIP calls are SIP URI calls. sip:user@domain:port ← That is a SIP URI. Your endpoint/device peers (or trunks) tell the PBX what sources and destinations to allow for this. So basically every extension and trunk is saying “I allow callls from these sources/users”.
What that person is referring to is having your PBX open to receive any call without having to know the source IP/host. Which is most cases is not a bright idea.
Still no luck. I’ve got the signal but the endpoint user doesn’t hear any ringing or any signal from me.
[2019-01-29 10:32:51] VERBOSE[12943][C-00000db8] app_dial.c: Called SIP/[email protected]
[2019-01-29 10:33:23] WARNING[2054] chan_sip.c: Retransmission timeout reached on transmission [email protected]:5060 for seqno 102 (Critical Request) – See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 31999ms with no response
[2019-01-29 10:33:23] WARNING[2054] chan_sip.c: Hanging up call [email protected]:5060 - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).
That’s from the logs.
Edit
When I’ve changed the @domain.com to ip address here’s what I get
[2019-01-29 10:35:01] VERBOSE[13531][C-00000dba] app_dial.c: Called SIP/[email protected]
[2019-01-29 10:35:33] VERBOSE[13531][C-00000dba] app_dial.c: SIP/xxx.xxx.xxx.xx-00001ca2 is circuit-busy
[2019-01-29 10:35:33] WARNING[2054] chan_sip.c: Retransmission timeout reached on transmission [email protected]:5060 for seqno 102 (Critical Request) – See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Edit 2
Isnt the problem in “[email protected]:5060” part? Shouldn’t it be our external IP address? We’re using NAT if that’s important.
Testing with the wbdemo:
[2019-01-29 13:29:03] VERBOSE[29628][C-00000dca] app_dial.c: Called SIP/[email protected]
[2019-01-29 13:29:21] VERBOSE[29628][C-00000dca] app_macro.c: Spawn extension (macro-dial-one, s, 51) exited non-zero on ‘SIP/1002-00001cc1’ in macro ‘dial-one’
[2019-01-29 13:29:21] VERBOSE[29628][C-00000dca] app_macro.c: Spawn extension (macro-exten-vm, s, 16) exited non-zero on ‘SIP/1002-00001cc1’ in macro ‘exten-vm’
[2019-01-29 13:29:21] VERBOSE[29628][C-00000dca] pbx.c: Spawn extension (ext-local, 2002, 2) exited non-zero on ‘SIP/1002-00001cc1’
[2019-01-29 13:29:21] VERBOSE[29628][C-00000dca] pbx.c: Executing [h@ext-local:1] Macro(“SIP/1002-00001cc1”, “hangupcall,”) in new stack
[2019-01-29 13:29:21] VERBOSE[29628][C-00000dca] pbx.c: Executing [s@macro-hangupcall:1] GotoIf(“SIP/1002-00001cc1”, “1?theend”) in new stack
[2019-01-29 13:29:21] VERBOSE[29628][C-00000dca] pbx_builtins.c: Goto (macro-hangupcall,s,3)
[2019-01-29 13:29:21] VERBOSE[29628][C-00000dca] pbx.c: Executing [s@macro-hangupcall:3] ExecIf(“SIP/1002-00001cc1”, “0?Set(CDR(recordingfile)=)”) in new stack
[2019-01-29 13:29:21] VERBOSE[29628][C-00000dca] pbx.c: Executing [s@macro-hangupcall:4] Hangup(“SIP/1002-00001cc1”, “”) in new stack
[2019-01-29 13:29:21] VERBOSE[29628][C-00000dca] app_macro.c: Spawn extension (macro-hangupcall, s, 4) exited non-zero on ‘SIP/1002-00001cc1’ in macro ‘hangupcall’
[2019-01-29 13:29:21] VERBOSE[29628][C-00000dca] pbx.c: Spawn extension (ext-local, h, 1) exited non-zero on ‘SIP/1002-00001cc1’
[2019-01-29 13:29:35] WARNING[2054] chan_sip.c: Retransmission timeout reached on transmission [email protected]:5060 for seqno 102 (Critical Request) – See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32000ms with no response
Sorry for the spam guys, I know what’s the problem.
Our device has 2 NIC - one is connected directly to our ISP provider and second one is connected to our firewall. All of the calls are going through the first NIC to our ISP provider - they said they cannot redirect that call to the SIP URI address - which is weird.
I have to do an exception - when we will call to a specific URI it has to go through the second NIC card and our firewall - how can we do that?
Any clues?
Cheers
My first hack at that would be to establish a static route in the network. Instead of using the default route for that IP, you need to set up a static. One thing that is going to get dicey is that you will have two external addresses now, so you may need to do something to support that so that your NAT configuration is correct.
It could be as simple as setting up a trunk for that route, or you may need to set up a special “outbound” context that sets all of the NAT processing up so that the call audio makes it back to your firewall.
Yea that’s what I was thinking about. I didn’t really have much experience in creating static routes tho.
So there are 2 interfaces, eth0 and eth1. Eth1 is connected to the ISP and their firewall/nat, eth0 is connected to our internal network (192.168.2.141). Let’s say I want to call the SIP URI on the 123.123.12.12 address via eth0 interface (everything else is going through eth1).
Should I create a route-eth0 in the network-scripts folder that would look something like:
123.123.12.12/255.255.255.255 via 192.168.2.1 (gateway for 192.168.2.141) dev eth0
which translates into something like connect to A via B on interface eth0
Am I correct?
Ok so I’ve added the static route that pointed the call to given IP address via second NIC, opened the 5060 ports on firewall just for the same address, created a NAT rule which binded our public IP to our internal FreePBX server, added a Custom trunk with their SIP URI and still no luck, same timeout error.
There’s probably something wrong in FreePBX config, but I have no idea what could it be.
I’m stuck guys.
Well why don’t you show a full call attempt and your configs for this. We have no idea what you have in place so we can’t tell you if it is a FreePBX config issue or not without looking at it.
Which config files would you like me to post? Would you like screenshots from the web panel or full .config files? I will provide everything, just tell me which files do you need. Full call attempt is posted above. Nothing has changed.
There isn’t a full call posted as nothing shows a call from the start to the end. You can run sip set debug on and get a full SIP log during the call.
You sip config would be nice to see since it has to deal with how calls are sent.
Thanks, there are some weird things going out there as far as I understand what’s in there.
The thing is, I didn’t set up anything on this server, probably that’s why I am so confused about what’s going on here.
Full SIP Debug: https://pastebin.com/1icgnUF5
I’ve XXXed the IP we want to call and XXXed IP to our ISP (made an adnotation next to it).
sip_general_additional below (sip.config has only include’s in it).
;--------------------------------------------------------------------------------;
; Do NOT edit this file as it is auto-generated by FreePBX. ;
;--------------------------------------------------------------------------------;
; For information on adding additional paramaters to this file, please visit the ;
; FreePBX.org wiki page, or ask on IRC. This file was created by the new FreePBX ;
; BMO - Big Module Object. Any similarity in naming with BMO from Adventure Time ;
; is totally deliberate. ;
;--------------------------------------------------------------------------------;
accept_outofcall_message=yes
auth_message_requests=no
outofcall_message_context=dpma_message_context
faxdetect=no
vmexten=*97
useragent=FPBX-13.0.190.19(13.14.0)
disallow=all
allow=ulaw
allow=alaw
allow=gsm
allow=g726
context=from-sip-external
callerid=Unknown
notifyringing=yes
notifyhold=yes
tos_sip=cs3
tos_audio=ef
tos_video=af41
alwaysauthreject=yes
limitonpeers=yes
context=from-sip-external
rtpend=20000
rtpstart=10000
tcpenable=no
callevents=no
bindport=5060
jbenable=no
notifyringing=yes
allowguest=yes
tlsbindaddr=[::]:5160
tlsclientmethod=sslv2
g726nonstandard=no
srvlookup=no
tlsenable=no
defaultexpiry=120
videosupport=no
maxcallbitrate=384
canreinvite=no
rtptimeout=30
rtpholdtimeout=300
rtpkeepalive=0
minexpiry=60
maxexpiry=3600
registerattempts=0
registertimeout=20
notifyhold=yes
checkmwi=10
nat=force_rport,comedia
ALLOW_SIP_ANON=no
callerid=Unknown
externip=xx.xxx.xxx.xx
language=pl
Doesn’t srvlookup=no should be set to yes?
Thanks!
Why this is set to yes is beyond me. This allows anyone to send calls through/to your system. That should be no.
Reliably Transmitting (NAT) to xxx.xxx.xxx.xx:5060:
Is the other side really behind NAT?
c=IN IP4 192.168.2.141
If this is going over the Internet, you’re going to have audio issues as you’re telling the other side to send RTP to a LAN IP which can’t route over the Internet.
Retransmitting #1 (NAT) to xxx.xxx.xxx.xx:5060:
INVITE sip:[email protected] SIP/2.0
And this is just happening for 6-7 times (the limit) and then it dies. So either the other side isn’t getting your requests or you are not getting their replies.
At this point you’re not using any defined peer to send this call out, you’re using the default Chan_SIP settings which show your system is behind NAT and it’s treating this like a “local call” because it has no other settings to tell it otherwise (like your providers trunk does).
What is the other side that is supposed to get this call?
The other side is using Cisco SX20, it’s a different company so I have no clue how does their setup looks like. All I know is that they have a public IP for SIP URI calls.
OK and have you worked with them to see what is happening? Verify that they are seeing your requests? Anything?
I tried to. Their setup was created by a cisco engineer and their IT guy doesn’t really touch it. He told me today that when we tried to call them this morning there were no hits on their side (confirmed by this cicso guy) so the call probably does not reach them.
Talking with them is like hitting a wall with your head. “Cisco can help us when you will at least be able to connect to our device, and there will be audio or connection problems - but you have to at least connect”.
If the call is not reaching them and they aren’t willing to do anything to help you figure out why, there isn’t much that can be done. You’re getting time out errors and that is something the other side needs to work with you on.