[SUrov_IBM]

В 18.12.2021 в 14:41, get56k сказал:

после этого попробую по IP трафик до цифровых модемов передать, вот и поглядим. Если кто-то пробовал и идея "шляпа" сразу скажите плиз :)

Get56k, здравствуйте.

 

 

К сожалению, не "взлетит", а если и взлетит, то не больше чем на 9600, как у факса, но скорей всего не "взлетит" от слова совсем.

 

G.711 A-Law и G.711 U-Law в VoIP, совершенно не тождество PCM G.703 (E1). Человек-человека будет слышать абсолютно нормально, а вот модемы не услышат друг друга и скорей всего не смогут сконнектиться даже на установлении соединения.

[forth32]

В 18.12.2021 в 16:49, SUrov_IBM сказал:

G.711 A-Law и G.711 U-Law в VoIP, совершенно не тождество PCM G.703 (E1).

Насколько я понимаю, это вообще разные вещи. G703 определяет физический интерфейс передачи данных, а G711 - метод DAC/ADC преобразования с различным типом компандирования сигнала (A и U).

Тип преобразования можно задать и для FXS-порта циски (параметер compand-type)  и для VOIP-портов (G711A или G711U). Вот если попытаться включить кодек, отличный от G711, то в работу вступает DSP, и сигнал безнадежно портится.

 

В 18.12.2021 в 16:49, SUrov_IBM сказал:

не больше чем на 9600, как у факса, но скорей всего не "взлетит" от слова совсем.

На G711 у меня модемы спокойно вяжутся на 28800 через SPA2102, и мне непонятно то мешает им соединяться на V90. Разве только SPA2102 делает какую-то неотключаемую обработку сигнала, типа комфортного шума, дополнительной компрессии или типа того - это улучшает разборчивость голоса но мешает работать модемам.

 

[SUrov_IBM]

Forth32, здравствуйте.

 

В 19.12.2021 в 08:19, forth32 сказал:

На G711 у меня модемы спокойно вяжутся на 28800 через SPA2102

Вам очень повезло, если модемы подключенные к FXS портам "услышали" друг друга по сети VoIP, с использование G.711. Тем более на скорости 28800. ;)

 

В 19.12.2021 в 08:19, forth32 сказал:

мне непонятно то мешает им соединяться на V90

Два аналоговых модема, подключённых к FXS, не смогут "услышать" друг друга на V90. Даже если подключены к одной АТС или коммутатору, и вызов коммутируется в пределах одного устройства.

 

В 19.12.2021 в 08:19, forth32 сказал:

если попытаться включить кодек, отличный от G711, то в работу вступает DSP

При обработке вызова, DSP в CISCO работает практически всегда, за исключением TDM Switching (доступно только в некоторых моделях CISCO, 28xx например) при явном типе потоков E1 <=> E1, или явном коммутации VoIP G.711 <=> VoIP G.711 (без перекодирования).

 

Примеры вызовов, когда CISCO задействует DSP:

 

FXS/FXO (аналог) <= [CISCO DSP] => FXS/FXO (аналог)

FXS/FXO (аналог) <= [CISCO DSP] => VoIP (при любом типе VoIP кодека)

FXS/FXO (аналог) <= [CISCO DSP] => G.703 (при любом типе потока (Е1/T1/J1))

VoIP (при любом типе VoIP кодека) <= [CISCO DSP] => G.703 (при любом типе потока (Е1/T1/J1))

G.703 (тип потока Е1 (имеет значения)) <= [CISCO TDM Switching] => G.703 (тип потока Е1 (имеет значения))

G.703 (тип потока T1 (имеет значения)) <= [CISCO TDM Switching] => G.703 (тип потока T1 (имеет значения))

 

G.703 (тип потока Е1 (имеет значения)) <= [CISCO DSP] => G.703 (тип потока T1 (имеет значения))

[forth32]

В 19.12.2021 в 16:50, SUrov_IBM сказал:

