Pull to refresh

Comments 31

По порядку и, по возможности, более конструктивно, чем оратор выше:
«Primary Rate Interface»: физический интерфейс с гарантированной доставкой пакетов и выделенными каналами по 64 килобита.
Поток E1/T1 — это коммутация каналов, а не пакетов. И никаких механизмов гарантированной доставки там нет.
от 4 до 16 E1-подключений, каждое из которых по 32 канала для голоса, несильно сжатого g.711 и сигнализации.
Во фрейме E1 30 тайм-слотов под голос, один под сигнализацию (16-й) и один под тактовую синхронизацию (0-й).
На почетном втором месте SIP со стыком через обычную ethernet-сеть или даже интернет.
И опять: «обычную Ethernet-сеть» нужно читать как «выделенный канал». В противовес публичному Интернет-каналу. На уровне L2/L1 доступ может предоставляться как угодно, лишь бы была IP-связность поверх. На то он и VoIP.
порядочность интернет-провайдеров, которые иногда настраивают QoS (но чаще – нет).
Интернет по своей природе не имеет никаких гарантий передачи данных и параметров качества обслуживания. Любой публичный трафик идет как best effort. Сетевой нейтралитет и все дела (его отмена местами — отдельная тема для разговора).
это номер сотового. Абонент сейчас уже говорит по телефону. Куда девать еще 10 входящих на этот же номер?
Внезапно, отправить на этот же сотовый второй линией или поставить в ожидание. Как Вы заметили, это логическое ограничение.
На практике можно ожидать корректную работу до 100 параллельных вызовов на один номер.
Только стоит обозначить, что это именно ваша практика. Колл-центры федерального масштаба могут иметь в разы больший поток вызов и количество линий для них.
Разделение на «городской номер», «ABC географически определенный номер», «мобильный номер», «DEF географически неопределенный номер» — оно условное. Не более чем договоренности операторов о формате и кто кому сколько будет платить за обслуживание данного конкретного номера
Есть в РФ такое Министерство Информационных Технологий и Связи, и все «не более чем договоренности» регулируются на уровне Приказов и Федеральных Законов, за нарушение которых провайдер может остаться слегка без лицензии. Географически определяемые номера законодательно привязаны к региону (отсюда и название), провайдер из Москвы не может дать номер в ABC-коде 495 абоненту из Владивостока. На DEF подобное ограничение не распространяется.
Что там будет написано: «84951234567», "+79261234567" или что еще — это уже как договорятся операторы и регуляторы в конкретной стране и регионе. И да, единого стандарта «на весь мир» у нас нету.
E.164 от ITU-T?
Хабр — торт. От себя добавлю, что 100 одновременных — это то, что можно ожидать «из коробки». У некоторых наших клиентов намного больше, но такие объемы уже лучше предварительно согласовывать, чтобы проверить интерконнекты и все прочее, что может стать бутылочным горлышком.
И я выше сам оговорился: синхронизация в нулевом тайм-слоте в Е1, конечно же, цикловая.
И что же с многоканальностью?
Итак, имеем 2 факта:
Здесь по-моему нужно выделить несколько другие моменты:
1. Вызов на какой-то номер — это абстракция. Грубо говоря, это выглядит как «вызываемый номер Б -> маршрутизировать туда».
2. Реализация накладывается на физические (производительность оборудования, пропускная способность или емкость каналов связи и т.п.) и логические (количество линий по договору, возможности оборудования и ПО, логика маршрутизации и т.п.) ограничения операторских сетей и абонентских стыков.
«Туда» может быть как одной линией (физической или виртуальной), так и несколькими. А может быть и вовсе другим номером, если включена переадресация (безусловная или при занятости/переполнении).

К слову, абонентских стыков под один и тот же номер может быть энное количество по разным технологиям. Например, в сначала вызовы приходят в Е1, затем — в SIP-транк, а если первые два варианта недоступны — по старому медному многопарнику на FXO-порты. Как-то так обычно делается (гео)резервирование и отказоустойчивость.
Да, я не стал излишне усложнять описание. Не для телекомщиков очень много терминов, а телекомщики и так знают как эта магия работает.
Во фрейме E1 30 тайм-слотов под голос, один под сигнализацию (16-й) и один под тактовую синхронизацию (0-й).

