Quantcast

SIP Capture storing as expected, but logging errors

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

SIP Capture storing as expected, but logging errors

Jock McKechnie
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; }

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SIP Capture storing as expected, but logging errors

Jock McKechnie
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
<[hidden email]> wrote:

> 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; }

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SIP Capture storing as expected, but logging errors

ionutrazvanionita
Hi,

    The bug seems to be in siptrace which sends opensips protocol
identifier(the 1 you see in logs) instead of IANA assigned protocol
numbers, because HEP shouldn't know OpenSIPS protocol ids.
To make a custom  fix just for your setup you can replace the
following chunk of code in proto_hep/proto_hep.c update_recv_info
function in your capture agent(opensips 2.2)

if(proto == IPPROTO_UDP) ri->proto=PROTO_UDP;
        else if(proto == IPPROTO_TCP) ri->proto=PROTO_TCP;
        else if(proto == IPPROTO_IDP) ri->proto=PROTO_TLS;
                                                                                        /* fake protocol */
        else if(proto == IPPROTO_SCTP) ri->proto=PROTO_SCTP;
        else if(proto == IPPROTO_ESP) ri->proto=PROTO_WS;
                                            /* fake protocol */
        else {
                LM_ERR("unknown protocol [%d]\n",proto);
                proto = PROTO_NONE;
        }

with
ri->proto=proto

and this should get you rid of the errors and the code should work
as it was designed to.



Regards,
Ionut Ionita
OpenSIPS Developer
On 04/06/2017 07:49 PM, Jock McKechnie wrote:
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
[hidden email] wrote:
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; }
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SIP Capture storing as expected, but logging errors

ionutrazvanionita
Forgot to say but this will generate errors if you will update from opensips 1.8
to newer versions such as 2.2 or 2.3 which are correctly using the protocol
numbers, so if you will do that you will have to leave the code as it is now.

Regards,
Ionut Ionita
OpenSIPS Developer
On 04/07/2017 11:15 AM, Ionut Ionita wrote:
Hi,

    The bug seems to be in siptrace which sends opensips protocol
identifier(the 1 you see in logs) instead of IANA assigned protocol
numbers, because HEP shouldn't know OpenSIPS protocol ids.
To make a custom  fix just for your setup you can replace the
following chunk of code in proto_hep/proto_hep.c update_recv_info
function in your capture agent(opensips 2.2)

if(proto == IPPROTO_UDP) ri->proto=PROTO_UDP;
        else if(proto == IPPROTO_TCP) ri->proto=PROTO_TCP;
        else if(proto == IPPROTO_IDP) ri->proto=PROTO_TLS;
                                                                                        /* fake protocol */
        else if(proto == IPPROTO_SCTP) ri->proto=PROTO_SCTP;
        else if(proto == IPPROTO_ESP) ri->proto=PROTO_WS;
                                            /* fake protocol */
        else {
                LM_ERR("unknown protocol [%d]\n",proto);
                proto = PROTO_NONE;
        }

with
ri->proto=proto

and this should get you rid of the errors and the code should work
as it was designed to.



Regards,
Ionut Ionita
OpenSIPS Developer
On 04/06/2017 07:49 PM, Jock McKechnie wrote:
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
[hidden email] wrote:
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; }
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: SIP Capture storing as expected, but logging errors

Jock McKechnie
Boy you guys are awesome.

Thanks, works like a _charm_.

(I really, really need to start updating the proxies...)

 - Jock

On Fri, Apr 7, 2017 at 3:18 AM, Ionut Ionita <[hidden email]> wrote:

> Forgot to say but this will generate errors if you will update from opensips
> 1.8
> to newer versions such as 2.2 or 2.3 which are correctly using the protocol
> numbers, so if you will do that you will have to leave the code as it is
> now.
>
> Regards,
>
> Ionut Ionita
> OpenSIPS Developer
>
> On 04/07/2017 11:15 AM, Ionut Ionita wrote:
>
> Hi,
>
>     The bug seems to be in siptrace which sends opensips protocol
> identifier(the 1 you see in logs) instead of IANA assigned protocol
> numbers, because HEP shouldn't know OpenSIPS protocol ids.
> To make a custom  fix just for your setup you can replace the
> following chunk of code in proto_hep/proto_hep.c update_recv_info
> function in your capture agent(opensips 2.2)
>
> if(proto == IPPROTO_UDP) ri->proto=PROTO_UDP;
>         else if(proto == IPPROTO_TCP) ri->proto=PROTO_TCP;
>         else if(proto == IPPROTO_IDP) ri->proto=PROTO_TLS;
>
> /* fake protocol */
>         else if(proto == IPPROTO_SCTP) ri->proto=PROTO_SCTP;
>         else if(proto == IPPROTO_ESP) ri->proto=PROTO_WS;
>                                             /* fake protocol */
>         else {
>                 LM_ERR("unknown protocol [%d]\n",proto);
>                 proto = PROTO_NONE;
>         }
>
> with
> ri->proto=proto
>
> and this should get you rid of the errors and the code should work
> as it was designed to.
>
>
>
> Regards,
>
> Ionut Ionita
> OpenSIPS Developer
>
> On 04/06/2017 07:49 PM, Jock McKechnie wrote:
>
> 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
> <[hidden email]> wrote:
>
> 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; }
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Loading...