Сколько параллельных линий имеет SIP аккаунт провайдера?

Question

[r1der]

Здравствуйте. Ситуация следующая есть колл-центр который совершает исходящие звонки по нескольким направлениям. Пусть этот будут Уфа, Москва, Петербург, Екатеринбург, Челябинск. от 100 до 400 одновременных коннектов и звонков.
Хотим поставить сервер на Астериске и максимально скоратить расходы на связь по разным направлениям.
Смотрел в сторону МангоТелеком, очень высокие ставки по России, но зато они предоставляют 100 линий на каждый аккаунт.
А сколько линий предоставляют другие провайдеры?
Например мы подключим по разным направлениям разные провайдеры.
Скажем по городу Уфа дешевле использовать транк местного провайдера с абонентской платой за физические линии
Но что если использовать тот же СИПНЕТ для исходящих звонков в другие города? Сколько можно делать параллельных исходящих звонков с одного аккаунта? Как правильно реализовать распределение звонков? Есть ли вообще какие-то ограничения у провадйеров? Ведь по сути это телефония через интернет здесь не должно быть ограничения количеством линий.

Answer 1

[mithraen]

Не слушайте теоретиков. 400 одновременных линий на астере не проблема, но только если нет transcoding, и обработки голосового потока на стороне самого астериска.

Т.е. если опции для управления переадресацией у Dial убрать, никакого inband dtmf (но его, к счастью, и так обычно никто в трезвом уме не использует), и идентичный список кодеков для абонентских устройств и аплинка — работать оно будет без проблем.

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

www.voip-info.org/wiki/view/Asterisk+dimensioning — почитайте это. Тысячи одновременных соединений для астериска на современном серверном железе уже не проблема.

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

Comments

[merlin-vrn]

Грустный факт заключается в том, что есть эти «если нет». Бывает, приходится делать разные вещи.

Работа с телефонией на компе, зачастую, это понимание того факта, что добиться 100% утилизации процессоров нереально, и высокая загрузка — это характерный такой показатель сбоя системы. В реальности всё нормально работает при загрузке меньше 10%, если больше — начинаются слышимые проблемы.

Очень хорошо это заметно, если вы задумаетесь о работе с факсами. Любимая тема просто. Отмахнуться не получится: это настолько удобно, что никто не собирается от них отказываться; фактически я знаю людей, которые внедряют IP-телефонию исключительно в надежде, что факсы будут работать лучше. И факсы — это первое, что сломается, если хоть появятся хоть какие-то лишние задержки или потери в системе телефонии.

Я, откровенно говоря, только на АТС (ну, обычная городская АТС) видел оборудование, действительно способное стабильно обслуживать 100+ разговоров.

Я не теоретик. Я обслуживаю несколько таких систем, в том числе — IP-телефонию в такси. Хорошо знаю, что можно сделать, что нельзя, и чего это всё стоит.

[JDima]

merlin_rterm, что-то вы какую-то чушь несете…
400 одновременных звонков без транскодирования — херня (я такое выжимал из жалкого цискиного 3845-го роутера — любой современный хотя бы 4-ядерный сервер будет на порядок быстрее), сложности начинаются, когда будет 400 новых вызовов в секунду. Судя по сказанному топикстартером, такого не будет.
Если поднятая вами система захлебывается на 400 звонках, то вы что-то делаете неправильно. Может, трейсы не отключили? :) И нет, даже при 75% утилизации никаких помех быть не должно.
Что до факсов — они тем более не проблема. Причина простая: если передавать их в виде медиатрафика, то даже на идеальном канале они едва ли доедут до получателя, потому используют костыли вроде t.38.

[mithraen]

Сравнивать циску с астериском некорректно — софтсвич и многофункциональная офисная АТС сильно разные вещи. С точки зрения софтсвича у астериска на редкость ублюдочная архитектура — я код читал, и во время 1.0.* активно патчил, так что в курсе :(

Циску корректнее сравнивать с OpenSER — на котором тысячи одновременных вызовов не проблема.

С факсами, опять же, хочу напомнить что еще во времена 1.4 поддержка T.38 была кривая до безобразия. В 1.6/1.8 ситуация улучшилась, но все же с T.38 проблемы бывают. И в реальности часто приходилось гонять факсы таки в виде медиатрафика. У меня это еще в 2004-м на астере замечательно работало (в те времена поддержки T.38 там не было вообще).

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

[mithraen]

Собственно о чем мы говорим? Задача вполне реальная. И на астере, используемом топикстартером вполне решается.
А мы тут на первоначальный вопрос-то так и не ответили :)

