[Serusers] thoroughly confused, how should I route?

[Jeremy M. Dolan]

Dreadfully sorry to bother you folks again, but over the last ten
hours, minus a short break for leftover tamales,  I've done nothing
but confuse myself even further.

I believe the main piece I need to know, now, is simply how I should
be going about forwarding outbound calls, from private addresses, to a
PSTN gateway. Here is my crude drawing from a few days ago, slightly
updated to our new plan.

 +--------+   +------------------------+   +-------+   +--------------+
 | Phones |___| IP Router & SER Server |___| I'net |___| PSTN Gateway |
 |  10.x  |   | 10.0.0.1 --- 17.28.6.1 |   |   *   |   |  17.40.2.42  |
 +--------+   +------------------------+   +-------+   +--------------+

I have tried a ridiculous number of combinations of using and not using
nathelper, forcing and not forcing rtp proxy, loose and strict routing,
handling first by method or first by destination, and so on.

The only thing that's been consistent is mhomed=1 is absolutely
necessary, and none of the NAT functions seem to update the private
address in the SDP packet. Do they need to be used in route[0],
route[x], or does it not matter?

What is the advantage to using rewritehostport(...) and t_relay() over
t_relay_to(...)? Or record_route() and forward(...)? Or blindly
loose_route()'ing all over the place?

If someone could *please* advise me on the "proper" theory for how to
set up routing for the above graphical situation, I would be very,
very grateful.


Elsewhere, what should be done with ACK requests? When SER sends my
phone an OK, my phone replies ACK to SER. When this hits my "if
(loose_route) { if (t_relay()) { sl_reply_error(); }; };" block, which
I see in many example configs out there, processing stops, presumably
because t_relay() returns a 0 rather than a negative number. What's
the proper way to process ACKs? Do they ever need to be relayed, or
are they always single point to point.


Hopefully my last desperate call for help to you all,
Jeremy (who is now off to find a nice wall with which to bang his head
on until hearing back from the list)

-- 
Jeremy M. Dolan <mailto:jmd at pobox.com> <http://jmd.us/>
PGP: 1024D/3C68A1BA 9470 210C A476 FFBB 6D11  0223 0D1C ABFC 3C68 A1BA