I can see TM API is exposing tmb.t_get_reply_totag(msg, &to_tag); looking at what can be done from acc_logic.c on_missed /* set env variables */ env_set_to( get_rpl_to(t,reply) ); env_set_code_status( code, reply); ... On Thu, Jul 30, 2020 at 11:51 PM Julien Chavanton <jchavanton(a)gmail.com> wrote: > Hi, considering this example : > > > modparam("acc_json", "acc_missed_flag", 6) > > failure_route[test] { > setflag(6); // MISSED_ACC, the failure will be recorded by ACC > t_flush_flags(); // This will set the flags in the newly created transaction > t_reply("500", "Service Unavailable"); > } > > This does generate an ACC event, however the to-tag is not populated, my guess this is because the TM callback is done before the to-tag is generated. > > I wonder if there is a way to populate the to-tag immediately ? > > I will dig it further, but maybe there is a trick I am missing > >

I can not find the explanation on why the data memory is different once I return from the function. This is the same process and the same memory address. code : void get_rpl_totag(struct cell *t, struct sip_msg *reply, str *totag) { if (reply==FAKED_REPLY || !reply || !reply->to) { tmb.t_get_reply_totag(t->uas.request, totag); } if (totag && totag->s) { LM_ERR("reply_totag ok [%p][%d][%*.s]\n", totag->s, totag->len, totag->len, totag->s); } } str ttag = STR_NULL; get_rpl_totag(t, reply, &ttag); LM_ERR(">>> to-tag[%p][%d][%.*s]\n", acc_env.to_tag.s, acc_env.to_tag.len, acc_env.to_tag.len, acc_env.to_tag.s); outputs : 0(25216) ERROR: acc [acc_logic.c:97]: get_rpl_totag(): reply_totag ok [0x7fa6a79d81e0][41][ ] 0(25216) ERROR: acc [acc_logic.c:525]: on_missed(): >>>>>>>>>>> to-tag[0x7fa6a79d81e0][41][594d50c3218065a60bb91fd47a70fbc1-857d6855] On Fri, Jul 31, 2020 at 8:33 AM Julien Chavanton <jchavanton(a)gmail.com> wrote: > Seems to work, I will complete the modifications and make an MR ... > > On Fri, Jul 31, 2020 at 12:30 AM Julien Chavanton <jchavanton(a)gmail.com> > wrote: > >> I can see TM API is exposing >> >> tmb.t_get_reply_totag(msg, &to_tag); >> >> looking at what can be done from acc_logic.c >> >> on_missed >> >> /* set env variables */ >> env_set_to( get_rpl_to(t,reply) ); >> env_set_code_status( code, reply); >> ... >> >> On Thu, Jul 30, 2020 at 11:51 PM Julien Chavanton <jchavanton(a)gmail.com> >> wrote: >> >>> Hi, considering this example : >>> >>> >>> modparam("acc_json", "acc_missed_flag", 6) >>> >>> failure_route[test] { >>> setflag(6); // MISSED_ACC, the failure will be recorded by ACC >>> t_flush_flags(); // This will set the flags in the newly created transaction >>> t_reply("500", "Service Unavailable"); >>> } >>> >>> This does generate an ACC event, however the to-tag is not populated, my guess this is because the TM callback is done before the to-tag is generated. >>> >>> I wonder if there is a way to populate the to-tag immediately ? >>> >>> I will dig it further, but maybe there is a trick I am missing >>> >>>

I tried adding a watchpoint in GDB I do not seen when how the data is replaced by empty characters ... On Fri, Jul 31, 2020 at 3:31 PM Julien Chavanton &lt;jchavanton(a)gmail.com&gt; wrote: > Sorry, the example was wrong .... > > code : > > void get_rpl_totag(struct cell *t, struct sip_msg *reply, str *totag) { > if (reply==FAKED_REPLY || !reply || !reply->to) { > tmb.t_get_reply_totag(t->uas.request, totag); > } > if (totag && totag->s) { > LM_ERR("reply_totag ok [%p][%d][%*.s]\n", totag->s, > totag->len, totag->len, totag->s); > } > } > ... > str ttag = STR_NULL; > get_rpl_totag(t, reply, &ttag); > LM_ERR(">>> ttag[%p][%d][%.*s]\n", ttag.s, ttag.len, ttag.len, ttag.s); > > > outputs : > > 0(25920) ERROR: acc [acc_logic.c:97]: get_rpl_totag(): reply_totag ok > [0x7f0559c2a1e0][41][ ] > 0(25920) ERROR: acc [acc_logic.c:525]: on_missed(): >>> > ttag[0x7f0559c2a1e0][41][594d50c3218065a60bb91fd47a70fbc1-857d6855] > > > > On Fri, Jul 31, 2020 at 3:26 PM Julien Chavanton &lt;jchavanton(a)gmail.com&gt; > wrote: > >> I can not find the explanation on why the data memory is different once >> I return from the function. >> This is the same process and the same memory address. >> >> code : >> >> void get_rpl_totag(struct cell *t, struct sip_msg *reply, str *totag) { >> if (reply==FAKED_REPLY || !reply || !reply->to) { >> tmb.t_get_reply_totag(t->uas.request, totag); >> } >> if (totag && totag->s) { >> LM_ERR("reply_totag ok [%p][%d][%*.s]\n", totag->s, >> totag->len, totag->len, totag->s); >> } >> } >> >> str ttag = STR_NULL; >> get_rpl_totag(t, reply, &ttag); >> LM_ERR(">>> to-tag[%p][%d][%.*s]\n", acc_env.to_tag.s, >> acc_env.to_tag.len, acc_env.to_tag.len, acc_env.to_tag.s); >> >> >> outputs : >> >> 0(25216) ERROR: acc [acc_logic.c:97]: get_rpl_totag(): reply_totag ok >> [0x7fa6a79d81e0][41][ ] >> 0(25216) ERROR: acc [acc_logic.c:525]: on_missed(): >>>>>>>>>>> >> to-tag[0x7fa6a79d81e0][41][594d50c3218065a60bb91fd47a70fbc1-857d6855] >> >> >> >> >> >> >> On Fri, Jul 31, 2020 at 8:33 AM Julien Chavanton &lt;jchavanton(a)gmail.com&gt; >> wrote: >> >>> Seems to work, I will complete the modifications and make an MR ... >>> >>> On Fri, Jul 31, 2020 at 12:30 AM Julien Chavanton &lt;jchavanton(a)gmail.com&gt; >>> wrote: >>> >>>> I can see TM API is exposing >>>> >>>> tmb.t_get_reply_totag(msg, &to_tag); >>>> >>>> looking at what can be done from acc_logic.c >>>> >>>> on_missed >>>> >>>> /* set env variables */ >>>> env_set_to( get_rpl_to(t,reply) ); >>>> env_set_code_status( code, reply); >>>> ... >>>> >>>> On Thu, Jul 30, 2020 at 11:51 PM Julien Chavanton < >>>> jchavanton(a)gmail.com&gt; wrote: >>>> >>>>> Hi, considering this example : >>>>> >>>>> >>>>> modparam("acc_json", "acc_missed_flag", 6) >>>>> >>>>> failure_route[test] { >>>>> setflag(6); // MISSED_ACC, the failure will be recorded by ACC >>>>> t_flush_flags(); // This will set the flags in the newly created transaction >>>>> t_reply("500", "Service Unavailable"); >>>>> } >>>>> >>>>> This does generate an ACC event, however the to-tag is not populated, my guess this is because the TM callback is done before the to-tag is generated. >>>>> >>>>> I wonder if there is a way to populate the to-tag immediately ? >>>>> >>>>> I will dig it further, but maybe there is a trick I am missing >>>>> >>>>>