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@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

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@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users