Hi, Makes perfect sense. Hope this thread will help someone with the same doubt in the future.
We manage to workaround by setting a dlg_var() with the name of our traffic profile. It works for our use-case. Thanks! Andre On Tue, Apr 20, 2021 at 12:05 PM Daniel-Constantin Mierla <[email protected]> wrote: > > Hello, > > On 14.04.21 16:20, Andre Barbosa wrote: > > Hi guys, > > > > I was trying to read the profile of a dialog on the > > event_route[dialog:end] and noticed that dialog profiles are not > > available at this point. > > > > My cfg code that doesn't work: > > > > event_route[dialog:end] { > > if (is_in_profile("orig")) { > > xinfo("this dialog belongs to a orig call\n"); > > route(EMIT_ORIG_CALL_ENDED); > > } > > } > > > > Log: > > | 3(12) INFO: <script>: Managing dialog... for BYE > > | 3(12) ERROR: *** cfgtrace:dbg_cfg_trace(): > > request_route=[DEFAULT_ROUTE] c=[/etc/kamailio/kamailio.cfg] l=263 > > a=24 n=dlg_manage > > | 3(12) DEBUG: dialog [dlg_hash.c:887]: internal_get_dlg(): ref dlg > > 0x7f8edda138e0 with 1 -> 3 > > | 3(12) DEBUG: dialog [dlg_hash.c:891]: internal_get_dlg(): dialog > > callid='96af5356-4663-4f5d-b6ca-c0d2381c992a' found on entry 16097, > > dir=1 to-tag='5' > > | 3(12) DEBUG: dialog [dlg_profile.c:536]: set_current_dialog(): > > setting current dialog [16097:1304] > > | 3(12) DEBUG: dialog [dlg_hash.c:1290]: next_state_dlg(): dialog > > 0x7f8edda138e0 changed from state 4 to state 5, due event 7 (ref 3) > > | 3(12) DEBUG: dialog [dlg_hash.c:1071]: dlg_ref_helper(): ref op on > > 0x7f8edda138e0 with 1 from dlg_handlers.c:1799 > > | 3(12) DEBUG: dialog [dlg_hash.c:1075]: dlg_ref_helper(): ref dlg > > 0x7f8edda138e0 with 1 -> 4 > > | 3(12) DEBUG: dialog [dlg_handlers.c:1803]: dlg_run_event_route(): > > executing event_route 3 on state 5 > > | 3(12) ERROR: *** cfgtrace:dbg_cfg_trace(): local_route=[dialog:end] > > c=[/etc/kamailio/kamailio.cfg] l=453 a=16 n=if > > | 3(12) ERROR: *** cfgtrace:dbg_cfg_trace(): local_route=[dialog:end] > > c=[/etc/kamailio/kamailio.cfg] l=448 a=25 n=is_in_profile > > > > > > Looking at code I can see that dialog profiles are cleaned on > > next_state_dlg() when the dialog moves from state 4 to state 5 > > > > /* remove the dialog from profiles when is not no longer active */ > > if(*new_state==DLG_STATE_DELETED && dlg->profile_links!=NULL > > && *old_state!=*new_state) { > > destroy_linkers(dlg->profile_links); > > dlg->profile_links = NULL; > > } > > > > > > My question for the more experienced guys: is this behaviour by design? > > Can we change it to only clean profiles at same time we clean dlg_vars > > for example? > > > Because the profiles are used quite often for setting the limits of > active calls, they are destroyed when the call is switched to terminated > state, so it does not block an attempt to make a new call. > > If anyone wants to change this behaviour, it has to make it based on a > modparam, so current behavior is preserved. > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla -- www.asipto.com > www.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio Advanced Training - Online > May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone) > * https://www.asipto.com/sw/kamailio-advanced-training-online/ > _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
