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

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

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

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