Сип минимальное сечение: СИП провода: особенности, виды, монтаж изделий

Содержание

Ошибки при строительстве воздушных линий электропередачи напряжением до 1 кВ с использованием СИП

В распределительных сетях напряжением до 1 кВ, а также сетях наружного освещения городов и посёлков всё масштабнее применяются самонесущие изолированные провода. Но, несмотря на это, качество проектных и строительно-монтажных работ остаётся на низком уровне. Чтобы разобраться в причинах возникающих ошибок, порой невидимых на поверхности, необходимо понять, с какими сложностями и на каких этапах сталкиваются сегодня технические специалисты при строительстве воздушных линий электропередачи с использованием СИП (ВЛИ).

В 2009 году нами был проведён опрос специалистов МРСК, проектных и монтажных компаний, а также основных игроков на рынке арматуры для СИП. Целью опроса стал анализ нужд, с которыми сталкиваются технические специалисты при проектировании и строительстве ВЛИ.

Несмотря на масштабное использование СИП в Росси более 8 лет, 77% респондентов отметили наличие таких проблем, как: низкий уровень инвестиций, недостаточное качество проектных решений, сжатые сроки строительства, ошибки отдела закупок при приобретении линейной арматуры и проводов, отсутствие квалифицированного персонала и полного комплекта инструмента для монтажа СИП. При этом большую долю (46%) составляют проблемы в области проектирования и монтажных работ. Эта цифра подтверждается систематическими осмотрами и изучением вновь построенных линий. Только 23% респондентов отметили отсутствие трудностей при строительстве ВЛИ.

При реализации любого проекта, в том числе строительстве ВЛИ, необходимо пройти ряд этапов — от стадии подготовки технического задания на проектирование до реализации проекта. Мы предлагаем рассмотреть 4 основных этапа и характерные ошибки, совершающиеся в них, которые сводят «на нет» инвестиционные затраты на строительство воздушных линий электропередачи с использованием СИП:

Подготовка заказчиком технического задания на проектирование.

Разработка специализированной (проектной) организацией рабочих чертежей и прилагаемых документов.

Приобретение службой закупок оборудования, изделий и материалов.

Реализация проекта.

1. Подготовка заказчиком технического задания на проектирование.

Изучение ряда проектов марок ЭС (электроснабжение) и ЭН (наружное электроосвещение), в которых применялись технические решения с использованием СИП, а также опрос специалистов проектных институтов выявили, что в технических заданиях на проектирование заказчиком, как правило, не указывается основное требование к СИП — соответствие конкретному техническому условию (ТУ) или ГОСТ Р 52373-2005. Чаще всего прописывается только марка провода, например, СИП-2 или СИП-4. К чему может привести отсутствие требования к СИП в части ТУ или ГОСТ Р 52373-2005 мы рассмотрим ниже. Вначале разберём, какой марке провода — СИП-2 или СИП-4 — и при каких условиях отдать предпочтение при формировании задания на проектирование.

Вопрос о плюсах и минусах различных конструктивных исполнений СИП неоднократно обсуждался в электротехнической литературе (см. «Новости электротехники» 2(14) 2002, №3(39) 2006). Для формирования собственного мнения в 2011 году мы провели независимое исследование технико-экономических характеристик воздушной линии электропередачи с использованием проводов СИП-2 и СИП-4 разных сечений. На рисунке 1 представлена модель анкерованного участка ВЛИ, на основе которой проводилась работа.

Рисунок 1. Модель анкерованного участка ВЛИ с использованием провода СИП.

Модель ВЛИ соответствует следующим характеристикам:

Длина расчётного анкерованного участка ВЛИ составляет 0,3 км.

Минимальное сечение провода магистрали ВЛИ выбрано по условию механической прочности согласно ПУЭ-7 п. 2.4.14 для нормативной стенки гололёда bэ ≥ 15 мм.

Провод СИП-2 производства ОАО «СЕВКАБЕЛЬ-ХОЛДИНГ» согласно ТУ 16-705.500-2006, (Россия).

Провод СИП-4 производства ОАО «СЕВКАБЕЛЬ-ХОЛДИНГ» согласно ТУ 3553-015 05755714-2002, (Россия).

Линейная арматура производства «ENSTO» (Финляндия).

Экономический расчёт проводился без учёта стоимости стоек и строительно-монтажных работ (СМР), так как при равных сечениях проводов СИП-2 и СИП-4 используются стойки одной марки, а стоимость СМР ВЛИ практически одинакова. На рисунках 2 и 3 представлен ряд результатов проведённого исследования.

Рисунок 2.

Рисунок 3.

На основании анализа представленных графических зависимостей можно сделать следующий вывод:

Механическая прочность провода СИП-4 выше прочности провода СИП-2 практически при всех сечениях жил, а при сечениях 95-120 мм2 превышает в 2 раза.

Стоимость провода СИП-4 ниже провода СИП-2 до 22% при сечениях 25-95 мм2. При сечении 120 мм2 стоимость проводов практически одинакова.

Стоимость арматуры для провода СИП-4 выше, чем для провода СИП-2 при всех сечениях в следующем диапазоне: на 5% при сечениях 25-35 мм2, на 21% при сечении 50 мм2 и на 30% при сечениях 70-120 мм2.

Суммарная стоимость провода и арматуры ВЛИ с использованием провода СИП-4 ниже, чем с использованием провода СИП-2 до 14% при сечениях 25-95 мм2, и только при сечении 120 мм2 вектор экономического преимущества смещается в сторону ВЛИ с использованием провода СИП-2 до 3%.

Согласно требованию п. 2.4.14 ПУЭ-7, учитывающего минимально допустимые сечения СИП по механической прочности, строительство ВЛИ с сечением фазных жил до 25 мм2, а это, как правило, сети наружного электроосвещения или ответвления от ВЛИ к вводу, экономически целесообразно только с использованием провода марки СИП-4 на большей части территории России.

Несмотря на представленные выше выводы, использование провода СИП-4 на магистралях ВЛИ встречается довольно редко. Основными сдерживающими факторами ограниченного использования провода СИП-4 сечением 35-120 мм2 в России являются ГОСТ Р 52373-2005 «Провода самонесущие изолированные и защищённые для воздушных линий электропередачи. Общие технические условия», а так же внутренние нормативные документы электросетевых компаний (решения научно-технических советов и др.), в которых не отражается возможность применения провода СИП-4 указанных сечений. Важно отметить, что ГОСТ Р 52373-2005, в котором прописаны классификация, основные параметры и размеры СИП, согласно Федеральному закону от 27.12.2002 г. №184-ФЗ «О техническом регулировании» носит лишь рекомендательный характер и не может ограничивать применение продукции, удовлетворяющей иным техническим условиям. Обратите внимание, что термин СИП в ГОСТ Р 52373-2005, пункт 3.1 даётся несколько в «усечённой» формулировке:

СИП — многожильный провод для воздушных линий электропередачи, содержащий изолированные жилы и несущий элемент, предназначенный для крепления или подвески провода. Согласно данному определению провод СИП должен крепиться к опорам или сооружениям за несущую жилу, которая существует только у проводов марок СИП-1 и СИП-2.

Пункт 2.4.2 ПУЭ даёт более полное определение провода:

СИП — скрученные в жгут изолированные жилы, причём несущая жила может быть как изолированной, так и не изолированной. Механическая нагрузка может восприниматься или несущей жилой, или всеми проводниками жгута.

Для максимально эффективного использования инвестиций в строительство и реконструкцию ВЛ до 1 кВ при формировании технического задания на проектирование необходимо принимать во внимание существующие требования нормативно-технических документов на сооружение ВЛИ, на производство проводов и линейной арматуры, а также технико-экономические характеристики различных систем СИП.

2. Разработка специализированной (проектной) организацией рабочих чертежей и прилагаемых документов.

Характерными ошибками при проектировании ВЛИ в настоящее время являются некорректный подбор линейной арматуры, отсутствие механического расчёта проводов, арматуры и опор.

На рисунке 5 представлен узел промежуточной опоры ВЛИ, выполненной проводом СИП-2, при этом в качестве поддерживающего зажима используется арматура для системы без нулевой несущей жилы (СИП-4). Согласно п. 2.4.18 ПУЭ-7:

Все виды механических нагрузок и воздействий на СИП с несущей жилой должна воспринимать эта жила, а на СИП без несущего провода должны воспринимать все жилы скрученного жгута.

Поэтому в данном случае вместо поддерживающего зажима SO130 (для системы без нулевой несущей жилы) необходимо применить поддерживающий зажим типа SO265, позволяющий поддерживать жгут провода за изолированную нулевую несущую жилу. Более того, разница в стоимости зажимов SO130 и SO265 составила 264 рубля в ценах 2010 г., что привело к необоснованному удорожанию объекта.

Более того, нулевая несущая жила провода СИП-2 выполнена из алюминия, упроченного стальной проволокой, а не из алюминиевого сплава типа АВЕ согласно требованию ГОСТ Р 52373-2005. В результате, при замене зажимов SO130 на зажимы SO265 нулевая несущая жила провода СИП-2 не фиксировалась надёжно защёлкой в поддерживающем зажиме из-за большей жёсткости, чем жила, выполненная из алюминиевого сплава. Монтаж ВЛИ проводился при температуре -12-15°С.

Рисунок 4. Узел промежуточной опоры ВЛИ.

На рисунке 5 представлен узел угловой промежуточной опоры ВЛИ, выполненной проводом СИП-4. В данном узле был применён поддерживающий зажим SO270 для угла поворота провода от 15° до 30° вместо поддерживающего зажима SO136, предназначенного для угла поворота провода до 90°, что привело к ненормируемому радиусу изгиба провода и снижению минимальной разрушающей нагрузки (МРН) узла практически в 6 раз.

Как было отмечено выше, в техническом задании на проектирование заказчиком не указывается одно из требований к СИП — соответствие провода конкретному техническому условию или ГОСТ Р 52373-2005. В свою очередь, проектная организация в спецификации оборудования, изделий и материалов также не всегда прописывает ТУ или ГОСТ Р 52373-2005 которым должен соответствовать СИП, что в принципе противоречит требованию раздела 6 ГОСТ Р 21.1101-2009 «Основные требования к проектной и рабочей документации». В итоге, в спецификации указывается только марка провода, например СИП-2 или СИП-4.

Рисунок 5. Узел угловой промежуточной опоры ВЛИ.

При выборе сечения жил по длительно допустимому току и проверке их по условию нагрева при КЗ необходимо чётко понимать, на основе какого типа изоляции проводится электротехнический расчёт. Напомним, что эксплуатационные характеристики (допустимый нагрев токопроводящих жил и соответственно токовые характеристики) проводов с изоляцией из сшитого полиэтилена выше в среднем на 28%, чем с изоляцией из термопластичного полиэтилена.

Правда, необходимо отметить, что более высокие эксплуатационные характеристики СИП с изоляцией из сшитого полиэтилена по отношению к изоляции из термопластичного полиэтилена невсегда экономически оправданы. Например, в сетях наружного освещения, в которых средняя нагрузка на фазу не превышает 25 А, целесообразно использовать СИП с изоляцией из термопластичного полиэтилена. При указанной нагрузке, минимальное сечение основных жил провода составит всего 16 мм2 при допустимом длительном токе 70 А, а у более дорого СИП с изоляцией из сшитого полиэтилена аналогичного сечения допустимый длительный ток достигает уже 100 А. Поэтому в сетях с малыми нагрузками расчётное сечение основных жил провода будет в большей степени зависеть не от пропускной способности провода, которая определяется сечением жилы и материалом её изоляции, а от условий механической прочности согласно п. 2.4.14 ПУЭ и длины ВЛИ (величины потери напряжения в линии).

3. Приобретение службой закупок оборудования, изделий и материалов.

После рассмотрения и утверждения рабочей документации, поступившей от проектной организации, заказчиком формируется заявка на приобретение оборудования и материалов, в том числе СИП и линейной арматуры, которая передаётся в работу службе закупок. К сожалению, требования к эффективности технико-экономических показателей при приобретении материалов и оборудования не всегда приводят к желаемому результату. Часто экономические показатели приобретаемой продукции преобладают над техническими показателями.

3.1. Приобретение провода СИП.

Служба закупок, ссылаясь только на проектную марку провода СИП-2 или СИП-4, приобретает провод по минимальной, на основе тендера, цене. А при абсолютно одинаковых, на первый взгляд, марках проводов меньшая стоимость будет у СИП с изоляцией из термопластичного полиэтилена, чем с изоляцией из сшитого полиэтилена или с несущей жилой из алюминия, упроченного стальной проволокой (для проводов СИП-1, СИП-2) по отношению к алюминиевому сплаву типа АВЕ. Если электротехнический расчёт провода выполнялся на основе данных для изоляции из сшитого полиэтилена, а приобретён провод с изоляцией из термопластичного полиэтилена, то в итоге строительства мы получим ВЛИ с заниженными характеристиками.

Разобраться в технических нюансах СИП, выпускаемых производителями России и ближнего зарубежья, затруднительно не только менеджерам отдела закупок, но и техническим специалистам. Дело в том, что введение ГОСТ Р 52373-2005 не привело к единому порядку в наименовании и исполнении проводов. Как указывалось выше, согласно Федеральному закону от 27.12.2002 г. №184-ФЗ «О техническом регулировании», указанный ГОСТ Р 52373-2005 не может ограничивать применение продукции, удовлетворяющей иным техническим условиям. Напомним, что требования ГОСТ Р 52373-2005, изм.1 к конструктивному исполнению проводов СИП гласит:

5.2.1.5. Нулевая несущая жила и токопроводящая жила защищённых проводов должны быть скручены из круглых проволок из алюминиевого сплава, иметь круглую форму и быть уплотнёнными.

5.2.1.8. Изоляция основных и вспомогательных токопроводящих жил, изоляция (при наличии) нулевой несущей жилы и защитная изоляция защищённых проводов должна быть из светостабилизированного сшитого полиэтилена. Изоляция должна быть чёрного цвета.

Ряд заводов, продолжают совершенно законно производить и реализовывать СИП с изоляцией из термопластичного полиэтилена или с несущей жилой из алюминия, упроченного стальной проволокой. Проблема в том, что указанные провода иногда маркируются в соответствии ГОСТ Р 52373-2005, то есть как провода с изоляцией из сшитого полиэтилена или с несущей жилой из алюминиевого сплава соответственно.

В 2010 году мы провели исследование самонесущих изолированных проводов, выпускаемых предприятиями, входящих в НП «Ассоциация «Электрокабель». Работа проводилась на основе изучения информации, представленной на заводских сайтах, и интервьюирования ведущих технических специалистов предприятий. Как видно из результатов исследования, представленных в приложении 1 под одной маркой СИП можно найти изделия с разными качественными характеристиками. Например, провод СИП-4 с изоляцией из термопластичного полиэтилена производят такие компании, как ПАО «Завод «Южкабель», Украина (таблица П1.1), ОАО «Казэнергокабель», Казахстан (таблица П1.4), ОАО «Севкабель», ОАО «Рыбинсккабель» (таблица П1.2), Россия. Эту же марку провода СИП-4, но с изоляцией из сшитого полиэтилена производят ЗАО «Завод» Людиновокабель», ОАО «Иркутсккабель», ООО «Камкабель», ЗАО «Цветлит», ЗАО «Завод Москабель». ОАО «Электрокабель» Кольчугинский завод», ЗАО «Томсккабель», Россия (таблица П1.2), ЗАО «Белтелекабель», Белоруссия (таблица П1.3). Напомним, что допустимый нагрев жилы СИП в нормальном режиме с изоляцией из термопластичного полиэтилена составляет 70°С, а с изоляцией из сшитого полиэтилена 90°С. Поэтому, если электрический расчёт ВЛИ выполнялся на основе технических данных СИП с изоляцией из сшитого полиэтилена, а для реализации проекта был приобретён СИП с изоляцией из термопластичного полиэтилена, то в итоге строительства мы получим линию с заниженными рабочими характеристиками.

Российские производители ООО «Камкабель», ОАО «Севкабель» и ОАО «Рыбинсккабель» производят провод марки СИП-2 с нулевой несущей жилой, выполненной как из алюминиевого сплава типа АВЕ, так и алюминия, упроченного стальной проволокой (таблица П1.2). Без учета технических условий на производство указанных проводов (технических характеристик) можно приобрести на рынке провод марки СИП-2 с нулевой несущей жилой из алюминия, упроченного стальной проволокой, вместо провода с нулевой несущей жилой из алюминиевого сплава. Опыт монтажа и эксплуатации доказывает, как рассматривалось выше, что нулевая несущая жила из алюминия, упроченного стальной проволокой предельного сечения 95 мм2, не всегда надёжно фиксируется в поддерживающих зажимах из-за большей жёсткости, чем жила из алюминиевого сплава.

3.2. Приобретение линейной арматуры.

Опрос монтажных компаний выявил, что причинами низкого качества строительства ВЛИ являются проблемы, связанные с организацией строительно-монтажных работ, в том числе приобретением линейной арматуры службой закупок заказчика или подрядной организацией. Так некорректное календарное планирование проектом по строительству ВЛИ (сжатые сроки выполнения СМР) ставит в узкие временные рамки службу закупок. В результате приобретаются провода и линейная арматура, существующие в наличии у ближайших поставщиков часто не соответствующие требованиям проектной документации (с пересортицей арматуры для разных марок СИП). Не менее важной проблемой является ценовая политика при закупках материалов и оборудования. Часто, взамен качественной проектной арматуры приобретается продукция малоизвестных сомнительных производителей с заниженными механическими характеристиками, но по более низким ценам.

Реализация проекта.

При реализации проектных решений основной причиной совершаемых ошибок является низкая дисциплина монтажных работ, вследствие отсутствия полного комплекта инструментов для монтажа ВЛИ или игнорирование его применения, а также низкая профессиональная подготовка электромонтажного персонала. Например, монтаж провода, как правило, выполняется без применения монтажных роликов непосредственно по земле и без вертлюга, что приводит к множественным повреждениям изоляции провода и образованию петель провода в пролётах. На рисунке 6 в дополнение к проектным замечаниям виден ряд ошибок, допущенных вследствие низкого качества монтажных работ. Опора и крюк SOT29.10 установлены без учёта биссектрисы угла поворота ВЛИ. Повторное заземление крюка выполнено с отступлением от требования п. 2.4.45 ПУЭ — без применения сварки или болтового соединения. При этом крюк SOT29.10 имеет специальное отверстие для выполнения качественного болтового соединения с заземляющим проводником. В нарушение требований производителя линейной арматуры бандаж верхней части крюка выполнен одинарным оборотом ленты COT37, а скрепа COT36 установлена не с противоположной стороны от крюка, а сбоку. Наглядно последняя ошибка представлена на рисунке 6. Так как для монтажников устанавливать скрепу сбоку от крюка более удобно (как правило, это объясняется расположением люльки гидроподъёмника), то такая ситуация часто наблюдается на построенных ВЛИ.

Рисунок 6. Узел промежуточной опоры.

Рекомендация производителя арматуры монтировать скрепу с противоположной стороны от крюка абсолютно обоснована. Мы провели исследование зависимости прочности узла крепления крюка SOT29.10 от места расположения скрепы на бандажной ленте. Испытания проводились на разрывной машине типа FP 100 с максимальным усилием до 10 тон. Крепление крюка SOT29.10 к модели стойки осуществлялось намеренно одинарным оборотом бандажной ленты COT37 с помощью скрепы COT36. Для исключения влияния механических характеристик бандажного крюка SOT29.10 на результаты испытаний элемент крюка был усилен электросварным швом. В качестве образца стойки использовалась металлическая труба с наружным диаметром 210 мм. Результаты исследования представлены на рисунке 8. Как видно из рисунка, при расположении скрепы в позиции №1 («усами» к крюку) прочность узла минимальна. В данном положении при достижении усилия в 15,5 кН происходит разрушение скрепы. При перемещении скрепы в позиции №2, 3 и 4 прочность узла повышается, достигая своего максимального значения в позиции №4. В указанном положении узел разрушается не в скрепе, а вследствие растяжения и, в конечном итоге, разрыва бандажной ленты. При дальнейшем перемещении скрепы в позиции №5, 6 и 7 прочность узла снижается (разрушение узла происходит вновь за счёт разрушения скрепы), но при этом выше значений минимальной разрушающей нагрузки при установке скрепы в позициях №3, 2 и 1, соответственно.

На основе выполненного исследования можно сделать вывод, что прочность узла крепления крюка SOT29.10 достигает своего максимального значения при установке скрепы COT36 в позиции №4 (с противоположной стороны от крюка). Именно эта позиция скрепы и рекомендуется производителем арматуры.

Рисунок 7. Прочности узла крепления крюка SOT 29.10 от места расположения скрепы.

Заключение.

Принимая во внимание перечисленные негативные факторы, ниже предлагаются основные требования, которые следует учитывать при строительстве воздушных линий электропередачи с использованием СИП:

В техническом задании на проектирование заказчику необходимо чётко отражать марку провода СИП, материал изоляции (сшитый или термопластичный полиэтилен), а также номер технического условия или ГОСТ Р 52373-2005, которому должен соответствовать провод.

Проектной организации в спецификации оборудования, изделий и материалов необходимо чётко прописывать номер технического условия, по которому должен изготавливаться СИП.

При приобретении провода и линейной арматуры службе закупок следует запрашивать у поставщиков информацию о реализуемой продукции с предоставлением сертификатов соответствия продукции требованиям нормативных документов. Все замены материалов и оборудования производить только после согласования с организацией, разработавшей проект.

Электромонтажные работы при строительстве ВЛИ должен выполнять только квалифицированный персонал, прошедший специальную подготовку и имеющий в наличии полный комплект инструментов.

Заказчику систематически при реализации проекта производить визуальный и инструментальный контроль строительно-монтажных работ, а также применяемых материалов.

Приложение 1

Таблица П1.1. Украинские производители СИП, входящие в НП «Ассоциация «Электрокабель».

Таблица П1.2. Российские производители СИП, входящие в НП «Ассоциация «Электрокабель».

Таблица П1.3. Белорусские производители СИП, входящие в НП «Ассоциация «Электрокабель».

Таблица П1.4. Казахские производители СИП, входящие в НП «Ассоциация «Электрокабель».

Сип кабель таблица сечений

Виды кабелей СИП, сечение и конструктивные особенности

Главная > Электропроводка > Виды кабелей СИП, сечение и конструктивные особенности

Основным предназначением кабелей СИП является передача электроэнергии по воздушным линиям. Кабель активно используется при отводе электроэнергии от основных магистралей к жилым и хозяйственным сооружениям, при строительстве осветительных сетей на улицах населенных пунктов.

Самонесущий изолированный провод (СИП)

Конструкция СИП

Фазные алюминиевые провода покрыты светостабилизирующим изоляционным покрытием черного цвета. Полиэтиленовое покрытие обладает высокой устойчивостью к влаге и ультрафиолетовым солнечным лучам, которые разрушают резиновую или обычную полимерную изоляцию.

Провода скручиваются в жгут вокруг нулевой алюминиевой жилы, в центре которой стальной провод. Сердечник нулевой жилы является несущей основой всего кабеля. Некоторые конструкции кабелей СИП с малым сечением и небольшим количеством жил имеют легкий вес, т. к. в этих видах отсутствует стальная жила. СИП расшифровывается как самонесущий изолированный провод.

Виды и строение

Производится пять основных типов СИП проводов:

СИП-1 включает в себя три фазы, каждая из которых скручена в жгут из нескольких алюминиевых проводов вокруг сердечника из алюминиевого сплава. Провода четвертой нулевой жилы скручиваются вокруг стального сердечника. Фазы изолированы термопластиком, устойчивым к ультрафиолетовым лучам. На марке кабеля СИП-1А нулевой провод, как и фазные жилы, в изолированной оболочке. Такие кабели выдерживают продолжительное время нагрева при 70°С.

Конструкция кабеля СИП-1, СИП-1А

СИП-2 и СИП-2А имеют аналогичную СИП-1 и 1А конструкцию, разница лишь в изоляционной оболочке. Изоляцией служит «сшитый полиэтилен» – соединение полиэтилена на молекулярном уровне в сетку с широкими ячейками с трехмерными поперечными связями. Такая структура изоляции намного прочнее к механическим воздействиям и выдерживает более низкие и высокие температуры при длительном воздействии (до 90°С). Это позволяет использовать такую марку СИП кабеля в холодных климатических условиях при больших нагрузках. Максимальное напряжение передаваемой электроэнергии до 1Кв.

Внутреннее устройство кабеля СИП-2, СИП-2А

СИП-3 – одножильный кабель со стальным сердечником, вокруг которого свиты провода из алюминиевого сплава AlMgSi. Изоляционная оболочка из «сшитого полиэтилена» позволяет использовать СИП-3 для строительства воздушных линий передачи электроэнергии с напряжением до 20 кВ. Рабочая температура кабеля 70°С, его можно эксплуатировать длительное время при температурах в диапазоне от минус 20°С до + 90°С. Такие характеристики позволяют использовать СИП-3 в различных климатических условиях: при умеренном климате, холодном или в тропиках.

Внутреннее устройство кабеля СИП-3

СИП-4 и СИП-4Н не имеют нулевого провода со стальным стержнем, они состоят из парных жил. Буква Н указывает, что провода в жиле из алюминиевого сплава. ПВХ изоляция устойчива к ультрафиолетовому облучению.

Конструкция самонесущего изолированного провода СИП-4

СИП-5 и СИП-5Н – две жилы имеют аналогичную структуру с СИП-4 и СИП-4Н, отличие в изоляционной оболочке. Технология сшитого полиэтилена позволяет увеличить время эксплуатации при максимально допустимой температуре на 30 процентов. ЛЭП с использованием СИП-5 применяют в холодном и умеренном климате, передавая электроэнергию с напряжением до 2,5 кВ.

Внутреннее устройство самонесущего изолированного провода СИП-5

В зависимости от условий эксплуатации и нагрузки потребляемой электроэнергии выбирают марку и сечение СИП кабеля.

Выбор сечения СИП

Выбор и расчет сечения проводов СИП для подключения различных объектов потребления производится по классической методике. Складываются максимальные потребляемые мощности электроустановок, расчет токовой нагрузки осуществляется по формуле:

I = P\U√³, где

— P – суммарная потребляемая мощность;

— I – максимальный потребляемый ток;

— U – напряжение в сети.

Руководствуясь значением максимального тока, по заранее просчитанным таблицам следует выбрать необходимое сечение СИП проводов.

Параметры наиболее используемых кабелей СИП для подключения зданий от основных магистралей линий электропередач (СИП-1, СИП-1А, СИП-2, СИП-2А)

Сечение в мм и количество жилСопро- тивле- ние фаз в Ом

на 1км

Максимально допустимый ток фазы с термоплас- тиковой изо-

ляцией

Максимально допустимый ток фазы со сшитым полиэти- леномТок короткого замыкания в

кА при продол-жительности 1с

1х16+1х25	1.91	75	105	1
2х16	1.91	75	105	1
2х25	1.2	100	135	1.6
3х16	1.91	70	100	1
3х25	1.2	95	130	1.6
3х16+1х25	1.91	70	100	1
3х25+1х35	1.2	95	130	1.6
3х120 +1х95	0.25	250	340	5.9
3х95+1х95	0.32	220	300	5.2
3х95+1х70	0.32	220	300	5.2
3х50+1х95	0.44	180	240	4.5
3х70+1х70	0.44	180	240	4.5
3х50+1х70	0.64	140	195	3.2
3х50+1х50	0.64	140	195	3.2
3х35+1х50	0.87	115	160	2.3
3х25+1х35	1.2	95	130	1.6
3х16+1х25	1.91	70	100	1
4х16+1х25	1.91	70	100	1
4х25+1х35	1.2	95	130	1.2

При выборе сечения и марки СИП проводов важно учитывать не только максимальную токовую нагрузку, но и температуру, время, в течение которого можно эксплуатировать кабель в экстремальных условиях. Обычно допустимая продолжительность составляет от 4000 до 5000 часов.

Максимальная температура для проводов

Режимы работы Максимальная температура для провода

	Термопластиковая изоляция СИП-1, СИП-1А, СИП-4	Сшитый полиэтилен СИП-2, СИП-2А, СИП-3,СИП-5
норма	70	90
при перегрузках	80	130
при коротком замыкании продолжительностью до 5 секунд	135	250

Выбирая марку СИП кабеля и его сечение по нагреву, обязательно нужно учитывать тип изоляции: сшитый полиэтилен или термопластик. С учетом потерь напряжения, термической стойкости при коротком замыкании, механической прочности, при недостаточной величине одного из параметров выбирается кабель с большим сечением.

При эксплуатации СИП кабеля перегрузки допустимы до 8 часов в сутки, 100 часов в год и не более 1000 часов за весь период работы. Чаще всего для подключения жилых домов или хозяйственных объектов применяют СИП-2А, это объясняется некоторыми недостатками остальных моделей кабеля:

на СИП-1 и СИП-2 нулевая жила не изолирована, при обрыве на ней может быть наведенный, опасный для человека потенциал;
СИП-1(А), СИП-4 имеет непрочную изоляцию;
СИП-3 используется только при напряжениях выше 1000В, это одиночный провод;
СИП-4 или СИП-5 не имеют центральной несущей жилы, поэтому могут применяться только на коротких расстояниях, на больших интервалах кабель растягивается и провисает.

Из вышеприведенной таблицы видно, что кабель СИП-2А может быть с одинаковым или разным сечением жил. Обычно при сечении фазных жил 70 кв./мм, нулевая жила для прочности делается 95мм/кв. При большем сечении фаз н

Провода. Линейная арматура. / ПУЭ 7 / Библиотека / Элек.ру

2.4.13. На ВЛ должны, как правило, применяться самонесущие изолированные провода (СИП).

СИП должен относиться к категории защищенных, иметь изоляцию из трудносгораемого светостабилизированного синтетического материала, стойкого к ультрафиолетовому излучению и воздействию озона.

2.4.14. По условиям механической прочности на магистралях ВЛ, на линейном ответвлении от ВЛ и на ответвлениях к вводам следует применять провода с минимальными сечениями, указанными в табл.2.4.1 и 2.4.2.

Таблица 2.4.1. Минимально допустимые сечения изолированных проводов.

Нормативная толщина стенки гололеда b_э, мм	Сечение несущей жилы, мм², на магистрали ВЛИ, на линейном ответвлении от ВЛИ	Сечение жилы на ответвлениях от ВЛИ и от ВЛ к вводам, мм²
10	35 (25)*	16
15 и более	50 (25)*	16

* В скобках дано сечение жилы самонесущих изолированных проводов, скрученных в жгут, без несущего провода.

Таблица 2.4.2. Минимально допустимые сечения неизолированных и изолированных проводов.

Нормативная толщина стенки гололеда b_э, мм	Материал провода	Сечение провода на магистрали и линейном ответвлении, мм
10	Алюминий (А), нетермообработанный алюминиевый сплав (АН)	25
	Сталеалюминий (АС),термообработанный алюминиевый сплав (АЖ)	25
	Медь (М)	16
15 и более	А, АН, АС, АЖ, М	35
		25
		16

2.4.15. При сооружении ВЛ в местах, где опытом эксплуатации установлено разрушение проводов от коррозии (побережья морей, соленых озер, промышленные районы и районы засоленных песков), а также в местах, где на основании данных изысканий оно возможно, следует применять самонесущие изолированные провода с изолированной жилой.

2.4.16. Магистраль ВЛ, как правило, следует выполнять проводами неизменного сечения.

Сечения фазных проводов магистрали ВД рекомендуется принимать не менее 50 мм².

2.4.17. Механический расчет проводов должен производиться по методу допускаемых напряжений для условий, указанных в 2.5.38-2.5.74. При этом напряжения в проводах не должны превышать допускаемых напряжений, приведенных в табл.2.4.3, а расстояния от проводов до поверхности земли, пересекаемых сооружений и заземленных элементов опор должны отвечать требованиям настоящей главы.

Таблица 2.4.3. Допустимое механическое напряжение в проводах ВЛ до 1 кВ.

Провод	Допустимое напряжение, % предела прочности при растяжении
Провод	при наибольшей нагрузке и низшей температуре t_г=t_	при среднегодовой температуре t_сг
СИП сечением 25-120 мм²	40	30
Алюминиевый сечением, мм²:
25-95	35	30
120	40	30
Из термообработанного и нетермообработанного алюминиевого сплава сечением, мм²:
25-95	40	30
120	45	30
Сталеалюминиевый сечением, мм²:
25	35	30
35-95	40	30

При расчете используются параметры проводов, приведенные в табл.2.5.8.

2.4.18. Все виды механических нагрузок и воздействий на СИП с несущей жилой должна воспринимать эта жила, а на СИП без несущего провода – должны воспринимать все жилы скрученного жгута.

