First of all I have already taken a look at similar questions such as :
https://serverfault.com/questions/392979/asterisk-sip-2-0-401-unauthorized
or
https://serverfault.com/questions/574166/asterisk-401-unauthorized-when-trying-to-register-sip-clients
yet they do not apply to my situation or the solutions do not solve my issue.
I have one asterisk 1.8 box sitting on site A .
Site A has a public static IP and a local class c network 192.168.1.X , asterisk is behind NAT.
Some phones are on the same local network, while others are in site B.
Site B has another public static IP and a local class c network 192.168.2.X.
So, phones on site B are behind nat aswell.
Strangely, some phones on site B are able to register, while others not.
The most interesting example is one grandstream gxp 2100.
This phone has 3 accounts with the following configuration configurations :
[1000]
deny=0.0.0.0/0.0.0.0
secret=xxxxxx
dtmfmode=rfc2833
canreinvite=no
context=from-internal
host=dynamic
trustrpid=yes
sendrpid=no
type=friend
nat=yes
port=5060
qualify=3000
qualifyfreq=60
transport=udp
encryption=no
callgroup=
pickupgroup=
dial=SIP/1000
mailbox=1000#device
permit=0.0.0.0/0.0.0.0
callerid=TONY - Lab Line 1 <1000>
callcounter=yes
faxdetect=no
cc_monitor_policy=generic
[3000]
deny=0.0.0.0/0.0.0.0
secret=xxxxxxx
dtmfmode=rfc2833
canreinvite=no
context=from-internal
host=dynamic
trustrpid=yes
sendrpid=no
type=friend
nat=yes
port=5060
qualify=3000
qualifyfreq=60
transport=udp
encryption=no
callgroup=
pickupgroup=
dial=SIP/3000
mailbox=3000#device
[9000]
deny=0.0.0.0/0.0.0.0
secret=xxxxxxxxxxx
dtmfmode=rfc2833
canreinvite=no
context=from-internal
host=dynamic
trustrpid=yes
sendrpid=no
type=friend
nat=yes
port=5060
qualify=3000
qualifyfreq=60
transport=udp
encryption=no
callgroup=
pickupgroup=
dial=SIP/9000
mailbox=9000#device
Only account 1000 and 3000 are able to register, while account 9000 encounters the following error:
<--- SIP read from UDP:95.254.61.X:5064 --->
REGISTER sip:95.231.94.6 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.190:5064;branch=z9hG4bK1380984150;rport
From: <sip:9000#95.231.94.6>;tag=1294836145
To: <sip:9000#95.231.94.6>
Call-ID: 844020207-5064-1#BJC.BGI.C.BJA
CSeq: 2672 REGISTER
Contact: <sip:9000#192.168.2.190:5064>;reg-id=3;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000B8251202A>"
X-Grandstream-PBX: true
Max-Forwards: 70
User-Agent: Grandstream GXP2100 1.0.5.23
Supported: path
Expires: 3600
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0
<------------->
--- (14 headers 0 lines) ---
Sending to 95.254.61.X:5064 (NAT)
<--- Transmitting (NAT) to 95.254.61.X:5064 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.2.190:5064;branch=z9hG4bK1380984150;received=95.254.61.248;rport=5064
From: <sip:9000#95.231.94.6>;tag=1294836145
To: <sip:9000#95.231.94.6>;tag=as54ceb003
Call-ID: 844020207-5064-1#BJC.BGI.C.BJA
CSeq: 2672 REGISTER
Server: FPBX-2.10.1(1.8.21.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="47737672"
Content-Length: 0
<------------>
What do you think is causing this issue?
Thank you in advance for your kind support and help!
That is normal behavour of asterisk
Asterisk answer as UNATHORIZED with NEW nonce packet. After that client have answer again with md5sum calculated with that nonce.
Very likly in your case client NOT receive that packet for some reason(incorrect nat setup, firewall etc)
Related
I am trying to send DTMFs through SIPp. Since the play_pcap_audio action was not 100% reliable, I wanted to construct SIP INFO messages to make my tests more robust, however when I send INFO packets I get 501 - Not implemented response from Asterisk.
If I set my softphone to use SIP INFO for sending DTMFs, that works fine, so I am assuming it has to do with the messages I am sending. However comparing the actual messages did not reveal any difference.
The INVITE I send:
INVITE sip:*203#192.168.200.208:5060 SIP/2.0
Via: SIP/2.0/UDP 172.17.0.2:5060;branch=z9hG4bK-234-1-7;rport
From: sipp <sip:2018005#192.168.200.208>;tag=1
To: <sip:*203#192.168.200.208:5060>
Call-ID: 1-234#172.17.0.2
CSeq: 4 INVITE
Contact: sip:2018005#172.17.0.2:5060
Authorization: //auth header omitted
Max-Forwards: 70
Allow: OPTIONS, SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO
Content-Type: application/sdp
Content-Length: 195
v=0
o=user1 53655765 2353687637 IN IP4 172.17.0.2
s=-
c=IN IP4 172.17.0.2
t=0 0
m=audio 8192 RTP/AVP 0
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
and the INFO message:
INFO sip:192.168.200.208:5060 SIP/2.0
Via: SIP/2.0/UDP 172.17.0.2:5060;branch=z9hG4bK-234-1-16
Max-Forwards: 70
Contact: <sip:2018005#172.17.0.2:5060;transport=UDP>
To: <sip:*203#192.168.200.208:5060>
From: "sipp" <sip:2018005#192.168.200.208>;tag=1
Call-ID: 1-234#172.17.0.2
CSeq: 5 INFO
User-Agent: SIPp docker
Authorization: // auth header omitted
Content-Length: 22
Signal=1
Duration=160
I have made sure it's not to do with the dtmfmode configuration in Asterisk.
One thing I noticed is when Asterisk responds to INVITE, it contains the following header:
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
I would expect INFO to be here - but again, it's the same when using the softphone and it all works.
What other areas could affect the processing of SIP INFOs?
Any help would be much appreciated on further debugging.
Turned out to be a problem with SIP dialogs.
The tags (+ a call-id) identify a dialog. After an INVITE is sent the UAS responds with an OK, sticking a remote tag to the To: field. Every subsequent request has to use the same tags (local and remote + call-id) to refer to the same dialog. This can be achieved by sticking [last_To:] into the header when using a SIPp scenario, so that we get the correct remote tag:
<send>
<![CDATA[
ACK sip:[field3]#[remote_ip]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: <sip:[field0]#[field1]>;tag=[call_number]
[last_To:]
Call-ID: [call_id]
CSeq: [cseq] ACK
Contact: sip:[field0]#[local_ip]:[local_port]
Max-Forwards: 10
Content-Length: 0
]]>
</send>
In the above case an ACK is sent back from the UAC and the dialog is established. Now when we send the INFO, we have to refer to the same dialog (by setting the correct tags) and it all works.
Interestingly, when not setting these values properly, pjsip gives 501 Not Implemented, whereas chan_sip responds with 481 Call/Transaction Does Not Exist which is much more accurate.
I have the enviroment that have an PSTN > GATEWAY (CME) . So I would like to know how to set the Asterisk to understand the dial-peer from the cisco. Somebody did this ?.
I did try to set the sip.conf to
[4000]
allowguest=yes
defaultuser=4000
nsecure=port,invite
bindport=5060
type=peer ; I did try change to "friend" as well, but the same problem.
port=5060
host=172.16.101.25
context=Plan1
insecure=yes
canreinvite=yes
qualify=yes
I did get a return from cisco.
<--- SIP read from UDP:172.16.101.25:53054 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.101.43:5060;branch=z9hG4bK0bfec330
From: "asterisk" <sip:asterisk#172.16.101.43>;tag=as26306981
To: <sip:172.16.101.25>;tag=65E9F470-228A
Date: Thu, 22 Oct 2015 16:05:13 GMT
Call-ID: 100fe7696c5adbf3170c02ff799d7539#172.16.101.43:5060
Server: Cisco-SIPGateway/IOS-12.x
CSeq: 102 OPTIONS
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Accept: application/sdp
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Content-Type: application/sdp
Content-Length: 170
v=0
o=CiscoSystemsSIP-GW-UserAgent 8815 8188 IN IP4 172.16.101.25
s=SIP Call
c=IN IP4 172.16.101.25
t=0 0
m=audio 0 RTP/AVP 18 0 8 9 4 2 15
c=IN IP4 172.16.101.25
<------------->
--- (14 headers 7 lines) ---
Really destroying SIP dialog '100fe7696c5adbf3170c02ff799d7539#172.16.101.43:5060' Method: OPTIONS
The Cisco gateway send the REGISTER but asterisk donĀ“t receive.
No firewalls or any rules.
Sorry for my poor english.
I'm not sure the problem is on the Asterisk side, might be config missing on the cisco side.
If you want phone calls delivered from the cisco gateway to asterisk here is the config on the cisco side you need:
dial-peer voice 6000 voip
destination-pattern 6...
session protocol sipv2
session target ipv4:172.16.101.43
This will send all 4 digit numbers starting with 6 to asterisk. Should be enough to get traffic flowing from cisco gateway to asterisk. Change destination-pattern to match the dial-plan on asterisk for the numbers you want delivered there. dot is a single digit wildcard, [] is used for collection of numbers to match.
If the gateway IOS is version 15 or later you will need to add the asterisk ip to the ip address trusted list also
voice service voip
ip address trusted list
ipv4 172.16.101.43
If you want/need to specify asterisk as a sip-ua on the cisco gateway you would do so under sip-ua in the cisco gateway config. This is where you would specify credentials used to register on asterisk. Here is a list of possible commands needed there.
sip-ua
credentials username <username> password <password> realm <sip domain>
authentication username <username> password <password> realm <sip domain>
registrar ipv4:172.16.101.43
sip-server ipv4:172.16.101.43
I was trying to setup instant messaging in asterisk server. For the client i'm using Blink Softphone. I did add to my sip.conf
[general]
accept_outofcall_message=yes
outofcall_message_context=dialplan_name
auth_message_requests=yes
and to my extensions.conf
[dialplan_name]
exten => _XXX,1,MessageSend(sip:${EXTEN},"${CALLERID(name)}"${MESSAGE(from)})
So this is a simple extension for testing. But when i try and send the message from user1 to user2 i get in the asterisk log:
[Jan 30 21:17:47] WARNING[6420][C-00000005]: chan_sip.c:10515 process_sdp: Insufficient information in SDP (c=)...
What can be wrong here? I'am sure that the clients are on the nat, so i do have both nat=force_rport,comedia for all my users in sip.conf
My asterisk version is 13 (latest).
[UPDATED]
I turned on the sip debug log, and tried to send the message (first i get some weird retransmission):
Retransmitting #9 (no NAT) to 14.228.14.150:5070: <- weird ip here
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 14.228.14.150:5070;branch=z9hA4cA-abcdef613aca8b1x3124abb0z3e1bc8;received=14.228.14.150;rport=5070
From: 2014<sip:2014#(server_ip_here)>;tag=a312facc
To: 0009735466221178<sip:0009735466221178#(server_ip_here)>;tag=bb62441233
Call-ID: abcdef613aca8b1x3124abb0z3e1bc8
CSeq: 1 INVITE
Server: Asterisk PBX 13.1.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="2222abcf"
Content-Length: 0
Then
<--- SIP read from TLS:(my_ip_here):49312 --->
INVITE sip:123#(server_ip_here) SIP/2.0
Via: SIP/2.0/TLS (my_ip_here):49312;rport;branch=b4ae88b115be15a5n9244;alias
Max-Forwards: 70
From: "user1" <sip:user1#server_ip_here>;tag=39e388fd5f616b7
To: <sip:123#(server_ip_here)>
Contact: <sip:12313560#(server_ip_here):49311;transport=tls>
Call-ID: ac48128192za12a2f432e24c18aabc7q
CSeq: 28982 INVITE
Allow: SUBSCRIBE, NOTIFY, PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER
Supported: 100rel, replaces, norefersub, gruu
User-Agent: Blink 0.9.1.2 (Windows)
Content-Type: application/sdp
Content-Length: 308
v=0
o=- 3211422221 3211422221 IN IP4 (my_ip)
s=Blink 0.9.1.2 (Windows)
t=0 0
m=message 2855 TCP/TLS/MSRP *
c=IN IP4 (my_ip)
a=path:msrps://(my_ip):2855/37a1cc82ab315e21b222;tcp
a=accept-types:message/cpim text/* application/im-iscomposing+xml
a=accept-wrapped-types:*
a=setup:active
<------------->
--- (13 headers 10 lines) ---
Sending to (my_ip):49312 (NAT)
Sending to (my_ip):49312 (NAT)
Using INVITE request as basis request - ad72cd1681aff769721af12c21aaea7c
Found peer 'user1' for 'user1' from (my_ip):49312
== Using SIP VIDEO CoS mark 6
== Using SIP RTP CoS mark 5
[Jan 31 21:02:17] WARNING[27265][C-00000118]: chan_sip.c:10515 process_sdp: Insufficient information in SDP (c=)...
arheops was right! Using INVITE request as basis request <- here it is. Instead of MESSAGE for some reason INVITE request is used.
Looks like your softphone use INVITE instead of MESSAGE for messaging.
You can get more info by enable sip debug in asterisk console
asterisk -r
sip set debug on
I'm trying to get Asterisk working with Bahnhof IP telephony provider here in Sweden. They don't officially support third party solutions but that have never stopped me before.
Anyhow to the nitty gritty, the VoIP linux (Debian 7) running Asterisk 11.5.1 has the public IP on interface eth1, the firewall (iptables) is fully opened between the box and Bahnhof VoIP servers. Incoming calls are working. Outgoing are not as shown in the log below. I've search the web from top to bottom and have zip about this issue.
I have another provider (CellIP) which works just fine with these same settings, I've never received any 404 messages like below from them.
sip.conf
...
[bahnhof]
type=peer
defaultuser=55500XXXXXX
fromuser=55500XXXXXX
context=default
secret=mypassword
host=bahnhof-lda.soho1.voip.bahnhof.net
fromdomain=bahnhof-lda.soho1.voip.bahnhof.net
insecure=port,invite
qualify=yes
canreinvite=no
dtmfmode=rfc2833
...
extensions.conf
...
[010XXXXXXX-out]
exten => _0X.,1,Set(CALLERID(num)=55500XXXXXX)
exten => _0X.,n,Dial(SIP/${EXTEN}#bahnhof,30,trg)
exten => _0X.,n,Hangup()
...
SIP DEBUG
<------------>
Audio is at 10060
Adding codec 0x100 (g729) to SDP
Adding codec 0x2 (gsm) to SDP
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x8 (alaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (no NAT) to 77.240.208.105:5060:
INVITE sip:0700XXXXXX#bahnhof-lda.soho1.voip.bahnhof.net SIP/2.0
Via: SIP/2.0/UDP 81.170.XXX.XXX:5060;branch=z9hG4bK4db8a605
Max-Forwards: 70
From: "0700XXXXXX" <sip:55500XXXXXX#bahnhof-lda.soho1.voip.bahnhof.net>;tag=as5eaad2ef
To: <sip:0700XXXXXX#bahnhof-lda.soho1.voip.bahnhof.net>
Contact: <sip:55500XXXXXX#81.170.XXX.XXX:5060>
Call-ID: 498e8f9616aadc0a658b301909fe58d7#bahnhof-lda.soho1.voip.bahnhof.net
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.8.11.0
Date: Wed, 16 Oct 2013 15:18:57 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 360
v=0
o=root 495353330 495353330 IN IP4 81.170.195.158
s=Asterisk PBX 1.8.11.0
c=IN IP4 81.170.XXX.XXX
t=0 0
m=audio 10060 RTP/AVP 18 3 0 8 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
---
<--- SIP read from UDP:77.240.208.105:5060 --->
SIP/2.0 100 Trying
User-Agent: Centile-Supra/1
CSeq: 102 INVITE
Via: SIP/2.0/UDP 81.170.XXX.XXX:5060;branch=z9hG4bK4db8a605
Content-Length: 0
From: "0700XXXXXX" <sip:55500XXXXXX#bahnhof-lda.soho1.voip.bahnhof.net>;tag=as5eaad2ef
To: <sip:0700XXXXXX#bahnhof-lda.soho1.voip.bahnhof.net>
Call-ID: 498e8f9616aadc0a658b301909fe58d7#bahnhof-lda.soho1.voip.bahnhof.net
<------------->
--- (8 headers 0 lines) ---
<--- SIP read from UDP:77.240.208.105:5060 --->
SIP/2.0 404 No domain-name found in requestURI:0700XXXXXX
User-Agent: Intraswitch/7.5.6.4.SR4-SNAPSHOT_SCF-8
CSeq: 102 INVITE
Via: SIP/2.0/UDP 81.170.XXX.XXX:5060;branch=z9hG4bK4db8a605
Content-Length: 0
Record-Route: <sip:77.240.208.105;lr>
From: "0700XXXXXX" <sip:55500XXXXXX#bahnhof-lda.soho1.voip.bahnhof.net>;tag=as5eaad2ef
To: <sip:0700XXXXXX#bahnhof-lda.soho1.voip.bahnhof.net>;tag=e67fec39-f749-59b4-4b8f-c798e694a64b
Supported: replaces, 100rel, timer
Server: Intraswitch/7.5.6.4.SR4-SNAPSHOT_SCF-8
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, MESSAGE, PRACK, REFER, INFO, SUBSCRIBE, NOTIFY
Contact: <sip:0700XXXXXX#77.240.208.19:5061>
Call-ID: 498e8f9616aadc0a658b301909fe58d7#bahnhof-lda.soho1.voip.bahnhof.net
The obvious error is "SIP/2.0 404 No domain-name found in requestURI:0700XXXXXX", however the underlying condition causing this is not at all obvious to me :]
Note, all XXX's are real values masked for obvious reasons.
Any help or ideas to try is greatly appreciated!
SOLVED - UPDATE 2013-10-19
The issue is now solved, the operator Bahnhof (in Sweden) has a similar setup to Sipgate. This means there is very little flexibility in how you configure the REGISTER and Trunk. A small mistake here which would not affect the general SIP provider has major impact here, perhaps this is a high security strategy from Bahnhof and Sipgate. In short having a bad register will prevent you from making outbound calls.
It came down to this in sip.conf,
Bad register: register => 55500XXXXXX:mypassword#bahnhof/2000
OK register: register => 55500XXXXXX:mypassword#bahnhof/55500XXXXXX
Then in extensions.conf,
[default]
exten => 55500XXXXXX,1,Goto(010XXXXXXX-in,s,1)
Now outbound calls work, however here is where Bahnhof is acutally even more tricky then Sipgate, Bahnhof has a cluster of SIP servers where a inbound call can originate from any of them. When Asterisk resolves bahnhof-lda.soho1.voip.bahnhof.net it simply takes the first ip address and considers this the SIP peer. The problem is that a inbound SIP call can come from any of the six addresses and not only the address you registered at.
The solution would be to add [bahnhof-peer-01], [bahnhof-peer-2] ... entries for each ip address,
[bahnhof-peer-01]
type=peer
context=default
host=77.240.208.19
insecure=port,invite
canreinvite=no
dtmfmode=rfc2833
[bahnhof-peer-02]
type=peer
context=default
host=77.240.208.20
insecure=port,invite
canreinvite=no
dtmfmode=rfc2833
...
OR
Simply set in sip.conf,
[general]
context=default
allowguest=yes
alwaysauthreject=yes
extensions.conf,
[default]
; Incoming calls on SE line 010XXXXXXX (steered from "register" section)
exten => 55500XXXXXX,1,Goto(010XXXXXXX-in,s,1)
; NOTHING MORE UNDER default
[extensions]
...
This would allow any incoming calls to be accepted, even unauthenticated ones. One might see this as a security risk but I have all VoIP traffic tightly locked down by firewall rules so this is the solution I went with. Also, as long as you have the context set to default in [general] and you have a proper setup with nothing under the [default] context except the inbound extension you will be fine. Anonymous inbound calls will have no access to you trunks or extensions, only access to inbound extensions which they obviously will need to know (55500XXXXXX) to get through to your inbound rules for your Bahnhof number.
So finally, this solution enabled both outbound and inbound calls via the Bahnhof SIP provider. Technically what seems to happen when you use the username as the extension on the register line is that this forces a Digest Auth towards the SIP server when an outbound call is made. This in turn seems to satisfy the SIP server with the domain-name part in the URI. This is not completely clear to me in relevance but obviously plays a part.
I am new to freeswitch world, I have been hacked somebody used my gateway and initialize a call from an unregistered user without any authentication , as i gues (after i test it by my self) , if i send an UDP invite packet to the freeswitch server using nc command in linux as the following:
$ nc -u x.x.x.x 5060 < invite
invite file contain the following :
INVITE sip:+99xxxxxxx#x.x.x.x SIP/2.0
Via: SIP/2.0/UDP x.x.x.x:5060
Max-Forwards: 70
To: Bob <sip:+99xxxxxx#xxx.xxx.xxx.xxx>
From: Alice <sip:101#x.x.x.x>;tag=1928301774
Call-ID: a84b4c76e66710#pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:101#192.168.15.50>
Content-Type: application/sdp
Content-Length: 142
v=0
o=ibc 1090098764 894503441 IN IP4 192.168.1.33
s=-
c=IN IP4 192.0.2.200
t=0 0
m=audio 33445 RTP/AVP 98 97 8 0 3 101
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=zrtp
i found the following :
the user 101 is unregistred user and have no authintication header in the packet , even that the freeswitch allow the call through my gateway .
so is there any way to authinticate the caller username and password before originate the call through the gateway?
My first guess would be checking sofia.conf.xml
look for
<param name="accept-blind-auth" value="true"/>
Here you have more details on sip authentication in FS:
http://wiki.freeswitch.org/wiki/Sofia_Configuration_Files#Auth
In a vanilla (default example) config freeswitch have two SIP profiles. First, named internal, listening on port 5060 and there authentication of packets is required. Second SIP profile, named external, listening on port 5060 and there authentication is not required to do call throw it. Security of external profile must be provided by your dialplan. If it`s not, then hacker can talk to freeswitch with INVITE, which command to make freeswitch call throw your gateway and bridge it with initial call.
i agree with #borik-bobrujskov , just expanding the same answer.
In sip_profiles/external.xml add the following options
<param name="auth-calls" value="true"/>
<param name="accept-blind-auth" value="false"/>
<param name="log-auth-failures" value="true"/>
<param name="auth-all-packets" value="true"/>
this will ensure that a proxy auth challenge like below is send back for every incoming sip request
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK4d5f.11c7cfacce4d26c8fd1b01339c08b1dc.0
From: "1001"<sip:100#x.x.x.x;transport=TCP>;tag=18aa565e
To: <sip:200#y.y.y.y:5080;pstn_inbound=;ignore_userinfo=>;tag=eX6m9Ktp48aaF
Call-ID: ZwRgsMB3luEHyKaM2vL9eQ..
CSeq: 1 INVITE
User-Agent: FreeSWITCH-mod_sofia/1.9.0-742-8f1b7e0~64bit
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Proxy-Authenticate: Digest realm="x.x.x.x", nonce="e797bde2-c7b5-47a7-ae95-931af57c9774", algorithm=MD5, qop="auth"
Content-Length: 0
It is not upto the UA to, reconstruct another INVITE ( with CSeq-2) with proxy Authorisation header containing digest , username , realm , nonce etc to resent to freeswitch server to authenticate and proceed with call
Proxy-Authorization: Digest username="aaa", realm="x.x.x.x", nonce="e797bde2-c7b5-47a7-ae95-931af57c9774", uri="sip:200#x.x.x.x5:5080;pstn_inbound=;ignore_userinfo=", qop=auth, nc=00000001, cnonce="4060286812", response="cae451f24bbbcefeb7d01c13b070026a", algorithm=MD5
if you use "param name="accept-blind-auth" value="true"" will gives you blind authentication.
without password authentication.