Re: [SR-Users] 183 acc records even if early_media equals to 0

Are you able to reproduce as you need in a testbed or so? I may have a small patch and wondering if you would be able to test? Cheers, Daniel On 09.11.17 14:32, Marco Capetta wrote: > I have the same issue on 4.4.5 and 4.4.6 > > Thanks > Marco > > On 11/09/2017 02:22 PM, Daniel-Constantin Mierla wrote: >> >> One more thing, have you seen it in latest versions from branch >> 4.4.x? Or was it on 4.4.1 only? Or from other perspective, on >> which versions you noticed this kind of issues? >> >> Cheers, >> Daniel >> >> >> On 09.11.17 14:02, Marco Capetta wrote: >>> Thank Daniel. >>> >>> Cheers >>> Marco >>> >>> On 11/09/2017 12:38 PM, Daniel-Constantin Mierla wrote: >>>> >>>> Hello, >>>> >>>> I expect that the code value is taken from status of the >>>> transaction, which at that time has 200ok ranked with more >>>> priority. I will check the code and if it proves to be this >>>> case, I will come up with a fix. >>>> >>>> Cheers, >>>> Daniel >>>> >>>> On 09.11.17 10:42, Marco Capetta wrote: >>>>> Hello, >>>>> >>>>> no we didn't try 5.0.X versions yet. >>>>> >>>>> To investigate deeper the issue, I added some additional log >>>>> lines in the acc module. In particular, I did the following: >>>>> >>>>> /* is this reply of interest for accounting ? */ >>>>> static inline int should_acc_reply(struct sip_msg *req, struct >>>>> sip_msg *rpl,int code) >>>>> { >>>>>    ... >>>>>    ... >>>>>     str req_callid, rpl_callid; >>>>>     get_callid(req, &req_callid); >>>>>     get_callid(rpl, &rpl_callid); >>>>> >>>>>     LM_ERR("++++++++++ early_media set to %d and code set to >>>>> %d - call_id req: %.*s - call_id rpl: %.*s\n", early_media, >>>>> code, req_callid.len, req_callid.s, rpl_callid.len, rpl_callid.s); >>>>> >>>>>     if ( code<200 && !(early_media && >>>>> parse_headers(rpl,HDR_CONTENTLENGTH_F, 0) == 0 && >>>>> rpl->content_length && get_content_length(rpl) > 0)) { >>>>>         LM_ERR("++++++++++ We will NOT account this reply - >>>>> call_id req: %.*s - call_id rpl: %.*s\n", req_callid.len, >>>>> req_callid.s, rpl_callid.len, rpl_callid.s); >>>>>         return 0; >>>>>     } >>>>> >>>>>     LM_ERR("++++++++++ We will account this reply - call_id >>>>> req: %.*s - call_id rpl: %.*s\n", req_callid.len, >>>>> req_callid.s, rpl_callid.len, rpl_callid.s); >>>>> >>>>>     return 1; /* seed is through, we will account this reply */ >>>>> } >>>>> >>>>> In case of a "normal" call I have: >>>>> >>>>> Nov 9 08:52:23 sp2 proxy[12072]: ERROR: acc [acc_logic.c:413]: >>>>> should_acc_reply(): ++++++++++ early_media set to 0 and code >>>>> set to 183 - call_id req: f4227b9a898b482887d9aebdf7137061 - >>>>> call_id rpl: f4227b9a898b482887d9aebdf7137061 >>>>> Nov 9 08:52:23 sp2 proxy[12072]: ERROR: acc [acc_logic.c:418]: >>>>> should_acc_reply(): ++++++++++ We will NOT account this reply >>>>> - call_id req: f4227b9a898b482887d9aebdf7137061 - call_id rpl: >>>>> f4227b9a898b482887d9aebdf7137061 >>>>> Nov 9 08:52:23 sp2 proxy[12072]: NOTICE: <script>: NAT-Reply - >>>>> S=183 - Session Progress M=INVITE IP=172.30.52.98:5060 >>>>> (172.30.52.132:5080) ID=f4227b9a898b482887d9aebdf7137061 >>>>> UA='<null>' >>>>> Nov 9 08:52:23 sp2 proxy[12072]: ERROR: acc [acc_logic.c:413]: >>>>> should_acc_reply(): ++++++++++ early_media set to 0 and code >>>>> set to 183 - call_id req: f4227b9a898b482887d9aebdf7137061 - >>>>> call_id rpl: f4227b9a898b482887d9aebdf7137061 >>>>> Nov 9 08:52:23 sp2 proxy[12072]: ERROR: acc [acc_logic.c:418]: >>>>> should_acc_reply(): ++++++++++ We will NOT account this reply >>>>> - call_id req: f4227b9a898b482887d9aebdf7137061 - call_id rpl: >>>>> f4227b9a898b482887d9aebdf7137061 >>>>> Nov 9 08:52:24 sp2 proxy[12073]: ERROR: acc [acc_logic.c:413]: >>>>> should_acc_reply(): ++++++++++ early_media set to 0 and code >>>>> set to 200 - call_id req: f4227b9a898b482887d9aebdf7137061 - >>>>> call_id rpl: f4227b9a898b482887d9aebdf7137061 >>>>> Nov 9 08:52:24 sp2 proxy[12073]: ERROR: acc [acc_logic.c:422]: >>>>> should_acc_reply(): ++++++++++ We will account this reply - >>>>> call_id req: f4227b9a898b482887d9aebdf7137061 - call_id rpl: >>>>> f4227b9a898b482887d9aebdf7137061 >>>>> Nov 9 08:52:24 sp2 proxy[12073]: NOTICE: <script>: NAT-Reply - >>>>> S=200 - OK M=INVITE IP=172.30.52.98:5060 (172.30.52.132:5080) >>>>> ID=f4227b9a898b482887d9aebdf7137061 UA='<null>' >>>>> Nov 9 08:52:24 sp2 proxy[12073]: ERROR: acc [acc_logic.c:413]: >>>>> should_acc_reply(): ++++++++++ early_media set to 0 and code >>>>> set to 200 - call_id req: f4227b9a898b482887d9aebdf7137061 - >>>>> call_id rpl: f4227b9a898b482887d9aebdf7137061 >>>>> Nov 9 08:52:24 sp2 proxy[12073]: ERROR: acc [acc_logic.c:422]: >>>>> should_acc_reply(): ++++++++++ We will account this reply - >>>>> call_id req: f4227b9a898b482887d9aebdf7137061 - call_id rpl: >>>>> f4227b9a898b482887d9aebdf7137061 >>>>> >>>>> In case of a call with the issue I have: >>>>> >>>>> Nov 8 23:42:38 sp2 proxy[12068]: ERROR: acc [acc_logic.c:413]: >>>>> should_acc_reply(): ++++++++++ early_media set to 0 and code >>>>> set to 183 - call_id req: eb22b398fda649ec92abd98c85534914 - >>>>> call_id rpl: eb22b398fda649ec92abd98c85534914 >>>>> Nov 8 23:42:38 sp2 proxy[12068]: ERROR: acc [acc_logic.c:418]: >>>>> should_acc_reply(): ++++++++++ We will NOT account this reply >>>>> - call_id req: eb22b398fda649ec92abd98c85534914 - call_id rpl: >>>>> eb22b398fda649ec92abd98c85534914 >>>>> Nov 8 23:42:38 sp2 proxy[12068]: NOTICE: <script>: NAT-Reply - >>>>> S=183 - Session Progress M=INVITE IP=172.30.52.98:5060 >>>>> (172.30.52.132:5080) ID=eb22b398fda649ec92abd98c85534914 >>>>> UA='<null>' >>>>> Nov 8 23:42:38 sp2 proxy[12073]: ERROR: acc [acc_logic.c:413]: >>>>> should_acc_reply(): ++++++++++ early_media set to 0 and code >>>>> set to 200 - call_id req: eb22b398fda649ec92abd98c85534914 - >>>>> call_id rpl: eb22b398fda649ec92abd98c85534914 >>>>> Nov 8 23:42:38 sp2 proxy[12073]: ERROR: acc [acc_logic.c:422]: >>>>> should_acc_reply(): ++++++++++ We will account this reply - >>>>> call_id req: eb22b398fda649ec92abd98c85534914 - call_id rpl: >>>>> eb22b398fda649ec92abd98c85534914 >>>>> Nov 8 23:42:38 sp2 proxy[12073]: NOTICE: <script>: NAT-Reply - >>>>> S=200 - OK M=INVITE IP=172.30.52.98:5060 (172.30.52.132:5080) >>>>> ID=eb22b398fda649ec92abd98c85534914 UA='<null>' >>>>> Nov 8 23:42:38 sp2 proxy[12068]: ERROR: acc [acc_logic.c:413]: >>>>> should_acc_reply(): ++++++++++ early_media set to 0 and code >>>>> set to 200 - call_id req: eb22b398fda649ec92abd98c85534914 - >>>>> call_id rpl: eb22b398fda649ec92abd98c85534914 >>>>> Nov 8 23:42:38 sp2 proxy[12068]: ERROR: acc [acc_logic.c:422]: >>>>> should_acc_reply(): ++++++++++ We will account this reply - >>>>> call_id req: eb22b398fda649ec92abd98c85534914 - call_id rpl: >>>>> eb22b398fda649ec92abd98c85534914 >>>>> Nov 8 23:42:38 sp2 proxy[12073]: ERROR: acc [acc_logic.c:413]: >>>>> should_acc_reply(): ++++++++++ early_media set to 0 and code >>>>> set to 200 - call_id req: eb22b398fda649ec92abd98c85534914 - >>>>> call_id rpl: eb22b398fda649ec92abd98c85534914 >>>>> Nov 8 23:42:38 sp2 proxy[12073]: ERROR: acc [acc_logic.c:422]: >>>>> should_acc_reply(): ++++++++++ We will account this reply - >>>>> call_id req: eb22b398fda649ec92abd98c85534914 - call_id rpl: >>>>> eb22b398fda649ec92abd98c85534914 >>>>> >>>>> It seems that in the second call the provisional response is >>>>> evaluated from acc module after the 200 message has been >>>>> received, so the sip code is 200 instead of 183. >>>>> >>>>> Thanks >>>>> Marco >>>>> >>>>> >>>>> On 11/09/2017 10:20 AM, Daniel-Constantin Mierla wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> >>>>>> On 09.11.17 09:50, Marco Capetta wrote: >>>>>>> Dear All, >>>>>>> >>>>>>> I'm facing a strange problem with the call accounting >>>>>>> module: even if in my configuration I have the parameter: >>>>>>>      modparam("acc", "early_media", 0) >>>>>>> I can find some ACC records with sip_code 180 or 183. >>>>>>> >>>>>>> >>>>>>> I investigated those cases and this issue seems to happen >>>>>>> when an endpoint sends an 183 message immediately followed >>>>>>> by a 200 OK. >>>>>>> >>>>>>> The issue seems started from kamailio version 4.4.1, but I >>>>>>> cannot be really sure of this. >>>>>>> >>>>>>> Have you ever had a similar problem? >>>>>>> Do you have any suggestions on how to solve it? >>>>>>> >>>>>> I haven't seen it so far and no other similar reports. Did it >>>>>> happen for you only in 4.4.x series or you have seen it with >>>>>> 5.0.x? >>>>>> >>>>>> Cheers, >>>>>> Daniel >>>>>> -- >>>>>> Daniel-Constantin Mierla >>>>>> www.twitter.com/miconda --www.linkedin.com/in/miconda >>>>>> Kamailio Advanced Training, Nov 13-15, 2017, in Berlin -www.asipto.com >>>>>> Kamailio World Conference -www.kamailioworld.com >>>>> >>>>> -- >>>>> *Marco Capetta * >>>>> Operations Engineer >>>>> >>>>> Sipwise GmbH <http://www.sipwise.com> , Campus 21/Europaring F15 >>>>> AT-2345 Brunn am Gebirge >>>>> >>>>> Phone: +43(0)1 301 2044 <tel:+4313012044> >>>>> Email: mcapetta(a)sipwise.com <mailto:mcapetta@sipwise.com> >>>>> Website: www.sipwise.com <http://www.sipwise.com> >>>>> >>>>> Particulars according Austrian Companies Code paragraph 14 >>>>> "Sipwise GmbH" - Europaring F15 - 2345 Brunn am Gebirge >>>>> FN:305595f, Commercial Court Vienna, ATU64002206 >>>>> >>>> >>>> -- >>>> Daniel-Constantin Mierla >>>> www.twitter.com/miconda --www.linkedin.com/in/miconda >>>> Kamailio Advanced Training, Nov 13-15, 2017, in Berlin -www.asipto.com >>>> Kamailio World Conference -www.kamailioworld.com >>> >>> -- >>> *Marco Capetta * >>> Operations Engineer >>> >>> Sipwise GmbH <http://www.sipwise.com> , Campus 21/Europaring F15 >>> AT-2345 Brunn am Gebirge >>> >>> Phone: +43(0)1 301 2044 <tel:+4313012044> >>> Email: mcapetta(a)sipwise.com <mailto:mcapetta@sipwise.com> >>> Website: www.sipwise.com <http://www.sipwise.com> >>> >>> Particulars according Austrian Companies Code paragraph 14 >>> "Sipwise GmbH" - Europaring F15 - 2345 Brunn am Gebirge >>> FN:305595f, Commercial Court Vienna, ATU64002206 >>> >> >> -- >> Daniel-Constantin Mierla >> www.twitter.com/miconda --www.linkedin.com/in/miconda >> Kamailio Advanced Training, Nov 13-15, 2017, in Berlin -www.asipto.com >> Kamailio World Conference -www.kamailioworld.com > > -- > *Marco Capetta * > Operations Engineer > > Sipwise GmbH <http://www.sipwise.com> , Campus 21/Europaring F15 > AT-2345 Brunn am Gebirge > > Phone: +43(0)1 301 2044 <tel:+4313012044> > Email: mcapetta(a)sipwise.com <mailto:mcapetta@sipwise.com> > Website: www.sipwise.com <http://www.sipwise.com> > > Particulars according Austrian Companies Code paragraph 14 > "Sipwise GmbH" - Europaring F15 - 2345 Brunn am Gebirge > FN:305595f, Commercial Court Vienna, ATU64002206 > -- Daniel-Constantin Mierla www.twitter.com/miconda --www.linkedin.com/in/miconda Kamailio Advanced Training, Nov 13-15, 2017, in Berlin -www.asipto.com Kamailio World Conference -www.kamailioworld.com