[SR-Users] Missing ACC record in case of canceled call forking

[Marco Capetta]

Hello,

Yes Flag 3 is set at the very beginning when we start handling the 
received INVITE message.
I checked and it is still active in both the branches of the outgoing 
INVITEs.



In the 1st case the following ACC is generated:
         id: 311
     method: INVITE
   from_tag:
     to_tag:
     callid: 121700311 at X.X.X.X
   sip_code: 487
sip_reason: Request terminated
       time: 2018-09-04 11:55:24
time_hires: 1536054924.342



I missed to say in my previous email that in kamailio ACC configuration 
we have also:
   modparam("acc", "acc_prepare_always", 1)


Thanks
Marco



On 09/04/2018 11:39 AM, Daniel-Constantin Mierla wrote:
> Hello,
>
> is flag 3 set for the INVITE transaction?
>
> In the 1st case, is the CANCEL accounted or the INVITE transaction or both?
>
> Cheers,
> Daniel
>
>
> On 04.09.18 11:18, Marco Capetta wrote:
>> HiAll,
>>
>> As additional step I tested the scenario with kamailio v5.1.5 but the
>> problem seems still there.
>>
>> Best regards.
>> Marco
>>
>>
>> On 08/28/2018 03:10 PM, Marco Capetta wrote:
>>> Hi All,
>>>
>>> I'm facing a strange problem of missing ACC record in case of
>>> parallel call forking.
>>>
>>> The scenario is the following:
>>>   - A subscriber with 1 device registered
>>>   - B subscriber with 2 device registered (B1 and B2)
>>>
>>> CASE 1:
>>>   - A calls B
>>>   - B1 and B2 start ringing
>>>   - A hangups the call before B1 or B2 answers
>>> Kamailio generates an ACC record.
>>>
>>> CASE 2:
>>>   - A calls B
>>>   - B1 and B2 start ringing
>>>   - B1 rejects the call sending back a 486
>>>   - B2 is still ringing
>>>   - A hangups the call before B2 answers
>>> Kamailio DOESN'T generate an ACC record.
>>>
>>>
>>>
>>> We have Kamailio v5.1.4 with TM module enabled.
>>>
>>> ACC configuration is the following:
>>>    modparam("acc", "early_media", 0)
>>>    modparam("acc", "report_ack", 0)
>>>    modparam("acc", "report_cancels", 1)
>>>    modparam("acc", "detect_direction", 1)
>>>    modparam("acc", "db_flag", 1)
>>>    modparam("acc", "db_missed_flag", 2)
>>>    modparam("acc", "failed_transaction_flag", 3)
>>>
>>>
>>> I increased debug level of TM and ACC modules and I added some debug
>>> lines as well.
>>> The difference between the two calls is that, after the CANCEL sent
>>> by A is processed by Kamailio, in CASE 1 I have the following lines:
>>>    Aug 28 14:21:11 spce proxy[13188]: DEBUG: tm [t_hooks.c:258]:
>>> run_trans_callbacks_internal(): DBG: trans=0x7f5a88049198, callback
>>> type 512, id 0 entered
>>>    Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_logic.c:670]:
>>> tmcb_func(): acc callback called for t(0x7f5a88049198) event type
>>> 512, reply code 487
>>>    Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_extra.h:63]:
>>> free_strar_mem(): Freeing memory, type is 2, message_index 8, index i 0
>>>    Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_extra.h:63]:
>>> free_strar_mem(): Freeing memory, type is 2, message_index 8, index i 1
>>>    Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_extra.h:63]:
>>> free_strar_mem(): Freeing memory, type is 2, message_index 8, index i 2
>>>    Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_extra.h:63]:
>>> free_strar_mem(): Freeing memory, type is 2, message_index 8, index i 3
>>>    Aug 28 14:21:11 spce proxy[13188]: DEBUG: acc [acc_extra.h:63]:
>>> free_strar_mem(): Freeing memory, type is 2, message_index 8, index i 4
>>>
>>> Those debug lines are not printed for CASE 2.
>>>
>>>
>>>
>>> Is there any configuration I'm missing or is it a bug?
>>>
>>>
>>>
>>> Thank you very much for your support.
>>> Marco
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
*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 at sipwise.com <mailto:mcapetta at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180904/75aae40a/attachment.html>