Лимиты на количество исходящих одновременных звонков у оператора определяются во-первых его физическими возможностями (небольшой оператор использующий собственное приземление через E1 может физически не иметь столько каналов). Плюс от ценовой политики (некоторые операторы дают анлим исходящие по некоторым направлениям — ясное дело за слишком активное использование будут бить по голове).

Вопрос решается таки разговором с самим оператором.

[JDima]

софтсвич и многофункциональная офисная АТС сильно разные вещи.

А теперь нюанс. Циска — это не офисная АТС, а роутер, у которого есть обычный процессор широкого профиля (устаревший лет на 10), и в его операционке (тоже безумно устаревший IOS) есть фичи по обработке звонков.
Так что и тут у вас какие-то неверные сведения. По части производительности 3845-й роутер просто смешон — даже с точки зрения передачи пакетов.

[mithraen]

В том-то и дело, что циска это роутер. И если не пытаться вмешиваться в голосовой поток и делать всякоразную странную логику (для чего собственно и предназначен астер), то никаких проблем в передачи 400 голосовых соединений нет. Потому как 400 голосовых соединений, это всего лишь 20k pps, в которых надо тупо переписать несколько байт в RTP пакетах.

Собственно потому какой-нибудь OpenSER на современном оборудовании обработает тысячи соединений и не пискнет.

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

Астер это не софтсвич, и не SIP-proxy. От этого есть свои преимущества (фичи, невозможные для SIP proxy), и свои недостатки (по сравнению с любым SIP proxy астер это не тормоз, он якорь).

Собственно потому до времен 1.4 все, кому нужен был большой трафик (операторы), старались использовать астер в связке с OpenSER. Где коммутация делается средствами OpenSER, а всякие фичи — коллцентр, интерактивные услуги, и т.д. — на астере.

[JDima]

«если не пытаться вмешиваться в голосовой поток и делать всякоразную странную логику»
Про что речь? Транскодирование? Больше ничего на ум не приходит. Выбор направления посылки вызова как раз не является никакого рода странной логикой.
«А астер, напомню, на эти 400 соединений еще и создаст по треду на каждое»
Вы серьезно? До сих пор, для роли простого IP-IP шлюза создается по потоку на звонок, или в 1.6 это поправили? Я просто никогда конкретно с астериском всерьез не работал и предполагал, что его разработчики не являются идиотами.

[mithraen]

1. Ну например начиная с 1.6 там можно ставить фильтры обработки голоса :) Проигрывание музыки в линию, конференц-связь. 3-х сторонные конференции, и прочие радости жизни. Это-ж офисная АТС, там много мелких фич. Да даже трансляция DTMF из inband в более человеческие форматы.

Напомню, что для астера SIP всего лишь один из channel modules.

2. На 1.6 не проводил тесты. Но, насколько я знаю архитектуру, сомневаюсь что они это исправили. Другое дело, что после установления соединения, если это SIP2SIP без опций обработки DTMF, то тред передаст соединение rtp-движку, и вся обработка rtp будет в рамках одного треда AFAIR.

В старых-то версиях еще прикольнее было, каждый RTP пакет сначала разбирался во внутренний астерисковский формат фрейма, а потом собирался заново. Это только в 1.4 они сделали вообще отдельный rtp-движок, который при прямом соединении без транскодинга тупо менял таймстампы в rtp и передавал его дальше.

Разработчики идиотами не являются, но пишут продукт явно несколько сложнее своей компетенции. Вы в исходники посмотрите, особенно в исходники chan_sip. Который, фактически, один человек писал. Перед просмотром не забудьте взять рвотный пакетик и успокоительное — понадобится.

На самом деле я восхищен тем, что ЭТО умудряется как-то работать. И дедлочится всего лишь при некоторых конфигурациях, а не постоянно (на тамошнее использование локов смотреть настоятельно не рекомендую — успокоительное не поможет, и может потребоваться срочная психиатрическая помощь).

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

[JDima]

Проигрывание музыки в линию, конференц-связь. 3-х сторонные конференции, и прочие радости жизни.

MOH и CFB (в случае low-complexity кодеков вроде g.711) не дает существенной нагрузки. В случае колл-центра количество конференций стремится к нулю, а MOH тоже будет большой редкостью.

