On Thursday, March 05, 2015 12:34:36 PM Camille Oudot wrote:
Are you saying
that $avp(caller_conid) when set on the initial
INVITE, for example, wouldn't be available in the onreply_route to
the INVITE? If so, the examples in the TCP Ops README will need to
reflect the need for using dialog vars instead.
Hi Anthony,
the AVP you set on a request will be available in the onreply_routes
that have been registered with t_on_reply().
The example in the tcpops readme uses some AVPs, but you might of
course need different ways of memorizing connection information that
fits your specific needs (stateless, dialog-aware, use a database, a
hashatable, ...).
Thanks, Camille, then I should be all set as I am calling
onreply_route[MANAGE_REPLY].
By the way,
I'm only using if(proto!=UDP) since the TCP Ops module
checks whether or not it can apply itself, but also logs each time it
does so. Is it more efficient for the script to introduce the check
for the proto (avoiding the clutter in the logs), or more efficient
for the module to just return when it isn't applicable?
The messages complaining about the connection not being a TCP connection
use the ERROR log level, because I felt like calling these TCP tuning
functions on something else than TCP should not remain unnoticed and
should be fixed at script level.
I would recommend that you keep this logic in your script, and in your
case, "if(proto!=UDP)" is efficient (probably more than writing a log
line).
Again, thank you. BTW, I'm looking forward to
modparam("usrloc", "close_expired_tcp", 1) when I rebuild later...
--
Anthony -
https://messinet.com/ -
https://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E