вместо анекдота

[tma]

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

На самом деле это у тебя просто привычка.
Миллион настроек на все случаи жизни конечно сделать невозможно.
Поэтому мне больше нравится подход Yate, в котором можно управлять каждым чихом системными сообщениями.
Asterisk'у этого и не снилось. В нем на каждый чих пишут новый модуль. Поэтому можно сказать, что Asterisk сложнее, чем Yate.
Что такое Asterisk? Это монолитное ядро с подгружаемыми модулями, которые встраиваются в основное ядро и реализуют какой-нибудь дополнительный функционал. Но данный функционал не может выйти за рамки разработчика модуля. Понадобился дополнительный -- пиши свой модуль или правь готовый модуль. Далеко не каждый это может сделать. Но есть куча разработчиков разного уровня, которые стараются наплодить модули на все случаи жизни, т.е. делают то, чего тебе как раз не нравится: "АТС с мильярдом настроек на все предполагаемые случаи жизни". Так что возможности Yate в данном случае явно выиграшнее.
В не ненадо писать новый модуль, т.к. можно писать к примеру ivr на php и управлять непосредственно из скрипта любой частью самого Yate.

Вот 3 разных подхода:
1. sipX. имеет законченный функционал, подходит в качестве SOHO на предприятия до 1000+ абонентов. Никаких особых излишеств, все варианты продуманы разработчиками. Чего-то не хвататет -- особо некуда двигаться.
2. Asterisk - пишем модули на все случаи жизни.
3. Yate - как пластилин -- можно сделать все, что угодно путем обмена сообщениями с любым из компонентов из dialplan'а. Это сложнее и многих отпугивает, но больше гибкости.

Что-то среднее -- как раз asterisk. А уж выбирает каждый свое.

[tma]

но я бы сказал в астериске тоже что то на подобии этого есть, AMI кажись называется? (забыл уже)

Нет, AMI скорее диалплан через tcp/ip и средство получения эвентов. (сейчас switch налетит как коршун )
Сравнить его с обменом сообщениями в Yate можно только с натяжкой.

еще раз привожу пример с GSM телефоном
поднимите руки кто покупает конструктор - сделай сам
и сам паяет себе GSM телефон и настраивает его потом?

Давно пытаются создать чистой воды терминал, чтобы вся логика выполнялась на стороне сервера.
GSM-телефон конечно не полный терминал, но близок к тому.
Может так и правильнее будет? Для пользователя -- дешевле уж точно.

валяется где то Smile у меня... руки не дошли посмотреть его

Хрень с интерфейсом на java.

неее. не тот уровень астракции
тогда уже в Yate тоже все встраивается в ядро

Согласен с замечанием. Не совсем правильно описал свою мысль.

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

Здесь обязательно будет потеря функциональности, я думаю. Но смотря на то, что хотелось реализовать. Пока не понятно...

[tma]

в Yate просто модуль есть отдельный который без tcpip ползовляет это управлять
но есть же и 127.0.0.1 интерфейс управляения которые через php работает

Нет, в Yate есть монитор, аналог AMI от asterisk'а.
Но AMI нельзя сравнивать с обменом сообщений в самом Yate -- это две разные вещи.
Asterisk имеет закрытую архитектуру, расширяется только путем написания дополнительного модуля, а в Yate можно управлять всем и вся. Да, нужно написать для этого свой модуль для обмена сообщений, но его нельзя сравнивать с Asterisk. Подход слишком разный. У Asterisk'а все направлено на расширение dialplan'а. Многие считают его верхом совершенства, но он перегружен очень сильно, концепция Yate в этом отношении лучше.
Но, как я уже говорил, подход Asterisk'а тоже неплох -- он проще. Проблема в реализации, а не в подходе.

[tma]

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

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

тебе два человека (которые априори лучше тебя в теме разбираются) твердят, а ты снова о своих "совершенно разных вещах". Надоело уже. Ты же реально не знаешь AMI и с чем его едят. Не представляешь, что может дать AMI и AGI при совместном использовании.

switch, я писал биллинг, который сейчас работает в одной конторе, с использованием AMI (демон, контролирующий вызовы) и AGI (сам биллинг, логика в SQL). В дальнейшем дописав поддержку RADIUS для работы с gnugk и mera mvts.
Я действительно наверное не знаю его, раз ты так утверждаешь. Куда уж мне...

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