Два аналоговых модема, подключённых к FXS, не смогут "услышать" друг друга на V90. Даже если подключены к одной АТС или коммутатору, и вызов коммутируется в пределах одного устройства.

Я вовсе не говорил про два аналоговых модема. Я подключаюсь через SPA2102 к цифровому модемному пулу на cisco3725 + NM-30DM. В данном случае схема выглядит так:

[CISCO3725] - E1 - [CISCO2821] - Ethernet - [SPA2102] - аналоговый модем.

В этой схеме мы имеем ровно одно цифроаналоговое преобразование - внутри SPA2102. Весь остальной путь до модемов сигнал идет в цифре. При этом если схему собрать так:

[CISCO3725] - E1 - [CISCO2821 - VIC3-4FXS] - аналоговый модем.

то все соединяется на V90 без проблем. Вот я и думаю, чем отличается FXS-порт циски от FXS-порта SPA2102.

[SUrov_IBM]

Forth32,

 

В 19.12.2021 в 17:27, forth32 сказал:

[CISCO3725] - E1 - [CISCO2821] - Ethernet - [SPA2102] - аналоговый модем

При переходе с плеча TDM на VoIP плечо – как бы это не выглядело странным, это не совсем то цифра-цифра преобразование, которое происходит при G.703 (E1)<=>[CISCO {TDM Switching / DSP}]<=>(FXS) и которое необходимо для V90. Это уже конвертирование - "послушали, услышали" с плеча TDM и "запаковали" в VoIP кодек, используя DSP для компрессии в RTP. Поэтому для V90, это выглядит, как ещё одно цифро-аналоговое преобразование по дороге.

 

Цифра-цифра преобразование для V90, относится к TDM и его коммутации канала на всём пути следования (не зависимо от сигнализации), что собственно Вы и демонстрируете на схеме:

В 19.12.2021 в 17:27, forth32 сказал:

[CISCO3725] - E1 - [CISCO2821 - VIC3-4FXS] - аналоговый модем.

то все соединяется на V90 без проблем

 

 

 

В 19.12.2021 в 17:27, forth32 сказал:

Вот я и думаю, чем отличается FXS-порт циски от FXS-порта SPA2102.

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

[SUrov_IBM]

Forth32,

 

В 19.12.2021 в 17:27, forth32 сказал:

[CISCO3725] - E1 - [CISCO2821 - VIC3-4FXS] - аналоговый модем

Встречный к Вам вопрос, в данной схеме на потоковом плече используется сигнализация ISDN? Если да, то в момент работы протокола V90, по B-channel передаётся "voice" или "data"? Сможете посмотреть?

[forth32]

В 19.12.2021 в 18:22, SUrov_IBM сказал:

схеме на потоковом плече используется сигнализация ISDN?

Конечно. ISDN-PRI. Иначе модемный пул NM-30DM работать не умеет.

В 19.12.2021 в 18:22, SUrov_IBM сказал:

по B-channel передаётся "voice" или "data"

Ну, вот:

c3725#sh isdn stat
Global ISDN Switchtype = primary-net5
ISDN Serial2/0:15 interface
        ******* Network side configuration ******* 
        dsl 0, interface ISDN Switchtype = primary-net5
    Layer 1 Status:
        ACTIVE
    Layer 2 Status:
        TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
    Layer 3 Status:
        1 Active Layer 3 Call(s)
        CCB:callid=12, sapi=0, ces=0, B-chan=15, calltype=VOICE
    Active dsl 0 CCBs = 1
    The Free Channel Mask:  0x8FFF3FFF
    Number of L2 Discards = 0, L2 Session ID = 4
    Total Allocated ISDN CCBs = 1

Передается voice, что вполне логично. Насколько я понял, data - это когда несколько таймслотов E1 объединяются для передачи данных по протоколу V35. Такой эксперимент я тоже хотел бы поставить, только пока еще не понял, как сконфигурировать pri-group для передачи данных.

[SUrov_IBM]

Forth32,

 