16 — это только в PRI принято, для SS7 сигнализация может быть, и довольно часто либо в отдельных слотах в конкретном потоке (для экономии того самого таймслота ибо сигнализации так много не надо), либо вообще по IP (ибо ее наоборот может быть очень много и совершенно не связанной с голосом).
Кстати автор это заметил по ходу не углубляясь в детали — ибо у каждой технологии своя специфика
Раньше было 30А + 2Б, но сейчас там действильно все довольно гибко.
Писк-восторг по отношению к javascript так смешно читать.

Как-будто бы плотник начал рассказывать — «а вот мой молоточек, мои гвоздички»
Так все остальное у всех плюс-минус одинаковое. А JavaScript мы любим. Это удобно. Компании могут делать телефонную автоматику силами своих веб разработчиков. Это круто.

P.S. Если ты продаешь молотки, то вполне логично рассказывать, какие они клевые :)
плотник не продаёт молотки

он делает мебель

и клиенту пофиг, какие молотки и гвоздики у плотника

ему важно качество мебели
Но мы-то не плотники. Мы производители молотков :) А нашу платформу уже используют и те, кому нужна телефония для себя (ритейл, такси, банки) и те, кто ее добавляет в свои продукты (CRM, телемедицина, хелпдеск)
eyeofhell Все хотел спросить, на каком движке работает VoxEngine? Находится ли под капотом V8 или что-то похитрее?
V8 заточено под соло работу. Один браузер, одна нода, вот это все. А когда на одном физическом сервере несколько сотен параллельных звонков, у каждого в реальном времени выполняется JavaScript и клиент по ошибке крутит бесконечный цикл и кушает память, то V8 лопается.
Со времен начала наводнения фальшивых звонков в пожарные службы в России хотел узнать — вызывающего абонента определяют по CID или ANI?
По CID. ANI — это внутренняя штука для биллинга номеров вроде 8-800
Если так почитать, то, получается, ваша уникальность — всего лишь в использовнаии JavaScript? Вряд ли так просто, потому что иначе то же (или более-менее то же, и более-менее теми же руками) делается и не только на JS.
У вас, конечно, вроде как все из коробки, но к вам же и привязано, и игра идет по вашим ценам за все.
Строго говоря, мы единственные, кто позволяет управлять звонками в реальном времени. JavaScript мы выполняем параллельно со звонком, и задержки между командами и тем, что происходит с голосом и видео, минимальные.

Но мы стараемся делать не «уникальные фишки», а удобное управление телефонией для разработчиков. У нас большая телеком экспертиза (более 10 лет), много телекомщиков в команде, мы это любим и умеем. С помощью Voximplant можно собрать автоответ, уведомление о доставке или видеомост за полчаса. И оно будет просто работать. Причем сделать это может обычный веб разработчик, знания Asterisk не требуются :)

При этом мы хорошо масштабируемся — на нашей платформе собиаются очень разные штуки, от простых демок на хакатонах до огромных телефоний вроде Битрикс24
Строго говоря, мы единственные, кто позволяет управлять звонками в реальном времени.

Это не так: Twillio, Plivo, Nexmo позволяют делать тоже самое. Яндекс.Телефония вроде как тоже двигается в эту сторону.
Уверен что помимо перечисленных провайдеров, также существуют десятки других, со схожей функциональностью, просто эти мне сразу пришли на ум, так как с ними приходилось иметь дело.

У всех перечисленных клиент-серверное взаимодействие, это не Realtime.
Прошу прощения, возможно я что-то не так понял. Не могли бы вы объяснить, чем отличается ваш WebSDK от того же Plivo или twilio-js и в чем заключается его Realtime-овость?
Web SDK — это чтобы веб страница могла звонить и принимать звонки. Секретный соус в VoxEngine — это JavaScript, который выполняется у нас в облаке в ответ на любой входящий или исходящий звонок: с сотового, Web SDK, мобильного SDK, SIP железки… Можно делать решения вообще без SDK, только на телефонных номерах и облачном JavaScript, который рулит звонками.
Спасибо за труды, в целов реклама прошла успешно…
у SS7-ISUP есть много разных вариантов представить «кому звоним», но в общем случае можно ожидать именно текстовую строку.
Параметры ISUP Called Party Number и Calling Party Number, исходя из своего названия, передают номер, то есть число. Каждая цифра этого номера кодируется четырьмя битами (комбинация 1111 — окончание номера, 1001-1110 — свободные). Это не считая индикаторов Numbering plan, Nature of address, Screening, Address Presentation, которые идут отдельными полями суммарной длиной в 16 бит.

