21 Sep
2009
21 Sep
'09
3:41 p.m.
Hi Andrei!
I'm still not sure for the correct usage.
If I got it right, set_forward_* is for relaying of messages (regardless
if it is a request or reponse) and set_reply_* is for local generated
replies (explicit in script or implicit somewhere in a module)
Is this correct?
regards
klaus
Andrei Pelinescu-Onciul schrieb:
On Sep 21, 2009 at 12:16, Klaus Darilion
<klaus.mailinglists(a)pernau.at> wrote:
Great!
I have documented the new function.
http://sip-router.org/wiki/cookbooks/core-cookbook/devel#set_forward_no_con…
Thanks!
Andrei, please verify if I understood correct and
the examples are correct.
Yes, they are correct.
There are some differences if you use them in other type of routes.
For example in onsend_routes and branch routes, only the set_forward*
work and they will apply only to the current message / current branch.
E.g.:
onsend_route{
if(to_ip!=10.0.0.0/8){
#only reuse connection for IPs outside the local net
set_foward_no_connect();
}
}
In a reply route they will apply only to the current reply (so you will
see their effect only if the current reply "wins" and it's forwarded).
As you said set_*_close() must be used with care (and in general they
should be avoided). Especially dangerous is the combination of
set_*_close() and set_*_no_connect() (it works only once, after that no
further messages can be forwarded to the same destination).
The primary purpose of set_*_close() is for xmlrpc use (work around
against the python xmlrpc client bug).
I suspect those functions work with TLS too? What
about SCTP?
Yes, they work with TLS. They don't work yet with SCTP (but I'll add
support for them to SCTP later).
What happens if the functions are called for UDP
transport - I hope they
will be ignored and do not make noisy log-statements.
Nothing, they are ignored.
Andrei