[SR-Users] Dialog module with 2 servers and 2 separate databases.
Daniel-Constantin Mierla
miconda at gmail.com
Mon Dec 13 15:12:13 CET 2010
Hello,
one option you can do is to write to db immediately when a call is
active (see dialog module parameters) and do a query to the other server
database in addition to counting the local instance active calls.
Another one, different, is to use memcache for a communication system
between two or more instances.
Cheers,
Daniel
On 12/13/10 2:37 PM, Pan B. Christensen wrote:
> Thanks for your reply, Daniel.
> The purpose is to do busy forwarding without querying the client when
> the user already has >= X active calls. X will normally be 1 (call
> waiting inactive) or 2 (call waiting active). Advanced users may
> possibly set a higher value. Counting the number of calls on
> the server and doing busy forwarding based on that rather than waiting
> for a "486 Busy here" from the client has several advantages.
> Currently, I've written code to do this with the dispatcher module,
> and it's working great with only one server. Here's a code snippet:
> $var(dlg_busy) = 0;
> get_profile_size("busy", "$avp(s:uid)", "$var(dlg_busy)");
> if ( $var(dlg_busy) >= $avp(s:busy_level) ) {
> if ($avp(s:cfb_status) == "on") {
> $rU = $avp(s:cfb_number);
> xlog("L_INFO", "-------------------- $avp(s:uid) has
> $var(dlg_busy) active calls. Treshold $avp(s:busy_level). Forwarding
> on busy to $rU --------------------\n");
> route(10);
> }
> ...
> }
> Based on your reply, I guess one way to solve this would be to write
> the get_profile_size function in sqlops, query the two dialog
> databases and add the numbers. This would still require the customer
> to change their database design. Is there an easier or better way to
> do this?
> I also wote code to do busy forwarding if the client replies with 486
> (do not disturb activated), 603 (call rejected) etc.
> This code works for normal busy forwarding if Polycom is set to 1 call
> per line key (default is 8). We'll then have to provision the
> $avp(s:busy_level) variable to the clients instead of handling it
> server-side. If a user now wants to change the setting, he'll have to
> reboot his phone after doing so. Changing the
> reg.x.callsPerLineKey setting in the phone also limits the number of
> outgoing calls the user can make. We'll also have to make code for all
> the other hardphones the customer is planning to use plus make guides
> on how to change the setting for all kinds of softphones. We want to
> avoid all this.
> With kind regards,
> Pan
>
> ----- Original Message -----
> *From:* Daniel-Constantin Mierla <mailto:miconda at gmail.com>
> *To:* Pan B. Christensen <mailto:pan at ibidium.no>
> *Cc:* sr-users at lists.sip-router.org
> <mailto:sr-users at lists.sip-router.org>
> *Sent:* Monday, December 13, 2010 12:26 PM
> *Subject:* Re: [SR-Users] Dialog module with 2 servers and 2
> separate databases.
>
>
>
> On 12/10/10 2:17 PM, Pan B. Christensen wrote:
>> Hello,
>> My customer has the following database design.
>> Voip server 1 talks to SQL server 1.
>> Voip server 2 talks to SQL server 2.
>> Voip 1 and Voip 2 are load-balanced.
>> Each SQL server has two databases. Database 1 contains
>> semi-static data like call forwarding properties for users and is
>> read-only. This is replicated from a third SQL server which the
>> web interface writes to. Database 2 is read/write, is not
>> replicated and contains data that is updated frequently like user
>> location and now dialog info.
>> Voip server 1 is not allowed to talk to SQL server 2 and vice versa.
>> I'm using forward() to send authenticated REGISTERs to the other
>> server so that it'll write this to RAM and its own SQL server.
>> Thus, both servers are aware of clients authenticated and
>> registered by the other server.
>> How can I make both servers be aware of active calls on the other
>> server?
> what is the purpose?
>
> Practically, it is not possible to track a call in two instances,
> because, unlike registration where is just a storage of mappings
> between contact and aor, call states of dialog module involve more
> processing logic, including timeouts and sending BYEs.
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla
> Kamailio (OpenSER) Advanced Training
> Jan 24-26, 2011, Irvine, CA, USA
> http://www.asipto.com
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.449 / Virus Database: 271.1.1/3312 - Release Date:
> 12/12/10 19:34:00
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Jan 24-26, 2011, Irvine, CA, USA
http://www.asipto.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20101213/02fb715a/attachment.htm>
More information about the sr-users
mailing list