Patches item #1872331, was opened at 2008-01-15 21:29 Message generated for change (Comment added) made by dan_pascu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1872331&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: Ovidiu Sas (osas) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: dialog: get_direction() api enhancement Initial Comment: Sometimes, modules that are sitting on top of the dialog module needs to know the direction of a message (upstream or downstream). The following patch will enhance the dialog callback api with get_direction() function. The prototype: unsigned int get_direction(struct dlg_cell *dlg, struct sip_msg* msg); and it will return one of the following values: DLG_DIR_UPSTREAM # the direction of the initial INVITE DLG_DIR_DOWNSTREAM # the direction of the first reply DLG_DIR_NONE # in case of an error ---------------------------------------------------------------------- >Comment By: Dan (dan_pascu) Date: 2008-03-18 21:24 Message: Logged In: YES user_id=1296758 Originator: NO There is at least another module, one I'm working on and that will be pushed to svn soon. I already have this in test for 1.3 and quite frankly I do not want to maintain 2 versions for it. A backward incompatible change in the API is never a good thing, no matter how little code depends on it, especially when it can be avoided. We should also consider that there may be non-public custom modules that people may have written and such incompatible changes will make maintaining them more complicated than necessary. The issue is not as much making a small change, is maintaining 2 versions for the code. As for the extra memory requirements, I do not think that is really a concern. The direction can be stored in a 1 bit flag. I'm not sure about the race issues. Someone more knowledgeable about the dialog internals can clarify if storing the direction on the dialog is even poossible in the given context. If it is not possible then we must live with an API change, but if possible, let's try to find a solution that is backward compatible. ---------------------------------------------------------------------- Comment By: Ovidiu Sas (osas) Date: 2008-03-18 20:46 Message: Logged In: YES user_id=1395524 Originator: YES Hello Dan, So far, there is one single module on top of the dialog that needs to be updates (the sst module) and the API change is pretty simple. Right now, the direction is computed for every request, but not computed for responses. Storing it into the dialog cell means more memory and special cases for requests vs responses: - for requests it is already computed, - for responses needs to be computed. So we will need to track the type of the SIP message that is processes in order to distinguish between the two (and we can have races between a real SIP message - we have several callbacks for the same SIP reply - and a tm timer timeout for destroying the transaction). Let's hear other's opinions on this matter and we will go to the path that best fits all. Regards, Ovidiu Sas ---------------------------------------------------------------------- Comment By: Dan (dan_pascu) Date: 2008-03-18 20:29 Message: Logged In: YES user_id=1296758 Originator: NO Ovidiu, I don't like this approach because it is very disruptive. It adds an unnecessary API change that will force one to go back and fix every module on top of the dialog module and also maintain distinct versions of them for distinct versions of openser. I think a more practical approach would be to store the direction on the dialog structure (a flag) wherever it processes a message belonging to the dialog and then offer a function that can be called inside a callback that returns the direction flag from the dialog structure, thus avoiding an API change that is not backward compatible and also avoiding to compute it everytime it is asked for. ---------------------------------------------------------------------- Comment By: Ovidiu Sas (osas) Date: 2008-03-18 19:47 Message: Logged In: YES user_id=1395524 Originator: YES Hello Bogdan, Here's another version of the patch. This one will reuse the already computed dialog, but instead of creating a new API, it enhances the old one by passing the direction as a parameter to the callback function (sst module updated). -void run_dlg_callbacks( int type , struct dlg_cell *dlg, struct sip_msg *msg); +void run_dlg_callbacks( int type , struct dlg_cell *dlg, struct sip_msg *msg, unsigned int direction); Please let me know your thoughts. Regards, Ovidiu Sas File Added: dialog_direction.patch.gz ---------------------------------------------------------------------- Comment By: Ovidiu Sas (osas) Date: 2008-03-03 17:52 Message: Logged In: YES user_id=1395524 Originator: YES Hi Bogdan, That was my initial approach, but I found it kind of intrusive because not all the modules sitting on top of the dialog will care about the direction, that's the reason that I went with the current approach. I can rework the patch to follow that approach. And if we follow your approach, another option would be to pass the direction in the callback functions along with the did, type, msg and param instead of creating this new API method. Let me know your thoughts. Regards, Ovidiu Sas ---------------------------------------------------------------------- Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2008-03-03 17:34 Message: Logged In: YES user_id=1275325 Originator: NO Hi Ovidiu, I delayed a bit the patch as I wanted to re-work it a bit - I think it is not really necessary to detect the direction at each function call, as the direction is detected at match time. So, more or less we just need to remember the direction :) Regards, Bogdan ---------------------------------------------------------------------- Comment By: Ovidiu Sas (osas) Date: 2008-03-01 19:30 Message: Logged In: YES user_id=1395524 Originator: YES If there are no objections, I will push this patch in next week. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1872331&group_id=139143 _______________________________________________ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
