So Freepbx does have the network defined for the client, the client is on VPN so its not Nated. IN freepbx the sip nat setting is set to Never.
Client is in 10.119.101.35 ip, Aserisk is 10.123.245.18.
The issue is only on incoming calls
The call comes into the user, they answer but the caller can’t here the agent till they put the call on hold and off hold.
To the best of my knowledge no one has been messing around with any settings.
I have a pcap of the call, I was expecting to see something like a port change but in the sample the media ports stay the same .
What doesn’t make send is I see a packet has Payload type: unassigned (95)
Buggy sender of the SDP containing the 95. 95 is in the dynamic range of payload numbers, so the SDP must always contain an RTPMAP line telling the receiver how to interpret the number. Please provide a log containing the offending SDP.
Getting NAT setting wrong will result in wrong values in SIP Via and Contact headers and SDP c= lines; it won’t affect port number. The NAT setting you referred to as being set to never is not the primary NAT setting, but rather options for violating the strict SIP and SDP protocols to work round systems which are not fully aware that they are behind NAT. Explicitly setting never should rarely be needed. The key requirement, in your case, is to ensure that all sub-networks of the VPN are listed as Local networks.
The file wasn’t a tgz, as there was no TAR layer. It was a gzipped pcap file.
It is the RTP packet that has the bogus payload type, and it has to be a bug in the remote system, as Asterisk has not offered to accept payload type 95. I’d assumed that you had had SDP with m= specifying 95, and not RTPMAP, but there is no SDP at all justifying the use of payload type 95.
The payload length is too short for it to be telephony events, so I have no idea what it is.
I believe it will just be ignored.
Generally we expect logging from Asterisk itself, as far as possible, and for pcap’s to be pre-interpreted.
Media is flowing in both directions on the B leg. I see no logging for the A leg, at all. However, because it is G.729, I can’t tell whether there is any non-silence.