[Serusers] Need way to specify SOURCE IP address on packets of SIP messages being emitted by SER

[Frank Durda IV]

Greger Viken Teigre wrote:
 >
 > My knee-jerk reaction would be to try to take SER out of the
 > picture, not use it to solve the problem.


And in our environment it does seem like SER adds complexity
with little apparent gain.  It and a gateway router are really
there to perform four tasks,

(1) Only let friends SIP and RTP packets to reach the PSTN switch,
(2) keep malformed or potentially fraudulent SIP/RTP packets away from
    the PSTN switch
(3) Keep all other types of IP traffic away from the PSTN switch.
(4) Drive rtpproxy to deal with NAT issues.

The PSTN switch doesn't seem to be hardened against rogue IP
data, and we really don't want someone looking for Windows back
doors to port scan the thing into the ground.  SIP signaling
processing seems to have the same priority as SS7 signaling, so
if you flood the SIP ethernet ports with junk packets, it is
bound to have a negative effect on all call setup times, and that
can result in customer complaints, FCC fines or maybe cause the
switch to panic and reboot.  All not good.

Now, obviously a good router can at least limit the sources of
packets, limit the packet classes (TCP, UDP, ICMP, etc) and limit
what port ranges are allowed through for RTP (the PSTN switch
reserves a range of 10,000 ports per CODEC card you install so it
makes a rather large door).  With a pile of permit/deny rules in the
router, it can take of those things.  However to actually look for
wacky stuff in the SIP protocol packets at all, you need something
like SER that understands the SIP protocol and can go "huh?" when
something weird shows up rather than letting that message go on to
the perfect victim, the PSTN switch simply because it happened to
be addresses to port 5060.  Similarly, while rtpproxy doesn't do
much to stop malformed RTP packets, it does do a good job of
dynamically allowing sources of RTP that should be sending them
at a given moment to pass through while blocking all the other
ports, so it has value for this task.

You can think of our SER setups as mainly a SIP firewall and funnel,
directing a number of SIP entities down to a single SIP-TDM
PSTN gateway.  We have a number of these, each with its own switch
and local SER servers.   However, don't forget the issues of
parsing the SDP payload and fixing up things for the RTP audio
to flow correctly through NAT conversions.


 > Because one day you want to get rid of that terrible provider of
 > TDM-style SIP services and swap it would something more "SIP-like".

It is funny, but we've looked at some hardware that does what
SER+rtpproxy does made by big players in the biz and they are
frequently even more limiting while requiring even more complexity,
not to mention being insanely expensive.  It's silly stuff like
only having a single Gigabit ethernet interface that all outside
(unscreened) and inside (screened) traffic must pass through,
leaving our Gigabit port on the actual PSTN switch operating at
half capacity.  And that's high-end gear I am talking about here
that have such basic shortcomings.   The idea of popping a
two-port Gigabit ethernet PCI-E card in that slot instead of
the one-port card that is in there now just never occurred to
them.  So now I have to buy more routing or switching devices
to compensate for not having two ethernet cables coming out of
the box.  Their simplicity becomes my complexity.

Yes, perhaps in ten years having to do a SIP to TDM conversion
will be a small part of the pie with most calls eventually
being SIP to SIP, but right now SIP compared to TDM is tiny and
it will take a long time for telcos to grow it to the point
where SIP becomes even half of their traffic and at that point
the gateway business could be pretty big.  That's clearly the
direction things are headed, but there are things about SIP that
just drive the TDM folks nuts, particularly the inability to be
able to point at the physical properties that will provide the five
nines of reliability they can get (and are expected to provide) on
a TDM network.  They really see SIP as lowering the quality of
wire-line phone service to the quality you see in cell phones
networks, rightly or wrongly.  Anyway, back to the matter at hand.


 > That being said, what you are looking for came in SER 2.0:
 > force_send_socket() 2.0 will also store the incoming interface
 > and reply to the correct one automatically (instead of using
 > one interface as source).

Okay, that sounds promising, although I must admit that when I
visited the iptel web site in December 2007 to obtain 0.9.6, it was
not at all clear as to whether the 2.0 release was actually real
yet or some experimental snapshot.  I found more discussion of the
RCS branch and revision philosophy being employed than finding a
place where some just actually said something like "2.0.0 IS
RELEASED AND CAN BE SAFELY RELIED ON AND IT ISN'T BETA".  :-)
What advice I could find was in the mailing list which said to
use 0.9.6, 2 isn't ready, etc.  Of course those comments could
have been written some time ago.   I'll grab a copy of 2.0 and see
what all it changes.  For iptel, I suggest a larger sign stating
that 2.0 is the place to be.


 > So, some ideas that may or may not work in your situation:
 > - Use iptables to rewrite SIP packets (you create your own bogus
 > ip addresses for the switch, then use an outgoing packet rule
 > to pick up the bogus dst address, rewrite to the tdm ip AND
 > change the src ip)

