488 Not Acceptable Here on Incoming Calls

FreePBX Providers
, ,
1

Hey everyone,

I currently have FreePBX 15 / Asterisk 17 setup and mostly working. Outgoing calls is properly functioning. Calls between extensions also works perfectly. The issue is that Incoming Calls/Origination don’t work. All the communication seems fine, but the FreePBX server is responding to the Twilio server in this case with a “488 Not Acceptable Here”. I’ve checked that I have codecs in common, and that encryption settings are correct. Outgoing calls have no issues.

The only real hint seems to be this error in the Asterisk log:

[2021-04-28 07:16:50] ERROR[1314]: res_pjsip_session.c:934 handle_incoming_sdp:  anonymous: Couldn't negotiate stream 0:audio-0:audio:sendrecv (nothing)

I’ve left the above error in the request log below so the order of events are preserved.

Here is the pjsip history print out for a summary:

No.   Timestamp  (Dir) Address                  SIP Message                        
===== ========== ============================== ===================================
00000 1619594210 * <== 192.168.201.20:26125     INVITE sip:[email protected];transport=tls;region=us1 SIP/2.0
00001 1619594210 * ==> 192.168.201.20:26125     SIP/2.0 100 Trying
00002 1619594210 * ==> 192.168.201.20:26125     SIP/2.0 488 Not Acceptable Here
00003 1619594210 * <== 192.168.201.20:26125     ACK sip:[email protected];transport=tls;region=us1 SIP/2.0

Here is the logs (I’ve obfuscated some information):

<--- Received SIP request (1596 bytes) from TLS:192.168.201.20:26125 --->
INVITE sip:[email protected];transport=tls;region=us1 SIP/2.0
Record-Route: <sip:54.172.60.0:5061;transport=tls;r2=on;lr>
Record-Route: <sip:54.172.60.0;r2=on;lr>
CSeq: 1 INVITE
From: <sip:[email protected]>;tag=57848935_6772d868_8fcd078b-2979-4af5-af87-4tert535yr3yre
To: <sip:[email protected];transport=tls;region=us1>
Max-Forwards: 65
X-OhSip-Sas-Id: ce52038e-106d-490b-a36d-4g4ff345t
X-OhSIP-Servlet: SipCallOut
X-OhSIP-Remote-Test-Id: sip-call-out_3364
X-OhSIP-Test-Params: {"request_uri":"sip:[email protected]"}
Diversion: <sip:[email protected]>;reason=unconditional
Call-ID: [email protected]
Via: SIP/2.0/TLS 54.172.60.0:5061;branch=z9hG4bK04b6.a4deb99b323fdsdf4g522d3a31e98635.0
Via: SIP/2.0/UDP 172.25.89.198:5060;rport=5060;branch=z9hG4bK8fcd078b-2979-4af5-af87-a64743721673_6772d868_431-10982788592345641489
Contact: <sip:[email protected]:5060;transport=udp>
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,NOTIFY
User-Agent: Twilio Gateway
X-Twilio-AccountSid: ACe03671ace6f4f849dfe5c363c6246545
Content-Type: application/sdp
X-Twilio-CallSid: CAe79a965bfbe6bd4ab67de524719cd8765
Content-Length: 361

v=0
o=root 309348332 309348332 IN IP4 172.18.146.83
s=Twilio Media Gateway
c=IN IP4 34.203.251.159
t=0 0
m=audio 10244 RTP/SAVP 0 8 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:HboccKn2v8m3QR6RaNAoZ2LtMFslAIk0DFVC342
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:20
a=sendrecv

