-
Публикации
114 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем tma
-
-
У нас в Питере были такие правила преобразования для РТУ:
Мегафон: ^810(.*)$/\1;^8([3489].{9})/7\1;^(.{7})$/7812\1;^([3489].{9})$/7\1 МТС: ^(.{7})$/7812\1;^([3489].{9})$/7\1;^8(800.{7})$/7\1
-
On 6/1/2021 at 2:02 PM, dr Tr0jan said:
@tma, ещё раз, как вы технически в SIP будете отличать national от international?
По префиксу. internetional вам пришлют с 810, например. Как договоритесь с встречным оператором.
Не понятна проблема - почему-то мы ее никогда не испытывали, всегда договаривались о формате номера на этапе присоединения. -
Странная формулировка - почему "угроза"?
-
On 4/16/2021 at 11:46 PM, dr Tr0jan said:
@MrGaribaldi, расскажите, как в SIPе отличить номер телефона national 812XXXYYZZ (Санкт-Петербург) от international 812XXXYYZZ (Ниигата, Япония)?
Очень просто - договоренностью с оператором по формату номеров. В РФ местный трафик все крупные операторы всегда шлют в national.
-
21 hours ago, xmanpsk said:
Выходит, что любой хрен с горы, представившийся сотрудником МВД, может на ящик mail.ru получить ответ?
Лично мы автоматом никогда не отвечали, а с mail.ru приходил запрос на бланке. Меня всегда радовало, как подобные запросы идут с mail.ru, но шлют ведь до сих пор...
-
On 5/18/2021 at 6:19 PM, grifin.ru said:
Кроме того, мы же смотрим куда отправляем ответ.
Нам чаще всего писали с mail.ru, причем это были ФСБшники и МВДшники.
-
On 4/20/2021 at 10:34 AM, grifin.ru said:
Мы себе автоматизацию сделали. МВД просим направлять запросы не в бумаге, а через форму на сайте:
Т.е. теперь любой может представиться товарищем майором и запросить у вас любую информацию?
-
Опубликовано · Изменено пользователем tma · Жалоба на ответ
On 1/19/2021 at 10:28 AM, jffulcrum said:делаете нагрузочный тест на АТС. Протокол с фейлами кинуть в рожу обоим, добавить с ноги.
Только потом не нужно удивляться, если оператор заблокирует доступ. ;)
On 1/19/2021 at 9:34 AM, Vladimir_8 said:Общение с техподдержкой как провайдера телефонии так и оператора связи результата не дает.
Каждый из них перекладывает ответственность на другого.
Подскажите в какую сторону копать, чтобы улучшить процент дозвона?Никогда не пишите в ТП типа "у меня ничего не работает" - всегда присылайте примеры звонков, в идеале дамп звонка (tcpdump в помощь).
Для коллцентра брать услугу АТС не разумно, лучше SIP-транк, можно у того же провайдера или у любого другого. Смысла нагружать функционал АТС никакого нет.
А дозваимость зависит от тарифного плана, вашего номера (может его в черный список давно внесли) и т.п. - тут Вам АТС точно не поможет.
-
On 2/5/2021 at 11:23 PM, dr Tr0jan said:
здесь публикуют базы спамеров (в том числе с "неберитрубку").
Обновления 2 месяца назад - не похоже на актуальные данные
-
Вариантов несколько, например поставить переадресацию с GSM-номера на DID в своем регионе и разруливать на АТС или подключить GSM-номера по SIP у своего провайдера, опять же зарулить на АТС.
В качестве АТС можно поставить asterisk/freeswitch или взять облачное решение.
Выход всегда есть.
-
Вы ищите интерконнекты?
-
Кстати я снял со своей locoM5 функции DHCP-сервера перенеся на свой роутер (Frit!Box) и перезагрузки стали происходить только раз в сутки, причем почему-то с утра примерно в одно и тоже время (на глаз), хотя никаких таймеров (по крону) и watchdog'ов я не ставил.
-
Такая у убнт технология радиодоступа.
А кого бы посоветовали взамен ubnt? Я понимаю, что немного не в тему ветки и топика, но информация была бы полезна.
Можно просто ссылку на грамотные сравнения.
Заранее благодарен.
-
Я брал то, что посоветовали. А полноценная M5 стабильнее?
Со вчерашнего дня, тьфу-тьфу-тьфу, работает. Правда жара только началась...
Какое еще доступное по цене оборудование подходит для работы на 5ГГц?
И еще вопрос: в России как обстояит дело с этой частотой? К примеру если построить мост между домами?
-
Бесперебойник не подходит - я бываю здесь на 1-2 месяца, аккумулятор любого UPS'а просто сдохнет с такой "эксплуатацией", а каждый год покупать новый...
Буду думать, что еще может помочь. ;(
За сегодня дважды антена вырубалась. Оба раза после 10-15 минут запускалась без проблем. Сама рестартануть не могла - результат такой же как и выше.
После очередного отрубания замерил напряжение сети - ~222в, вполне себе нормально. Был ли скачок в этот момент сказать не могу.
-
В наших местах еще найти нужно. Или ждать до следующего года, везти с собой. ;)
В этом ли причина - вот в чем вопрос...
-
Опубликовано · Изменено пользователем tma · Жалоба на ответ
Единственное на что можно действительно грешить - на возможные перепады напряжения в сети 220в.
Я нахожусь в селе, днем возможны скачки за счет того, что рядом с селом построили солнечную электростанцию.
В прошлом году напряжение вообще так скакало и мощности совсем не хватало - у меня включается бойлер, а у соседа насос перестает в колодце работать!
В этом году конечно это исправили, но стабильность здесь всегда была ужасная.
Попробую поизмерять напряжение, но визуально много не насмотришься, а перепады на современных энергоэкономичных лампочках почти не видно.
Человек, который ко мне приходил, вполне может работать от другого трансформатора - наш явно еще с советских времен пашет, а нагрузка с тех пор мягко говоря увеличилась.
Буду думать на счет стабилизатора напряжения...
-
Опубликовано · Изменено пользователем tma · Жалоба на ответ
Жуть какая-то, короче говоря. Вчера сдохла M5 и не хотела стартовать. До вечера (несколько часов) периодически пытался ее включить - ноль эффекта.
Вечером пришел человек, залез на крышу, сняли - не стартует и не сбрасывается (эх, блин, опция-то 'reset button' оказывается отключается сброс в factory default!).
Унес человек ее к себе, а я переобжал кабель полностью и укоротил его метров до 20.
Звонит вдруг мне человек - стартанула! Во, блин. Приносим ко мне, ставим - работает!
Сегодня с утречка, как температура поднялась... СНОВА СДОХЛА! Это где-ж у меня 80 градусов-то?!!
PoE-адаптеры меняли - нулевой эффект. Даже сменил обжим с A на B и дважды переобжимал - это все никакого отношения явно не имеет.
Видимо проблема в том, что несмотря на 80 градусов по цельсию больше ~30 она не тянет.
После отключения, паузы в ~10 минут - вновь заработала. Пока...
При этом вяглядят ping'и вот так, когда сдыхает:
$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=63 time=14835 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=63 time=13836 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=63 time=12836 ms
64 bytes from 192.168.1.1: icmp_req=4 ttl=63 time=11836 ms
64 bytes from 192.168.1.1: icmp_req=5 ttl=63 time=10836 ms
64 bytes from 192.168.1.1: icmp_req=6 ttl=63 time=9836 ms
64 bytes from 192.168.1.1: icmp_req=11 ttl=63 time=7709 ms
64 bytes from 192.168.1.1: icmp_req=12 ttl=63 time=6709 ms
64 bytes from 192.168.1.1: icmp_req=21 ttl=63 time=9676 ms
64 bytes from 192.168.1.1: icmp_req=22 ttl=63 time=8669 ms
64 bytes from 192.168.1.1: icmp_req=23 ttl=63 time=7660 ms
64 bytes from 192.168.1.1: icmp_req=24 ttl=63 time=6652 ms
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
^C
--- 192.168.1.1 ping statistics ---
64 packets transmitted, 12 received, 81% packet loss, time 146426ms
rtt min/avg/max/mdev = 6652.917/10091.216/14835.205/2657.773 ms, pipe 6
Т.е. вначале M5 начинает ужасно тормозить и давать немерянную задержку, а затем, веростяно, срабатывает внутренний watchdog и она ребутается.
При этом загрузиться она нормально не может, выглядит это так:
$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
From 192.168.188.20 icmp_seq=23 Destination Host Unreachable
From 192.168.188.20 icmp_seq=24 Destination Host Unreachable
From 192.168.188.20 icmp_seq=26 Destination Host Unreachable
From 192.168.188.20 icmp_seq=27 Destination Host Unreachable
From 192.168.188.20 icmp_seq=29 Destination Host Unreachable
From 192.168.188.20 icmp_seq=30 Destination Host Unreachable
From 192.168.188.20 icmp_seq=32 Destination Host Unreachable
From 192.168.188.20 icmp_seq=33 Destination Host Unreachable
From 192.168.188.20 icmp_seq=35 Destination Host Unreachable
From 192.168.188.20 icmp_seq=36 Destination Host Unreachable
64 bytes from 192.168.1.1: icmp_req=43 ttl=63 time=9029 ms
64 bytes from 192.168.1.1: icmp_req=44 ttl=63 time=8021 ms
64 bytes from 192.168.1.1: icmp_req=45 ttl=63 time=6.86 ms
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
64 bytes from 192.168.1.1: icmp_req=66 ttl=63 time=7652 ms
64 bytes from 192.168.1.1: icmp_req=67 ttl=63 time=6652 ms
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
192.168.188.0/24 - это локальная сеть моего роутера Fritz!Box.
И так на всякий случай - вы не меняли параметр Ping Watchdog на локе?
Watchdog выключен, все опции у него - серые.
Настройки вообще дефолтные, почти.
Больше похоже на аппаратную проблему с самой платой. Может от жары в 30 градусов у нее крышу сносит... ;(
-
Сегодня зависла моя M5. Ребутнул по питанию - заработало.
На замыкание проверю, конечно, но большие сомнения.
-
Uptime: 04:21:55
Полет нормальный. Плохо то, что не понятно в чем проблема. ;(
-
Опубликовано · Изменено пользователем tma · Жалоба на ответ
Отключил reset в настройках - пока полет нормальный.
Всвязи с этим вопрос: что может влиять на сигнал о перезапуске?
БП, витуха или погода на Марсе?
И почему это случилось только сегодня, а до этого жило почти месяц без проблем?
-
Спасибо, попробую как она заработает. Пока что между ребутами проскакивает максимум 1 пинг...
Кстати, а как потом с выключенной опцией ребута ее ребутать удаленно? Правда кроме передергивания питания я по другому раза 2 только пробовал.
В дефолт мне ресетом с адаптера отправить ее не удается...
-
Не долго я радовался чудесному воскрешению M5 - поработав примерно минут 30 она вновь ушла в ребут. Пишу через EDGE.
Что теперь делать - не знаю.
Солнца нет, жара спала давно, дует ветерок и даже накрапывает дожь...
-
Всем привет,
Сегодня моя NanoStation LocoM5 ушла в вечный ребут.
После безуспешных попыток зайти на нее между стартами (после очередного старта проходило 3-5 успешных пингов) я ее выключил.
Так я пытался включить M5 периодически в течение нескольких часов - повторялось все одно и тоже.
После последнего включения и очередной перезагрузки я плюнул на все и только через минут 15 обнаружил, что M5 вдруг ожила как ни в чем не бывало.
Вопрос - что это могло быть?!!
Из особенностей:
1. Было достаточно жарко, порядка 28 градусов в тени, M5 прикручена к дымоходу (нерабочему) над металлической двухскатной крышей на высоте ~30 см.
2. Т.к. M5 установлена пока еще временно, кабель (6 категория) не проведен окончательно и лежит бухтой 50м.
PoE адаптер родный, с reset'ом.
Из возникших предположений:
1. Возможно скопился конденсат.
2. Попала вода в кабель, но дождя вчера и сегодня небыло. Антенна закрыта, кабель в месте выхода из корпуса для плотности обмотан скотчем (временное решение ;))
До этого несколько дней подряд были дожди и грозы. На время грозы M5 отключается (село, все-таки).
3. Жар идет от самой крыши, но рабочий температурный режим, насколько я помню, от -30 до +80 градусов! Ну не могло быть такой температуры на крыше.
На ней жарко, но даже человек по ней при желании может ходить. Ну вспотеет конечно... ;) Жаркие дни (по +30 в тени) уже были по несколько дней подряд.
Хотелось бы услышать предположения и рекомендации.
В частности рекомендации по длине кабеля, подключению и т.д.
Стоит ли на M5 надеть защитный чехол какой-нибудь? У витой пары планирую сделать петлю вверх, чтобы избежать возможного затекания воды.
Планирую сегодня сделать более постоянное решение, но мне все это нужно последнюю неделю - далее я уезжаю, на постоянку буду делать уже следующим летом...
P.S. Вводные: Температура от +30 до +40 в тени в данных местах не редкость.
Грозы тоже могут бушевать неплохие, т.к. село находится в низине окруженной горами - если сюда что попало, то бабахать будет конкретно.
Специалистов по грозозащите здесь нет (хотя рядом строили электростанцию на солнечных батареях, думаю найти можно), а я сам в этом - профан.
Номерная емкость от МСЭ
в Телефония: классическая, IP-телефония (VoIP), NGN сети
Опубликовано · Изменено пользователем tma · Жалоба на ответ
Как-то не до конца они ее вернули, скорее забросили. Ссылка на нумерацию как была, так и осталась: https://www.itu.int/dms_pub/itu-t/oth/02/02/T02020000F30001PDFE.pdf