В 19.12.2021 в 23:15, forth32 сказал:

Насколько я понял, data - это когда несколько таймслотов E1 объединяются для передачи данных по протоколу V35. Такой эксперимент я тоже хотел бы поставить, только пока еще не понял, как сконфигурировать pri-group для передачи данных.

Наверное, Вы имеете в виду channel-group (в терминологии CISCO). Правда, это просто передача данных, используя нефреймированный (channel-group unframed) или фреймированный (channel-group timeslots) G.703 поток (или группу потоков) между маршрутизаторами.

 

К телефонной сигнализации (CAS, ISDN) и модемной коммутации, channel-group отношения не имеет. Да и к телефонии в целом, это мало относится, за исключением того, что бегает это "чудо" по G.703. При использовании channel-group, CISCO не обрабатывает телефонную сигнализацию, для неё выделяется либо полный G.703 (для этого должна стоять карточка G.703, а не E1/PRI), который пробрасывается по мультиплексорам TDM сети до маршрутизатора, либо для channel-group задаются timeslots (в этом случае может использоваться карточка E1/PRI), которые "выкусываются" из потока и так же передаются по мультиплексорам TDM сети до маршрутизатора. В этой схеме, на противоположной стороне может быть установлен условно "V.35 модем" (устройство доступа), который терминирует из потока полученный от CISCO channel-group, преобразовав в V.35, есть устройства доступа позволяющие преобразовать CISCO channel-group сразу в Ethernet.

 

Вся эта channel-group "тряхомудия" не интересна (по крайней мере для меня и в рамках классической модемной тематики) потому, что не важно целый это поток или 1 timeslots, всё это тупо статически, по цепочке прописывается на TDM мультиплексорах оператора между двух точек, без какой либо коммутации вызова по сигнализации. DATA в ISDN, это другая история, там используется коммутируемое соединение на основе вызова, то есть CISCO полноценно использует телефонную сигнализацию для коммутации вызова. ;)

 

Правда, эта тема отдельного, развёрнутого разговора. Постараюсь поделиться свои мямли в ближайшее время, возможно кому то будет интересно. ;)

[SUrov_IBM]

Forth32,

 

В 19.12.2021 в 23:15, forth32 сказал:

Такой эксперимент я тоже хотел бы поставить

Кстати, Вы можете легко поднять фреймированный (channel-group timeslots) между CISCO 3725 и CISCO2821, чтобы потрогать это "чудо". К сожалению, карточки VWIC2, могут работать либо в режиме телефонной сигнализации (CAS, ISDN), либо в channel-group. Поэтому придётся разобрать ISDN коммутацию. Совмещать телефонию и channel-group в одном потоке, могут только карточки VWIC3-MFT-G703 и соответственно другая линейка маршрутизаторов.

[forth32]

В 20.12.2021 в 05:18, SUrov_IBM сказал:

DATA в ISDN, это другая история, там используется коммутируемое соединение на основе вызова, то есть CISCO полноценно использует телефонную сигнализацию для коммутации вызова. ;)

И где такое может применяться? Для подключения цифровых ISDN-модемов к цифровому модемному пулу, чтобы по дороге не было ни одного A/D преобразования?

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

 

У меня вот тут валяется железка FG-PLEX, которая, судя по описанию, позволяет вытащить из E1-потока  4 телефонных канала, а из остальных таймслотов получить V.35. Но это будет тот самый channel-group, о котором вы писали выше. Со стороны cisco для работы с ней я закупил WVIC-2MFT-G703, но еще пока не разбирался как все это настроить.

[Mis]

forth32

 

Я проводил много опытов со всякими VOIP шлюзами и результаты были удручающие, так что 28800 это успех. На дефолтных ADDPAC'ах  еле 14400 устанавливается или чуть больше. Да и стабильность соединения никакая. По поводу успехов конкретно этих SPA шлюзов видел тут: https://www.youtube.com/watch?v=EGFIEF6siIE

