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 , Campus 21/Europaring F15
AT-2345 Brunn am Gebirge

Phone:  +43(0)1 301 2044
Email:  mcapetta@sipwise.com
Website:  www.sipwise.com

Particulars according Austrian Companies Code paragraph 14
"Sipwise GmbH" - Europaring F15 - 2345 Brunn am Gebirge
FN:305595f, Commercial Court Vienna, ATU64002206