If they could be truly be bogus, that is a possibility.  In practice,
I could see this setup needing perhaps 500 listening IP addresses on
each interface per SER box to accommodate the number of separate SIP
gateway we have to communicate with and bill differently.
In this model, I'd have to burn a new pair of IP addresses on the
SER box for each of these systems.

Of course, I'm not sure you would have to use bogus IP addresses
to use iptables as well.  In a way, all of these are made up but
working IP addresses just to deal with providing isolation.


A note on a curious thing encountered when SER values are stored
in databases.  We were using the mysql modules to store various
IP addresses that SER could look up, the idea being that this
would avoid specifying them in ser.cfg and avoid brief outages
caused by a SER restart,  but what we found in practice was that
SER failed to re-query mysql or someone was caching answers
perviously obtained, because changes we made in the mysql
database were usually not detected by SER until you did a SER
restart anyway!

In the lab, we left one of our IP addresses out and made a test
call out, which failed as you would expect.  Added the IP address
to mysql and made a test call again and it still failed, even
though the needed values were now in the database.  Apparently
something had cached the previous query.  So we restarted SER
and now SER apparently actually looked at mysql again and said
"Oh, there it is", found the value that was there and now the
test call would work.   Most annoying.  This implies we can't
use dynamic deletions/additions of database entries to cut off
IP addresses or add new ones, unless you also do a SER reload,
an act which we would like to avoid except for maintenance
windows.

I haven't had time to dig into the details of this problem, but
obviously we need something that doesn't cache the database
answers and allows SER to basically never need to be reloaded.
Changes of IP addresses that SER should and should not allow in
as well as what other IP addresses they should forward to or
pretend to be should be things you can change at any time and
they take effect immediately.  For the moment as mysql was no
longer bringing anything useful to the party, we are coding
everything in ser.cfg.  (ick)  Maybe this behaves better in 2.x.

With all those IP address listeners we will have, I suspect it would
be a bad thing to reload SER ever while calls are being attempted,
as SER likely closes all the sockets and re-opens them on the
ser.cfg config reload, which could mean that SIP messages are
ignored for a second or two (how long does it take to close
and re-open, say 1,000 sockets), which would interfere with
hundreds of call setups/teardowns, more than enough to trigger an
outage alarm in the TDM world.  I think we need the interface IP
and alias details (currently kept at the top of the ser.cfg file)
to be in a separate config file that is read on start and re-read
separately (and only with a special SERctl
blow-up-network-environment-reload command) from the call
rule/routing sections which cause less havoc when they are
changed/reloaded.  (Future SER feature, perhaps?)



 > - Use one SER instance per company and only listen to a pair of
 > IP addresses for each instance

I actually thought of this earlier, but the fact that we must
use rtpproxy (there be NATing here) and rtpproxy uses a AF_UNIX
socket seems like it would prevent having multiple SER instances.
Only one (if any) would successfully communicate with rtpproxy,
or at least I think that is what the outcome would be.  Now I am
dimly aware that rtpproxy can also be run using a AF_INET/AF_INET6
socket (apparently meant for running rtpproxy on a completely
separate computers) and so you *might* be able to have multiple
instances of both SER and rtpproxy on the same computer (now
tripling the number of interface IP addresses in play, two for
each SER and one for each rtpproxy), but this is something I have
not seen any mention of anybody else attempting.

Alternatively, maybe a single rtpproxy can cope with multiple
SERs instances sending it instructions (with AF_INET or maybe
even AF_UNIX), but the documentation that exists really doesn't
say anything that suggests this would work.  So, does anybody
know if

1 "many SER each with its own rtpproxy on the same box works"  or
2 "many SER, and ONE rtpproxy serving all SERs on the same box"
works?  If so on either, would that be AF_UNIX or AF_INET for
communication between the parties?

The software setup would certainly be more complex, but it does
have the added advantage of providing more runnable things for
these multi-core CPUs to work on in parallel.


 > - Use lcr as a starting point and write your own module that
 > does the matching from database. I think Andreas Graning
 > wrote an extension to the lcr module that added some new
 > matching criteria that you might use

I'm afraid I don't know what lcr is nor what functionality it
provides or replaces.  Is it a substitute for the SER function
for this particular need, or just a module that SER uses?
Where is there information on lcr?

Thanks again for the pointer and any answers to the above.
It was a tremendous help.


Frank Durda IV