[sr-dev] ACC events missing to-tag when doing t_reply

Julien Chavanton jchavanton at gmail.com
Sat Aug 1 01:39:38 CEST 2020


haha, found the mistake  that was so disturbing ...
%*.s >> %.*s

Not my best day !

I did not know this would remain uncaught by the compiler

On Fri, Jul 31, 2020 at 4:17 PM Julien Chavanton <jchavanton at gmail.com>
wrote:

> 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 <jchavanton at gmail.com>
> 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 <jchavanton at gmail.com>
>> 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 <jchavanton at 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 at 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 at 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
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20200731/d105a406/attachment-0001.htm>


More information about the sr-dev mailing list