[Serusers] Can SER 2.0.0-rc1 pstn.cfg file actually work with BYE from PSTN?

[Frank Durda IV]

A follow-up on this.  One of the questions  Mr. Teigre asked
earlier got me thinking about some things I tried some months
ago where I thought I solved these issues before getting
stuck on one point and not being able to get any ideas on
the list at that time about what was going on.   This evening
I went back and tried reducing the ser.cfg file, then adding
the pieces back as long as each one got things closer to what
was desired.

I finally hit on a combination that works and visually seems
correct, but at a cost that I guess I will have to pay.
It requires me to abandon using two interfaces for SER.
I have to let the router split the traffic towards the two
now-not-as-isolated networks rather than let SER sit between
the two isolated network as was the original design.   Router
access lists will have to provide protection to keep rogue
packets from the public network from reaching the isolated
network with the PSTN switch, rather than letting SER stand
entirely in the way as was the original design.

The reason SER doesn't appear to work with two interfaces that
connect to two isolated networks is pretty simple:  If you use
record_route() and loose_route() to handle the called-party BYE
and re-INVITEs addressing correctly and fix_nated_contact()
to straighten out the Contact headers in both directions
on most messages, SER also inserts two Record-Route: headers,
which is fine for the direction the Method message is sent in,
but the order is only good for that direction.  On the replies
(such as 180/183/200) once you get past the SER, everything
falls apart.  The two Record-Routes that come out of SER
(or are just passed-through) are now in the wrong order for
the side of the isolated networks that the reply is sent out
of SER to, so the machine receiving them tries to send the
PRACK/ACK back to SER on the IP address of the other isolated
network because that Record-Route line appears first, and of
course you can't get there from here.

If you force the Record-Routes to come out with the listener IP
addresses in reverse order, then the same scenario just fails
earlier, because now the PSTN gateway sees the first
Record-Route of the network it can't reach and sends the
180/183/200 reply there, so it promptly gets lost since that
destination can't be reached either.

There doesn't seem to be any logic in SER to flip the order
of the two Record-Routes that SER added when the replies pass
back through SER (or are regenerated in that order by SER),
even though SER knows both of these Record-Routes are ones
that it added.   As these are reply messages, I doubt I can
use the ser.cfg language to fix the problem since SER doesn't
allow much editing on reply messages.  It will likely require
a code change somewhere within SER to allow isolated networks
each on its own interface to really work.

The earlier samples included various attempts to avoid the
record_route/loose_route trap, but that meant much more
complexity in the ser.cfg file and even then all the issues
couldn't quite be resolved.


As I have been battling many different problems with SER
for two years now and many of the problems are the result of
trying to use the two listener/interface address feature,
I think I will give up now and go with just one listen
interface.  The parts I need in SER seem to be really
wired to only work that way.  Naturally, the SER documentation
talks mainly about the one-interface model too.   Pity,
because this was the main reason we originally wanted
to use SER, to put a wall between outside IP traffic and
only SIP messages that managed to get past SER config file
and malformed packet checks would reach the somewhat
vulnerable PSTN switch.   A poor-mans Acme Packet SBC
if you will.  Unfortunately, SIP-capable PSTN switches
are far too easy to confuse, or make angry, or both.


Thanks to Mr. Teigre for responding and reviewing this mess.