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
<miconda(a)gmail.com> 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/