Остальное — да, почитал, ужаснулся. Но даже со всеми этими ужасами, если не напрягать машину транскодированием (ну да, еще CFB на тяжелых кодеках вроде g.729) — 400 одновременных звонков любая относительно современная машина должна переварить без всяких проблем.

[mithraen]

Практика доказывает что вы правы :)

Answer 2

[merlin-vrn]

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

Например, готовое коробочное решение на базе Asterisk от Digium (разработчики Asterisk), Switchvox — для старшей модели обещают 75 одновременных вызовов. Вам потребуется три таких железки, чтобы обслужить ваш предполагаемый уровень нагрузки.

Comments

[r1der]

здесь именно программное ограничение или аппаратное? в чем обычно возникает проблема? У нас Астериск на 4x Xeom 5350(4 core) 64 gb ddr
должно хватать поидее, как вы считаете?

[merlin-vrn]

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

Какое pps вообще переживает операционная система? (Ну, хотябы флуд-пингуйте ping -f сразу из нескольких мест и наблюдайте.) Какая загрузка процессоров? Какие при этом статистики прерываний (хотя бы из /proc/interrupts)?

[Григорий Лямин]

75 одновременных вызовов в Switchvox — это уже старые данные. По факту использования, при использовании современного процессора, «затыки» случаются только при >120 звонках.

Answer 3

[merlin-vrn]

В Сипнет — сколько угодно. По крайней мере, у нас не получилось добраться до ограничения, когда мы это проверяли.
Каждый разговор будет тарифицироваться независимо.

А вообще зависит от провайдера и прописывается в договоре.

Answer 4

[mithraen]

100% утилизация процессора на сервере вообще это зло. Особенно для realtime задач (к коим относится и IP-телефония).

С факсами — согласен, тут все уже зависит от задач. Когда делал крупные системы для офисов, факсы обслуживались отдельно (вплоть до подключения к отдельным шлюзам, которые напрямую связывались с оператором).

Но более 900 одновременных соединений в 1 сервере я успешно делал. Жалоб на качество связи при этом не было.

С тем что все зависит от конкретных задач и требуемых сервисов — опять же согласен.

К счастью телефония прекрасно кластеризируется.

Конкретно в исходной задаче решение очевидно — зажать G.729 как требуемый кодек для всех peer'ов (потому как все транки обычно умеют его, но не все умеют G.711) — тем самым избавиться от транскодинга. Думаю даже transfer работать под такой нагрузкой будет, хотя надо проверять.

Если понадобится запись переговоров (а она наверняка в call-центре понадобится), вот там будет засада — ибо 400 потоков записи на диск убьют дисковую подсистему напрочь. Так что писать придется на tmpfs, а потом переносить одним потоком на диски. Кроме того писать придется прямо сырой G.729, а чем и где его потом перекодировать в пригодный для прослушивания формат — отдельная песня.

В общем ничего нерешаемого тут нет. Это задача — непростая, требующая подбора оборудования, тестов, и т.д. — но вполне решаемая.

Answer 5

[helsiby]

Попбробуйте МультиФон.
Мегафон сейчас стал предоставлять услуги SIP-транкинга. Количество параллельных входящих/исходящих конфигурируемо.

Comments

[iscsi]

У услуги «Мультифон» ужасный уровень сервиса. Рекомендую МТТ.

[Александр Хамидулин]

Я вот МТТ я вспоминаю как страшный сон. Два месяца я пытался заставить нормально работать их номера. При том что Астериск у меня уже к тому моменту год держал больше десятка номеров от 5 разных провайдеров и никаких проблем. А в МТТ так и не смогли сделать так, чтобы их тел.номер нормально работал. Он периодически отказывался принимать вызовы, показывая отсутствие регистрации СИП-аккаунта... в топку их.

Answer 6

[iscsi]

400 одновременных разговоров для asterisk не проблема, если:
1) Используется packet2packet bridging (sip to sip, h323 to h323) например, когда RTP пакеты обрабатываются в RTP стеке и asterisk не выделяет отдельный поток для его обработки;
2) Не используется MOH — asterisk в этом случае выступает микшером голосовых потоков, причем использует транскодинг в свой внутренний формат slin (можно посмотреть asterisk -rx 'core show translation';
3) Не используется In-band DTMF.

Answer 7

[iscsi]

Товарищу mithraen, cisco 3845, а конкретней CUCME, это шлюз чистой воды, на роль sip proxy она не «тянет», в CUCME можно использовать подобную функциональность, называется она CUBE.

Answer 8

[Александр]

Спросите у телекомтехнолоджи (в гугл)