чо это? у нас пока попался тоьлко 1 кейс, где без pjsip никак, когда на сервера куча IP, и нужно разным провайдерам (а иногда одному и тому же) слать с разных IP, разных портов и т.д... Мне кажется в более типовых случаях chan_sip более чем достаточно

Согласен что сейчас chan sip это и удобно и быстро, но не для разработчиков. Потому что каждый фикс ведёт за собой парочку ошибок, ибо файл ну очень большой

Согласен что сейчас chan sip это и удобно и быстро, но не для разработчиков. Потому что каждый фикс ведёт за собой парочку ошибок, ибо файл ну очень большой

Например?

Например?

Например, что?)

Например, что?)

Каклй например фикс, который вызывает пару ошибок

Вы не думали что архитектура поменялась, поэтому старые команды нарушают новую архитектура. Если постоянно тепляться за старое, о можно поиметь проблемы того же wifi стандарта 802.11xx когда новое не работает из-за поддержки старого.

Старые команды ничего не нарушают. Я не против прогресса, нового канального драйвера и модульной структуры. Я о том, что синтаксис могли бы тот же оставить . Конечно, там, где появились новые сущности, пусть новые команды будут... понятно, что со временем и к новым командам привыкнем

Старые команды ничего не нарушают. Я не против прогресса, нового канального драйвера и модульной структуры. Я о том, что синтаксис могли бы тот же оставить . Конечно, там, где появились новые сущности, пусть новые команды будут... понятно, что со временем и к новым командам привыкнем

Это мнение простого обывателя, вам не понятно к чему это все ведут в итоге, вы мыслите сегодняшними своими . И опять же повторюсь. Многие про 802.11 жумаю так же как и вы, но каждый новый релиз упмрается в концепцию обратной совместимости. Вопрос к чему? Вы готовы предложить.готовый код.для реализациии в следующем релизе????

Каклй например фикс, который вызывает пару ошибок

Asterisk community, на их официальном сайте в системе jira ведутся постоянные фиксы, которые постим мы, админы, я бы привел конкретные кейсы но лень их выискивать. А вообще попробуйте сами 50 тыс строчный файл вести в ногу со временем, это неудобно, и это поняли разрабы ещё в 2005 году. Да и к тому же chan sip не поддерживает incoming call как мультитреды, как например исходящие, что в будущем может привести к неприятным последствия для хайлоад систем. Мы же не все обслуживаем астеры от 600к+ а им как раз модульность ой как кстати. В общем вам в коммъюнити на поиски багов и фиксов))

Старые команды ничего не нарушают. Я не против прогресса, нового канального драйвера и модульной структуры. Я о том, что синтаксис могли бы тот же оставить . Конечно, там, где появились новые сущности, пусть новые команды будут... понятно, что со временем и к новым командам привыкнем

Так они и ввели новую сущность оставив старую, выбирайте :)

пробовал и просто same => n,ExecIfTime(20:00-20:20,*,12,Oct?:Dial(SIP/666))

Зачем тут вообще двоеточие? В консоли же ниже явно указан знак вопроса

Зачем тут вообще двоеточие? В консоли же ниже явно указан знак вопроса

: у меня в одном из вариантов стоит после ? И я думал что оно работает так же как GotoIf, где можно указать как 2 варианта действия ?true:false так и по одному ?true и ?:false

: у меня в одном из вариантов стоит после ? И я думал что оно работает так же как GotoIf, где можно указать как 2 варианта действия ?true:false так и по одному ?true и ?:false

Насколько я знаю сокращённый синтаксис требует оба условия, например так true ? If : else; А вот true ? If; не работает, ну в большинстве яп

У меня в чистом астере 14 В диалплане (не луа и тд) срабатывает как if?then:else Так и if?then так и if?:else

Это мнение простого обывателя, вам не понятно к чему это все ведут в итоге, вы мыслите сегодняшними своими . И опять же повторюсь. Многие про 802.11 жумаю так же как и вы, но каждый новый релиз упмрается в концепцию обратной совместимости. Вопрос к чему? Вы готовы предложить.готовый код.для реализациии в следующем релизе????