Я лишь пытаюсь объяснить, что AMI можно сравнить с rmanager'ом в yate, но никак не с обменом управляющими сообщениями о которых идет речь применительно к yate. Чтобы это понять, тебе нужно очень пристально посмотреть на yate, но не на его rmanager -- он мало на что годится.
Но ты же не отвлекаешься от asterisk'а и в этом твоя беда -- вокруг все течет и меняется, появляются новые продукты. Одни исчезают, другие совершенствуются. Я помню FreeRADIUS в зародыше -- падал при каждом чихе. Сейчас это очень стабильный продукт, используемый в том числе и в проприетарных биллинговых системах.
Разница Yate с его сообщениями и AMI в том, что с помощью этих самых сообщений построена и функционирует весь Yate.
AMI же используется для взаимодействия внешних программ к строго ограниченному интерфейсу. В некоторых случаях который просто копирует CMD (например очереди), что потом приходится парсить вывод.

С помощью AGI можно вполне избавиться от диалплана. Но тоже самое есть и в Yate, только там вся система так работает по определению, а в asterisk'е это скорее побочный эффект.

Ты сам-то Yate использовал? Посмотри скрипты к нему, где реализованы IVR и т.д. Вот тебе ссылка на интерфейс.

И как я уже писал выше -- все 3 метода имеют право на существование.
Они подходят для разных задач. sipX - готовый продукт, Yate - скорее конструктор, а asterisk что-то среднее.

[tma]

Бесполезный потому, что ни тебя, ни tma переубедить невозможно.

Разве смысл спора только в том, чтобы кого-то переубедить?
Тебя же тоже не переубедить?!!
В споре рождается истина.

[tma]

Задача биллинга и машрутизации направлений в хулиселе решается на раз-два, ничего алгоритмически сложного в ней нет.

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

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

Предлагаю тебе реализовать на asterisk'е 2 простые вещи:
1. отключить транскодинг, в принципе, а не чтобы он по собственному желанию вдруг его включал.
2. отключать/включать проксирование по желанию (только не путем транскодинга через SLIN)

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

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

Таких преимуществ, чтоб прям сказать, убийственных не вижу, как в прочим и те десятки тысяч людей, которые ежедневно ставят астериск и плевали на недоделанный SIPX и прочие YATE.

Это только от узости мышления.

[tma]

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

Ok, подведем черту. Правда я не нашел актуальных для себя вопросов, поэтому и не смог на них ответить.
Ты отвечаешь избирательно и я тоже отвечаю избирательно. Каждый смотрит со своей колокольни.
Еще одна задача для тебя на закуску про биллинг, который написать легко: мультивалютность с возможностью смены валюты клиентом. Заманаешься воевать с курсовой разницей...
Ты смотришь с колокольни клиента, а я с колокольни оператора.
Оба не могут существовать друг без друга, по крайней мере еще долго без оператора обойтись будет нельзя.
Давайте жить дружно (C) Леопольд...

[tma]

не думаю что и оператор долго протянет без клиентов, не так ли?

Кто ж спорит. Но клиенты еще долго не смогут обходиться без них, а возможно никогда (транспорт кто-то же должен обеспечивать).
А дальше: существование единого плана нумерации, поддержка вызова экстренных служб и т.д.
Так что VoIP при том, что может существавть почти что сама по себе из-за возможности соединения peer-to-peer без операторов еще долго не сможет обойтись.
Тот же Skype не может жить без центральных серверов. Что показали недавние проблемы. Полностью система не может быть децентрализованной. Как не пытайся, а для связи между собой оператор понадобится. Может измениться предоставляемый сервис, как то произошло с операторами интернета, которые теперь больше сервис и контент -провайдеры, а не только тупо гоняют интернет.
Поэтому нужно жить дружно, а не жрать друг-друга как пауки в банке.

А причем тут мультвалютность я не не понял.

Это к вопросу о биллинге к вопросу о:

Задача биллинга и машрутизации направлений в хулиселе решается на раз-два, ничего алгоритмически сложного в ней нет.

Ты читаешь уж больно избирательно...
Реши простейшую на твой взгляд задачу -- тебе будут благодарны организации, занимающиеся импортом/экспортом и банки, а не только операторы и биллингописатели.

[tma]

Я оставил 20 модулей, астериск работает.

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

Из этих 20 модулей можно сделать телефонную систему (в понимании астериска - диалплан) любой сложности на AGI+AMI.

И что ты этим доказал? Только то, что половина модулей нафиг не нужна и это тебе давно пытаются втолковать.

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

Ой как мне стыдно...

Но каким бл@дь боком ты мультивалютность прикрутил к функциям софтсвича - я не знаю.

О биллинге ты сам вспомнил...

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

Видимо я где-то тебе написал, что задачи офисной АТС можно решать на softswitch class IV?
Или ты только сейчас понял, зачем может понадобиться вытащить ненужный функционал из asterisk'а?
Но ты так и не понял, почему его нельзя использовать везде...

[tma]

ну и какой функционал из оставшегося тебе не нужен? ПРИВЕДИ ПРИМЕР, а не гунди.

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

неадекват, граничащий с тупостью

Перешли на личности? Ok, разговор окончен.