Во-первых, быстродействие, Go во много раз быстрее справляется с опросом маршрутизаторов, чем питон.
В задаче выше Питон для наиболее ресурсоемких частей кода является, если посмотреть чуть глубже, оберткой под C в модуле re и под C++ в модуле SubnetTree. Что вполне положительно сказывается на скорости работы скрипта.
Так что и производительность все же имеет смысл измерять и сравнивать под конкретные сценарии и ограничения.
И я выше сам оговорился: синхронизация в нулевом тайм-слоте в Е1, конечно же, цикловая.
И что же с многоканальностью?
Итак, имеем 2 факта:
Здесь по-моему нужно выделить несколько другие моменты:
1. Вызов на какой-то номер — это абстракция. Грубо говоря, это выглядит как «вызываемый номер Б -> маршрутизировать туда».
2. Реализация накладывается на физические (производительность оборудования, пропускная способность или емкость каналов связи и т.п.) и логические (количество линий по договору, возможности оборудования и ПО, логика маршрутизации и т.п.) ограничения операторских сетей и абонентских стыков.
«Туда» может быть как одной линией (физической или виртуальной), так и несколькими. А может быть и вовсе другим номером, если включена переадресация (безусловная или при занятости/переполнении).
К слову, абонентских стыков под один и тот же номер может быть энное количество по разным технологиям. Например, в сначала вызовы приходят в Е1, затем — в SIP-транк, а если первые два варианта недоступны — по старому медному многопарнику на FXO-порты. Как-то так обычно делается (гео)резервирование и отказоустойчивость.
По порядку и, по возможности, более конструктивно, чем оратор выше:
«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" или что еще — это уже как договорятся операторы и регуляторы в конкретной стране и регионе. И да, единого стандарта «на весь мир» у нас нету.
Увольняли по сокращению в нестабильном конце 2014 года. ИТ-Директор вызвал к себе, объяснил, что в Регионе принято решение подсократить российский ИТ-штат и перераспределить обязанности (это было подразделение международной промышленной компании, я там сисадминил), что претензий к моей работе нет, и могут, при необходимости, дать рекомендации. Предложили по соглашению сторон через месяц, аккурат с Нового Года, стать свободным человеком с тремя дополнительными окладами на карточке, разрешили до момента увольнения свободно ходить по собеседованиям в рабочее время.
Спустя почти три года могу сказать, что это увольнение в разгар кризиса под Новый Год — лучшее, что со мной случалось в карьерном плане в той компании даже с учётом попадания в техподдержку с нулем опыта и повышением до младшего сисадмина после 9.5 месяцев работы: на новом месте ушёл в специализацию по UC и сетям от энтерпрайзного шиваадминства, имею бОльшую инфраструктуру в зоне ответственности с задачами и должностью иного уровня, плюс значительно возросший доход. Но это совсем другая история.
А как бы Вы оценили плюсы и минусы реализации обозначенной в статье задачи на ELK относительно Splunk?
Одному_моему_другу приснилось доводилось делать очень похожее решение как раз на ELK: CDR'ы по SFTP с CUCM грузятся на сервер, разбираются в Logstash и складываются в индексы на Elasticsearch. На Kibana собраны дашборды под возникшие нужды. Большинство визуализаций создается в пару кликов. Дашборды можно генерировать динамически, есть возможность их вставки через iframe в сторонние ресурсы.
Плюс базовый ELK бесплатен без ограничений на объемы информации и количество нод в кластере (в противовес стоимости on-premise железа у Elastic, если мне не изменяет память, есть и SaaS-опции).
Wireshark действительно может извлечь звук из дампа, вот только тон мы там не услышим
Зависит от конкретного случая, оборудования и настроек. RFC2833 описывает возможность как оставлять оригинальный тон в аудио-потоке, наряду с генерацией NTE-пайлода, так и удалять его (в Cisco реализовано оба варианта: dtmf-relay rtp-nte [digit-strip]). Из RFC:
A source MAY send events and coded audio packets for the same time
instants, using events as the redundant encoding for the audio
stream, or it MAY block outgoing audio while event tones are active
and only send named events as both the primary and redundant
encodings.
Так что тон мог быть в записанном голосе (или даже только в нем как in-band DTMF, без relay вовсе), и подобная проблема сменой DTMF-relay механизма уже не решалась бы.
По крайней мере лично я до сих пор так и не научился отличать RTP-NTE и SIP INFO на слух.
В Wireshark они были бы видны как пакеты с полной структурой сообщения внутри.
Декодированный RTP-NTE, к примеру (нажата цифра 8):
Да, появление тонов так можно отследить. Но в отрыве от контекста разговора мы не сможем сказать, правомерно ли появился данный тон
Очевидно, анализ имеет смысл производить только на вызове с воспроизведенной проблемой и уточненными данными со стороны абонентов (в какое время тестового звонка возник тон, не нажимались ли клавиши и т.д.).
О них и так в доступе масса информации, чего не скажешь об экстракции звука из дампов PCM.
Ничуть не умаляю проделанной работы, за анализ и статью спасибо, было интересно почитать. :)
Вопрос только зачем было это делать в контексте возникшей проблемы?
В схеме [Абонент1]---[АТС]--E1--[Cisco GW]--SIP--(Провайдер)--(ТфОП)--[Абонент2] начинать сбор основной информации на участке АТС-Cisco, как мне показалось, немного нелогично. Дебаги и стандартные средства показали бы, что в тестовом вызове DTMF приходил на call-leg'е провайдера, и дальнейший источник проблемы, и ее фикс стоит искать в той стороне. К чему Вы, собственно, и пришли:
Удалось выявить, что шлюз, на котором включен RFC2833, передает странные (не вполне понятно, откуда они берутся — то ли генерируются самим шлюзом, то ли приходят из сети оператора, но точно не от удаленного абонента) пакеты, которые маршрутизатор (на котором, в свою очередь, тоже включен RFC2833) воспринимает как RTP NTE
Подход, конечно, интересный, но не логичнее было бы сначала использовать встроенный в ISR еще с IOS 12.X monitor capture на SIP call-leg'е?
На выходе получили бы pcap файс с дампом трафика, Wireshark отлично декодит RTP из него во всех основных кодеках.
Да и само появление DTMF-тонов можно было бы отследить через debug voice rtp session named-event и debug voice ccapi inout, не прибегая сразу к такому глубокому анализу.
переключение шлюза в режим SIP INFO (на маршрутизаторах Cisco ISR данный режим всегда включен)
Если на dial-peer статически задать dtmf-relay rtp-nte без дополнительных вариантов, то не так уж и всегда.
Проводя автомобильные аналогии, Вы заказали разработку абстрактной машины с четырьмя колесами, крышей и рулем, на выходе получили два сваренных друг с другом велосипеда с запряженной костылями лошадью и прикрученным синей изолентой пляжным зонтиком (или Лада Калину). После чего удивляетесь, что у нее нет адаптивных систем безопасности, круиз-контроля, разгона до 100 за 3 секунды и шильдика S63 AMG — 21й век на дворе ведь, это само собой разумеющиеся вещи.
Так что и производительность все же имеет смысл измерять и сравнивать под конкретные сценарии и ограничения.
Здесь по-моему нужно выделить несколько другие моменты:
1. Вызов на какой-то номер — это абстракция. Грубо говоря, это выглядит как «вызываемый номер Б -> маршрутизировать туда».
2. Реализация накладывается на физические (производительность оборудования, пропускная способность или емкость каналов связи и т.п.) и логические (количество линий по договору, возможности оборудования и ПО, логика маршрутизации и т.п.) ограничения операторских сетей и абонентских стыков.
«Туда» может быть как одной линией (физической или виртуальной), так и несколькими. А может быть и вовсе другим номером, если включена переадресация (безусловная или при занятости/переполнении).
К слову, абонентских стыков под один и тот же номер может быть энное количество по разным технологиям. Например, в сначала вызовы приходят в Е1, затем — в SIP-транк, а если первые два варианта недоступны — по старому медному многопарнику на FXO-порты. Как-то так обычно делается (гео)резервирование и отказоустойчивость.
Поток E1/T1 — это коммутация каналов, а не пакетов. И никаких механизмов гарантированной доставки там нет.
Во фрейме E1 30 тайм-слотов под голос, один под сигнализацию (16-й) и один под тактовую синхронизацию (0-й).
И опять: «обычную Ethernet-сеть» нужно читать как «выделенный канал». В противовес публичному Интернет-каналу. На уровне L2/L1 доступ может предоставляться как угодно, лишь бы была IP-связность поверх. На то он и VoIP.
Интернет по своей природе не имеет никаких гарантий передачи данных и параметров качества обслуживания. Любой публичный трафик идет как best effort. Сетевой нейтралитет и все дела (его отмена местами — отдельная тема для разговора).
Внезапно, отправить на этот же сотовый второй линией или поставить в ожидание. Как Вы заметили, это логическое ограничение.
Только стоит обозначить, что это именно ваша практика. Колл-центры федерального масштаба могут иметь в разы больший поток вызов и количество линий для них.
Есть в РФ такое Министерство Информационных Технологий и Связи, и все «не более чем договоренности» регулируются на уровне Приказов и Федеральных Законов, за нарушение которых провайдер может остаться слегка без лицензии. Географически определяемые номера законодательно привязаны к региону (отсюда и название), провайдер из Москвы не может дать номер в ABC-коде 495 абоненту из Владивостока. На DEF подобное ограничение не распространяется.
E.164 от ITU-T?
Увольняли по сокращению в нестабильном конце 2014 года. ИТ-Директор вызвал к себе, объяснил, что в Регионе принято решение подсократить российский ИТ-штат и перераспределить обязанности (это было подразделение международной промышленной компании, я там сисадминил), что претензий к моей работе нет, и могут, при необходимости, дать рекомендации. Предложили по соглашению сторон через месяц, аккурат с Нового Года, стать свободным человеком с тремя дополнительными окладами на карточке, разрешили до момента увольнения свободно ходить по собеседованиям в рабочее время.
Спустя почти три года могу сказать, что это увольнение в разгар кризиса под Новый Год — лучшее, что со мной случалось в карьерном плане в той компании даже с учётом попадания в техподдержку с нулем опыта и повышением до младшего сисадмина после 9.5 месяцев работы: на новом месте ушёл в специализацию по UC и сетям от энтерпрайзного шиваадминства, имею бОльшую инфраструктуру в зоне ответственности с задачами и должностью иного уровня, плюс значительно возросший доход. Но это совсем другая история.
Одному_моему_другу
приснилосьдоводилось делать очень похожее решение как раз на ELK: CDR'ы по SFTP с CUCM грузятся на сервер, разбираются в Logstash и складываются в индексы на Elasticsearch. На Kibana собраны дашборды под возникшие нужды. Большинство визуализаций создается в пару кликов. Дашборды можно генерировать динамически, есть возможность их вставки через iframe в сторонние ресурсы.Плюс базовый ELK бесплатен без ограничений на объемы информации и количество нод в кластере (в противовес стоимости on-premise железа у Elastic, если мне не изменяет память, есть и SaaS-опции).
Зависит от конкретного случая, оборудования и настроек. RFC2833 описывает возможность как оставлять оригинальный тон в аудио-потоке, наряду с генерацией NTE-пайлода, так и удалять его (в Cisco реализовано оба варианта: dtmf-relay rtp-nte [digit-strip]). Из RFC:
Так что тон мог быть в записанном голосе (или даже только в нем как in-band DTMF, без relay вовсе), и подобная проблема сменой DTMF-relay механизма уже не решалась бы.
В Wireshark они были бы видны как пакеты с полной структурой сообщения внутри.
Декодированный RTP-NTE, к примеру (нажата цифра 8):
Очевидно, анализ имеет смысл производить только на вызове с воспроизведенной проблемой и уточненными данными со стороны абонентов (в какое время тестового звонка возник тон, не нажимались ли клавиши и т.д.).
Ничуть не умаляю проделанной работы, за анализ и статью спасибо, было интересно почитать. :)
Вопрос только зачем было это делать в контексте возникшей проблемы?
В схеме [Абонент1]---[АТС]--E1--[Cisco GW]--SIP--(Провайдер)--(ТфОП)--[Абонент2] начинать сбор основной информации на участке АТС-Cisco, как мне показалось, немного нелогично. Дебаги и стандартные средства показали бы, что в тестовом вызове DTMF приходил на call-leg'е провайдера, и дальнейший источник проблемы, и ее фикс стоит искать в той стороне. К чему Вы, собственно, и пришли:
На выходе получили бы pcap файс с дампом трафика, Wireshark отлично декодит RTP из него во всех основных кодеках.
Да и само появление DTMF-тонов можно было бы отследить через debug voice rtp session named-event и debug voice ccapi inout, не прибегая сразу к такому глубокому анализу.
Если на dial-peer статически задать dtmf-relay rtp-nte без дополнительных вариантов, то не так уж и всегда.