О других способах передачи номеров вызывающих/вызываемых абонентов, которые реально используются на телефонных сетях общего пользования, я не слышал. Вы пишите про «много разных вариантов». Можете привести пример?
В length indicator и nature of address можно много всего записать интересного. Но скажу честно — таки да, я умышленно привел их к общему знаменателю чтобы сделать понятную статью. На практике в тех wireshark логах что я видел у коллег там только цифры. Но Хабр же не только торт, но и научпоп? Если писать все как есть, то кроме узких спецов никто не поймет о чем это. Кошелек Миллера, все дела.
Статья могла бы быть короче:
"
1) телефония, я для вас специально упростил, и местами написал ерунду, но это же научпоп, оно для вас и так прокатит, вот вам мой бисер.
2) javascript это сила
"
Ерунду я нигде не писал :) Рассказывать о том, как стек протоколов и стандартов SS7 переплетается с физическими интерфейсами — это тема отдельной статьи. Упор этой на многоканальность, задача — рассказать, как это устроено и как разработчики могут этим воспользоваться. А JS крутой. Особенно ES2018 с новыми regexp и destructuring.
Ну вот например…

— от 4 до 16 E1-подключений, каждое из которых по 32 канала для голоса, несильно сжатого g.711 и сигнализации.


От четырех ли?
До шестнадцати ли?
32 канала для голоса?
И где то сигнализация...?
Несильно сжатого… Это как?

Все верно, вы же специально откусили начало предложения, где написано "обычно обслуживает" :) Обычно один модуль расширения на 4 E1 подключения. Одно E1 подключения это 32 канала по 64 килобит. Раньше это было 30 А-каналов на голос и 2 B-канала на сигнализацию, но сейчас в SS7 сигнализация может идти по любому каналу, так что формулировка «32 канала для голоса и сигнализации» лучше отражает текущее положение дел.

Несильно сжатого — это g.711, это очень смешной аудиокодек, который жмет всего в два раза. Зато и CPU почти не использует. Legacy — оно такое.
Даже не знаю зачем вы про конкретные шлюзы в теоретической статье начали писать) не все же в курсе, что у этих шлюзов потоки Е1 включаются в работу только после установки модуля с процессором на плату для обработки сигнализации. И каждый такой модуль активирует 4 порта. Вот отсюда и есть это «от 4 до 16» (само собой 16 потому, что модуля только 4 можно установить.
И всё таки не надо ссылаться на «раньше» и всё такое… есть PRI — там по прежнему 30B+1D. Хотя 1D не пишут, а пишут просто D. Ещё один тайм слот, как у же тут упоминал, это синхронизация, где на 2МГц частоте передаётся меандр, благодаря которому TDM оборудование отсчитывает такты синхронно с встречной стороной. И этот ТС (0) — статичный, какой бы вид сигнализации не использовался в ISDN присоединение. Получается, что 30B каналов (разговорных, всё таки B а не А) это минимум на потоке можно сотворить (при полной его эксплуатации для одного присоединения), либо 31B канал на потоке, при условие, что это linkset ОКС7 и D канал находится на другом потоке. Всё таки где то он должен быть. Но в случае, когда потоков в линксете много, то с каждого экономится по 1 ТС (тайм слоту) и получится (сумма-1) дополнительных разговорных каналов со всего стыка экономии.

За статью спасибо. Когда предыдущую про волшебный DEF-963 читал, задолбало это «чЁ» в голове, прочитывая очередной параграф. Даже комментировать не стал, ибо с телефона было лень.
Sign up to leave a comment.