При чем тут код , структура канального драйвера и прочее? Я говорю просто о командах в cli, которые могли бы быть такими же , как для chan_sip там, где это возможно. Я не говорю о совместимости. Это Вы всё время про это говорите. Вы, например, говорите про wifi, а я говорю о том, чтобы форма коробки , в которой устройство , оставалась привычно прямоугольной, а не шарообразной, чтобы мне её удобно было засунуть в коммуникационный шкаф. И да - это подход обывателя :)

Сделайте алиасы в cli_aliases.conf

возможно ли при занятости всех операторов в очереди выполнять опеределенное действие, например проиграть заданное собшении вызывающему абоненты и вывести его из очереди?

возможно ли при занятости всех операторов в очереди выполнять опеределенное действие, например проиграть заданное собшении вызывающему абоненты и вывести его из очереди?

да

есть отдельный параметр - по занятости выходить из очереди

какой?

какой?

гугленье на - asterisk queue дает чудеса

гугленье на - asterisk queue дает чудеса

мог бы с таким же успехом просто помолчать

тут мы делимся решениями, советами, опытом

ну ради вас можем переименоваться - помогаем гуглить по теме asterisk

тут мы делимся решениями, советами, опытом

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

уровень достойный, спросил - получил ответ, пошел гуглить

по другому это не работает

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

Все правильно тебе сказали. Есть вещи которые находятся по первой ссылке. И не иммет смысла спрашивать то что можно прочитать. Приходи с вопросами на которые нет ответов в гугл. Тут все так делают. Никто гуглить не стесняется.

если локальный абонент находится за NAT то что сделать что-бы входящие вызовы на него можно было отправлять? Исходяшие при этом через NAT нормально ходят и звук есть, проблема с входящими, например sip show peers показывает статус UNREACHABLE средствами одного Asterisk можно такую задачу решить? (Cам Астериск на белом IP, за NAT только клиенты) nat=auto_comedia в настройках клиента стоит, клиент не всегда за NAT, он мобильный, может иногда и без NAT подключаться

Настраивай vpn и не парься с натом тем более если все именно так как ты описал то это единственный нормальный вариант

VPN никак не вариант

Так астер на белом ип ? Клиент идёт к Астеру.

Qualify no поставь.

Регистрация должна быть и что то вроде нат кипалив или как его там

Нужна документация, описывающая очередность событий asterisk для различных примеров прохождения вызовов. Или документация, которая упорядочивает события AMI таким образом, чтобы было понятно, какое из них за каким ожидается. Такое реально найти?

Например, я бы хотел понимать, какие события вызываются и в какой очередности при входящем вызове от ТфОП, если он напрямую скоммутирован на внутренний номер, или если он назначен на группу серийного искания. Если у вызова есть изнаачльно адрес А или если его нет и он приходит позже.

Буду чрезмерно благодарен, если поделитесь такой информацией. Если в виде блок-диаграмм - будет вобоще отлично. Никак не могу отыскать :(

наверное просто ее нет, подключаетесь телнетом к ами и смотрите что летит

Придется слишком много вариантов имитировать

В официальной документации есть отличное описание всех АМИ-событий. Но не ясно, какие из них обязательные, а какие нет. Какие несут нужную информацию, а какие нет. Справочник событий есть, а структуризации этих знаний нет.

их порядок зависит от порядка выполнения диалплана

какая важная информация, какая нет - решать вам

У меня накопилось слишком много вопросов, я боюсь выкладывать их все в этот чат, потому что это будет похоже на флуд. Даже с серийником не все так просто. Я надеялся, что есть хотябы какой-то наглядный пример или описание того, что происходит и когда. Логов то достаточно у меня с разных систем. Именно поэтому и вопрос возник, так как одинаковый ход действий на разных системах вызывает разные события. Маршрутизация клиентских астериск мне недоступна. Моя задача разработать универсальный модуль для клиентов, собирающий вызовы.

Возможно, на разных системах по-разному составлены extension, но все равно с точки зрения пользователей разных астерисков происходит одно и то же действие, но со стороны событий АМИ оно сильно отличается.

универсальный) теоретически это, наверно, возможно, практически ... может быть вы будете первый)

