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