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