2.4.19. Длина пролета ответвления от ВЛ к вводу должна определяться расчетом в зависимости от прочности опоры, на которой выполняется ответвление, высоты подвески проводов ответвления на опоре и на вводе, количества и сечения жил проводов ответвления.

При расстояниях от магистрали ВЛ до здания, превышающих расчетные значения пролета ответвления, устанавливается необходимое число дополнительных опор.

2.4.20. Выбор сечения токоведущих проводников по длительно допустимому току следует выполнять с учетом требований гл.1.3.

Сечение токоведущих проводников должно проверяться по условию нагрева при коротких замыканиях (КЗ) и на термическую стойкость.

2.4.21. Крепление, соединение СИП и присоединение к СИП следует производить следующим образом:

1) крепление провода магистрали ВЛИ на промежуточных и угловых промежуточных опорах – с помощью поддерживающих зажимов;

2) крепление провода магистрали ВЛИ на опорах анкерного типа, а также концевое крепление проводов ответвления на опоре ВЛИ и на вводе – с помощью натяжных зажимов;

3) соединение провода ВЛИ в пролете – с помощью специальных соединительных зажимов; в петлях опор анкерного типа допускается соединение неизолированного несущего провода с помощью плашечного зажима. Соединительные зажимы, предназначенные для соединения несущего провода в пролете, должны иметь механическую прочность не менее 90% разрывного усилия провода;

4) соединение фазных проводов магистрали ВЛИ – с помощью соединительных зажимов, имеющих изолирующее покрытие или защитную изолирующую оболочку;

5) соединение проводов в пролете ответвления к вводу не допускается;

6) соединение заземляющих проводников – с помощью плашечных зажимов;

7) ответвительные зажимы следует применять в случаях:

ответвления от фазных жил, за исключением СИП со всеми несущими проводниками жгута;
ответвления от несущей жилы.

2.4.22. Крепление поддерживающих и натяжных зажимов к опорам ВЛИ, стенам зданий и сооружениям следует выполнять с помощью крюков и кронштейнов.

2.4.23. Расчетные усилия в поддерживающих и натяжных зажимах, узлах крепления и кронштейнах в нормальном режиме не должны превышать 40% их механической разрушающей нагрузки.

2.4.24. Соединения проводов в пролетах ВЛ следует производить при помощи соединительных зажимов, обеспечивающих механическую прочность не менее 90% разрывного усилия провода.

В одном пролете ВЛ допускается не более одного соединения на каждый провод.

В пролетах пересечения ВЛ с инженерными сооружениями соединение проводов ВЛ не допускается.

Соединение проводов в петлях анкерных опор должно производиться при помощи зажимов или сваркой.

Провода разных марок или сечений должны соединяться только в петлях анкерных опор.

2.4.25. Крепление неизолированных проводов к изоляторам и изолирующим траверсам на опорах ВЛ, за исключением опор для пересечений, рекомендуется выполнять одинарным.

Крепление неизолированных проводов к штыревым изоляторам на промежуточных опорах следует выполнять, как правило, на шейке изолятора с внутренней его стороны по отношению к стойке опоры.

2.4.26. Крюки и штыри должны рассчитываться в нормальном режиме работы ВЛ по методу разрушающих нагрузок.

При этом усилия не должны превышать значений, приведенных в 2.5.101.

Провода, арматура / Правила устройства ВЛЭП с СИП / Библиотека / Элек.ру

4.1. На ВЛИ должны применяться изолированные фазные провода, скрученные в жгут относительно изолированного или неизолированного несущего нулевого провода. Ответвления к вводу допускается выполнять изолированными, скрученными в жгут проводами без несущего провода.

4.2. Изолированный провод должен относиться к категории защищенных, иметь изоляцию из трудносгораемого светостабилизированного синтетического материала, стойкого к ультрафиолетовому излучению и воздействию озона; СИП не должен распространять горения.
Изоляция СИП должна быть атмосферостойкой и обеспечивать работоспособность СИП при допустимом длительном токе и интенсивности солнечной радиации не менее 1200 Вт/м².

4.3. Вес виды механических нагрузок и воздействий на СИП должен воспринимать несущий нулевой провод.
На ответвлениях к вводу, выполняемых изолированными проводами, скрученными в жгут без несущего провода, механические нагрузки и воздействия воспринимаются каждым проводом жгута.

4.4. По условиям механической прочности в зависимости от расчетной толщины стенки гололеда на магистралях ВЛИ, на ответвлениях к вводам, а также при натяжке по зданиям и сооружениям или между ними следует применять СИП с сечениями жил несущего нулевого провода не менее приведенных в табл. 4.1.

Таблица 4.1. Минимально допустимое сечение жилы несущего нулевого провода в зависимости от расчетной толщины стенки гололеда

Расчетная толщина стенки гололеда, мм	Сечение жилы несущего нулевого провода, мм²
Расчетная толщина стенки гололеда, мм	на ВЛИ	на ответвлениях от ВЛИ к вводам
до 10	25	16
15 и более	35	16

4.5. На ответвлениях от ВЛИ к вводам допускается применение скрученных в жгут изолированных проводов с изолированным или неизолированным нулевым проводом.

4.6. Длина пролета ответвления от магистрали до ввода должна определяться расчетом в зависимости от прочности опоры, на которой выполняется ответвление, габаритов подвески проводов ответвления на опоре и на вводе, количества и сечения жил проводов ответвления, а также климатических условий.

4.7. Магистраль ВЛИ, как правило, следует выполнять фазными проводами одного сечения. Сечение жил фазных проводов магистрали должно быть не менее 50 мм².

4.8. Механический расчет СИП должен производиться для следующих сочетаний климатических условий:

наибольшая внешняя нагрузка;
низшая температура и отсутствие внешних нагрузок;
среднегодовая температура и отсутствие внешних нагрузок.

Допустимые механические напряжения в несущем нулевом проводе СИП при этих условиях приведены в табл. 4.2.

Таблица 4.2. Допустимое механическое напряжение в несущем нулевом проводе СИП

Номинальное сечение несущего нулевого провода СИП, мм²	Допустимое напряжение, % предела прочности при растяжении
Номинальное сечение несущего нулевого провода СИП, мм²	при наибольшей внешней нагрузке и низшей температуре	при среднегодовой температуре
25-35	35	30
50-95	40	30

4.9. В механических расчетах следует исходить из физико-механических характеристик СИП конкретного типоисполнения.

4.10. Выбор сечения токопроводящих жил СИП по длительному допустимому току следует выполнять с учетом требований 1.3.2. ПУЭ применительно к техническим характеристикам СИП конкретного типоисполнения.

4.11. Сечение токопроводящих жил СИП должно проверяться по условию нагрева при коротких замыканиях и на термическую стойкость.

4.12. Расчетные параметры и характеристики СИП (электрические характеристики, допустимые длительные токи. допустимые токи короткого замыкания) следует принимать по нормативно-технической документации на СИП конкретного типоисполнения.

4.13. Крепление, соединение СИП и присоединение к СИП следует производить при помощи специальной линейной арматуры.

4.13.1. Крепление несущего нулевого провода магистрали ВЛИ на промежуточных и угловых промежуточных опорах — с помощью поддерживающих зажимов.

4.13.2. Анкерное (концевое) крепление несущего нулевого провода магистрали ВЛИ на опорах анкерного типа, а также концевое крепление проводов ответвления на опоре ВЛИ и на вводе — с помощью натяжных анкерных зажимов.

Поддерживающие и натяжные зажимы должны иметь вкладыши или корпуса из изолирующих материалов, препятствующие истиранию изоляции проводов.

4.13.3. Соединение несущего нулевого провода ВЛИ в пролете — с помощью специальных соединительных зажимов; в петлях опор анкерного типа допускается соединение неизолированного несущего нулевого провода с помощью плашечного зажима. Зажим для соединения изолированного несущего нулевого провода должен иметь изолирующее покрытие или защитную изолирующую оболочку.

4.13.4. Соединение фазных проводов магистрали ВЛИ — с помощью специальных соединительных зажимов, имеющих изолирующее покрытие или защитную изолирующую оболочку.

4.13.5. Соединительные зажимы по п.4.13.3. настоящих Правил должны иметь механическую прочность не менее 90% прочности проводов (за исключением плашечного зажима).

4.13.6. Соединение проводов ВЛИ в пролете ответвления к вводу не допускается.

4.13.7. Соединение заземляющих проводников — с помощью плашечных зажимов.

4.13.8. Присоединение с помощью ответвительных зажимов следует производить для устройства:

ответвления от фазных проводов магистрали ВЛИ;
ответвления от несущего нулевого провода магистрали ВЛИ.

4.13.9. Присоединение с помощью ответвительных зажимов следует производить дтя устройства:

заземляющих проводников к несущему нулевому проводу магистрали ВЛИ;
нулевого провода светильника уличного освещения к несущему нулевому проводу магистрали ВЛИ и зануления корпуса светильника;
фазного провода светильника уличного освещения к проводу уличного освещения ВЛИ;
приборов контроля напряжения и переносного (инвентарного) заземляющего устройства.

4.14. Зажимы по пп. 4.13.8. и 4.13.9. настоящих Правил должны иметь корпуса, выполненные из изолирующего материала или материала с изолирующим покрытием, либо снабжены защитными изолирующими кожухами.

4.15. Крепление поддерживающих и натяжных анкерных зажимов к опорам ВЛИ, стенам зданий и сооружениям следует выполнять с помощью специальных узлов крепления, крюков или кронштейнов.

4.16. Коэффициент запаса прочности поддерживающих и натяжных зажимов, узлов крепления, крюков и кронштейнов в нормальном режиме должен быть не менее 2,0.

4.17. При монтаже СИП и линейной арматуры необходимо применять следующую гарнитуру:

4.17.1. Защитные накладки, предназначенные для защиты отдельных проводов СИП от повреждений. Они должны быть установлены на соединительных и ответвительных зажимах, не имеющих защитных кожухов.

4.17.2. Защитные самоусаживающиеся оболочки для изоляции соединительных зажимов, нс имеющих изолирующего покрытия.

4.17.3. Бандажные ленты или хомуты из изолирующего материала — для бандажирования скрученных в жгут проводов, устанавливаемые на СИП с обеих сторон смонтированных на проводах одиночных зажимов или группы зажимов.

4.17.4. Защитные колпачки — для изоляции концов жил изолированных проводов.

Пропускная способность провода сип. Виды кабелей сип, сечение и конструктивные особенности

Сегодня для прокладки воздушных электрических линий вместо нескольких разделённых друг от друга голых алюминиевых проводов, прикрученных к изоляторам, используют провод СИП
(Самонесущий Изолированный Провод
). СИП представляет собой один или жгут из нескольких изолированных проводов, который крепится к опорам специальными креплениями за одну или за все жилы одновременно (в зависимости от его разновидности).

Разновидности СИП

СИП имеет несколько разновидностей:

СИП-1 — несущая нулевая жила без изоляции, фазные жилы заизолированы. Изоляция — термопластичный светостабилизированный полиэтилен. Крепится за нулевую жилу. Рабочее напряжение: до 0,66/1 кВ с частотой 50 Гц.

СИП-1А — то же, что и СИП-1, но все жилы заизолированы

СИП-2 — несущая нулевая жила без изоляции, фазные жилы заизолированы. Изоляция — сшитый светостабилизированный полиэтилен (полиэтилен с поперечными молекулярными связями). Крепится за нулевую жилу. Рабочее напряжение: до 0,66/1 кВ с частотой 50 Гц.

СИП-2А — то же, что и СИП-2, но все жилы заизолированы.

СИП-3 — одножильный провод. Жила выполнена из уплотнённого сплава или уплотнённой сталеалюминевой конструкции проволок. Изоляция — сшитый светостабилизированный полиэтилен. Рабочее напряжение: до 35 кВ.

СИП-4 — все жилы заизолированы. Изоляция — термопластичный светостабилизированный полиэтилен. Не имеет несущей жилы. Крепится за все жилы одновременно. Рабочее напряжение: до 0,66/1 кВ с частотой 50 Гц.

СИП-5 — то же, что и СИП-4, но изоляция — сшитый светостабилизированный полиэтилен.

Выбор разновидности СИП для СНТ

Для прокладки воздушных линий в СНТ наиболее приемлемым является провод СИП-2А.

Недостатки других типов СИП:

У СИП-1 и СИП-2 на неизолированной нулевой жиле при её обрыве возможно присутствие опасного для людей потенциала.

У СИП-1, СИП-1А и СИП-4 менее прочная изоляция.

СИП-3 предназначен для напряжений свыше 1000 вольт. Кроме того, это одиночный провод, его не сворачивают в жгут.

СИП-4 и СИП-5 могут применяться только для отводов к домам. Из-за отсутствия упрочнённой несущей жилы могут растягиваться со временем.

СИП-2А может иметь в своём жгуте жилы как одного, так и разных сечений. Как правило, при сечениях фазных жил до 70 кв.мм. несущая нулевая жила для прочности делается большего сечения, чем фазные, а свыше 95 кв.мм. — меньшего, потому что прочности уже хватает, а электрически (при равномерном распределении нагрузки между фазами
) нулевая жила нагрузки практически не несёт. Также распространены жгуты с жилами одинакового сечения. Жилы освещения, если таковые присутствуют в жгуте, делают сечением 16 или 25 кв.мм.

Расчёт сечения фазных жил СИП

При расчёте сечения фазных проводов следует учитывать не только максимальный ток, который они могут держать, а ещё и падение напряжения на конце линии, которое не должно превышать 5% при максимальной нагрузке. При расстояниях свыше 100 метров падение напряжения в линии уже становится узким местом. Провод ещё держит нагрузку, но до конца провода доходит слишком низкое напряжение.

Рассмотрим ситуацию на примере моего СНТ. Длина магистральной линии 340 метров. Максимальная мощность энергопринимающих устройств — 72 кВт. Требуется подобрать соответствующий СИП. Для этого вычислим максимальный ток, который может протекать в проводах:

Вычислим максимальную мощность, приходящуюся на 1 фазу.
72 кВт / 3 фазы = 24 кВт = 24000 Вт.

Вычислим максимальный ток одной фазы. На выходе из трансформатора по стандарту 230 В. При подсчёте учитываем также емкостную и индуктивную нагрузку от бытовых приборов, используя косинус фи = 0,95.
24000 Вт / (230 В * 0,95) = 110 А

Итак, провод должен держать 110 А. Смотрим технические характеристики СИП для разных сечений, и видим, что 110 А вполне выдержит СИП с сечением фазных жил 25 кв.мм.

Казалось бы, что ещё нужно? Но не всё так просто. У нас линия длиной 340 метров, а любой провод имеет своё собственное сопротивление, которое снижает напряжение на его конце. Согласно допускам, падение напряжения на максимальной нагрузке в конце линии не должно превышать 5%. Посчитаем падение напряжения для нашего случая с жилами 25 кв.мм.

Рассчитаем сопротивление 350 м провода сечением 25 кв.мм.:

Удельное сопротивление алюминия в СИП — 0,0000000287 ом·м.
Сечение провода — 0,000025 кв.м.
Удельное сопротивление провода 25 кв.мм = 0,0000000287 / 0,000025 = 0,001148 ом·м
Сопротивление 350 метров провода сечением 25 кв.мм. = 0,001148 * 350 = 0,4018 ом

Рассчитаем сопротивление нагрузки 24 000 Вт:

Выведем удобную для расчёта формулу.

и подставив в последнюю формулу значения, рассчитаем сопротивление нагрузки:
230 В * 230 В * 0,95 / 24000 Вт = 2,094 ом

Рассчитаем полное сопротивление всей цепи, сложив оба полученных выше сопротивления:

0,4018 ом + 2,094 ом = 2,4958 ом

Рассчитаем максимальный ток в проводе, который может возникнуть, исходя из полного сопротивления цепи:

230 В / 2,4958 ом = 92,1564 А

Рассчитаем падение напряжения в проводе, перемножив максимально возможный ток и сопротивление провода:

92,1564 А * 0,4018 ом = 37 В

Падение напряжения в проводе в 37 вольт — это 16% от исходного напряжения 230 вольт, что намного больше допустимых 5%. Вместо 230 вольт на конце линии при полной нагрузке окажется всего 230 — 37 = 193 вольта вместо допустимых 230 — 5% = 218,5. Поэтому сечение жил надо увеличивать.

Для рассматриваемого нами случая подойдёт сечение фазных жил 95 кв.мм. Это существенно больше, чем необходимо по току, но при максимальной нагрузке на конце линии такое сечение даст падение напряжения 10,8 В, что соответствует 4,7% от исходного напряжения, что вписывается в допуск.

Таким образом, нам для линии 350 метров и нагрузки по 24 кВт на фазу, необходим СИП-2А сечением фазных жил 95 кв.мм.

Замечу, что при неравномерной нагрузке на фазы усиливается ток по нулевому проводнику, а значит, его сопротивление тоже начинает играть роль, и его следует включить в расчёт (например, увеличить расчётную длину провода, скажем, в полтора раза). При очень неравномерной нагрузке (например, зимой, когда в СНТ живёт 1-2 человека, отапливающихся электрообогревателями, которые сидят на 1, или пусть даже на 2 фазах) может возникнуть перекос фаз на самом трансформаторе. В этом случае напряжение на нагруженных фазах падает ещё больше, а на не нагруженной — возрастает. Поэтому в идеале таким потребителям следует ставить трёхфазный ввод, и включать разные обогреватели в разные фазы.

P.S.:
Расчёт однофазной линии производится аналогично трёхфазной, только мощность потребителей не делится на 3 фазы и указывается двойная длина линии, поскольку в однофазной линии нулевая жила нагружена одинаково с фазной.

Самонесущий изолированный провод (СИП)

Конструкция СИП

Виды и строение

Производится пять основных типов СИП проводов:

СИП-1 включает в себя три фазы, каждая из которых скручена в жгут из нескольких алюминиевых проводов вокруг сердечника из алюминиевого сплава. Провода четвертой нулевой жилы скручиваются вокруг стального сердечника. Фазы изолированы термопластиком, устойчивым к ультрафиолетовым лучам. На марке кабеля СИП-1А нулевой провод, как и фазные жилы, в изолированной оболочке. Такие кабели выдерживают продолжительное время нагрева при 70°С.

Конструкция кабеля СИП-1, СИП-1А

СИП-2 и СИП-2А имеют аналогичную СИП-1 и 1А конструкцию, разница лишь в изоляционной оболочке. Изоляцией служит «сшитый полиэтилен» – соединение полиэтилена на молекулярном уровне в сетку с широкими ячейками с трехмерными поперечными связями. Такая структура изоляции намного прочнее к механическим воздействиям и выдерживает более низкие и высокие температуры при длительном воздействии (до 90°С). Это позволяет использовать такую марку СИП кабеля в холодных климатических условиях при больших нагрузках. Максимальное напряжение передаваемой электроэнергии до 1Кв.

СИП-3 – одножильный кабель со стальным сердечником, вокруг которого свиты провода из алюминиевого сплава AlMgSi. Изоляционная оболочка из «сшитого полиэтилена» позволяет использовать СИП-3 для строительства воздушных линий передачи электроэнергии с напряжением до 20 кВ. Рабочая температура кабеля 70°С, его можно эксплуатировать длительное время при температурах в диапазоне от минус 20°С до + 90°С. Такие характеристики позволяют использовать СИП-3 в различных климатических условиях: при умеренном климате, холодном или в тропиках.

Внутреннее устройство кабеля СИП-3

СИП-4 и СИП-4Н не имеют нулевого провода со стальным стержнем, они состоят из парных жил. Буква Н указывает, что провода в жиле из алюминиевого сплава. ПВХ изоляция устойчива к ультрафиолетовому облучению.

Конструкция самонесущего изолированного провода СИП-4

СИП-5 и СИП-5Н – две жилы имеют аналогичную структуру с СИП-4 и СИП-4Н, отличие в изоляционной оболочке. Технология сшитого полиэтилена позволяет увеличить время эксплуатации при максимально допустимой температуре на 30 процентов. ЛЭП с использованием СИП-5 применяют в холодном и умеренном климате, передавая электроэнергию с напряжением до 2,5 кВ.

Внутреннее устройство самонесущего изолированного провода СИП-5

Выбор сечения СИП

Выбор и расчет сечения проводов СИП для подключения различных объектов потребления производится по классической методике. Складываются максимальные потребляемые мощности электроустановок, расчет токовой нагрузки осуществляется по формуле:

I = P\U√³, где

— P – суммарная потребляемая мощность;

— I – максимальный потребляемый ток;

— U – напряжение в сети.

Сечение в мм и количество жил	Сопро- тивле- ние фаз в Ом на 1км	Максимально допустимый ток фазы с термоплас- тиковой изо- ляцией	Максимально допустимый ток фазы со сшитым полиэти- леном	Ток короткого замыкания в кА при продол-жительности 1с
1х16+1х25	1.91	75	105	1
2х16	1.91	75	105	1
2х25	1.2	100	135	1.6
3х16	1.91	70	100	1
3х25	1.2	95	130	1.6
3х16+1х25	1.91	70	100	1
3х25+1х35	1.2	95	130	1.6
3х120 +1х95	0.25	250	340	5.9
3х95+1х95	0.32	220	300	5.2
3х95+1х70	0.32	220	300	5.2
3х50+1х95	0.44	180	240	4.5
3х70+1х70	0.44	180	240	4.5
3х50+1х70	0.64	140	195	3.2
3х50+1х50	0.64	140	195	3.2
3х35+1х50	0.87	115	160	2.3
3х25+1х35	1.2	95	130	1.6
3х16+1х25	1.91	70	100	1

СИП провод: назначение, применение — Электрик Ступино

СИП применяется для подключении дома, строения, щита учета электроэнергии, а также уличных фонарей. Он имеет невысокую цену и при этом хорошие электрические и механические характеристики.

Конструкция СИП провода:

СИП – 1, СИП – 2, ТУ 16.К71-268-98

СИП – 1А, СИП – 2А, ТУ 16.К71-268-98

СИП – 3, ТУ 16.К71-268-98

СИП – 4, СИП – 5, ТУ 16.К71-272-98, ТТ

Фазная токопроводящая жила изготовлена из алюминия, она многопроволочная и уплотненная.
Нулевая несущая жила изготовлена из алюминиевого сплава ABE или стале-алюминевого, она также многопроволочная и уплотненная.
Изоляция выполнена из светостабилизированного термопластичного полиэтилена (LDPE) для проводов СИП-1, СИП-1А, СИП-4, а для проводов СИП-2 светостабилизированного сшитого полиэтилена (XLPE) , СИП-2А, СИП-3, а также СИП-5.

Область применения СИП провода

Самонесущие изолированные провода (СИП) предназначены для применения в воздушных линиях электропередачи (ЛЭП) с подвеской на опорах или фасадах зданий и сооружений.

Климатическое исполнение — УХЛ, категории размещения — 1, 2 и 3, в атмосфере II и III типа по ГОСТ 15150-69.

У самонесущих изолированных проводов выявилось техническое и экономическое преимущество линий по сравнению с воздушными линиями электропередачи напряжением 0,38 кВ с неизолированными проводами.

На основании положительного опыта применения СИП, был издан директивный документ РАО «ЕЭС России» №ОБ-5145 от 26.06.2000 «О применении самонесущих изолированных проводов при строительстве и реконструкции».

Преимуще

RFC 4412 — Приоритет коммуникационных ресурсов для протокола инициации сеанса (SIP)

[Docs] [txt | pdf] [draft-ietf-sip -…] [Tracker] [Diff1] [Diff2]

Обновлено: 7134 ПРЕДЛАГАЕМЫЙ СТАНДАРТ

Сетевая рабочая группа Х. Шульцринне
Запрос комментариев: 4412 Columbia U.Категория: Стандарты Track J. Polk
Cisco Systems
Февраль 2006 г.

Приоритет коммуникационных ресурсов для
протокол инициации сеанса (SIP)

Статус этой памятки

Этот документ определяет протокол отслеживания стандартов Интернета для
Интернет-сообщество и просит обсуждения и предложения по
улучшения.Пожалуйста, обратитесь к текущему выпуску "Интернет
Официальные стандарты протокола »(STD 1) для состояния стандартизации
и статус этого протокола. Распространение памятки не ограничено.

Уведомление об авторских правах

Авторское право (C) The Internet Society (2006).

Аннотация

В этом документе определены два новых протокола инициации сеанса (SIP).
поля заголовка для передачи приоритета ресурса, а именно,
«Приоритет ресурсов» и «Приоритет ресурсов». В
Поле заголовка "Resource-Priority" может влиять на поведение SIP.
пользовательские агенты (например, телефонные шлюзы и IP-телефоны) и SIP
прокси.Это не влияет напрямую на поведение пересылки
IP-маршрутизаторы.

Содержание

1. Введение ............................................... ..... 3
2. Терминология ............................................... ...... 6
3. Протокол SIP с приоритетом ресурсов и приоритетом принятия ресурсов.
Поля заголовка ................................................ ... 6
3.1. Поле заголовка Resource-Priority ....................... 6
3.2. Поле заголовка Accept-Resource-Priority................ 8
3.3. Использование приоритета ресурсов и
'Приоритет-ресурс-принятие' ................................. 8
3.4. Тег опции 'resource-priority' ......................... 9
4. Поведение SIP-элементов, которые получают приоритетные запросы ...... 9
4.1. Введение ............................................... 9
4.2. Общие правила .............................................. 9
4.3. Использование заголовка требования с приоритетом ресурса ............ 10
4.4. Запрос OPTIONS с приоритетом ресурсов .................... 10

Schulzrinne & Polk Standards Track [Страница 1]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


      4.5. Подходы к преференциальному рассмотрению запросов ......... 11
           4.5.1. Упреждение ......................................... 11
           4.5.2. Приоритетная организация очереди .................................. 12
      4.6. Условия ошибки .......................................... 12
           4.6.1. Введение ....................................... 12
           4.6.2. Нет известного пространства имен или значения приоритета ............... 13
           4.6.3. Ошибка аутентификации ............................. 13
           4.6.4. Ошибка авторизации .............................. 14
           4.6.5. Недостаток ресурсов ............................. 14
           4.6.6. Занят ............................................... 14
      4.7. Элементно-зависимое поведение................................ 15
           4.7.1. Поведение клиента пользовательского агента ......................... 15
           4.7.2. Поведение сервера пользовательского агента ......................... 15
           4.7.3. Поведение прокси ..................................... 16
   5. Сторонняя аутентификация ..................................... 17
   6. Обратная совместимость ........................................ 17
   7. Примеры ............................................... ........ 17
      7.1. Простой звонок ............................................... 18
      7.2. Получатель не понимает пространство имен ............... 19
   8. Обработка нескольких одновременных пространств имен ........................ 21
      8.1. Общие правила ............................................. 21
      8.2. Примеры действительных заказов ............................... 21
      8.3. Примеры неверных заказов ............................. 22
   9. Регистрация пространств имен ......................................... 23
   10. Определения пространств имен......................................... 24
      10.1. Введение ............................................. 24
      10.2. Пространство имен "DSN" ...................................... 24
      10.3. Пространство имен "DRSN" ..................................... 25
      10.4. Пространство имен "Q735" ..................................... 25
      10.5. Пространство имен "ETS" ...................................... 26
      10.6. Пространство имен "WPS" ...................................... 26
   11. Соображения безопасности....................................... 27
      11.1. Общие примечания .......................................... 27
      11.2. Аутентификация и авторизация ......................... 27
      11.3. Конфиденциальность и честность ............................ 28
      11.4. Анонимность ................................................ 29
      11.5. Атаки типа отказа в обслуживании ................................ 29
   12. Вопросы IANA ........................................... 30
      12.1. Введение ............................................. 30
      12.2. Регистрация IANA приоритетных ресурсов и
            Поля заголовка Accept-Resource-Priority ................. 30
      12.3. Регистрация в IANA для приоритетного ресурса Option Tag ....... 31
      12.4. Регистрация в IANA для кода ответа 417 .................. 31
      12.5. Регистрация пространства имен с приоритетом ресурсов IANA ............ 31
      12.6. Приоритетные регистрации IANA ....................... 32
   13. Благодарности .............................................. 32
   14. Список литературы ............................................... ..... 33




Schulzrinne & Polk Standards Track [Страница 2]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


1. Введение

   Во время аварийных ситуаций ресурсы связи (в том числе телефонные
   каналов, пропускной способности IP и шлюзов между коммутируемыми каналами и
   IP-сети) могут быть перегружены. Застой может возникнуть из-за тяжелого
   использование, потеря ресурсов, вызванная стихийным бедствием или техногенной катастрофой,
   и атаки на сеть во время техногенных чрезвычайных ситуаций.Этот
   скопление может затруднить работу людей, которым поручено
   помощь, восстановление или правоохранительные органы для координации их усилий.
   Поскольку IP-сети становятся частью конвергентных или гибридных сетей,
   с общедоступными и частными коммутируемыми (телефонными) сетями, это
   становится необходимым для обеспечения того, чтобы эти сети могли помочь во время
   такие чрезвычайные ситуации.

   Кроме того, пользователи могут захотеть прервать свою связь с более низким приоритетом.
   деятельности и направляют свои ресурсы конечной системы на высшие
   попытка приоритетной связи, если высокоприоритетная связь
   запрос поступает в их конечную систему.Существует множество IP-сервисов, которые могут помочь в чрезвычайных ситуациях.
   Эта памятка касается только приложений связи в реальном времени, связанных с
   протокол инициации сеанса (SIP) [RFC3261], включая голосовой
   через IP, мультимедийные конференции, обмен мгновенными сообщениями и присутствие.

   Приложения SIP могут включать не менее пяти различных ресурсов, которые
   может стать дефицитным и перегруженным во время чрезвычайных ситуаций. Эти ресурсы
   включают ресурсы шлюза, сетевые ресурсы с коммутацией каналов, IP
   сетевые ресурсы, получение ресурсов конечной системы и прокси-сервер SIP
   Ресурсы.Ресурсы IP-сети выходят за рамки SIP
   сигнализация и поэтому здесь не рассматриваются.

   Даже если ресурсов самого элемента SIP нет в дефиците, SIP
   шлюз может отмечать исходящие вызовы указанием приоритета, например,
   в ISUP (пользовательская часть ISDN) исходное сообщение IAM (исходное адресное сообщение)
   через шлюз SIP с коммутируемой телефонной сетью общего пользования (PSTN).

   Чтобы улучшить аварийное реагирование, может потребоваться
   назначать приоритет доступа к ресурсам с сигнализацией SIP в периоды
   дефицит ресурсов, вызванный чрезвычайной ситуацией.Мы называем это "ресурсом"
   определение приоритетов ". Сам механизм вполне может быть
   раз, но может существенно повлиять на обработку вызовов только во время
   дефицит ресурсов.

   В настоящее время SIP не включает механизм, позволяющий запрос
   отправитель, чтобы указать элементу SIP, что он хочет, чтобы запрос
   вызвать такую приоритизацию ресурсов. Чтобы удовлетворить эту потребность, это
   документ добавляет элемент протокола SIP, который маркирует определенные SIP
   Запросы.