Разработал множество разных "поведений", которые каждый пользователь примеряет под свою систему методом перебора. У одних новый вызов можно прочитать с Newchannel, у других только с Newstate и тому подобное

универсальный) теоретически это, наверно, возможно, практически ... может быть вы будете первый)

это и хорошая и плохая новость одновременно ? хорошая - значит эта цель недостежима плохая - та же причина

еще и полно любителей наклацать конфигурацию в freepbx. в итоге цели они добиваются и вызова как-то ходят, как они задумали, но внутри творится кошмар :(

так и есть, добро пожаловать в реальный мир)

спасибо ?

Хоть какая-то определенность. я то думал, я туплю и не могу найти правильный подход. а оно эво как.

Еще вопрос есть. Если используется группа серийного искания. По истечение заданного времени вызовы для группы перезапускаются. Получается, что в АМИ событиях видны новые вызовы в сторону операторов. Есть ли какой-то способ понять, что это те же вызовы, что и были до этого, но перезапущенные? А то у меня они как новые вызовы и я не могу их отличить от действительно новых. Речь только о тех вызовах, которые генерирует астериск в сторону операторов, подключенных к серийнику. (Серийник в терминологии астериск - очередь)

А то клиенту не нравится, что у него множество записей, будто оператору звонили много раз, а он не отвечал, хотя фактически это один и тот же абонент долго ждал на линии и группа успела 3..4 раза перезапустить вызовы.

Еще вопрос есть. Если используется группа серийного искания. По истечение заданного времени вызовы для группы перезапускаются. Получается, что в АМИ событиях видны новые вызовы в сторону операторов. Есть ли какой-то способ понять, что это те же вызовы, что и были до этого, но перезапущенные? А то у меня они как новые вызовы и я не могу их отличить от действительно новых. Речь только о тех вызовах, которые генерирует астериск в сторону операторов, подключенных к серийнику. (Серийник в терминологии астериск - очередь)

Там где то в канальных переменных, емнип, можно отследить айди ноги откуда оно берется. Но с точки зрения ноги б - это действительно новые вызовы.

ноги?

ноги?

Дда. Вызов состоит из двух ног обычно. Они же плечи.

Leg-a, leg-b

а в ами-событии это что за поле? Каналы то разные

а в ами-событии это что за поле? Каналы то разные

Да я ваще астериск плохо помню. Смотреть нужно в сторону поиска идентификаторов ноги а, из которой возникает б.

по номерам А и Б - не вариант сравнивать. Потому что абонент действительно мог перезвонить через 2 минуты и это уже новый вызов с точки зрения пользователя

по номерам А и Б - не вариант сравнивать. Потому что абонент действительно мог перезвонить через 2 минуты и это уже новый вызов с точки зрения пользователя

Не нумера, а айди ног

Потому что нога а не меняется, когда обзванивается стописот операторов

Окей. Поищу этот параметр среди логов. Спасибо

Есть что-то похожее в NewChannel - поле Linkedid - оно равно Uniqueid изначального канала. Но есть только начиная с 13 версии астериск

Кажется, это то, что нужно. Спасибо!

Есть что-то похожее в NewChannel - поле Linkedid - оно равно Uniqueid изначального канала. Но есть только начиная с 13 версии астериск

оно равно лишь потому что это родительский канал, когда будут пораждаться следующие то уже не будут равны, именно поэтому есть Uniq и Linked. Плюс ко всему я бы даже и не пытался писать что-то подобное для астеров ниже 12 версии ибо изменений там достаточно а поддерживать старье не имеет смысла. Но если сильно хочется, для старых астеров можно юзать финт с channelvars для ami и брать переменную CDR(linkedid) но это сработает не для всех событий, есть события на которые channelvars не канают и в этом вся печаль старых астеров

