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

[Frank Durda IV]

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.