SUrov_IBM

Novossyol, здравствуйте. 😊 В мобильной связи у "кнопочных телефонов" отображение посылаемой оператором информации может происходить по USSD (Unstructured Supplementary Service Data), вне зависимости от USSD запроса со стороны абонента. Так же, при вызове возможно передать Caller ID Name (не толь Caller ID number, сопоставляемый с телефонной книгой). Правда насколько информация поместиться на дисплее телефона, тот ещё вопрос. 😉 Скорей всего для смартфонов, будет применяться этот же способ, а не какой-то "смартфонный", только на дисплее поместиться всё. 😉

Eternity, здравствуйте. В таком случая, я бы обратился в "Роскомнадзор" с формулировкой - проблемы доступа к социально значимым информационным ресурсам сети "Интернет".

Уважаемые знатоки, приветствую Вас. Столкнулся на днях, что при попытке внести номер ГАР в объект "route", поле "geoguid" недоступно для редактирования. Знакомый специалист так же подтвердил недоступность редактирования поля "geoguid" для его организации. Указал координаты префикса в соседнем объекте "geoinfo". При этом после проверки получил ответ ЦМУ ССОП, что представленные в РАНР сведения (п. 9.1 - п. 9.7.1 приказа) - представлены в полном объеме. Вот и думаю, может я невнимательно прочитал инструкцию или существует более новая версия инструкции где описано, что "geoguid" заменён на "geoinfo"? 🙄

Sirmax, здравствуйте. Спасибо большое за предложение, но от Вас я далеко, в Санкт-Петербурге. Да мне тоже для домашнего использования, поэтому также вряд ли смогу утилизировать что-то выше гигабита. 😉 После нового года навернулся медным тазом коммутатор TP-Link отслуживший больше десятка лет, временно заменил на Catalyst 3750. Вот и решил использовать hEX S дополнив SFP порт SFP-T модулем. Знаю, у hEX S порт SFP вынесен за коммутационную матрицу других портов, но меня это не смущает, домашняя схема не сильно нагружена. Привлекает возможность питания hEX S по PoE и малые габариты.

Sirmax, здравствуйте. В любом случае, спасибо Вам за тест! 😉 P.S. Не думаю, что среди присутствующих на форуме много кто пытался запихать SFP-T именно в hEX S. Всё же он такой, больше "детский маршрутизатор". В этом месяце скорей всего соберу схему SFP-T + hEX S. Расскажу, что получилось на практике.

Уважаемые знатоки, здравствуйте. Чтобы не создавать отдельной темы и услышать ваше мнение, поинтересуюсь в этой ветке. 😉 Хочется странного, как думаете - в hEX S взлетит SFP-T поддерживающий стандарт 10/100/1000BASE-T, подключаемый Ethernet link при этом будет 1000Base-T (only). Захотелось пересобрать схему, добавив в hEX S Ethernet Gigabit порт в виде SFP-T, а собрать в данную минуту тестовый стенд не представляется возможным. Вот и решил спросить у форума, возможно кто-то сталкивался? Заранее благодарен за ответ. 😊

Jffulcrum, здравствуйте. Большое спасибо за ответ! Благодаря Вам и форуму, буду спать спокойно. 😉

Уважаемые знатоки, приветствую Вас. Прошу прощения за глупый вопрос, по уму нужно сделать тестовый стенд и не приставая ни к кому самому проверить, но интересует Ваше мнение, на то он и форум - возможно, кто-то знает верный ответ. Вопрос: имеется VM с CHR 7.16.1, после установки лицензия "Free" (с ограничением интерфейсов в 1 МБ/Сек) обновлена до "Trial P-Unlimited" (сроком 60 дней). Собственно после истечения "deadline-at" и отсутствием связи с лицензирующим сервером, каким образом себя поведёт CHR, условно потеряет возможность обновления прошивки или вернётся к лицензия "Free" (с ограничением интерфейсов в 1 МБ/Сек)? Дело не в жлобстве с экономией на лицензии, просто VM с CHR находится в изолированной, без доступа в публичный Интернет схеме, как с следствие серверам лицензирования. В этом случае разницы между "Trial" или приобретённой лицензией по-моему особо нет, ведь для проверки лицензии периодически формируется запрос к серверам лицензирования? Было замечено, что CHR 6 версии при недоступности серверов лицензирования и истечении "deadline-at" не изменил состояние лицензии и не ограничил интерфейсы в 1 МБ/Сек, возможно в 7 версии что-то принципиально изменилось. Заранее благодарю за ответ, если кто-то столкнулся с подобным вопросом. В любом случае попробую сделать тестовый стенд, чтобы совершить "прыжок в будущее". 😉

Saab95, здравствуйте. Дело в том, что оригинатором (создателем письма) рассылки "Расчетных отчетов" является непосредственно платформа "1С Предприятие". Поэтому при взаимодействии с внешним рассыльным потребуется какой-то relay механизм. CRP / API в данном случае никто городить не будет, поэтому остаётся SMTP. В любом случае спасибо за советы. Рискну осуществить рассылку более привычными / понятными в настройке способами, например MTA relay на VPS. Благодарю всех, кто откликнулся! 🙂