Schulzrinne & Polk Standards Track [Страница 3]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   Этот документ определяет (Раздел 3) два новых поля заголовка SIP для
   приоритет коммуникационных ресурсов, называемый «приоритет ресурсов» и
   «Принять-ресурс-приоритет».Поле заголовка Resource-Priority МОЖЕТ
   использоваться пользовательскими агентами SIP, включая коммутируемый телефон общего пользования
   Сетевые (PSTN) шлюзы и терминалы, а также прокси-серверы SIP для
   влиять на их обработку SIP-запросов, включая приоритет
   предоставляется для звонков по телефонной сети общего пользования. Для шлюзов PSTN поведение переводится как
   в аналогичные схемы в PSTN, например, ITU
   Рекомендация Q.735.3 [Q.735.3] механизм приоритезации в обоих
   направления PSTN-to-IP и IP-to-PSTN. Рекомендация МСЭ I.255,3
   [I.255.3] - еще один пример.

   SIP-запрос с указанием приоритета ресурса может быть обработан.
   иначе в этих ситуациях:

   1. Запросу может быть присвоен повышенный приоритет для доступа к PSTN.
       ресурсы шлюза, такие как магистральные каналы.

   2. Запрос может прерывать запросы с более низким приоритетом у пользователя.
       терминал, например IP-телефон.

   3. Запрос может нести информацию с одним многоуровневым приоритетом.
       домена в телефонной сети (например, используя средства
       В.735.3 [Q.735.3]) на другой, без самих SIP-прокси
       проверка или изменение поля заголовка.

   4. В SIP-прокси и в пользовательских агентах запросы более высокого уровня
       приоритеты могут замещать существующие запросы сигнализации или обходить
       Ограничения пропускной способности шлюза PSTN действуют для более низких приоритетов.

   Это поле заголовка связано с полем, но отличается от него семантикой.
   Поле заголовка «Priority» ([RFC3261], раздел 20.26). «Приоритет»
   поле заголовка описывает важность, которую должен выполнять запрос SIP.
   иметь для принимающего человека или его агента.Например, этот заголовок
   может учитываться при принятии решений о маршрутизации вызовов на мобильные устройства
   и помощников, а также о приеме вызовов, когда адресат вызова
   занятый. Поле заголовка Priority не влияет на использование PSTN.
   например, ресурсы шлюза или прокси. Кроме того, любой пользовательский агент
   Клиент (UAC) может утверждать любое значение «Приоритета» и использование «Ресурса-
   Значения поля заголовка Priority подлежат авторизации.

   Хотя поле заголовка Resource-Priority напрямую не
   влиять на поведение IP-маршрутизаторов при пересылке или на использование
   коммуникационные ресурсы, такие как приоритет пересылки пакетов,
   процедуры использования этого поля заголовка, чтобы вызвать такое влияние, могут быть
   определены в других документах.Schulzrinne & Polk Standards Track [Страница 4]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   Существующие реализации RFC 3261, которые не участвуют в
   механизм приоритета ресурсов соответствует нормальным правилам RFC 3261,
   Раздел 8.2.2: «Если UAS не понимает поле заголовка в
   запрос (то есть поле заголовка не определено в этом
   спецификации или в любом поддерживаемом расширении) сервер ДОЛЖЕН игнорировать
   это поле заголовка и продолжить обработку сообщения ».Таким образом
   использование этого механизма полностью невидимо для существующих реализаций
   если запрос не включает поле заголовка Require с
   Тег опции приоритета ресурса.

   Описанный здесь механизм может быть использован для аварийной готовности.
   в системах электросвязи в чрезвычайных ситуациях, но составляет лишь небольшую часть
   сеть аварийной готовности и не ограничивается таким использованием.

   Механизм направлен на удовлетворение требований [RFC3487]. это
   структурирован так, что он работает со всеми SIP и транспортом в реальном времени
   Протокол (RTP) [RFC3550] прозрачных сетей, определенных в [RFC3487].В таких сетях все сетевые элементы и SIP-прокси позволяют действующим SIP
   запросы проходят без изменений. Это важно, так как это
   вероятно, что этот механизм будет часто применяться в сетях, где
   пограничные сети не знают о механизме приоритета ресурсов и
   не предоставлять никаких особых привилегий таким запросам. Запрос тогда
   достигает шлюза PSTN или набора SIP-элементов, которые знают о
   механизм.

   Для краткости мы ссылаемся на SIP-прокси и пользовательские агенты (UA), которые
   действуют в поле заголовка «Resource-Priority» как субъекты RP.Вероятно, что один и тот же элемент SIP будет обрабатывать
   запросы, содержащие поля заголовка "Resource-Priority" и те
   это не так.

   Государственные органы и органы по стандартизации разработали несколько
   разные схемы приоритетов для своих сетей. Пользователи хотели бы
   иметь возможность получить авторизованную приоритетную обработку в некоторых из этих
   сети, не меняя SIP-клиентов. Также один звонок может
   пересекать элементы SIP, которые обслуживаются разными администрациями и
   с учетом различных механизмов приоритета.Поскольку нет глобального
   упорядочивая эти приоритеты, мы позволяем каждому запросу содержать
   более одного значения приоритета, взятого из этих разных приоритетов
   списки, называемые в этом документе пространством имен. Обычно каждый SIP
   element поддерживает только одно такое пространство имен, но мы обсуждаем, что происходит
   если элемент должен поддерживать несколько пространств имен в Разделе 8.

   Поскольку получение приоритетного доступа к ресурсам открывает возможности для
   отказывать в обслуживании другим, ожидается, что все такие приоритетные
   звонки проходят аутентификацию и авторизацию с использованием стандартных
   Безопасность SIP (раздел 11) или другие подходящие механизмы.Schulzrinne & Polk Standards Track [Страница 5]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   Остальная часть этого документа структурирована следующим образом. После
   определяя терминологию в разделе 2, мы определяем синтаксис для двух
   новые поля заголовка SIP в разделе 3, а затем описать протокол
   поведения в разделе 4. Два основных механизма
   дифференцированная обработка SIP-запросов (а именно приоритетное и
   очереди) описаны в разделе 4.5. Условия ошибки описаны
   в разделе 4.6. В разделах с 4.7.1 по 4.7.3 подробно описано поведение
   специфические элементы SIP. Сторонняя аутентификация кратко
   резюмируется в Разделе 5. Раздел 6 описывает, как эта функция
   влияет на существующие системы, которые его не поддерживают.

   Поскольку вызовы могут проходить через несколько административных доменов с
   разные пространства имен или несколько элементов с одним и тем же пространством имен, это
   настоятельно рекомендуется, чтобы все такие домены и элементы применяли
   те же алгоритмы для одного и того же пространства имен, в противном случае сквозной
   опыт привилегированных пользователей может быть скомпрометирован.Примеры протоколов приведены в Разделе 7. Раздел 8 обсуждает, что
   происходит, если запрос содержит несколько пространств имен или элемент может
   обрабатывать более одного пространства имен. В разделе 9 перечисляется информация
   это пространство имен необходимо предоставить. Раздел 10 определяет
   свойства пяти пространств имен, зарегистрированных через этот
   документ. Вопросы безопасности рассматриваются в разделе 11, но это
   документ не определяет новые механизмы безопасности. Раздел 12
   обсуждает соображения IANA и регистрирует параметры, связанные с
   этот документ.2. Терминология

   В этом документе ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО»,
   «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ»,
   и «ДОПОЛНИТЕЛЬНО» следует интерпретировать, как описано в BCP 14, RFC 2119.
   [RFC2119] и укажите уровни требований для соответствия
   реализации.

3. Поля заголовка SIP Resource-Priority и Accept-Resource-Priority

   В этом разделе определяется «Приоритет ресурсов» и
   Синтаксис поля заголовка SIP "Accept-Resource-Priority". Поведение
   описано в разделе 4.3.1. Поле заголовка Resource-Priority

   Поле заголовка запроса Resource-Priority отмечает SIP-запрос как
   желая получить приоритетный доступ к ресурсам, как описано в
   введение.





Schulzrinne & Polk Standards Track [Страница 6]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   Нет требований протокола, чтобы все запросы в пределах SIP
   диалоговое окно или сеанс используйте поле заголовка «Resource-Priority».Местный
   административная политика МОЖЕТ предписывать включение
   Поле заголовка Resource-Priority во всех запросах. Реализации
   эта спецификация ДОЛЖНА допускать включение явным пользователем
   запрос или автоматический для всех запросов.

   Описан синтаксис поля заголовка Resource-Priority.
   ниже. Производство «токен-нодот» скопировано из [RFC3265].

      Resource-Priority = "Resource-Priority" HCOLON
                           r-значение * (запятая r-значение)
      r-значение = пространство имен "."r-приоритет
      пространство имен = токен-нодот
      r-приоритет = токен-узел
      token-nodot = 1 * (alphanum / "-" / "!" / "%" / "*"
                                  / "_" / "+" / "` "/" '"/" ~ ")

   Пример поля заголовка Resource-Priority показан ниже:

      Ресурс-приоритет: dsn.flash

   Параметр r-value в поле заголовка Resource-Priority
   указывает приоритет ресурса, желаемый отправителем запроса.
   Каждое значение ресурса (r-значение) форматируется как «пространство имен».'
   «приоритетное значение». Значение берется из идентифицированного пространства имен
   токеном namespace. Пространства имен и приоритеты регистр -
   нечувствительные токены ASCII, не содержащие точек. Таким образом,
   Например, «dsn.flash» и «DSN.Flash» эквивалентны. Каждый
   пространство имен имеет как минимум одно значение приоритета. Пространства имен и приоритет
   значения в каждом пространстве имен ДОЛЖНЫ быть зарегистрированы в IANA
   (Раздел 12). Начальные регистрации пространства имен описаны в
   Раздел 12.5.

   Поскольку запрос может проходить через несколько административных доменов с
   несколько разных пространств имен, необходимо иметь возможность
   перечислить несколько разных пространств имен в одном сообщении.Однако конкретное пространство имен НЕ ДОЛЖНО появляться более одного раза в
   такое же сообщение SIP. Их можно эквивалентно выразить как
   списки, разделенные запятыми, в одном поле заголовка, как несколько
   поля заголовка или в виде некоторой комбинации. Порядок значений r
   в поле заголовка не имеет значения. Так, например,
   следующие три фрагмента заголовка эквивалентны:

     Приоритет ресурсов: dsn.flash, wps.3

     Приоритет ресурсов: wps.3, dsn.flash




Schulzrinne & Polk Standards Track [Страница 7]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


     Ресурс-приоритет: wps.3
     Ресурс-приоритет: dsn.flash

3.2. Поле заголовка Accept-Resource-Priority

   В поле заголовка ответа Accept-Resource-Priority перечисляются
   значения ресурсов (r-значения), которые сервер пользовательского агента SIP готов
   процесс. (Это не означает, что вызов с такими значениями найдет
   достаточно ресурсов и успех.) Синтаксис команды 'Accept-
   Поле заголовка Resource-Priority выглядит следующим образом:

      Accept-Resource-Priority = "Accept-Resource-Priority" HCOLON
                                 [r-значение * (запятая r-значение)]

   Ниже приведен пример:

   Accept-Resource-Priority: dsn.flash-override,
        dsn.flash, dsn.immediate, dsn.priority, dsn.routine

   Некоторые административные домены МОГУТ отключить использование
   Заголовок Accept-Resource-Priority для раскрытия слишком большого количества информации
   об этом домене в отзывах. Однако это поведение НЕ
   РЕКОМЕНДУЕТСЯ, так как это поле заголовка помогает в устранении неполадок.

3.3. Использование «приоритета ресурса» и «приоритета принятия-ресурса»
      Поля заголовка

   Следующая таблица расширяет значения в таблице 2 RFC 3261.
   [RFC3261].(Метод PRACK, обозначенный как PRA, определен в
   [RFC3262], ПОДПИСАТЬСЯ (помечено как SUB) и NOTIFY (помечено как NOT)
   методы в [RFC3265], метод UPDATE (UPD) в [RFC3311],
   MESSAGE (MSG) в [RFC3428], метод REFER (REF) в
   [RFC3515], метод INFO (INF) в [RFC2976] и PUBLISH (PUB)
   метод в [RFC3903].)

      Поле заголовка, в котором прокси INV ACK МОЖЕТ БЫТЬ REG OPT PRA
      -------------------------------------------------- --------------
      Приоритет ресурсов R amdr o o o o o o o
      Принять-ресурс-приоритет 200 драм o - o o o o o
      Принять-ресурс-приоритет 417 драм o - o o o o o

      Поле заголовка, где прокси SUB NOT UPD MSG REF INF PUB
      -------------------------------------------------- --------------
      Приоритет ресурсов R amdr o o o o o o o
      Принять-ресурс-приоритет 200 драм o o o o o o o
      Принять-ресурс-приоритет 417 драм o o o o o o o





Schulzrinne & Polk Standards Track [Страница 8]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.

Другие методы запроса МОГУТ определять свои собственные правила обработки; если только
в противном случае получатели МОГУТ игнорировать эти поля заголовка.3.4. Тег опции 'resource-priority'

В этом документе также определяется тег опции «приоритет ресурса». В
поведение описано в разделе 4.3, а регистрация IANA находится в
Раздел 12.3.

4. Поведение SIP-элементов, получающих приоритетные запросы

4.1. Введение

Все пользовательские агенты SIP и прокси-серверы, поддерживающие эту спецификацию
разделяют определенное общее поведение, которое мы описываем ниже в
Раздел 4.2. Поведение, когда тег опции "приоритет ресурса"
Встречающееся в поле заголовка «Требовать» описано в Разделе 4.3.
В разделе 4.4 описывается обработка запросов OPTIONS. Два
фундаментальные механизмы разрешения конфликтов за ресурсы, вытеснение и
очереди, описаны в разделе 4.5. Раздел 4.6 объясняет, что
происходит, когда запросы терпят неудачу. Поведение, специфичное для клиентов пользовательских агентов,
серверы и прокси-серверы рассматриваются в разделе 4.7.

4.2. Основные правила

Поле заголовка Resource-Priority потенциально применимо ко всем
Сообщения SIP-запроса. Как минимум, реализации следующих
типы запросов ДОЛЖНЫ поддерживать заголовок Resource-Priority, чтобы быть в
соответствие данной спецификации:

o ПРИГЛАСИТЬ [RFC3261]

o ACK [RFC3261]

o PRACK [RFC3262]

o ОБНОВЛЕНИЕ [RFC3311]

o ССЫЛКА [RFC3515]

Реализации ДОЛЖНЫ поддерживать поле заголовка Resource-Priority.
в следующих типах запросов:

o СООБЩЕНИЕ [RFC3428]

o ПОДПИСАТЬСЯ на [RFC3265]

o УВЕДОМЛЕНИЕ [RFC3265]

Schulzrinne & Polk Standards Track [Страница 9]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   Обратите внимание, что это не означает, что все реализации должны
   поддерживать все перечисленные методы запроса.Если элемент SIP получает поле заголовка Resource-Priority в
   запрос кроме перечисленных выше, заголовок МОЖЕТ игнорироваться,
   согласно правилам [RFC3261].

   Короче говоря, субъект RP выполняет следующие шаги при получении
   приоритетный запрос. Поведение при ошибке описано в Разделе 4.6.

   1. Если субъект RP не распознает ни одно из пространств имен, он обрабатывает
       запрос, как если бы он не имел поля заголовка «Resource-Priority».

   2. Он подтверждает, что запрос разрешен в соответствии с местными
       политика для использования указанных уровней приоритета.Если запрос
       не авторизован, он его отклоняет. Примеры авторизации
       политики обсуждаются в разделе «Вопросы безопасности» (раздел 11).

   3. Если запрос авторизован и ресурсы доступны (нет
       перегруженность), он обслуживает запрос как обычно. Если запрос
       авторизован, но ресурсы недоступны (перегрузка), это
       либо вытесняет другие текущие сеансы, либо вставляет запрос
       в приоритетную очередь, как описано в Разделе 4.5.

4.3. Использование заголовка требования с приоритетом ресурса

   Следуя стандартному поведению SIP, если запрос SIP содержит
   Поле заголовка Require с тегом параметра resource-priority, SIP
   пользовательский агент ДОЛЖЕН ответить 420 (недопустимое расширение), если он не
   поддерживают расширения SIP, описанные в этом документе.Затем он перечисляет
   "приоритет ресурса" в поле заголовка "Неподдерживаемый", включенном в
   ответ.

   Использование тега опции 'resource-priority' в 'Proxy-Require'
   поле заголовка НЕ РЕКОМЕНДУЕТСЯ.

4.4. OPTIONS Запрос с приоритетом ресурса

   Запрос OPTIONS может использоваться, чтобы определить, поддерживает ли элемент
   механизм. Соответствующая реализация ДОЛЖНА возвращать 'Accept-
   Поле заголовка Resource-Priority 'в ответах OPTIONS, в которых перечислены все
   допустимые значения ресурсов, но субъект RP МОЖЕТ быть настроен не на
   возвращать такие значения или только для того, чтобы вернуть их авторизованным запрашивающим.Следуя стандартному поведению SIP, ответы OPTIONS ДОЛЖНЫ включать
   Поле заголовка "Поддерживается", которое включает параметр "приоритет ресурса"
   тег.




Schulzrinne & Polk Standards Track [Страница 10]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   Согласно RFC 3261, раздел 11, прокси, которые получают запрос
   с нулевым значением поля заголовка «Max-Forwards» МОЖЕТ отвечать на
   OPTIONS, позволяющий UAC обнаруживать возможности обоих
   прокси и серверы пользовательских агентов.4.5. Подходы к преференциальному рассмотрению запросов

   Элементы SIP могут использовать механизм приоритета ресурсов для изменения
   различные варианты поведения, такие как запросы маршрутизации, аутентификация
   требования, переопределение контроля пропускной способности сети или ведение журнала. В
   механизм приоритета ресурсов может влиять на обработку
   сам запрос, маркировка исходящих вызовов PSTN на шлюзе, или
   сеанса, созданного по запросу. (Здесь мы используем термины
   сеанс и вызов взаимозаменяемы, оба подразумевают непрерывные данные
   поток между двумя или более сторонами.Сессии устанавливаются SIP
   диалоги.)

   Ниже мы определяем два общих алгоритма, а именно приоритетное прерывание и
   приоритетная очередь. Вытеснение применяется только к сеансам, созданным
   SIP-запросы, в то время как сеансы и обработка запросов могут быть предметом
   к приоритетной очереди. Оба алгоритма иногда можно комбинировать в
   тот же элемент, хотя ни одно из пространств имен, описанных в этом
   документ сделай это. Алгоритмы могут быть определены для каждого пространства имен или,
   в некоторых случаях может относиться к административному домену.Другие
   поведение, такое как маршрутизация запросов или средства управления сетью,
   не определено данной спецификацией.

   Естественно, только элементы SIP, которые понимают этот механизм и
   пространство имен и значение ресурса выполняют эти алгоритмы. Раздел 4.6.2
   обсуждает, что происходит, если субъект RP не понимает приоритета
   значения, содержащиеся в запросе.

4.5.1. Упреждение

   Действующий субъект RP, придерживающийся политики вытеснения, может нарушить существующий
   session, чтобы освободить место для входящего сеанса с более высоким приоритетом.поскольку
   сеансы могут потребовать другой пропускной способности или другого
   количество каналов, один сеанс с более высоким приоритетом может заменить
   более одного сеанса с более низким приоритетом. Если иное не отмечено,
   запросы не вытесняют другие запросы с таким же приоритетом. Как указано
   выше, сама обработка SIP-запросов не прерывается. Таким образом,
   поскольку прокси-серверы не управляют сеансами, они не выполняют приоритетное обслуживание.

   [RFC4411] содержит более подробную информацию и примеры такого поведения.

   Поведение UAS при приоритетном обслуживании обсуждается в разделе 4.7.2.1.





Schulzrinne & Polk Standards Track [Страница 11]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


4.5.2. Приоритетная очередь

   В политике приоритетной очереди запросы, которые не находят доступных
   ресурсы помещаются в очередь, которой присвоено значение приоритета.
   Если не указано иное, запросы ставятся в очередь в порядке очереди.
   обслужил заказ. Каждое значение приоритета может иметь свою очередь или несколько
   значения приоритета могут разделять одну очередь.Если ресурс становится
   доступно, субъект RP выбирает запрос из списка с наивысшим приоритетом
   непустая очередь в соответствии с политикой обслуживания очереди. Для первых-
   приходят, первоочередные политики, запрос из той очереди, которая
   ждал дольше всех обслуживается. Каждая очередь может содержать конечное
   количество ожидающих запросов. Если очередь значений приоритета для
   вновь поступивший запрос заполнен, запрос немедленно отклоняется,
   с кодами состояния, указанными в Разделе 4.6.5 и Разделе 4.6.6.
   Кроме того, политика очередности с приоритетом МОЖЕТ устанавливать время ожидания.
   предел для каждого класса приоритета, при этом запросы, превышающие
   указанное время ожидания удаляется из очереди и 408 (Запрос
   Тайм-аут) запрашивающей стороне возвращается ответ об ошибке.

   Наконец, субъект RP МОЖЕТ наложить ограничение на размер глобальной очереди в сумме.
   во всех очередях и отбросить ожидающие запросы с более низким приоритетом с 408
   (Тайм-аут запроса) отказ. Это не означает упреждения,
   так как сеанс еще не установлен.Поведение UAS при организации очередей обсуждается в Разделе 4.7.2.2.

4.6. Условия ошибки

4.6.1. Введение

   В этом разделе мы описываем поведение при ошибках, которое характерно для
   несколько типов субъектов RP (включая различные экземпляры UAS, такие
   как магистральные шлюзы, линейные шлюзы и IP-телефоны) и прокси.

   Запрос, содержащий указание приоритета ресурса, может завершиться ошибкой в течение четырех
   причины:

   o субъект RP не понимает значение приоритета
      (Раздел 4.6.2),

   o запрашивающая сторона не аутентифицирована (Раздел 4.6.3),

   o аутентифицированный запрашивающий не уполномочен делать такие
      запрос (раздел 4.6.4) или

   o недостаточно ресурсов для авторизованного запроса
      (Раздел 4.6.5).




Schulzrinne & Polk Standards Track [Страница 12]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   Мы обрабатываем эти случаи ошибок в том порядке, в котором они обычно возникают.
   обработка запросов с заголовками Resource-Priority.Однако,
   этот заказ не является обязательным. Например, актер RP, который знает, что
   конкретное значение ресурса не может быть обслужено или поставлено в очередь МОЖЕТ, поскольку
   вопрос локальной политики, откажитесь от авторизации, так как это только добавит
   обработка нагрузки без изменения результата.

4.6.2. Нет известного пространства имен или значения приоритета

   Если субъект RP не понимает ни одного из значений ресурсов в
   запрос, лечение зависит от наличия «Требовать»
   Тег опции 'resource-priority':

   1. Без тега option субъект RP обрабатывает запрос, как если бы он
       не содержит поля заголовка Resource-Priority и обрабатывает его
       с приоритетом по умолчанию.Непонятные значения ресурсов
       НЕ ДОЛЖНЫ быть изменены или удалены.

   2. С тегом option он ДОЛЖЕН отклонить запрос с 417
       (Неизвестный приоритет ресурса) код ответа.

   Сделать case (1) значением по умолчанию необходимо, поскольку в противном случае
   быть не в состоянии успешно завершить какие-либо вызовы в случае, если
   прокси на пути к UAS не имеет общих пространств имен с UAC,
   но у UAC и UAS есть такое общее пространство имен.

   Как правило, как уже отмечалось, запрос SIP может содержать более одного
   Поле заголовка Resource-Priority.Это необходимо, если запрос
   должен проходить через разные административные домены, каждый со своими
   набор допустимых значений ресурсов. Например, пространство имен ETS может
   быть активным для правительственных сетей США, которые также поддерживают
   пространства имен DSN и / или DRSN для большинства людей в этих доменах.

   Ответ 417 (неизвестный ресурс-приоритет) МОЖЕТ, согласно местным
   policy, включите поле заголовка Accept-Resource-Priority
   перечисление допустимых значений ресурсов.

4.6.3. Ошибка аутентификации

   Если запрос не аутентифицирован, 401 (неавторизованный) или 407
   (Требуется проверка подлинности прокси) возвращается ответ, чтобы
   разрешить запрашивающей стороне вставить соответствующие учетные данные.









Schulzrinne & Polk Standards Track [Страница 13]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


4.6.4. Ошибка авторизации

   Если субъект RP получает аутентифицированный запрос с пространством имен
   и значение приоритета, которое он распознает, но отправитель не авторизован
   для этого уровня обслуживания элемент ДОЛЖЕН возвращать 403 (Запрещено)
   ответ.4.6.5. Недостаточно ресурсов

   Недостаточные ресурсы могут возникнуть на прокси-серверах и у пользователя.
   серверы агентов, обычно магистральные шлюзы, если субъект RP получает
   авторизованный запрос, недостаточно ресурсов, и запрос
   не вытесняет другой сеанс и не ставится в очередь. Запрос может быть неудачным
   поскольку субъект RP не имеет достаточной вычислительной мощности для
   обрабатывать SIP-запрос или недостаточную пропускную способность или пропускную способность магистрали для
   установить запрошенный сеанс для создания сеансов SIP-запросов.Если запрос не выполняется из-за того, что субъект RP не может обработать сигнализацию
   load, субъект RP отвечает 503 (служба недоступна).

   Если пропускной способности недостаточно или недостаточно
   количество соединительных линий, ответ 488 (здесь неприемлемо) указывает, что
   субъект RP отклоняет запрос из-за доступности медиа-пути,
   например, недостаточно ресурсов шлюза. В этом случае [RFC3261]
   сообщает, что ответ 488 ДОЛЖЕН включать поле заголовка 'Предупреждение'
   с поводом для отказа; код предупреждения 370 (Недостаточно
   Пропускная способность) является типичным.Для систем, реализующих организацию очереди, если запрос поставлен в очередь, UAS
   вернет 408 (тайм-аут запроса), если запрос превышает максимум
   настроенное время ожидания в очереди.

4.6.6. Занятый

   Конфликт за ресурсы также возникает, когда запрос вызова поступает на UAS.
   который не может принять другой вызов, потому что UAS либо
   только одна линия или имеет активные вызовы на всех линиях.
   Если в запросе вызова указано равное или более низкое значение приоритета, когда
   по сравнению со всеми активными вызовами, присутствующими на UAS, UAS возвращает
   486 (здесь занято) ответ.Если вместо этого запрос поставлен в очередь, UAS вернет 408 (Запрос
   Тайм-аут), если запрос превышает максимальное настроенное время ожидания
   в очереди устройства.

   Если прокси-сервер получает 486 ответов (здесь занят) во всех ветвях, он может
   затем верните вызывающему абоненту ответ 600 (везде занято).




Schulzrinne & Polk Standards Track [Страница 14]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


4.7. Поведение, зависящее от элемента

4.7.1. Поведение клиента пользовательского агента

   SIP UAC, поддерживающие эту спецификацию, ДОЛЖНЫ быть способны генерировать
   Поле заголовка Resource-Priority для запросов, требующих повышенных
   приоритет доступа к ресурсам. Как указывалось ранее, ОАК ДОЛЖЕН быть
   возможность генерировать более одного значения ресурса в одном SIP
   запрос.

   При получении ответа 417 (приоритет неизвестного ресурса) UAC
   МОЖЕТ попытаться выполнить последующий запрос с тем же или другим ресурсом
   значение. Если доступно, СЛЕДУЕТ выбрать авторизованные значения ресурсов.
   из набора значений, возвращенных в 'Accept-Resource-Priority'
   поле заголовка.4.7.1.1. Поведение клиента пользовательского агента с алгоритмом вытеснения

   UAC, который запрашивает значение приоритета, которое может вызвать приоритетное прерывание, ДОЛЖЕН
   понять поле заголовка Reason в запросе BYE, объясняющее, почему
   сеанс был прерван, как описано в [RFC4411].

4.7.1.2. Поведение клиента пользовательского агента с политикой организации очереди

   Согласно стандартным правилам протокола SIP, UAC ДОЛЖЕН быть готов к получению
   182 (в очереди) ответ от исполнителя RP, который в настоящее время загружен,
   но это поставило исходный запрос в очередь.ОАК МОЖЕТ
   указать пользователю этот статус в очереди с помощью аудио или видео
   индикация для предотвращения интерпретации пользователем вызова как имеющего
   не удалось.

4.7.2. Поведение сервера пользовательского агента

   Точный эффект индикации «Приоритет ресурсов» зависит от
   тип UAS, пространство имен и локальная политика.

4.7.2.1. Серверы пользовательских агентов и алгоритм вытеснения

   БПЛА, соответствующий этой спецификации, ДОЛЖЕН завершить сеанс.
   установлен с допустимым пространством имен и значением с более низким приоритетом в пользу
   нового сеанса, настроенного с допустимым пространством имен и более высоким относительным
   значение приоритета, если локальная политика не имеет какой-либо формы ожидания вызова
   возможность включена.Если сеанс завершен, метод BYE
   используется с полем заголовка "Причина", указывающим, почему и где
   упреждение имело место.

   У разработчиков есть несколько вариантов реализации вытеснения.
   на IP-телефонах с несколькими линиями присутствия, т. е. с устройствами, которые



