Re: [Serusers] Deadly embrace with rtpproxy - Is it necessary? Can it be turned off?

Valentin Nechayev wrote: Preface, these Class 4 sites (TDM gateways) are configured as a NAT environment 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. 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, 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. It is a deadly embrace, and unfortunately the rtpproxy documentation basically says "Yes, it does that", even though this is improper behavior. So the question remains, is there a setting or compile option in rtpproxy to force it to start forwarding packets from either part of a call once rpptoxy has received the addresses and port information from SER for that call? We already know rtpproxy is getting the right values, we just want it to start doing its job immediately even if one of the two parties doesn't generate any audio instantly. If rtpproxy as it stands can't do this, I either have to re-write rpproxy or replace it with a commercial appliance that doesn't have this "Must see two-way audio before I allow two-way audio" criteria. That requirement of rtpproxy the behavior are not RFC compliant.