Patches item #1642890, was opened at 2007-01-23 12:41 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1642890&group_id=139143
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: ver devel Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kobi Eshun (ekobi) Assigned to: Nobody/Anonymous (nobody) Summary: 'bye2bye' UA module prototype Initial Comment: Hi, Attached are two patches implementing a prototype 'bye2bye' UA module that cheaply fakes end-to-end BYE requests -- it's a watchdog that enforces metered call duration. One of the patches augments the existing dialog module so that it caches to/from contact and CSeq values; the other implements the new module. I'm soliciting feedback, in particular: Q1 - is there enough general interest in this functionality to warrant further development? Q2 - is there some additional functionality that makes sense? Q3 - would it be better implemented as an integrated extention to the existing dialog module? Use of the module is very straightforward: - Define the module flag parameter that will enable the watchdog on a per-dialog basis. This is used in conjunction with the dialog module flag defined by 'dlg_flag.' - Optionally define the module parameters 'bye2bye_headers,' 'bye2bye_to_next_hop,' and 'bye2bye_from_next_hop.' - set the value of the dialog 'timeout_avp' as required for each dialog that will be monitored. -- kobi ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-24 06:33 Message: Logged In: NO Dan, Are you suggesting that the dialog module should use the cookie if present (for optimization purposes) but still check the CallID: and To: field to make sure it does not miss an altered request in case the dialog cookie is missing ? Or do you think we need to go even further and totally remove the dialog cookie and only use pristine header to identify the dialog matching a particular request ? I don't see all the implications in terms of speed, but from what I understand the cookie method was chosen for performance reasons, because we benefit from the fact that the RR: header is already parsed and stored. What do you think ? Cheers, Jerome Martin ---------------------------------------------------------------------- Comment By: Dan (dan_pascu) Date: 2007-01-24 06:21 Message: Logged In: YES user_id=1296758 Originator: NO There is another thing that needs to be considered when building functionality that needs strict control over the message flow in a dialog, like the one that this patch wishes to implement. The dialog module has a serious shortcoming that prevents such functionality to be reliable. The dialog module identifies in-dialog requests by using a cookie in the Record-Route header. This cookie can be removed or altered by the endpoints (on purpose or because of a flawed implementation). If this happens those requests will not be identified as belonging to the dialog and will be ignored in computing dialog related state. Now any functionality that needs strict control over the message flow in a dialog (like for example implementing a prepaid system where fake BYEs need to be sent when the user credit has expired) cannot be reliably based on the dialog module in its current form. For example if the endpoints send some in-dialog requests with the cookie missing or altered, they will not be identified by the proxy as belonging to the dialog and the CSeq information will not be updated. Then later when the fake BYEs are sent, they will have an old CSeq number which will be rejected by the endpoints because it was already used and the call will not be closed. In this case the call will continue past the credit limit and there is nothing the proxy can do to close it. All of this happens because in the current implementation of the dialog module, the endpoints have control over which messages will be detected as being part of the dialog and which not. ---------------------------------------------------------------------- Comment By: Klaus Darilion (klaus_darilion) Date: 2007-01-24 05:38 Message: Logged In: YES user_id=1318360 Originator: NO I agree with Dan. Please see my feature request with some details about the data which should be stored inside the dialog structure. https://sourceforge.net/tracker/index.php?func=detail&aid=1632996&group_id=139143&atid=743023 ---------------------------------------------------------------------- Comment By: Dan (dan_pascu) Date: 2007-01-24 05:32 Message: Logged In: YES user_id=1296758 Originator: NO For this functionality to be really useful, much more information needs to be stored per dialog and be put in the faked BYEs. One thing that comes to mind is the Route headers that would be present in the BYEs sent by the endpoints themselves as a result of Record-Route information added by proxies that wish to stay in the path. The fake BYEs must follow the same path that the native BYEs sent by the endpoints would have, for 2 reasons: 1. You may not have direct access to the endpoints because you do not have the NAT with them open, so you need to send via the proxies that have. 2. If you send directly to the endpoints, the other proxies that wished to stay in the path by using Record-Routes will be unaware of the dialog that just ended and may make wrong assumptions and wrong decisions about the call. Without adding the Route heders, the functionality's usefulness is limited to calls where there is only 1 proxy between the endpoints. ---------------------------------------------------------------------- Comment By: Bogdan (bogdan_iancu) Date: 2007-01-24 04:07 Message: Logged In: YES user_id=1275325 Originator: NO Hi Martin, I do not disagree with you, but 'm exploring the possibilities :). My thoughs were to keep dialog module as a container for the basic dialog functionalities - creating, tracing and terminating them. Based on this, I see the existing module a good place to have a geenric function for ending a dialog. Maybe more new modules will want to do dialog cancelling and I see no reason not to have everything together. If more complex dialog-processing modules will show in time, they will all use the basic dialog functions from "dialog" module. At least this is my personal view on the matter. Shortly : 1) keep in dialog module all the basic functionlities (add, view, delete) 2) add more modules for complex dialog-based scenarios Regards, Bogdan ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-24 03:06 Message: Logged In: NO Hi Bogdan, It seems you disagree with my point of keeping things separate, which is fine by me. I understand the reasons, but still I am afraid this can grow out of reach quick. As I mentionned before, I perceive the dialog-related features as having the highest growth-potential of the whole OpenSER codebase, and I would not like to see it become nuclear-factory-sized as I am sure many people will have "related features" to add. However, you're the one with CVS access so you probably know better :-) Still, I would appreciate if you took some time when you're a bit less busy to share your thoughts in more depth on that matter. Still, the important thing is that Kobi initiative is really one of those that WILL attract users and typically enhances OpenSER in a manner that will seduce many people. Way to go ! (and in fact, I'm happy disregarding if this ends up in a separate module or in dialog :-) Best Regards, Jerome Martin ---------------------------------------------------------------------- Comment By: Bogdan (bogdan_iancu) Date: 2007-01-24 02:52 Message: Logged In: YES user_id=1275325 Originator: NO Hi Kobi, yes, the interes exists and it si huge :) my original plan was to have the dialog module to encapsulate dialog-related functionalities. First was to be able to track down dialogs and possible to do count based on different criteria (see the features request comming from Klaus). I would prefer to stick to this original plan and continue extending the dialog module (instead of adding small new modules) as time as there is related functionality. regards, bogdan ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-01-24 02:21 Message: Logged In: NO Hello Kobi, I am myself in the process of writing some code to implement this functionnality myself, so I am very enthusiastic about you submission. If you want to talk about it (help, debugging, ideas, discussion), I can be reached at [EMAIL PROTECTED] My own code is not a module but an external piece of code called by exec(), so I'll probably dump it in favor to your approach which is of course cleaner. As of your questions, here are my answers : Q1 - is there enough general interest in this functionality to warrant further development? Well, given the number of threads I've seen on SER/OPENSER MLs, I would say everybody's looking for a way to cut calls. Currently, I've only seen external perl scripts using FIFO UA features to acheive this (and I'm doing the same thing). Q2 - is there some additional functionality that makes sense? In order to enlarge the module's userbase, an ideal addition would be being able to trigger the end2end BYE messages from an external source in addtion to timed calls. Q3 - would it be better implemented as an integrated extention to the existing dialog module? I would keep both modules separate for now, as I suspect many more functionnalities will arise that use dialog statefullness, and a global policy that makes sense would rather be keeping things clean, small and maintainable. But that's just IMHO. Cheers, Jerome Martin ---------------------------------------------------------------------- Comment By: Kobi Eshun (ekobi) Date: 2007-01-23 12:42 Message: Logged In: YES user_id=1039134 Originator: YES File Added: dialog.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1642890&group_id=139143 _______________________________________________ Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
