FreePBX Anveo configuraiton on Static IP

I do have 10000-20000 forward UDP to the PBX server. I have it setup for the speaking clock. The issue is the there are no audio at all. I run this on a cellular network. Looks like I have traffic in and out but no audio.

this is the latest log for Anveo Direct.

/*>>>|174.141.213.62:5060 @ 2026-01-09 06:16:54 */
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 169.48.232.158:5060;branch=z9hG4bK70ed6d736bd93a0d51ff2d9f6f35407e;rport
Max-Forwards: 70
From: <sip:[email protected]>;tag=8c1eb24f2c497328d371ed39a41f10b6
To: <sip:[email protected]>
Call-ID: [email protected]_1-b2b_1
CSeq: 200 INVITE
Contact: Anonymous <sip:[email protected]:5060>
Expires: 300
User-Agent: ACC
cisco-GUID: 3960892066-958964228-2806036863-1761516287
h323-conf-id: 3960892066-958964228-2806036863-1761516287
P-Asserted-Identity: <sip:+13363744673;[email protected]:5060>
P-attestation-indicator: A
P-origination-id: 3f4feb19-ebfd-4423-87ea-a24d3ad4d9c0
X-anveo-e164: 16627800002
Content-Type: application/sdp
Content-Length: 281

v=0
o=Sonus_UAC 496888 688293 IN IP4 67.231.5.112
s=SIP Media Capabilities
c=IN IP4 67.231.5.85
t=0 0
m=audio 42416 RTP/AVP 0 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20

/*<<<|174.141.213.62:5060 @ 2026-01-09 06:16:54 */
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 169.48.232.158:5060;rport=5060;received=169.48.232.158;branch=z9hG4bK70ed6d736bd93a0d51ff2d9f6f35407e
Call-ID: [email protected]_1-b2b_1
From: <sip:[email protected]>;tag=8c1eb24f2c497328d371ed39a41f10b6
To: <sip:[email protected]>
CSeq: 200 INVITE
Server: FPBX-17.0.24(22.6.0)
Content-Length:  0


/*<<<|174.141.213.62:5060 @ 2026-01-09 06:16:54 */
SIP/2.0 200 OK
Via: SIP/2.0/UDP 169.48.232.158:5060;rport=5060;received=169.48.232.158;branch=z9hG4bK70ed6d736bd93a0d51ff2d9f6f35407e
Call-ID: [email protected]_1-b2b_1
From: <sip:[email protected]>;tag=8c1eb24f2c497328d371ed39a41f10b6
To: <sip:[email protected]>;tag=7a7ea371-ef8f-4512-95ed-2618b3d64854
CSeq: 200 INVITE
Server: FPBX-17.0.24(22.6.0)
Contact: <sip:174.141.213.62:5060>
Allow: OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INFO, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length:   280

v=0
o=- 496888 688295 IN IP4 174.141.213.62
s=Asterisk
c=IN IP4 174.141.213.62
t=0 0
m=audio 11752 RTP/AVP 0 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:140
a=sendrecv

/*>>>|174.141.213.62:5060 @ 2026-01-09 06:16:54 */
ACK sip:174.141.213.62:5060 SIP/2.0
Via: SIP/2.0/UDP 169.48.232.158:5060;rport;branch=z9hG4bK0e4aec7ca00d1e18581c190e85bf6981
Max-Forwards: 70
From: <sip:[email protected]>;tag=8c1eb24f2c497328d371ed39a41f10b6
To: <sip:[email protected]>;tag=7a7ea371-ef8f-4512-95ed-2618b3d64854
Call-ID: [email protected]_1-b2b_1
CSeq: 200 ACK
User-Agent: ACC
Content-Length: 0


/*>>>|174.141.213.62:5060 @ 2026-01-09 06:16:57 */
BYE sip:174.141.213.62:5060 SIP/2.0
Via: SIP/2.0/UDP 169.48.232.158:5060;branch=z9hG4bKc0174bcc5abe6a04eb9dc8911efcd6df;rport
Max-Forwards: 70
From: <sip:[email protected]>;tag=8c1eb24f2c497328d371ed39a41f10b6
To: <sip:[email protected]>;tag=7a7ea371-ef8f-4512-95ed-2618b3d64854
Call-ID: [email protected]_1-b2b_1
CSeq: 201 BYE
Contact: Anonymous <sip:[email protected]:5060>
User-Agent: ACC
cisco-GUID: 3960892066-958964228-2806036863-1761516287
h323-conf-id: 3960892066-958964228-2806036863-1761516287
P-Asserted-Identity: <sip:+13363744673;[email protected]:5060>
P-attestation-indicator: A
P-origination-id: 3f4feb19-ebfd-4423-87ea-a24d3ad4d9c0
X-anveo-e164: 16627800002
Content-Length: 0


