<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Forgot to say but this will generate errors if you will update from
opensips 1.8<br>
to newer versions such as 2.2 or 2.3 which are correctly using the
protocol<br>
numbers, so if you will do that you will have to leave the code as
it is now.<br>
<br>
Regards,<br>
<pre class="moz-signature" cols="72">Ionut Ionita
OpenSIPS Developer</pre>
<div class="moz-cite-prefix">On 04/07/2017 11:15 AM, Ionut Ionita
wrote:<br>
</div>
<blockquote
cite="mid:4d808e06-6465-2465-d371-d43c7eac942d@opensips.org"
type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
Hi,<br>
<br>
The bug seems to be in siptrace which sends opensips protocol<br>
identifier(the 1 you see in logs) instead of IANA assigned
protocol<br>
numbers, because HEP shouldn't know OpenSIPS protocol ids.<br>
To make a custom fix just for your setup you can replace the <br>
following chunk of code in proto_hep/proto_hep.c <b>update_recv_info</b><br>
function in your capture agent(opensips 2.2)<br>
<font size="-1"><br>
if(proto == IPPROTO_UDP) ri->proto=PROTO_UDP;<br>
else if(proto == IPPROTO_TCP) ri->proto=PROTO_TCP;<br>
else if(proto == IPPROTO_IDP) ri->proto=PROTO_TLS;<br>
/* fake protocol */<br>
else if(proto == IPPROTO_SCTP) ri->proto=PROTO_SCTP;<br>
else if(proto == IPPROTO_ESP) ri->proto=PROTO_WS;<br>
/* fake protocol */<br>
else {<br>
LM_ERR("unknown protocol [%d]\n",proto);<br>
proto = PROTO_NONE;<br>
}<br>
</font><br>
with <font size="-1"><br>
ri->proto=proto<br>
</font><br>
and this should get you rid of the errors and the code should work<br>
as it was designed to.<br>
<br>
<br>
<br>
Regards,<br>
<pre class="moz-signature" cols="72">Ionut Ionita
OpenSIPS Developer</pre>
<div class="moz-cite-prefix">On 04/06/2017 07:49 PM, Jock
McKechnie wrote:<br>
</div>
<blockquote
cite="mid:CACZoz7TucRCvFr-CyNsX246=_RpnSDRzP8iv=C=Obsq=Uce+9g@mail.gmail.com"
type="cite">
<pre wrap="">Apologies for the half-sent eMail, I lost an argument with Opera and
it decided which one of us was smarter. I'll try again:
Hey all;
I've been working on trying to integrate Homer into our platform
(hurrah for SIP logging) and have run up against a problem I can't
quite figure out. It might be because we're mixing OpenSIPS versions,
however since the HEP protocol should be the same I'm not confident
that's the case.
The situation is as follows:
I have several (hundred) 1.8.8 OpenSIPS with the following headers
(the config has a sip_trace()/setflag() in it as well but I think it's
probably immaterial to this discussion):
---------------------
modparam("siptrace", "duplicate_uri", "sip:CaptureServer:9060")
modparam("siptrace", "duplicate_with_hep", 1)
modparam("siptrace", "trace_to_database", 0)
modparam("siptrace", "trace_flag", 22)
modparam("siptrace", "trace_on", 1
modparam("siptrace", "db_url", "borked://abc:123@localhost/zzz")
modparam("siptrace", "hep_version", 2)
---------------------
(The bogus db_url allows SIP Trace to work w/o pushing to a local DB,
as trace_to_database only appears in later releases). As far as I can
tell this works handily - I'm seeing plenty of HEP being sent off to
the CaptureServer and I've not noticed any missing packets.
The Capture Server is running 2.2.2 and has the following config:
---------------------
listen=hep_udp:PublicIP:9060 use_children 100
listen=hep_udp:PrivateIP:9060 use_children 1
mpath="/usr/lib64/opensips/modules/"
loadmodule "db_mysql.so"
loadmodule "proto_hep.so"
loadmodule "sipcapture.so"
####### Module setup ##########
modparam("proto_hep", "hep_capture_id", 101)
modparam("sipcapture", "db_url",
"mysql://homer_user:PASSWORD@DatabaseServer/homer_data")
modparam("sipcapture", "capture_on", 1)
modparam("sipcapture", "table_name", "sip_capture_call_%Y%m%d")
modparam("sipcapture", "rtcp_table_name", "rtcp_capture")
modparam("sipcapture", "hep_capture_on", 1)
# Main SIP request routing logic
route {
xlog("L_INFO", "MRECV: $rm, $fu, $ru ($HEPVERSION)\n");
sip_capture();
drop;
}
onreply_route {
xlog("L_INFO", "RRECV: $rm, $fu, $ru ($HEPVERSION)\n");
sip_capture();
drop;
}
---------------------
On the Capture Server I'm getting logs like this:
RRECV: BYE, sip:+15125551212@SBCIP, <null> (2)
ERROR:proto_hep:update_recv_info: unknown protocol [1]
RRECV: BYE, sip:+15125551212@SBCIP, <null> (2)
ERROR:proto_hep:update_recv_info: unknown protocol [1]
ERROR:proto_hep:update_recv_info: unknown protocol [1]
MRECV: INVITE, sip:+14695551212@SBCIP, sip:+12145551212@CaptureAgent (2)
MRECV: INVITE, sip:+14695551212@SBCIP, sip:+12145551212@SBCIP:5060 (2)
ERROR:proto_hep:update_recv_info: unknown protocol [1]
RRECV: INVITE, sip:+14695551212@SBCIP, <null> (2)
ERROR:proto_hep:update_recv_info: unknown protocol [1]
The Errored entries appear to align with
provisional/progression/numbered mesages - 100s, 18x, 200s, etc. The
Logs further seem to bear this out as there are no xlog()s showing
such a message - they're all INVITEs, ACKs, CANCELs or BYEs.
This being said - I can see them in the database! So OpenSIPS is
clearly storing them even though (apparently) it's throwing an unknown
protocol error.
What am I missing here?
My thanks;
- Jock
On Thu, Apr 6, 2017 at 11:19 AM, Jock McKechnie
<a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:jock.mckechnie@gmail.com"><jock.mckechnie@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hey all;
I've been working on trying to integrate Homer into our platform
(hurrah for SIP logging) and have run up against a problem I can't
quite figure out. It might be because we're mixing OpenSIPS versions,
however since the HEP protocol should be the same I'm not confident
that's the case.
The situation is as follows:
I have several (hundred) 1.8.8 OpenSIPS with the following config:
modparam("siptrace", "duplicate_uri", "sip:CaptureServer:9060")
modparam("siptrace", "duplicate_with_hep", 1)
modparam("siptrace", "trace_to_database", 0)
modparam("siptrace", "trace_flag", 22)
modparam("siptrace", "trace_on", 1
modparam("siptrace", "db_url", "borked://abc:123@localhost/zzz")
modparam("siptrace", "hep_version", 2)
(The bogus db_url allows SIP Trace to work w/o pushing to a local DB,
as trace_to_database only appears in later releases). As far as I can
tell this works handily - I'm seeing plenty of HEP being sent off to
the CaptureServer and I've not noticed any missing packets.
The Capture Server is running 2.2.2 and has the following config:
listen=hep_udp:PublicIP:9060 use_children 100
listen=hep_udp:PrivateIP:9060 use_children 1
mpath="/usr/lib64/opensips/modules/"
loadmodule "db_mysql.so"
loadmodule "proto_hep.so"
loadmodule "sipcapture.so"
####### Module setup ##########
modparam("proto_hep", "hep_capture_id", 101)
modparam("sipcapture", "db_url",
"mysql://homer_user:PASSWORD@DatabaseServer/homer_data")
modparam("sipcapture", "capture_on", 1)
modparam("sipcapture", "table_name", "sip_capture_call_%Y%m%d")
modparam("sipcapture", "rtcp_table_name", "rtcp_capture")
modparam("sipcapture", "hep_capture_on", 1)
# Main SIP request routing logic
route {
xlog("L_INFO", "MRECV: $rm, $fu, $ru ($HEPVERSION)\n"); sip_capture();
drop; } onreply_route { xlog("L_INFO", "RRECV: $rm, $fu, $ru
($HEPVERSION)\n"); sip_capture(); drop; }
</pre>
</blockquote>
<pre wrap="">_______________________________________________
Users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
<br>
</body>
</html>