18 Aug
2017
18 Aug
'17
6:29 a.m.
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.
18 Aug
18 Aug
11:49 a.m.
Daniel Tryba <d.tryba(a)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.tra…
Seems to be introduced in 4.4.0
--
Mikko
21 Aug
21 Aug
4:54 a.m.
On Fri, Aug 18, 2017 at 06:49:17PM +0300, Mikko Lehto wrote:
Exactly what I was looking for. I missed that flag some how. Thanks for
the info.
Now I have a good reason to upgrade.
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.tra…
Seems to be introduced in 4.4.0
6:06 a.m.
On Mon, Aug 21, 2017 at 10:54:15AM +0200, Daniel Tryba wrote:
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
http://kamailio.org/docs/modules/4.4.x/modules/siptrace.html#siptrace.p.tra…
Seems to be introduced in 4.4.0
Exactly what I was looking for.
10:46 a.m.
Daniel Tryba <d.tryba(a)pocos.nl>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(a)pocos.nl>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)
--
Mikko Lehto
2685
days inactive
2688
days old
4 comments
2 participants
participants (2)
-
Daniel Tryba -
Mikko Lehto