Hello Stan, First of all, thank you for taking the time to reply back at me :)
I've been messing around with this all day long and I think I am pretty much where you stand. Forcing OpenSIPS to send all consecutive calls from one account through the same asterisk server was my first thought as well. However this carries a heavy drawback; if they use you as a peer, handling multiple number of concurrent calls, you eventually disable all the load balancing and the high-available cluster service that you so hard tried to implement. You pick one asterisk at the beginning and you go with this one until it fails. I've also tried to force asterisk to serve multiple domains, so that it might identify the Refer-To contents and serve it properly, however so far I haven't made any progress. Your solution sounds interesting and I would really like to give it a try, if that is ok for you. I will continue searching as well, to see if I can come up with something else to try. Regards, Paris Stamatopoulos -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Stanislaw Pitucha Sent: Wednesday, May 05, 2010 5:38 PM To: [email protected] Subject: Re: [OpenSIPS-Users] OpenSIPS Load Balancer of an Asterisk Cluster - REFER Issue On 05.05.2010 11:50, Paris Stamatopoulos wrote: > Has anyone experience this before? Do you have any working solutions? Yes and yes. Short version: It's impossible without hacking asterisk. Long version: First we tried routing all related calls to the same destination using the dialog module. It would work, but only in the most trivial cases. It will work only if you can always match the destination or the source number to an existing call. If you use call forking / huntgroups / queues / redirection on your asterisk - forget about easy transfers - you will get calls which don't match on any field, but are still going to the same phone. Now - theoretically transfers should work between asterisks based on the information in refer-to - it already includes the host which handles the call and in the transfer context you can extract that address and force a Dial() to that destination. I never discovered why it doesn't quite work. Half of the calls failed and sometimes I got deadlocks (still using 1.4 - maybe 1.6 is better here). AFAIK there's also no real possibility to set the callerid in that case to figure out who initiated the transfer. But we've got a working solution now: - The first part is a custom res_cluster module which will publish for each call (hooked into the Dial() command) the callid, ftag, ttag and the ip of the local asterisk into a shared mysql database. - The second part is activated on refer. It does some magic in handle_refer() (or something like that) and then magicks the call to magically know the correct callerid, customer id, checks whether the transfer is allowed and dials the destination asterisk with correct refer-to headers. (destination comes from the database) It could be much simpler if you don't have to handle different customers and bill them separately. Maybe I missed some other option... but that's the solution we got to after ~3 months of testing different methods, annoying asterisk mailing list and their IRC. And it works just fine so far. I'm not sure I can release all the needed patches, but if you want them, let me know. Stan _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