оно равно лишь потому что это родительский канал, когда будут пораждаться следующие то уже не будут равны, именно поэтому есть Uniq и Linked. Плюс ко всему я бы даже и не пытался писать что-то подобное для астеров ниже 12 версии ибо изменений там достаточно а поддерживать старье не имеет смысла. Но если сильно хочется, для старых астеров можно юзать финт с channelvars для ami и брать переменную CDR(linkedid) но это сработает не для всех событий, есть события на которые channelvars не канают и в этом вся печаль старых астеров

Желания поддерживать старьё нет. Есть необходимость. Потенциальные клиенты держат до сих пор 10й астериск. Не отказываться же от них.

На Bria iOS упорно нет входящих, на Bria на PC входящие есть, оба подключены через одну сеть и через один Nat, в логах на Astrtisk Bria iOS в поднятом состоянии, при попытке соединения сразу получаю канал не доступен, (в Bria на телефоне галочка принимать входящие вызовы есть, и аккаунт в зеленом состоянии и две стрелочки есть (входящая исходящая связь доступна) как более детально логи астериска посмотреть что бы понять что не так, сейчас в логах просто канал не доступен, но он же доступен....

На Bria iOS упорно нет входящих, на Bria на PC входящие есть, оба подключены через одну сеть и через один Nat, в логах на Astrtisk Bria iOS в поднятом состоянии, при попытке соединения сразу получаю канал не доступен, (в Bria на телефоне галочка принимать входящие вызовы есть, и аккаунт в зеленом состоянии и две стрелочки есть (входящая исходящая связь доступна) как более детально логи астериска посмотреть что бы понять что не так, сейчас в логах просто канал не доступен, но он же доступен....

Сигналку можно посмотреть сначала на предмет вылетают ли пули

Желания поддерживать старьё нет. Есть необходимость. Потенциальные клиенты держат до сих пор 10й астериск. Не отказываться же от них.

обновляйте до 13, либо геморрой в квадрате обеспечен. То что сделаете для 10-11 не будет работать для 12+ и наоборот, двойная работа минимум

Сейчас так и есть в виде набора "поведений", которые клиент перебирает, пока не заработает как ожидается. Но приказать клиентам обновить все свои астериски - не вариант ведь совершенно. Многие просто очкуют это делать: "а вдруг все поломается?". А я не собираюсь еще оказывать поддержку их системам. Уже проходили. Неблагодарное дело.

наверное потому, что pjsip это вообще другой модуль, со своими понятиями типа ендпоинтов, аоров,,блекджеком и шлюхами....

А еще res_pjsip состоит из сущностей, которые предусмотрены RFC 3261, в отличие от chan_sip, который вообще непонятно из чего состоит и откуда все эти чудные названия взялись (friend / user / peer и т.д.).

Возможно, на разных системах по-разному составлены extension, но все равно с точки зрения пользователей разных астерисков происходит одно и то же действие, но со стороны событий АМИ оно сильно отличается.

Если на всех нодах одинаковые версии * с одинаковыми конфигами и диалпланами, то все должно быть идентично. собирайте ami события со всех нод в одном ami proxy и делайте что надо там-же

Если на всех нодах одинаковые версии * с одинаковыми конфигами и диалпланами, то все должно быть идентично. собирайте ami события со всех нод в одном ami proxy и делайте что надо там-же

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

Сейчас так и есть в виде набора "поведений", которые клиент перебирает, пока не заработает как ожидается. Но приказать клиентам обновить все свои астериски - не вариант ведь совершенно. Многие просто очкуют это делать: "а вдруг все поломается?". А я не собираюсь еще оказывать поддержку их системам. Уже проходили. Неблагодарное дело.

Посылайте их к нам

Не знаю, как в 13 версии и дальше отдаются ami events, но в 11 это адилище - будьте готовы получать имена параметров разным регистром, в событиях с очередями может отсутствовать linkedid и тд ;))

Посылайте их к нам

:) с удовольствием, но им это не надо. у них есть телефонная система, которая "работает годами" :) и они хотят просто использовать наш модуль, который обещает им связку их телефонной истемы с нашим программным комплексом. И когда они слышат, что наш модуль не поддерживает их систему в том виде, в котором она сейчас находится, им это не нравится.

