Hi,
Frank Durda IV frank.durda@hypercube-llc.com wrote:
If rtpproxy receives a packet from one side, it relays the packet to other side. But target address for this can be incorrect. Your problems can be tied with NAT or asymmetric implementation, in which packets are waited on one address (declared in SDP) but sent from another address.
Preface, these Class 4 sites (TDM gateways) are configured as a NAT environment
What side is behind NAT and what is outside?
and have been working for some months without issue (or without this particular issue being detected and identified), until we happened to pick up traffic that is originating in a network where they use silence suppression (likely originally G.729/G.726 but converted to G.711 by the time we get it). Absolutely NO RTP packets are being received from the calling party until they make a lot of noise, so there is nothing for rtpproxy to forward to the called party, and so half of the rtpproxy proxy activation criteria is not met.
The problem with NAT and VAD is that if the party behind NAT doesn't conform to conditions for such source, the party outside NAT isn't able to determine address to send. To talk with party behind NAT, the following conditions shall be met:
1. The party behind NAT is symmetric either for signaling and for media. Here, it's symmetric, if source address for packets and declared target address are the same.
2. Either 1) the party behind NAT is able to determine its external address (most probably by STUN requests), or 2) it shall send RTP immediately without delay - so the other party is able to determine external address from real packet.
Your description is very close to situation if one party is behind NAT, doesn't use STUN or is unable to use it (i.e. NAT is truly symmetric). If the media originated by this party stops due to VAD or another similar technique, the effect will be exactly as you describe.
According to the rtpproxy README file that I quoted in the original mail, rtpproxy will not forward packets coming from one direction (in this case, the called/answering party) at all until audio packets are received from the calling party,
Seems your reading is wrong. I have analyzed rtpproxy code detailedly. Details in different versions can differ (Maxim refactored it very deeply some time ago), but the common algorithm is unchanged. You can see it in source code. On creating or updating session, in handle_command(), there is initial address filling (just after writeport: label) in all cases except address is null (0.0.0.0 for IPv4). You can also check it in log - there shall be messages like "Pre-filling caller/callee address with..."
which won't happen because the calling party can't hear the called party and won't grunt or cough or something because they only hear silence from the called party, not even ring-back. They then hang up and call their local carrier and complain that the service sucks, and here we are. In this scenario, debug shows SER and rtpproxy have exchanged IP and port info and rtpproxy is listening. Tcpdump shows the ring-back and called party audio is reaching rtpproxy (in-progress ring-back audio), but is all being discarded by rtpproxy and not forwarded. Tcpdump also shows no packets coming from the calling party, because they don't think the called party has answered, much less been rung.
Where did you get this dump? If rtpproxy sends packets to bogus address, this can be detected on the rtpproxy host itself, not some intermediate point.
It is a deadly embrace, and unfortunately the rtpproxy documentation basically says "Yes, it does that", even though this is improper behavior.
We work with rtpproxy 4+ years. There is no such desired behavior in it, even if you read such in its documentation. It can be bug, but not intentional behavior. Please try to investigate as detailedly as possible.