1 Jul
2004
1 Jul
'04
9:20 p.m.
On Jul 01, 2004 at 11:22, Jeremy M. Dolan <jmd(a)pobox.com> wrote:
Question one, most important:
Could someone please summarize how loose_route() actually functions?
I've seen it used in various ways, in various places in the configs
I've come across. The only documentation on the SER implementation is
a reference to all 260 pages of RFC 3261, a skimming of which was
mostly unhelpful. Specifically, does SER's loose_route() modify the
request at all, and most importantly, what determines its return code.
loose_route does modify the request if route headers are present.
It will at least remove some route header fields.
It will return true if it does soemthing (if it "routes" the messages
either strict or loose). It will return false on error (e.g. parse error
) or when it doesn't do anything (no route headers in the message).
If we have only loose routers in the path, loose_route will basically
set the forward address of the message to the next loose router and it
will remove its own route.
If the previous or the next router is a strict router, loose_route will
try to "fix" the ruri and the routes so that they would work with the
strict router (for more info see the rfc 3261,it's too long to explain
:-))
.
Question two, a long shot:
Anyone have a complete working config of SER acting as a gateway *and*
registrar situated between a 1918 (private) network and the Internet?
Question three, mostly out of curiosity:
The default ser.cfg (in stable CVS) loads the stateful transaction
manager (tm.so), but uses sl_send_reply for all error replies (404,
too many hops, etc). The documentation for the tm module shows t_reply
being used to send a 404 response, however. Is there any advantage to
using the stateful functions for messages like these? Any disadvantage?
t_reply should be used only when a transaction was already created.
So use it if you use t_newtran or from the failure route.
For alll the other stuff use sl_send_reply (t_reply won't work if a
transaction does not exit anyway).
Question four, important but not as urgent:
How can I set a timer similar to fr_inv_timer, but on a per-call
basis? For example, I'd like to redirect (with t_relay_to_udp) certain
incoming calls to a voice mail server after a certain amount of time.
Using fr_inv_timer for the timeout, outbound calls also get canceled!
Is there some other way to arrange a routing callback?
That's not possible right now. We will add this feature after we will
switch to a new generic timer code.
Question five, last but not least:
How are "internal" methods like ACK and OPTIONS supposed to be
handled? Is it essential that they fall off the end of the main
route{} block so they can be processed by the locally-running SER?
Does OPTIONS even enter route{}? Can I "break;" them as a short-cut?
All the methods enter route{}. You should at least loose_route and
forward them (so at least you won't break anything).
"break" by itself is synonym to drop(), so forward them before break
(you wouldn't want to drop the ACKs).
One last thing, is anyone currently working on updating the module
documentation? I've come across quite a few errors, and kept track of
them, intending to send in a patch once I have SER up and running and
have to time to tinker with the docs. If someone's handling it
currently I'll just send over my list.
No, currently nobody is working on the docs.
If you can send a patch it would be great.
Even if you don't have a patch, please send the list to serdev(a)lists.iptel.org
(at least we will know what to fix).
Andrei