2 Jul
2004
2 Jul
'04
2:31 p.m.
On Jul 01, 2004 at 18:07, Jeremy M. Dolan <jmd(a)pobox.com> wrote:
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.
It seems you need an rtpproxy in the bridge mode. For this you need the
nathelper modules from unstable and the latest rtpproxy (it won't work
with ser 0.8.12 versions). You can just replace nathelper in 0.8.12 with
the unstable nathelper and recompile.
Look also at modules/nathelper/examples/alg.cfg (from the unstable
nathelper). It is an example of bridged config.
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?
It doesn't matter. Make sure you catch also the replies (t_on_reply &
in the onreply router force again rtpproxy if status is 183 or 2xx).
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?
rewritehostport will change the request uri.
t_relay_to won't. It depends on what you want.
forward does the same thing as t_relay_to or t_relay
(forward(uri:host)), but statelessly. This means it's slightly faster
and demands no proxy resources, but on the other hand you won't be able
to intercept the replies in the on_reply router and you won't be able to
do proper accounting).
You must use record_route to make sure the other requests in the dialog
will pass through your proxy (and you want this because your internal
hosts are not directly reachable from the internet).
You must also use loose_route to handle the routes you added with
record_route :-)
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.
Yes they need to be delivered.
You should have if (!t_relay()) { /* ...error */ }. You forgot the '!'.
In script t_relay (and in general all the functions) return 0 if they
failed for some reason and 1 on success.
Andrei