Звонить, кликая по контакту в MS Outlook.
Google говорит (freeware): Star Outlook Dialer, a-squared Anti-Dialer, 1st Dialer,.....
Хотелось бы что-то бесплатное (или в крайнем случае недорогое) решение для реализации исходящих звонков.
Что посоветуете ?

OutCALL

Asterisk Outlook Dialer 1.08
http://www.voip.com.sg/asterisk/voip_asterisk_outlook_dialer.html

http://www.counterpath.com/bria-for-microsoft-outlook.html
http://www.xtelsio.com/

Правда оба платные.
Второй мне больше понравился. Использует станадратную возможность звонков в Outlook.

activa tsp больше года, директор доволен - тыкнул в контакт, нажал "позвонить"
правда аутлук надо минимум 2003 (у нас 2007, ибо лицензия).

с помошью програмнного телефона звонит директор?

burder, если стоит програмный, значит с програмного. если аппаратный - то с него. TAPI <-> AMI интерфейс.

А мне вот чего со всеми этими TAPI интересно: это же все требует выставить AMI наружу (наружу относительно связки Астерисковских машин - в "публичный интранет"). А в AMI все не очень как я понимаю с permission control. Соответственно если юзер может получать через AMI информацию о том что ему звонят то эту же информацию про него получат и все остальные и нет способа отдавать каждому только его. Откуда растут два пункта:

1. privacy нах
2. При большом числе пользователей это все плодит приличный абсолютно ненужный трафик.

Точно также, права на originate позволяют пытливым умам делать звонки которые они делать не должны.

Ну и последнее - как все это заставить жить в кластере если юзеры регистрируются на разных серверах. Они же и к AMI должны в правильное место идтию...

да, с privacy проблемы. и решать их нужно с помощью прокси. например - astmanproxy. он и трафик уменьшит, и соединение зашифрует, вроде как есть какие-то разрешения. Но AMI придуман не для человека, а для программ.

только вот не понятно мне, зачем выставлять AMI наружу, в публичный интернет?

хотя доработать управление пользователям ох как не мешало бы. самое логичное (по аналогии с подпиской на blf):
в manager.conf в описании прав пользователя определять контекст. в этом контексте определяется область видимости номеров, события от которых может принимать юзер. Добавить две команды AMIAccept(команда) и AMIDeny(команда). к примеру:
[ami-permissions]
exten => _1ХХ,1,AMIAccept(originate)
exten => _1ХХ,n,AMIAccept(monitor)
exten => _1ХХ,n,AMIAccept(hangup)
exten => _1ХХ,n,AMIAccept(extensionstate)
exten => _1ХХ,1,AMIDeny(all)

т.е. пользователю разрешены операции originate, monitor, hangup, extensionstate с помощью AMI только с его номером (если определен) и номером из диапазона _1ХХ.
использование диалплана вероятно позволит строить обработку ami запросов или делать запросы в БД для проверку разрешений.

хз как это соотносится с архитектурой астериска, но ami давно нуждается в переделке.
может кто-нить напишет в багрепорт?

аха.... прокси... Интересно, не знал.
А он и с кластером вопрос может решить? (Если несколько одинаковых серверов и регистрации по ним равномерно размаззаны - AMI запросы для данного юзера нужно слать на тот же сервер на котором он зарегистрирован).

Но AMI придуман не для человека, а для программ.

Ну да, только недобрый человек его все равно может заюзать. При помощи программы :)

только вот не понятно мне, зачем выставлять AMI наружу, в публичный интернет?

Я написал "публичный ИНТРАнет" не "ИНТЕРнет" :)

может кто-нить напишет в багрепорт?

Ну так ответ на это известен - this is not a bug but rather a feature requests. We only accept these with patches attached...