I'm trying to trace a complete dialog on a loadbalancer/proxy:
UAC <-> Proxy <-> backend 109.235.34.a <-> 109.235.32.b <-> 185.61.68.c
Proxy runs 4.3.x (but with 4.4.x I appear to have the same results).
siptrace config: ============================================= modparam("siptrace", "duplicate_uri", "sip:10.11.12.13:9060") modparam("siptrace", "hep_mode_on", 1) modparam("siptrace", "trace_to_database", 0) modparam("siptrace", "trace_flag", 22) modparam("siptrace", "trace_on", 1) =============================================
After REQINIT (which does pike and handles OPTIONS), I setflag(22) the message.
============================================= route(REQINIT);
setflag(22);
route(NATDETECT); route(WITHINDLG); =============================================
Next depending in where the message comes from: ============================================= if(!is_in_subnet($si, backends)) { ds_select_dst(1, 0); t_on_failure("RTF_DISPATCH"); } else { remove_hf("Route"); loose_route(); }
route(RELAY); =============================================
sip_trace() is being called in the routes: WITHINDLG MANAGE_BRANCH MANAGE_REPLY MANAGE_FAILURE RTF_DISPATCH
The resulting duplicate packets are:
11:20:21.037 INVITE 109.235.34.a:39621 109.235.32.b:5060 tcp 11:20:21.040 INVITE 109.235.34.a:39621 109.235.32.b:5060 tcp 11:20:21.047 401 185.61.68.c:5060 109.235.32.b:5060 udp 11:20:21.073 ACK 109.235.34.a:39621 109.235.32.b:5060 tcp 11:20:21.117 INVITE 109.235.34.a:39621 109.235.32.b:5060 tcp 11:20:21.135 100 185.61.68.c:5060 109.235.32.b:5060 udp 11:20:21.450 180 185.61.68.c:5060 109.235.32.b:5060 udp 11:20:27.929 200 185.61.68.c:5060 109.235.32.b:5060 udp 11:20:28.106 ACK 109.235.34.a:39621 109.235.32.b:5060 tcp 11:20:30.625 BYE 185.61.68.c:5060 109.235.32.b:5060 udp 11:20:30.659 BYE 185.61.68.c:5060 109.235.32.b:5060 udp 11:20:30.663 BYE 109.235.32.b:5060 109.235.34.a:39621 tcp 11:20:30.664 200 109.235.34.a 39621 109.235.32.b:5060 tcp 11:20:30.664 200 109.235.32.b:5060 185.61.68.c:5060 udp
What is missing are the forwarded replies, there is an ACK that matches the 401, but I have no clue what message was send to the UAC. Adding a sip_trace after REQINIT shows nothing extra.
How (if possible) do I get all messages being send via the proxy? I could use sngrep/sipgrep, but that is an other process to monitor for failure.
Daniel Tryba d.tryba@pocos.nl wrote:
How (if possible) do I get all messages being send via the proxy?
Hi, you are propably looking for parameter "trace_mode": http://kamailio.org/docs/modules/4.4.x/modules/siptrace.html#siptrace.p.trac...
Seems to be introduced in 4.4.0
On Fri, Aug 18, 2017 at 06:49:17PM +0300, Mikko Lehto wrote:
How (if possible) do I get all messages being send via the proxy?
Hi, you are propably looking for parameter "trace_mode": http://kamailio.org/docs/modules/4.4.x/modules/siptrace.html#siptrace.p.trac...
Seems to be introduced in 4.4.0
Exactly what I was looking for. I missed that flag some how. Thanks for the info.
Now I have a good reason to upgrade.
On Mon, Aug 21, 2017 at 10:54:15AM +0200, Daniel Tryba wrote:
http://kamailio.org/docs/modules/4.4.x/modules/siptrace.html#siptrace.p.trac...
Seems to be introduced in 4.4.0
Exactly what I was looking for.
Well, not exactly since I don't care about OPTIONS.
BTW maybe it would be useful to change the documentation http://kamailio.org/docs/modules/stable/modules/siptrace.html#idp48573308
It currently reads:
" There are two ways of storing information:
* by calling the sip_trace() method explicitely in the Kamailio configuration file. In this case the original message is processed.
* by setting the flag equal with the value of “trace_flag” (e.g., setflag(__trace_flag__)) parameter of the module. In this case, the message sent forward is processed. The logging mechanism is based on TM/SL callbacks, so only messages processed with the TM module or sent statelessly are logged. "
But there are actually 3 ways:
* by setting 'modparam("siptrace", "trace_mode", 1)' will mirror all traffic
Daniel Tryba d.tryba@pocos.nl:
Well, not exactly since I don't care about OPTIONS.
Yeah, polling is not very exciting always :)
Maybe you can simply catch all and filter later? I have (something like) this on HEP receiving Kamailio: --- } else if($rm =~ "(OPTIONS)$" ) { return; } else { $var(table) = "sip_capture_rest"; } ---
Daniel Tryba d.tryba@pocos.nl:
BTW maybe it would be useful to change the documentation . . . But there are actually 3 ways:
- by setting 'modparam("siptrace", "trace_mode", 1)' will mirror all traffic
Thanks for the text, added (commit 309895b0a3494f3ac476646779dfd0605e0857f1)
-
Daniel Tryba -
Mikko Lehto