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

More on this, it appears at least one of the parties who has calls get in this situation with our SER/rtpproxy setup is also running SER/rtpproxy, and if the rtpproxy documentation is correct, this will never ever work, regardless of the use of NAT. Consider this situation. Caller sends a call to a nearby SER/rtpproxy (unit A). Unit A does the INVITE to a second SER/rtpproxy system (unit B) owned by another party which acts as a PSTN gateway. The call is set up, and unit B receives the SDP data from the PSTN switch, passes it to his rtpproxy (unit B), and sends that SDP payload on to unit A SER, who passes it to his rtpproxy and then on to the calling party. PSTN switch starts sending ring-back and maybe the calling party answers. Unit B rtpproxy discards all the audio because it has not heard anything from Unit A. Meanwhile, the calling party is screaming his lungs out and those audio packets are being received by Unit A rtpproxy, who discards them because he hasn't seen any audio from Unit B. B never sees audio from A and A never sees audio from B. Stalemate. Neither A nor B rptproxy can end the stalemate (aka a deadly embrace) because of this "must see two-way audio in order to allow at least one-way audio" rule. Each rtpproxy prevents the other from meeting that criteria. That rule needs to go away immediately.