Jump to content
Калькуляторы

All Activity

This stream auto-updates     

  1. Yesterday
  2. Заключайте договор между провайдером и вами просто на интернет и аренду нужного количества IP адресов.
  3. Дело в том, что это L2 технология и любые потери на одном канале скажутся на работе общего, объединенного канала. С тем же успехом можно просто взять 2 линка и на L3 их объединять, хоть той же маршрутизацией. Получится результат тот же, но без использования устаревших технологий.
  4. Только вот такая отбраковка работает уже лет 10 без проблем (первые партии камер закупались в 2014 году), при этом имеют в своем составе отдельно модуль питания, отдельно модуль камеры, отдельно моторизованный объектив. Подключение по PoE через блоки питания UBNT на 48 вольт. Никаких коммутаторов с PoE, никаких дешевых блоков питания. Для распознавания автомобильных номеров на скорости только он и подходит, т.к. может получиться так, что автомобиль (его номер), пройдет по экрану между опорными кадрами и смажется. Хотя на самой раскадровке с камеры все кадры будут нормальные. Компрессии никакой дополнительной не будет, поток максимально возможный для камеры - 10М. И сколько надо для обработки? Почему же тогда на максимальном разрешении обычно 20 кадров, а на ступень ниже уже 25? Сами включите WDR разных реализаций на камере и посмотрите, сколько кадров в секунду камера выдает. Только посмотреть это можно на специализированном ПО, которое кадры анализирует, на регистраторе и самой камере этого нет. И увидите, что без WDR будет четко 20 кадров с равными промежутками между ними, а с WDR количество кадров и задержка между ними сразу плывет, как джиттер в интернете. Автовыдержка не нужна, нужно устанавливать диапазон выдержек, тогда днем будет четкая картинка, в сумерках камера раньше перейдет в ч/б режим, ночью будет показывать темную, но четкую картинку, осветлить которую можно дополнительным внешним освещением, которое должно идти не со стороны камеры, что бы не пересвечивать ближний план. Какой же тогда уровень не средний и не подделка? По 50 тыс. у перекупов с еще более дешевой и китайской начинкой?
  5. Обычно, за то, что-бы кто-то взял на себя чужую контору с 20 летним стажем "доплачивают", а вы хотите что-бы заплатили Вам? Ну что-же будет интересно посмотреть.
  6. Вы не получите того что хотите, потому что ваш вопрос: мужики, у кого машина сколько жрёт на 100км при перевозе картохи с огорода? Любые цифры будут не репрезентативны, потому что у одного буханка на газу, бездорожье и 2 тонны, в другого ламба на бензине, 2 кило, манякеньщица на месте навигатора и автострада. Опять же, даже если вам что то скажут, это будет из серии 2 сервера держут 1м, 3 сервера держат 5м абонентов. Железо разное, загрузка разная, настройки разные. Обычно никто не мониторит загрузку дхцп сервера, и вообще не в курсе даже какой у него предел по RPS. Что тут сравнивать? https://www.youtube.com/watch?v=tFYSOxMB33k https://kb.isc.org/docs/kea-performance-optimization https://kb.isc.org/docs/kea-performance-tests-140-vs-150
  7. Обычно так бывает, когда соединение по неизвестной причине рубит ТСПУ по пути до ресурса.
  8. Аналогичная проблема. В данный момент проблема с ru.ots.io.mi.com. В моем случаи строится TCP, но не приходит ответ на TLS Client Hello. На разных адресах одной сети поведение разное.
  9. Коллеги, вроде удалось верифицировать входящий вызов. Вот пример рабочего SIP INVITE на "incomingCallsPort" From: <sip:11056*79261111111@1.1.1.1;user=phone>;tag=o1500p0D1925D0t15r172919 To: <sip:74959999999@1.1.1.1;user=phone> В базе данных появилась вот такая строчка NUM_A |NUM_B |NUM_D|NUM_C|DATE |DATE_ACT |ID_SRC|ID_DST|SESSION_ID |ID_REL|VRF_RSP|RELEASE_CODE|DURATION|ID_UVR_T|CALL_ID |CALL_TYPE| --------------+--------------+-----+-----+-----------------------------+-------------------+------+------+-------------------+------+-------+------------+--------+--------+------------------+---------+ 79261111111 |74959999999 | | |2024-05-20 16:31:25.207184359|2024-05-20 16:31:25| 11056| |1158155729710874626| 1| 0| | | 11|1716-222685-172718| 2| Совокупность ID_REL = 1 и VRF_RSP = 0 говорит о том что верификация удалась.
  10. to lext55: Нужно верифицировать вызовы внутри станции, если 74957777777 принадлежит оператору X, а 74957777778 оператору Y. (Не редкий случай, когда на одной станции несколько операторов) Если номера принадлежат одному оператору, то не нужно.
  11. Здравствуйте. Продается оператор связи, лицензии выданы на Москву и Московскую область. Лицензии: - Телематические услуги связи; - Услуги связи по предоставлению каналов связи; - Услуги связи по передаче данных, за исключением услуг связи по передаче данных для целей передачи голосовой информации; - Услуги местной телефонной связи, за исключением услуг местной телефонной связи с использованием таксофонов и средств коллективного доступа . Лицензии действуют до мая 2028 года. Фирма пустая, имущество отсутствует. (оборудование, сети и клиенты проданы), из основных средств только кассовый аппарат. Бухгалтерия белая. Все необходимые отчеты сдаются. Фирма работала 20 лет. Имеется зарегистрированный товарный знак. Единственный учредитель. Все договорные отношения, кроме аренды офиса, завершены. Вид юридического лица - общество с ограниченной ответственностью. Идея цены: 2100000 руб. Посредники в сделке отсутствуют. Связь: телеграм +79011836327.
  12. Добрый день коллеги! На джунике поднят ip адрес в CE влане 308. В ae2 приходит влан 2001 set interfaces ae2 unit 2001 vlan-tags outer 0x8100.2001 set interfaces ae2 unit 2001 vlan-tags inner 0x8100.308 set interfaces ae2 unit 2001 family inet address X.XX.X/31 А на NE40 как реализовать такую же фичу. Конфиг ниже это наверно запаковка клиентского влана во внешний при входе в роутер и не то что надо interface GigabitEthernet1/0/0.100 control-vid 200 qinq-termination qinq termination pe-vid 200 ce-vid 100 ip address 10.10.10.10 255.255.255.0 Или я ошибаюсь ?
  13. Коллеги, раз уже на то пошло, вопрос , а нужно ли верифицировать вызовы внутри станции ? Например абонент А 74957777777 звонит абоненту Б 74957777778 , вызов за пределы станции не выходит, тут подмена в принципе не возможна.
  14. to lsergei Методом тыка и вот этой инструкции 1137847334745.63.11.1.2023.1.001 (ОПИСАНИЕ ПРОТОКОЛОВ ВЗАИМОДЕЙСТВИЯ ЦЕНТРАЛЬНЫЙ УЗЕЛ - УЗЕЛ ВЕРИФИКАЦИИ) я это освоил. Запутался в формировании правильного SIP INVITE - согласен. По причине просто отсутсвивия нормального примера. Например вот друг пример входящего SIP INVITE, вот друг пример исходящего SIP INVITE. Спасибо за добрые слова. А то РКН уже звонили , сказали что будут протокол составлять в конце мая, начале июня о неподключении.
  15. to: lext55 При исходящих вызовах не нужен сепаратор в поле From, так как не нужно туда добавлять префикс. Вижу, что вы запутались в двух разных процессах) Но, как грица, кто строит УВР, тот обязательно его построит.
  16. to lsergei Большое спасибо, работает. Пример рабочего SIP INVITE: From: <sip:74959999999@1.1.1.1;user=phone>;tag=o1162p0D2263D0t16r860795 To: <sip:11084*79261111111@1.1.1.1;user=phone> Кстате, задать сепаратор в поле FROM не получается. Т.е. вот такой SIP INVITE почему-то не проходит: From: <sip:22222*74959999999@1.1.1.1;user=phone>;tag=o1162p0D2263D0t16r860795 To: <sip:11084*79261111111@1.1.1.1;user=phone> Опять же речь про исходящие вызовы , которые отправляются на "outgoingCallsPort" В базе clickhouse данных появилась вот такая строчка: NUM_A |NUM_B |NUM_D|NUM_C|DATE |DATE_ACT |ID_SRC|ID_DST|SESSION_ID|ID_REL|VRF_RSP|RELEASE_CODE|DURATION|ID_UVR_T|CALL_ID |CALL_TYPE| --------------+--------------+-----+-----+-----------------------------+-------------------+------+------+----------+------+-------+------------+--------+--------+------------------+---------+ 74959999999 |79261111111 | | |2024-05-20 14:35:40.986966952|2024-05-20 14:35:40| | 11084| 0| 1| -1| | | |1716-215740-860609| 1| VFR_RSP все равно равно -1 , это значит что верификация исходящего не производилась. Разбираюсь дальше.
  17. to lext55: Сепаратор - это разделитель. Например # или *. Вам нужно отправлять From: id#a_number Например, с билайна получили вызов и отправляете From: 11084#79001234567@blah-blah
  18. to lsergei В том то и дело, что есть . Это первое что я заполнил. Тут указан НАШ ID_SRC "idSrcSeparator" : "22222" Хотя в документации как-то расплывчато написано. Если он используется для исходящих из моей сети то тогда вариант заполнения только один - мой наш ID_SRC . Если он используется для входящих на мою сеть, то тогда вопрос. У нас сразу 3 входящих оператора(на местном уровне) : Beeline , МГТС, WestCall. Конструкция ниже будет явно неправильной. "idSrcSeparatorBeeline" : "11084", "idSrcSeparatorMGTS" : "11056", "idSrcSeparatorWestCall" : "11397" Соответсвтенно вышепридуманный вариант явно не рабочий. Остается только заполнить это поле нашим ID_SRC.
  19. to lext55: To: <sip:1108479261111111@2.2.2.2;user=phone> Сепаратор (из конфига) должен быть, а его нет.
  20. Вот сейчас опять попробовал отправить 2 вызова по разному , в одном случае указывал ID_SRC , в другом ID_DST . Вот INVITE-ы Вот первый вызов From: <sip:2222274959999999@1.1.1.1;user=phone>;tag=o1495p0D1930D0t16r244911 To: <sip:79261111111@2.2.2.2;user=phone> Вот второй вызов From: <sip:4959999999@1.1.1.1;user=phone>;tag=o1495p0D1930D0t16r244911 To: <sip:1108479261111111@2.2.2.2;user=phone> Вот кусок лога из journalctl -u uvr May 20 15:48:44 uvr-sip uvr.sh[251245]: [2024-05-20 15:48:44.587][TID=0x7f38727fc6c0][warn ] <TRecQ763NumberValidator> Octet string with number='2222274959999999...' is too long. Expected size=8 bytes, a> May 20 15:48:44 uvr-sip uvr.sh[251245]: [2024-05-20 15:48:44.587][TID=0x7f38727fc6c0][warn ] <TRecQ763NumberValidator> Too long number will be trimmed 10->9 bytes. (/usr/local/src/uvr-sip/v3.3/release_uv> May 20 15:48:44 uvr-sip uvr.sh[251245]: [2024-05-20 15:48:44.587][TID=0x7f38727fc6c0][warn ] <APIGW:0> Calling number (A) is not valid reason=TooLongNumber NUM_A: '2222274959999999', CALL_ID: '1716-209324-> May 20 15:49:46 uvr-sip uvr.sh[251245]: [2024-05-20 15:49:46.404][TID=0x7f38737fe6c0][warn ] <TRecQ763NumberValidator> Octet string with number='1108479261111111...' is too long. Expected size=8 bytes, a> May 20 15:49:46 uvr-sip uvr.sh[251245]: [2024-05-20 15:49:46.404][TID=0x7f38737fe6c0][warn ] <TRecQ763NumberValidator> Too long number will be trimmed 10->9 bytes. (/usr/local/src/uvr-sip/v3.3/release_uv> May 20 15:49:46 uvr-sip uvr.sh[251245]: [2024-05-20 15:49:46.404][TID=0x7f38737fe6c0][warn ] <APIGW:0> Called number (B) is not valid reason=TooLongNumber NUM_B: '1108479261111111', CALL_ID: '1716-209386-3> Ругается на то что номер слишком длинный. Вообще непонятно как передать префикс. О ГРЧЦ взываю дайте пример SIP INVITE . Печаль....
  21. to lext55: Верификация - это когда вы получаете входящий вызов на свою сеть и запрашиваете верификацию у инициатора. Регистрация - это когда вы совершаете вызов на ССОП из своей сети и регистрируете вызов в своей БД. Это процессы управляются в sip-uvr разными серверами (сокетами). При исходящем вызове нужно заполнять ID_DST, а не SRC. Так как SRC в этом случае - это вы:)
  22. Нет. Имитация не значит функционирование. А движения по тому варианту, который озвучивал я как рабочий уже идут. Просто достаточно изучить письма от РКН - интервал уже 1500мс, и основной акцент на обработку событий. Осталось дождаться когда всё отдадут и на техническую на реализацию ГРЧЦ. В общем-то итог я думаю будет как с ТСПУ, но еще годик надо подождать.
  23. to lsergei Верификация исходящего вызова. Если честно ваш вопрос "регистрация", у меня вызвал вопрос. Что Вы подразумеваете под словом "регистрация" ? Его заполнить элементарно, т.к. он постоянный для нас по справочнику ГРЧЦ . Просто для теста. Там поле не обязательно к заполнению, но заполнить его лечке всего.
  24. Есть новости по airFiber 60 Xtreme-Range?
  25. Продам Ericsson Se100. 45 т.р.связь в личку. Отправка в любой регион.
  1. Load more activity