/*<<<|174.141.213.62:5060 @ 2026-01-09 06:16:57 */
SIP/2.0 200 OK
Via: SIP/2.0/UDP 169.48.232.158:5060;rport=5060;received=169.48.232.158;branch=z9hG4bKc0174bcc5abe6a04eb9dc8911efcd6df
Call-ID: [email protected]_1-b2b_1
From: <sip:[email protected]>;tag=8c1eb24f2c497328d371ed39a41f10b6
To: <sip:[email protected]>;tag=7a7ea371-ef8f-4512-95ed-2618b3d64854
CSeq: 201 BYE
Server: FPBX-17.0.24(22.6.0)
Content-Length:  0

Are you using the mobile providers router/modem as your core or do you have your own router behind it? If you have your own router, you do have the provider’s router in pass-through mode so the WAN’s L3 is directly on your router?

I am using the cradelpoint E320 so i’m not doing the passthrough mode. I could try that I have an asus router but did not think I would need to. Please let me know.

So where are you setting all these firewall rules? Directly on the Cradelpoint or do you have a router behind the Cradelpoint?

I’m doing this within the cradelpoint.

1 Like

I am stumped on this issue with no audio using Anveo Direct. I have made sure that 10000 to 20000 was forwarded to the pbx and I also made sure the firwall was not blocking anything. There were concerns that the codec be checked and only enable ULAW. I have done all of that but still have issues. Any Ideas?

Make sure SIP ALG is disabled in the Cradlepoint

Yet another log of a successful call! 3 seconds duration and cleared by the caller.

Until you provide a log showing a failure, I don’t see how we can help.

I would note that logs from Asterisk are much easier to debug, as we are used to interpreting them.

Please post the relevant FreePBX Firewall rules.

The signalling isn’t the problem here. It’s the RTP, so looking at the signalling for outside of getting the SDP details, is not going to help with the issue.

We need to see an RTP debug from the server:

  1. SSH in
  2. asterisk -r
  3. rtp set debug on
  4. Make call
  5. Get RTP output

I dont have it turned on.

I will do that and get that information. I know the audio goes over 10000-20000 but looks like Anveo was sending out on 8000 which the port rang I have open is 10000-20000. Everything connects but I can’t hear any audio. I have the speaking clock setup so I can hear when it starts working. Anveo Direct is harder to setup since it uses strictly IP addresses no authentication.

The Anveo chooses the port on its side. Your firewall settings should only reflect the Asterisk. Anveo sending from 8000 to Asterisk 10,000 is perfectly OK, or Asterisk sending from Port 10000 to Anveo port 8000 is perfectly normal.

PS I did wonder if it was RTP, but all I was seeing was successful signalling conflicting with a report of failure, without any description of what constituted a failure.

Looks like

  1. Anveo sends RTP to: 174.141.213.62:17128
  2. FreePBX sends RTP to: 67.231.4.7:39786

my free pbc says

2026-01-14 00:35:45] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063177, ts 862289225, len 000160)

15347[2026-01-14 00:35:45] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063178, ts 862289385, len 000160)

15348[2026-01-14 00:35:45] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063179, ts 862289545, len 000160)

15349[2026-01-14 00:35:45] VERBOSE[3760426][C-000004db] file.c: <PJSIP/anonymous-000004da> Playing ‘digits/2.ulaw’ (language ‘en’)

15350[2026-01-14 00:35:45] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063180, ts 862289705, len 000160)

15351[2026-01-14 00:35:45] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063181, ts 862289865, len 000160)

15352[2026-01-14 00:35:45] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063182, ts 862290025, len 000160)

15353[2026-01-14 00:35:45] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063183, ts 862290185, len 000160)

15354[2026-01-14 00:35:45] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063184, ts 862290345, len 000160)

15355[2026-01-14 00:35:45] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063185, ts 862290505, len 000160)

15356[2026-01-14 00:35:45] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063186, ts 862290665, len 000160)

15357[2026-01-14 00:35:45] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063187, ts 862290825, len 000160)

15358[2026-01-14 00:35:45] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063188, ts 862290985, len 000160)

15359[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063189, ts 862291145, len 000160)

15360[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063190, ts 862291305, len 000160)

15361[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063191, ts 862291465, len 000160)

15362[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063192, ts 862291625, len 000160)

15363[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063193, ts 862291785, len 000160)

15364[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063194, ts 862291945, len 000160)

15365[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063195, ts 862292105, len 000160)

15366[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063196, ts 862292265, len 000160)

15367[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063197, ts 862292425, len 000160)

15368[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063198, ts 862292585, len 000160)

15369[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063199, ts 862292745, len 000160)

15370[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] pbx.c: Executing [*60@from-internal:18] Set(“PJSIP/anonymous-000004d9”, “NumLoops=1”) in new stack