<--- Transmitting SIP response (657 bytes) to TLS:192.168.201.20:26125 --->
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 54.172.60.0:5061;rport=26125;received=192.168.201.20;branch=z9hG4bK04b6.a4deb99b323fdsdf4g522d3a31e98635.0
Via: SIP/2.0/UDP 172.25.89.198:5060;rport=5060;branch=z9hG4bK8fcd078b-2979-4af5-af87-a64743721673_6772d868_431-10982788592345641489
Record-Route: <sip:54.172.60.0:5061;transport=tls;lr;r2=on>
Record-Route: <sip:54.172.60.0;lr;r2=on>
Call-ID: [email protected]
From: <sip:[email protected]>;tag=57848935_6772d868_8fcd078b-2979-4af5-af87-a64743721673
To: <sip:[email protected];region=us1>
CSeq: 1 INVITE
Server: FPBX-15.0.17.32(17.9.3)
Content-Length:  0

[2021-04-28 07:16:50] ERROR[1314]: res_pjsip_session.c:934 handle_incoming_sdp:  anonymous: Couldn't negotiate stream 0:audio-0:audio:sendrecv (nothing)

<--- Transmitting SIP response (711 bytes) to TLS:192.168.201.20:26125 --->
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/TLS 54.172.60.0:5061;rport=26125;received=192.168.201.20;branch=z9hG4bK04b6.a4deb99b323fdsdf4g522d3a31e98635.0
Via: SIP/2.0/UDP 172.25.89.198:5060;rport=5060;branch=z9hG4bK8fcd078b-2979-4af5-af87-a64743721673_6772d868_431-10982788592345641489
Record-Route: <sip:54.172.60.0:5061;transport=tls;lr;r2=on>
Record-Route: <sip:54.172.60.0;lr;r2=on>
Call-ID: [email protected]
From: <sip:[email protected]>;tag=57848935_6772d868_8fcd078b-2979-4af5-af87-a64743721673
To: <sip:[email protected];region=us1>;tag=c84eb84f-9160-4989-b101-81fbc1a4c695
CSeq: 1 INVITE
Server: FPBX-15.0.17.32(17.9.3)
Content-Length:  0


<--- Received SIP request (457 bytes) from TLS:192.168.201.20:26125 --->
ACK sip:[email protected];transport=tls;region=us1 SIP/2.0
CSeq: 1 ACK
From: <sip:[email protected]>;tag=57848935_6772d868_8fcd078b-2979-4af5-af87-a64743721673
To: <sip:[email protected];region=us1>;tag=c84eb84f-9160-4989-b101-81fbc1a4c695
Max-Forwards: 65
Call-ID: [email protected]
Via: SIP/2.0/TLS 54.172.60.0:5061;branch=z9hG4bK04b6.a4deb99b323fdsdf4g522d3a31e98635.0
Content-Length: 0

Any help would be greatly appreciated!

2

Twilio is saying ‘encryption is mandatory for this call’, but the path (anonymous?) chosen by pjsip does not permit encryption, so the call fails.

My first thought is that the Match (Permit) field of your trunk does not include all the addresses from which Twilio can send calls (apparently 54.172.60.0 in this case), so the call was not associated with your Twilio trunk. See IP Addresses for SIP Services | Twilio .

However:

WTF is going on here? Twilio obviously didn’t send the INVITE from a private address. Do you have some sort of SBC or SIP proxy intentionally in the path? Or is your router/firewall doing an unwanted SIP ALG, even on a TLS connection?

If intentional and required, you would have to add 192.168.201.20 to your Match (Permit) field (which would preclude having trunks from other providers). If unwanted, set your firewall to not stick its nose into your SIP traffic.

If you still have trouble, temporarily set Twilio to not encrypt, so the call gets further and you can understand from the log, why it’s taking the wrong path.

3

Thank you for that explanation. I now think I understand what exactly is going wrong.

WTF is going on here?

I’m trying to get this working going via ingress-nginx in a kubernetes deployment. I’m using UDP and TCP passthrough right now, but it doesn’t seem to save/pass the source IPs properly.

I might simply have to drop to host networking. I was hoping to get the proxies working for kubernetes based high availability(minimal down time).

4

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.