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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Так что мыши плачут, колятся, но кактус жрать продолжают — пляшем с бубном и в каждой конкретной ситуации добиваемся его работоспособности.

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

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

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

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

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

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

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

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

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

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