MMM, здравствуйте. Благодарен за консультацию в каком направлении смотреть. >>Я предположил, что цель именно на своих серверах делать рассылки. Да, рассылка предполагается с MTA компании, для отправки отчётов сотрудникам компании (на публичные адреса электронной почты). >>А так то да. Извиняюсь за глупый вопрос, возможно Вы сможете порекомендовать компанию предоставляющую услугу рассылки, в моём случае ретрансляции почтовых сообщений с внутреннего MTA на публичные адреса? Jffulcrum, здравствуйте. Благодарю Вас за расширенный ответ!

Уважаемые знатоки, не обойтись без Вашего мнения. Потребовалось организовать рассылку "Расчетных отчетов" для сотрудников компании на публичные адреса электронной почты. В общем-то технических проблем нет. Возникли сомнения, что при рассылке приблизительно 2000 писем, отправляющий MTA может быть определён как "SPAM рассыльный", с последующий блокировкой в "Spamhaus" и т.п. Подскажите - помимо ключевых соответствий в DNS: "A" ="PTR" ="HELO/EHLO ", полюс наличие записей SPF, DMARC, DKIM. Какие неочевидные параметры возможно должен иметь отправляющий MTA, чтобы не опасться быть определён как "SPAM рассыльный"? P.S. Прошу сильно "не кидаться тапками", с рассылкой большого количества корреспонденции дела не имел, возможно мой вопрос в принципе глупый.

Den4ikArgv, здравствуйте. Для линейки кошек 2800 чаще всего использую c2800nm-adventerprisek9-mz.151-4.M1. Ссылка для скачивания - https://cloud.mail.ru/public/krXW/aQ5cpoi7S

Andrei, здравствуйте. Всё же предположу, что проблема кроется в UTP кабеле. Сталкивался с некачественными новыми кабелями (из магазина), которые не обеспечивали работу AP по PoE 802.3at на расстоянии более 50 метров, правда проблемы в виде перезагрузки наблюдались практически сразу. Так же сталкивался, что на оборудовании Infinet Wireless работающим по Passive PoE, некачественные кабели напитывали воду атмосферных осадков, что приводило к замыканию в районе RG45 jack cо стороны инжектора (вода стекала "вниз") и перезагрузке радио-модуля. Для теста, я бы переместил инжектор максимально близко к Ubiquiti, если радио-модуль перестанет перезагружаться, это даст возможность не теряя показаний посмотреть CRC счётчик на его порту.

Motto, здравствуйте. Из приведённой короткой отладки неудачного вызова "в глаза бросается" - 0x84A2 "No circuit/channel available". Т.е. по логике не хватает свободного "B канала" в потоке, либо ресурсов DSP самой CISCO (про ресурс DSP могу и ошибаться, возможно там другое сообщение), НО в приведённой отладке удачного вызова занимается всё тот же "Channel 31"... Хм, тем более Вы говорите, что видите на "АТС 2" попытку транзита неудачного вызова в сторону оператора? Попробую тыкнув пальцем в небо предположить, что "АТС 2" в отличии от исходящих вызовов собственных внутренних линий, принудительно не закрывает групповым номером (495) XXX-XX-XX транзитные вызовы направленные в оператора. Т.е. при исходящем вызове с "АТС 1" до оператора пролезает некорректный номер "А (?) /ISDN Type" (внутренней линии или переадресации с "АТС 1"), хотя судя по отладке в случае успешного и неуспешного вызовов "Calling num" одинаковые, оператор отбивает вызов не удовлетворившись полученным АОН или ISDN Type, а "АТС 2" получив отбой от оператора закрывает "B канал" в сторону CISCO, хотя это и ненормальное поведение без причины отбоя в сигнализации. Самое интересное в процессе неудачного вызова осталось за кадром - "ISDN Se0/0/1:15 Q931: call_disc: PI received in disconnect; Postpone sending RELEASE for callid 0x...?". :) P.S. В изложенной схеме не очевидно соединение "АТС 1" и CISCO, если это VoIP с сигнализацией SIP / H.323, можно попробовать снять трассировку удачного и неудачного вызовов сниффером Wireshark. Но сначала хотелось бы увидеть полный код отбоя "call_disc: PI received in disconnect; Postpone sending RELEASE for callid 0x" обрезанный при копировании текста отладки.

Fox_m, приветствую! Если Вы не используете сервисы требующие поддержки IPv6, можно полностью исключить работу протокола со стороны клиентской ОС. Понимаю, в меня "полетят тапки" за предложение подобной "кастрации". В своей локальной среде, я бы именно так поступил, чтобы не ловить грабли IPv6 DNS. ОС Windows 10 (и выше): В ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters Создать DWORD (32-bit) параметр DisabledComponents Шестнадцатеричное значение ff После перезагрузить ОС. P.S. DisabledComponents можно распространять через групповую политику Active Directory, если потребуется.