> 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). -- Camille _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users