Patches item #1907645, was opened at 2008-03-05 06:33
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1907645&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: 9
Private: No
Submitted By: Ovidiu Sas (osas)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: dialog: dialog profiling
Initial Comment:
Here is a patch for the dialog module that will allow dialog profiling. This
new enhancement to the dialog module will keep track of the number of
dialogs/calls per 'profile'.
How is it working?
Two new dialog params are available:
1. dlg_index_avp
2. profiling_table_size
The "profiling_table_size" parameter will define the maximum numbers of
profiles. If a call needs to be accounted, the profile index shall be stored
into the "dlg_index_avp" avp. If the "dlg_index_avp" is not set (i.e. NULL),
the call will not be profiled.
A new pseudo variable is available for holding the number of dialogs/calls per
profile: "DLG_profile".
In order to get the number of dialogs/calls associated to a profile, the
profile id must be passed as an index to the "DLG_profile" PV. The index must
follow into the [0,profiling_table_size range-1] range.
Config example:
modparam("dialog", "dlg_flag", 4)
modparam("dialog", "dlg_index_avp", "$avp(i:600)")
modparam("dialog", "profiling_table_size", 10)
...
/* print the number of calls for profile 2 */
xlog("L_INFO","$(DLG_profile[2])\n");
/* or */
$var(profiling) = 2;
xlog("L_INFO","$(DLG_profile[$var(profiling)])\n");
...
if (profiling) {
/* account the call into profile 2*/
$avp(i:600) = "2";
/* or */
$avp(i:600) = 2;
/* or */
$var(profiling) = 2;
$avp(i:600) = $var(profiling);
}
...
This patch is presented as a proof of concept and it is provided against
current stable version of openser 1.3.
I would like to collect more feedbacks before proceeding with a full
implementation for 1.4.
Bogdan, will this work for you? I know that you had something similar in your
TODO list, so I would like to have your opinion about this patch and merge the
efforts in order to get this asap in the gate.
Regards,
Ovidiu Sas
----------------------------------------------------------------------
>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-05-11 00:43
Message:
Logged In: YES
user_id=1275325
Originator: NO
Hi Ovidiu,
I hope I will finish the work on this patch during the next days.
Regards,
Bogdan
----------------------------------------------------------------------
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-04-23 17:11
Message:
Logged In: YES
user_id=1275325
Originator: NO
Hi Ovidiu,
I'm right now working on it (on the general approach I was talking about)
and it will be ready in the next week I think...But is work in progress ;)
Regards,
Bogdan
----------------------------------------------------------------------
Comment By: Ovidiu Sas (osas)
Date: 2008-04-23 01:03
Message:
Logged In: YES
user_id=1395524
Originator: YES
Hello Bogdan,
Do you have any updates/comments on this?
Regards,
Ovidiu Sas
----------------------------------------------------------------------
Comment By: Ovidiu Sas (osas)
Date: 2008-03-10 20:51
Message:
Logged In: YES
user_id=1395524
Originator: YES
Hello Bogdan,
If I understand this correctly, you want to add several profiling tables
(each one with it's own avp as index):
- DLG_id_profile (based on index - this is the initial proof of concept
implementation);
- fixed size table initialized at startup via module param.
- DLG_clid_profile (based on CLID, using a hash table to retrieve the
profiling value);
- dynamic table (will grow as elements are added).
- DLG_ip_profile (based on IP, using a hash table to retrieve the
profiling value);
- dynamic table (will grow as elements are added).
Note: maybe we can collapse the DLG_clid_profile and DLG_ip_profile into a
single generic table: DLG_hash_profile.
This is fine by me (several choices is always a plus).
Also, I would like to have more input from the community. More opinions
on this issue will draw better requirements.
Regards,
Ovidiu Sas
----------------------------------------------------------------------
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-03-10 17:22
Message:
Logged In: YES
user_id=1275325
Originator: NO
Hi Ovidiu,
I was thinking to something a bit more general and easy to use in the same
time - you can do profiling based on several attributes (like in your case,
with multiple profiling tables), but also to have values for the attributes
to allow you to group the dialogs.
Ex:
profile I - based on caller (attribute) ; value is the caller ID - you can
see how many calls a certain user has
profile II - based on GW destination (attribute) ; values is the IP of the
outgoing GW - you can have the load on each GW.
Regards,
Bogdan
----------------------------------------------------------------------
Comment By: Ovidiu Sas (osas)
Date: 2008-03-07 15:24
Message:
Logged In: YES
user_id=1395524
Originator: YES
Hello Bogdan,
That is correct. You can perform IP to index translations using
allow_trusted or some other mechanism:
allow_trusted ->
http://www.openser.org/docs/modules/1.4.x/permissions.html#AEN496
The carrierroute module will have an enhancement to provide a tag into an
avp after the routing is performed.
I don't think the mapping of the IP (or a generic value) into an tag/index
should belong to the dialog module.
The index inside the PV can be provided as an integer or a string and this
provides some flexibility.
If you want to make it more generic, that's fine with me. I was looking
for something fast and simple.
Regards,
Ovidiu Sas
----------------------------------------------------------------------
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-03-07 11:29
Message:
Logged In: YES
user_id=1275325
Originator: NO
Hi Ovidiu,
One question: the profiling can be used only with types (you select the
profiling index), but not with values also (like a do profiling for
destinations and I use as value the IP address).
Regards,
Bogdan
----------------------------------------------------------------------
Comment By: Ovidiu Sas (osas)
Date: 2008-03-06 19:38
Message:
Logged In: YES
user_id=1395524
Originator: YES
Hi Bogdan,
I'm glad that we found common ground here :)
If you want to merge this out in 1.4, that's fine with me.
As I mentioned previously, this was a proof of concept work, so the code
is not optimized. For instance, we should use atomic locks for storing
profiling counters.
Let me know when you can commit this in, and I will add some MI commands
for retrieving/manipulating the profiling counters.
Regards,
Ovidiu Sas
----------------------------------------------------------------------
Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2008-03-06 19:17
Message:
Logged In: YES
user_id=1275325
Originator: NO
Hi Ovidiu,
This sounds interesting, especially as it overlaps with some of my ideas.
Give me some time to work out a merge.
Thanks and regards,
Bogdan
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743022&aid=1907645&group_id=139143
_______________________________________________
Devel mailing list
Devel@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/devel
