originate, каналы и CDR - полный бардак

[Vslav1]

Могу предположить зачем Вы это делаете.
Пишете ЕЩЁ_ОДИН_АВТООБЗВОН?

Я же ясно написал зачем - для мониторинга:

Поясню зачем это нужно - для проверки работоспособности городского номера...

А для автодозвона как раз больше подходит команда Originate, соединяющая два канала.

Думаю да, поэтому ответов не будет, по принципиальным соображениям.

Уважаемый ded, от Вас мне не нужно ответов!
Ваша миссия - создание шумихи вокруг интересных тем для привлечения к ним внимания разработчиков
и хорошего индексирования.

[Vslav1]

Уважаемый zzuz, Вы заняты очень важным делом - вывешиванием на постах Вашего рекламного логотипа.

Я вот тоже не понимаю , как вести диалог с автором , если он занимается ерундой.

Если бы Вы немного посмотрели не описание, а как устроен сам класс, то увидели бы метод exec_dial:

Код: Выделить всё

function exec_dial($type, $identifier, $timeout=NULL, $options=NULL, $url=NULL){
     return $this->exec('Dial', trim("$type/$identifier|$timeout|$options|$url", '|'));
}

Вот сама функция exec

Код: Выделить всё

function exec($application, $options){
    if(is_array($options)) $options = join('|', $options);
    return $this->evaluate("EXEC $application $options");
}

То есть в результате в Asterisk передаётся следующая строка:
EXEC 'Dial' <опции>
или если более подробно то так:
'EXEC' 'Dial' $type/$identifier|$timeout|$options|$url", '|'

Именно так и нужно передать всё это для выполнения в AMI.

[zzuz]

Ага. А версия астериска 1.2 ?

[Vslav1]

Ага. А версия астериска 1.2 ?

Уважаемый zzuz, предлагаю вам пройти небольшой тест.
В какой версии Asterisk можно увидеть такое сообщение:

Код: Выделить всё

Asterisk Call Manager/1.1
Response: Success
Message: Authentication accepted

[zzuz]

Да. Я пожалуй поддержу ded'а и тоже перестану отвечать.
После трех явных подсказок и одного ответа - игра в догадки продолжается. это бесполезно.

[Vslav1]

Говоруны утихли, продолжим
Появилась ещё одна возможность (в Asterisk 1.6.0) инициировать вызовы
и отслеживать состояние канала - Асинхронный AGI.
Она позволяет приложению, которое использует AMI
асинхронно передавать AGI команды для исполнения на канал.

Вот такой контекст создаёт канал, который будет будет ожидать AGI команды:

Код: Выделить всё

context async-agi {
    1234 => {
        AGI(agi:async);
    };
};

Почитать можно здесь:
http://ofps.oreilly.com/titles/9780596517342/AGI.html
Async AGI—AMI-Controlled AGI ...

Патч для реализации на версии 1.4.15 здесь:
http://www.moythreads.com/wordpress/200 ... onous-agi/

Кто нибудь уже опробовал эту возможность, есть какие нибудь результаты?

[ded]

Уважаемый ded, от Вас мне не нужно ответов!
Ваша миссия - создание шумихи вокруг интересных тем для привлечения к ним внимания разработчиков и хорошего индексирования.

Спасибо, что напомнили мне о моей миссии, а то я как-то разбрасываюс, надо сосредоточица.

[kasper]

Мне понравилась идея делать Dial-ы через интерфейс AMI вместо Originate

И всё таки на мой взгляд это разные весчи.
Задача originate создать канал и соединить его с контекстом или application например тот же dial (links it to an application or context) а задача dial (Attempts to establish a new outgoing connection on a channel, and then link it to the existing input channel.)

А проблема в том, что нельзя сделать Dial для несуществуюшего канала.

Отсюда и ваша проблема что ненужно их заменять, они должны работать вместе.
Например чем ваше

console dial 4991234567@from-probe

так уж отличается от originate? Судя по синтаксису и описанию console dial больше похоже на originate чем на application dial

Можно ли как-то сделать Dial, чтобы сразу узнать ИМЯ_КАНАЛА или руками задать его ?

Руками задать нельзя, он должен быть хотя бы временно уникальным(иначе будет конец света имхо =) ). Там есть счётчик на основании которого генерится имя(по крайней мере для sip это так).

Общеизвестно, что при большой нагрузке некоторые события просто теряются.

Не шутите так. Народ, кто то ещё может подтвердить этот факт на линейке >= 1.6 ( я надеюсь это это было вызвано медленным чтением событий)

[Vslav1]

Уважаемый kasper, с вами согласен лишь частично.
Под каждую задачу хорошо-бы подобрать оптимальный инструмент.

Например чем ваше
console dial 4991234567@from-probe
так уж отличается от originate?

А отличие тем, что console dial создаёт один канал, а originate сначала два, а потом ещё третий.
Ну зачем мне три, когда нужен только один?

И хотя сразу сразу узнать ИМЯ_КАНАЛА не получается (счётчик, на основании которого генерится имя, наверное медленно считает )
но в ответе на Dial идентификатор Uniqueid канала возвращается сразу!
А оказывается его можно использовать вместо переменной ИМЯ_КАНАЛА,
хотя внешне они выглядят по разному:
Channel: SIP/4321-45cf6c80
Uniqueid: 1321618149.83078
То есть вот такие AMI команды работают:

Код: Выделить всё

Action: Status
Channel: <Uniqueid>

и

Код: Выделить всё

Action: Hangup
Channel: <Uniqueid>

А потери событий на 1.4 при возрастании нагрузки я наблюдал неоднократно.
На 1.6 я с больной нагрузкой не экспериментировал, если потерю устранили, то это классно!

я надеюсь это это было вызвано медленным чтением событий

Так поделитесь секретом как читать быстро
Я пробовал только метод регистрации функции обратного вызова, которая вызывается при обработке события.
в PhpAGI это:

Код: Выделить всё

add_event_handler($event, $callback)

в Perl Asterisk::Manager это:

Код: Выделить всё

$astman->setcallback("$event", \&event_callback); 

[Vslav1]

Уважаемый switch!
Проверил версиях 1.6.2.13 и 1.6.2.17 - идентификатор Uniqueid вместо имени канала работает

К Вам, как съевшему собаку при разборе свистопляски с каналами вопрос.
Можно ли в Asterisk просто СОЗДАТЬ КАНАЛ?
Он ведь может быть виртуальным (логическим) и не привязанным к технологии.
Потом установить переменные канала, затем редиректить канал или заставлять в нём выполняться AGI и т. д.