Hello,
I am using the dialog module to time out excessively long calls:
modparam("dialog", "default_timeout", 21600) # 6 hours modparam("dialog", "dlg_flag", 2) ... route { ... ... setflag(2); $dlg_ctx(timeout_bye) = 2; ... ... if(!t_relay()) sl_reply_error(); }
I have two unrelated questions:
1) Why does $dlg_ctx(timeout_bye) work here? My understanding is that $dlg_ctx(...) is a PV namespace container that exposes some aspect of the allocated dialog tracking structure. The dialog structure is created via a TM->dialog callback triggered by t_relay(); why is it possible to access it prior to that point?
2) The spoofed BYEs that are generated by the proxy with this setting do not show up as sequential requests, nor are catchable in script at all. As a result, BYE events are not written to CDRs with 'acc' and I have no way of knowing when the call actually closed.
What is the most efficient and canonical solution to this problem?
I can think of two:
(a) Define a $dlg_ctx(timeout_route) and have it write a BYE event artificially using acc_db_request().
(b) Loop the BYE request back to the proxy with some sort of differentiating URI parameter or similar that causes it to be dropped instead of forwarded. But this is really nasty.
What is your suggestion?
Thanks,
On 04/19/2010 02:00 AM, Alex Balashov wrote:
(a) Define a $dlg_ctx(timeout_route) and have it write a BYE event artificially using acc_db_request().
Well, this isn't going to work.
I tried having it write a "201 Initial" event that my triggers can postprocess as though it were a BYE, a la:
acc_db_request("201 Dialog Timeout", "acc");
Unfortunately, none of the usual request data is populated when the synthetic BYE is generated, including From URI, Call-ID, etc. The request method is "OPTIONS" for some reason, and the Call-ID is "123." With this, there is no way to pass this information to "acc," even with a manual SQL query, because this information is not available in the timeout route.
I don't know what to do here. Help appreciated.
Maybe the solution here is to generate a synthetic custom request with $uac_req() and uac_send_req(), like with method SYNTHETIC_BYE?
The problem is that I cannot populate it with the From URI, Call-ID, etc. because that information is not available in the timeout-triggered route to begin with.
2010/4/19 Alex Balashov abalashov@evaristesys.com:
- The spoofed BYEs that are generated by the proxy with this setting do not
show up as sequential requests, nor are catchable in script at all. As a result, BYE events are not written to CDRs with 'acc' and I have no way of knowing when the call actually closed.
Have you tryed local_route to manage it? It's also called event_route in kamailio 3.0: http://www.kamailio.org/dokuwiki/doku.php/features:new-in-3.0.x#event_route
On 04/19/2010 03:28 AM, Iñaki Baz Castillo wrote:
2010/4/19 Alex Balashovabalashov@evaristesys.com:
- The spoofed BYEs that are generated by the proxy with this setting do not
show up as sequential requests, nor are catchable in script at all. As a result, BYE events are not written to CDRs with 'acc' and I have no way of knowing when the call actually closed.
Have you tryed local_route to manage it? It's also called event_route in kamailio 3.0: http://www.kamailio.org/dokuwiki/doku.php/features:new-in-3.0.x#event_route
Interesting idea.
"event_route[tm:local-request] - executed by tm modules when a local SIP request is generated (former local_route in 1.5.x)"
Do we know for a fact that in this particular aspect of the dialog module (synthetic BYE on timeout), the local request generation is plumbed back through TM in a way that would cause this route to be triggered?
2010/4/19 Alex Balashov abalashov@evaristesys.com:
Have you tryed local_route to manage it? It's also called event_route in kamailio 3.0:
http://www.kamailio.org/dokuwiki/doku.php/features:new-in-3.0.x#event_route
Interesting idea.
"event_route[tm:local-request] - executed by tm modules when a local SIP request is generated (former local_route in 1.5.x)"
Do we know for a fact that in this particular aspect of the dialog module (synthetic BYE on timeout), the local request generation is plumbed back through TM in a way that would cause this route to be triggered?
AFAIR the main purpose of local_route was to handle the locallly generated BYE for accounting purposes.
On 04/19/2010 03:36 AM, Iñaki Baz Castillo wrote:
AFAIR the main purpose of local_route was to handle the locallly generated BYE for accounting purposes.
I defined an event_route[tm:local-request] but it does not appear to fire in this scenario. Is it supposed to? Is there a possibility that 'dialog' synthesises the BYE without using TM bindings?
On 04/19/2010 03:50 AM, Alex Balashov wrote:
On 04/19/2010 03:36 AM, Iñaki Baz Castillo wrote:
AFAIR the main purpose of local_route was to handle the locallly generated BYE for accounting purposes.
I defined an event_route[tm:local-request] but it does not appear to fire in this scenario. Is it supposed to? Is there a possibility that 'dialog' synthesises the BYE without using TM bindings?
If you look in modules_k/dialog/dlg_req_within.c:dlg_bye_all(), it calls the locally defined send_bye(), which does appear to use TMCB:
set_uac_req(&uac_r, &met, hdrs, NULL, dialog_info, TMCB_LOCAL_COMPLETED, bye_reply_cb, (void*)cell);
result = d_tmb.t_request_within(&uac_r);
So, why doesn't the event_route for local requests get called?
On 04/19/2010 03:54 AM, Alex Balashov wrote:
On 04/19/2010 03:50 AM, Alex Balashov wrote:
On 04/19/2010 03:36 AM, Iñaki Baz Castillo wrote:
AFAIR the main purpose of local_route was to handle the locallly generated BYE for accounting purposes.
I defined an event_route[tm:local-request] but it does not appear to fire in this scenario. Is it supposed to? Is there a possibility that 'dialog' synthesises the BYE without using TM bindings?
If you look in modules_k/dialog/dlg_req_within.c:dlg_bye_all(), it calls the locally defined send_bye(), which does appear to use TMCB:
set_uac_req(&uac_r, &met, hdrs, NULL, dialog_info, TMCB_LOCAL_COMPLETED, bye_reply_cb, (void*)cell);
result = d_tmb.t_request_within(&uac_r);
So, why doesn't the event_route for local requests get called?
Then again, maybe problem has something to do with this:
Apr 19 04:55:04 diminuendo-1 /usr/local/sbin/kamailio[29521]: CRITICAL: dialog [dlg_hash.c:591]: bogus event 6 in state 2 for dlg 0xb3821150 [3678:1255894621] with clid '1868cddf629ea8612fb1e116666da251@208.52.173.7' and tags 'as3d985c5d' '' Apr 19 04:55:04 diminuendo-1 /usr/local/sbin/kamailio[29521]: INFO: [R-MAIN:1868cddf629ea8612fb1e116666da251@208.52.173.7] -> Other sequential ACK received from 208.52.173.7:5060 Apr 19 04:55:10 diminuendo-1 /usr/local/sbin/kamailio[29528]: WARNING: dialog [dlg_timer.c:243]: start with tl=0xb3821180 tl->prev=0xb37f98d0 tl->next=0xb37f98d0 (50007729) at 50007729 and end with end=0xb37f98d0 end->prev=0xb3821180 end->next=0xb3821180 Apr 19 04:55:10 diminuendo-1 /usr/local/sbin/kamailio[29528]: WARNING: dialog [dlg_timer.c:246]: getting tl=0xb3821180 tl->prev=0xb37f98d0 tl->next=0xb37f98d0 with 50007729 Apr 19 04:55:10 diminuendo-1 /usr/local/sbin/kamailio[29528]: WARNING: dialog [dlg_timer.c:252]: end with tl=0xb37f98d0 tl->prev=0xb3821180 tl->next=0xb3821180 and d_timer->first.next->prev=(nil) Apr 19 04:55:10 diminuendo-1 /usr/local/sbin/kamailio[29523]: WARNING: dialog [dlg_req_within.c:172]: inconsitent dlg timer data on dlg 0xb3821150 [3678:1255894621] with clid '1868cddf629ea8612fb1e116666da251@208.52.173.7' and tags 'as3d985c5d' 'SDff59b99-ac3f4687+1+a4c0010+dc2edda'
On 4/19/10 9:54 AM, Alex Balashov wrote:
On 04/19/2010 03:50 AM, Alex Balashov wrote:
On 04/19/2010 03:36 AM, Iñaki Baz Castillo wrote:
AFAIR the main purpose of local_route was to handle the locallly generated BYE for accounting purposes.
I defined an event_route[tm:local-request] but it does not appear to fire in this scenario. Is it supposed to? Is there a possibility that 'dialog' synthesises the BYE without using TM bindings?
If you look in modules_k/dialog/dlg_req_within.c:dlg_bye_all(), it calls the locally defined send_bye(), which does appear to use TMCB:
set_uac_req(&uac_r, &met, hdrs, NULL, dialog_info, TMCB_LOCAL_COMPLETED, bye_reply_cb, (void*)cell); result = d_tmb.t_request_within(&uac_r);So, why doesn't the event_route for local requests get called?
event_route should be called in this case. Can you test with dlg bridge to see if the event route is executed?
Cheers, Daniel
On 04/19/2010 05:15 AM, Daniel-Constantin Mierla wrote:
event_route should be called in this case. Can you test with dlg bridge to see if the event route is executed?
I have not had a chance to test this with dlg_bridge() yet, but it clearly is not working so well with dialog timeout/BYE.
To accomplish my goal (accounting for internally generated BYEs), what else can I do? Is $dlg(...) exposed within the timeout_route? If it is, and I can fish the Call-ID out of it, that is probably enough for me to cut a custom CDR event, though it will not be possible to use acc_db_request() to do it because it uses db_extras which contain things like:
ani=$fU
... which are R/O, and not populated in the timeout route.
I understand why the timeout route has no real information; the timeout_route feature and the timeout_bye feature are not actually related, and can be used independently of each other, so there is not an underlying "request" driving the firing of the timeout_route.
At the same time, it makes the timeout_route rather useless if it is completely acontextual and has no information about the dialog in connection with which it is being called.
On 4/20/10 8:36 PM, Alex Balashov wrote:
On 04/19/2010 05:15 AM, Daniel-Constantin Mierla wrote:
event_route should be called in this case. Can you test with dlg bridge to see if the event route is executed?
I have not had a chance to test this with dlg_bridge() yet, but it clearly is not working so well with dialog timeout/BYE.
Do you get it for some other case? Can you check the event route name? Have you run in debug mode (it should be a debug message when the event route is executed)?
To accomplish my goal (accounting for internally generated BYEs), what else can I do? Is $dlg(...) exposed within the timeout_route?
trying will reveal that :-)
Cheers, Daniel
If it is, and I can fish the Call-ID out of it, that is probably enough for me to cut a custom CDR event, though it will not be possible to use acc_db_request() to do it because it uses db_extras which contain things like:
ani=$fU
... which are R/O, and not populated in the timeout route.
I understand why the timeout route has no real information; the timeout_route feature and the timeout_bye feature are not actually related, and can be used independently of each other, so there is not an underlying "request" driving the firing of the timeout_route.
At the same time, it makes the timeout_route rather useless if it is completely acontextual and has no information about the dialog in connection with which it is being called.
On 4/20/10 8:36 PM, Alex Balashov wrote:
On 04/19/2010 05:15 AM, Daniel-Constantin Mierla wrote:
event_route should be called in this case. Can you test with dlg bridge to see if the event route is executed?
I have not had a chance to test this with dlg_bridge() yet, but it clearly is not working so well with dialog timeout/BYE.
seemed it was not enabled, can you try again with latest git?
Cheers, Daniel
To accomplish my goal (accounting for internally generated BYEs), what else can I do? Is $dlg(...) exposed within the timeout_route? If it is, and I can fish the Call-ID out of it, that is probably enough for me to cut a custom CDR event, though it will not be possible to use acc_db_request() to do it because it uses db_extras which contain things like:
ani=$fU
... which are R/O, and not populated in the timeout route.
I understand why the timeout route has no real information; the timeout_route feature and the timeout_bye feature are not actually related, and can be used independently of each other, so there is not an underlying "request" driving the firing of the timeout_route.
At the same time, it makes the timeout_route rather useless if it is completely acontextual and has no information about the dialog in connection with which it is being called.
On 04/21/2010 04:37 AM, Daniel-Constantin Mierla wrote:
On 4/20/10 8:36 PM, Alex Balashov wrote:
On 04/19/2010 05:15 AM, Daniel-Constantin Mierla wrote:
event_route should be called in this case. Can you test with dlg bridge to see if the event route is executed?
I have not had a chance to test this with dlg_bridge() yet, but it clearly is not working so well with dialog timeout/BYE.
seemed it was not enabled, can you try again with latest git?
Yep, I will. I saw the git commit. Thank you. :-)
-
Alex Balashov -
Daniel-Constantin Mierla -
Iñaki Baz Castillo