[OpenSIPS-Users] SIP Capture storing as expected, but logging errors
Ionut Ionita
ionutionita at opensips.org
Fri Apr 7 04:18:36 EDT 2017
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 at SBCIP, <null> (2)
>> ERROR:proto_hep:update_recv_info: unknown protocol [1]
>> RRECV: BYE, sip:+15125551212 at 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 at SBCIP, sip:+12145551212 at CaptureAgent (2)
>> MRECV: INVITE, sip:+14695551212 at SBCIP, sip:+12145551212 at SBCIP:5060 (2)
>> ERROR:proto_hep:update_recv_info: unknown protocol [1]
>> RRECV: INVITE, sip:+14695551212 at 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
>> <jock.mckechnie at gmail.com> 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
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170407/2f099690/attachment-0001.html>
More information about the Users
mailing list