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

Frank Durda IV frank.durda at hypercube-llc.com
Wed Dec 3 23:20:26 CET 2008


Sorry for the long delay on this topic.  Personal matters
prevented me from investigating for a while and the original
occurrence of the problem went away for the first client
(because they changed something on their end), but now I
have another apparently-identical problem with calls
originating from a big-iron switch who isn't willing to
change their settings like the first client did.

The problem is easily reproducible for those of you who
wish to hear (or not hear) it themselves.  (instructions below)


To recap, the problem is that per rtpproxys own documentation
rtpproxy won't pass a packet in either direction for a given session
until it has received audio from both sides of a given session.
The README says:

[0]- after the session has been created, the proxy listens on the port 
it has
[0]  allocated for that session and waits for receiving at least one UDP
[0]  packet from each of two parties participating in the call. Once such
[0]  packet is received, the proxy fills one of two ip:port structures
[0]  associated with each call with source ip:port of that packet. When both
[0]  structures are filled in, the proxy starts relaying UDP packets between
[0]  parties;

This is exactly the behavior I am experiencing, but it is causing
interoperability problems and really needs to change.

In my case, there is a new calling switch/SBC that won't send rtpproxy any
audio packets when it places a call to us until it receives audio
for that call from us first.  I can see the switch on my side sending the
RTP to the port that rtpproxy stipulated (following a 183 or 200 message),
and absolutely none of that audio being sent out of rtpproxy and onto
the calling switch/SBC.  In other words, it is behaving exactly like
what the README statement says.

Meanwhile, the equipment at other clients that send me calls usually
send at least one RTP packet to rtpproxy shortly after receiving the
183 message (certainly by the time the 200 message shows up), and
so two-way audio commences for that call.   We have always noted
a slight truncation of initial audio, but apparently no one is
upset by that, but I suspect that was a result of rtpproxy behavior.
This noted behavior also supports the statement in the README that
audio must come from both directions before audio is sent in any
direction by rtpproxy.


So, the original question was (and now still is), is there a way to
disable this "both sides must send" criteria of rtpproxy?   I don't see
a technical reason for it, and I have a client with a NexTone or a Sonus
(or perhaps both) and when they send us calls, there is no audio.
Now, there may be some knob they can turn on their system to
not wait to send audio to the called party (of which our rtpproxy is
in the middle somewhere) until audio is received from the called
party (as is happening now), but some of these companies see no
need to alter their settings in such a way.   It would be better
if I could fix this behavior in rtpproxy to allow audio
in both directions from the moment that it selects the ports to
listen to for a given call and hands those back to SER.


NOTE: We do run rtpproxy with two interfaces, and did have to
alter SER* to actually pay attention to passed address parameters
passed to  force_rtp_proxy(), as the stock logic in SER quietly
ignored a provided IP address if two interfaces are in use.
I also had to change fix_nated_contact() to accept and use an IP
address provided if one was passed as a parameter because the
value SER came up with was always wrong for our environment.
We've had those two fixes in SER for eight months and it works
fine with numerous clients.  Rtpproxy is handed the right IP address
for each interface and customer, along with desired settings to
force_send_socket(), rewritehost() and fix_nated_contact(), and
everybody gets the IP addresses that are correct for their network.
It works, although I will admit ser.cfg is a bit klunky due to
the lack of a way in SER to pass non-constants, eg "variables" to
functions, but we manage.  *These alterations were all in SER
nathelper and rtpproxy is  untouched.   SER nathelper patches
available on request.


However, we have this condition that rtpproxy (as claimed
by its own documentation), won't pass traffic unless it
receives at least one packet from both parties, which probably
isn't going to happen in this situation because the maker of
that equipment says they aren't doing anything that violates RFC
in waiting to receive audio from the called system before
sending audio to the called system and so see no need to change
their stuff.

Let's see, someone asked earlier which rtpproxy interface is which?
Well we ended up with "e" being the side facing our equipment and "i"
being the side facing the rest of the world.  That seemed backwards, but
it worked first and the more logical combination did not for some
reason that was never investigated.  I suspect either way would work
because interfaces are different netblocks in the 10.x.x.x space.
The interface details are:

(internal/trusted side - no further NAT conversions to reach in-house 
switches))
em4: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
        inet 10.33.168.18 netmask 0xffffffc0 broadcast 10.33.168.63

(external/untrusted side)
em5: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        options=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
        inet 10.83.168.2 netmask 0xffffffc0 broadcast 10.83.168.63

Destination        Gateway            Flags    Refs      Use  Netif Expire
default            10.83.168.1       UGS         0 6480075550    em5
(causes packets with public IPaddrs destinations to flow to router
and out to Internet.  (On outbound packets, Router replaces source
IP with a matched public IP addr but destination is not altered,
nor is packet content.)

/usr/local/bin/rtpproxy -l 10.33.168.18/10.83.168.20


As you see, the external/untrusted interface is also where the default
route is, so that public IPaddrs will flow to the directly-connected
router.  Inbound rtp is NATed from a public address to an internal one
on the rtpproxy interface em5.  Again, all that has been passing
millions of calls for months now,  but now I've got one customer
who won't send audio until we send audio, and apparently rtpproxy
won't do this for some reason.  All IP addresses check out as being
reachable, it's just that nothing comes out of rtpproxy.   Since the packet
doesn't even come out of rtpproxy, the lack of audio can't be blamed
on NAT, since there are no packets being emitted in first place that
a NAT conversion might mess up.  That isn't it.  The problem appears
to be rtpproxy, and the documentation says it is supposed to behave
like this.  The question is, why?


I am able to easily replicate the problem using an Asterisk box
as the PBX for a Cisco SIP phone, by having the router immediately
in front of the SER/rtpproxy server block all incoming UDP but
port 5060 for packets coming from the asterisk server.  Allow
outgoing everything.

Remove the port block/access-list rule and the phone works fine.
Add the block of RTP and calls set up and answer, but both parties
hear nothing, not even 183 ring-back, even though the caller should
be able to hear the called party.   (All other calls occuring
simultaneously are unaffected since I only blocked incoming RTP
from one call source.)   tcpdump running on all the interfaces
on the SER/rtpproxy server also show that audio coming in on the
one side to rtpproxy but is not emitted by the other side.

Now, wait ten seconds or so after you know the called party
has answered (so far no audio of for either party), and remove
the incoming RTP block and ding!  You now have two-way audio, even
though you should have had one-way audio up until the moment the
inbound RTP block was removed.   This basically emulates
the behavior of the switch that won't send audio unless it
receives audio and how this puts the calling switch and rtpproxy
in a deadly embrace.

So that seems to demonstrate that rtpproxy is behaving exactly
as documented, but that this is terrible behavior.   What can
be done to fix this?

(tcpdumps of the sample calls available on request)

Thanks in advance for staying awake and bonus points for
suggesting a fix or coming up with one!





More information about the sr-users mailing list