Greetings, this is either something really odd or I am just totally overlooking something. I have a production system that works fine with handsets. And it has been working that way for sometime. Recently we have added 1 softphone to the system. This softphone (and all testing surrounding it) run on a cell. This is something I have done many times in the past but in this case something is wrong. Below are important case notes.
FreePBX v13 built off of official distro
tried multiple cellphones using 3 different softphones (including Bria)
handsets are behind NAT as of course the softphone would be (So server side NAT settings are solid I think)
NAT traversal seems to be fine as packets go to the correct addresses (never see them fire off to the wrong place)
I have tried stun (I can even see the correct external IPs in SDP) but still no audio
audio fails in both directions between softphone and FreePBX server however audio across trunk is fine
SDP looks to fail (I see invite/invite/OK vs invite/invite/Progress/OK) vs a normal call
softphone side sends UDP packets to server like it is sending audio however said stream is empty and wireshark does not identify it as RTP (i assume because their is no audio for it to glean info from)
server never appears to send audio to softphone
call sets up normally so SIP itself seems to be happy and codec is set to 711 all around (SDP appears to confirm that)
Asterisk log files appear to be normal outside of the warning about no rtp packets seen
Any help or just pointing in the right direction would be greatly appreciated. I am quite sure I am just missing something.
If your NAT and network are set up correctly, the next obvious place to check is in your codec management. We’ve seen some problems with Asterisk/SIP/PJSIP not correctly negotiating the codecs. Have you tried setting the extension and phone to both use either alaw or ulaw (depending on whether you are out of or in North America, repsectively).
The system itself (via SIP settings) , the extension and the softphone are set to have only ulaw as an option. I did this because I did initially have an issue where 729 was available as an option on the softphone and it was getting selected (noticed this in captures).
But at this point everything seems to be selecting ulaw properly as far as I can tell. It is the only option being sent in SIP/SDP packets.
The thing that worries me is that you are getting no audio in either direction.
If it was one-way audio, that would point us directly at a NAT problem. Since the problem is actually both directions, I’m not sure that is necessarily the problem point. I’d really like to narrow the scope of the problem. Have you tried the following:
Can you dial a number on the soft phone and have it show up on the console as an attempted call?
Can you dial the soft phone and have it try to ring/pick up?
Do you see the registrations being acknowledged at both ends?
When you do your tcpdump/pcap, are you seeing the RTP traffic hitting the server with the correct routable addresses?
Have you tried pcap-ing the softphone end to see what the traffic looks like?
Can you call into a voicemail box on the server and listen at both ends?
– Do you hear the prompts at the softphone end?
– Do you hear the message on the server?
Without breaking this down into what works and what doesn’t, I’m afraid it’s going to be like trying to teach a pig to sing.
Well as I mentioned a bit earlier RTP packets flow from the softphone to the server. However they are empty. No audio in them at all. In fact wireshark does not even decode them as RTP. I assume because they are empty.
I literally never see audio flow from the server towards the softphone. Not on the correct address or even an incorrect one.
Here are the answers to your questions.
–Can you dial a number on the soft phone and have it show up on the console as an attempted call?
===Yes call setup/tear down appears normal
–Can you dial the soft phone and have it try to ring/pick up?
===have not tested that there is no DID associated but I will test that this evening
–Do you see the registrations being acknowledged at both ends?
===SIP itself appears normal
–When you do your tcpdump/pcap, are you seeing the RTP traffic hitting the server with the correct routable addresses?
===yes however the audio is all empty
–Have you tried pcap-ing the softphone end to see what the traffic looks like?
===No but I will also do that and report back
–Can you call into a voicemail box on the server and listen at both ends?
– Do you hear the prompts at the softphone end?
– Do you hear the message on the server?
===I will test all 3 items this evening as well. I should point out their are a number of handsets behind NAT working fine at this time.
If it makes a difference to anything I have tried both VOIPER and Bria with the same results.
I will test the items you pointed out in about 30mins and report back. Just waiting for that office to empty out so I can test call without explanation over and over again.