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

[Frank Durda IV]

Valentin Nechayev 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 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.