Показаны сообщения с ярлыком rfc. Показать все сообщения
Показаны сообщения с ярлыком rfc. Показать все сообщения

Магия IETF: ASCII Art

В IETF множество разных штук зависит от магии. Без волшебной пыльцы или других дополнительных действий из мира фей, Интернет просто бы никогда не заработал. Тролли должны быть голодными. Единороги обеспечивают работоспособность алгоритма SDN PCE.

Очередной первоапрельский RFC 8140 от 2017 года прекрасен как первый снег и наполнен благородным безумием до краёв.

RFC от 1 апреля 2015 года

В 2015 году коллекция шутливых RFC обогатилась двумя новыми экземплярами:

RFC 7511 предлагает ввести в протокол IPv6 дополнительную опцию маршрутизации, которая позволит несчастным IP-пакетам получать как можно больше свежего воздуха, избегая передачи по меди или оптике в пользу беспроводных сред. Вероятно, от этого IP-пакеты станут более счастливыми и количество добра в мире увеличится.

RFC 7514 предлагает ввести в ICMP новое ообщение "Really Explicit Congestion Notification" (RECN), которое можно использовать в качестве совета уменьшить скорость передачи данных для таких устройств, которые не понимают нормального языка игнорируют потерю пакетов или сообщения Explicit Congestion Notification (ECN). Новый стандарт предлагает доводить такое сообщение аж до специалиста, ответственного за передачу пакетов на конкретном узле и даже выдавать аудио-сигнализацию или показывать pop-up сообщение, если подсистема text-to-speach отключена или звук выключен

SIP: RFC 7403 и SIP Traceroute

В ноябре 2014 года набор стандартов, описывающих телефонию в интернет, получил новое расширение: RFC 7403 описывает механизм поиска пути прохождения голосового потока от адресата к адресату. Предполагается, что узлы, через которые проходит голос, при получении запроса с нулевым значением в заголовке Max-Forwards должны принимать соединение и включать голосовую петлю (RFC 6849). Таким образом, инициатор вызова, пошагово увеличивая значение в этом заголовке, протестировать качество связи на всех промежуточных узлах, передающих медиапоток.

Все SIP RFC




Ниже обновляемый список RFC, описывающих протокол SIP и его все его дополнения. Последнее обновление выполнено  06.02.2015 г. Кроме этого списка, поиск документа по конкретной теме начать можно с RFC 5411 (на английском языке), там есть почти полный список с разбивкой на категории и темы по состоянию на 2009 год.
Список длинный, разбит по годам появления документов:

IANA: Закрома полезняшек

В очередной раз пополняя страницу про rfc по сипу, в потайном углу rfc-editor.org набрёл на коллекцию заботливо собранных редакторами MIB-файлов для различных систем. Сами редакторы пишут об этом так:
Эта папка содержит частные MIB-файлы, которые были собраны редакторами IANA и RFC в период между 1990 и 1996 годами. Мы не знаем, валидны они до сих пор или нет, поэтому условно считаем их историческими.

RFC Editor
4 сентября 2001

Новые RFC про SIP:

Не успел собрать в один список все RFC по сипу, как в мае 2014 появилось 3 новых документа: rfc7245, касающийся архитектуры для реализации записи разговоров в SIP, и интернетворкинг SIP и XMPP в раздельных документах,- архитектур, адресация и обработка ошибок (rfc7247) и, отдельно, статусы присутствия (rfc7248). Общий список обновил, естественно.

Все RFC про SIP в одном месте!

