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, ...).
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).