The other two don’t have anything useful. The only information there is really about which FreePBX modules you’ve licensed.
When taking the log from the file, you still need to set verbosity and enable pjsip debugging.
(Note that you don’t need extra FreePBX licences for media forwarding.)
Here’s an idea, fix the codec configuration in the softphone so that PCMU (g711u) is the first codec. See what happens when PCMU is the first offered codec by the softphone.
Ok! I did the “pjsip set logger on”, then did the “tail -f /var/log/asterisk/full” command.
Remote 1003 (MizuDroid via 4G/LTE)
Local 1000 (MicroSIP via 192.168.86.170)
Here is the failed remote-to-local connection: failedaudio - Pastes.io
And here is the successful local-to-remote connection: successfulaudio - Pastes.io
I tried to keep the test calls as short as possible to prevent super lengthy logs.
The only obvious thing there is that, after the hold/unhold, the Mizudroid has limited its codec choices to just PCMU, whereas it originally offered a selection. On the other hand, I don’t see why PCMU everywhere wouldn’t be the preferred choice.
I’d agree that limiting everything to PCMU would be something to try.
MizuDroid limits it just to PCMU in the first round, for the call going the other way.
It might be instructive to see the RTP logging, to see which codec is actually used at each stage.
Ok, I have retested by setting the softphones to ONLY use PCMU, and set freepbx to use PCMU, and logged it by using these commands: “pjsip set logger on” & “rtp set debug on”
Here is the failed test remote-to-local: failedaudio_rtpdbug - Pastes.io
Here is the successful test local-to-remote: successfulaudio-rtpdbug - Pastes.io
I think I see the problem here. The RTP debugging definitely revealed this!
On the successful log, the RTP stream log shows this:
[2025-09-25 20:44:08] VERBOSE[1190211][C-00000047] res_rtp_asterisk.c: Sent RTP packet to 192.168.86.170:4034 (type 00, seq 058933, ts 058008, len 000160)
[2025-09-25 20:44:08] VERBOSE[1190211][C-00000047] res_rtp_asterisk.c: Got RTP packet from 192.168.86.170:4034 (type 00, seq 025560, ts 002880, len 000160)
[2025-09-25 20:44:08] VERBOSE[1190255][C-00000047] res_rtp_asterisk.c: Sent RTP packet to 148.251.28.182:49828 (type 00, seq 063892, ts 002880, len 000160)
[2025-09-25 20:44:08] VERBOSE[1190255][C-00000047] res_rtp_asterisk.c: Got RTP packet from 148.251.28.182:49828 (type 00, seq 014517, ts 058175, len 000160)
Note that its sending and receiving from both IP Addresses, and that the IP of the remote user is 148.251.28.182
Now the failed log, the RTP stream log shows this:
[2025-09-25 20:39:44] VERBOSE[1189732][C-00000046] res_rtp_asterisk.c: Got RTP packet from 192.168.86.170:4015 (type 00, seq 023298, ts 010240, len 000160)
[2025-09-25 20:39:44] VERBOSE[1189686][C-00000046] res_rtp_asterisk.c: Sent RTP packet to 100.110.108.175:18122 (type 00, seq 046755, ts 010240, len 000160)
[2025-09-25 20:39:44] VERBOSE[1189732][C-00000046] res_rtp_asterisk.c: Got RTP packet from 192.168.86.170:4015 (type 00, seq 023299, ts 010400, len 000160)
[2025-09-25 20:39:44] VERBOSE[1189686][C-00000046] res_rtp_asterisk.c: Sent RTP packet to 100.110.108.175:18122 (type 00, seq 046756, ts 010400, len 000160)
Note here that its only receiving from the local device, and sending to the remote device. Now you mentioned before, that the remote device which connected to 4G/LTE is under a CGNAT, which I didn’t know about before and means it has a different send a receive IP sorta (and likes to mix up the ports). So I believe the server is trying to send the RTP packets to the outbound IP address of the remote device which is 100.110.108.175, and is different than the successful logs IP address of 148.251.28.182.
I can try to connect to a VPN under my network to get rid of the CGNAT issue and see if the packets are being sent to and from the same IP address.
.
Now I could be really wrong on this, because the more I think about it, the more I’m confusing myself…
It’s sending to the address that the INVITE told it to send to, which is an address which is private to the mobile network, and is the only address that the Android knows for itself. Until the MizuDroid sends media to Asterisk, Asterisk cannot discover the correct address to send to.
The question is is the MizuDroid sending any media, in which case why is it not reaching Asterisk, or is it not sending media, in which case why is it not doing so? The other question is why do the re-INVITEs cause it to start sending media, or start the media getting through.
Normally if there is a router problem at the Asterisk side, it is the outgoing media from Asterisk that triggers rules to let incoming media in, and I don’t see how the re-INVITEs would improve that situation.
I wanna say that MizuDroid is sending RTP packets? But I can’t be sure. The app has logging capabilities, but ZERO information on how to access the logs.
I connected to a VPN on my phone and the calls went through fine. Do you think a proxy would solve the problems I’m having? Something like Siproxd or Kamailio or OpenSIPS? If they would be a viable option then I would need direct help setting it up.
I tried Kamailio with rtpproxy before reaching out for help, and the documentation and resources online are so uninformative that I don’t understand why people would recommend it.
Without understanding what is happening at the mobile end, I don’t know what will fix it. A proxy will have the same problem of finding the public address and port being used by the phone as does Asterisk, if no media reaches it from the phone.
You need to monitor the traffic at every accessible point, so outside the firewall on the FreePBX machine (tcpdump on that machine will cover that); on the routers between you and the internet; and, ideally on the Android device. Logging on the phone may be difficult, and the network operator is unlikely to be prepared to provide logs.
This is an issue with MizuDroid not sending outbound calls through their proxy, thus it’s using the CGNAT IP from the mobile carrier. MizuDroid is registering to the PBX through the MizuFCMPushProxy which has a proper public IP.
So calls to the MizuDroid are doing PBX → MizuFCMPushProxy → MizuDroid app which is why audio is flowing with no issues. When it is reversed it’s MizuDroid → FreePBX which ends up using the CGNAT which can’t receive the audio because it’s dying in transit due to CGNAT.
See if the MizuDroid will let you send outbound calls via the Push Proxy that will solve the issue. Otherwise the VPN is a good choice.
Try removing that. Instead, forward UDP ports 10000-20000 and 5060 to 192.168.86.252
If you still have trouble, post router make/model and any VoIP-related settings.
Also, confirm that the router has your 97.220.x.x address on its WAN interface. If not, please explain (ISP does NAT, router connected to ISP-supplied modem configured as router, etc.)
The MizuDroid app doesn’t have anything for using the Push proxy unfortunately.
My Verizon Router shows the same correct WAN IP Address and it doesn’t use CGNAT thankfully, and yes I will turn off the DMZ Host for the server, I just wanted to make sure that ports weren’t an issue. Thank you Stewart1!
Also, I have thought of a way to get tcpdump and wireshark to read MizuDroid through 4G/LTE. I’ll use a family members phone with mobile hotspot and connect my phone(1003) and laptop running the analyzing software. The days running short so I will try this tomorrow afternoon.
I highly appreciate everyone’s insight and help!
hi @flowers3907 ,
you need to verify that you are not using SIP-ALG on your router. it should be turned off. if you do not see this setting, verify with your provider that it is turned off.
ensure that you have configured the nat settings correctly on the Freepbx sip module. update all the local networks that you are using (including local VPN networks).
ensure that you activate RTP keep-alive to 1 sec.
if you are using DMZ on your router that forwards all the inbound traffic to your pbx, switch to port forwarding with these ports: TCP/UDP 5060 and UDP 10000-20000
activate TCP on your asterisk in the SIP module and change the transport to TCP on your softphones (don’t forget to allow the TCP transport also on the extensions settings).
Let me know if that helped you.
Daniel Friedman
Trixton LTD
The OP isn’t having problems with signalling, and the media always uses UDP.
The OP isn’t reporting a problem once media starts flowing and keepalive will teach the router the wrong address, before that, as it is sending to an address that doesn’t exist on the public internet. It won’t reach the mobile network to keep that open, and if, as assumed by the other suggestions, the OP has control of the local router, it is much better to simply port forward everything in the Asterisk UDP range, on that.
His logs are showing that he is compensating for being behind NAT (external media and signalling addresses in, in particular the SDP c= line, and also that he is allowing for the remote device being behind NAT, but not compensating for it (RTP switches to an address that could only have been discovered using symmetric media rules).