On Jul 01, 2004 at 18:07, Jeremy M. Dolan jmd@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