Schulzrinne & Polk Standards Track [Страница 15]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   может обрабатывать несколько одновременных сеансов.Естественно, если это устройство
   исчерпал количество одновременных сеансов, один из
   сеансы нужно заменить. Если на устройстве есть свободные сеансы,
   реализация МОЖЕТ выбрать оповещение вызываемого о прибытии
   вызов с более высоким приоритетом. Детали также могут быть установлены локально или пространством имен
   политика.

   [RFC4411] предоставляет дополнительную информацию в случае целенаправленного
   или административное завершение сеанса с указанием причины
   заголовок в сообщении BYE, в котором указывается, почему было отправлено BYE (в этом
   случай, событие упреждения).Механизмы в этом документе позволяют
   указание места прерывания («в UA», «в пределах
   резервирование ',' на шлюзе IP / PSTN ') и включить примеры потоков вызовов
   по каждой причине.

4.7.2.2. Серверы пользовательских агентов и политика на основе очередей

   БПЛА, соответствующий этой спецификации, ДОЛЖЕН генерировать 182
   (В очереди) ответ, если ресурсы этого элемента заняты, пока он не будет
   способен обработать запрос и предоставить окончательный ответ. В
   частота таких предварительных сообщений регулируется [RFC3261].4.7.3. Прокси-поведение

   Прокси-серверы SIP МОГУТ игнорировать поле заголовка «Resource-Priority». ГЛОТОК
   прокси МОГУТ отклонить любой неаутентифицированный запрос с таким заголовком
   поле.

   Когда поле заголовка «Требовать» включено в сообщение, оно обеспечивает
   что при параллельном разветвлении только ветки, поддерживающие ресурс -
   механизм приоритета успешен.

   Если инкапсуляция S / MIME используется в соответствии с разделом 23 RFC 3261,
   Особые соображения применяются. Как указано в таблице в разделе 3.3,
   Поле заголовка Resource-Priority может быть изменено прокси-серверами и, следовательно,
   освобождается от проверки целостности, описанной в Разделе 23.4.1.1
   из RFC 3261. Поскольку может потребоваться проверка или изменение
   прокси, поле заголовка ДОЛЖНО также быть помещено во "внешнее" сообщение
   если UAC хочет, чтобы прокси-серверы могли работать с заголовком
   Информация. Аналогичные соображения применимы, если части сообщения
   защищены целостностью или зашифрованы, как описано в [RFC3420].

   Если S / MIME не используется или поле заголовка Resource-Priority установлено
   во «внешнем» заголовке прокси-серверы SIP МОГУТ понижать или обновлять
   'Resource-Priority' запроса или вставьте новый 'Resource-Priority'
   заголовок, если это разрешено местной политикой.Schulzrinne & Polk Standards Track [Страница 16]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   Если прокси-сервер с отслеживанием состояния разрешил определенный приоритет ресурса
   уровень, и если он предлагает дифференцированный подход к ответам
   содержащие уровни приоритета ресурсов, прокси-сервер ДОЛЖЕН игнорировать любые
   более высокое значение, содержащееся в ответах, чтобы предотвратить сговор пользовательских агентов
   от искусственного повышения уровня приоритета.Прокси-сервер SIP МОЖЕТ использовать указание Resource-Priority в своей маршрутизации.
   решения, например, перенацелить на узел SIP или URI SIP, который
   зарезервировано для определенного приоритета ресурса.

   Нет никаких особых требований к прокси при форковании запросов.
   содержащий указание приоритета ресурса.

   В остальном поведение прокси такое же, как и для серверов пользовательских агентов.
   описано в разделе 4.7.2.

5. Сторонняя аутентификация

   В некоторых случаях субъект RP может быть не в состоянии аутентифицировать
   запросчик или определить, авторизован ли аутентифицированный пользователь для
   сделать такую просьбу.В этих обстоятельствах SIP-объект может
   использовать общие механизмы SIP, не относящиеся к этому
   применение. Механизм управления аутентифицированной идентификацией
   [RFC3893] позволяет третьей стороне проверять личность
   запрашивающего и сертифицировать это по отношению к субъекту RP. В сетях с
   взаимное доверие, механизм идентификации с подтверждением SIP [RFC3325] может помочь
   субъект RP определяет личность запрашивающего.

6. Обратная совместимость

   Механизм приоритета ресурсов, описанный в этом документе, полностью
   обратно совместима с системами SIP согласно [RFC3261].Системы
   которые не понимают механизм, могут поставлять только стандартные, а не
   повышенный, приоритет обслуживания. Серверы пользовательских агентов и прокси-серверы могут
   игнорировать любое поле заголовка Resource-Priority, как и любое другое
   неизвестное поле заголовка, а затем обработайте запрос как любой другой
   запрос. Естественно, запрос все же может быть успешным.

7. Примеры

   Тело сообщения SDP и обмены BYE и ACK такие же, как в
   RFC 3665 [RFC3665] и опущены для краткости.









Schulzrinne & Polk Standards Track [Страница 17]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


7.1. Простой звонок

   Пользователь A Пользователь B
     | |
     | ПРИГЛАСИТЬ F1 |
     | -----------------------> |
     | 180 Звонок F2 |
     | <----------------------- |
     | |
     | 200 ОК F3 |
     | <----------------------- |
     | ACK F4 |
     | -----------------------> |
     | Двусторонний RTP Media |
     | <======================> |
     | |

   В этом сценарии пользователь A выполняет вызов пользователя B напрямую.В
   вызов от A к B отмечен указанием приоритета ресурса.

   F1 ПРИГЛАСИТЬ Пользователь A -> Пользователь B

   ПРИГЛАСИТЬ sip: [email protected] SIP / 2.0
   Через: SIP / 2.0 / TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   Максимальное количество нападающих: 70
   От: BigGuy ; tag = 9fxced76sl
   Кому: LittleGuy 
   Call-ID: [email protected]
   CSeq: 1 ПРИГЛАШАТЬ
   Ресурс-приоритет: dsn.flash
   Контакт: 
   Тип содержимого: приложение / sdp
   Content-Length: ...

   ...

   F2 180 Звонит пользователю B -> Пользователь A

   SIP / 2.0 180 звонков
   Через: SIP / 2.0 / TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
     ; получено = 192.0.2.101
   От: BigGuy ; tag = 9fxced76sl
   Кому: LittleGuy ; tag = 8321234356
   Call-ID: [email protected]
   CSeq: 1 ПРИГЛАШАТЬ
   Контакт: 
   Content-Length: 0




Schulzrinne & Polk Standards Track [Страница 18]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   F3 200 OK Пользователь B -> Пользователь A

   SIP / 2.0 200 ОК
   Через: SIP / 2.0 / TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
     ; получено = 192.0.2.101
   От: BigGuy ; tag = 9fxced76sl
   Кому: LittleGuy ; tag = 8321234356
   Call-ID: [email protected]
   CSeq: 1 ПРИГЛАШАТЬ
   Контакты: 
   Тип содержимого: приложение / sdp
   Content-Length: ...

   ...

7.2. Получатель не понимает пространство имен

   В этом примере принимающий UA не понимает "dsn"
   пространство имен и, таким образом, возвращает статус 417 (приоритет неизвестного ресурса)
   код. Мы опускаем детали сообщений для сообщений с F5 по F7, поскольку
   по сути они такие же, как в первом примере.Пользователь A Пользователь B
     | |
     | ПРИГЛАСИТЬ F1 |
     | -----------------------> |
     | 417 R-P не удалось F2 |
     | <----------------------- |
     | ACK F3 |
     | -----------------------> |
     | |
     | ПРИГЛАСИТЬ F4 |
     | -----------------------> |
     | 180 Звонок F5 |
     | <----------------------- |
     | 200 ОК F6 |
     | <----------------------- |
     | ACK F7 |
     | -----------------------> |
     | |
     | Двусторонний RTP Media |
     | <======================> |









Schulzrinne & Polk Standards Track [Страница 19]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   F1 ПРИГЛАСИТЬ Пользователь A -> Пользователь B

   ПРИГЛАСИТЬ sip: UserB @ biloxi.example.com SIP / 2.0
   Через: SIP / 2.0 / TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   Максимальное количество нападающих: 70
   От: BigGuy ; tag = 9fxced76sl
   Кому: LittleGuy 
   Call-ID: [email protected]
   CSeq: 1 ПРИГЛАШАТЬ
   Требовать: приоритет ресурса
   Ресурс-приоритет: dsn.flash
   Контакты: 

   Тип содержимого: приложение / sdp
   Content-Length: ...

   ...

   F2 417 Ошибка приоритета ресурса Пользователь B -> Пользователь A

   SIP / 2.0 417 Неизвестный приоритет ресурсов
   Через: SIP / 2.0 / TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
     ; получено = 192.0.2.101
   От: BigGuy ; tag = 9fxced76sl
   Кому: LittleGuy ; tag = 8321234356
   Call-ID: [email protected]
   CSeq: 1 ПРИГЛАШАТЬ
   Приоритет принятия-ресурсов: q735.0, q735.1, q735.2, q735.3, q735.4
   Контакт: 
   Тип содержимого: приложение / sdp
   Content-Length: 0

   F3 ACK Пользователь A -> Пользователь B

   ACK sip: [email protected] SIP / 2.0
   Через: SIP / 2.0 / TCP client.atlanta.example.com:5060;branch=z9hG4bK74bd5
   Максимальное количество нападающих: 70
   От: BigGuy ; tag = 9fxced76sl
   Кому: LittleGuy ; tag = 8321234356
   Call-ID: [email protected]
   CSeq: 1 ACK
   Content-Length: 0









Schulzrinne & Polk Standards Track [Страница 20]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   F4 ПРИГЛАСИТЬ пользователя A -> пользователя B

   ПРИГЛАСИТЬ sip: UserB @ biloxi.example.com SIP / 2.0
   Через: SIP / 2.0 / TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
   Максимальное количество нападающих: 70
   От: BigGuy ; tag = 9fxced76sl
   Кому: LittleGuy 
   Call-ID: [email protected]
   CSeq: 2 ПРИГЛАШАТЬ
   Требовать: приоритет ресурса
   Приоритет ресурсов: q735.3
   Контакты: 

   Тип содержимого: приложение / sdp
   Content-Length: ...
   ...

8.Обработка нескольких одновременных пространств имен

8.1. Основные правила

   Один запрос SIP МОЖЕТ содержать значения ресурсов из нескольких
   пространства имен. Как отмечалось ранее, субъект RP игнорирует все пространства имен
   он не узнает. Эта спецификация касается только случая
   где субъект RP затем выбирает одно из оставшихся значений ресурса
   для обработки, обычно выбирая тот, у которого самый высокий родственник
   приоритет.

   Если субъект RP понимает несколько пространств имен, он ДОЛЖЕН создать
   местный общий заказ по всем значениям ресурсов из этих
   пространства имен, сохраняя относительный порядок в каждом пространстве имен.РЕКОМЕНДУЕТСЯ использовать один и тот же порядок для
   административный домен. Однако нет требования, чтобы такие
   порядок должен быть одинаковым для всех административных доменов.

8.2. Примеры действительных заказов

   Ниже приведены примеры RP-актера, поддерживающего два
   пространства имен, foo и bar. Значения приоритета Foo равны 3 (наивысший), тогда
   2, а затем 1 (самый низкий), а приоритетные значения бара - C (самый высокий),
   затем B, а затем A (самый низкий).










Schulzrinne & Polk Standards Track [Страница 21]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   Ниже приведены пять списков приемлемых приоритетов для SIP-элемента.
   может использовать:

       Фу.3 Foo 3 Bar.C (высший приоритет)
       Foo.2 Bar.C Foo.3
       Foo.1 или Foo.2 или Foo.2
       Bar.C Bar.B Foo.1
       Bar.B Foo.1 Bar.B
       Bar.A Bar.A Bar.A (самый низкий приоритет)


              Bar.C (высший приоритет)
           Foo.3 Bar.B (оба обрабатываются с равным приоритетом (FIFO))
    или Foo.2 Bar.A (оба обрабатываются с равным приоритетом (FIFO))
              Foo.1 (самый низкий приоритет)


           Бар.C (высший приоритет)
           Foo.3
    или Foo.2
           Foo.1 (самый низкий приоритет)

   В последнем примере выше Bar.A и Bar.B игнорируются.

8.3. Примеры неверных заказов

   Основываясь на порядке приоритета пространств имен выше, следующие
   комбинации являются примерами заказов, которые НЕ приемлемы и
   НЕ ДОЛЖНЫ быть настраиваемыми:

          Пример 1 Пример 2 Пример 3
          --------- --------- ---------
            Foo.3 Foo.3 Bar.C
            Фу.2 бар.A Foo.1
            Foo.1 или Foo.2 или Foo.3
            Bar.C Bar.B Foo.2
            Bar.A Foo.1 Bar.A
            Bar.B Bar.C Bar.B

                 Пример 4
                 ---------
                   Bar.C
                Foo.1 Bar.B
         или Foo.3 Bar.A
                   Foo.2






Schulzrinne & Polk Standards Track [Страница 22]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   Эти примеры недействительны, так как следующие глобальные порядки
   не соответствует внутреннему порядку пространства имен:

   o В примере 1 Bar.A заказывается выше, чем Bar B.

   o В примере 2 Bar.A заказывается выше, чем Bar.B и Bar.C.

   o В примере 3 Foo.1 упорядочивается выше, чем Foo.2 и Foo.3.

   o В примере 4 Foo.1 упорядочивается выше, чем Foo.3 и Foo.2.

9. Регистрация пространств имен

   Организации, рассматривающие возможность использования заголовка Resource-Priority
   поле должно исследовать, существует ли существующая комбинация пространства имен
   а приоритетные ценности удовлетворяют их потребности. Например, сначала экстренная помощь
   респонденты по всему миру обсуждают использование этого механизма
   для преференциального режима в будущих сетях.Юрисдикции ДОЛЖНЫ
   попытаться повторно использовать существующие зарегистрированные IANA пространства имен, где это возможно,
   поскольку цель этого документа - не иметь уникальных пространств имен для
   юрисдикция, служащая той же цели, с тем же использованием
   уровни приоритета. Это значительно увеличит совместимость и
   сократить время разработки и, вероятно, уменьшить путаницу в будущем, если
   когда-либо возникает необходимость сопоставить одно пространство имен с другим в
   функция взаимодействия.

   Ниже мы описываем шаги, необходимые для регистрации нового пространства имен.Новое пространство имен ДОЛЖНО быть определено в RFC Standards Track, после
   политика "Standards Action" в [RFC2434], и ДОЛЖНА включать
   следующие грани:

   o Он должен определять метку пространства имен, уникальную метку пространства имен
      в реестре IANA для заголовка SIP Resource-Priority
      поле.

   o Он должен перечислять уровни приоритета (т.е. значения 'r-priority')
      пространство имен использует. Обратите внимание, что только конечные списки
      допустимые, не неограниченные целые числа или токены, например.o Алгоритм приоритета (раздел 4.5), определяющий,
      пространство имен должно использоваться с приоритетной очередью ("очередь") или
      упреждение («упреждение»). Если используется организация очереди, пространство имен МОЖЕТ
      указывает, поставлены ли в очередь запросы с нормальным приоритетом. Если там есть
      новый «предполагаемый алгоритм», отличный от вытеснения или приоритета
      постановки в очередь необходимо описать алгоритм с учетом всех
      Актеры РП (UAC, UAS, прокси).




Schulzrinne & Polk Standards Track [Страница 23]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   o Пространство имен может ссылаться на существующий список приоритетов.
      значения или определить новый конечный список значений приоритета в относительных
      порядок приоритета регистрации IANA в параметрах sip
      Реестр приоритетных значений ресурсов.Новые значения приоритета
      НЕ СЛЕДУЕТ добавлять в список, ранее зарегистрированный IANA.
      связаны с определенным пространством имен, так как это может вызвать
      проблемы взаимодействия. Если не указано иное, это
      предполагается, что все значения приоритета имеют более высокий приоритет, чем
      запросы без значения приоритета.

   o Любые новые коды ответов SIP, уникальные для этого нового пространства имен, должны быть
      объяснил и зарегистрировал.

   o В справочном документе должны быть указаны и описаны все новые предупреждения.
      коды предупреждения поля заголовка (RFC 3261, раздел 27.2).

   o В документе необходимо указать новую строку для следующей таблицы
      который суммирует особенности пространства имен и включен в
      Регистрация пространства имен с приоритетом ресурсов IANA:

                         Предполагаемый Новый Новый соотв.
   Алгоритм уровней пространства имен код предупреждения Код ссылки
   --------- ------ ---------------- --------- -------- - -------
    <метка> <количество <приоритетное прерывание <новое предупреждение <новое соотв. 
             уровни> или очередь> код> код>

   Если информация о новых кодах ответа, кодах отказа или ошибке
   поведение опускается, предполагается, что пространство имен определяет
   никаких новых параметров или поведения.10. Определения пространств имен

10.1. Введение

   Эта спецификация определяет пять уникальных пространств имен ниже: DSN, DRSN,
   Q735, ETS и WPS, составляющие их регистрацию в IANA. Каждый
   Регистрация IANA включает аспекты, определенные в разделе 9. Для
   узнаваемость, мы обозначаем пространства имен заглавными буквами, но учтите
   эти имена пространств имен нечувствительны к регистру и обычно
   отображается в нижнем регистре в запросах протокола.

10.2. Пространство имен "DSN"

   Пространство имен DSN происходит от имени правительственной сети США.
   называется «Защитная коммутируемая сеть».Schulzrinne & Polk Standards Track [Страница 24]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   Пространство имен DSN имеет конечный список относительных значений приоритета,
   перечислены ниже в порядке убывания приоритета:

      (самый низкий) dsn.routine
                dsn.priority
                dsn.immediate
                dsn.flash
      (самый высокий) dsn.flash-override

   Пространство имен DSN использует алгоритм вытеснения (раздел 4.5.1).

10.3. Пространство имен "DRSN"

   Пространство имен DRSN происходит от названия правительственной сети США,
   называется «Коммутируемая сеть Defense RED».

   Пространство имен DRSN определяет следующие значения ресурсов, перечисленные в
   от низшего приоритета к высшему:

      (самый низкий) drsn.routine
                drsn.priority
                drsn.immediate
                drsn.flash
                drsn.flash-override
      (самый высокий) drsn.flash-override-override

   Пространство имен DRSN использует алгоритм вытеснения (раздел 4.5.1).

   Пространство имен DRSN отличается в одном алгоритмическом аспекте от DSN и
   Q735 пространства имен. Поведение для 'flash-override-override'
   значение приоритета отличается от других значений. Обычно запросы делают
   не вытеснять тех, кто имеет равный приоритет, а только что прибывшие «вспышки»
   запрос override-override 'заменит другой такой же
   приоритет при нехватке ресурсов. Это также может быть
   выражается в том, что запросы "flash-override-override" защищают
   сами по себе только как «флэш-переопределение».10.4. Пространство имен "Q735"

   Q.735.3 [Q.735.3] был создан как коммерческая версия
   функционально эквивалентная спецификация DSN для многоуровневого приоритета
   и упреждение (MLPP). Пространство имен Q735 определено здесь в
   таким же образом.








Schulzrinne & Polk Standards Track [Страница 25]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   Пространство имен Q735 определяет следующие значения ресурсов, перечисленные в
   от низшего приоритета к высшему:

      (самый низкий) q735.4
                q735.3
                q735.2
                q735.1
      (высший) q735,0

   Пространство имен Q735 работает в соответствии с приоритетом
   (Раздел 4.5.1) алгоритм.

10.5. Пространство имен "ETS"

   Пространство имен ETS косвенно получило свое название от названия США.
   государственная телекоммуникационная служба, называемая "Чрезвычайная государственная служба
   Телекоммуникационная служба »(или GETS), хотя организация
   Ответственный за сервис GETS выбрал аббревиатуру ETS для своего GETS
   через IP-сервис, что означает «Экстренные телекоммуникации.
   Обслуживание".Пространство имен ETS определяет следующие значения ресурсов, перечисленные в
   от низшего приоритета к высшему:

      (самый низкий) ets.4
                ets.3
                ets.2
                ets.1
      (высший) ets.0

   Пространство имен ETS работает в соответствии с приоритетной очередью.
   алгоритм (раздел 4.5.2).

10.6. Пространство имен "WPS"

   Пространство имен WPS получило свое название от "Wireless Priority".
   Сервис », определенный в GSM и других беспроводных технологиях.

   Пространство имен WPS определяет следующие значения ресурсов, перечисленные в
   от низшего приоритета к высшему:

      (самый низкий) wps.4
                wps.3
                wps.2
                wps.1
      (самый высокий) wps.0





Schulzrinne & Polk Standards Track [Страница 26]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   Пространство имен WPS работает в соответствии с очередью приоритетов.
   алгоритм (раздел 4.5.2).

11. Соображения безопасности

11.1. Основные пометки

   Любой механизм приоритета ресурсов может быть использован для получения ресурсов и
   таким образом отказывать в обслуживании другим пользователям.Противник может взять
   через конкретный шлюз PSTN, вызвать дополнительную перегрузку во время
   чрезвычайные ситуации, влияющие на PSTN, или отказ в обслуживании законных пользователей.
   В оконечных системах SIP, таких как IP-телефоны, этот механизм может
   ненадлежащим образом завершать существующие сеансы и вызовы.

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

   Ниже мы описываем аспекты аутентификации и авторизации.
   требования конфиденциальности и конфиденциальности, защита от отказа-
   служебные атаки и требования анонимности. Естественно,
   применяется общее обсуждение в RFC 3261 [RFC3261].

   Все пользовательские агенты и прокси-серверы, поддерживающие это расширение, ДОЛЖНЫ
   реализовать SIP через TLS [RFC3546], схему URI «sips», как описано
   в разделе 26.2 RFC 3261 и Digest Authentication [RFC2617] как
   описано в разделе 22 RFC 3261. Кроме того, пользовательские агенты,
   поддерживать это расширение СЛЕДУЕТ также реализовать S / MIME [RFC3851] как
   описано в Разделе 23 RFC 3261, чтобы разрешить подписывание и
   проверка подписей над запросами, использующими это расширение.

11.2. Аутентификация и авторизация

   Приоритетный доступ к сетевым ресурсам и ресурсам конечной системы требует
   особо строгие требования к аутентификации и
   механизмы авторизации, поскольку доступ к приоритетным ресурсам может
   влияют на общую стабильность и производительность системы, а не только на результат
   в краже, скажем, единственного телефонного звонка.При определенных аварийных условиях сетевая инфраструктура,
   включая его механизм аутентификации и авторизации, может быть
   под атакой.




Schulzrinne & Polk Standards Track [Страница 27]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   Учитывая срочность чрезвычайных ситуаций, обычное статистическое мошенничество
   обнаружение может быть менее эффективным, поэтому ставка делается на надежные
   аутентификация.

   Применяются общие требования к механизмам аутентификации, такие как
   устойчивость к атакам повтора, вырезания и вставки и понижения ставки.Аутентификация МОЖЕТ быть основана на SIP или использует другие механизмы. Использование
   Дайджест-аутентификация и / или S / MIME РЕКОМЕНДУЕТСЯ для UAS
   аутентификация. Дайджест-аутентификация требует, чтобы стороны
   имеют общий секрет, тем самым ограничивая его использование в административных
   домены. SIP-системы, использующие приоритет ресурсов, ДОЛЖНЫ реализовывать
   S / MIME, по крайней мере, для целостности, как описано в Разделе 23
   [RFC3261]. Однако в некоторых средах получение подтвержденного
   идентификация [RFC3325] от доверенного объекта может быть достаточной
   авторизация.Раздел 5 описывает стороннюю аутентификацию.

   Авторизация на основе признаков [TRAIT] "влечет за собой утверждение
   служба авторизации атрибутов, связанных с идентичностью »и
   может подойти для этого приложения. На основе черт
   авторизации сетевой элемент может напрямую определить,
   проверяя сертификат, что запрос уполномочен на получение
   особый тип сервиса, без необходимости обращаться к карте
   механизм, преобразующий идентификаторы пользователей в авторизации.Авторизация может быть основана на других факторах, помимо личности
   вызывающий абонент, например, запрошенный пункт назначения. Пространства имен МОГУТ также
   предъявлять особые требования к аутентификации или авторизации, которые
   являются более строгими, чем базовый уровень, описанный здесь.

11.3. Конфиденциальность и честность

   Вызовы, использующие повышенные уровни приоритета ресурсов, предоставляемые
   Поле заголовка Resource-Priority может быть чувствительным и часто
   необходимо защитить от перехвата и переделки. Особенно,
   требования по защите конфиденциальности сообщений
   отношения могут быть выше, чем у обычных коммерческих услуг.Для SIP: заголовки «Кому», «От», «Организация» и «Тема».
   поля являются примерами особо конфиденциальной информации. Системы
   ДОЛЖЕН реализовывать шифрование на транспортном уровне с использованием TLS и МОЖЕТ
   реализовать другие механизмы безопасности транспортного или сетевого уровня.
   UAC ДОЛЖНЫ использовать URI "sips" для запроса безопасного транспорта.
   связь с местом назначения.

   Поле заголовка Resource-Priority может передаваться в SIP.
   заголовок сообщения или может быть инкапсулирован во фрагмент сообщения, переносимый
   в теле сообщения SIP [RFC3420].Считаться действительным
   аутентификация для целей данной спецификации, с подписью S / MIME



Schulzrinne & Polk Standards Track [Страница 28]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   Сообщения или фрагменты SIP ДОЛЖНЫ содержать как минимум Дата, Кому,
   Поля заголовка From, Call-ID и Resource-Priority. Инкапсуляция в
   Части тела S / MIME позволяют пользователю защитить это поле заголовка
   от проверки или модификации через доверенных лиц.Однако во многих
   случаях прокси должны будут аутентифицировать и авторизовать запрос,
   поэтому инкапсуляция нежелательна.

   Удаление поля заголовка Resource-Priority или понижение его
   приоритетное значение не дает дополнительных возможностей противнику,
   поскольку этот человек посередине мог просто упасть или иначе
   аннулировать запрос SIP и, таким образом, предотвратить завершение вызова.

   Только элементы SIP в пределах одного административного доверенного домена
   использование безопасного канала между их элементами SIP будет доверять
   Поле заголовка Resource-Priority не подписано должным образом.Другим потребуется аутентифицировать запрос независимо. Таким образом,
   вставка поля заголовка Resource-Priority или обновление
   значение приоритета не имеет дополнительных последствий для безопасности, кроме
   запрос не выполняется (см. обсуждение в предыдущем абзаце).

11.4. Анонимность

   Некоторые пользователи могут пожелать остаться анонимными для адресата запроса.
   Анонимность для запросов с приоритетом ресурса ничем не отличается от
   это для любого другого аутентифицированного запроса SIP. По указанным причинам
   ранее пользователи должны были аутентифицироваться по отношению к SIP
   элементы, несущие запрос, где они желают приоритет ресурса
   лечение.Аутентификация может быть основана на возможностях и номиналах,
   не обязательно их гражданское имя. Очевидно, они могут остаться анонимными.
   к месту назначения запроса, используя подтвержденную сетью личность
   и общий механизм конфиденциальности, описанный в [RFC3323].

11.5. Атаки отказа в обслуживании

   Как уже отмечалось, описанные здесь системы, вероятно, будут
   преднамеренные атаки типа «отказ в обслуживании» (DoS) во время определенных типов
   чрезвычайные ситуации. DoS-атаки могут запускаться в самой сети как
   а также о его механизме аутентификации и авторизации.Как указано,
   системы должны минимизировать количество состояний, вычислений и сети
   ресурсы, которыми может управлять неавторизованный пользователь. Система не должна
   усиление атак, вызывая передачу более одного пакета
   на сетевой адрес, доступность которого не проверена.









Schulzrinne & Polk Standards Track [Страница 29]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


12. Вопросы IANA

12.1. Введение

   В этом разделе определены два новых заголовка SIP (раздел 12.2), один SIP
   тег опции (раздел 12.3), один новый код ошибки 4xx (раздел 12.4),
   новый реестр в разделе sip-параметров IANA for Resource-
   Приоритетные пространства имен (раздел 12.5) и новый реестр в
   раздел sip-parameters IANA для приоритетов ресурсов и приоритетов
   значения (раздел 12.6).

   Дополнительные пространства имен и значения приоритета ДОЛЖНЫ быть зарегистрированы с
   IANA, как описано в разделе 9.

   Процесс изменения SIP [RFC3427] устанавливает политику для
   регистрация новых заголовков расширения SIP.Приоритет ресурсов
   пространства имен и значения приоритета имеют аналогичное взаимодействие
   требования к заголовкам расширения SIP. Как следствие,
   регистрация новых пространств имен приоритета ресурсов и значений приоритета
   требуется документация в RFC с использованием утверждения заголовка расширения
   процесс, указанный в RFC 3427.

   Политики регистрации для новых пространств имен определены в Разделе 9.

12.2. Регистрация IANA «Resource-Priority» и «Accept-Resource-
       Поля заголовка Priority '

   Ниже приведена регистрация заголовка «Приоритет ресурса».
   поле:

   Номер RFC: 4412
   Название заголовка: "Приоритет ресурса"
   Компактная форма: нет

   Ниже приводится регистрация для «Принять-ресурс-приоритет».
   поле заголовка:

   Номер RFC: 4412
   Имя заголовка: Accept-Resource-Priority
   Компактная форма: нет











Schulzrinne & Polk Standards Track [Страница 30]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


12.3. Регистрация IANA для приоритета ресурса Option Tag

   Номер RFC: 4412
   Имя тега опции: 'приоритет-ресурс'
   Описательный текст: указывает или запрашивает поддержку для ресурса.
      механизм приоритета.

12.4. Регистрация IANA для кода ответа 417

   Номер RFC: 4412
   Код ответа: 417
   Фраза причины по умолчанию: Неизвестный приоритет ресурса

12.5. Регистрация пространства имен с приоритетом ресурсов IANA

   Новый реестр («Пространства имен приоритетов ресурсов») в sip-параметрах.
   был создан раздел IANA, имеющий форму, аналогичную этой таблице
   ниже:

                         Предусмотрено Новое предупреждение - Новое соотв.Уровни пространства имен Код кода алгоритма Ссылка
   --------- ------ ---------------- --------- --------- - --------
      приоритетное обслуживание dsn 5 нет нет [RFC4412]

      drsn 6 premption no no [RFC4412]

      q735 5 приоритетное обслуживание нет нет [RFC4412]

      ets 5 queue no no [RFC4412]

      wps 5 очередь нет нет [RFC4412]

   Легенда
   ------
   Пространство имен Уникальная строка, определяющая пространство имен.Уровни Количество значений приоритета в пространстве имен.
   Алгоритм Предполагаемое рабочее поведение SIP-элементов
                    реализация этого пространства имен.
   Новый код предупреждения Новые коды предупреждений (коды предупреждений), представленные
                    это пространство имен.
   New Resp. code Новые коды ответов SIP, представленные этим пространством имен.
   Ссылка Ссылка на документ IETF для этого пространства имен.









Schulzrinne & Polk Standards Track [Страница 31]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


12.6. Приоритетные регистрации IANA

   Новый реестр ("Значения приоритета ресурсов") в sip-
   был создан раздел параметров IANA, имеющий форму, аналогичную
   эта таблица ниже:

   Пространство имен: drsn
   Ссылка: RFC 4412
   Значения приоритета (от наименьшего к наибольшему): «рутина», «приоритет»,
      "немедленный", "вспышка", "переопределение вспышки", "переопределение вспышки"

   Пространство имен: dsn
   Ссылка: RFC 4412
   Значения приоритета (от наименьшего к наибольшему): «рутина», «приоритет»,
      "немедленный", "вспышка", "устранение вспышки"

   Пространство имен: q735
   Ссылка: RFC 4412
   Значения приоритета (от меньшего к большему): «4», «3», «2», «1», «0».

   Пространство имен: ets
   Ссылка: RFC 4412
   Значения приоритета (от меньшего к большему): «4», «3», «2», «1», «0».

   Пространство имен: wps
   Ссылка: RFC 4412
   Значения приоритета (от меньшего к большему): «4», «3», «2», «1», «0».

13.Благодарности

   Бен Кэмпбелл, Кен Карлберг, Пол Кизиват, Рохан Мэхи, Эллисон Манкин,
   Ксавьер Маржу, Пирс О'Хэнлон, Майк Пирс, Самир Шривастава и
   Дейл Уорли предоставил полезные комментарии.

   Дин Уиллис очень помог в этом деле.

   Мартин Долли, Ан Нгуен и Ниранджан Сандесара помогали с ETS
   и пространства имен WPS.

   Джанет Ганн помогла улучшить текст по приоритету на основе очередей.











Schulzrinne & Polk Standards Track [Страница 32]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


14.Ссылки

14.1. Нормативные ссылки

   [I.255.3] Международный союз электросвязи, "Интегрированный
              Цифровая сеть услуг (ISDN) - Общая структура и
              Возможности обслуживания - многоуровневый приоритет и
              Упреждение ", Рекомендация I.255.3, июль 1990 г.

   [Q.735.3] Международный союз электросвязи, "Этап 3
              описание для сообщества по интересам дополнительно
              услуги с использованием Системы сигнализации № 7: Многоуровневые
              приоритет и приоритет », Рекомендация Q.735,3,
              Март 1993 г.

   [RFC2119] Брэднер, С. "Ключевые слова для использования в RFC для обозначения
              Уровни требований », BCP 14, RFC 2119, март 1997 г.

   [RFC2434] Нартен, Т. и Х. Альвестранд, "Рекомендации по написанию
              Раздел соображений IANA в RFC », BCP 26, RFC 2434,
              Октябрь 1998 г.

   [RFC3261] Розенберг, Дж., Шульцринн, Х., Камарилло, Г., Джонстон,
              А., Петерсон, Дж., Спаркс, Р., Хэндли, М. и Э.
              Школьник, "SIP: протокол инициации сеанса", RFC 3261,
              Июнь 2002 г.[RFC3262] Розенберг, Дж. И Х. Шульцринн, "Надежность
              Предварительные ответы в протоколе инициации сеанса
              (SIP) ", RFC 3262, июнь 2002 г.

   [RFC3265] Roach, A.B., "Протокол инициации сеанса (SIP) - специфический
              Уведомление о событии », RFC 3265, июнь 2002 г.

   [RFC3311] Розенберг, Дж., "Протокол инициации сеанса (SIP)
              UPDATE Method », RFC 3311, октябрь 2002 г.

   [RFC3420] Sparks, R., "Internet Media Type message / sipfrag", RFC
              3420, ноябрь 2002 г.[RFC3428] Кэмпбелл, Б., Розенберг, Дж., Шульцринн, Х., Хайтема, К.,
              и Д. Гурл, "Расширение протокола инициации сеанса (SIP)"
              для обмена мгновенными сообщениями », RFC 3428, декабрь 2002 г.

   [RFC4411] Полк, Дж., "Расширение протокола инициации сеанса (SIP)"
              Заголовок причины для событий вытеснения », RFC 4411, февраль
              2006 г.




Schulzrinne & Polk Standards Track [Страница 33]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


14.2. Информативные ссылки

   [RFC2617] Фрэнкс, Дж., Халлам-Бейкер, П., Хостетлер, Дж., Лоуренс, С.,
              Лич П., Луотонен А. и Л. Стюарт, HTTP
              Аутентификация: базовая и дайджест-проверка подлинности »,
              RFC 2617, июнь 1999 г.

   [RFC2976] Донован С., «Метод SIP INFO», RFC 2976, октябрь
              2000 г.

   [RFC3323] Петерсон, Дж., "Механизм конфиденциальности для сеанса
              Протокол инициации (SIP) », RFC 3323, ноябрь 2002 г.

   [RFC3325] Дженнингс, К., Петерсон, Дж. И М. Уотсон, "Частный
              Расширения протокола инициации сеанса (SIP) для
              Подтвержденная идентификация в надежных сетях », RFC 3325,
              Ноябрь 2002 г.

   [RFC3427] Манкин, А., Брэднер, С., Мэхи, Р., Уиллис, Д., Отт, Дж.,
              и Б. Розен, "Процесс изменения для инициирования сеанса.
              Протокол (SIP) », BCP 67, RFC 3427, декабрь 2002 г.

   [RFC3487] Шульцринн, Х., «Требования к приоритету ресурсов.
              Механизмы протокола инициации сеанса (SIP) », RFC
              3487, февраль 2003 г.[RFC3515] Спаркс, Р., "Протокол инициации сеанса (SIP) См.
              Метод », RFC 3515, апрель 2003 г.

   [RFC3546] Блейк-Уилсон, С., Нистром, М., Хопвуд, Д., Миккельсен, Дж.,
              и Т. Райт, "Безопасность транспортного уровня (TLS)"
              Расширения ", RFC 3546, июнь 2003 г.

   [RFC3550] Шульцринн, Х., Каснер, С., Фредерик, Р. и В.
              Якобсон, "RTP: транспортный протокол для реального времени
              Приложения », STD 64, RFC 3550, июль 2003 г.

   [RFC3665] Джонстон А., Донован, С., Спаркс, Р., Каннингем, К., и
              К. Саммерс, "Базовый вызов протокола инициации сеанса (SIP)"
              Примеры потоков », BCP 75, RFC 3665, декабрь 2003 г.

   [RFC3851] Рамсделл Б., "Безопасная / многоцелевая Интернет-почта.
              Расширения (S / MIME) Версия 3.1 Спецификация сообщений ",
              RFC 3851, июль 2004 г.

   [RFC3893] Петерсон, Дж., "Протокол инициации сеанса (SIP)"
              Формат аутентифицированного идентификационного тела (AIB) », RFC 3893,
              Сентябрь 2004 г.Schulzrinne & Polk Standards Track [Страница 34]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


   [RFC3903] Ниеми, А., "Расширение протокола инициации сеанса (SIP)"
              для публикации состояния события », RFC 3903, октябрь 2004 г. для
              Публикация состояния события », RFC 3903, октябрь 2004 г.

   [TRAIT] Петерсон, Дж., Полк, Дж., Сикер, Д., и Х. Чофениг,
              "Требования к авторизации на основе характеристик для сеанса
              Протокол инициации (SIP) », Работа в процессе,
              Февраль 2005 г.Адреса авторов

   Хеннинг Шульцринне
   Колумбийский университет
   Департамент компьютерных наук
   450 корпус компьютерных наук
   Нью-Йорк, NY 10027
   НАС

   Телефон: +1212939 7004
   Электронная почта: [email protected]
   URI: http://www.cs.columbia.edu


   Джеймс Полк
   Cisco Systems
   2200 Восточная магистраль президента Джорджа Буша
   Ричардсон, Техас 75082
   НАС

   Электронная почта: [email protected]





















Schulzrinne & Polk Standards Track [Страница 35]

RFC 4412 Приоритет ресурсов SIP, февраль 2006 г.


Полное заявление об авторских правах

   Авторское право (C) The Internet Society (2006).На этот документ распространяются права, лицензии и ограничения.
   содержится в BCP 78, и, за исключением случаев, указанных в нем, авторы
   сохраняют все свои права.

   Этот документ и содержащаяся в нем информация размещены на
   Принцип «КАК ЕСТЬ» и ПОСТАВЩИК, ОРГАНИЗАЦИЯ, ПРЕДСТАВЛЯЕМЫЕ ОН / ОНА
   ИЛИ СПОНСИРУЕТСЯ (ЕСЛИ ЕСТЬ) ИНТЕРНЕТ-ОБЩЕСТВОМ И ИНТЕРНЕТОМ
   ТЕХНИЧЕСКОЕ ОБРАЗОВАНИЕ ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ,
   ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯ ГАРАНТИЮ, ЧТО ИСПОЛЬЗОВАНИЕ
   ДАННАЯ ИНФОРМАЦИЯ НЕ НАРУШАЕТ НИКАКИХ ПРАВ ИЛИ ПОДРАЗУМЕВАЕМЫХ
   ГАРАНТИИ КОММЕРЧЕСКОЙ ЦЕННОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ.Интеллектуальная собственность

   IETF не занимает никакой позиции относительно действительности или объема любых
   Права интеллектуальной собственности или другие права, которые могут быть заявлены
   относятся к реализации или использованию технологии, описанной в
   этот документ или степень, в которой любая лицензия на такие права
   может быть, а может и нет; и не означает, что
   предпринял какие-либо независимые усилия для определения любых таких прав. Информация
   о процедурах в отношении прав в документах RFC может быть
   найдено в BCP 78 и BCP 79.Копии разглашения прав интеллектуальной собственности в секретариат IETF и
   гарантии предоставления лицензий или результат
   попытка получить генеральную лицензию или разрешение на использование
   такие права собственности разработчиками или пользователями этого
   спецификацию можно получить из он-лайн репозитория IETF IPR по адресу
   http://www.ietf.org/ipr.

   IETF приглашает любую заинтересованную сторону довести до ее сведения любые
   авторские права, патенты или заявки на патенты или другие проприетарные
   права, которые могут распространяться на технологии, которые могут потребоваться для реализации
   этот стандарт.Пожалуйста, направьте информацию в IETF по адресу
   [email protected].

Подтверждение

   Финансирование функции редактора RFC обеспечивается IETF.
   Административная поддержка деятельности (IASA).







Schulzrinne & Polk Standards Track [Страница 36]

Разметка HTML, созданная rfcmarkup 1.129d, доступная по адресу
https://tools.ietf.org/tools/rfcmarkup/

RFC 3903 — Расширение протокола инициирования сеанса (SIP) для публикации состояния события

[Документы] [txt | pdf] [draft-ietf-sip-…] [Трекер] [Diff1] [Diff2]

ПРЕДЛАГАЕМЫЙ СТАНДАРТ

Сетевая рабочая группа А. Ниеми, Под ред.
Запрос комментариев: 3903 Nokia
Категория: Standards Track Октябрь 2004 г.


              Расширение протокола инициации сеанса (SIP)
                      для публикации состояния события

Статус этой памятки

   Этот документ определяет протокол отслеживания стандартов Интернета для
   Интернет-сообщество и просит обсуждения и предложения по
   улучшения.Пожалуйста, обратитесь к текущему выпуску "Интернет
   Официальные стандарты протокола »(STD 1) для состояния стандартизации
   и статус этого протокола. Распространение памятки не ограничено.

Уведомление об авторских правах

   Авторские права (C) The Internet Society (2004).

Аннотация

   Этот документ описывает расширение для инициации сеанса.
   Протокол (SIP) для публикации состояния события, используемый в событиях SIP
   фреймворк. Первое применение этого расширения предназначено для
   публикация информации о присутствии.Механизм, описанный в этом документе, может быть расширен для поддержки
   публикация любого состояния события, для которого существует соответствующий
   пакет мероприятий. Он не предназначен для использования в качестве механизма общего назначения.
   для транспортировки произвольных данных, так как есть более подходящие
   механизмы для этого.

Содержание

   1. Введение . . . . . . . . . . . . . . . . . . . . . . . . 2
   2. Определения и условные обозначения в документе. . . . . . . . . . . . 3
   3. Общая работа.. . . . . . . . . . . . . . . . . . . . 4
   4. Построение PUBLISH запросов. . . . . . . . . . . . . . . 5
        4.1. Идентификация опубликованного состояния события. . . . . . . . 6
        4.2. Создание первоначальной публикации. . . . . . . . . . . . . 7
        4.3. Обновление состояния события. . . . . . . . . . . . . . . . 8
        4.4. Изменение состояния события. . . . . . . . . . . . . . . . 9
        4.5. Удаление состояния события. . . . . . . . . . . . . . . . . 9
   5. Обработка ответов PUBLISH.. . . . . . . . . . . . . . . 10
   6. Обработка запросов PUBLISH. . . . . . . . . . . . . . . . 10
   7. Обработка запросов OPTIONS. . . . . . . . . . . . . . . . 13
   8. Использование Entity-тегов в PUBLISH. . . . . . . . . . . . . . . 13



Niemi Standards Track [Страница 1]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


        8.1. Главные примечания. . . . . . . . . . . . . . . . . . . . . 13
        8.2. Использование клиента. . . . . . . . . . . . . . . . . . . . . 14
        8.3. Использование сервера. . . . . . . . . . . . . . . . . . . . . 14
   9. Контроль скорости публикации. . . . . . . . . . . . 15
   10. Рекомендации для пакетов событий с использованием PUBLISH. . . . . . 15
        10.1. ОПУБЛИКОВАТЬ тела. . . . . . . . . . . . . . . . . . . . 16
        10.2. ОПУБЛИКОВАТЬ органы ответа. . . . . . . . . . . . . . . . 16
        10.3. Множественные источники для состояния события. . . . . . . . . . . 16
        10.4. Сегментация состояния события. . . . . . . . . . . . . . . 17
        10.5. Скорость публикации. . . . . . . . . . . . . . . . . . 17
   11. Определения элементов протокола. . . . . . . . . . . . . . . . 17
        11.1. Новые методы. . . . . . . . . . . . . . . . . . . . . . 17
              11.1.1. ОПУБЛИКОВАТЬ метод. . . . . . . . . . . . . . . . 17
        11.2. Новые коды ответов. . . . . . . . . . . . . . . . . . 19
              11.2.1. Код ответа «412 Условный запрос не выполнен» 19
        11.3. Новые поля заголовка. . . . . . . . . . . . . . . . . . 20
              11.3.1. Поле заголовка "SIP-ETag". . . . . . . . . . . 20
              11.3.2. Поле заголовка «SIP-If-Match». . . . . . . . . 20
   12. Дополненные определения BNF. . . . . . . . . . . . . . . . . 21 год
   13. Соображения IANA. . . . . . . . . . . . . . . . . . . . 21 год
        13.1. Методы. . . . . . . . . . . . . . . . . . . . . . . 21 год
        13.2. Коды ответов. . . . . . . . . . . . . . . . . . . . 21 год
        13.3. Имена полей заголовка. . . . . . . . . . . . . . . . . . 21 год
   14. Соображения безопасности. . . . . . . . . . . . . . . . . . 22
        14.1. Контроль доступа . . . . . . . . . . . . . . . . . . . . 22
        14.2. Атаки отказа в обслуживании. . . . . . . . . . . . . . 22
        14.3. Воспроизвести атаки. . . . . . . . . . . . . . . . . . . . 22
        14.4. Человек посередине атакует. . . . . . . . . . . . . . 23
        14.5. Конфиденциальность. . . . . . . . . . . . . . . . . . . 23
   15.Примеры . . . . . . . . . . . . . . . . . . . . . . . . . . 24
   16. Авторы. . . . . . . . . . . . . . . . . . . . . . . . 29
   17. Благодарности. . . . . . . . . . . . . . . . . . . . . . 30
   18. Список литературы. . . . . . . . . . . . . . . . . . . . . . . . . 30
        18.1. Нормативные ссылки . . . . . . . . . . . . . . . . . 30
        18.2. Информативные ссылки. . . . . . . . . . . . . . . . 31 год
   Адрес автора. . . . . . . . . . . . . . . . . . . . . . . . . 31 год
   Полное заявление об авторских правах.. . . . . . . . . . . . . . . . . . . . 32

1. Введение

   Эта спецификация обеспечивает основу для публикации события
   состояние от пользовательского агента до объекта, который отвечает за
   составление этого состояния события и распространение его заинтересованным
   стороны через структуру SIP Events [1].







Niemi Standards Track [Страница 2]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


   Помимо определения структуры публикации событий, это
   спецификация определяет конкретное использование этой структуры для
   публикация состояния присутствия [2] пользовательским агентом присутствия [3] в
   композитор присутствия, который тесно связан с
   агент присутствия [1].Требования и модель публикации о присутствии задокументированы в
   [10]. В данной спецификации будут рассмотрены все эти требования.

   Механизм, описанный в этом документе, может быть расширен для поддержки
   публикация любого состояния события, для которого существует соответствующий
   пакет событий, как определено в [1]. Например, приложение SIP
   события для индикаторов ожидающего сообщения [11] могут выбрать сбор
   статусы ящиков голосовой почты в наборе пользовательских агентов, использующих
   механизм ПУБЛИКАЦИЯ.Композитор в таком приложении
   затем отвечать за сбор и передачу этого состояния
   подписчики пакета мероприятий.

   Каждое приложение, использующее механизм PUBLISH в
   публикация состояния события должна соответствовать установленным правилам
   в Разделе 10. Механизм, описанный в этом документе, не
   предназначенный как универсальный механизм для транспортировки произвольных
   data, поскольку для этой цели существуют более подходящие механизмы.

2.Определения и условные обозначения в документе

   В дополнение к определениям RFC 2778 [3], RFC 3265 [1] и RFC
   3261 [4], в этом документе представлены некоторые новые концепции:

   Состояние события: информация о состоянии ресурса, связанного с
      пакет событий и адрес записи.

   Агент публикации событий (EPA): Клиент пользовательского агента (UAC), который
      выдает PUBLISH запросы на публикацию состояния события.

   Составитель состояний событий (ESC): Сервер пользовательского агента (UAS), который
      обрабатывает запросы PUBLISH и отвечает за композитинг
      состояние события в полное, составное состояние события ресурса.Составитель присутствия: тип составителя состояния события, который
      отвечает за композицию состояния присутствия для настоящего.

   Публикация: действие EPA, отправляющего запрос PUBLISH на ESC для
      опубликовать состояние события.

   Жесткое состояние события: устойчивое состояние или состояние события по умолчанию для
      ресурс, который ESC может использовать в отсутствие или дополнительно
      к, мягкие государственные публикации.



Niemi Standards Track [Страница 3]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


   Мягкое состояние события: состояние события, опубликованное EPA с помощью PUBLISH
      механизм.Элемент протокола (т. Е. Тег объекта) используется для
      идентифицировать конкретный объект мягкого состояния на ESC. Мягкое состояние имеет
      определенное время жизни и истечет после согласованного количества
      время.

   Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «НЕ ДОЛЖНЫ»,
   «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом
   документ следует интерпретировать, как описано в BCP 14, RFC 2119 [5]
   и указать уровни требований для совместимых реализаций.

      Отрывки с отступом, подобные этому, используются в этом документе для
      предоставить дополнительную информацию и поясняющий текст.Они не
      содержат описания нормативного поведения протокола.

3. Общая операция

   Этот документ определяет новый метод SIP, PUBLISH, для публикации события
   штат. ПУБЛИКАЦИЯ похожа на РЕГИСТРАЦИЮ тем, что позволяет пользователю
   создавать, изменять и удалять состояние в другом объекте, который управляет этим
   состояние от имени пользователя. Обращение к запросу PUBLISH
   идентично обращению к запросу SUBSCRIBE. Запрос-URI
   В запросе PUBLISH указывается адрес ресурса для
   который пользователь желает опубликовать состояние события.Пользователь может в свою очередь
   иметь несколько пользовательских агентов или конечных точек, которые публикуют состояние события.
   Каждая конечная точка может публиковать свое собственное уникальное состояние, из которого
   Композитор состояния события генерирует составное состояние события
   ресурс. Помимо конкретного ресурса, все опубликованные события
   состояние связано с конкретным пакетом событий. Через
   подписка на этот пакет событий, пользователь может обнаружить
   составное состояние событий всех активных публикаций.

   Клиент пользовательского агента (UAC), который публикует состояние события, помечен как
   Агент публикации событий (EPA).Для присутствия это знакомый
   Роль агента пользователя присутствия (PUA) определена в [2]. Сущность, которая
   обрабатывает запрос PUBLISH, известный как составитель состояния события
   (ESC). Для присутствия это знакомая роль агента присутствия (PA).
   как определено в [2].

   Запросы PUBLISH создают мягкое состояние в ESC. Мягкое состояние этого события
   имеет определенный срок службы и истечет после согласованного количества
   время, требующее обновления публикации последующим ПУБЛИКАЦИЕЙ
   Запросы.Также может быть предусмотрено жесткое состояние события для каждого
   ресурс для конкретного пакета событий. Это состояние события представляет
   состояние ресурса, которое присутствует постоянно и не истекает.
   ESC может использовать жесткое состояние события при отсутствии или дополнительно
   в, мягкое состояние события, обеспечиваемое механизмом PUBLISH. Настройка




Niemi Standards Track [Страница 4]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


   жесткое состояние этого события или настройка политики ESC в отношении
   агрегирование различных состояний событий выходит за рамки этого
   Технические характеристики.В теле запроса PUBLISH содержится опубликованное состояние события. В
   ответ на каждый успешный запрос PUBLISH, ESC назначает
   идентификатор публикации в виде сущности-тега. Этот
   идентификатор затем используется EPA в любом последующем запросе PUBLISH
   который изменяет, обновляет или удаляет состояние события этого
   публикация. Когда состояние события истекает или явно удаляется,
   связанный с ним объект-тег становится недействительным. Публикация для
   недопустимый тег объекта, естественно, не сработает, и EPA необходимо запустить
   заново и повторно отправить его состояние события без ссылки на предыдущий
   объект-тег.4. Создание запросов PUBLISH

   PUBLISH запрашивает создание, изменение и удаление связанного состояния события
   с адресом записи. Соответствующим образом уполномоченная третья сторона может
   также выполнять публикацию от имени конкретного адреса записи.

   Если не указано иное, построение запроса PUBLISH и
   поведение клиентов, отправляющих запрос PUBLISH, идентично
   общее поведение UAC, описанное в разделах 8.1 и 17.1 RFC
   3261 [4].

   При необходимости клиенты могут запросить поддержку PUBLISH, используя
   Запрос OPTIONS определен в SIP [4].Наличие "PUBLISH" в
   Поле заголовка "Разрешить" в ответе на запрос OPTIONS указывает
   поддержка метода PUBLISH. Кроме того, «Разрешить-События»
   поле заголовка указывает поддерживаемые пакеты событий.

      Обратите внимание, что запрос OPTIONS может быть разветвлен, и
      следовательно, вернуть ответ от пользовательского агента, кроме
      ESC. В этом случае поддержка метода PUBLISH может быть недоступна.
      соответствующим образом представлен для этого конкретного Request-URI.

   Запрос PUBLISH не устанавливает диалог.UAC МОЖЕТ включать
   Поле заголовка маршрута в запросе PUBLISH на основе уже существующего маршрута
   установить, как описано в разделе 8.1 RFC 3261 [4]. Рекорд-Маршрут
   поле заголовка не имеет значения в запросах или ответах PUBLISH, и
   ДОЛЖЕН быть проигнорирован, если он присутствует. В частности, UAC НЕ ДОЛЖЕН создавать
   новый маршрут, установленный на основе наличия или отсутствия Record-Route
   поле заголовка в любом ответе на запрос PUBLISH.

   Запрос PUBLISH МОЖЕТ содержать поле заголовка контакта, но включая
   один в запросе PUBLISH не имеет значения в публикации события
   контекст и будет игнорироваться ESC.EPA МОЖЕТ отправить ПУБЛИКАЦИЮ



Niemi Standards Track [Страница 5]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


   запрос в существующем диалоге. В этом случае запрос
   полученные в контексте любого медиа-сеанса или связанных сеансов
   с этим диалогом.

      Обратите внимание, что при отправке запроса PUBLISH в существующем
      диалог не запрещен, обычно он не приводит к
      ожидаемое поведение.Если другой конец диалога также не является
      ESC, вероятно, он отклонит запрос.

   EPA НЕ ДОЛЖНЫ отправлять новый запрос PUBLISH (не повторную передачу) для
   тот же Request-URI, пока они не получат окончательный ответ от
   ESC для предыдущего или предыдущего запроса PUBLISH имеет
   время вышло.

4.1. Идентификация опубликованного состояния события

   Идентификация опубликованного состояния события обеспечивается тремя частями
   информации: Request-URI, тип события и (необязательно) объект-
   тег.Request-URI запроса PUBLISH содержит достаточно информации для
   направить запрос соответствующему объекту в соответствии с маршрутизацией запроса
   процедуры, описанные в RFC 3261 [4]. Он также содержит достаточно
   информация для идентификации ресурса, состояние события которого должно быть
   опубликовано, но недостаточно информации для определения типа
   опубликованное состояние события.

   Для определения типа опубликованного состояния события EPA ДОЛЖНО
   включать одно поле заголовка события в запросы PUBLISH.Значение
   этого поля заголовка указывает пакет событий, для которого это
   запрос публикует состояние события.

   Для каждого успешного запроса PUBLISH ESC будет генерировать и назначать
   объект-тег и вернуть его в поле заголовка SIP-ETag 2xx
   ответ.

   При обновлении ранее опубликованного состояния события запросы ПУБЛИКАЦИИ ДОЛЖНЫ
   содержать одно поле заголовка SIP-If-Match, определяющее конкретный
   состояние события, что запрос обновляется, изменяет или удаляет.
   Это поле заголовка ДОЛЖНО содержать единственный тег объекта, который был возвращен
   ESC в поле заголовка SIP-ETag ответа на предыдущий
   публикация.Запрос PUBLISH МОЖЕТ содержать тело, которое содержит состояние события.
   что клиент желает опубликовать. Формат и семантика контента
   зависят от пакета событий, указанного в заголовке события
   поле.




Niemi Standards Track [Страница 6]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


   Наличие тела и поля заголовка SIP-If-Match определяют
   конкретная операция, которую выполняет запрос, как описано
   в таблице 1.+ ----------- + ------- + --------------- + ------------- - +
      | Операция | Тело? | SIP-If-Match? | Срок действия истекает |
      + ----------- + ------- + --------------- + ------------- - +
      | Начальная | да | нет | > 0 |
      | Обновить | нет | да | > 0 |
      | Изменить | да | да | > 0 |
      | Удалить | нет | да | 0 |
      + ----------- + ------- + --------------- + ------------- - +

                 Таблица 1: Операции публикации

   «Начальная» публикация устанавливает начальное состояние события для
   конкретное EPA.Конечно, может уже быть состояние события
   опубликовано другими EPA (по тому же адресу регистрации). Это состояние
   первоначальная публикация не влияет. Публикация "Обновить"
   обновляет время жизни предыдущей публикации, тогда как «Изменить»
   публикация изменяет состояние события предыдущей публикации. А
   Публикация «Удалить» требует немедленного удаления состояния события.
   Эти операции описаны более подробно в следующих
   разделы.

4.2. Создание первоначальной публикации

   Первоначальная публикация - это запрос PUBLISH, созданный EPA и
   отправляется на ESC, который устанавливает мягкое состояние для пакета событий
   указан в поле заголовка события запроса и привязан к
   адрес в Request-URI запроса.Первоначальный запрос PUBLISH НЕ ДОЛЖЕН содержать заголовок SIP-If-Match.
   поле. Однако, если EPA ожидает соответствующего, хранящегося на месте
   entity-tag по-прежнему действителен, СЛЕДУЕТ сначала попытаться изменить это
   состояние события, как описано в Разделе 4.4, вместо отправки
   первоначальная публикация.

   Первоначальный запрос PUBLISH ДОЛЖЕН содержать тело, которое содержит
   опубликованное состояние события.

   Первоначальный запрос PUBLISH МОЖЕТ содержать одно поле заголовка Expires.
   Это значение указывает предполагаемое время жизни состояния события.
   публикация.Niemi Standards Track [Страница 7]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


   ESC может снизить предполагаемый срок службы публикации, но он
   никогда не продлят. Если поле заголовка Expires отсутствует,
   EPA указывает на свое желание ESC выбирать. Истекает
   поле заголовка в ответе 2xx на начальную PUBLISH указывает
   фактическая продолжительность, в течение которой публикация будет оставаться активной.Если только
   обновлено до истечения этого срока, публикация будет
   истек.

4.3. Обновление состояния события

   EPA несет ответственность за обновление ранее установленных
   публикации до истечения срока их действия. Чтобы
   обновить публикацию, EPA ДОЛЖНО создать запрос PUBLISH, который
   включает в поле заголовка SIP-If-Match тег объекта
   публикация подлежит обновлению.

   Поле заголовка SIP-If-Match, содержащее тег объекта, определяет условия
   PUBLISH запрос на обновление состояния определенного события, установленного
   предварительная публикация.Если объект-тег соответствует ранее опубликованному
   состояние события на ESC, обновление завершается успешно, и EPA получает сообщение
   2хх ответ.

   Как и ответ 2xx на начальный запрос PUBLISH, ответ 2xx
   для обновления запроса PUBLISH будет содержать поле заголовка SIP-ETag
   с тегом объекта. EPA ДОЛЖНО сохранить этот тег объекта, заменив
   любой существующий тег объекта для обновленного состояния события. См. Раздел
   8.2 для получения дополнительной информации об обработке EPA тегов объектов.

   Если нет соответствующего состояния события, e.g., состояние события должно быть
   обновленный уже истек, EPA получает 412 (условный
   Request Failed) ответ на запрос PUBLISH.

   Обновление публикации МОЖЕТ содержать одно поле заголовка Expires.
   Это значение указывает предполагаемое время жизни состояния события.

   ESC может снизить предлагаемый срок действия обновления публикации,
   но это никогда не продлит его. Если в поле заголовка Expires нет
   В настоящее время EPA заявляет о своем желании сделать выбор ESC. В
   Поле заголовка Expires в ответе 2xx на обновление публикации
   указывает фактический срок, в течение которого будет оставаться публикация
   активный.Обновление публикации только продлевает срок действия уже
   существующее состояние события. Это не влияет на состояние события ни в каком
   другой путь. Следовательно, запрос PUBLISH, который обновляет состояние события
   НЕ ДОЛЖНЫ иметь тело.





Niemi Standards Track [Страница 8]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


4.4. Изменение состояния события

   Изменение состояния события очень похоже на создание начального события
   штат.Однако вместо того, чтобы устанавливать совершенно новое состояние события
   на ESC уже существующее состояние события обновляется измененным
   состояние события. Характер этого обновления зависит от содержания
   body и семантика, связанная с форматом этого тела.

   Чтобы изменить состояние события, EPA ДОЛЖНО создать запрос PUBLISH, который
   включает в поле заголовка SIP-If-Match тег объекта события
   государственное издание подлежит изменению. Запрос PUBLISH, изменяющий
   состояние события ДОЛЖНО содержать тело, которое включает измененное событие
   штат.Поле заголовка SIP-If-Match обуславливает выполнение запроса PUBLISH.
   изменить состояние конкретного события, установленное в предыдущей публикации, и
   идентифицируется тегом объекта. Если объект-тег соответствует ранее
   опубликованное состояние события на ESC, это состояние события заменяется на
   состояние события передается в запросе PUBLISH, и EPA получает
   2хх ответ.

   Как и ответ 2xx на начальный запрос PUBLISH, ответ 2xx
   к изменяющему запросу PUBLISH будет содержаться поле заголовка SIP-ETag
   с тегом объекта.EPA ДОЛЖНО сохранить этот тег объекта, заменив
   любой существующий тег объекта для измененного состояния события. См. Раздел
   8.2 для получения дополнительной информации об обработке EPA тегов объектов.

   Если на ESC нет соответствующего состояния события, например, состояние события
   срок действия доработки уже истек, EPA получает 412
   (Ошибка условного запроса) ответ на запрос PUBLISH.

   Изменяющий запрос PUBLISH МОЖЕТ содержать один заголовок Expires.
   поле. Это значение указывает предполагаемое время жизни события.
   государственное издание.ESC может снизить предполагаемый срок службы публикации, но он
   никогда не продлят. Если поле заголовка Expires отсутствует,
   EPA указывает на свое желание ESC выбирать. Истекает
   поле заголовка в ответе 2xx на модифицирующий запрос PUBLISH
   указывает фактический срок, в течение которого будет оставаться публикация
   активный. Если не обновить до истечения этого срока службы,
   срок публикации истекает.

4.5. Удаление состояния события

   Состояние события, установленное предыдущей публикацией, также может быть явно
   удалено.Niemi Standards Track [Страница 9]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


   Чтобы запросить немедленное удаление состояния события, EPA ДОЛЖНО создать
   PUBLISH со значением Expires, равным «0», и установите SIP-If-
   Поле заголовка совпадения, содержащее тег объекта состояния события
   публикация будет удалена.

      Обратите внимание, что удаление состояния события фактически является публикацией
      обновить, предлагая бесконечно малый интервал истечения срока.Следовательно, обновленное состояние события истекает сразу после
      освежается.

   Подобно обновлению состояния события, удаление только состояния события
   влияет на истечение срока действия состояния события. Следовательно, запрос PUBLISH
   который удаляет состояние события, НЕ ДОЛЖЕН содержать тело.

5. Обработка ответов PUBLISH

   При обработке ответов на запросы PUBLISH, шаги в Разделе
   Применяется 8.1.2 RFC 3261 [4].

   Если EPA получает ответ 412 (Условный запрос не выполнен), он
   ЗАПРЕЩАЕТСЯ повторять попытку запроса PUBLISH.Вместо этого, чтобы опубликовать событие
   состоянии, EPA ДОЛЖНО выполнить первоначальную публикацию, т. е. ОПУБЛИКОВАТЬ
   запрос без поля заголовка SIP-If-Match, как описано в Разделе
   4.2. EPA также ДОЛЖНО отказаться от тега объекта, который произвел это
   ответ об ошибке.

   Если EPA получает ответ 423 (Interval Too Brief) на PUBLISH
   запрос, он МОЖЕТ повторить попытку публикации после изменения срока действия
   интервал в поле заголовка Expires должен быть больше или равен
   интервал истечения срока в поле заголовка Min-Expires
   423 (интервал слишком короткий).6. Обработка запросов PUBLISH

   Компоновщик состояний событий (ESC) - это сервер пользовательского агента (UAS), который
   обрабатывает и отвечает на запросы PUBLISH, а также поддерживает список
   публикации для данного адреса регистрации. ESC должен знать
   (например, через конфигурацию) набор адресов, для которых он
   поддерживает состояние события.

   ESC ДОЛЖЕН игнорировать поле заголовка Record-Route, если оно включено
   в запросе PUBLISH. ESC НЕ ДОЛЖЕН включать заголовок Record-Route
   в любом ответе на запрос PUBLISH.ESC ДОЛЖЕН игнорировать
   Поле заголовка контакта, если оно присутствует в запросе PUBLISH.







Niemi Standards Track [Страница 10]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


   Запросы PUBLISH с тем же Request-URI ДОЛЖНЫ обрабатываться в
   приказ, чтобы они были получены. PUBLISH запросы также ДОЛЖНЫ быть
   обрабатывается атомарно, что означает, что конкретный запрос PUBLISH
   либо полностью обработаны, либо не обработаны совсем.При получении запроса PUBLISH ESC выполняет шаги, определяющие
   общее поведение UAS описано в разделе 8.2 RFC 3261 [4]. К тому же,
   для конкретного поведения ПУБЛИКАЦИЯ ESC выполняет следующие шаги:

   1. ESC проверяет Request-URI, чтобы определить,
      нацелен на ресурс, за который отвечает ESC
      поддержание состояния события. Если нет, ESC ДОЛЖЕН вернуть 404 (Not
      Найдено) и пропустите остальные шаги.

      Также может быть, что Request-URI указывает на домен, который
      ESC не несет ответственности за.В этом случае БПЛА, получающий
      запрос может взять на себя роль прокси-сервера и перенаправить
      запрос на более подходящую цель.

   2. ESC проверяет поле заголовка события запроса PUBLISH.
      Если поле заголовка события отсутствует или содержит пакет событий
      которые ESC не поддерживает, ESC ДОЛЖЕН отвечать на
      PUBLISH запрос с ответом 489 (недопустимое событие) и пропустить
      оставшиеся шаги.

   3. ESC проверяет поле заголовка SIP-If-Match сообщения PUBLISH
      запрос наличия предусловия запроса.* Если запрос не содержит поля заголовка SIP-If-Match,
         ESC ДОЛЖЕН сгенерировать и сохранить локально уникальный объект-тег для
         идентификация публикации. Этот объект-тег связан
         с состоянием события, перенесенным в теле ПУБЛИКАЦИИ
         запрос.

      * В противном случае, если запрос имеет поле заголовка SIP-If-Match, ESC
         проверяет, содержит ли поле заголовка единственный объект-тег.
         В противном случае запрос недействителен, и ESC ДОЛЖЕН вернуться с
         400 (недопустимый запрос) и пропустите оставшиеся шаги.* В противном случае ESC извлекает тег объекта, содержащийся в SIP-If-
         Сопоставить поле заголовка и сопоставить этот тег объекта со всеми
         локально хранимые теги сущностей для этого ресурса и пакета событий.
         Если совпадений не найдено, ESC ДОЛЖЕН отклонить публикацию с
         ответ 412 (сбой условного запроса) и пропустите
         оставшиеся шаги.






Niemi Standards Track [Страница 11]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


   4.ESC обрабатывает значение поля заголовка Expires из PUBLISH
      запрос.

      * Если запрос имеет поле заголовка Expires, это значение ДОЛЖНО быть
         считается запрошенным сроком действия.

      * В противном случае в качестве значения ДОЛЖНО использоваться локально настроенное значение по умолчанию.
         запрошенный срок.

      * ESC МОЖЕТ выбрать срок действия меньше запрошенного
         срок годности. Только если запрошенный интервал истечения
         больше нуля и меньше локально настроенного
         минимум, ESC МОЖЕТ отклонить публикацию с ответом
         423 (Слишком короткий интервал) и пропустите оставшиеся шаги.Этот
         ответ ДОЛЖЕН содержать поле заголовка Min-Expires, в котором указано
         минимальный интервал истечения срока, который ESC желает соблюдать.

   5. ESC обрабатывает опубликованное состояние события, содержащееся в теле.
      запроса PUBLISH. Если тип содержимого запроса
      не соответствует пакету событий или не понимается ESC,
      ESC ДОЛЖЕН отклонить запрос с соответствующим ответом, например
      415 (неподдерживаемый тип носителя) и пропустите остальные шаги.* ESC сохраняет состояние события, доставленное в теле сообщения.
         PUBLISH запрос и идентифицирован соответствующим тегом объекта,
         обновление любого существующего состояния события для этого тега объекта. В
         значение срока действия устанавливается равным выбранному интервалу срока действия.

      * Если запрос не имеет тела сообщения и не содержит тега объекта,
         ESC СЛЕДУЕТ отклонить запрос с соответствующим ответом,
         например 400 (недопустимый запрос), и пропустите оставшуюся часть
         шаги.В качестве альтернативы, если локальная политика ESC или
         пакет событий определил семантику для первоначальной публикации
         не содержащий тела сообщения, ESC МОЖЕТ принять его.

      * В противном случае состояние события, идентифицированное тегом объекта, является
         обновлен, установив значение срока действия для выбранного
         срок годности.

      * Если для выбранного интервала истечения задано специальное значение «0»,
         состояние события, идентифицированное тегом объекта, ДОЛЖНО быть
         сразу удалил.ESC НЕ ДОЛЖЕН сохранять какое-либо состояние события как
         результат такого запроса.








Niemi Standards Track [Страница 12]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.

Обработка запроса PUBLISH ДОЛЖНА быть атомарной. Если внутренний
возникают ошибки (например, невозможность доступа к серверной базе данных)
до завершения обработки публикация НЕ ДОЛЖНА быть успешной,
и ESC ДОЛЖЕН выйти из строя с соответствующим ответом об ошибке, например
504 (тайм-аут сервера) и пропустите последний шаг.6. ESC возвращает ответ 200 (OK). Ответ ДОЛЖЕН содержать
Поле заголовка Expires, указывающее интервал истечения срока, выбранный
ESC. Ответ ДОЛЖЕН также содержать поле заголовка SIP-ETag.
который содержит один тег объекта, идентифицирующий публикацию.
ESC ДОЛЖЕН генерировать новый тег объекта для каждого успешного
публикация, заменяющая любой предыдущий тег объекта, связанный с
это состояние события. Сгенерированный тег объекта ДОЛЖЕН быть уникальным среди любых
другие теги объекта, назначенные в настоящее время для связанного состояния события
с этим Request-URI, и ДОЛЖЕН отличаться от любого объекта-тега
присвоенный ранее состоянию события для этого Request-URI.Увидеть
Раздел 8.3 для получения дополнительной информации об обработке ESC объекта.
теги.

7. Обработка запросов OPTIONS

Клиент может проверить ESC для поддержки PUBLISH, используя
Запрос OPTIONS определен в SIP [4]. ESC обрабатывает ОПЦИИ
запросы, как определено в разделе 11.2 RFC 3261 [4]. В ответ
к запросу OPTIONS, ESC ДОЛЖЕН включать "PUBLISH" в список
разрешенных методов в поле заголовка Разрешить. Кроме того, СЛЕДУЕТ перечислить
поддерживаемые пакеты событий в поле заголовка Allow-Events.Поле заголовка Разрешить также может использоваться для специального объявления
поддержка PUBLISH сообщений при регистрации. (См. Возможности SIP
[12] для подробностей).

8. Использование Entity-тегов в PUBLISH

В этом разделе дается общий обзор использования тегов сущностей в
ПУБЛИКОВАТЬ. Он носит информативный характер и поэтому не содержит нормативных документов.
описание протокола.

8.1. Главные примечания

Механизм PUBLISH использует теги сущностей, как определено в HTTP /
1.1 [13]. Хотя основные функции сохранены, синтаксис и
семантика для тегов сущностей и соответствующих полей заголовков
адаптировано специально для использования с методом PUBLISH.Главный
отличия:

o Синтаксис для тегов сущностей - это токен, а не строка в кавычках.
Также не определен префикс для указания слабого тега объекта.

Niemi Standards Track [Страница 13]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


   o Предварительное условие PUBLISH может применяться только к одному объектному тегу, поэтому
      предварительные условия запроса с несколькими тегами сущностей не допускаются.

   o Предварительное условие запроса не может применяться к "любому" объекту, а именно к нему
      не является специальным значением тега объекта "*", определенным для PUBLISH.o В то время как в HTTP / 1.1 возврат тега объекта не является обязательным для origin
      серверы в PUBLISH ESC должны всегда возвращать объект -
      тег для успешной публикации.

   Основная мотивация для вышеупомянутой адаптации заключается в том, что ПУБЛИКАЦИЯ - это
   концептуально HTTP PUT, для которого только часть функций в
   проверка кеша с использованием сущностей-тегов разрешена в HTTP / 1.1. Это делает
   мало смысла включать функции, отличные от этого подмножества, для события
   государственное издание.

   Чтобы было очевидно, что использование тегов объектов в PUBLISH похоже
   но не идентичен HTTP / 1.1, мы не приняли поле заголовка
   имена прямо из HTTP / 1.1, а создали похожие, но
   различные имена, как можно увидеть в Разделе 11.

8.2. Использование клиента

   Каждой успешной публикации будет присвоен тег объекта, который
   затем доставляется в EPA в ответ на запрос PUBLISH.
   Агентству по охране окружающей среды необходимо сохранить этот тег объекта, заменив все предыдущие
   entity-tag для этого состояния события. Если запрос не выполняется с ошибкой 412
   (Ошибка условного запроса), EPA отклоняет объект -
   тег, вызвавший сбой.Сущности-теги - это непрозрачные токены для EPA. EPA не может делать никаких выводов
   дальнейшая семантика от объекта-тега помимо простого идентификатора, или
   предполагают определенное форматирование. Объект-тег может быть монотонно
   увеличивающийся счетчик, но это также может быть совершенно случайный жетон. это
   вплоть до реализации ESC относительно того, какое форматирование объекта -
   тег есть.

8.3. Использование сервера

   Сущности-теги создаются и поддерживаются ESC. Они часть
   состояния, поддерживаемого ESC, которое также включает фактические
   состояние события и оставшийся срок его действия.Тег объекта
   генерируется и сохраняется для каждой успешной публикации состояния события, и
   вернулся в EPA в ответе 200 (ОК). Состояние каждого события
   публикация EPA, обновляющая предыдущую публикацию, будет
   включить тег объекта, который ESC может использовать в качестве ключа поиска в наборе
   активных публикаций.




Niemi Standards Track [Страница 14]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


   Способ создания тега объекта - это реализация
   решение.Один из возможных способов создания тега объекта - реализовать
   это как целочисленный счетчик, который увеличивается на единицу для каждого
   успешно обработанная публикация. Другие, не менее действенные способы
   генерирующие теги сущностей существуют, и в этом документе нет
   рекомендации или предпочтение одного пути.

9. Контроль скорости публикации

   Как субъект, ответственный за агрегирование информации о состоянии из
   потенциально много источников, ESC может подвергаться значительным
   объемы публикаций.Есть способы уменьшить сумму
   запросов PUBLISH, которые ESC получает:

   o Выбор срока действия публикации может быть
      затронутый ESC. Он может настаивать на том, чтобы EPA выбрало более длительный
      значение истечения срока до того, что он предлагает, в случае, если локальный ESC
      значение минимального срока действия по умолчанию не достигнуто. Поддержание
      более длительное значение минимального срока действия по умолчанию на ESC снижает
      скорость обновления публикаций.

   o Еще один способ уменьшить трафик публикации - использовать SIP-уровень
      push-back, чтобы подавить определенный источник трафика публикации.Чтобы
      оттолкнуть публикации из определенного источника, ESC МОЖЕТ
      ответить на запрос PUBLISH с кодом 503 (служба недоступна), поскольку
      определено в RFC 3261 [4]. Этот ответ ДОЛЖЕН содержать Retry-
      Поле заголовка после, указывающее временной интервал, в который
      источник публикации должен дождаться отправки другого
      ОПУБЛИКОВАТЬ запрос.

   На момент написания этой спецификации работа по управлению нагрузкой в
   SIP запускается, что может предоставить дополнительные инструменты для
   управление нагрузкой в системах публикации состояний событий.10. Рекомендации для пакетов событий с использованием PUBLISH

   В этом разделе обсуждается несколько вопросов, которые следует учитывать.
   учитывать при применении механизма PUBLISH к пакетам событий.
   Он также демонстрирует, как эти проблемы решаются при использовании PUBLISH
   для публикации о наличии.

   Любая будущая спецификация пакета событий ДОЛЖНА включать обсуждение
   его рекомендации по использованию PUBLISH. Как минимум те
   соображения ДОЛЖНЫ касаться вопросов, представленных в этой главе,
   и МОЖЕТ включать дополнительные соображения.Niemi Standards Track [Страница 15]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


10.1. ОПУБЛИКОВАТЬ органы

   Тело запроса PUBLISH обычно содержит опубликованное событие.
   штат. Любое применение механизма PUBLISH для данного события
   пакет ДОЛЖЕН определять, какой тип или типы контента ожидаются в
   ОПУБЛИКОВАТЬ запросы. Каждый пакет событий ДОЛЖЕН также описывать
   семантика, связанная с этим типом контента, и ДОЛЖНА предписывать
   по умолчанию, обязательно для реализации типа MIME.Этот документ определяет семантику публикации о присутствии
   запросов (пакет событий «присутствие»), когда Общий профиль для
   Присутствие (CPP) Используется формат данных информации о присутствии (PIDF) [6].
   PUA, который использует PUBLISH для публикации состояния присутствия в PA, ДОЛЖЕН
   поддерживают формат присутствия PIDF. Он МОЖЕТ поддерживать другие форматы.

10.2. ОПУБЛИКОВАТЬ органы ответа

   Ответ на запрос PUBLISH указывает, был ли запрос
   успешно или нет. В общем, тело такого ответа будет
   пусто, если пакет событий не определяет явное значение для такого
   тело.Для тела ответа на присутствие такого значения нет.
   публикация.

10.3. Множественные источники для состояния события

   Для некоторых пакетов событий базовой моделью является модель одного
   объект, ответственный за агрегирование состояния события (ESC), и несколько
   источники, из которых только некоторые могут использовать механизм PUBLISH.

      Обратите внимание, что источники состояния события, кроме тех, которые используют
      Механизм PUBLISH явно разрешен. Однако это выходит за рамки
      объем этого документа для определения таких интерфейсов.Пакеты событий, которые используют механизм PUBLISH, ДОЛЖНЫ описывать
   применима ли эта модель для публикации состояния события, и МОЖЕТ
   описать конкретные механизмы, используемые для агрегирования публикаций из
   несколько источников.

   Что касается присутствия, PUA может публиковать состояние присутствия только для подмножества
   кортежи, которые могут быть объединены в документ присутствия, который
   наблюдатели получают в УВЕДОМЛЕНИИ. Механизм, с помощью которого ESC
   собирает эту информацию в соответствии с местной политикой и вне
   объем данной спецификации.Niemi Standards Track [Страница 16]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.

10.4. Сегментация состояния события

Для некоторых пакетов событий существует естественная декомпозиция
состояние события на сегменты. Каждый сегмент определяется как один из
потенциально много идентифицируемых разделов в опубликованном состоянии события.
Любой пакет событий, тип содержимого которого поддерживает такую сегментацию
состояние события, СЛЕДУЕТ описывать способ, которым эти состояния события
сегменты обозначаются ESC.В публикации о присутствии EPA ДОЛЖНО сохранять атрибуты id
кортежи, согласованные в контексте тега объекта. Если публикация
изменяет содержимое кортежа, этот кортеж ДОЛЖЕН поддерживать свое
оригинальный "id". ESC интерпретирует каждый кортеж в контексте
тег объекта, с которым поступил запрос. Кортеж с идентификатором
отсутствует по сравнению с исходной публикацией, будет считаться
удаляется. Точно так же кортеж интерпретируется как добавляемый, если
его атрибут "id" - тот, который не был указан в исходной публикации.
содержать.10.5. Скорость публикации

Управление скоростью публикации обсуждается в Разделе 9.
Индивидуальные пакеты мероприятий МОГУТ, в свою очередь, определять рекомендации (СЛЕДУЕТ
или ОБЯЗАНА сила) с абсолютными максимальными ставками, при которых публикации
разрешено генерировать одним EPA.

Нет никаких рекомендаций по ограничению скорости для публикации информации о присутствии.

11. Определения элементов протокола

В этом разделе описаны расширения, необходимые для публикации событий.
в SIP.

11.1. Новые методы

11.1.1. ПУБЛИКАЦИЯ Метод

«ПУБЛИКАЦИЯ» добавляется к определению элемента «Метод» в
Грамматика сообщений SIP. Как и в случае со всеми другими методами SIP, имя метода
чувствителен к регистру. PUBLISH используется для публикации состояния события в
объект, ответственный за составление этого состояния события.

Таблица 2 и Таблица 3 расширяют таблицы 2 и 3 RFC 3261 [4], добавляя
дополнительный столбец, определяющий поля заголовка, которые можно использовать в
ОПУБЛИКОВАТЬ запросы и ответы. Ключи в этих таблицах:
указано в разделе 20 RFC 3261 [4].Niemi Standards Track [Страница 17]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


   + --------------------- + --------- + --------- +
   | Поле заголовка | где | ИЗДАТЬ |
   + --------------------- + --------- + --------- +
   | Принять | R | о |
   | Принять | 2xx | - |
   | Принять | 415 | м * |
   | Принять-кодирование | R | о |
   | Принять-кодирование | 2xx | - |
   | Принять-кодирование | 415 | м * |
   | Accept-Language | R | о |
   | Accept-Language | 2xx | - |
   | Accept-Language | 415 | м * |
   | Предупреждение-Информация | | - |
   | Разрешить | R | о |
   | Разрешить | г | о |
   | Разрешить | 405 | м |
   | Allow-Events | R | о |
   | Allow-Events | 489 | м |
   | Информация об аутентификации | 2xx | о |
   | Авторизация | R | о |
   | Call-ID | c | м |
   | Телефонная информация | | о |
   | Контакты | R | - |
   | Контакты | 1xx | - |
   | Контакты | 2xx | - |
   | Контакты | 3xx | о |
   | Контакты | 485 | о |
   | Content-Disposition | | о |
   | Content-Encoding | | о |
   | Content-Language | | о |
   | Content-Length | | т |
   | Content-Type | | * |
   | CSeq | c | м |
   | Дата | | о |
   | Событие | R | м |
   | Информация об ошибке | 300-699 | о |
   | Истекает | | о |
   | Истекает | 2xx | м |
   | От | c | м |
   | In-Reply-To | R | - |
   | Макс-Форвардс | R | м |
   | Мин-истекает | 423 | м |
   | MIME-версия | | о |
   | Организация | | о |
   + --------------------- + --------- + --------- +

     Таблица 2: Сводка полей заголовка, A - O




Niemi Standards Track [Страница 18]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


   + --------------------- + ----------------- + --------- +
   | Поле заголовка | где | ИЗДАТЬ |
   + --------------------- + ----------------- + --------- +
   | Приоритет | R | о |
   | Прокси-аутентификация | 407 | м |
   | Прокси-аутентификация | 401 | о |
   | Прокси-авторизация | R | о |
   | Proxy-Require | R | о |
   | Рекорд-Маршрут | | - |
   | Ответить | | - |
   | Требовать | | о |
   | Retry-After | 404,413,480,486 | о |
   | Retry-After | 500 503 | о |
   | Retry-After | 600 603 | о |
   | Маршрут | R | c |
   | Сервер | г | о |
   | Тема | R | о |
   | Поддерживается | R | о |
   | Поддерживается | 2xx | о |
   | Отметка времени | | о |
   | К | c (1) | м |
   | Не поддерживается | 420 | о |
   | User-Agent | | о |
   | Через | R | м |
   | Через | rc | м |
   | Предупреждение | г | о |
   | WWW-аутентификация | 401 | м |
   | WWW-аутентификация | 407 | о |
   + --------------------- + ----------------- + --------- +

         Таблица 3: Сводка полей заголовка, P - Z

11.2. Новые коды ответов

11.2.1. Код ответа "412 Conditional Request Failed"

   Ответ 412 (сбой условного запроса) добавляется к
   Определение поля заголовка «Client-Error». 412 (условный запрос
   Failed) используется, чтобы указать, что предварительное условие для
   запрос не удался.











Niemi Standards Track [Страница 19]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


11.3. Новые поля заголовка

   Таблица 4, Таблица 5 и Таблица 6 расширяют Таблицу 3 в SIP [4], поскольку
   внесены изменениями в Разделе 11.1.

   + -------------- + ------- + ------- + ----- + ----- + ----- + ----- + ----- +
   | Поле заголовка | где | прокси | ACK | Пока | CAN | INF | INV |
   + -------------- + ------- + ------- + ----- + ----- + ----- + ----- + ----- +
   | SIP-ETag | 2xx | | - | - | - | - | - |
   | SIP-If-Match | R | | - | - | - | - | - |
   + -------------- + ------- + ------- + ----- + ----- + ----- + ----- + ----- +

              Таблица 4: Сводка полей заголовка, P - Z

   + -------------- + ------- + ------- + ----- + ----- + ----- + ----- + ----- +
   | Поле заголовка | где | прокси | НЕ | OPT | PRA | REG | SUB |
   + -------------- + ------- + ------- + ----- + ----- + ----- + ----- + ----- +
   | SIP-ETag | 2xx | | - | - | - | - | - |
   | SIP-If-Match | R | | - | - | - | - | - |
   + -------------- + ------- + ------- + ----- + ----- + ----- + ----- + ----- +

              Таблица 5: Сводка полей заголовка, P - Z

    + -------------- + ------- + ------- + ----- + ----- + ----- + --------- +
    | Поле заголовка | где | прокси | UPD | MSG | REF | ИЗДАТЬ |
    + -------------- + ------- + ------- + ----- + ----- + ----- + --------- +
    | SIP-ETag | 2xx | | - | - | - | м |
    | SIP-If-Match | R | | - | - | - | о |
    + -------------- + ------- + ------- + ----- + ----- + ----- + --------- +

              Таблица 6: Сводка полей заголовка, P - Z

11.3.1. Поле заголовка "SIP-ETag"

   SIP-ETag добавлен в определение элемента "general-header"
   в грамматике сообщений SIP. Использование этого заголовка описано в
   Раздел 4 и Раздел 6.

11.3.2. Поле заголовка "SIP-If-Match"

   SIP-If-Match добавлен к определению элемента "общие-
   заголовок "в грамматике сообщения SIP. Этот заголовок используется
   описано в Разделах 4 и 6.








Niemi Standards Track [Страница 20]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


12.Дополненные определения BNF

   В этом разделе описаны расширения синтаксиса, необходимые для события
   публикация в SIP. Формальные определения синтаксиса, описанные в этом
   секции представлены в формате Augmented BNF [7], используемом в SIP
   [4] и содержат ссылки на определенные в нем элементы.

      ПУБЛИКАЦИЯm =% x50.55.42.4C.49.53.48; ПУБЛИКАЦИЯ заглавными буквами.
      extension-method = PUBLISHm / токен
      SIP-ETag = "SIP-ETag" тег объекта HCOLON
      SIP-If-Match = "SIP-If-Match" тег объекта HCOLON
      entity-tag = токен

13.Соображения IANA

   Этот документ регистрирует новое имя метода, новый код ответа и
   два новых имени поля заголовка.

13.1. Методы

   В этом документе регистрируется новый метод SIP, определяемый следующим
   информация, которая была добавлена в метод и код ответа
   суб-реестр в http://www.iana.org/assignments/sip-parameters.

      Имя метода: PUBLISH
      Ссылка: [RFC3903]

13.2. Коды ответов

   В этом документе регистрируется новый код ответа. Этот код ответа
   определяется следующей информацией, которая была добавлена в
   метод и подрегистр кода ответа в
   http: // www.iana.org/assignments/sip-parameters.

      Номер кода ответа: 412
      Фраза причины по умолчанию: условный запрос не выполнен

13.3. Имена полей заголовка

   В этом документе регистрируются два новых имени поля заголовка SIP. Эти
   заголовки определяются следующей информацией, которая была
   добавлен в подрегистр заголовка под
   http://www.iana.org/assignments/sip-parameters.

      Имя заголовка: SIP-ETag
      Компактная форма: (нет)





Niemi Standards Track [Страница 21]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


      Имя заголовка: SIP-If-Match
      Компактная форма: (нет)

14.Соображения безопасности

14.1. Контроль доступа

   Поскольку состояние события может считаться конфиденциальной информацией, ESC
   должен иметь возможность выборочно принимать публикации от
   Только авторизованные источники, на основании личности EPA.

   Агент состояния ДОЛЖЕН аутентифицировать EPA и ДОЛЖЕН применять его
   политики авторизации (например, на основе списков контроля доступа) для всех
   Запросы. Модель композиции не предполагает, что все входные данные
   источники для ESC находятся в одной сети или в одной
   административный домен.ESC и EPA ДОЛЖНЫ реализовывать дайджест для аутентификации PUBLISH
   запросы, как определено в RFC 3261 [4]. Точные методы создания
   и манипулирование политиками контроля доступа в ESC находится за пределами
   объем этого документа.

14.2. Атаки отказа в обслуживании

   Создание состояния в ESC при получении запроса PUBLISH
   могут использоваться злоумышленниками для потребления ресурсов на машине жертвы,
   возможно сделать его непригодным для использования.

   Чтобы снизить вероятность такой атаки, реализации ESC
   СЛЕДУЕТ требовать аутентификации запросов PUBLISH.Реализации
   ДОЛЖЕН поддерживать дайджест-аутентификацию, как определено в RFC 3261 [4].

   Кроме того, ESC СЛЕДУЕТ ограничивать входящие публикации и
   соответствующие уведомления в результате изменений в событии
   штат. В качестве первого шага следует тщательно выбрать минимальный срок действия по умолчанию.
   значения поля заголовка для поддерживаемых пакетов событий на ESC могут
   помогите ограничить обновление состояния события.

   Дополнительная логика дросселирования и устранения дребезга на ESC рекомендуется
   еще больше уменьшить трафик уведомлений, созданный в результате
   ОПУБЛИКОВАТЬ запрос.14.3. Воспроизведение атак

   Воспроизведение запроса PUBLISH может иметь пагубные последствия. An
   злоумышленник может выполнить публикацию состояния любого события.
   был свидетелем исполнения в какой-то момент в прошлом путем воспроизведения
   этот запрос PUBLISH. Помимо прочего, такое сообщение воспроизведения может



Niemi Standards Track [Страница 22]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


   использоваться для подделки старой информации о состоянии события, хотя управление версиями
   механизм, e.g., отметка времени, информация о состоянии может помочь
   смягчить такую атаку.

   Чтобы предотвратить атаки повторного воспроизведения, реализации ДОЛЖНЫ поддерживать дайджест.
   аутентификация с защитой от воспроизведения, как определено в RFC 3261 [4].
   Дальнейшие механизмы противодействия атакам повторного воспроизведения обсуждаются в SIP.
   [4].

14.4. Человек в центре атаки

   Даже с аутентификацией атаки типа "злоумышленник посередине" с использованием PUBLISH могут
   использоваться для установки произвольной информации о состоянии события, изменения или
   удалить существующую информацию о состоянии события в публикациях или даже
   полностью удалить состояние события на ESC.Чтобы предотвратить такие атаки, реализации ДОЛЖНЫ, как минимум,
   обеспечить защиту целостности через To, From, Event, SIP-If-
   Поля заголовков Match, Route и Expires и текст PUBLISH
   Запросы.

   Если ESC получает состояние события в запросе PUBLISH, который
   целостность защищена с помощью ассоциации безопасности, которая не
   ESC (например, сквозная защита целостности от издателя
   подписчику), агент состояния вместе с ESC НЕ ДОЛЖЕН изменять
   состояние события перед тем, как раскрыть его подписчикам этого события
   указать в запросах NOTIFY.Это сделано для сохранения сквозного
   целостность состояния события.

   Для защиты целостности ESC ДОЛЖНЫ реализовывать TLS [8] и ДОЛЖНЫ
   поддерживать как взаимную, так и одностороннюю аутентификацию, а также ДОЛЖЕН поддерживать
   схема SIPS URI, определенная в SIP [4]. EPA ДОЛЖНЫ быть способны:
   инициирование TLS и ДОЛЖЕН поддерживать схему URI SIPS. ESC и EPA
   МОЖЕТ поддерживать S / MIME [9] для защиты целостности, как определено в SIP.
   [4].

14.5. Конфиденциальность

   Информация о состоянии, содержащаяся в сообщении PUBLISH, потенциально может
   содержат конфиденциальную информацию.Реализации МОГУТ шифровать такие
   информация для обеспечения конфиденциальности.

   Для обеспечения конфиденциальности ESC ДОЛЖНЫ реализовывать TLS [8], ДОЛЖНЫ
   поддерживать как взаимную, так и одностороннюю аутентификацию, а также ДОЛЖЕН поддерживать
   схема SIPS URI, определенная в SIP [4]. EPA ДОЛЖНЫ быть способны:
   инициирование TLS и ДОЛЖЕН поддерживать схему URI SIPS. ESC и EPA
   МОЖЕТ поддерживать S / MIME [9] для шифрования информации о состоянии события, поскольку
   определено в SIP [4].



Niemi Standards Track [Страница 23]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


15.Примеры

   В этом разделе показан пример использования метода PUBLISH для
   публикация документа о присутствии из пользовательского агента присутствия в
   агент присутствия. Наблюдатель в этом примере подписывается на
   информация о присутствии присутствия от PA. PUA может также
   ПОДПИСАТЬСЯ на его собственное присутствие, чтобы увидеть составное состояние присутствия
   разоблачены ПА. Это необязательный, но вероятный шаг для PUA,
   и не показан в этом примере.

   Когда значение поля заголовка Content-Length равно "..." это означает
   что значение должно быть независимо от вычисленной длины тела.

          PUA PA WATCHER
         (EPA) (ESC)
           | | |
           | | <---- M1: ПОДПИСАТЬСЯ --- |
           | | |
           | | ----- M2: 200 ОК -----> |
           | | |
           | | ----- M3: УВЕДОМЛЕНИЕ -----> |
           | | |
           | | <---- M4: 200 ОК ------ |
           | | |
           | | |
           | ---- M5: ПУБЛИКАЦИЯ ---> | |
           | | |
           | <--- M6: 200 ОК ---- | |
           | | |
           | | ----- M7: УВЕДОМЛЕНИЕ -----> |
           | | |
           | | <---- M8: 200 ОК ------ |
           | | |
           | ---- M9: ПУБЛИКАЦИЯ ---> | |
           | | |
           | <--- M10: 200 ОК --- | |
           | | |
           | | |
           | --- M11: ПУБЛИКАЦИЯ ---> | |
           | | |
           | <- M12: 200 ОК ---- | |
           | | |
           | | ----- M13: УВЕДОМЛЕНИЕ ----> |
           | | |
           | | <---- M14: 200 ОК ----- |
           | | |





Niemi Standards Track [Страница 24]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


   Поток сообщений:

   M1: Наблюдатель инициирует новую подписку на
      презентация @ пример.com агент присутствия.

      ПОДПИСАТЬСЯ на sip: [email protected] SIP / 2.0
      Через: SIP / 2.0 / UDP host.example.com; branch = z9hG4bKnashds7
      Кому: 
      От: ; tag = 12341234
      Call-ID: [email protected]
      CSeq: 1 ПОДПИСАТЬСЯ
      Максимальное количество нападающих: 70
      Срок годности: 3600
      Событие: присутствие
      Контакты: sip: [email protected]
      Content-Length: 0

   M2: агент присутствия для [email protected] обрабатывает
      запрос на подписку и создает новую подписку.А 200 (ОК)
      отправляется ответ для подтверждения подписки.

      SIP / 2.0 200 ОК
      Через: SIP / 2.0 / UDP host.example.com; branch = z9hG4bKnashds7
       ; получил = 192.0.2.1
      Кому: ; tag = abcd1234
      От: ; tag = 12341234
      Call-ID: [email protected]
      CSeq: 1 ПОДПИСАТЬСЯ
      Контакт: sip: pa.example.com
      Срок годности: 3600
      Content-Length: 0

   M3: для завершения процесса агент присутствия отправляет
      Наблюдатель за NOTIFY с текущим состоянием присутствия
      настоящее.УВЕДОМЛЕНИЕ sip: [email protected] SIP / 2.0
      Через: SIP / 2.0 / UDP pa.example.com; branch = z9hG4bK8sdf2
      Кому: ; tag = 12341234
      От: ; tag = abcd1234
      Call-ID: [email protected]
      CSeq: 1 УВЕДОМЛЕНИЕ
      Максимальное количество нападающих: 70
      Событие: присутствие
      Состояние подписки: активно; истекает = 3599
      Контакт: sip: pa.example.com
      Тип содержимого: приложение / pidf + xml
      Content-Length: ...



Niemi Standards Track [Страница 25]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


      [Документ PIDF]

   M4: Наблюдатель подтверждает получение запроса NOTIFY.SIP / 2.0 200 ОК
      Через: SIP / 2.0 / UDP pa.example.com; branch = z9hG4bK8sdf2
       ; получил = 192.0.2.2
      Кому: ; tag = 12341234
      От: ; tag = abcd1234
      Call-ID: [email protected]
      CSeq: 1 УВЕДОМЛЕНИЕ

   M5: Пользовательский агент присутствия (действующий от имени) инициирует
       ОПУБЛИКОВАТЬ запрос агенту присутствия, чтобы обновить его
       новая информация о присутствии. Поле заголовка Expires указывает
       рекомендуемая продолжительность для этого мягкого состояния события.ПУБЛИКАЦИЯ sip: [email protected] SIP / 2.0
      Через: SIP / 2.0 / UDP pua.example.com; branch = z9hG4bK652hsge
      Кому: 
      От: ; tag = 1234wxyz
      Call-ID: [email protected]
      CSeq: 1 ОПУБЛИКОВАТЬ
      Максимальное количество нападающих: 70
      Срок годности: 3600
      Событие: присутствие
      Тип содержимого: приложение / pidf + xml
      Content-Length: ...

      [Опубликованный документ PIDF]

   M6: агент присутствия получает и принимает данные о присутствии
      публикация.Опубликованные данные включены в
      информация о присутствии присутствия.

      SIP / 2.0 200 ОК
      Через: SIP / 2.0 / UDP pua.example.com; branch = z9hG4bK652hsge
       ; получил = 192.0.2.3
      Кому: ; tag = 1a2b3c4d
      От: ; tag = 1234wxyz
      Call-ID: [email protected]
      CSeq: 1 ОПУБЛИКОВАТЬ
      SIP-ETag: dx200xyz
      Срок годности: 1800

   M7: агент присутствия определяет, что внесено изменение, о котором следует сообщить.
      передается в информацию о присутствии объекта и отправляет
      новое уведомление о присутствии для наблюдателя.Niemi Standards Track [Страница 26]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


      УВЕДОМЛЕНИЕ sip: [email protected] SIP / 2.0
      Через: SIP / 2.0 / UDP pa.example.com; branch = z9hG4bK4cd42a
      Кому: ; tag = 12341234
      От: ; tag = abcd1234
      Call-ID: [email protected]
      CSeq: 2 УВЕДОМЛЕНИЕ
      Максимальное количество нападающих: 70
      Событие: присутствие
      Состояние подписки: активно; истекает = 3400
      Контакты: sip: pa.example.com
      Тип содержимого: приложение / pidf + xml
      Content-Length: ...

      [Новый документ PIDF]

   M8: Наблюдатель подтверждает получение запроса NOTIFY.

      SIP / 2.0 200 ОК
      Через: SIP / 2.0 / UDP pa.example.com; branch = z9hG4bK4cd42a
       ; получил = 192.0.2.2
      Кому: ; tag = 12341234
      От: ; tag = abcd1234
      Call-ID: [email protected]
      CSeq: 2 УВЕДОМЛЕНИЕ
      Content-Length: 0

   M9: PUA определяет, что состояние события было опубликовано ранее.
      скоро истечет, и обновляет это состояние события.ПУБЛИКАЦИЯ sip: [email protected] SIP / 2.0
      Через: SIP / 2.0 / UDP pua.example.com; branch = z9hG4bK771ash02
      Кому: 
      От: ; tag = 1234kljk
      Call-ID: [email protected]
      CSeq: 1 ОПУБЛИКОВАТЬ
      Максимальное количество нападающих: 70
      SIP-If-Match: dx200xyz
      Срок годности: 3600
      Событие: присутствие
      Content-Length: 0

   M10: агент присутствия получает и принимает публикацию
      обновить. Таймеры относительно истечения определенного
      состояние события, идентифицированное тегом объекта, обновляется.Как всегда,
      ESC возвращает тег объекта в ответ на успешное
      ПУБЛИКОВАТЬ. Обратите внимание, что фактического изменения состояния не произошло, поэтому
      наблюдатели не будут получать УВЕДОМЛЕНИЯ.




Niemi Standards Track [Страница 27]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


      SIP / 2.0 200 ОК
      Через: SIP / 2.0 / UDP pua.example.com; branch = z9hG4bK771ash02
       ; получил = 192.0.2.3
      Кому: ; tag = 2affde434
      От: ; tag = 1234kljk
      Call-ID: [email protected]
      CSeq: 1 ОПУБЛИКОВАТЬ
      SIP-ETag: kwj449x
      Срок годности: 1800

   M11: PUA объекта присутствия обнаруживает изменение в пользовательском
      состояние присутствия. Он инициирует запрос PUBLISH к присутствию
      агент для изменения опубликованной информации о присутствии с последними
      изменение.

      ПУБЛИКАЦИЯ sip: [email protected] SIP / 2.0
      Через: SIP / 2.0 / UDP pua.example.com; branch = z9hG4bKcdad2
      Кому: 
      От: ; tag = 54321 мм
      Call-ID: [email protected]
      CSeq: 1 ОПУБЛИКОВАТЬ
      Максимальное количество нападающих: 70
      SIP-If-Match: kwj449x
      Срок годности: 3600
      Событие: присутствие
      Тип содержимого: приложение / pidf + xml
      Content-Length: ...

      [Опубликованный документ PIDF]

   M12: Агент присутствия получает и принимает изменение
       публикация. Опубликованные данные включены в
       информация присутствия, обновление предыдущего
       публикация из того же PUA.SIP / 2.0 200 ОК
      Через: SIP / 2.0 / UDP pua.example.com; branch = z9hG4bKcdad2
       ; получил = 192.0.2.3
      Кому: ; tag =ffe22aa
      От: ; tag = 54321 мм
      Call-ID: [email protected]
      CSeq: 1 ОПУБЛИКОВАТЬ
      SIP-ETag: qwi982ks
      Срок годности: 3600

   M13: Агент присутствия определяет, что внесено изменение, о котором следует сообщить.
       вносится в документ присутствия и отправляет
       новое уведомление о присутствии для всех активных подписок.Niemi Standards Track [Страница 28]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


      УВЕДОМЛЕНИЕ sip: [email protected] SIP / 2.0
      Через: SIP / 2.0 / UDP pa.example.com; branch = z9hG4bK32defd3
      Кому: ; tag = 12341234
      От: ; tag = abcd1234
      Call-ID: [email protected]
      CSeq: 2 УВЕДОМЛЕНИЕ
      Максимальное количество нападающих: 70
      Событие: присутствие
      Состояние подписки: активно; истекает = 3400
      Контакты: sip: pa.example.com
      Тип содержимого: приложение / pidf + xml
      Content-Length: ...

      [Новый документ PIDF]

   M14: Наблюдатель подтверждает получение запроса NOTIFY.

      SIP / 2.0 200 ОК
      Через: SIP / 2.0 / UDP pa.example.com; branch = z9hG4bK32defd3
       ; получил = 192.0.2.3
      Кому: ; tag = 12341234
      От: ; tag = abcd1234
      Call-ID: [email protected]
      CSeq: 2 УВЕДОМЛЕНИЕ
      Content-Length: 0

16. Авторы

   Первыми участниками этой спецификации являются:

      Бен Кэмпбелл
      Estacado Systems

      Шон Олсон
      Microsoft

      Джон Петерсон
      Neustar, Inc.Джонатан Розенберг
      Dynamicsoft

      Брайан Стакер
      Nortel Networks, Inc.







Niemi Standards Track [Страница 29]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


17. Благодарности

   Авторы хотели бы поблагодарить SIMPLE Working Group за их
   коллективные усилия, и особенно следующие люди для их
   рецензирование и поддержка этой работы: Хеннинг Шульцринне, Пол Кизиват,
   Хишам Хартабил, Джордж Фоти, Кейт Драге, Самир Шривастава, Арун
   Кумар, Адам Роуч, Пекка Песси, Кай Ван, Каллен Дженнингс, Микко
   Лоннфорс, Ева-Мария Леппанен, Эрнст Хорват, Танос Диакакис, Одед
   Кнаан, Рохан Махи и Дин Уиллис.18. Ссылки

18.1. Нормативные ссылки

   [1] Роуч, А., "Протокол инициации сеанса (SIP) - специфическое событие
        Уведомление », RFC 3265, июнь 2002 г.

   [2] Розенберг, Дж., "Пакет мероприятий присутствия для сеанса".
        Протокол инициации (SIP) », RFC 3856, август 2004 г.

   [3] Дэй М., Розенберг Дж. И Х. Сугано, «Модель присутствия и
        Обмен мгновенными сообщениями », RFC 2778, февраль 2000 г.

   [4] Розенберг, Дж., Шульцринн, Х., Камарилло, Г., Джонстон, А.,
        Петерсон, Дж., Спаркс, Р., Хэндли, М., и Э. Шулер, "SIP:
        Протокол инициации сеанса », RFC 3261, июнь 2002 г.

   [5] Брэднер С. «Ключевые слова для использования в RFC для обозначения требований.
        Уровни », BCP 14, RFC 2119, март 1997 г.

   [6] Сугано, Х., Фудзимото, С., Клайн, Г., Бейтман, А., Карр, В., и
        Дж. Петерсон, "Формат данных информации о присутствии (PIDF)", RFC
        3863, август 2004 г.

   [7] Crocker, D., Ed. и П. Оверелл, "Расширенный BNF для синтаксиса
        Спецификации: ABNF », RFC 2234, ноябрь 1997 г.[8] Диркс, Т. и К. Аллен, «Протокол TLS версии 1.0», RFC
        2246, январь 1999 г.

   [9] Рамсделл Б., Ред. "Безопасные / многоцелевые расширения электронной почты в Интернете".
        (S / MIME) Версия 3.1 Спецификация сообщений ", RFC 3851, июль
        2004 г.








Niemi Standards Track [Страница 30]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


19.2. Информативные ссылки

   [10] Кэмпбелл, Б., «Требования к публикации для ПРОСТОГО присутствия», Работа
        в процессе, февраль 2003 г.[11] Махи Р., "Краткое изложение сообщения и индикация ожидающего сообщения".
        Пакет событий для протокола инициации сеанса (SIP) », RFC
        3842, август 2004 г.

   [12] Розенберг, Дж., Шульцринн, Х., и П. Кизиват, «Пользователь с указанием»
        Возможности агента в протоколе инициации сеанса (SIP) »,
        RFC 3840, август 2004 г.

   [13] Филдинг, Р., Геттис, Дж., Могул, Дж., Фристик, Х., Масинтер, Л.,
        Лич, П. и Т. Бернерс-Ли, "Протокол передачи гипертекста -
        HTTP / 1.1 ", RFC 2616, июнь 1999 г.

Адрес автора

   Аки Ниеми (редактор)
   Nokia
   P.O. Коробка 407
   NOKIA GROUP, FIN 00045
   Финляндия

   Телефон: +358 50389 1644
   Электронная почта: [email protected]
























Niemi Standards Track [Страница 31]

RFC 3903 Публикация состояния события SIP, октябрь 2004 г.


Полное заявление об авторских правах

   Авторские права (C) The Internet Society (2004).

   На этот документ распространяются права, лицензии и ограничения.
   содержится в BCP 78, и, за исключением случаев, указанных в нем, авторы
   сохраняют все свои права.Этот документ и содержащаяся в нем информация размещены на
   Принцип «КАК ЕСТЬ» и ПОСТАВЩИК, ОРГАНИЗАЦИЯ, ПРЕДСТАВЛЯЕМЫЕ ОН / ОНА
   ИЛИ СПОНСИРУЕТСЯ (ЕСЛИ ЕСТЬ) ИНТЕРНЕТ-ОБЩЕСТВОМ И ИНТЕРНЕТОМ
   ТЕХНИЧЕСКОЕ ОБРАЗОВАНИЕ ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ,
   ВКЛЮЧАЯ, НО НЕ ОГРАНИЧИВАЯ ГАРАНТИЮ, ЧТО ИСПОЛЬЗОВАНИЕ
   ДАННАЯ ИНФОРМАЦИЯ НЕ НАРУШАЕТ НИКАКИХ ПРАВ ИЛИ ПОДРАЗУМЕВАЕМЫХ
   ГАРАНТИИ КОММЕРЧЕСКОЙ ЦЕННОСТИ ИЛИ ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ.

Интеллектуальная собственность

   IETF не занимает никакой позиции относительно действительности или объема любых
   Права интеллектуальной собственности или другие права, которые могут быть заявлены
   относятся к реализации или использованию технологии, описанной в
   этот документ или степень, в которой любая лицензия на такие права
   может быть, а может и нет; и не означает, что
   предпринял какие-либо независимые усилия для определения любых таких прав.Информация
   о процедурах IETF в отношении прав в документах IETF может
   можно найти в BCP 78 и BCP 79.

   Копии разглашения прав интеллектуальной собственности в секретариат IETF и
   гарантии предоставления лицензий или результат
   попытка получить генеральную лицензию или разрешение на использование
   такие права собственности разработчиками или пользователями этого
   спецификацию можно получить из он-лайн репозитория IETF IPR по адресу
   http://www.ietf.org/ipr.

   IETF приглашает любую заинтересованную сторону довести до ее сведения любые
   авторские права, патенты или заявки на патенты или другие проприетарные
   права, которые могут распространяться на технологии, которые могут потребоваться для реализации
   этот стандарт.Пожалуйста, направьте информацию в IETF по адресу ietf-
   [email protected].

Подтверждение

   Финансирование функции редактора RFC в настоящее время обеспечивается
   Интернет-общество.







Niemi Standards Track [Страница 32]

Разметка HTML, созданная rfcmarkup 1.129d, доступная по адресу
https://tools.ietf.org/tools/rfcmarkup/

Руководство по обмену сообщениями по линии SIP (стандартная версия) для Cisco Unified Communications Manager, выпуск 11.5 (1) - Стандартный линейный интерфейс SIP [Cisco Unified Communications Manager (CallManager)]

AOR	Адрес записи
BLF	Поле занятости лампы
Cseq	Порядковый номер вызова
CPN	Нормализация вызывающего абонента
CSS	Вызов поискового пространства
CTI	Интеграция компьютерной телефонии
Не беспокоить	Не беспокоить
DNS	Сервер доменных имен
DTMF	Двухтональный многочастотный
FECC	Управление удаленной камерой
FMTP	Параметры формата
FQDN	Полное доменное имя
KPML	Язык разметки клавиатуры
MLPP	Многоуровневый приоритет и приоритетное прерывание
MTP	Точка завершения среды передачи
MWI	Индикация ожидающего сообщения
OOB	Вне диапазона
OOD	Вне диалога
PRACK	Подтверждение предварительного ответа
RDNIS	Служба информации о перенаправленных набираемых номерах
RPID	Идентификатор удаленного участника
RTT	Время повторной передачи
SDP	Протокол описания сеанса
SIP	Протокол начала сеанса
SIS	Спецификация интерфейса линии SIP
TLS	Безопасность транспортного уровня
ОАК	Клиент пользовательского агента
UAS	Сервер пользовательского агента
URI	Унифицированный идентификатор ресурса
URN	Унифицированное имя ресурса
VM	Голосовая почта

Параметры протокола инициации сеанса (SIP)

100rel	Эта опция предназначена для надежности предварительные ответы.Когда присутствует в Поддерживаемый заголовок указывает, что UA может отправить или получить надежный предварительный ответы. Когда присутствует в заголовке Require в запросе он указывает, что БПЛА ДОЛЖЕН отправьте все предварительные ответы надежно. Если присутствует в заголовке Require в надежный предварительный ответ, это указывает что ответ должен быть отправлен надежно.	[RFC3262]
199	Этот тег-параметр предназначен для обозначения поддержки из 199 раннего диалога прекращено предварительный код ответа.Когда присутствует в Поддерживаемый заголовок запроса, указывает что UAC поддерживает код ответа 199. При наличии в Require или Proxy-Require поле заголовка запроса, оно указывает, что UAS или прокси-серверы ДОЛЖНЫ поддерживать 199 код ответа. Не требует БПЛА, или прокси, чтобы отправить 199 ответов.	[RFC6228]
режим ответа	Этот тег опции предназначен для поддержки Режим ответа и режим Priv-ответа расширения, используемые для автоматического согласования или ответ на запрос вручную.	[RFC5373]
ранняя сессия	UA, добавляющий тег опции раннего сеанса к сообщению означает, что он понимает расположение содержимого в начале сеанса.	[RFC3959]
список событий	Расширение для подписки на списки ресурсов	[RFC4662]
эксплицитсуб	Этот тег опции идентифицирует расширение для СООБЩЕНИЯ подавить неявную подписку и предоставить URI для явного подписка.	[RFC7614]
от изменения	Этот тег опции используется, чтобы указать, что UA поддерживает изменения URI в From и К полям заголовка во время диалога.	[RFC4916]
геолокация-http	Параметр тега "геолокация-http" сигнализирует поддержка для получения информации о местоположении через HTTP [RFC2616]. Местоположение получатель, поддерживающий эту опцию, может запросить местоположение с помощью HTTP GET и проанализировать полученный ответ 200, содержащий объект PIDF-LO.Схемы URI поддерживаемые этой опцией включают "http" и "https".	[RFC6442]
geolocation-sip	Сигналы тега опции "geolocation-sip" поддержка для получения информации о местоположении через пакет событий присутствия SIP [RFC3856]. Получатель местоположения, который поддерживает эту опцию может отправить ПОДПИСАТЬСЯ запросить и проанализировать полученное сообщение NOTIFY содержащий объект PIDF-LO. URI схемы, поддерживаемые этой опцией, включают «глоток», «глоток» и «пресс».	[RFC6442]
джин	Этот тег опции используется для идентификации расширение, обеспечивающее регистрацию для Несколько телефонных номеров в SIP. Когда присутствует в поле заголовка Require или Proxy-Require запрос REGISTER, он указывает, что поддержка для этого расширения требуется от регистраторов и прокси, соответственно, являющиеся партией к регистрационной транзакции.	[RFC6140]
ГРУ	Этот тег опции используется для идентификации глобально Расширение URI маршрутизируемого пользовательского агента (GRUU).когда используется в заголовке Supported, это означает, что Пользовательский агент понимает расширение. При использовании в поле заголовка Требовать РЕГИСТРА запрос, это указывает на то, что регистратор не ожидается обработка регистрации, если он поддерживает расширение GRUU.	[RFC5627]
histinfo	При использовании с поддерживаемым заголовком поле, этот тег параметра указывает на UAC поддерживает историческую информацию захвачено для запросов и возвращено в последующие ответы.Этот тег не используется в Proxy-Require или Require поле заголовка, так как поддержка История-информация не является обязательной.	[RFC7044]
лед	Этот тег опции используется для идентификации Создание интерактивного подключения (ICE) расширение. Когда присутствует в заголовке Require это означает, что ICE требуется для агент.	[RFC5768]
присоединиться	Поддержка заголовка присоединения SIP	[RFC3911]
с несколькими ссылками	Этот тег опции указывает на поддержку для запросов REFER, содержащих документ со списком ресурсов, описывающий несколько целей REFER.	[RFC5368]
norefersub	Этот тег параметра указывает агент пользователя. возможность принять запрос REFER без установление неявной подписки (по сравнению со случаем по умолчанию, определенным в [RFC3515].	[RFC4488]
носуб	Этот тег опции идентифицирует расширение для СООБЩЕНИЯ подавить неявную подписку и указать, что нет явной подписка готовится.	[RFC7614]
исходящий	Этот тег-параметр используется для идентификации UA и Регистраторы, поддерживающие расширения для Подключения, инициированные клиентом. Места UA этот параметр в заголовке Поддерживается, чтобы сообщить о своей поддержке этого расширения. Регистратор помещает этот тег опции в Требовать заголовок для указания регистрирующий Пользовательский агент, который Регистратор использовали регистрации с использованием обязательных правил определено в этом расширении.	[RFC5626]
путь	UA SIP, поддерживающий расширение пути поле заголовка включает этот тег опции как значение поля заголовка в поддерживаемом заголовке во всех запросах, сгенерированных этим UA.Промежуточные прокси могут использовать присутствие этого тега опции в запросе REGISTER на определить, предлагать ли услугу Path для для этого запроса. Если промежуточный прокси требует, чтобы путь поддержки регистратора для запрос, тогда он включает этот тег опции как значение поля заголовка в Требуется поле заголовка в этом запросе.	[RFC3327]
полис	Этот тег опции используется, чтобы указать, что UA может обрабатывать URI сервера политик для и подписаться на сеанс политики.	[RFC6794]
предварительное условие	Оферент ДОЛЖЕН включить этот тег в Требовать поле заголовка, если предложение содержит один или несколько «обязательных» тегов прочности. Если все признаки силы в описании "необязательно" или "нет", оферент ДОЛЖЕН включать этот тег либо в поле поддерживаемого заголовка или в поле «Требовать заголовка».	[RFC3312]
преф	Этот тег опции используется, чтобы гарантировать, что сервер понимает возможности вызываемого параметры, используемые в запросе.	[RFC3840]
конфиденциальность	Этот тег опции указывает на поддержку Механизм конфиденциальности. При использовании в Заголовок Proxy-Require, он указывает, что прокси серверы не пересылают запрос, если они может предоставить запрошенную услугу конфиденциальности. Этот тег не используется в Require или Поддерживаемые заголовки. Прокси убирают эту опцию тег перед пересылкой запроса при желании функция конфиденциальности была выполнена.	[RFC3323]
список получателей-приглашение	Тело содержит список URI что указывает получателей Запрос SIP INVITE	[RFC5366]
сообщение-список-получателей	Тело содержит список URI что указывает на получателей запрос SIP MESSAGE	[RFC5365]
список получателей-подписка	Этот тег опции используется для обеспечения что сервер может обрабатывать тело списка получателей, используемое в ПОДПИСАТЬСЯ на запрос.	[RFC5367]
с учетом записей	Этот тег опции указывает на способность UA к получать индикаторы записи в SDP на уровне носителя или на уровне сеанса. Если он присутствует в заголовке Supported, это означает, что UA может получать индикаторы записи в SDP на уровне носителя или на уровне сеанса.	[RFC7866]
заменяет	Этот тег опции указывает на поддержку SIP Заменяет заголовок.	[RFC3891]
приоритет ресурса	Указывает или запрашивает поддержку для механизм приоритета ресурсов.	[RFC4412]
SDP-анат	Параметр-тег sdp-anat определен для использования в Требуемом и поддерживаемом протоколе SIP [RFC3261] поля заголовка. Пользовательские агенты SIP, которые помещают это option-tag в поддерживаемом поле заголовка понять семантика ANAT, как определено в [RFC4091].	[RFC4092]
сек согласен	Этот тег опции указывает на поддержку Механизм соглашения об обеспечении. При использовании в Заголовки Require или Proxy-Require, он указывает что прокси-серверы должны использовать Механизм соглашения об обеспечении. При использовании в Заголовок Supported, он указывает, что Пользовательский агент Клиент поддерживает Соглашение о безопасности механизм. При использовании в заголовке Require в 494 (требуется соглашение о безопасности) или 421 (требуется расширение) откликов, это указывает, что клиент User Agent должен использовать механизм соглашения об обеспечении безопасности.	[RFC3329]
siprec	Этот тег опции предназначен для идентификации того, что SIP сессия предназначена для RS. Это обычно не используется в заголовке Supported. Когда присутствует в Требовать заголовок в запросе, он указывает, что UA является либо SRC или SRS, способные обрабатывать сеанс записи.	[RFC7866]
tdialog	Этот тег опции используется для идентификации цели расширение поля заголовка диалога.При использовании в поле "Требовать заголовок" означает, что получатель должен поддерживать целевой диалог поле заголовка. При использовании в поддерживаемом заголовке поле, это означает, что отправитель сообщения поддерживает это.	[RFC4538]
таймер	Этот тег опции предназначен для поддержки расширение таймера сеанса. Включение в поддерживаемый поле заголовка в запросе или ответе указывает что UA может выполнять обновления в соответствии с этой спецификацией.Включение в заголовке Require в запросе означает, что UAS должен понимать расширение таймера сеанса для обработки запроса. Включение в требование поле заголовка в ответе указывает, что UAC должен искать заголовок Session-Expires в ответ и обработайте соответственно.	[RFC4028]
мелкий лед	Этот тег опции используется для указания что UA поддерживает и понимает Trickle ICE.	[RFC-ietf-mmusic-trickle-ice-sip-18]
uui	Этот тег опции используется, чтобы указать, что UA поддерживает и понимает поле заголовка User-to-User.	[RFC7433]

1. Введение в SIP

Абстрактные

Краткий обзор SIP, описывающий все важные аспекты инициирования сеанса
Протокол.

SIP расшифровывается как протокол инициации сеанса.Это элемент управления на уровне приложения
протокол, который был разработан и разработан в IETF. В протоколе есть
был разработан с учетом простой реализации, хорошей масштабируемости и гибкости.

Спецификация доступна в виде нескольких RFC , наиболее
важным является RFC3261, содержащий спецификацию основного протокола. В
протокол используется для создания, изменения и завершения сеансов с одним или несколькими
участников.Под сеансами мы понимаем набор отправителей и получателей, которые
общаются, и состояние сохраняется в этих отправителях и получателях во время
общение. Примеры сеанса могут включать в себя телефонные звонки через Интернет,
раздача мультимедиа, мультимедийные конференции, раздача компьютерных игр и др.

SIP - не единственный протокол, который потребуется устройствам связи. Нет, это не так
предназначалась для протокола общего назначения. Цель SIP - просто сделать
коммуникация возможна, сама коммуникация должна быть достигнута другими средствами
(и, возможно, другой протокол).Два протокола, которые чаще всего используются вместе с
SIP - это RTP и SDP. Протокол RTP используется для передачи мультимедиа в реальном времени.
данные (включая аудио, видео и текст), протокол позволяет кодировать
и разделить данные на пакеты и транспортировать такие пакеты по
Интернет. Другой важный протокол - SDP, который используется для описания и кодирования
возможности участников сеанса. Такое описание затем используется для согласования
характеристики сеанса, чтобы все устройства могли участвовать (что
включает, например, согласование кодеков, используемых для кодирования мультимедиа, так что все
участники смогут его расшифровать, согласовать используемый транспортный протокол и
скоро).

Протокол SIP разработан в соответствии с интернет-моделью. Это сквозной
ориентированный протокол сигнализации, что означает, что вся логика сохраняется в конце
устройства (кроме маршрутизации SIP-сообщений). Состояние также сохраняется в конечных устройствах
только нет единой точки отказа, и сети, спроектированные таким образом, масштабируются
Что ж. Цена, которую мы должны заплатить за распределенность и масштабируемость, составляет
более высокие накладные расходы на сообщения, вызванные сквозной отправкой сообщений.

Стоит отметить, что сквозная концепция SIP является важной
отклонение от обычной коммутируемой телефонной сети общего пользования, где все
состояние и логика хранятся в сети, а конечные устройства (телефоны) очень
примитивный. Цель SIP - обеспечить ту же функциональность, что и традиционные
ТфОП есть, но сквозная конструкция делает сети SIP намного более мощными и
открыт для внедрения новых услуг, которые вряд ли могут быть реализованы в
традиционные телефонные сети общего пользования.

SIP основан на протоколе HTTP. Формат сообщения, унаследованный от протокола HTTP
заголовки из RFC822. HTTP, наверное, самый успешный и широко используемый
протокол в Интернете. Он пытается объединить лучшее из обоих. Фактически, HTTP
также можно классифицировать как протокол сигнализации, поскольку пользовательские агенты используют протокол
чтобы сообщить HTTP-серверу, в каких документах они заинтересованы. SIP используется для
нести описание параметров сеанса, описание закодировано в
документ с использованием SDP.Оба протокола (HTTP и SIP) унаследовали кодировку
заголовки сообщений из RFC822. Кодирование оказалось надежным и гибким.
с годами.

Сущности SIP идентифицируются с помощью SIP URI (унифицированный идентификатор ресурса). А
SIP URI имеет форму sip: имя пользователя @ домен, например,
sip: [email protected]. Как мы видим, SIP URI состоит из части имени пользователя и
часть доменного имени, разделенная символом @ (at). SIP URI похожи на
адреса электронной почты, например, можно использовать один и тот же URI для электронной почты
и связь по протоколу SIP, такие URI легко запомнить.

1.3. Сетевые элементы SIP

Хотя в простейшей конфигурации можно использовать всего два пользовательских агента.
которые отправляют сообщения SIP напрямую друг другу, типичная сеть SIP будет
содержат более одного типа SIP-элементов. Основные элементы SIP - это пользовательские агенты,
прокси, регистраторы и серверы перенаправления. Мы кратко их опишем в этой
раздел.

Обратите внимание, что элементы, представленные в этом разделе, часто являются только логическими.
сущности. Часто бывает выгодно разместить их вместе, например, чтобы
увеличить скорость обработки, но это зависит от конкретной реализации
и конфигурация.

Конечные точки Интернета, которые используют SIP для поиска друг друга и согласования сеанса
характеристики называются пользовательскими агентами . Пользовательские агенты
обычно, но не обязательно, находятся на компьютере пользователя в виде
приложение - в настоящее время это наиболее широко используемый подход, но пользовательские агенты
также могут быть сотовые телефоны, шлюзы PSTN, КПК, автоматизированные
Системы IVR и так далее.

Пользовательские агенты часто упоминаются как User Agent Server
(UAS) и User Agent Client (UAC). БАС и ОАК
только логические объекты, каждый пользовательский агент содержит UAC и UAS. ОАК - это
часть пользовательского агента, которая отправляет запросы и получает ответы. UAS - это
часть пользовательского агента, которая получает запросы и отправляет ответы.

Поскольку пользовательский агент содержит как UAC, так и UAS, мы часто говорим, что пользователь
агент ведет себя как UAC или UAS.Например, пользовательский агент вызывающего абонента ведет себя
как UAC, когда он отправляет запросы INVITE и получает ответы на
запрос. Пользовательский агент Callee ведет себя как БПЛА, когда получает ПРИГЛАШЕНИЕ.
и отправляет ответы.

Но эта ситуация меняется, когда вызываемый абонент решает отправить BYE и завершить работу.
сессия. В этом случае пользовательский агент вызываемого абонента (отправляющий BYE) ведет себя как
UAC и пользовательский агент вызывающего ведут себя как UAS.

На рис. 1, «UAC и UAS» показаны три пользовательских агента и одно разветвление с отслеживанием состояния.
прокси.Каждый пользовательский агент содержит UAC и UAS. Часть прокси, которая
получает ПРИГЛАШЕНИЕ от вызывающего абонента, фактически действует как UAS. При пересылке
запрос с сохранением состояния прокси создает два UAC, каждый из которых отвечает за
одна ветка.

В нашем примере вызываемый абонент B взял трубку и позже, когда он захочет прекратить вызов
он отправляет BYE. В это время пользовательский агент, который ранее был UAS, становится
UAC и наоборот.

В дополнение к этому SIP позволяет создавать инфраструктуру сетевых хостов.
назвал прокси-серверами .Пользовательские агенты могут отправлять сообщения на
прокси-сервер. Прокси-серверы - очень важные объекты в SIP.
инфраструктура. Они выполняют маршрутизацию приглашений на сеанс в соответствии с
текущее местонахождение приглашенного, аутентификация, учет и многое другое.
функции.

Самая важная задача прокси-сервера - направлять приглашения на сеанс.
"ближе" к вызываемому. Приглашение к сеансу обычно проходит через
набор прокси, пока он не найдет тот, который знает фактическое местоположение
вызываемый.Такой прокси пересылает приглашение на сеанс прямо вызываемому.
а затем вызываемый абонент примет или отклонит приглашение на сеанс.

Существует два основных типа прокси-серверов SIP - без отслеживания состояния и с отслеживанием состояния.

1.3.2.1. Серверы без сохранения состояния

Серверы без сохранения состояния - это простые пересылки сообщений. Они пересылают сообщения
независимо друг от друга.Хотя сообщения обычно располагаются в
транзакции (см. Раздел 1.5, «Транзакции SIP»), прокси без сохранения состояния
не занимайтесь транзакциями.

Прокси без сохранения состояния просты, но быстрее, чем прокси-серверы с отслеживанием состояния. Oни
могут использоваться как простые балансировщики нагрузки, трансляторы сообщений и маршрутизаторы. Один
из недостатков прокси без сохранения состояния является то, что они не могут поглощать
повторная передача сообщений и выполнение более сложной маршрутизации, например,
разветвление или рекурсивный обход.

1.3.2.2. Серверы с отслеживанием состояния

Прокси-серверы с отслеживанием состояния более сложны. При получении запроса
прокси создают состояние и сохраняют состояние до транзакции
отделка. Некоторые транзакции, особенно те, которые созданы INVITE, могут длиться
довольно долго (пока вызываемый абонент не возьмет или не отклонит вызов). Потому что состояние
прокси должны поддерживать состояние на время транзакции, их
производительность ограничена.

Возможность связывать SIP-сообщения с транзакциями дает
прокси некоторые интересные функции. Прокси-серверы с отслеживанием состояния могут выполнять разветвление,
это означает, что при получении сообщения будут отправлены два или более сообщения
вне.

Прокси-серверы с отслеживанием состояния могут поглощать повторные передачи, потому что они знают, из
состояние транзакции, если они уже получили такое же сообщение (без сохранения состояния
прокси-серверы не могут выполнить проверку, потому что они не сохраняют состояние).

Прокси-серверы с отслеживанием состояния могут выполнять более сложные методы поиска пользователя. Это
например, можно попытаться дозвониться до рабочего телефона пользователя, и когда он
не берет трубку, тогда звонок перенаправляется на его мобильный телефон. Без гражданства
прокси-серверы не могут этого сделать, потому что у них нет возможности узнать, как
транзакция, адресованная офисному телефону, завершена.

Большинство SIP-прокси сегодня поддерживают состояние, потому что их конфигурация обычно
очень сложный.Часто выполняют учет, разветвление, какой-то NAT
помощь при обходе и все эти функции требуют прокси с отслеживанием состояния.

1.3.2.3. Использование прокси-сервера

Типичная конфигурация состоит в том, что каждый централизованно управляемый объект (
компании, например) имеет собственный прокси-сервер SIP, который используется всеми
пользовательские агенты в сущности.Допустим, есть две компании A и
B и у каждого из них свой прокси-сервер. Рисунок 2, «Приглашение к сеансу»
показывает, как приглашение на сеанс от сотрудника Джо из компании А достигнет
сотрудник Боб в компании Б.

Рис. 2. Приглашение на сеанс

Пользователь Джо использует адрес sip: [email protected] для звонка Бобу. Пользовательский агент Джо не
знаю, как направить само приглашение, но оно настроено на отправку всех
исходящий трафик на прокси-сервер SIP компании.a.com. Прокси
сервер выясняет, что пользователь sip: [email protected] находится в другой компании, поэтому
найдет прокси-сервер SIP B и отправит туда приглашение. Прокси B
сервер можно предварительно настроить на proxy.a.com или прокси будет использовать
Записи DNS SRV для поиска прокси-сервера B. Приглашение
достигает proxy.bo.com. Прокси-сервер знает, что Боб сейчас сидит в своем
офиса и с ним можно связаться по телефону на его столе, у которого есть IP-адрес
1.2.3.4, значит, прокси пришлет туда приглашение.

Мы упоминали, что прокси-сервер SIP на proxy.b.com знает текущее местоположение Боба.
но еще не упомянул, как прокси может узнать текущее местоположение
пользователь. Пользовательский агент Боба (SIP-телефон) должен зарегистрироваться с
регистратор . Регистратор - это специальная SIP-организация, которая
получает регистрации от пользователей, извлекает информацию об их текущих
местоположение (IP-адрес, порт и имя пользователя в данном случае) и хранит
информацию в базу данных о местонахождении.Цель базы данных местоположения - отображать
sip: [email protected] на что-то вроде sip: [email protected]: 5060. База данных местоположения
затем используется прокси-сервером B. Когда прокси получает приглашение для
sip: [email protected] будет искать в базе данных о местоположении. Находит
sip: [email protected]: 5060 и отправим туда приглашение. Регистратор очень
часто только логическая сущность. Из-за их тесной связи с прокси
регистраторы, как правило, расположены вместе с прокси-серверами.

На Рис. 3, «Обзор регистратора» показана типичная регистрация SIP.РЕГИСТР
сообщение, содержащее Address of Record sip: [email protected] и контактный адрес
sip: [email protected]: 5060, где 1.2.3.4 - IP-адрес телефона, отправляется на
регистратор. Регистратор извлекает эту информацию и сохраняет ее в
база данных местоположения. Если все прошло успешно, регистратор отправляет 200 OK.
ответ на телефон и процесс регистрации окончен.

Рисунок 3. Обзор регистратора

Каждая регистрация имеет ограниченный срок действия.Срок действия поля заголовка истекает или истекает
параметр поля заголовка контакта определяет, как долго длится регистрация
действительный. Пользовательский агент должен обновить регистрацию в течение срока службы.
в противном случае срок его действия истечет, и пользователь станет недоступен.

Сущность, которая получает запрос и отправляет ответ, содержащий список
Текущее местоположение конкретного пользователя называется сервером перенаправления . А
сервер перенаправления получает запросы и ищет предполагаемого получателя запроса в
база данных местоположения, созданная регистратором.Затем он создает список текущих
местоположения пользователя и отправляет его отправителю запроса в ответе в пределах 3xx
класс.

Затем отправитель запроса извлекает список адресатов и отправляет
другой запрос прямо к ним. На рис. 4, «Перенаправление SIP» показан типичный
перенаправление.

Рисунок 4. Перенаправление SIP

Связь с использованием SIP (часто называемого сигнализацией) состоит из серии
сообщения .Сообщения могут передаваться независимо
сеть. Обычно они передаются в отдельной датаграмме UDP каждая. Каждый
сообщение состоит из «первой строки», заголовка сообщения и тела сообщения. В
первая строка определяет тип сообщения. Есть два типа
сообщения - запросов и ответов .
Запросы обычно используются, чтобы инициировать какое-либо действие или информировать получателя о запросе.
чего-либо. Ответы используются для подтверждения того, что запрос был получен и обработан.
и содержать статус обработки.

Типичный SIP-запрос выглядит так:

 INVITE sip: [email protected] SIP / 2.0
Через: SIP / 2.0 / UDP 195.37.77.100:5040;rport
Максимальное количество нападающих: 10
От: "jiri" ; tag = 76ff7a07-c091-4192-84a0-d56e91fe104f
Кому: 
Call-ID: [email protected]
CSeq: 2 ПРИГЛАШАТЬ
Контакты: 
Пользовательский агент: Windows RTC / 1.0
Прокси-авторизация: дайджест username = "jiri", realm = "iptel.org ",
 алгоритм = "MD5", uri = "sip: [email protected]",
 nonce = "3cef7530001771328f5ae1b8b7f0d742da1feb5753c",
 response = "53fe98db10e1074
 b03b3e06438bda70f "
Тип содержимого: приложение / sdp
Длина содержимого: 451

v = 0
o = jku2 0 0 В IP4 213.20.128.35
s = сеанс
c = В IP4 213.20.128.35
b = CT: 1000
т = 0 0
m = аудио 54742 RTP / AVP 97 111 112 6 0 8 4 5 3 101
a = rtpmap: 97 красный / 8000
a = rtpmap: 111 СИРЕНА / 16000
a = fmtp: 111 битрейт = 16000
a = rtpmap: 112 G7221 / 16000
a = fmtp: 112 битрейт = 24000
a = rtpmap: 6 DVI4 / 16000
a = rtpmap: 0 PCMU / 8000
a = rtpmap: 4 G723 / 8000
a = rtpmap: 3 GSM / 8000
a = rtpmap: 101 телефонное событие / 8000
a = fmtp: 101 0-16

Первая строка сообщает нам, что это сообщение INVITE, которое используется для установления
сеанс.URI в первой строке - sip: [email protected] называется Request.
URI и содержит URI следующего прыжка сообщения. В этом случае это
будет хост iptel.org.

Запрос SIP может содержать одно или несколько полей заголовка Via, которые используются для записи
путь запроса. Позже они точно так же используются для маршрутизации SIP-ответов.
путь. Сообщение INVITE содержит только одно поле заголовка Via, созданное
пользовательский агент, отправивший запрос.Из поля Via мы можем сказать, что пользовательский агент
работает на хосте 195.37.77.100 и порте 5060.

Поля заголовка From и To идентифицируют инициатора (вызывающего) и получателя (вызываемого)
приглашение (как и в SMTP, где они определяют отправителя и получателя
сообщение). Поле заголовка From содержит параметр тега, который служит диалогом
идентификатор и будет описан в Раздел 1.6, «Диалоги SIP».

Поле заголовка Call-ID - это идентификатор диалога, и его цель - идентифицировать сообщения.
принадлежащий тому же вызову.Такие сообщения имеют одинаковый идентификатор Call-ID. CSeq - это
используется для поддержания порядка запросов. Поскольку запросы могут быть отправлены через ненадежный
транспорт, который может переупорядочивать сообщения, порядковый номер должен присутствовать в
сообщения, чтобы получатель мог идентифицировать повторные передачи и неупорядоченные запросы.

Поле заголовка контакта содержит IP-адрес и порт, на котором отправитель ожидает
дальнейшие запросы, отправленные вызываемым пользователем. Остальные поля заголовка не важны и будут
здесь не описано.

Заголовок сообщения отделяется от тела сообщения пустой строкой. Тело сообщения INVITE
запрос содержит описание типа носителя, принятого отправителем и закодированного в
SDP.

Мы описали, как выглядит запрос INVITE, и сказали, что запрос
используется для приглашения абонента на сеанс. Другие важные запросы:

ACK - это сообщение подтверждает получение окончательного
ответ на ПРИГЛАШЕНИЕ.Установление сеанса использует 3-сторонний
рукопожатие из-за асимметричного характера приглашения. Это может занять
а до того, как вызываемый абонент принимает или отклоняет вызов, чтобы вызываемый
Пользовательский агент периодически повторно передает положительный окончательный ответ, пока он
получает ACK (который указывает на то, что вызывающий абонент все еще там и
готовы к общению).
BYE - Сообщения прощания используются для разрушения мультимедиа
сессий. Сторона, желающая прервать сеанс, отправляет BYE на
другая вечеринка.
CANCEL --Cancel используется для отмены еще не полностью
установленная сессия. Он используется, когда вызываемый абонент не ответил
окончательный ответ, но вызывающий абонент хочет прервать вызов (обычно
когда вызываемый абонент некоторое время не отвечает).
REGISTER --Цель запроса REGISTER - разрешить
регистратор знает местонахождение текущего пользователя. Информация о текущих
IP-адрес и порт, по которому можно связаться с пользователем, переносятся в
РЕГИСТРАЦИЯ сообщений.Регистратор извлекает эту информацию и помещает ее в
база данных местоположения. База данных может позже использоваться прокси-сервером SIP
серверы для маршрутизации звонков к пользователю. Регистрация ограничена по времени и
нужно периодически обновлять.

Перечисленные запросы обычно не имеют тела сообщения, потому что он не нужен в
большинство ситуаций (но может быть). В дополнение к этому многие другие типы запросов
были определены, но их описание выходит за рамки этого документа.

Когда пользовательский агент или прокси-сервер получает запрос, он отправляет ответ. Каждый
на запрос должен быть дан ответ, кроме запросов ACK, которые не вызывают ответа.

Типичный ответ выглядит так:

 SIP / 2.0 200 ОК
Через: SIP / 2.0 / UDP 192.168.1.30:5060;received=66.87.48.68
От: sip: [email protected]
Кому: sip: [email protected]; tag = 794fe65c16edfdf45da4fc39a5d2867c.b713
Call-ID: [email protected]
CSeq: 63629 РЕГИСТРАЦИЯ
Обращаться: Msip: sip2 @ 66.87.48.68: 5060; транспорт = udp>; q = 0.00; истекает = 120
Сервер: маршрутизатор Sip EXpress (0.8.11pre21xrc (i386 / linux))
Content-Length: 0
Предупреждение: 392 195.37.77.101:5060 "Шумная обратная связь говорит:
  pid = 5110 req_src_ip = 66.87.48.68 req_src_port = 5060 in_uri = sip: iptel.org
  out_uri = sip: iptel.org via_cnt == 1 "

Как видим, ответы очень похожи на запросы, за исключением первого
линия. Первая строка ответа содержит версию протокола (SIP / 2.0), ответ
код и фраза причины.

Код ответа - это целое число от 100 до 699 и
указывает тип ответа. Всего существует 6 классов ответов:

1xx - это предварительные
ответы. Предварительный ответ - это ответ, который сообщает его
получатель, что связанный запрос был получен, но результат
обработка пока не известна. Предварительные ответы отправляются только тогда, когда
обработка не заканчивается сразу.Отправитель должен остановиться
повторная передача запроса после получения предварительного ответа.
Обычно прокси-серверы при запуске отправляют ответы с кодом 100.
обработка сообщения INVITE и пользовательские агенты отправляют ответы с кодом 180
(Звонок) означает, что звонит телефон вызываемого абонента.
2xx откликов, положительных
окончательные ответа. Окончательный ответ - это окончательный ответ
что отправитель запроса когда-либо получит.Поэтому окончательный
ответы выражают результат обработки связанных
запрос. Окончательные ответы также прекращают транзакции. Ответы с
код от 200 до 299 - положительные ответы, что означает, что запрос
был успешно обработан и принят. Например, ответ 200 OK
отправляется, когда пользователь принимает приглашение в сеанс (запрос INVITE).
UAC может получить несколько 200 сообщений на одно ПРИГЛАШЕНИЕ.
запрос. Это связано с тем, что прокси-сервер разветвления (описанный позже) может разветвлять
запрос, чтобы он достиг нескольких UAS, и каждый из них примет
приглашение.В этом случае каждый ответ выделяется тегом
в поле заголовка Кому. Каждый ответ представляет собой отдельный диалог
с однозначным идентификатором диалога.
3xx ответов используются для перенаправления вызывающего абонента. А
ответ на перенаправление дает информацию о новом местоположении пользователя или
альтернативный сервис, который вызывающий может использовать для удовлетворения
вызов. Ответы на перенаправление обычно отправляются прокси-серверами. Когда
прокси получает запрос и не хочет или не может его обработать ни по какой
причина, он отправит ответ перенаправления вызывающему и поместит
другое место в ответе, которое звонящий может захотеть
пытаться.Это может быть местоположение другого прокси или текущее местоположение
вызываемый (из базы данных местоположения, созданной регистратором). В
Затем предполагается, что вызывающий абонент повторно отправит запрос в новое место. 3xx
отзывы окончательные.
4xx - это отрицательный финал
ответы. ответ 4xx означает, что проблема связана с отправителем
боковая сторона. Запрос не может быть обработан из-за неправильного синтаксиса
или не может выполняться на этом сервере.
5xx означает, что проблема на стороне сервера. В
запрос, по-видимому, действителен, но сервер не смог его выполнить. Клиенты
обычно следует повторить запрос позже.
6xx код ответа означает, что запрос не может быть
выполняется на любом сервере. Этот ответ обычно отправляется сервером, который
содержит исчерпывающую информацию о конкретном пользователе. Пользовательские агенты обычно
отправить ответ 603 Decline, если пользователь не хочет участвовать в
сессия.

Помимо класса ответа первая строка также содержит причины.
фраза . Кодовый номер предназначен для обработки
машины. Это не очень удобно для человека, но его очень легко разбирать и
разбираюсь на машинах. Фраза причины обычно содержит читабельный
сообщение, описывающее результат обработки. Пользовательский агент должен отображать
фраза причины пользователю.

Запрос, которому принадлежит конкретный ответ, идентифицируется с помощью CSeq
поле заголовка.В дополнение к порядковому номеру это поле заголовка также содержит
способ соответствующего запроса. В нашем примере это был запрос REGISTER.

Хотя мы сказали, что сообщения SIP отправляются по сети независимо, они
обычно объединяются в транзакции пользовательскими агентами и
определенные типы прокси-серверов. Поэтому SIP называется
протокол транзакций .

Транзакция - это последовательность сообщений SIP, которыми обмениваются между сетью SIP.
элементы.Транзакция состоит из одного запроса и всех ответов на него.
запрос. Это включает ноль или несколько предварительных ответов и один или несколько окончательных
ответы (помните, что на ПРИГЛАШЕНИЕ может быть дано более одного окончательного ответа
когда прокси-сервер разветвляет запрос).

Если транзакция была инициирована запросом INVITE, то та же транзакция также
включает ACK, но только если окончательный ответ не был ответом 2xx. Если финальный
ответ был ответом 2xx, то ACK не считается частью транзакции.

Как мы видим, это довольно асимметричное поведение - ACK является частью транзакций с
отрицательный окончательный ответ, но не является частью транзакций с положительным окончательным
ответы. Причина этого разделения - важность доставки всех 200
ОК сообщения. Мало того, что они устанавливают сеанс, но и 200 OK могут быть
генерируется несколькими объектами, когда прокси-сервер разветвляет запрос, и все они
должен быть доставлен вызывающему пользовательскому агенту.Поэтому пользовательские агенты принимают
ответственность в этом случае и повторно передать 200 ответов ОК, пока они не получат
ACK. Также обратите внимание, что повторно передаются только ответы на ПРИГЛАШЕНИЕ!

Сущности SIP, которые имеют представление о транзакциях, называются
с состоянием . Такие сущности обычно создают состояние, связанное с
транзакция, которая сохраняется в памяти на время транзакции. Когда
приходит запрос или ответ, объект с отслеживанием состояния пытается связать запрос (или
ответ) на существующие транзакции.Чтобы сделать это, он должен извлечь уникальный
идентификатор транзакции из сообщения и сравните его с идентификаторами всех
существующие транзакции. Если такая транзакция существует, ее состояние обновляется
из сообщения.

В предыдущем SIP RFC2543 идентификатор транзакции рассчитывался как хэш
все важные поля заголовка сообщения (включая To, From, Request-URI и
CSeq). Это оказалось очень медленным и сложным во время тестов на совместимость, таких как
идентификаторы транзакций были частым источником проблем.

В новом RFC3261 способ вычисления идентификаторов транзакций был полностью
изменилось. Вместо сложного хеширования важных полей заголовка теперь SIP-сообщение
включает идентификатор напрямую. Параметр ветвления полей заголовка Via содержит непосредственно
идентификатор транзакции. Это значительное упрощение, но все еще существуют старые
реализации, которые не поддерживают новый способ вычисления идентификатора транзакции, поэтому
даже новые реализации должны поддерживать старый способ.Они должны быть обратно совместимы.

Рисунок 5, «Транзакции SIP» показывает, какие сообщения каким транзакциям принадлежат.
во время разговора двух пользовательских агентов.

Рисунок 5. Транзакции SIP

Мы показали, что такое транзакции, что одна транзакция включает INVITE, и это
ответов, а другая транзакция включает BYE, и она отвечает, когда сеанс
сносят.Но мы считаем, что эти две транзакции должны как-то
связанные - оба принадлежат одному диалогу . Диалог
представляет собой одноранговые SIP-отношения между двумя пользовательскими агентами. Диалог
сохраняется в течение некоторого времени, и это очень важная концепция для пользовательских агентов. Диалоги
облегчить правильную последовательность и маршрутизацию сообщений между конечными точками SIP.

Диалоги идентифицируются с помощью Call-ID, From tag и To.
тег. Сообщения с одинаковыми тремя идентификаторами принадлежат
тот же диалог.Мы показали, что поле заголовка CSeq используется для упорядочивания
messages, фактически он используется для упорядочивания сообщений в диалоге. В
число должно монотонно увеличиваться для каждого сообщения, отправленного в
диалоговое окно, иначе одноранговый узел будет обрабатывать его как запрос вне очереди
или ретрансляция. Фактически, номер CSeq идентифицирует
транзакции в диалоге, потому что мы сказали, что запросы и
связанные ответы называются транзакцией. Это означает, что только
одна транзакция в каждом направлении может быть активной в течение
диалог.Можно также сказать, что диалог - это последовательность
Сделки . Рисунок 6, «Диалог SIP» расширяет Рисунок 5, «Транзакции SIP», чтобы показать, какие сообщения принадлежат
тот же диалог.

Некоторые сообщения устанавливают диалог, а некоторые нет. Это позволяет явно выразить
взаимосвязь сообщений, а также для отправки сообщений, не связанных с другими
сообщения вне диалога. Это проще реализовать, потому что у пользовательского агента нет
чтобы сохранить состояние диалога.

Например, сообщение INVITE устанавливает диалог, потому что за ним последуют
по запросу BYE, который прервет сеанс, установленный INVITE. Это пока
отправляется в диалоге, установленном сообщением INVITE.

Но если пользовательский агент отправляет запрос MESSAGE, такой запрос не устанавливает никаких
диалог. Любые последующие сообщения (даже СООБЩЕНИЕ) будут отправлены независимо от
Предыдущая.

1.6.1. Диалоги упрощают маршрутизацию

Мы уже говорили, что диалоги также используются для маршрутизации сообщений между пользователями.
агенты, опишем это немного.

Предположим, что пользователь sip: [email protected] хочет поговорить с пользователем sip: [email protected]. Он
знает SIP-адрес вызываемого абонента (sip: [email protected]), но этот адрес не говорит
что-либо о текущем местоположении пользователя - т.е. звонящий не знает
на какой хост отправить запрос.Поэтому запрос INVITE будет отправлен на
прокси-сервер.

Запрос будет отправлен с прокси на прокси, пока не достигнет того, кто знает
текущее местонахождение вызываемого. Этот процесс называется маршрутизацией. Как только запрос
достигает вызываемого, пользовательский агент вызываемого создает ответ, который будет
отправлено обратно вызывающему абоненту. Пользовательский агент Callee также поместит поле заголовка контакта
в ответ, который будет содержать текущее местоположение пользователя. В
исходный запрос также содержал поле заголовка контакта, что означает, что оба пользователя
агенты знают текущее местоположение партнера.

Поскольку пользовательские агенты знают местоположение друг друга, нет необходимости отправлять
дальнейшие запросы к любому прокси - они могут быть отправлены напрямую от пользовательского агента пользователю
агент. Именно так диалоги упрощают маршрутизацию.

Дальнейшие сообщения в диалоговом окне отправляются непосредственно от пользовательского агента пользователю.
агент. Это значительное улучшение производительности, поскольку прокси-серверы не видят
все сообщения в диалоге, они используются для маршрутизации только первого запроса
что устанавливает диалог.Прямые сообщения также доставляются с большим количеством
меньшая задержка, потому что типичный прокси обычно реализует сложную маршрутизацию
логика. Рисунок 7, «Трапеция SIP» содержит пример сообщения.
в диалоговом окне (BYE), которое обходит прокси.

Рис. 7. Трапеция SIP

1.6.2. Идентификаторы диалогов

Мы уже показали, что идентификаторы диалогов состоят из трех частей: Call-Id,
From tag и To tag, но не совсем понятно, почему идентификаторы диалога
создан именно таким образом и кто какую часть вносит.

Call-ID - это так называемый идентификатор вызова . Это должно быть уникальное
строка, идентифицирующая вызов. Вызов состоит из одного или нескольких диалогов. Множественный
пользовательские агенты могут отвечать на запрос, когда прокси на пути разветвляет
запрос. Каждый пользовательский агент, отправляющий 2xx, устанавливает отдельный диалог с
звонящий. Все такие диалоги являются частью одного вызова и имеют один и тот же Call-ID.

Тег From создается вызывающей стороной и однозначно идентифицирует диалог в
пользовательский агент вызывающего абонента.

Тег To создается вызываемым пользователем и однозначно идентифицирует, как и тег From,
диалог в пользовательском агенте вызываемого.

Этот идентификатор иерархического диалога необходим, потому что один вызов
приглашение может создать несколько диалогов, и вызывающий должен уметь различать
их.

1,7. Типичные сценарии SIP

В этом разделе дается краткий обзор типичных сценариев SIP, которые обычно составляют
SIP трафик.

Пользователи должны зарегистрироваться у регистратора, чтобы другие
пользователей. Регистрация состоит из сообщения REGISTER, за которым следует сообщение 200 OK, отправленное
регистратора, если регистрация прошла успешно. Регистрации обычно
авторизован, поэтому может появиться ответ 407, если пользователь не предоставил действительный
учетные данные. На рисунке 8, «Поток сообщений REGISTER» показан пример регистрации.

Рисунок 8.РЕГИСТРАЦИЯ потока сообщений

1.7.2. Приглашение на сеанс

Приглашение к сеансу состоит из одного запроса INVITE, который обычно отправляется
прокси. Прокси-сервер немедленно отправляет 100 попыток ответа, чтобы остановить повторную передачу.
и пересылает запрос дальше.

Все предварительные ответы, созданные вызываемым пользователем, отправляются обратно вызывающему абоненту.Увидеть
180 Ответ на звонок в потоке вызовов. Ответ генерируется, когда вызываемый
телефон начинает звонить.

Рисунок 9. Поток сообщений INVITE

200 OK генерируется, когда вызываемый абонент поднимает трубку, и он повторно передается.
агентом пользователя вызываемого, пока он не получит ACK от вызывающего. Сессия
установлено на этом этапе.

1.7.3. Завершение сеанса

Завершение сеанса выполняется путем отправки запроса BYE в диалоговом окне
установлено до свидания INVITE. Сообщения BYE отправляются напрямую от одного пользовательского агента к
другой, если прокси на пути запроса INVITE не указал, что он
желает оставаться на пути, используя маршрутизацию записей (см. Раздел 1.7.4, «Маршрутизация записей».

Сторона, желающая прервать сеанс, отправляет другой стороне запрос BYE
участвует в сеансе.Другой абонент отправляет ответ 200 OK, чтобы подтвердить
BYE, и сеанс завершается. См. Рисунок 10, «Поток сообщений BYE (с маршрутизацией записи и без нее)», левое сообщение
течь.

Все запросы, отправленные в диалоговом окне, по умолчанию отправляются напрямую от одного пользовательского агента.
к другому. Только запросы вне диалога проходят через SIP-прокси. Этот подход
делает сеть SIP более масштабируемой, поскольку попадает только небольшое количество сообщений SIP
прокси.

Существуют определенные ситуации, в которых прокси-сервер SIP должен оставаться на пути всех
дальнейшие сообщения. Например, прокси, управляющие блоком NAT, или прокси, выполняющие
бухгалтерский учет должен оставаться на пути BYE-запросов.

Механизм, с помощью которого прокси может сообщить пользовательским агентам, что он хочет остаться на пути
всех дальнейших сообщений называется маршрутизацией записи . Такой прокси
будет вставлять поле заголовка Record-Route в сообщения SIP, которые содержат адрес
прокси.Сообщения, отправленные в диалоговом окне, будут проходить через все прокси-серверы SIP, которые
поместите в сообщение поле заголовка Record-Route.

Получатель запроса получает набор полей заголовка Record-Route в
сообщение. Он должен отражать все поля заголовка Record-Route в ответах, потому что
отправителю запроса также необходимо знать набор прокси.

Рисунок 10. Поток сообщений BYE (с маршрутизацией записи и без нее)

Левый поток сообщений на рисунке 10, «Поток сообщений BYE (с маршрутизацией записи и без нее)» показывает, как BYE (запрос
в диалоге, установленном INVITE) отправляется непосредственно другому пользовательскому агенту
когда в сообщении нет поля заголовка Record-Route.Правильный поток сообщений
показать, как меняется ситуация, когда прокси помещает поле заголовка Record-Route
в сообщение.

1.7.4.1. Строгая и свободная маршрутизация

То, как работает маршрутизация записей, изменилось. Запись маршрутизации в соответствии с
RFC2543 переписал Request-URI. Это означает, что Request-URI всегда
содержит URI следующего перехода (который может быть следующим прокси-сервером,
вставленное поле заголовка Record-Route или целевой пользовательский агент).Из-за
что необходимо было сохранить исходный Request-URI как последний маршрут
поле заголовка. Такой подход называется строгой маршрутизацией .

Свободная маршрутизация , как указано в RFC3261, работает в
немного иначе. Request-URI больше не перезаписывается, он всегда
содержит URI целевого пользовательского агента. Если есть заголовок Route
поле в сообщении, то сообщение отправляется на URI из самого верхнего
Поле заголовка маршрута.Это существенное изменение - Request-URI не
обязательно содержать URI, на который будет отправлен запрос. Фактически, свободный
маршрутизация очень похожа на маршрутизацию от источника IP.

Потому что переход от строгой маршрутизации к свободной маршрутизации прервался бы в обратном направлении
совместимость и старые пользовательские агенты не будут работать, необходимо сделать
свободная маршрутизация с обратной совместимостью. Обратная совместимость
к сожалению, это увеличивает накладные расходы и часто является источником серьезных проблем.

1.7.5. Подписка на мероприятие и уведомление

Спецификация SIP была расширена для поддержки общего механизма, позволяющего
подписка на асинхронные события. Такие мероприятия могут включать статистику прокси SIP.
изменения, информация о присутствии, изменения сеанса и т. д.

Механизм используется в основном для передачи информации о присутствии (готовность
общаться) пользователей.На рисунке 11, «Подписка на события и уведомление» показано основное сообщение.
течь.

Рисунок 11. Подписка и уведомление о событиях

Пользовательский агент, заинтересованный в уведомлении о событии, отправляет сообщение ПОДПИСАТЬСЯ на
SIP сервер. Сообщение ПОДПИСАТЬСЯ устанавливает диалог и немедленно
ответил сервер, используя ответ 200 OK. На этом этапе диалог
установлено.Сервер отправляет пользователю запрос NOTIFY каждый раз, когда событие
изменения, на которые подписался пользователь. Сообщения NOTIFY отправляются в диалоговом окне
установленный ПОДПИСАТЬСЯ.

Обратите внимание, что первое сообщение NOTIFY на рисунке 11, «Подписка на событие и уведомление» отправляется.
независимо от какого-либо события, вызывающего уведомления.

Подписки, а также регистрации имеют ограниченный срок действия и, следовательно, должны быть
периодически обновляется.

Мгновенные сообщения отправляются с использованием запроса MESSAGE. Запросы MESSAGE не устанавливают
диалог, и поэтому они всегда будут проходить через один и тот же набор прокси. Это
простейшая форма отправки мгновенных сообщений. Текст мгновенного сообщения
транспортируется в теле SIP-запроса.

Рисунок 12. Мгновенные сообщения

Настройки SIP

Разрешить повторное приглашение RTP	По умолчанию система будет маршрутизировать медиапотоки с SIP. конечные точки через себя.Включение этой опции приводит к тому, что система чтобы попытаться согласовать конечные точки для маршрутизации пакетов к каждому другие напрямую, передавая систему. Это не всегда возможно для системы для согласования среды конечной точки к конечной точке маршрутизация.
Пользовательский агент	Измените поле User-Agent.
Отправить удаленный идентификатор участника	Отправлять или нет Remote-Party-ID в заголовке SIP. Примечание. Эта конфигурация действует только на внутренние звонки. Чтобы настроить внешние вызовы, настройте Расширенные настройки SIP хобот.
Отправить P Подтверждено Идентифицировать	Следует ли отправлять P-Asserted-Identify в заголовке SIP или нет. Примечание. Эта конфигурация действует только на внутренние звонки. Чтобы настроить внешние вызовы, настройте Расширенные настройки SIP хобот.
Отправить Diversion ID	Указывает, отправлять ли переадресацию в заголовке SIP или нет. Если это выбран вариант, значение переадресации будет расширено число. Примечание. Эта конфигурация действует только на внутренние звонки. Чтобы настроить внешние вызовы, настройте Расширенные настройки SIP хобот.
Поддержка Early Media	Поддерживать ли Early Media или нет.
Режим полной занятости для разветвления SIP	Отметьте этот вариант: Когда один из терминалов, зарегистрировать тот же внутренний номер занят во время разговора, другие терминалы не будут принимать звонки. Снимите отметку с этого параметра: когда один терминал занят, другие терминалы по-прежнему смогут принимать и принимать звонки.
Внутренний ход	Этот параметр Inband Progress применяется ко всем добавочным номерам. Примечание. Чтобы настроить глобальную настройку Inband Progress, вам потребуется связаться со службой поддержки Yeastar для настройки пользовательской конфигурации файл. Отметьте эту опцию: УАТС будет отправлять 183 сеанс Переход к расширению, когда будет сказано указать звонит и сразу начинает посылать звонок как аудио. Снимите отметку с этого параметра: УАТС будет отправлять звонок 180 на добавочный номер при указании звонка и будет НЕ отправляйте его как аудио.
Получить идентификатор вызывающего абонента от	Решите, из какого заголовка система будет извлекать идентификатор вызывающего абонента. поле.
Получить DID от	Решите, из какого поля заголовка система будет извлекать DID. Примечание. Если выбран Remote-Party-ID, но магистраль SIP не поддерживает это, система получит DID от Заголовок INVITE.
100рел	Поддерживать ли 100rel или нет.
Разрешить гостю	Если выбрана эта опция, УАТС будет принимать неизвестные звонки.
Запрос на сообщение службы поддержки	Следует ли поддерживать запрос сообщения SIP или нет.
Максимальное время	Выберите или введите значение Maxptime.
Уведомить идентификатор вызывающего абонента	Если этот флажок установлен, при входящем вызове внутреннего абонента А УАТС будет отправить информацию об идентификаторе вызывающего абонента на добавочный номер, у которого подписался на статус звонка А. Отображение идентификатора вызывающего абонента информация может быть полезной, чтобы помочь агенту решить, следует ли принять входящий звонок.Эта опция отключена по умолчанию.
DTMF Passthrough	Если включен DTMF Passthrough, PBX не будет обрабатывать DMTF тонов и прозрачно передавать тона DTMF другим конец.
Включить соединение uaCSTA	Если эта опция включена, УАТС будет использовать uaCSTA (Пользователь Телекоммуникационное приложение, поддерживаемое компьютером агента) на удаленно управлять IP-телефоном через Linkus Desktop Client CTI.Ваш IP-телефон должен поддерживать стандарт uaCSTA, чтобы использовать этот функция.

Сип минимальное сечение: СИП провода: особенности, виды, монтаж изделий

Ошибки при строительстве воздушных линий электропередачи напряжением до 1 кВ с использованием СИП

Сип кабель таблица сечений

Виды кабелей СИП, сечение и конструктивные особенности

Конструкция СИП

Виды и строение

Выбор сечения СИП

Провода. Линейная арматура. / ПУЭ 7 / Библиотека / Элек.ру

Провода, арматура / Правила устройства ВЛЭП с СИП / Библиотека / Элек.ру

Пропускная способность провода сип. Виды кабелей сип, сечение и конструктивные особенности

Конструкция СИП

Виды и строение

Выбор сечения СИП

СИП провод: назначение, применение — Электрик Ступино

Конструкция СИП провода:

Область применения СИП провода

Преимуще

RFC 4412 — Приоритет коммуникационных ресурсов для протокола инициации сеанса (SIP)

RFC 3903 — Расширение протокола инициирования сеанса (SIP) для публикации состояния события

Параметры протокола инициации сеанса (SIP)

1. Введение в SIP

1.3. Сетевые элементы SIP

1.3.2.1. Серверы без сохранения состояния

1.3.2.2. Серверы с отслеживанием состояния

1.3.2.3. Использование прокси-сервера

1.6.1. Диалоги упрощают маршрутизацию

1.6.2. Идентификаторы диалогов

1,7. Типичные сценарии SIP

1.7.2. Приглашение на сеанс

1.7.3. Завершение сеанса

1.7.4.1. Строгая и свободная маршрутизация

1.7.5. Подписка на мероприятие и уведомление

Настройки SIP

alexxlab

Добавить комментарий Отменить ответ

Ошибки при строительстве воздушных линий электропередачи напряжением до 1 кВ с использованием СИП

Сип кабель таблица сечений

Виды кабелей СИП, сечение и конструктивные особенности

Конструкция СИП

Виды и строение

Выбор сечения СИП

Провода. Линейная арматура. / ПУЭ 7 / Библиотека / Элек.ру

Провода, арматура / Правила устройства ВЛЭП с СИП / Библиотека / Элек.ру

Пропускная способность провода сип. Виды кабелей сип, сечение и конструктивные особенности

Конструкция СИП

Виды и строение

Выбор сечения СИП

СИП провод: назначение, применение — Электрик Ступино

Конструкция СИП провода:

Область применения СИП провода

Преимуще

RFC 4412 — Приоритет коммуникационных ресурсов для протокола инициации сеанса (SIP)

RFC 3903 — Расширение протокола инициирования сеанса (SIP) для публикации состояния события

Параметры протокола инициации сеанса (SIP)

1. Введение в SIP

1.3. Сетевые элементы SIP

1.3.2.1. Серверы без сохранения состояния

1.3.2.2. Серверы с отслеживанием состояния

1.3.2.3. Использование прокси-сервера

1.6.1. Диалоги упрощают маршрутизацию

1.6.2. Идентификаторы диалогов

1,7. Типичные сценарии SIP

1.7.2. Приглашение на сеанс

1.7.3. Завершение сеанса

1.7.4.1. Строгая и свободная маршрутизация

1.7.5. Подписка на мероприятие и уведомление

Настройки SIP

alexxlab

Вам также может понравиться

0 логики: Книга Наука логики (Гегель Г. ISBN: 978-5-17-107096-0) — купить в книжном интернет-магазине по цене 776 руб

Примеры магнитные и электрические явления: Электрические и магнитные явления примеры. Электрические явления

Как зарегистрировать тсж: Как организовать ТСЖ в многоквартирном доме

Добавить комментарий Отменить ответ