Comments 20
У вас $ini в конструкторах у некоторых примеров без $this, т.е. объявляются внутри функции.
Ребята, Звездочка открытое решение, и я только начал описывать начало начал, зачем меня «минусовать»? С форумов удаляете данную инфу хотя это же все очень просто делается. Любой человек разбирающийся в Астере может себя реализовать и написать собственное API, а затем еще и интегрировать его в приложение. Вы еще и с Хабра удалите эту статью, и вообще станет как в политике Америки, только Американцы и Европейцы имеют право писать СОФТ. А остальные должны лишь рукоплескать их уму. А я татарин, который живет в Казахстане. И я считаю что мы тоже можем реализовать собственную «открытую» обертку для Астера.
Извините наболело, особенно когда на форумах по астеру мои статьи с фишками для Астера уничтожаются в течении часа. Я даже на хабре пишу на ночь глядя, а вдруг и здесь статью сольют.
Извините наболело, особенно когда на форумах по астеру мои статьи с фишками для Астера уничтожаются в течении часа. Я даже на хабре пишу на ночь глядя, а вдруг и здесь статью сольют.
Судя по голосованию, интерес есть, поэтому создавайте проект на github, добавляйте ссылку в статью.
Сможете продуктивно работать с единомышленниками и собирать фидбек в виде issues/pull requests.
Ну а там видно будет взлетел проект и стагнировал — в любом случае вы в плюсе. Удачи!
Сможете продуктивно работать с единомышленниками и собирать фидбек в виде issues/pull requests.
Ну а там видно будет взлетел проект и стагнировал — в любом случае вы в плюсе. Удачи!
kalessil, пока по голосованию на данном этапе интерес имеется. Но надо дождаться результатов хотя бы недельного голосования.
На гитхаб у меня лично нет желания выкладывать свои или общие наработки. Поясню: я сам плохо разбираюсь в техническом английском, и мне не нравится в международных проекта ненавязчивый регламент вести описание на не родном мне языке. Согласен это ведет к моей ограниченности, но я не хочу чтобы мои мысли были неправильно интерпретированы в связи с моим плохим английским. Ведь даже когда на русском комментируешь тот или иной участок кода, два разных человека могу совершенно по разному это понять. Проще работать с бывшими «совками» есть связующее звено, русский, и найти взаимопонимание становится проще.
Что то я сам запутался в своем комменте.
На гитхаб у меня лично нет желания выкладывать свои или общие наработки. Поясню: я сам плохо разбираюсь в техническом английском, и мне не нравится в международных проекта ненавязчивый регламент вести описание на не родном мне языке. Согласен это ведет к моей ограниченности, но я не хочу чтобы мои мысли были неправильно интерпретированы в связи с моим плохим английским. Ведь даже когда на русском комментируешь тот или иной участок кода, два разных человека могу совершенно по разному это понять. Проще работать с бывшими «совками» есть связующее звено, русский, и найти взаимопонимание становится проще.
Что то я сам запутался в своем комменте.
То что вы рассказали про связку Asterisk и php — достойно похвалы и если бы статья вышла года полтора назад я был бы несказанно счастлив её прочитать и понять в какую сторону копать, но «всё уже написано за нас», нужно просто правильно искать:
github.com/marcelog/PAMI
github.com/marcelog/PAMI
AotD Спасибо за комментарий. К сожалению статья вышла вчера, а не полтора года назад. По поводу ПАМИ, скажу сразу, я не описал готовое решение, я описал механизм по которому можно работать. И кто сказал, что взяв просто код ПАМИ можно сразу нарисовать колл центр? Особенно когда сама библиотека не документирована для русскоговорящей аудитории, и механизм ее работы даже для англоязычной аудитории не раскрыт? В статье описан механика используя которую любой начинающий(или практикующий) разработчик может понять с чего начать работу. А для небольших приложений так вообще готовый модуль, который просто нужно переработать под свои нужды.
Если у Вас нет желания про это читать, велком к голосованию.
Если у Вас нет желания про это читать, велком к голосованию.
Собственно PAMI тоже не есть готовое решение, а библиотека предоставляющая удобную абстракцию для общения с Asterisk не погружаясь в его кишки =)
В случае вашей реализации «Для работы с Астериск АМИ мы должны записывать в сокет пакеты строк, в ответ на которые мы будем также получать строки о статусе наших запросов.», нужно разбирать ответы и контролировать всё в ручную. В PAMI всё разложено по полочкам, выкидывает соответствующие Exception'ы, покрыто тестами и превращается действительно в программирование на php:
Зачем документировать библиотеку для русских/белорусов/казахов/мексиканцев? Хотите — дело ваше, fork, translate, merge, repeat. Английский — отличный способ международного общения и главное «ЗА» этого языка в том что не только определенная замкнутая группа людей может, хочет и будет поддерживать продукт и вносить в него полезные изменения, но вообще любой кто имеет компетенцию в данной области и знает язык на уровне чуть выше elementary. Извините, за этот выпад на ваш «вообще станет как в политике Америки, только Американцы и Европейцы имеют право писать СОФТ. А остальные должны лишь рукоплескать их уму», но автор вышеупомянутой библиотеки Аргентинец и я вообще не понимаю разделения программистов по дислокации и расовой принадлежности. Так что ответ на голосование: «Да, тема интересная» и хочется больше материалов о способах взаимодействия (но не деталей реализации, которая увы делается без оглядки на общемировые практики и стандарты), потому как «Нет, уже имеются готовые решения»
В случае вашей реализации «Для работы с Астериск АМИ мы должны записывать в сокет пакеты строк, в ответ на которые мы будем также получать строки о статусе наших запросов.», нужно разбирать ответы и контролировать всё в ручную. В PAMI всё разложено по полочкам, выкидывает соответствующие Exception'ы, покрыто тестами и превращается действительно в программирование на php:
$outgoing = new OriginateAction('/SIP/someprovider/' . $phone);
$outgoing->setContext('outgoing');
$outgoing->setExtension(sprintf("%04d",$digits));
$outgoing->setPriority('1');
$outgoing->setAsync(true);
$this->ami->send($outgoing)
Зачем документировать библиотеку для русских/белорусов/казахов/мексиканцев? Хотите — дело ваше, fork, translate, merge, repeat. Английский — отличный способ международного общения и главное «ЗА» этого языка в том что не только определенная замкнутая группа людей может, хочет и будет поддерживать продукт и вносить в него полезные изменения, но вообще любой кто имеет компетенцию в данной области и знает язык на уровне чуть выше elementary. Извините, за этот выпад на ваш «вообще станет как в политике Америки, только Американцы и Европейцы имеют право писать СОФТ. А остальные должны лишь рукоплескать их уму», но автор вышеупомянутой библиотеки Аргентинец и я вообще не понимаю разделения программистов по дислокации и расовой принадлежности. Так что ответ на голосование: «Да, тема интересная» и хочется больше материалов о способах взаимодействия (но не деталей реализации, которая увы делается без оглядки на общемировые практики и стандарты), потому как «Нет, уже имеются готовые решения»
AotD Спасибо еще раз за Ваши комментарии.
Отвечу по мере способностей =)
Ну во первых не у всех имеется такой багаж опыта как у Вас. Поэтому я и спрашиваю сообщество стоит ли продолжать или закончить на этом. Ведь эта статья, как бы первая ласточка, которая показывает вариант как можно самим начать работу с АМИ звездочки. Если в ПАМИ есть готовый функционал, это еще не значит что допустим некто, начавший работать с Астером недавно не имея полноценной документации сразу же начнет писать приложение основываясь на ПАМИ. Если статья, ее подача и полезность ее информации не интересует Вас то нет проблем. Я ведь жду что скажет сообщество.
Поясню почему я начал писать эту статью, когда первый клиент обратился к нам с просьбой связать его CRM систему с Астером, мы пришли к ПАМИ также как и Вы. поюзав данный фреймворк, отдел разработки пришел к выводу что там все сильно запущено. То есть она написана для абстрактной системы которая не может контролировать большие колл центры, реальность вернула нас к началу начал. Пришлось изучить исходники и перерыть гору информации, которой в рунете почти нет.
По поводу написания софта, да у меня действительно наболело, вот опубликуешь статью на специализированном форуме, вроде движение начинается по статье, но только до прихода модератора, как только модератор появляется статья вместе с аккаунтом исчезает. Поднимать собственные форумы это к сожалению не мое, не хочу тратить свое время на еще одну помойку. Хотя допустим даже эта статья приведет на хабр огромное количество постигающих Астериск из поисковых систем.
По поводу Аргертинца, ну я же отписался, что ограничен в своем развитии =).
А во вторых оказывается и нету.
Отвечу по мере способностей =)
Ну во первых не у всех имеется такой багаж опыта как у Вас. Поэтому я и спрашиваю сообщество стоит ли продолжать или закончить на этом. Ведь эта статья, как бы первая ласточка, которая показывает вариант как можно самим начать работу с АМИ звездочки. Если в ПАМИ есть готовый функционал, это еще не значит что допустим некто, начавший работать с Астером недавно не имея полноценной документации сразу же начнет писать приложение основываясь на ПАМИ. Если статья, ее подача и полезность ее информации не интересует Вас то нет проблем. Я ведь жду что скажет сообщество.
Поясню почему я начал писать эту статью, когда первый клиент обратился к нам с просьбой связать его CRM систему с Астером, мы пришли к ПАМИ также как и Вы. поюзав данный фреймворк, отдел разработки пришел к выводу что там все сильно запущено. То есть она написана для абстрактной системы которая не может контролировать большие колл центры, реальность вернула нас к началу начал. Пришлось изучить исходники и перерыть гору информации, которой в рунете почти нет.
По поводу написания софта, да у меня действительно наболело, вот опубликуешь статью на специализированном форуме, вроде движение начинается по статье, но только до прихода модератора, как только модератор появляется статья вместе с аккаунтом исчезает. Поднимать собственные форумы это к сожалению не мое, не хочу тратить свое время на еще одну помойку. Хотя допустим даже эта статья приведет на хабр огромное количество постигающих Астериск из поисковых систем.
По поводу Аргертинца, ну я же отписался, что ограничен в своем развитии =).
А во вторых оказывается и нету.
AotD еще раз спасибо за Ваши комментарии.
Отвечу по поводу
В Евросоюзе и США имеются «практика и стандарт и даже законы социальной защиты детей» диктующие что в 70% в семья жителей бывших «совков» издеваются (именно издеваются) над детьми, и на основании этого нужно проверять каждую такую семью для защиты детей от родителей. Давайте применим эти же законы и стандарты у себя. У это уже будет нонсенс.
Также мировая практика говорит что специалист должен в совершенстве знать только свою специализацию. Но мы живем в другом мире, где каждый мужчина может сам выкрутить лампочку и заменить ее, не вызывая электрика, не смотря на то что он допустим учитель литературы.
Я конечно немного утрировал, и не во всем это так, но примеры увы вполне из реальности.
И давайте придем к логическому мнению что:
И Вы и Я будем применять те стандарты и спецификации которые действительно полезны и необходимы нам, а не кому то там кто сидит в сертифицирующем органе и кто далек от наших потребностей. Если Ваша команда ориентирована на западного клиента и западную сертификацию, то это Ваше право работать по стандартам которые приняты на тех территориях. Но у нас имеются собственные сертификационные центры, которые выпускают собственные стандарты, которые в свою очередь могут легко идти в разрез с американскими или европейскими стандартами.
И такого понятия как общемировой стандарт или общемировая практика не существует. Также как общемирового сертификационного центра. В каждой стране имеются свои наработки в сертификации. Даже определенное ИСО в каждой стране может быть разным.
Возьмите даже вроде бы самую большую мировую куммунити — науку.Так даже здесь, нет единых стандартов. Даже теория Дарвина и то идет в разрез с Научным обществом Ватикана, а ведь докторантура Ватикана считается одной из самых сильнейших в мире. Примеров масса. Оглянитесь. Нету мировых стандартов. Есть стандарты которые Вы или Я или группа людей договорилась соблюдать, на определенной территории или в определенном направлении.
Отвечу по поводу
общемировые практики и стандарты
В Евросоюзе и США имеются «практика и стандарт и даже законы социальной защиты детей» диктующие что в 70% в семья жителей бывших «совков» издеваются (именно издеваются) над детьми, и на основании этого нужно проверять каждую такую семью для защиты детей от родителей. Давайте применим эти же законы и стандарты у себя. У это уже будет нонсенс.
Также мировая практика говорит что специалист должен в совершенстве знать только свою специализацию. Но мы живем в другом мире, где каждый мужчина может сам выкрутить лампочку и заменить ее, не вызывая электрика, не смотря на то что он допустим учитель литературы.
Я конечно немного утрировал, и не во всем это так, но примеры увы вполне из реальности.
И давайте придем к логическому мнению что:
И Вы и Я будем применять те стандарты и спецификации которые действительно полезны и необходимы нам, а не кому то там кто сидит в сертифицирующем органе и кто далек от наших потребностей. Если Ваша команда ориентирована на западного клиента и западную сертификацию, то это Ваше право работать по стандартам которые приняты на тех территориях. Но у нас имеются собственные сертификационные центры, которые выпускают собственные стандарты, которые в свою очередь могут легко идти в разрез с американскими или европейскими стандартами.
И такого понятия как общемировой стандарт или общемировая практика не существует. Также как общемирового сертификационного центра. В каждой стране имеются свои наработки в сертификации. Даже определенное ИСО в каждой стране может быть разным.
Возьмите даже вроде бы самую большую мировую куммунити — науку.Так даже здесь, нет единых стандартов. Даже теория Дарвина и то идет в разрез с Научным обществом Ватикана, а ведь докторантура Ватикана считается одной из самых сильнейших в мире. Примеров масса. Оглянитесь. Нету мировых стандартов. Есть стандарты которые Вы или Я или группа людей договорилась соблюдать, на определенной территории или в определенном направлении.
AotD Извините за резкость моих ответов на Ваш комментарий.
/* Переменные класса */
public $ini = array();
Не нужно так делать. Используйте различные переменные для хранения разнородных данных. Вообще, следовало сделать хоть какой-нибудь рефакторинг, прежде чем советовать использовать свой код. Читайте книги и откройте для себя PSR-2.
P.S.: Если честно, я не понял что вы имели ввиду под асинхронностью, в коде я её не нашёл
RUgaleFF спасибо за комментарий. Поясняю по массиву. Массив проще использовать так как он динамически изменяется. То есть я просто упрощаю продакшн. Декларировать же каждую переменную это хорошо когда в самом начале имеется полное представление по переменным которые будут использованы в конечном коде.
По поводу PSR-2, мы в нашей команде работаем по переработанной версии регламента, которая упрощает нам работу по чтению кода между разработчиками, что удобно для нас. Ведь регламент принятый для сертификации кода в одном органе может не полностью соответствовать нашим реалиям и потребностям. Здесь подходит «Сколько людей столько и мнений».
зы: Асинхронность не в потоках, а в варианте чтения из сокета. Пока сокет открыт там нет EOF, поэтому операция чтения может тупо зависнуть пока не дождется полного закрытия сокета или прервется по таймауту. И это всего лишь класс, а не вариант кода с пометкой «следуй моему мнению». Этот класс на простом и доступном языке показывает как можно работать с сокетами, в частности, с Астериск АМИ.
По поводу PSR-2, мы в нашей команде работаем по переработанной версии регламента, которая упрощает нам работу по чтению кода между разработчиками, что удобно для нас. Ведь регламент принятый для сертификации кода в одном органе может не полностью соответствовать нашим реалиям и потребностям. Здесь подходит «Сколько людей столько и мнений».
зы: Асинхронность не в потоках, а в варианте чтения из сокета. Пока сокет открыт там нет EOF, поэтому операция чтения может тупо зависнуть пока не дождется полного закрытия сокета или прервется по таймауту. И это всего лишь класс, а не вариант кода с пометкой «следуй моему мнению». Этот класс на простом и доступном языке показывает как можно работать с сокетами, в частности, с Астериск АМИ.
Если я правильно понимаю, то это же telnet обычный. Какой смысл был писать свой велосипед, если достаточно было написать обёртку к существующим библиотекам?
Которых, кстати, достаточно:
— github.com/bestnetwork/Telnet
— github.com/bosha/PTel
— github.com/tiagobutzke/php-remote-server
— github.com/avin/telnet-commander
Да и где-то видел библиотеку как раз под ваши нужды.
UPD: Да, выше написали про PAMI.
Которых, кстати, достаточно:
— github.com/bestnetwork/Telnet
— github.com/bosha/PTel
— github.com/tiagobutzke/php-remote-server
— github.com/avin/telnet-commander
Да и где-то видел библиотеку как раз под ваши нужды.
UPD: Да, выше написали про PAMI.
пользуюсь pami нареканий нет, что там нравится так это команды уже как классы представлены, но если продолжать развивать проект то хотелось бы увидеть возможность асинхронного запуска команд (Вы написали что легко, но все равно, как говорят мелочь, а приятно), парсинг ответа в удобочитаемый вариант(в класс(модель) для сохранения в базу например через orm) и интеграция с amqp. Для чего, просто не всегда есть возможность поставить свое оборудывание на стороне хостера, например gsm шлюз, и если у вас проект находится где нибудь в панаме, а сам шлюз в грузии, то представляете какой будет read_timeout. Да еще насчет асинхронности но это только для sms, во многих gsm шлюзах с астериксом внутри есть возможность работать с почтой, то есть конвертировать письма в sms или наоборот, и используя эту возможность Вам тогда не надо подключать к проекту pami или люубую другую библиотеку для работы с ami, просто шлете письмо на указанный ящик, шлюз по pop3 каждые n- секунд проверяет его и конвертит письма в sms, так же можно указывать pin для безопасности.
PaulWeb Спасибо за Ваш комментарий.
По поводу асинхронности чтения, в ПАМИ есть много проблем так как он заточен под абстрактный малоинтенсивный продакшн. В связи с этим и ответы от астериска приходят в совершенно неудобном формате. В классе режим чтения данных из сокета представлен асинхронно, то есть чтение из сокета может происходить не по мере поступления информации а именно тогда когда требует приложение.
В следующей части я собираюсь раскрыть потенциал простого Originate-а, с возможностью чтения данных уже из готового массива и с историей по ActionID. Но пока я соберусь походу меня заминусуют =) Видать статья не понравилась сообществу, хотя опрос показывает что тема актуальна, да и количество человек которые добавили статью в избранное тоже заставляет думать что здесь что-то не то.
На самом деле собрать всю информацию в готовый и классифицированный массив что не так уж и сложно, сложнее бороться с памятью которую жрут демоны. Мы у себя в продуктах нашли решение. Оно связано с применением массивов как динамических объектов, которое также нужно показывать отдельной статьей. Потому что готовый класс ни приведет разработчика к написанию более-менее сложного приложения, пока он не поймет механику класса,.
Повторюсь, даже в этом классе реализовано «асинхронное» чтение из сокета. Которое не дает зависнуть приложению в случае отсутствия данных на стороне сокета, а просто выбрасывает пустой массив.
По поводу асинхронности чтения, в ПАМИ есть много проблем так как он заточен под абстрактный малоинтенсивный продакшн. В связи с этим и ответы от астериска приходят в совершенно неудобном формате. В классе режим чтения данных из сокета представлен асинхронно, то есть чтение из сокета может происходить не по мере поступления информации а именно тогда когда требует приложение.
В следующей части я собираюсь раскрыть потенциал простого Originate-а, с возможностью чтения данных уже из готового массива и с историей по ActionID. Но пока я соберусь походу меня заминусуют =) Видать статья не понравилась сообществу, хотя опрос показывает что тема актуальна, да и количество человек которые добавили статью в избранное тоже заставляет думать что здесь что-то не то.
На самом деле собрать всю информацию в готовый и классифицированный массив что не так уж и сложно, сложнее бороться с памятью которую жрут демоны. Мы у себя в продуктах нашли решение. Оно связано с применением массивов как динамических объектов, которое также нужно показывать отдельной статьей. Потому что готовый класс ни приведет разработчика к написанию более-менее сложного приложения, пока он не поймет механику класса,.
Повторюсь, даже в этом классе реализовано «асинхронное» чтение из сокета. Которое не дает зависнуть приложению в случае отсутствия данных на стороне сокета, а просто выбрасывает пустой массив.
У вас в функции init ошибка вместо пароля передаётся 2 раза логин. Исправьте пожалуйста.
Надо вот так:
Вы ещё не завили git репозиторий для этого проекта?
Надо вот так:
public function init()
{
return $this->write("Action: Login\r\nUsername: ".$this->ini["login"]."\r\nSecret: ".$this->ini["password"]."\r\n\r\n");
}
Вы ещё не завили git репозиторий для этого проекта?
Sign up to leave a comment.
Пишем обработку Asterisk AMI своими руками. Часть первая: создаем класс на PHP для обращения к звездочке или как сделать php socket клиент своими руками