15371[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] pbx.c: Executing [*60@from-internal:19] GotoIf(“PJSIP/anonymous-000004d9”, “1?start”) in new stack

15372[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] pbx_builtins.c: Goto (from-internal,*60,8)

15373[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] pbx.c: Executing [*60@from-internal:8] Set(“PJSIP/anonymous-000004d9”, “FutureTime=1768368954”) in new stack

15374[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] pbx.c: Executing [*60@from-internal:9] Set(“PJSIP/anonymous-000004d9”, “FutureTimeMod=4”) in new stack

15375[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] pbx.c: Executing [*60@from-internal:10] Set(“PJSIP/anonymous-000004d9”, “FutureTime=1768368960”) in new stack

15376[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] pbx.c: Executing [*60@from-internal:11] Gosub(“PJSIP/anonymous-000004d9”, “sub-hr12format,s,1()”) in new stack

15377[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] pbx.c: Executing [s@sub-hr12format:1] GotoIf(“PJSIP/anonymous-000004d9”, “1?sub-hr12format,en,1:sub-hr12format,en,1”) in new stack

15378[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] pbx_builtins.c: Goto (sub-hr12format,en,1)

15379[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] pbx.c: Executing [en@sub-hr12format:1] Playback(“PJSIP/anonymous-000004d9”, “at-tone-time-exactly”) in new stack

15380[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Sent RTP packet to 67.231.4.7:3256 (type 00, seq 009844, ts 178165, len 000160)

15381[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] file.c: <PJSIP/anonymous-000004d9> Playing ‘at-tone-time-exactly.ulaw’ (language ‘en’)

15382[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063200, ts 862292905, len 000160)

15383[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063201, ts 862293065, len 000160)

15384[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Sent RTP packet to 67.231.4.7:3256 (type 00, seq 009845, ts 178325, len 000160)

15385[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063202, ts 862293225, len 000160)

15386[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Sent RTP packet to 67.231.4.7:3256 (type 00, seq 009846, ts 178485, len 000160)

15387[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063203, ts 862293385, len 000160)

15388[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Sent RTP packet to 67.231.4.7:3256 (type 00, seq 009847, ts 178645, len 000160)

15389[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063204, ts 862293545, len 000160)

15390[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Sent RTP packet to 67.231.4.7:3256 (type 00, seq 009848, ts 178805, len 000160)

15391[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063205, ts 862293705, len 000160)

15392[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Sent RTP packet to 67.231.4.7:3256 (type 00, seq 009849, ts 178965, len 000160)

15393[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063206, ts 862293865, len 000160)

15394[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Sent RTP packet to 67.231.4.7:3256 (type 00, seq 009850, ts 179125, len 000160)

15395[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Sent RTP packet to 67.231.4.7:3256 (type 00, seq 009851, ts 179285, len 000160)

15396[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063207, ts 862294025, len 000160)

15397[2026-01-14 00:35:46] VERBOSE[3760402][C-000004da] res_rtp_asterisk.c: Got RTP packet from 67.231.4.7:3256 (type 00, seq 063208, ts 862294185, len 000160)

You should also be sending RTP. I can’t think why you would not be getting that, without other errors being reported.

I have been working with T-Mobile for the business fire team and anveo and we can’t figure out what the deal is. we have traffic going in and out, and I hve dissabled codec and switched them around and nobody has a clue. Does anybody in this forum use ANVEO DIRECT?

You have Allow Guest / Anonymous enabled?

Sure, it works fine if the PBX is on a public IP, or if the router doesn’t butcher the traffic.

So it appears that the router rewrote the source port number. I suspect that it doesn’t handle port range forwarding correctly. Please try the following:

  1. In Asterisk SIP Settings, RTP Port Ranges, set Start to 10000 and End to 10009. Submit, Apply Config, then restart Asterisk.
  2. In the Cradlepoint, remove the UDP ports 10000-20000 forwarding. Instead, individually forward UDP ports 10000, 10002, 10004, 10006 and 10008. Each of these five entries should look the same as what you have for port 5060, except with a different port number. Restart the Cradlepoint.

Test. If you still have trouble, change the Inbound Route to point to a working extension (confirmed by dialing *43 echo test from the extension). Make an inbound call, answer the extension when it rings, report whether inbound audio works (the extension user can hear the caller) and whether outbound audio works. If they don’t both work, post a new log.

Don’t forget RTP takes up two ports. So if the RTP is assigned to 10000 then RTPC will use 10001. If RTPC doesn’t have an open port is can cause quality and other issues.

The Cradlepoint, based on what I’m finding, might have to have SIP ALG enabled. There are numerous postings of this exact issue and the Cradlepoint has SIP ALG turned off by default. All the solutions are saying turn it on.