Одно время меня активно интересовал SIP и разные его инкарнации в виде МультиФона, всевозможных SIP-телефонов и программных клиентов. Потом в силу определённых обстоятельств окружающей действительности, интересы немного изменились, но пятно на карме осталось. Чтобы подытожить накопленный опыт и вообще попытаться спрыгнуть с собственной тени, -  привёл в порядок старый пост про список спецификаций SIP. Пост был небольшой и неказистый,- немного кривое форматирование, да и RFC не все. В самом начале казалось, что список документов должен быть не очень большим, ссылок 20 или 30... Но реальность, как обычно, оказалась намного интереснее,- как выяснилось, с 2001 по 2014 год,  рабочие группы IETF опубликовали почти 200 спецификаций, информационных документов, размышлений о будущем протокола и сборников сигнального обмена на все случаи жизни. В эмпирическую оценку вкралась небольшая десятикратная погрешость :-).  И это ещё я не включал RFC, в названии которых нет аббревиатуры SIP, например, в список не попали стандарты, касающиеся форматов SDP.  Но зато, в процессе изучения аннотаций и вводных глав вспомнилось многое из того, что уже казалось забытым, ну и, конечно, новые какие-то вещи тоже попались. Вообщем, получился полный список SIP RFC с краткими русскими названиями.

April1: HTCPCP-TEA и NSA Certificate Extension

Фрагмент логотипа сайта http://www.rfc-editor.org/
В этом году на 1 апреля RFC опубликовал два новых чудесных документа:

Первый из них RFC 7168, озаглавленный The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA), повествует о нелёгкой судьбе кофейников, предоставляющих сетевые функции приготовления кофе по протоколу HTCPCP, но не умеющих при этом варить чай. К слову сказать, протокол HTCPCP тоже зафиксирован в RFC 2324 ещё 1 апреля 1998 года. Так вот, HTCPCP-TEA определяет дополнительные коды возврата, например, HTTP 300 Multiple Options возвращается кофеваркой, если URL, по которому обратился клиент, может запускать процесс приготовления и того и другого напитка. Кроме того, этот документ стандартизирует новый тип MIME message/teapot на случай, когда клиент, обращающийся по сети к кофеварке хочет непременно чаю (а если ещё да с мягкими французскими булочками,- как быть тогда?)

Второй первоапрельский RFC 2014 года,- RFC 7169 The NSA (No Secrecy Afforded) Certificate Extension,- предлагает добавить в сертификаты новое расширение "Секретность не поддерживается" на тот случай когда владелец сертификата не уверен, сможет ли он сохранить свои приватные ключи действительно приватными, или даже если прямо хочет сообщить, что приватные ключи публично доступны. Вообщем,- секретность,- это сложно.

Сравнить нельзя обновить

Ну, допустим, хочется сделать скрипт проверки и обновления какого либо файла из интернет. Хороший такой скрипт, чтобы лишней нагрузки на сервер не создавал, и лишний трафик не гонял. То есть, необходимо проверять обновление какого-либо ресурса по URL, и, при необходимости, загружать новую версию, или как-то по иначе отреагировать, письмо, например, послать. Тут на помощь приходят заголовки HTTP Last-Modified (в ответе сервера) и If-Modified-Since или If-Unmodified-Since(в запросе). При ближайшем рассмотрении оказывается, что значения в этих полях не имеет смысла из строкового приводить к типу datetime в принципе

Страсти по CSV


В приступе очередного скриптописания столнулся с адскими проблемами при работе с CSV. Входные данные просты до безобразия: взять данные из Excel, заметьте,- простые данные, 4 столбца безо всяких извращений вроде переводов строки внутри значений или внутренних кавычек,- переложить это в CSV, прочесть скриптом на python, преобразовать по алгоритму. Компот и второе (т.е. прочесть и преобразовать),- оказалось меньшим из зол, а вот CSV...

FTL Communications

Очередной первоапрельский RFC: Соглашения для коммуникаций на скорости быстрее света (Design Considerations for Faster-Than-Light (FTL) Communication).

Автор упоминает некоторые аспекты взаимодействии пространства-времени при околосветовых скоростях и делает смелое предположение, что при скорости быстрее света время обращается вспять. Это может привести к таким неожиданным эффектам, что пакеты данных могут будут доставлены получателю раньше, чем они были посланы отправителем. Таким образом, существующий дизайн протокола TCP/IP не совсем подходит для передачи данных в среде FTL и требует доработки.

