Hello all,
I've been reading through the dialog module docs again, and there seems to be a discrepancy in what's suggested in the docs. In the intro, it is stated that 'To create the dialog associated with an initial INVITE request, execute the function “dlg_manage()"'. Later on, in section "7.10" the following example code is provided: request_route { ... if(is_method("INVITE") && !has_totag()) { $dlg_ctx(timeout_route) = "DLGTIMEOUT"; $dlg_ctx(timeout_bye) = 1; } dlg_manage(); ... } In this example code, dlg_manage seems to be called for all requests, as it is not dependent on the conditional that only requests with no to-tag are to be handled.
Previously, Daniel had suggested to me in person that one also run dlg_manage() for CANCELs, and in-dialog reINVITEs, BYEs and ACKs to mitigate some buggy corner cases. Is this still the case?
What do you guys and gals do in production? Have you had to revise how you use dlg_manage in terms of calling it for initial INVITEs only vs all requests? Thanks!
BR, George
Hi George,
Not sure what 'buggy corner cases' you are referring to, but involving dlg_manage() makes sense only for initial INVITEs. IMO in that snippet, dlg_manage() should placed one row higher, within the curly brackets condition.
Regards, --Sergiu
On Mon, Nov 25, 2019 at 9:58 AM George Diamantopoulos georgediam@gmail.com wrote:
Hello all,
I've been reading through the dialog module docs again, and there seems to be a discrepancy in what's suggested in the docs. In the intro, it is stated that 'To create the dialog associated with an initial INVITE request, execute the function “dlg_manage()"'. Later on, in section "7.10" the following example code is provided: request_route { ... if(is_method("INVITE") && !has_totag()) { $dlg_ctx(timeout_route) = "DLGTIMEOUT"; $dlg_ctx(timeout_bye) = 1; } dlg_manage(); ... } In this example code, dlg_manage seems to be called for all requests, as it is not dependent on the conditional that only requests with no to-tag are to be handled.
Previously, Daniel had suggested to me in person that one also run dlg_manage() for CANCELs, and in-dialog reINVITEs, BYEs and ACKs to mitigate some buggy corner cases. Is this still the case?
What do you guys and gals do in production? Have you had to revise how you use dlg_manage in terms of calling it for initial INVITEs only vs all requests? Thanks!
BR, George
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hello George,
as already mentioned, you do dlg_manage() for initial requests. About the corner cases – I can only think about some failures in the dialog tracking due to user agent issues right now. In normal operation the module should track all in-dialog messages due to the internal callbacks. Daniel might be able to add something as well.
Cheers,
Henning
-- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.comhttps://gilawa.com/ Kamailio Merchandising – https://skalatan.de/merchandising
From: sr-users sr-users-bounces@lists.kamailio.org On Behalf Of George Diamantopoulos Sent: Monday, November 25, 2019 3:57 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: [SR-Users] dialog module: Does dlg_manage() have to be called for all requests?
Hello all,
I've been reading through the dialog module docs again, and there seems to be a discrepancy in what's suggested in the docs. In the intro, it is stated that 'To create the dialog associated with an initial INVITE request, execute the function “dlg_manage()"'. Later on, in section "7.10" the following example code is provided: request_route { ... if(is_method("INVITE") && !has_totag()) { $dlg_ctx(timeout_route) = "DLGTIMEOUT"; $dlg_ctx(timeout_bye) = 1; } dlg_manage(); ... } In this example code, dlg_manage seems to be called for all requests, as it is not dependent on the conditional that only requests with no to-tag are to be handled.
Previously, Daniel had suggested to me in person that one also run dlg_manage() for CANCELs, and in-dialog reINVITEs, BYEs and ACKs to mitigate some buggy corner cases. Is this still the case?
What do you guys and gals do in production? Have you had to revise how you use dlg_manage in terms of calling it for initial INVITEs only vs all requests? Thanks!
BR, George
Thank you both for your input. I guess I'll continue calling dlg_manage() for in-dialog requests for now until I gather more feedback, since we do cater for a large set of endpoints and several have at times exhibited various offending behaviours.
Hello,
the recommended way is to call dlg_manage() for all requests belonging to the dialog. There can be a record-routing callback executed for requests within dialog for the same purpise, but it has some constraints related to the presence of an unaltered parameter, as well as it was designed with the use of setting a flag for tracking the dialogs. Even the r-r callback is executed, doing the dlg_manage() for all requests is still safe.
Cheers, Daniel
On 26.11.19 15:25, George Diamantopoulos wrote:
Thank you both for your input. I guess I'll continue calling dlg_manage() for in-dialog requests for now until I gather more feedback, since we do cater for a large set of endpoints and several have at times exhibited various offending behaviours.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Is the idea behind doing this to provide extra safety in case the TM callbacks that feed into dialog life-cycle tracking do not work? Are there remaining known cases of this, given how long the dialog module has been around?
On Tue, Nov 26, 2019 at 03:33:19PM +0100, Daniel-Constantin Mierla wrote:
Hello,
the recommended way is to call dlg_manage() for all requests belonging to the dialog. There can be a record-routing callback executed for requests within dialog for the same purpise, but it has some constraints related to the presence of an unaltered parameter, as well as it was designed with the use of setting a flag for tracking the dialogs. Even the r-r callback is executed, doing the dlg_manage() for all requests is still safe.
Cheers, Daniel
On 26.11.19 15:25, George Diamantopoulos wrote:
Thank you both for your input. I guess I'll continue calling dlg_manage() for in-dialog requests for now until I gather more feedback, since we do cater for a large set of endpoints and several have at times exhibited various offending behaviours.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - April 27-29, 2020, in Berlin -- www.kamailioworld.com
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Daniel's recommendation must have raised quite a few eyebrows. I'd also like to know more about the logic behind this. It's not what the 'book' says.
Thanks,
On Tue, Nov 26, 2019, 7:04 PM Alex Balashov, abalashov@evaristesys.com wrote:
Is the idea behind doing this to provide extra safety in case the TM callbacks that feed into dialog life-cycle tracking do not work? Are there remaining known cases of this, given how long the dialog module has been around?
On Tue, Nov 26, 2019 at 03:33:19PM +0100, Daniel-Constantin Mierla wrote:
Hello,
the recommended way is to call dlg_manage() for all requests belonging to the dialog. There can be a record-routing callback executed for requests within dialog for the same purpise, but it has some constraints related to the presence of an unaltered parameter, as well as it was designed with the use of setting a flag for tracking the dialogs. Even the r-r callback is executed, doing the dlg_manage() for all requests is still safe.
Cheers, Daniel
On 26.11.19 15:25, George Diamantopoulos wrote:
Thank you both for your input. I guess I'll continue calling dlg_manage() for in-dialog requests for now until I gather more feedback, since we do cater for a large set of endpoints and several have at times exhibited various offending behaviours.
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - April 27-29, 2020, in Berlin --
www.kamailioworld.com
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Alex Balashov -
Daniel-Constantin Mierla -
George Diamantopoulos -
Henning Westerholt -
Sergiu Pojoga