I recently transitioned from 3cx to freepbx due to freepbx being FREE! A little bit of a learning curve but I love it. I use freepbx as a home phone system with an Analog-Telephone-Adapter and some digital devices with Mizudroid and MicroSip setup.
I am having 1 issue though; I cannot get the audio to work during remote connection. I have cloudflare setup with a domain name that points directly to my public ip address(and yes I have tried using the direct public ip address), and the device will register and place a call but no audio inbound or outbound.
THEN, if i place the call on hold and un-hold theres audio both ways. But if i do this on the local wifi USING the public ip it works just fine, weird. I used tcpdump to view the udp packets on port 10000 through 20000 and there’s a few packets until the hold button is pressed, then it starts flooding. I have tried everything that the forums had to offer to no avail.
I have the freepbx setup as a DMZ Host under my router (yes this poses as a security risk but its temporary so I don’t have to worry about ANY port forwarding issues, just wide open.)
In freepbx I setup in pjsip that the external domain is publicip.website.com(example). I have tried using googles stun server, I tried using chatgpt which only helped me use tcpdump and pjsip logging.
I’m stuck! I tried to setup Kamailio with rtpproxy because rtpproxy seemed like it COULD fix my rtp issue, but I cant find any guides that are understandable.
We need at least the SDP from the logs. Asterisk should be sending its public address in the c= line and receiving the remote public address in the incoming c=l line.
Also a problem that resolves after a hold un-hold sequence is something I remember seeing reported maybe two years ago. I can’t remember whether that was actually an Asterisk problem, but we also need to be sure you are using a current version (Linux distribution versions tend not to be current).
david55, I highly appreciate you replying.
I wanna ask, how would I get the SDP messages? I’m learning along the way! Is that running on the freepbx server “asterisk -rvvv” then “pjsip set logger on”? This is what I learned from some other posts to get some results.
Also it’s running in a Proxmox container on debian 12. And I recently had it on a virtual machine on proxmox before, but figured it was lighter as a container.
That should do it. The SDP is the payload part of the some requests and response. The c= lines say which IP to send media to, and the m= lines say which port to send to. Those from Asterisk should be the correct values as seen from the public internet. That should also be the case for any internet service provider, but is often not the for remote “extensions”.
Ok, I used the remote device to call a local device and answer it, then hangup after 3 seconds.
I’ll give a little legend here: [email protected],170 local device, pc [email protected],157: Remote device.
(I’ve redacted the real public information in the pastebin)
PUBLICIP.domain,com is my Cloudflare shortcut to public IP.
PUBLIC_IP is the actual public IP.
192.168.86.252 is the freepbx server.
192.168.86.253 is analog telephone adapter.(ignore)
Is this for inbound calls, outbound calls or both ? We had an issue (still do) that if you take an inbound route and send it directly to an extension, 2 way sound does not work. but if you fist pass the inbound route through an IVR or an announcement (even if there is no sound file announced) then the call sound works normally.
Answering early is a workaround, not a solution, and I’m not even sure how it would work if the problem description is correct.
It gives a false signal to the caller, and if call is being metered for the caller, means they will be billed, even if the call fails.
I can’t think how answering early in any way simulates the effect of a hold/unhold sequence, and I wonder if it is actually being quoted as a solution of a lack of support for early media. The problem description, as I understand it, relates to normal media, not early media.
Also, sometimes if you call is from a Local to Remote device, and the hold un-hold solution is tried, it still wont work.
I tried it with my local computer using MicroSIP and it plays the hold on the local side, doesn’t play anything on the remote side which is my phone, and doesn’t allow two way audio communications.
Since recent policy changes, which seem designed to require you to completely waive all rights to privacy, I will not use pastebin.com, so I won’t be able to look at any logs posted there.
They used to allow you configure to privacy options other than total freedom for them to track you, but the last few times I’ve tried it, I got directed to click bait target type web sites.
Again, I appreciate your assistance in helping me attempt to resolve my issue.
Here is an alternative to pastebin. I’m not sure how else you would like to view the logs. Maybe just a direct file upload and link via Google Drive or Dropbox?
Your A side is behind NAT but doesn’t know its public address. Given that it is on the shared IP range, and contains Droid, I would assume it is an Android phone app, and the NAT is probably CGNAT. Port numbers aren’t being preserved, which also indicates CGNAT.
In that environment, Asterisk requires several frames of incoming media before it can work out the address to which to send outgoing media. It also requires symmetric RTP enabling, but it wouldn’t work at all, in this environment, without that.
Your logs are missing timestamps and don’t contain information about the symmetric media setup process, so I don’t think you took them from the actual log file; it looks like you captured the console data stream.
There is no indication of the call ever going on hold, but I don’t think that is a logging issue; I think it was never on hold.
it looks a bit like the caller is not sending any media, initially, and therefore Asterisk cannot work out where to send media.
There is some risk that the CGNAT could split the media into two streams and apply different address translations to each one.
Note that 100.117.85,157 is not a unique address, and is only meaningful within the context of the mobile network in use. At the time of the call, 174.211.229.89 is the public address of the caller, but that address may be shared with other users of the mobile network. It belongs to Verizon.
And yes, you are correct about me just getting the console data stream, I’m not sure how to get a log file. If you could point me in the right direction I’ll be sure to give it to you as soon as possible.
Just to add to this. I don’t know what happened but NOW, any local device that calls the remote device, audio works perfectly. This doesn’t work the other way around.