21 Aug
2008
21 Aug
'08
5:57 p.m.
Hi,
What side is behind NAT and what is outside?
>>>> Frank Durda IV
<frank.durda(a)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 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@portaone.com