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: mcape...@sipwise.com <mailto:mcape...@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
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users