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

Valentin Nechayev netch at portaone.com
Thu Aug 21 23:57:57 CEST 2008


Hi,

>>>>> Frank Durda IV <frank.durda at 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.

-- 
Valentin Nechayev
PortaOne Inc., Software Engineer
mailto:netch at portaone.com



More information about the sr-users mailing list