Opened 2 months ago
Last modified 2 months ago
#441 new задача
Инверсия СУВ в окончании FXO
Reported by: | san | Owned by: | alx |
---|---|---|---|
Priority: | высокий | Milestone: | 1 очередь |
Component: | any | Keywords: | |
Cc: |
Description
У наших пользователей довольно часто встречается стыковка нашего оборудования с TDM каналом FxO приходящим от аппаратуры производства RAD.
Ранее схема стыковки выглядела так: FXO(RAD) <-> E1 <-> FS-08
Особенность аппаратуры RAD в том, что активное состояние СУВ в ней передаётся не нолём, а единицей(толи это нельзя изменить в конфигурации, толи никто не умеет, но вот так оно есть).
В связи с этой особенностью для успешной стыковки нам потребовалось:
- В плате FS-08 добавить возможность инверсии СУВ
- При инверсии наблюдается один негативный эффект - при обрыве линии E1, в сторону FS-08 будет сформирован сигнал AIS, который интерпретируется как активный СУВ и все телефоны начинают ложно звонить. В связи с этим, Толя решил добавить условие при включенной настройке инверсии - если все 4 входящих СУВ = 1, это считается неактивным СУВ. Это решило проблему ложных звонков при обрыве линии (один из СУВ, со стороны RAD всегда передаётся нолём, а при AIS вместо него передаётся 1, кажется это "СУВ c").
Это всё была предыстория :) Теперь к теме тиета:
В связи с постепенным переходом сервисов пользователей в IP, у пользователей изменилась схема связи, теперь она выглядит так:
FXO(RAD) <-> E1 <-> VE-01(окончание FxO) <-> IPАТС
И теперь в окончание FXO платы VE-01(и VE-02) тоже требуется добавить возможность стыковки через TDM с аппаратурой RAD - инверсию СУВа с "защитой" от ложного вызова при сигнале AIS.
Change History (7)
comment:2 by , 2 months ago
с правой стороны вдруг превратился в FXO? Теперь получается, что на обоих концах канала - FXO, что вряд ли будет работать. . :) Так, непример, FXO с левой стороны передает номер из абонентской линии в канал. Но окончание FXO справа не принимает набор номера из канала, у него просто нет такой функции. А выходящий из канала СУВ оно интерпретирует как сигнал вызова...
Наверное. ты не правильно понял мою схему, нарисую чуть подробнее:
АТС(FxS) <-медная линия-> FxO(RAD) <-tdm-> E1 <-tdm-> VE-01(окончание FxO) <-ip-> IPАТС
Это примерно тоже самое, что и в АТС "АДС", только вместо FXO RAD у нас плата FO-08:
АТС(FxS) <-медная линия-> FO-08 <-tdm-> VE-01(окончание FxO) <-ip-> Freeswitch
comment:3 by , 2 months ago
А, да, ты прав, это я ошибся с направлением передачи номера. FXO (с левой стороны) передает номер не в канал, а в абонентскую линию, то есть все правильно нарисовано.
follow-up: 5 comment:4 by , 2 months ago
Более рациональным и логичным мне кажется несколько иное решение. Так как источник проблемы (инвертор СУВ) находится на уровне сигнального канала, то и решать эту проблему логично на уровне канала - средствами ПЛИС платы SW-01. То есть СУВ для нужных каналов инвертируются прямо в SW-01, при этом учитывается авария сверхцикла, в случае которой платам передается 1111 (или 1101). Это было бы универсальное решение в одном месте, не зависящее от канального окончания, то есть никакие другие платы дорабатывать не надо.
Предлагаю рассмотреть предложенный выше альтернативный вариант решения.
Такой вариант был предложен в #218, но у Толи не получилось это реализовать, и ,к сожалению, я не записал причину неудачи, придётся теперь заново получить эту информацию.
На текущий момент предлагаю реализовать промежуточное решение:
Сделать в окончании FXO платы VE, обычную инверсию СУВ, как это сделано в FXS и 1ИНД, думаю сделать это не сложно и "костылей" тут нет. А мне это позволит временно удовлетворить потребности пользователей в стыковке, хоть и пока с возможностью ложных прозвонов при обрыве, и даст время обдумать и реализовать окончательное решение.
comment:5 by , 2 months ago
Replying to san:
На текущий момент предлагаю реализовать промежуточное решение:
Сделать в окончании FXO платы VE, обычную инверсию СУВ, как это сделано в FXS и 1ИНД, думаю сделать это не сложно и "костылей" тут нет.
Без костылей здесь вряд ли получится обойтись (подозреваю, что во время передачи Caller-ID СУВ перейдет в дефолтное состояние, что удаленной стороной будет воспринято как ответ, поэтому придется "замораживать" СУВ на это время), но есть вероятность, что все нужные костыли уже имеются (были поставлены для режима T.38, в котором MSP не управляет СУВ'ами)...
comment:7 by , 2 months ago
Реализация инверсии оказалась проще, чем я предполагал. :)
Однако этот тикет поднимает более широкую проблему. Ни одно канальное окончание VE не проверяет СУВ на комбинацию 1111 (то есть на аваарийное состояние потока). В каких-то канальных окончаниях это и не требуется (например в 1IND), а в каких-то такая комбинация может оказаться деструктивной (например в R2 комбинация 11 означает clearback, в результате потеря СЦС на долю секунды может привести к отбою установленного соединения). Получается, что даже при отсутствии инверсии СУВ необходимо принимать какие-то меры по защите...
Replying to san:
...
??? Но ведь эти схемы не эквивалентны - каким образом порт FXS (который был в плате FS-08) с правой стороны вдруг превратился в FXO? Теперь получается, что на обоих концах канала - FXO, что вряд ли будет работать. :) Так, непример, FXO с левой стороны передает номер из абонентской линии в канал. Но окончание FXO справа не принимает набор номера из канала, у него просто нет такой функции. А выходящий из канала СУВ оно интерпретирует как сигнал вызова...
Предполагаю, что ты на самом деле имел в виду канальное окончание FXS, а не FXO. Эти два типа окончаний комплементарны - если на одном конце канала FXO, то на другом должно быть FXS (как это и было в первой схеме, где справа FS-08)...
Теперь о собственно предложении. Предложение понятно, но я не уверен, что такой вариант решения проблемы является оптимальным. Ведь завтра вместо канального окончания FXS платы VE-01 к такому каналу может потребоваться подключить какое-то другое канальное окончание платы VE-01 (например FXO или R2), или не VE-01 а какой-то еще другой платы (например FO-08) - и та же проблема возникнет вновь, и опять придется добавлять новую функцию в другую платы или другое канальное окончание... Получается, что для обеспечения полной совместимости с RAD нам надо дорабатывать софт и FS-08, и FO-08, и всех остальных плат, работающих с СУВ (даже тех, у которых функция инверсии уже есть, например MI-04, EM-04 так как там наверняка нет проверки на комбинацию СУВ 1111), и все канальные окончания VE-01/VE-02, использующие СУВ (ну или почти все - надо с каждым окончанием разбираться, что для него означает комбинация СУВ 00)...
Более рациональным и логичным мне кажется несколько иное решение. Так как источник проблемы (инвертор СУВ) находится на уровне сигнального канала, то и решать эту проблему логично на уровне канала - средствами ПЛИС платы SW-01. То есть СУВ для нужных каналов инвертируются прямо в SW-01, при этом учитывается авария сверхцикла, в случае которой платам передается 1111 (или 1101). Это было бы универсальное решение в одном месте, не зависящее от канального окончания, то есть никакие другие платы дорабатывать не надо.
Предлагаю рассмотреть предложенный выше альтернативный вариант решения.