SOLVED Next IncrediblePBX on RaspbPi2 Question :-)

[wnpaul]

Update 1: Solution: set trunk to "insecure=very"

Update 2: No surprise, but this also fixed the same problem on my X100.com JS200-FX.

So, I have a USER (201) configured, and a TRUNK, and an incoming rule 's' which should go to EXT 201, but it doesnt.

I have tried this with a pattern of '0' in the incoming rules (because that's obviously what is sent), and it doesn't work either.

What am I missing?

Here are the SIP messages generated as the call comes in and produces a busy signal:

<--- SIP read from UDP:195.137.238.102:5060 --->
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 195.137.238.102;rport;branch=z9hG4bK7Zyy5t4rc0jgN
Route: <sip:[email protected]:1024>
Max-Forwards: 18
From: "0127764" <sip:[email protected]>;tag=0KrDjF4j1meQj
To: <sip:[email protected]>
Call-ID: 0e40ab14-6f6b-1233-c688-00144f2839ae
CSeq: 75169009 INVITE
Contact: <sip:[email protected]:5060>
User-Agent: sip
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Privacy: none
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 279
X-FS-Support: update_display,send_info
P-Asserted-Identity: "0127764" <sip:[email protected]>

v=0
o=FreeSWITCH 1430993365 1430993366 IN IP4 195.137.238.102
s=FreeSWITCH
c=IN IP4 195.137.238.102
t=0 0
m=audio 16782 RTP/AVP 18 8 0 101 13
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

<------------->
--- (19 headers 12 lines) ---
Sending to 195.137.238.102:5060 (no NAT)
Sending to 195.137.238.102:5060 (no NAT)
Using INVITE request as basis request - 0e40ab14-6f6b-1233-c688-00144f2839ae
Found peer 'trunk_1' for '0127764' from 195.137.238.102:5060

<--- Reliably Transmitting (no NAT) to 195.137.238.102:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 195.137.238.102;branch=z9hG4bK7Zyy5t4rc0jgN;received=195.137.238.102;rport=5060
From: "0127764" <sip:[email protected]>;tag=0KrDjF4j1meQj
To: <sip:[email protected]>;tag=as52abf8f0
Call-ID: 0e40ab14-6f6b-1233-c688-00144f2839ae
CSeq: 75169009 INVITE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="49efc9c2"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '0e40ab14-6f6b-1233-c688-00144f2839ae' in 32000 ms (Method: INVITE)

<--- SIP read from UDP:195.137.238.102:5060 --->
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 195.137.238.102;rport;branch=z9hG4bK7Zyy5t4rc0jgN
Route: <sip:[email protected]:1024>
Max-Forwards: 18
From: "0127764" <sip:[email protected]>;tag=0KrDjF4j1meQj
To: <sip:[email protected]>;tag=as52abf8f0
Call-ID: 0e40ab14-6f6b-1233-c688-00144f2839ae
CSeq: 75169009 ACK
Content-Length: 0


<------------->
--- (9 headers 0 lines) ---

<--- SIP read from UDP:10.1.113.104:35499 --->


<------------->
Really destroying SIP dialog '0e40ab14-6f6b-1233-c688-00144f2839ae' Method: ACK
doulos-incrediblepi*CLI>

 

[wnpaul]

Setting the trunk to "insecure=very" fixed the problem ...