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@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
Seems to work, I will complete the modifications and make an MR ...
On Fri, Jul 31, 2020 at 12:30 AM Julien Chavanton jchavanton@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@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@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@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@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
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@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@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@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@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 jchavanton@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@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@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@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@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
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@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@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@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@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@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@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
-
Julien Chavanton