[OpenSER-Users] [OpenSER-Devel] NEW FEATURE: dialog profiling

[Ovidiu Sas]

Hello Bogdan,

>From a PSTN point of view, a channel is allocated right at the
beginning of the call (before ringing)
If I have a gateway that if offering me 1000 channels and I don't want
to saturate the gateway, I need to add channels to the profile right
after the INVITE is sent and decrement them when the call is
terminated.  Like this I can keep track of the channel utilization per
gateway and do proper failover between gateways.

Regards,
Ovidiu Sas

On Fri, Jun 20, 2008 at 7:04 AM, Bogdan-Andrei Iancu
<bogdan at voice-system.ro> wrote:
> Hi Ovidiu,
>
> why don't you add the dialog to the profile when you receive the 200 OK in
> reply route ?
>
> Regards,
> Bogdan
>
> Ovidiu Sas wrote:
>>
>> Hello Bogdan,
>>
>> I started to play with the new profiling feature and tested a few
>> scenarios.
>>
>> Scenario 1:
>> UserA calls UserB.  UserB has call forward no answer configured and
>> activated.
>> For the first call (UserA to UserB) I tag the call with profile [caller,
>> UserA].
>> When the call is forwarded from UserB to UserC, I re-tag the call with
>> profile [caller, UserB].
>> Inspecting the profile counters via the MI interface I can see that
>> both subprofiles are incremented with 1.
>> This works fine for this scenario.
>>
>> Scenario 2:
>> UserA makes a call to PSTN.  I have two gateways configured for
>> outgoing calls to PSTN.
>> First, the call is routed to GW1 and therefore I tag the the call with
>> profile [outgoing, GW1].
>> Let's suppose that GW1 is unreachable or to busy to handle new
>> requests, and therefore I will failover the call to GW2.
>> In this case, I will re-tag the call with profile [outgoing, GW2].
>> For this scenario, I would like to keep in the profile "outgoing" the
>> the number of active calls to each gateway.
>> I think we need a new function that will give the ability to reset a
>> previous profile for the existing dialog.
>> Before re-routing the call to the second gateway, I would like to have
>> the ability to reset the previous profile set for the previous gateway
>> so I can have accurate numbers of calls per gateway.
>>
>>
>> Regards,
>> Ovidiu Sas
>>
>> On Mon, Jun 2, 2008 at 11:07 AM, Bogdan-Andrei Iancu
>> <bogdan at voice-system.ro> wrote:
>>
>>>
>>> Hi,
>>>
>>> I just committed in SVN trunk (1.4, next major release) support for
>>> dialog profiling.
>>>
>>>
>>> What dialog profiling is
>>> =========================
>>>
>>> Dialog profiling is a mechanism that helps in classifying, sorting and
>>> keeping trace of certain types of dialogs, using whatever properties of
>>> the dialog (like caller, destination, type of calls, etc). Dialogs can
>>> be dynamically added in different (and several) profile tables -
>>> logically, each profile table can have a special meaning (like dialogs
>>> outside the domain, dialogs terminated to PSTN, etc).
>>> Information provided by the profiles can be used also for doing real
>>> load-balancing - by real, I mean routing decisions based on load. So far
>>> dispatcher module can do probabilistic dispatching with no feedback on
>>> the actual load of the peer (or about the call success). See example 3 -
>>> load balancing between 2 asterisk boxes with identical capacities.
>>>
>>> Being able to actually trace the ongoing dialog, gives liberty to do
>>> more complex routing logics.
>>>
>>>
>>> There are two types of profiles:
>>>    * with no value - a dialog simply belongs to a profile. (like
>>>      outbound calls profile). There is no other additional
>>>      information to describe the dialog's belonging to the
>>>      profile;
>>>    * with value - a dialog belongs to a profile having a certain
>>>      value (like in caller profile, where the value is the
>>>      caller ID). The belonging of the dialog to the profile is
>>>      strictly related to the value.
>>>
>>> A dialog can be added to multiple profiles in the same time.
>>>
>>>
>>>
>>> What it should be used for
>>> ===========================
>>>
>>> Example 1:
>>>
>>> Count the calls terminating to PSTN in order to monitor the load. Before
>>> routing the call the GW, check if the number of ongoing calls (to the
>>> GW) do not exceed some value.
>>>
>>>
>>> modparam("dialog","profiles_no_value","pstn_calls")
>>> ....
>>> /* do some checking */
>>> get_dialog_size("pstn_calls","$avp(cnt)");
>>> if ( $avp(cnt) > 32 ) {
>>>   sl_send_reply("500","GW full");
>>>   exit;
>>> }
>>> set_dlg_profile("pstn_calls");
>>> /* route to the GW */
>>> .....
>>>
>>>
>>>
>>> Example 2:
>>>
>>> Allow only 2 parallel calls per user - use a profile with value to count
>>> the outgoing calls for each subscriber
>>>
>>> modparam("dialog","profiles_with_value","caller")
>>> ....
>>> /* do some checking */
>>> get_dialog_size("caller","$fu","$avp(cnt)");
>>> if ( $avp(cnt) > 2 ) {
>>>   sl_send_reply("403","Not allowed");
>>>   exit;
>>> }
>>> set_dlg_profile("caller","$fu");
>>> /* route the call */
>>> .....
>>>
>>>
>>>
>>> Example 3:
>>>
>>> Do load balancing between 2 asterisk boxes with identical capacities -
>>> use a profile with values to count the ongoing calls through each
>>> Asterisk box.
>>>
>>> modparam("dialog","profiles_with_value","asterisk")
>>> ....
>>> /* do some checking */
>>> get_dialog_size("asterisk","box1","$avp(cnt1)");
>>> get_dialog_size("asterisk","box2","$avp(cnt2)");
>>>
>>> if ( $avp(cnt1) > $avp(cnt2) ) {
>>>   setdsturi("sip:IP_BOX2:PORT_BOX2");
>>>   set_dlg_profile("asterisk","box2");
>>> } else {
>>>   setdsturi("sip:IP_BOX1:PORT_BOX1");
>>>   set_dlg_profile("asterisk","box1");
>>> }
>>> /* route the call */
>>> .....
>>>
>>> Of course, this can be extended for asymmetric load or for multiple
>>> boxes.
>>>
>>>
>>>
>>>
>>>
>>> Regards,
>>> Bogdan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at lists.openser.org
>>> http://lists.openser.org/cgi-bin/mailman/listinfo/devel
>>>
>>>
>>
>>
>
>