Found out about Asterisk CLI and installed it.
Debug sip.
Here I can se the calls comming in with INVITE, but some ACK with NAT get errorcode 401.
Something refuse to take it the last step.
CLI SIP DEBUG:
<------------->
[2016-07-28 22:14:36] VERBOSE[1679] chan_sip.c: — (13 headers 0 lines) —
[2016-07-28 22:14:36] VERBOSE[1679] chan_sip.c: Really destroying SIP dialog ‘[email protected]:5060’ Method: OPTIONS
[2016-07-28 22:14:47] VERBOSE[1679] chan_sip.c:
<— SIP read from UDP:62.80.216.2:5060 —>
INVITE sip:[email protected]:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 62.80.216.2:5060;branch=z9hG4bK-524287-1—8a86d04b08139d3f;rport
Max-Forwards: 70
Contact: sip:[email protected]
To: "045234567"sip:[email protected]:5060;user=phone
From: "070823456"sip:[email protected];user=phone;tag=90c0cf25
Call-ID: hWYwDBOIXS4a6mFOjtx__Q…
CSeq: 1 INVITE
Session-Expires: 3600;refresher=uac
Min-SE: 3600
Allow: INVITE, ACK, BYE, CANCEL
Content-Type: application/sdp
Supported: timer
User-Agent: LEICA-1.8.39-RC3
X-Ecan: On
Content-Length: 444
v=0
o=- 47381316 0 IN IP4 88.131.198.35
s=Cisco SDP 0
c=IN IP4 88.131.198.35
t=0 0
m=audio 38948 RTP/AVP 8 18 0 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sqn:0
a=cdsc: 1 audio RTP/AVP 8 18 0 101
a=cdsc: 5 image udptl t38
a=cpar: a=T38FaxVersion:0
a=cpar: a=T38FaxRateManagement:transferredTCF
a=cpar: a=T38FaxMaxDatagram:160
a=cpar: a=T38FaxUdpEC:t38UDPRedundancy
a=X-sqn:0
a=X-cap: 1 image udptl t38
a=sendrecv
<------------->
[2016-07-28 22:14:47] VERBOSE[1679] chan_sip.c: — (16 headers 18 lines) —
[2016-07-28 22:14:47] VERBOSE[1679] chan_sip.c: Sending to 62.80.216.2:5060 (NAT)
[2016-07-28 22:14:47] VERBOSE[1679][C-0000000a] chan_sip.c: Sending to 62.80.216.2:5060 (NAT)
[2016-07-28 22:14:47] VERBOSE[1679][C-0000000a] chan_sip.c: Using INVITE request as basis request - hWYwDBOIXS4a6mFOjtx__Q…
[2016-07-28 22:14:47] VERBOSE[1679][C-0000000a] chan_sip.c: Found peer ‘affinity’ for ‘070823456’ from 62.80.216.2:5060
[2016-07-28 22:14:47] VERBOSE[1679][C-0000000a] chan_sip.c:
<— Reliably Transmitting (NAT) to 62.80.216.2:5060 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 62.80.216.2:5060;branch=z9hG4bK-524287-1—8a86d04b08139d3f;received=62.80.216.2;rport=5060
From: "070823456"sip:[email protected];user=phone;tag=90c0cf25
To: "045234567"sip:[email protected]:5060;user=phone;tag=as242ff9fa
Call-ID: hWYwDBOIXS4a6mFOjtx__Q…
CSeq: 1 INVITE
Server: FPBX-13.0.163(11.22.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="7367e6b6"
Content-Length: 0
<------------>
[2016-07-28 22:14:47] VERBOSE[1679][C-0000000a] chan_sip.c: Scheduling destruction of SIP dialog ‘hWYwDBOIXS4a6mFOjtx__Q…’ in 32000 ms (Method: INVITE)
[2016-07-28 22:14:47] SECURITY[1633] res_security_log.c: SecurityEvent=“ChallengeSent”,EventTV=“1469736887-385124”,Severity=“Informational”,Service=“SIP”,EventVersion=“1”,AccountID="sip:[email protected];user=phone",SessionID=“0x7668cc14”,LocalAddress=“IPV4/UDP/46.59.21.14/5060”,RemoteAddress=“IPV4/UDP/62.80.216.2/5060”,Challenge=“7367e6b6”
[2016-07-28 22:14:47] VERBOSE[1679] chan_sip.c:
<— SIP read from UDP:62.80.216.2:5060 —>
ACK sip:[email protected]:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP 62.80.216.2:5060;branch=z9hG4bK-524287-1—8a86d04b08139d3f;rport
Max-Forwards: 70
To: "045234567"sip:[email protected]:5060;user=phone;tag=as242ff9fa
From: "070823456"sip:[email protected];user=phone;tag=90c0cf25
Call-ID: hWYwDBOIXS4a6mFOjtx__Q…
CSeq: 1 ACK
Content-Length: 0
<------------->
[2016-07-28 22:14:47] VERBOSE[1679] chan_sip.c: — (8 headers 0 lines) —
[2016-07-28 22:15:00] SECURITY[1633] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“1469736900-617897”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x761014bc”,LocalAddress=“IPV4/TCP/127.0.0.1/5038”,RemoteAddress=“IPV4/TCP/127.0.0.1/54950”,UsingPassword=“0”,SessionTV=“1469736900-617880”
[2016-07-28 22:15:02] SECURITY[1633] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“1469736902-148310”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x761014bc”,LocalAddress=“IPV4/TCP/127.0.0.1/5038”,RemoteAddress=“IPV4/TCP/127.0.0.1/54954”,UsingPassword=“0”,SessionTV=“1469736902-148290”
[2016-07-28 22:15:04] SECURITY[1633] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“1469736904-785242”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7661274c”,LocalAddress=“IPV4/TCP/127.0.0.1/5038”,RemoteAddress=“IPV4/TCP/127.0.0.1/54958”,UsingPassword=“0”,SessionTV=“1469736904-785224”
[2016-07-28 22:15:06] SECURITY[1633] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“1469736906-527135”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x7663f4cc”,LocalAddress=“IPV4/TCP/127.0.0.1/5038”,RemoteAddress=“IPV4/TCP/127.0.0.1/54962”,UsingPassword=“0”,SessionTV=“1469736906-527109”
[2016-07-28 22:15:06] SECURITY[1633] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“1469736906-538226”,Severity=“Informational”,Service=“AMI”,EventVersion=“1”,AccountID=“admin”,SessionID=“0x722d197c”,LocalAddress=“IPV4/TCP/127.0.0.1/5038”,RemoteAddress=“IPV4/TCP/127.0.0.1/54966”,UsingPassword=“0”,SessionTV=“1469736906-538202”
Also found this link about no incomming calls and 401 error.
The problem/solution in the link was, secret on extensions should be erased. Should it be no password at all set in the extensions pxb registering then (and also in FreePBX of course)?
Seems like a bit odd, and some insecure. Even more odd since I have a ring group in the inbound route - that should have the incomming call.