Помимо некоторых RFC, требующих переосмысления, автор рекомендует задуматься над соглашениями и ограничениями путешествий во времени, так как, по его мнению, FTL-коммуникации неминуемо приведут к возможности путешествий во времени:
That said, FTL communication might lead to FTL travel, where we can travel into the past. It may be necessary to start working on this yesterday.

Широковещательная передача через атмосферу

Очередной первоапрельский RFC 6217: Regional Broadcast Using an Atmospheric Link Layer :-)

Предлагают использовать в качестве среды передачи атмосферу. В IPv4/6 слишком много лишних заголовков (Destination, TTL (Time to Live), DSCP (Diffserv Code Point), ECN (Explicit Congestion Notification), Hop Limits и т.д.). От этого всего можно отказаться. Оставим только необходимое:

      +-------------------------------+-----------------------------+
      |            Content            |           Source            |
      +-------------------------------+-----------------------------+

                     Рисунок 1: Формат датаграммы

Content - Поле переменной длины, содержащее инкапсулированные данные протоколов верхнего уровня,
Source - источник данных
В качестве источника могут выступать:
  • IP - адрес
  • номер телефона в формате E.123
  • IPv6 адрес в стандартной нотации (RFC 5952)
  • URI (RFC 3986)
  • географический адрес
  • и так далее...
Типичным примером использования такого вида связи может быть трансляция рекламных сообщений, типа такого:
 Content                          Source
   +------------------------------------------------------------+
   | Lobster Dinner - only $14.99    500 Boardwalk, Pt Pleasant |
   +------------------------------------------------------------+

                 Figure 2: Example ADVERT Datagram

Жгут ребята :-)

Полный список параметров SIP

Обнаружил полезный документ,- полный список заголовков SIP и других параметров (Session Initiation Protocol (SIP) Parameters):
В документе описаны:

Registries included below:
- Заголовки (Header Fields)
- Протоколы причин (Reason Protocols)
- Опциональные теги (Option Tags)
- Коды уведомлений (Warning Codes (warn-codes))
- Методы и коды ответов (Methods and Response Codes)
- Значения приватных заголовков (SIP Privacy Header Values)
- Имена механизмов безопасности (Security Mechanism Names)
- Схемы сжатия (Compression Schemes)
- Параметры URI (SIP/SIPS URI Parameters)
- Параметры и значения полей заголовков (Header Field Parameters and Parameter Values)
- Назначения и форматы URI (URI purposes)
- Пространства имён приоритетов (Resource-Priority Namespaces)
- Значения приоритетов (Resource-Priority Priority-values)
- Параметры идентификационной информации (Identity-Info Parameters)
- Параметры алгоритма идентификационной информации (Identity-Info Algorithm Parameter Values)
- Параметры настройки User-Agent (SIP Forum User Agent Configuration Parameters)

Skype: SDK и аудиокодек SILK

 Оказывается Skype ещё в марте открыл спецификации своего аудио кодека SILK для некоммерческого использования. Краткая информация по кодеку доступна на странице для разработчиков, оттуда же доступны ссылки на весьма интересный драфт драфт RFC и описание формата RTP payload с отсылками к RFC 3550 и нескольким другим. Ощущение такое, что изначально всё базировалось на SIP.

И ещё срочно в номер: появился SkypeKit SDK, который позволяет любым программам и устройствам использовать сеть Skype для обмена сообщениями, контроля статуса, аудио и видео-связи без необходимости установки проприетарного клиента.

Мультифон: настройка входящих вызовов

Тем, кто пользуется альтернативными клиентами для Мультифона, узнать режим приёма входящих звонков или изменить входящую маршрутизацию можно с помощью обычного браузера (или HTTPs запроса, например с помощью wget)
Предположим, что ваш номер телефона — 79261234567, а пароль — aaaBBB