Мне кажется проблема отчасти в IP сети с её задержками. Голосовому общению не повредит, а вот модемы такое терпеть не будут, т.к. не были рассчитаны на такие искажения линии.

Для обмена в режиме факса придумали протокол t.38 и кажется планировалось что-то подобное для модемов, но актуальность быстро ушла и о нем забыли.

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

З.Ы. Терзает только один вопрос: Вроде же были E1-IP шлюзы для передачи PRI потока по IP сетям. Интересно как такое взлетит для данной ситуации.

[SUrov_IBM]

В 21.12.2021 в 12:12, Mis сказал:

Вроде же были E1-IP шлюзы для передачи PRI потока по IP сетям. Интересно как такое взлетит для данной ситуации.

Mis, здравствуете.

 

Были такие устройства, технология называется TDMoE. Позволяет прогонять через себя как нефреймированный, так и  фреймированный G.703. А что там внутри, ISDN PRI, CAS, SS7 или DATA "фаршмак", не имеет значения. При передачи потока, TDMoE не занимается вопросами телефонной сигнализации и там "внутри" используется совершенно не VoIP. Если запакованный в IP по TDMoE поток будет соединять АТС и Digital модемный пул, то модемы ещё как взлетят. ;)

[SUrov_IBM]

В 21.12.2021 в 12:12, Mis сказал:

Интересно как такое взлетит для данной ситуации.

У CISCO была своя разработка TDMoE – CEM называлась, потом канула в вечность. По ней можно было G.703 поток из карточки VWIC2 торчащей в той же кошке завернуть в CEM NM-CEIP-4TE1, передать по IP, вывернуть на дорогой кошке через CEM NM-CEIP-4TE1 в сторону АТС например. Даже работало, хотя железки TDMoE RAD IPMUX в этом плане значительно лучше работали, по крайней мере мне так казалось. ;)

[SUrov_IBM]

В 21.12.2021 в 07:11, forth32 сказал:

У меня вот тут валяется железка FG-PLEX, которая, судя по описанию, позволяет вытащить из E1-потока  4 телефонных канала, а из остальных таймслотов получить V.35.

Forth32,

 

К сожалению, боюсь, что на FG-Plex-4E&M задуманная схема не заработает. Это проприетарная железка, позволяющая передавать V.35, аналоговые телефонные и каналы Тональной Частоты E&M по G.703 потоку от одного FG-Plex до другого FG-Plex. С CISCO, его можно только соединить кабелем по V.35, чтобы потом V.35 запаковать в G.703, передать по TDM сети и вывернуть его таким-же  FG-Plex в V.35 с другой стороны.

 

[CISCO]<=V.35=>[FG-Plex]<=G.703=>[FG-Plex]<=V.35=>[Хреновина, работающая по V.35]

 

 

 

Для Вашей предполагаемой схемы, подошло бы устройство доступа к каналам G.703 с синхронным портом «Зелакс ММ».

 

[CISCO {WVIC-2MFT-G703}]<=G.703=>[«Зелакс ММ»]

https://www.zelax.ru/assets/docs/mm-20x_mm-21x_502_cr_network.pdf

 

Изменено 22 декабря, 2021 пользователем SUrov_IBM

[YuryD]

В 22.12.2021 в 04:54, SUrov_IBM сказал:

Forth32,

 

К сожалению, боюсь, что на FG-Plex-4E&M задуманная схема не заработает. Это проприетарная железка, позволяющая передавать V.35, аналоговые телефонные и каналы Тональной Частоты E&M по G.703 потоку от одного FG-Plex до другого FG-Plex. С CISCO, его можно только соединить кабелем по V.35, чтобы потом V.35 запаковать в G.703, передать по TDM сети и вывернуть его таким-же  FG-Plex в V.35 с другой стороны.

 

[CISCO]<=V.35=>[FG-Plex]<=G.703=>[FG-Plex]<=V.35=>[Хреновина, работающая по V.35]

 

 

 

