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:  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
>
> -- 
> *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

Reply via email to