Да я много лет уже поддерживаю модуль. Сейчас собрался писать с нуля новую версию, основанную на опыте за все годы, переосмыслив все накопленные знания. Вот и решил поискать какой-то справочник, систематизирующим мои знания о событиях.

А то код старого модуля, мягко говоря, выглядит как костыли и велосипеды :)

:) с удовольствием, но им это не надо. у них есть телефонная система, которая "работает годами" :) и они хотят просто использовать наш модуль, который обещает им связку их телефонной истемы с нашим программным комплексом. И когда они слышат, что наш модуль не поддерживает их систему в том виде, в котором она сейчас находится, им это не нравится.

Ну это их проблемы. Старые айфоны тоже не поддерживают новые иос, поэтому если они хотят пользоваться прогрессом то должны идти с ним в ногу а не позади

да, но я хочу продать им свой модуль. моя задача сделать так, чтобы работало всё из коробки. Иначе я потеряю клиента.

прошло время, когда я выделывался. сейчас уже не до этого.

начинаю выделываться, находится другой парень, который не выделывается, и забирает клиентов себе

да, но я хочу продать им свой модуль. моя задача сделать так, чтобы работало всё из коробки. Иначе я потеряю клиента.

Тогда желаю удачи и советую брать сразу пару кг вазелина на будущее, он понадобится!!!

Роман прав - уровень прогиба перед клиентом зависит от котлеты которую он готов положить перед вами. Не всегда правильно нагибаться очень низко ;))))

Я сейчас хочу пока что просто понять, как мне лучше работать с событиями, чтобы покрыть одинм алгоритмом максимальное количество конфигураций. В текущей (старой) версии модуля я подбирал события методом тыка: снимал АМИ логи и наблюдал, когда происходит какое событие одновременно с действием. Вызовы я идентифицирую по uniqueid, а не по chain, что, скорее всего, было ошибочным решением. Но мне изначально показалось, что так правильно. Да много чего сделано "странно". Сейчас хочу переделать красиво

Роман прав - уровень прогиба перед клиентом зависит от котлеты которую он готов положить перед вами. Не всегда правильно нагибаться очень низко ;))))

очень низко - это поддерживать 1.8 и ниже :) от этого я октазался сразу

Чем больше зоопарк поддерживаемых версий, тем тяжелее поддерживать систему

но клиентов с 10 очень много. примерно четверть

я не боюсь трудностей. мне главное понимать, как это работает.

Денис, пишите прокси или для каждой версии астериска свою точку входа давайте клиенту

сейчас у меня для каждой версии свой класс-обработчик, который "слушает" ами и генерирует на выходе стандартные события модуля (не астериска) вроде "поступил вызов", "вызов направлен оператору", "оператор ответил"

и это работает от 10 до 16 версии нормально. но я хочу еще лучше :)

клиент в конфиге модуля просто выбирает версию астериска и автоматически подключается нужный класс-слушатель. Но я многого не знаю из логики астериска. Я не понимаю, какие события за какими следует ожидать. Не понимаю, как лучше идентифицировать вызовы, по каналу или по uniquid и т.д. Кстати, как?

Еще не знаю, каким способом в АМИ поймать имя файла mixmonitor. Но, скорее всего, без внедрения в диалпланы событий, передающих в АМИ имя файла, никак не обойтись.

Ami event -> json -> inmemorydb (like a redis) и дальше анализируйте. В любом случае на стороне клиента потребуется донастройка отдаваемых событий

Приведу пример проблемы, с которой обратился клиент. Для фиксации факта направления вызова оператору, я слушал события Newstate с состоянием Ringing. Это работает у всех клиентов, кроме одного. У него почему-то канал не переходит в это состояние. После этого решил написать сюда в группу, потому что понял, что не доконца понимаю логику последовательности событий.

Изначальновый вопрос был только в том, существует ли какой-то справочник последовательности событий. Конкретно, обязательно ли канал должен переходить в Ringing или может быть это не обязательное состояние.