Для Вашей предполагаемой схемы, подошло бы устройство доступа к каналам G.703 с синхронным портом «Зелакс ММ».

 

[CISCO {WVIC-2MFT-G703}]<=G.703=>[«Зелакс ММ»]

https://www.zelax.ru/assets/docs/mm-20x_mm-21x_502_cr_network.pdf

 

 

 Чего-то  я забыл. g703 - голая физика синхрнонная, хоть мопеды этой физики, коть еще что. Поверх этой физики едут синхронные протоколы типа E1/T1,  далее их распетрушивают на субпотоки уже, делают из каждого таймслота потоки, приземляют в нужные точки, согласно сигнализации. Или железно, на древних муксах, или софтверно, на дсп.  V.35  -это древний  ахрененный физически разьем :)

 

 И да, в дополнение к физике, в станции это выглядит как или 2 коаксиала, или 2 медные пары, v.35 устарел в voip.

[ShumBor]

кстати через аудиокдесы по voip я v90 поднимал, но у них передача была в своем формате (по внешнему вид это был 711, rtp dynamic type 103, * его видел как h263_plus).

по схеме:

audiocodes mp124 <-sip-> * (1.4.22 с моими патчами для транзитного пропуска rtp dynamic type 103) <-sip-> audiocodes mediant 2000 <-G.703-> m200 <-G.703-> audiocodes mediant 2000 <-sip-> * (1.4.22 с моими патчами для транзитного пропуска rtp dynamic type 103) <-sip-> audiocodes mediant 1000 <-G.703-> lucent max 4000

вроде даже в районе 50000 цеплялись и работали.

[smirnov_dima98]

В 19.12.2021 в 08:19, forth32 сказал:

Насколько я понимаю, это вообще разные вещи. G703 определяет физический интерфейс передачи данных, а G711 - метод DAC/ADC преобразования с различным типом компандирования сигнала (A и U).

Тип преобразования можно задать и для FXS-порта циски (параметер compand-type)  и для VOIP-портов (G711A или G711U). Вот если попытаться включить кодек, отличный от G711, то в работу вступает DSP, и сигнал безнадежно портится.

 

На G711 у меня модемы спокойно вяжутся на 28800 через SPA2102, и мне непонятно то мешает им соединяться на V90. Разве только SPA2102 делает какую-то неотключаемую обработку сигнала, типа комфортного шума, дополнительной компрессии или типа того - это улучшает разборчивость голоса но мешает работать модемам.

 

А можно уточнить, 28800 соединение устанавливается через вашу локальную IPPBX или же есть подобный опыт соединения через sip провайдера с другим удаленным модемом, который подключен по "классической" аналоговой линии? Просто есть идея добавить к описываемой в данной теме схеме городские номера от sip провайдера. Даже если v90 не заведется, скорость в 28800 была бы очень неплоха. Пока же по sip больше 9600 мне удавалось добиться. Использую черный курьер, шлюз dlink 7111s c G711a, провайдер sipnet, звоню на диалап BBS в Мск. Вот и интересно, куда копать, чтоб выйти за 9600 предел? Компоненты для запуска "пула" пока в пути, с ними не пробовал.

[edo]

В 19.12.2021 в 18:11, SUrov_IBM сказал:

При переходе с плеча TDM на VoIP плечо – как бы это не выглядело странным, это не совсем то цифра-цифра преобразование, которое происходит при G.703 (E1)<=>[CISCO {TDM Switching / DSP}]<=>(FXS) и которое необходимо для V90. Это уже конвертирование - "послушали, услышали" с плеча TDM и "запаковали" в VoIP кодек, используя DSP для компрессии в RTP

разве? ЕМНИП в e1 бегает тот же 711a/u, так что можно обойтись без конвертации.

 

 

[SUrov_IBM]

Edo, здравствуйте.

 

В 05.02.2022 в 16:01, edo сказал:

разве? ЕМНИП в e1 бегает тот же 711a/u, так что можно обойтись без конвертации.