Серии рекомендаций ITU-T

Правильному IT-шнику надо учить матчасть. Помимо IETF, известной специалистам по множеству документов RFC существует Международный Институт Электросвязи (International Telecommunication Union). ITU является ведущим учреждением Организации Объединенных Наций в области информационно-коммуникационных технологий. Роль МСЭ, как всемирного координационного центра для органов государственного управления и частного сектора, состоит в том, чтобы помогать миру общаться, и осуществляется в виде деятельности трех основных секторов: радиосвязи, стандартизации и развития. Деятельность МСЭ по разработке стандартов (Сектор стандартизации электросвязи ITU-T) является самым известным и самым давним видом его деятельности.

Настроение TCP-пакетов

Для того, чтобы добавить немного антропоморфности потокам бит сетях всего мира, специалисты из Google R. Hay и W. Turkal предлагают использовать опции TCP для передачи настроения. Вольный перевод:

Сами по себе пакеты не могут чувствовать. Они созданы только для передачи данных от одного хоста к другому. Тем не менее, в некоторых ситуациях можно добавить им немного эмоциональности. Например, пакет, который пришлось отправить повторно (из-за того, что для него не было получено подтверждение ACK), может быть описан как "сердитый" или "разочарованный"


Предложение гугловцев зафиксировано в RFC 5841 1 апреля 2010 года, и содержит описание TCP Options для использования, возможные Use Cases, психологические характеристики различных пакетов (счастливые, удивлённые и смущённые пакеты, и даже апатичные, ага) и отсылки к используемой литературе и дополняемым RFC

TEL-URI в социальных сетях

Довелось попасть на мобильную версию вКонтакте: а что, неплохо! Не без глюков, конечно, и HTML-код можно было бы подчистить от лишних пробелов и переносов, но в целом терпимо. Но, что меня поразило: в мобильной версии телефонные номера оформлены в ссылки вида href="tel:xxxxxxxxx". Во-первых,- это стандарт RFC 3966 (перекрывающий устаревший RFC 2806), а, во-вторых, со смартфона по клику на такую ссылку сразу можно позвонить.

Отрадно видеть заинтересованность создателей портала в мобильных пользователях, и ещё более отрадно видеть готовность следовать стандартам. Впрочем, вКонтакт славится слизыванием функций Facebook, в его мобильной версии поддержка tel-uri тоже реализована, причём с каким-то расширенным параметром после номера.

Будущее стремительно наступает

IP.MATIKA и Multifon

Протестировал аппаратный sip-телефон IP.matika SIP-T26P на совместимость с Мультифоном:

Входящие звонки ок, - показывает информацию о вызывающем абоненте из поля From.

На исходящих через раз звонок не проходит, в tcpdump видно, что вставляется пустое поле P-Preferred-Identity, на которое мегафоновский sip-proxy и ругается. Звонки отправляются в формате SIP-URI, так что позвонить удаётся только существующему пользователю Мультифона.

Умеет принимать текстовые сообщения из Мультифона. Поддерживает до 3-х SIP-аккаунтов одновременно.

В описании и конфигурации есть несколько "вкусных" возможностей, в Мультифоне не поддерживающихся: BFL (занятость линий), поддержка LDAP адресной книги, поддержка простых серверных XML адресных справочников. Есть даже поддержка SNMP,- протестировать, правда, не успел.

Интересно было бы построить телефонию в небольшом офисе на таких машинках с привязкой к ActiveDirectory по LDAP.

Агенты и менеджеры SNMP

SNMP (Simple Network Management Protocol) разработан как стандартный язык для использования всеми компьютерами в сети. SNMP используется системами управления сетью (NMS - Network Management System) для управления и мониторинга сетевых усзлов и их оборудования. Для работы SNMP в сети необходимы, как минимум, два элемента: SNMP Manager и SNMP Agent: