Comments 21
1. Вы не рассматривали вариант использования боксовых решений по типу Elastix, Trixbox, etc?
2. Отчеты из CDR Вы тоже скриптами прямо из мускуля выгружаете?
2. Отчеты из CDR Вы тоже скриптами прямо из мускуля выгружаете?
Требую! чтобы все кто занимается настройкой АТС на базе протокола SIP, позволяли звонить из интернета внутренним абонентам сервера на прямую на SIP адрес, по умолчанию!
Есть тут и обратная сторона медали. Телефон можно относительно дешево хм… спамить.
Вот когда появится что то наподобие спам листов, тогда можно подумать о таких разрешениях, а пока что fail2ban и всех посторонних лесом ибо трафик жалко на этих всех брутфорсеров…
Друзья, по моему вы решаете проблему которой еще не существует. У нас на обслуживание тысячи людей, имеющие данную возможность, но до сих пор ни разу не пожаловались. Наверно сначала стоит заниматься популяризацией технологии, а когда проблема станет актуальной заниматься собственно проблемой. А то как в анекдоте про корову, которую еще не купили.
Мы тоже у вас на обслуживании =)
Вот смотрите, как я могу узнать, что конкретному абоненту с номером 7 495 1234567 ext123 можно звонить через SIP?
Желательно для трёх случаев: оба абонента ваши клиенты (у них один провайдер АТС, но номера всё равно где) и ваши абоненты a и b (по отдельности).
Есть решения уровня DNS. Как вы считаете, насколько сильно они распространены?
Спасибо.
Вот смотрите, как я могу узнать, что конкретному абоненту с номером 7 495 1234567 ext123 можно звонить через SIP?
Желательно для трёх случаев: оба абонента ваши клиенты (у них один провайдер АТС, но номера всё равно где) и ваши абоненты a и b (по отдельности).
Есть решения уровня DNS. Как вы считаете, насколько сильно они распространены?
Спасибо.
Мы тоже у вас на обслуживании =)— Спасибо.
Вот смотрите, как я могу узнать, что конкретному абоненту с номером 7 495 1234567 ext123 можно звонить через SIP?— Прямой связи между городскими номерами и SIP адресами нет, мы задумываемся над бесплатным сервисом который позволил-бы эти связи определять, но тут пока больше вопросов чем ответов.
Узнать о наличие SIP адреса можно только если владелец адреса прямым способом сообщит об этом, для примера в подписи к электронному письму, пример (http://call2sip.ru/#222@bustel.onlinepbx.ru).
Также существует другая проблема, практически ни в одной публичной базе данных предприятий или CRM системе, нет возможность указать SIP адрес, но полагаю это следствие не популярности технологии в целом.
Есть решения уровня DNS.— Честно признаюсь, я о таких не знаю.
Мы в amocrm принципиально не накладываем ограничений на то, что можно вписать в поле «Телефон». Другое дело с кнопкой позвонить, часть софтфонов не понимает call:sip@provider.ru, поэтому, всё, что отлично от цифр режется.
По поводу DNS: www.e164.org/ www.ietf.org/rfc/rfc2916.txt (даже делегирован: www.internic.net/zones/arpa.zone). Но не понятно, как заставить этим пользоваться провайдеров линий.
По поводу DNS: www.e164.org/ www.ietf.org/rfc/rfc2916.txt (даже делегирован: www.internic.net/zones/arpa.zone). Но не понятно, как заставить этим пользоваться провайдеров линий.
Мы в amocrm— Парни вы исключение из правил, признаться такого уровня оперативности, отзывчивости и открытости к общению я больше не встречал. Так держать.
часть софтфонов не понимает call:sip@provider.ru— Попробуйте так sip:number@example.com, phonerlite поймет.
По поводу DNS: www.e164.org/ www.ietf.org/rfc/rfc2916.txt (даже делегирован: www.internic.net/zones/arpa.zone). Но не понятно, как заставить этим пользоваться провайдеров линий.— На мой взгляд это утопия. Операторы никогда не отдадут свой хлеб, его надо отбирать.
Сегодня редкий представитель молодого поколения покупает телефон без 3G, WiFi и сенсорного экрана, а как часто вы набираете телефонный номер не из телефонного справочника, а путем набора цифр? Я не вижу какой-либо проблемы набрать в место номера SIP адрес, по моему он даже лучше запоминается. Вопрос лишь в популярности технологии.
Я уверен в том что протокол SIP займет свое почетное место в нашей жизни, также как и mail: ведь у них одинаковый фундамент.
Вопрос.
1) при переводе звонков это будут, я так понимаю, разные записи в CDR. Часто есть необходимость связать эти переводы. (напр, ответить на вопрос кто звонил в бухгалтерию с 12 до 14 вчера).
2) Как вы пробрасываете (если пробрасываете) входящий номер телефона до конечного абонента. Например, звонок в ТП, та переводит на бухгалтерию. Узнает ли бухгалтерия номер звонящего?
Мне кажется, офисная АТС в первую очередб должна давать ответы на эти вопросы.
Заранее спасибо!
PS Есть ощущение, что в freepbx, например, много чего описанного в статье есть «из коробки». AGI впиливается довольно просто. Почему не стали использовать его как стартовую платформу?
1) при переводе звонков это будут, я так понимаю, разные записи в CDR. Часто есть необходимость связать эти переводы. (напр, ответить на вопрос кто звонил в бухгалтерию с 12 до 14 вчера).
2) Как вы пробрасываете (если пробрасываете) входящий номер телефона до конечного абонента. Например, звонок в ТП, та переводит на бухгалтерию. Узнает ли бухгалтерия номер звонящего?
Мне кажется, офисная АТС в первую очередб должна давать ответы на эти вопросы.
Заранее спасибо!
PS Есть ощущение, что в freepbx, например, много чего описанного в статье есть «из коробки». AGI впиливается довольно просто. Почему не стали использовать его как стартовую платформу?
Во freePBX много всего наворочено. Эта платформ хороша, когда не нужно ничего кастомизировать. Когда нужно только вбить значения. Если же есть какие-то изменения, то начинается ковыряние, которое таки приводит к результатам, но времени на это требуется все равно больше.
ИМХО написание диалпланов в конфигурационных файлах гораздо удобнее и быстрее, чем управление ими через веб.
ИМХО написание диалпланов в конфигурационных файлах гораздо удобнее и быстрее, чем управление ими через веб.
AGI — плохо, его следует избегать, особенно в тех случаях, когда можно обойтись без него (у вас именно такой). Не только из соображений надежности и производительности, но и из соображений удобства отладки и поиска проблем.
Macro() можно заменить на Gosub().
MySQL тоже не нужен, данные, которые вы храните в нем, прекрасно лягут во встроенную key-value БД астериска.
Macro() можно заменить на Gosub().
MySQL тоже не нужен, данные, которые вы храните в нем, прекрасно лягут во встроенную key-value БД астериска.
С чего Вы взяли, что AGI это плохо и его следует избегать??? Аргументы в студию!
Как я уже сказал в своем предыдущем комментарии, хотя бы из-за неудобства отладки (надо смотреть логи АТС и логи AGI-скрипта, да еще пытаться как-то синхронизировать записи в них, чтобы понять, как проходил звонок и в чем была проблема).
Кроме того, каждый вызов AGI (если вы не используете FastAGI) — это, как минимум fork+exec, со всеми накладными расходами, после чего AGI-скрипт будет загружаться/интерпретироваться — вроде бы, мелочь, однако в один прекрасный момент дохленькая ембедед система может ВНЕЗАПНО перестать справляться с нагрузкой. Кроме того, по-крайней мере, в старых версиях астериска с помощью AGI можно было словить по парочке дедлоков в день — сейчас, это, конечно, исправили, но осадочек, как понимаете, остался.
А еще может, например, винт умереть и унести с собой в могилу всю телефонию офиса — скрипт-то не кэшируется в памяти, а каждый раз загружается с диска. «Голый» астериск с дохлым винтом может работать неделями, а то и месяцами (было на практике) — больше чем достаточно, чтобы подготовить замену.
В общем, люди вполне справедливо ожидают от программной АТС надежности, сравнимой с дубовым «панасом», который один раз прикрутили на стенку в самом темном углу серверной и забыли, так что надо по-возможности делать ее (АТС) просто и надежно :)
Кроме того, каждый вызов AGI (если вы не используете FastAGI) — это, как минимум fork+exec, со всеми накладными расходами, после чего AGI-скрипт будет загружаться/интерпретироваться — вроде бы, мелочь, однако в один прекрасный момент дохленькая ембедед система может ВНЕЗАПНО перестать справляться с нагрузкой. Кроме того, по-крайней мере, в старых версиях астериска с помощью AGI можно было словить по парочке дедлоков в день — сейчас, это, конечно, исправили, но осадочек, как понимаете, остался.
А еще может, например, винт умереть и унести с собой в могилу всю телефонию офиса — скрипт-то не кэшируется в памяти, а каждый раз загружается с диска. «Голый» астериск с дохлым винтом может работать неделями, а то и месяцами (было на практике) — больше чем достаточно, чтобы подготовить замену.
В общем, люди вполне справедливо ожидают от программной АТС надежности, сравнимой с дубовым «панасом», который один раз прикрутили на стенку в самом темном углу серверной и забыли, так что надо по-возможности делать ее (АТС) просто и надежно :)
Аргументы весомы, однако в некоторых случаях не соглашусь.
Во-первых, AGI очень легко дебажится и на стороне самого астериска и на стороне AGI.
Во-вторых, call flow очень тяжело потом вытянуть из логов (тут я не имею ввиду тупой CDR), а например, поведение диалплана в каком-то конкретном звонке, при потоке в 100-200 одновременных звонков. Но зато AGI-приложение, используя **правильный** логгинг позволяет все найти и вычислить проблему…
А Вы думаете, внутренние фишки не форкаются? Попробуйте например сделать 'fine convert /blabla/file.alaw /blabla/file.ulaw' и посмотреть, что оно делает. Да, оно не просто форкается, там делается ast_pthread_create, потом pthread_getschedparam, а если еще стоит полиси SCHED_RR, то и pthread_setschedparam. Все это я к тому, что в некоторых случаях, внутренние экзекуты диалплана на порядок медленнее, чем execve+fork внешнего AGI-скрипта.
На счет умирания винта — это да :-).
Однако звонки так же не проходят, если например /var раздел (куда пишет астериск логи) переполяется. Голый астер много логов не пишет (если конечно там в cli.conf не стоит set debug atleast 100 (ну и с verbose так же)).
Как говорится, на вкус и цвет фломастеры разные.
Во-первых, AGI очень легко дебажится и на стороне самого астериска и на стороне AGI.
Во-вторых, call flow очень тяжело потом вытянуть из логов (тут я не имею ввиду тупой CDR), а например, поведение диалплана в каком-то конкретном звонке, при потоке в 100-200 одновременных звонков. Но зато AGI-приложение, используя **правильный** логгинг позволяет все найти и вычислить проблему…
А Вы думаете, внутренние фишки не форкаются? Попробуйте например сделать 'fine convert /blabla/file.alaw /blabla/file.ulaw' и посмотреть, что оно делает. Да, оно не просто форкается, там делается ast_pthread_create, потом pthread_getschedparam, а если еще стоит полиси SCHED_RR, то и pthread_setschedparam. Все это я к тому, что в некоторых случаях, внутренние экзекуты диалплана на порядок медленнее, чем execve+fork внешнего AGI-скрипта.
На счет умирания винта — это да :-).
Однако звонки так же не проходят, если например /var раздел (куда пишет астериск логи) переполяется. Голый астер много логов не пишет (если конечно там в cli.conf не стоит set debug atleast 100 (ну и с verbose так же)).
Как говорится, на вкус и цвет фломастеры разные.
call flow целиком вытягивается с помощью fgrep ИМЯ_КАНАЛА /var/log/asterisk/full, что ж тут сложного :)
Я не думаю, я знаю, что астериск не форкается — он сугубо многопоточный и живет в одном процессе, а форк там используется только в нескольких местах (AGI, app_mp3, app_festival и т.д.) — можете посмотреть исходники :) Ну а создание потока — это быстро и дешево. Ну а что касается file convert — это, вообще говоря, не функция диалплана, а команда CLI, которая в общем случае не должна участвовать в обработке звонка.
И, кстати, если файл логов недоступен для записи, астериск все-таки продолжает обрабатывать звонки.
Я не думаю, я знаю, что астериск не форкается — он сугубо многопоточный и живет в одном процессе, а форк там используется только в нескольких местах (AGI, app_mp3, app_festival и т.д.) — можете посмотреть исходники :) Ну а создание потока — это быстро и дешево. Ну а что касается file convert — это, вообще говоря, не функция диалплана, а команда CLI, которая в общем случае не должна участвовать в обработке звонка.
И, кстати, если файл логов недоступен для записи, астериск все-таки продолжает обрабатывать звонки.
самый дешевый шлюзик из порядочных, чтобы железный факс прицепить, — Linksys PAP2?
pap2 t38 не держит. Лучше взять Linksys SPA112
В pap2 замечательно работает G.711 Pass Through, некоторые кастомные прошивки даже держат T.38.
Почитайте тут: www.cisco.com/en/US/products/ps10030/products_qanda_item09186a0080a35e4b.shtml
Почитайте тут: www.cisco.com/en/US/products/ps10030/products_qanda_item09186a0080a35e4b.shtml
Sign up to leave a comment.
Корпоративная АТС на базе Asterisk