Да, Вы правы для аудиокомпандирования в TDM и в VoIP (G.711, голосовой кодек без сжатия) используется алгоритм 8-битной компрессии голоса PCM alaw и ulaw.

 

Только для голосового шлюза, по крайней мере, если мы говорим про CISCO, имеется чёткое разделение на коммутацию цифровых голосовых каналов TDM, наряду с ними аналоговых каналов и пакетную голосовую маршрутизацию (формирование, транскодирование (если требуется), получение) RTP. Для перехода между плечами цифровых голосовых каналов TDM, наряду с ними аналоговыми каналами и VoIP,  CISCO всегда применяет DSP.

 

Когда со стороны TDM плеча, поступает DS-0 с PCM alaw или ulaw, CISCO IOS будут создавать RTP заголовки пакетов, для пакетной передачи, а DSP будет заполнять полезную нагрузку данных RTP пакетов, чем прилетело из DS-0 и соответственно обратная схема перехода RTP в DS-0 также использует DSP. По сути, со стороны VoIP, DSP отвечают за создание/сжатие/распаковку RTP пакетов для различных голосовых кодеков. И если рассматривать проходящий через него процесс перехода из одной цифровой среды DS-0 в другую цифровую среду RTP, это кажется коммутацией, но это не так, поскольку полезная нагрузка RTP пакета "рисуется заново" из полученных от DS-0 alaw или ulaw.

 

Для CISCO ситуация, в которой избегается использования DSP - для TDM это вызов поступивший из одного DS-0 в другой DS-0, с одинаковым PCM, тогда канальный интервал коммутируется напрямую. Для VoIP - это вызов маршрутизирующийся в одном типе RTP кодека, без перехода на TDM DS-0 или аналоговые pots.

 

Если я ошибаюсь, пожалуйста поправьте меня.

[edo]

В 06.02.2022 в 01:34, SUrov_IBM сказал:

CISCO всегда применяет DSP.

надо же. ЕМНИП asterisk умеет без перекодирования гонять звук между pstn и voip. но там другая проблема — тайминги

[YuryD]

В 06.02.2022 в 09:00, edo сказал:

надо же. ЕМНИП asterisk умеет без перекодирования гонять звук между pstn и voip. но там другая проблема — тайминги

Обалдеть, софтовая атс прямо так и делает ? Без перекодирования , или таки прокси есть ?

[edo]

@YuryD честно говоря, не понял что за прокси вы имеете в виду.

[YuryD]

В 06.02.2022 в 16:34, edo сказал:

@YuryD честно говоря, не понял что за прокси вы имеете в виду.

 Ну поищите букварь, что голосовые тракты могут идти в кучке кодеков, от gsm через g711 До патентованных g729. Сигналлинг - одно, а rtp -другое...

[edo]

всё ещё не понимаю про что вы.

да, кодеков много, разумеется, если кодеки разные, то без перекодирования нам не обойтись. или если требуется внесение каких-то изменений в аудиопоток (эхоподавление, конференции).

 

речь шла про то, что если кодек в e1 и в sip, например, совпадает, и не включено эхоподавление, то asterisk должен обойтись без перекодирования.

[YuryD]

В 06.02.2022 в 17:12, edo сказал:

всё ещё не понимаю про что вы.

да, кодеков много, разумеется, если кодеки разные, то без перекодирования нам не обойтись. или если требуется внесение каких-то изменений в аудиопоток (эхоподавление, конференции).

 

речь шла про то, что если кодек в e1 и в sip, например, совпадает, и не включено эхоподавление, то asterisk должен обойтись без перекодирования.

Для начала, о регистрации клиента на сип-н323 он сдает свои возможности по приему-передаче. и Не должен совершать звонок, если нету совместимости. Посему астерикс хреново не только конвекртит сигналлинг, но и пытается переконвертить ртп. т.е перековырять кодек ртп gsm  в голосовой 711 например. На лету - это просто подмена ip в rtp коннекте на -

прокси при коннекте.