Сип 2 расчет сечения: Расчет сечения провода сип по мощности

Разное

Содержание

Сколько киловатт выдержит СИП?

 

   Просматривая простоты интернета на предмет электромонтажа, обнаружил на одном форуме тему с обсуждением «выдержит ли сип 4х16 15квт». Вопрос возникает потому что на подключение частного дома выделяют 15 кВт 380 вольт. Ну и народ интересуется не маловато ли заложить 16 квадрат на ответвление от воздушной линии? Заглянул я счанала в ПУЭ, но почему то на тему мощности СИПа ничего там не нашел.

  Вот есть только табличка 1.3.29 «Допустимый длительный ток для неизолированных проводов по ГОСТ 839-80». И по ней видно что максимальный допустимый ток для сечения 16кв. мм. провода типа АС, АСКС, АСК вне помещения составляет 111 ампер. Ну хоть что то для начала. 

Сколько киловатт выдержит СИП 4х16?

  Но зато есть ГОСТ  31943-2012 «Провода самонесущие изолированные и защищенные для воздушных линий электропередачи». В конце госта, в пункте 10 указания по эксплуатации, есть табличка 

Сколько киловатт выдерживает СИП — таблица:












Сечение СИП напряжение 380В (3х фазная нагрузка) напряжение 220В (1фазная нагрузка)
СИП 4х16 62 кВт 22 кВт
СИП 4х25 80 кВт 29 кВт
СИП 4х35 99 кВт 35 кВт
СИП 4х50 121 кВт 43 кВт
СИП 4х70 149 кВт 53 кВт
СИП 4х95 186 кВт 66 кВт
СИП 4х120 211 кВт 75 кВт
СИП 4х150 236 кВт 84 кВт
СИП 4х185 270 кВт 96 кВт
СИП 4х240 320 кВт 113 кВт

Методика расчета (update от 19. 02.2018)

  Берем табличку 10 и по ней находим что одна жила сипа 16 кв.мм. выдерживает — 100 ампер. Далее берем следующие формулы расчета:

   для однофазной нагрузки 220В P=U*I

   для трехфазной нагрузки 380В P=(I1+I2+I3)\3*cos φ*1,732*0,38

  update от 19.02.2018 Что касается расчета мощности для трехфазной нагрузки, необходимо понимать что многое зависит от типа потребителей (точнее какую нагрузку они предоставляют активную или реактивную, от этого зависит какой cos φ нужно подставлять в формулу, в данном случае для расчетов он равен 0.95)

  Дорогие посетители сайта и я возможно бы не заметил ваши колкие, но технически верные комментарии к статье если бы мне, как раз сегодня мне позвонил человек с вопросом : «какой сип мне нужен под 120 кВт?». По табличке ему отлично подойдет СИП сечением 50мм кв. Даже если опустить тот факт что длина линии влияет на падение напряжения (у него 150 метров), не стоит забывать что нагрузка по фазам может разниться, что видно из формулы — там берется средняя велечина по трем фазам. Тут просто надо понимать что ток по фазе может превысить  предельно допустимые значения для данного сечения провода.

  Поэтому если значение необходимой вам нагрузки лежит ближе 10% к табличному, следует выбирать более крупное сечения сипа по списку. Поясню на примере 120 квт. По таблице для этой трехфазной нагрузки подходит СИП сечением токопроводящих жил 50мм, однако это меньше 10%. То есть 121кВт*0.9=109 кВт. Соотвественно нужно выбирать СИП 3х70+1х54.6.

В начале темы поднимался вопрос «выдержит ли сип 4х16 15квт»? Поэтому для частного дома мы умножаем 220Вх100А=22кВт по фазе. Но не забываем что фазы то у нас три. А это уже 66 киловатт суммарно для жилого дома. Что представляет собой 4х кратный запас относительно выдаваемых техусловий.

  

сечение, вес, диаметр, мощность – Справочник электрика


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


Табл. 1. Основные характеристики в зависимости от марки кабеля СИП-1















Количество жил, шт.


Количество проволок и диаметр, шт. и мм


Наружный диаметр провода, мм


Сечение, мм2


Масса 1 км провода, кг


Электрическое сопротивление жил, Ом/км


Сила тока нагрузки, не более, А


1


7х1,79


15


16


159,29


1,9


75


1


7х2,23


15


25


159,29


2,3


75


2


7х1,79


13


16


159,29


1,9


70


2


7х2,23


15


25


159,29


2,3


95


3


7х1,79


22


16


294,48


1,9


70


3


7х2,23


26


25


434,19


2,3


95


3


7х2,69


30


35


600,04


5,6


115


3


7х3,28


41


50


815,64


7,3


140


3


7х3,82


45


70


1122,41


10,8


180


3


19х3,00


47


120


1620,18


16,8


250


4


7х1,79


22


16


1620,18


1,9


70


4


7х2,23


26


25


1620,18


2,3


95


 


Теперь подробнее о технических характеристиках самонесущего провода СИП, которые указаны в таблице. Например, на трехжильную линию под максимальную нагрузку в 220А приобретают марку с сечением 120 мм2. При этом учитывают, что каждый метр давит на крепежные элементы массой минимум 1,62 кг. Провод СИП с такими токовыми характеристиками нужен для работы на линии 220В (фаза, ноль и заземление).


Количество и диаметр проволоки


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


Наружный диаметр провода


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


Сечение


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


Масса 1 км провода


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


Электрическое сопротивление жил


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


Сила тока нагрузки


Еще один критерий, связанный с выбором сечение провода СИП по току, таблице мощности. Этот параметр часто и является основным при подборе надежной марки.

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

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

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

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

Какие виды проводов существуют

  • Сип -1 и Сип -2 используются в основном для магистральных ЛЭП либо их ответвлений, имеющих напряжение 0,6-1 кВ;
  • Сип – 3 также применяется для воздушных магистралей, но рассчитан на гораздо более высокие нагрузки — в 10 — 35 кВ;
  • СИП – 4 не имеет несущей жилы, прокладывается в основном по стенам зданий и сооружений, а основная сфера его использования – ответвления от магистралей для подведения электричества конечным потребителям.

Как выбрать сечение?

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

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

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

Для разных сечений этот показатель различен:

  • 16 мм2 — 100 А;
  • 25 мм2 – 130 А;
  • 35 мм2 — 160 А;
  • 50 мм2 — 195 А;
  • 70 мм2 — 240 А;
  • 95 мм2 — 300 А;
  • 120 мм2 — 340 А;
  • 150 мм2 — 380 А;
  • 185 мм2 — 436 А;
  • 240 мм2 — 515 А;

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

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

В стандартной бытовой сети электроснабжения не возникает существенных перегрузок, а температура окружающей среды не выходит за рамки — 50 — + 60 градусов.

Выбор изоляции провода

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

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

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

Производство и продажа

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

Все требования к проводам СИП представлены в соответствующем ГОСТе, и если продукция конкретного предприятия не соответствует ему, она просто не попадет на рынок.

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

Кабель СИП-1, СИП -2,3, 4: технические характеристики провода СИП

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

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

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

Достоинства кабеля

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

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

Типоразмеры

Площадь основных жил и допустимые нагрузки по току для них:

  • 16 мм2 — 100 А;
  • 25 мм2 — 130 А;
  • 35 мм2 — 160 А;
  • 50 мм2 — 195 А;
  • 70 мм2 — 240 А;
  • 95 мм2 — 300 А;
  • 120 мм2 — 340 А;
  • 150 мм2 — 380 А;
  • 185 мм2 — 436 А;
  • 240 мм2 — 515 А;

Токовые нагрузки указываются для температуры воздуха в 25 °С, ветра со скоростью 0,6 м/с и ультрафиолетового излучения 1000 Вт/м2, для иных условий применяются поправочные коэффициенты.

Сечение несущей жилы имеет площадь (в мм2):

Таблица 1. Краткая техническая характеристика проводов СИП
Марка провода СИП-1 СИП-2 СИП-3 СИП-4 СИП-5
Количество токопроводящих жил, шт 1 ÷ 4 1 ÷ 4 1 2 — 4 2 — 4
Сечение жил, мм2 16 ÷ 120 16 ÷ 120 35 ÷ 240 16 ÷ 120 16 ÷ 120
Нулевая жила, несущая сплав алюминия (со стальным сердечников)  сплав алюминия (со стальным сердечников) отсутствует отсутствует отсутствует
Токопроводящая жила алюминиевая алюминиевая сплав алюминия (со стальным сердечников) алюминиевая алюминиевая
Класс напряжения, кВ 0.4 ÷ 1 0.4 ÷ 1 10 ÷ 35 0.4 ÷ 1 0.4 ÷ 1
Тип изоляции жил термопластичный полиэтилен светостабилизир. полиэтилен светостабилизир. полиэтилен термопластичный полиэтилен светостабилизир. полиэтилен
Температура эксплуатации -60оС ÷ +50оС -60оС ÷ +50оС -60оС ÷ +50оС -60оС ÷ +50оС -60оС ÷ +50оС
Допустимый нагрев жил при эксплуатации  +70оС  +90оС  +70оС  +90оС +90оС
min радиус изгиба провода  не менее 10 Ø  не менее 10 Ø  не менее 10 Ø  не менее 10 Ø  не менее 10 Ø
 Срок службы  не менее 40 лет  не менее 40 лет  не менее 40 лет  не менее 40 лет  не менее 40 лет
Применение
  • — ответвлений от ВЛ;
  • — ввод питания в жилые помещения;
  • — хоз. постройки;
  • — прокладка по стенам зданий и сооружений.
 — — для монтажа ВЛ напряжением 10-35 кВ
  • — ответвлений от ВЛ;
  • — ввод питания в жилые помещения;
  • — хоз. постройки;
  • — прокладка по стенам зданий и сооружений.

Читайте также: «Применение и монтаж СИП«

Строение провода

Жилы имеют круглую форму, в готовом проводе скручиваются между собой с шагом от 80 до 150 см в зависимости от их сечения. Токопроводящие жилы выполняются как из алюминия, так и из его сплавов (в случае СИП-3), несущие – исключительно из сплавов алюминия. Для сечений до 95 мм2 жила состоит из 7 проволок, для остальных – из 19. Провод с сечением в 95 мм2 может выполняться в обоих вариантах.

Несущая жила имеет прочность в среднем в 2-2,5 раза больше, чем токопроводящая такого же сечения. Для алюминиевой проволоки устанавливается прочность на растяжение не менее 120 Н/мм2, для проволоки из сплавов алюминия этот показатель существенно выше – не менее 295 Н/мм2.

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

Читайте также: «Где купить СИП?»

Условия эксплуатации

Изолированный провод может работать при температуре в окружающей среде в диапазоне от — 60 °С до + 50 °С, но монтаж можно производить при морозах только до -20°С. В процессе эксплуатации допускается нагрев жил провода до 70-90°С. Кратковременно температура может подниматься даже до 130°С. В случае короткого замыкания провод нагревается до 250°С.

Изгибать провод при монтаже можно с радиусом не менее 10 диаметров этого провода.

Виды СИП-кабеля

Провода подразделяются на 4 основные типа.

  • СИП-1 и СИП-2 применимы как для магистральных воздушных ЛЭП, так и их ответвлений, рассчитаны на напряжение 0,6-1 кВ. Несущая жила в СИП-1 неизолированная, в отличие от СИП-2.
  • В СИП-3 жилы выполнены из алюминиевого сплава с изоляцией из экструдированных полимеров. Такие провода используются для воздушных линий электропередач, где номинальное напряжение имеет показатели в 10, 20 либо 35 кВ.
  • В СИП-4 несущая жила отсутствует, поэтому такой тип применяется исключительно для линейных ответвлений воздушных магистралей и прокладывается по поверхности стен зданий и сооружений.

Для регионов с повышенной влажностью выпускаются специальные герметизированные провода, имеющие, соответственно, в маркировке букву «г». Для них ГОСТ устанавливает требования по устойчивости к продольному распространению воды. Этот показатель не должен превышать 3 м вдоль провода от места ее проникновения.

Большинство производителей устанавливает на самонесущие провода гарантию в 3-4 года, при этом срок их службы должен быть не менее 40 лет.

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

СИП — самонесущий изолированный провод, предназначенный для организации воздушных силовых линий, осветительных сетей и ответвлений к вводам в дома и постройки, на переменное напряжение 0,66/1 кВ номинальной частотой 50 Гц.

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

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

Характеристики проводов СИПт-1, СИПт-2, СИП-1, СИП-2, СИП-2а

предельно допустимая температура нагрева жил кабелей в аварийном режиме
(или режиме перегрузки):

80°С для СИПт   и   130°С для СИП-1, СИП-2.
номинальное напряжение — 0,6/1 кВ.
относительная влажность воздуха (при температуре до 35 °С) — 98%.
максимальная температура нагрева жил при коротком замыкании — 135°С для СИПт   и   250°С для СИП-1, СИП-2.
предельная длительно допустимая рабочая температура жил — 70°С для СИПт   и   90°С для СИП-1, СИП-2 – 90°С.
срок службы — 30 лет.
температура окружающей среды при эксплуатации кабеля — от -50°С до 50°С.
минимально допустимый радиус изгиба при прокладке — 10 диаметров кабеля.
минимальная температура прокладки кабеля без предварительного подогрева — -20°С.
гарантийный срок эксплуатации кабеля — 3 года.

Характеристики СИП-3а

минимально допустимый радиус изгиба при прокладке — 10 диаметров кабеля.
срок службы не менее — 40 лет.
гарантийный срок эксплуатации кабеля — 3 года.
минимальная температура прокладки кабеля без предварительного подогрева — -20°С.
номинальное напряжение — до 20 кВ, 35 кВ.
температура окружающей среды при эксплуатации кабеля — от -60°С до 50°С.
максимальная температура нагрева жил при коротком замыкании — 250°С.
относительная влажность воздуха (при температуре до 35 °С) — 98%.
предельная длительно допустимая рабочая температура жил — 90°С.
предельно допустимая температура нагрева жил кабелей в аварийном режиме (или режиме перегрузки) — 130°С.

Характеристики СИП-4, СИПс-4, СИПн-4

максимальная температура нагрева жил при коротком замыкании — 135°С для СИП-4, СИПн-4   и   250°С для СИПс-4.
предельная длительно допустимая рабочая температура жил — 70°С для СИП-4, СИПн-4   и   90°С для СИПс-4.
гарантийный срок эксплуатации кабеля — 3 года.
срок службы не менее — 30 лет.
минимально допустимый радиус изгиба при прокладке — 7,5 диаметров кабеля.
минимальная температура прокладки кабеля без предварительного подогрева — -20°С.
относительная влажность воздуха (при температуре до 35 °С) — 98%.
номинальное напряжение — 0,6/1 кВ.
предельно допустимая температура нагрева жил кабелей в аварийном режиме (или режиме перегрузки) — 80°С для СИП-4, СИПн-4   и   130°С для СИПс-4.
температура окружающей среды при эксплуатации кабеля — от -50°С до 50°С.

Номинальный наружный диаметр, мм Расчетный наружный диаметр провода, мм Расчетная масса 1 км провода, кг
СИП-1
1×16+1×25 15 135
3×16+1×25 22 270
3×25+1×35 26 390
3×35+1×50 30 530
3×50+1×50 32 685
3×50+1×70 35 740
3×70+1×70 37 930
3×70+1×90 41 990
3×95+1×70 41 1190
3×95+1×95 43 1255
3×120+1×95 46 1480
3×150+1×95 48 1715
3×185+1×95 52 2330
3×240+1×95 56 2895
СИП-2
3×16+1×25 24 308
3×16+1×54.6 28 427
3×25+1×35 27 424
3×25+1×54,6 30 512
3×35+1×50 31 571
3×35+1×54.6 32 606
3×50+1×50 34 727
3×50+1×54.6 35 762
3×50+1×70 36 798
3×70+1×54.6 39 973
3×70+1×70 40 1010
3×70+1×95 41 1087
3×95+1×70 43 1240
3×95+1×95 45 1319
3×120+1×95 48 1553
3×150+1×95 50 1787
3×185+1×95 55 2403
3×240+1×95 60 2968
СИП-3
1×35 12 165
1×50 13 215
1×70 15 282
1×95 16 364
1×120 18 445
1×150 19 540
1×185 21 722
1×240 24 950
СИП-3
1×35 14 209
1×50 16 263
1×70 17 334
1×95 19 421
1×120 20 518
1×150 22 618
1×185 24 808
1×240 26 1045
СИП-4
2×16 15 139
4×16 18 278
2×25 17 196
4×25 21 392

Номенклатура проводов марки СИП:

СИП-1 3×16+1×25

СИП-1 3×25+1×35

СИП-1 3×35+1×50

СИП-1 3×50+1×50

СИП-1 3×50+1×70

СИП-1 3×70+1×70

СИП-1 3×70+1×95

СИП-1 3×95+1×70

СИП-1 3×95+1×95

СИП-1 3×120+1×95

СИП-1 3×150+1×95

СИП-1 3×185+1×95

СИП-1 3×240+1×95

СИП-2 3×16+1×25

СИП-2 3×25+1×35

СИП-2 3×35+1×50

СИП-2 3×50+1×50

СИП-2 3×50+1×70

СИП-2 3×70+1×70

СИП-2 3×70+1×95

СИП-2 3×95+1×70

СИП-2 3×95+1×95

СИП-2 3×120+1×95

СИП-2 3×150+1×95

СИП-2 3×185+1×95

СИП-2 3×240+1×95

СИП-3 1х35

СИП-3 1х50

СИП-3 1х70

СИП-3 1х95

СИП-3 1х120

СИП-3 1х150

СИП-4 2х16

СИП-4 2×16

СИП-4 2×25

СИП-4 2×35

СИП-4 2×50

СИП-4 2×70

СИП-4 2×95

СИП-4 2×120

СИП-4 3×16

СИП-4 3×25

СИП-4 3×35

СИП-4 3×50

СИП-4 3×70

СИП-4 3×95

СИП-4 3×120

СИП-4 4×16

СИП-4 4×25

СИП-4 4×35

СИП-4 4×50

СИП-4 4×70

СИП-4 4×95

СИП-4 4×120

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


5. Выберите (провод, кабель или шина). 1.Провода, шнуры и кабели с резиновой или пластмассовой изоляцией. 2.Кабели с бумажной пропитанной изоляцией. 3.Неизолированные провода и шины. 4.Провода с изоляцией из сшитого полиэтилена.


Выберите тип провода или кабеля. 1.Медные с резиновой и ПВХ изоляцией. 2.Алюмин. с резиновой и ПВХ изоляцией. 3.Медные с резин. и ПВХ изол. в метал. защ. оболоч.4.Алюмин. с резин. и ПВХ изол. в метал. защ. оболоч.5.Медные шлангов., перенос. кабели, шахтные гибк., прожектор. кабели6.Медные шланговые с резиновой изоляцией для торфопредприятий. 7.Медные шланговые с резин. изол. для передв. электроприемников. 8.Медные с резин. изоляц. для электрифиц. транспорта 1, 3 и 4 кВ.


Выберите условия прокладки. Открыто. В трубе ( два одножильных). В трубе ( три одножильных). В трубе ( четыре одножильных). В трубе ( один двухжильный). В трубе ( один трехжильный).


Выберите условия прокладки. Открыто. В трубе ( два одножильных). В трубе ( три одножильных). В трубе ( четыре одножильных). В трубе ( один двухжильный). В трубе ( один трехжильный).


Выберите условия прокладки. Одножильные открыто Двухжильные проложенные в воздухе. Двухжильные провода проложенные в земле. Трехжильные проложенные в воздухе. Трехжильные проложенные в земле. Четырехжильные проложенные в воздухе. Четырехжильные проложенные в земле.


Выберите условия прокладки. Одножильные открыто Двухжильные проложенные в воздухе. Двухжильные провода проложенные в земле. Трехжильные проложенные в воздухе. Трехжильные проложенные в земле. Четырехжильные проложенные в воздухе. Четырехжильные проложенные в земле.


Выберите условия прокладки. Одножильные. Двухжильные. Трехжильные.


Выберите величину нарпяжения. Напряжение 0,5кВ. Напряжение 3кВ. Напряжение 6кВ.


Выберите величину нарпяжения. Напряжение 3кВ. Напряжение 6кВ.


Выберите условия прокладки. Провода под напряжением 1,3,4 кВ


Выберите тип провода или кабеля. 1.Медные с бумажной маслоканифольной в свинцовой оболочке, в земле. 2.Медные с бумажной маслоканифольной в свинцовой оболочке, в воде. 3.Медные с бумажной маслоканифольной в свинцовой оболочке, в воздухе. 4.Алюм. с бумажной маслоканифольной в свинцовой оболочке, в земле. 5.Алюм. с бумажной маслоканифольной в свинцовой оболочке, в воде. 6.Алюм. с бумажной маслоканифольной в свинцовой оболочке, в воздухе. 7.Медные трехжильные напр. 6 кВ в общей свинц. обол, в земле и воздухе. 8.Алюм. трехжильные напр. 6 кВ алюмин. в общей свинц. обол, в земле и воздухе. 9.Медные отдельно освинцов. с бум. изол., в земле, воде, воздухе. 10.Алюм. отдельно освинцов. с бум .изол., в земле, воде, воздухе.


Выберите условия прокладки. Одножильные до 1 кВ в земле. Двухжильные до 1 кВ в земле. Трехжильные до 3 кВ в земле. Трехжильные 6 кВ в земле. Трехжильные 10 кВ в земле. Четырехжильные до 1 кВ в земле.


Выберите условия прокладки. Ттрехжильные до 3 кВ в воде.Трехжильные до 6 кВ в воде.Трехжильных до 10 кВ в воде. Четырехжильные до 1 кВ в воде.


Выберите условия прокладки. Одножильные до 1 кВ в воздухе. Двухжильные до 1 кВ в воздухе.Трехжильные до 3 кВ в воздухе. Трехжильные 6 кВ в воздухе. Четырехжильные 1 кВ в воздухе.


Выберите условия прокладки. Одножильные до 1 кВ в земле.Двухжильные до 1 кВ в земле. Трехжильные до 3 кВ в земле. Трехжильные 6 кВ в земле. Четырехжильные до 1 кВ в земле.


Выберите условия прокладки. Трехжильные до 3 кВ в воде. Трехжильные 6 кВ в воде.Трехжильные 10 кВ в воде Четырехжильные до 1 кВ в воде.


Выберите условия прокладки. Одножильные до 1 кВ в воздухе. Двухжильные до 1 кВ в воздухе. Трехжильные до 3 кВ в воздухе.Трехжильные 6 кВ в воздухе. Трехжильные 10 кВ в воздухе. Четырехжильные 1 кВ в воздухе.


Выберите условия прокладки. Трехжильные 6 кВ в землеДвухжильные 6 кВ в воздухе


Выберите условия прокладки. Трехжильные 6 кВ в земле. Двухжильные 6 кВ в воздухе.


Выберите условия прокладки. Трехжильные 20 кВ в земле. Трехжильные 20 кВ в воде.Трехжильные 20 кВ в воздухе. Трехжильные 35 кВ в земле. Трехжильные 35 кВ в водеТрехжильные 35 кВ в воздухе


Выберите условия прокладки. Трехжильные 20 кВ в земле.Трехжильные 20 кВ в воде. Двухжильные 20 кВ в воздухе. Трехжильные 35 кВ в земле. Трехжильные 35 кВ в воде.Двухжильные 35 кВ в воздухе.


Выберите тип провода или шины. Неизолированные провода по ГОСТ 839-80 Шины прямоугольного сечения.


Выберите условия прокладки. Вне помещений АС, АСКС, АСК, АСКП. Внутри помещений АС, АСКС, АСК, АСКП. Вне помещений М. Вне помещений А, АКП. Внутри помещений М. Внутри помещений А и АКП.


Выберите материал и количество шин. Медные шины 1 шт на фазу или полюс. Медные шины 2 шт на фазу или полюс. Медные шины 3 шт на фазу или полюс. Медные шины 4 шт на фазу или полюс. Алюминиевые шины 1 шт на фазу или полюс. Алюминиевые шины 2 шт на фазу или полюс. Алюминиевые шины 3 шт на фазу или полюс. Алюминиевые шины 4 шт на фазу или полюс.


Выберите марку провода. СИП-3 СИП-4


Выберите условия прокладки. Открыто.


Выберите условия прокладки. Открыто.

1. Введение в SIP

Авторские права © 2003 FhG FOKUS

Аннотация

Краткий обзор 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 = "3cef753

0001771328f5ae1b8b7f0d742da1feb5753c", response = "53fe98db10e1074 b03b3e06438bda70f " Тип содержимого: application / 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, которые не вызывают ответа.

Типичный ответ выглядит так:

 СИП / 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. Подписка и уведомление о событиях

Пользовательский агент, заинтересованный в уведомлении о событии, отправляет сообщение SUBSCRIBE на
SIP сервер. Сообщение ПОДПИСАТЬСЯ устанавливает диалог и немедленно
ответил сервер, используя ответ 200 OK. На данный момент диалог
установлено.Сервер отправляет пользователю запрос NOTIFY каждый раз, когда событие
изменения, на которые подписался пользователь. Сообщения NOTIFY отправляются в диалоговом окне
установлен ПОДПИСАТЬСЯ.

Обратите внимание, что первое сообщение NOTIFY на рисунке 11, «Подписка на событие и уведомление» отправляется.
независимо от какого-либо события, вызывающего уведомления.

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

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

Рисунок 12. Мгновенные сообщения

RFC 3261 — SIP: протокол инициации сеанса (RFC3261)



Сетевая рабочая группа J.Розенберг
Запрос комментариев: 3261 Dynamicsoft
Устаревшие: 2543 H. Schulzrinne
Категория: Стандарты Track Columbia U.
                                                            Г. Камарильо
                                                                Ericsson
                                                             А. Джонстон
                                                                WorldCom
                                                             Дж.Петерсон
                                                                 Neustar
                                                               Р. Спаркс
                                                             Dynamicsoft
                                                              М. Хэндли
                                                                    ICIR
                                                             Э. Школьник
                                                                    AT&T
                                                               Июнь 2002 г.

                    SIP: протокол инициирования сеанса

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

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

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

   Авторское право (C) The Internet Society (2002). Все права защищены.

Аннотация

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

Содержание

   1 Введение ........................................ 8
   2 Обзор функций SIP ....................... 9
   3 Терминология ......................................... 10
   4 Обзор работы ............................... 10
   5 Структура протокола ........................... 18
   6 Определения ......................................... 20
   7 Сообщения SIP ........................................ 26
   7.1 Запросы ............................................ 27
   7.2 Ответы ........................................... 28
   7.3 Поля заголовка ....................................... 29
   7.3.1 Формат поля заголовка ................................. 30
   7.3.2 Классификация поля заголовка ......................... 32
   7.3.3 Компактная форма ........................................ 32
   7.4 Органы .............................................. 33
   7.4.1 Тип тела сообщения ................................... 33
   7.4.2 Длина тела сообщения ................................. 33
   7.5 Фрейминг сообщений SIP ................................ 34
   8 Общее поведение агента пользователя ......................... 34
   8.1 Поведение UAC ........................................ 35
   8.1.1 Формирование запроса.............................. 35
   8.1.1.1 Request-URI ......................................... 35
   8.1.1.2 К .............................................. .... 36
   8.1.1.3 Из .............................................. .. 37
   8.1.1.4 Call-ID ............................................ 37
   8.1.1.5 CSeq .............................................. .. 38
   8.1.1.6 Макс-вперед ........................................ 38
   8.1.1.7 Через ................................................. 39
   8.1.1.8 Контакт ............................................. 40
   8.1.1.9 Поддерживаемые и требуемые ............................... 40
   8.1.1.10 Дополнительные компоненты сообщения ....................... 41
   8.1.2 Отправка запроса ................................. 41
   8.1.3 Обработка ответов ................................ 42
   8.1.3.1 Ошибки на уровне транзакции ........................... 42
   8.1.3.2 Нераспознанные ответы.............................. 42
   8.1.3.3 Переходные отверстия .............................................. .. 43
   8.1.3.4 Обработка ответов 3xx ........................... 43
   8.1.3.5 Обработка ответов 4xx ........................... 45
   8.2 Поведение БПЛА ........................................ 46
   8.2.1 Проверка метода ................................... 46
   8.2.2 Проверка заголовка ................................... 46
   8.2.2.1 Кому и URI запроса.................................. 46
   8.2.2.2 Объединенные запросы ..................................... 47
   8.2.2.3 Требовать ............................................. 47
   8.2.3 Обработка контента .................................. 48
   8.2.4 Применение расширений ................................. 49
   8.2.5 Обработка запроса .............................. 49

   8.2.6 Формирование ответа ............................. 49
   8.2.6.1 Отправка предварительного ответа...................... 49
   8.2.6.2 Заголовки и теги .................................... 50
   8.2.7 Поведение БПЛА без сохранения состояния .............................. 50
   8.3 Серверы перенаправления .................................... 51
   9 Отмена запроса ................................. 53
   9.1 Поведение клиента ..................................... 53
   9.2 Поведение сервера ..................................... 55
   10 Регистрации ....................................... 56
   10.1 Обзор ............................................ 56
   10.2 Создание запроса REGISTER ................... 57
   10.2.1 Добавление привязок ..................................... 59
   10.2.1.1 Установка срока действия контактных адресов 60
   10.2.1.2 Предпочтения среди контактных адресов ................. 61
   10.2.2 Удаление привязок ................................... 61
   10.2.3 Получение привязок................................... 61
   10.2.4 Обновление привязок ................................. 61
   10.2.5 Настройка внутренних часов .......................... 62
   10.2.6 Обнаружение регистратора ............................. 62
   10.2.7 Передача запроса .............................. 62
   10.2.8 Действия при ошибках ..................................... 63
   10.3 Обработка запросов РЕГИСТРА ........................ 63
   11 Запрос возможностей........................... 66
   11.1 Создание запроса OPTIONS ..................... 67
   11.2 Обработка запроса OPTIONS ....................... 68
   12 Диалоги ............................................. 69
   12.1 Создание диалога ................................ 70
   12.1.1 Поведение БПЛА ........................................ 70
   12.1.2 Поведение UAC ........................................ 71
   12.2 Запросы в диалоге............................ 72
   12.2.1 Поведение UAC ........................................ 73
   12.2.1.1 Генерация запроса .............................. 73
   12.2.1.2 Обработка ответов ............................ 75
   12.2.2 Поведение БПЛА ........................................ 76
   12.3 Завершение диалога ............................. 77
   13 Начало сеанса ................................ 77
   13.1 Обзор ............................................ 77
   13.2 Обработка UAC ...................................... 78
   13.2.1 Создание начального приглашения ......................... 78
   13.2.2 Обработка ответов на INVITE ......................... 81
   13.2.2.1 Ответы 1xx ....................................... 81
   13.2.2.2 Ответы 3xx ....................................... 81
   13.2.2.3 Ответы 4xx, 5xx и 6xx .......................... 81
   13.2.2.4 Ответы 2xx....................................... 82
   13.3 Обработка БПЛА ...................................... 83
   13.3.1 Обработка INVITE ........................... 83
   13.3.1.1 Прогресс ............................................ 84
   13.3.1.2 ПРИГЛАШЕНИЕ перенаправлено ........................... 84

   13.3.1.3 ПРИГЛАШЕНИЕ отклонено .............................. 85
   13.3.1.4 ПРИГЛАШЕНИЕ принято .............................. 85
   14 Изменение существующего сеанса....................... 86
   14.1 Поведение UAC ........................................ 86
   14.2 Поведение БПЛА ........................................ 88
   15 Завершение сеанса ............................... 89
   15.1 Завершение сеанса с помощью запроса BYE ............ 90
   15.1.1 Поведение UAC ........................................ 90
   15.1.2 Поведение БПЛА ........................................ 91
   16 Поведение прокси ...................................... 91
   16.1 Обзор ............................................ 91
   16.2 Прокси-сервер с отслеживанием состояния ..................................... 92
   16.3 Запрос на подтверждение .................................. 94
   16.4 Предварительная обработка информации о маршруте ..................... 96
   16.5 Определение целей запроса ......................... 97
   16.6 Пересылка запросов .................................. 99
   16.7 Обработка ответа................................. 107
   16.8 Таймер обработки C .................................. 114
   16.9 Обработка ошибок при транспортировке ........................... 115
   16.10 Обработка CANCEL ................................... 115
   16.11 Прокси-сервер без сохранения состояния ..................................... 116
   16.12 Сводка по обработке прокси-маршрута ...
   16.12.1 Примеры ............................................ 118
   16.12.1.1 Базовая трапеция SIP................................. 118
   16.12.1.2 Обход прокси строгой маршрутизации ................... 120
   16.12.1.3 Перезапись значений поля заголовка маршрута-записи ......... 121
   17 транзакции ........................................ 122
   17.1 Клиентская транзакция .................................. 124
   17.1.1 Клиентская транзакция INVITE ........................... 125
   17.1.1.1 Обзор транзакции INVITE ..................... 125
   17.1.1.2 Формальное описание.................................. 125
   17.1.1.3 Создание запроса ACK ..................... 129
   17.1.2 Клиентская транзакция без приглашения ....................... 130
   17.1.2.1 Обзор транзакции без приглашения INVITE .............. 130
   17.1.2.2 Формальное описание .................................. 131
   17.1.3 Сопоставление ответов с клиентскими транзакциями ........... 132
   17.1.4 Обработка ошибок при транспортировке ........................... 133
   17.2 Серверная транзакция.................................. 134
   17.2.1 Серверная транзакция INVITE ........................... 134
   17.2.2 Серверная транзакция без приглашения INVITE ....................... 137
   17.2.3 Сопоставление запросов с серверными транзакциями ........... 138
   17.2.4 Обработка ошибок при транспортировке ........................... 141
   18 Транспорт ........................................... 141
   18.1 Клиенты ............................................. 142
   18.1.1 Отправка запросов.................................... 142
   18.1.2 Получение ответов ................................. 144
   18.2 Серверы ............................................. 145
   18.2.1 Получение запросов .................................. 145

   18.2.2 Отправка ответов ................................... 146
   18.3 Обрамление ............................................. 147
   18.4 Обработка ошибок ...................................... 147
   19 Общие компоненты сообщений........................... 147
   19.1 Индикаторы унифицированных ресурсов SIP и SIPS ............ 148
   19.1.1 Компоненты URI SIP и SIPS ......................... 148
   19.1.2 Требования к экранированию символов ..................... 152
   19.1.3 Примеры URI SIP и SIPS ........................... 153
   19.1.4 Сравнение URI ...................................... 153
   19.1.5 Формирование запросов из URI ......................... 156
   19.1.6 Связь SIP URI и телефонных URL...................... 157
   19.2 Теги опций ......................................... 158
   19.3 Теги ................................................ 159
   20 полей заголовков ....................................... 159
   20.1 Принять .............................................. 161
   20.2 Принятие-кодирование ..................................... 163
   20.3 Accept-Language ..................................... 164
   20.4 Информация о предупреждении .......................................... 164
   20.5 Разрешить ............................................... 165
   20.6 Информация об аутентификации ................................. 165
   20.7 Авторизация ....................................... 165
   20.8 Call-ID ............................................. 166
   20.9 Информация о вызове ........................................... 166
   20.10 Контакт ............................................. 167
   20.11 Content-Disposition................................. 168
   20.12 Кодирование содержимого .................................... 169
   20.13 Content-Language .................................... 169
   20.14 Content-Length ...................................... 169
   20.15 Content-Type ........................................ 170
   20.16 CSeq ................................................ 170
   20.17 Дата ................................................ 170
   20.18 Информация об ошибке.......................................... 171
   20.19 Истекает ............................................. 171
   20.20 С ................................................ 172
   20.21 In-Reply-To ......................................... 172
   20.22 Макс-вперед ........................................ 173
   20.23 Мин. Истекает ......................................... 173
   20.24 MIME-версия ........................................ 173
   20.25 Организация........................................ 174
   20.26 Приоритет ............................................ 174
   20.27 Проверка подлинности прокси .................................. 174
   20.28 Прокси-авторизация ................................. 175
   20.29 Требование прокси ....................................... 175
   20.30 Рекорд-Маршрут ........................................ 175
   20.31 Ответить ........................................... 176
   20.32 Требовать............................................. 176
   20.33 Retry-After ......................................... 176
   20.34 Маршрут ............................................... 177

   20.35 Сервер .............................................. 177
   20.36 Тема ............................................. 177
   20.37 Поддерживается ........................................... 178
   20.38 Отметка времени ........................................... 178
   20.39 К.................................................. 178
   20.40 Не поддерживается ......................................... 179
   20.41 User-Agent .......................................... 179
   20.42 Через ................................................ 179
   20.43 Предупреждение ............................................. 180
   20.44 WWW-аутентификация .................................... 182
   21 Коды ответа ...................................... 182
   21.1 Предварительная 1xx..................................... 182
   21.1.1 100 Попытка .......................................... 183
   21.1.2 180 Звонок ......................................... 183
   21.1.3 181 Переадресация вызова ......................... 183
   21.1.4 182 В очереди .......................................... 183
   21.1.5 183 Ход сеанса ................................ 183
   21.2 Успешно 2xx ...................................... 183
   21.2.1 200 ОК.............................................. 183
   21.3 Перенаправление 3xx ..................................... 184
   21.3.1 300 вариантов выбора ................................ 184
   21.3.2 301 перемещен навсегда ............................... 184
   21.3.3 302 перемещен временно ............................... 184
   21.3.4 305 Использовать прокси ....................................... 185
   21.3.5 380 Альтернативная служба ............................. 185
   21.4 Ошибка запроса 4xx................................. 185
   21.4.1 400 неверный запрос ..................................... 185
   21.4.2 401 Неавторизованный .................................... 185
   21.4.3 402 Требуется платеж ................................ 186
   21.4.4 403 Запрещено ....................................... 186
   21.4.5 404 не найдено ....................................... 186
   21.4.6 405 Метод запрещен .............................. 186
   21.4.7 406 Неприемлемо.................................. 186
   21.4.8 407 Требуется аутентификация прокси ................... 186
   21.4.9 408 Тайм-аут запроса ................................. 186
   21.4.10 410 Gone ............................................ 187
   21.4.11 413 Слишком большой объект запроса ........................ 187
   21.4.12 414 Request-URI Too Long ............................ 187
   21.4.13 415 Неподдерживаемый тип носителя .......................... 187
   21.4.14 416 Неподдерживаемая схема URI.......................... 187
   21.4.15 420 Bad Extension ................................... 187
   21.4.16 Требуется расширение 421 .............................. 188
   21.4.17 423 Интервал слишком короткий .............................. 188
   21.4.18 480 Временно недоступен ......................... 188
   21.4.19 481 Вызов / транзакция не существует ................. 188
   21.4.20 Обнаружено 482 петли ................................... 188
   21.4.21 483 Too Many Hops................................... 189
   21.4.22 484 Адрес неполный .............................. 189

   21.4.23 485 Неоднозначно ....................................... 189
   21.4.24 486 Здесь занято ....................................... 189
   21.4.25 487 Запрос прекращен .............................. 190
   21.4.26 488 Здесь неприемлемо ............................. 190
   21.4.27 491 Запрос на рассмотрении ................................. 190
   21.4.28 493 Невозможно расшифровать.................................. 190
   21.5 Отказ сервера 5xx .................................. 190
   21.5.1 500 Внутренняя ошибка сервера ........................... 190
   21.5.2 501 Не реализовано ................................. 191
   21.5.3 502 Плохой шлюз ..................................... 191
   21.5.4 503 Служба недоступна ............................. 191
   21.5.5 504 Тайм-аут сервера ................................. 191
   21.5.6 Версия 505 не поддерживается........................... 192
   21.5.7 513 Сообщение слишком велико ............................... 192
   21.6 Глобальные отказы 6xx ................................. 192
   21.6.1 600 Везде занято ................................. 192
   21.6.2 603 Отклонение ......................................... 192
   21.6.3 604 Нигде не существует ......................... 192
   21.6.4 606 Неприемлемо .................................. 192
   22 Использование HTTP-аутентификации........................ 193
   22.1 Платформа ........................................... 193
   22.2 Аутентификация между пользователем ......................... 195
   22.3 Проверка подлинности прокси-сервера ........................ 197
   22.4 Схема дайджест-аутентификации .................... 199
   23 S / MIME .............................................. 201
   23.1 Сертификаты S / MIME ................................. 201
   23.2 Обмен ключами S / MIME................................. 202
   23.3 Защита тел MIME ................................ 205
   23.4 Конфиденциальность и целостность заголовка SIP с использованием S / MIME:
              Туннельный SIP ....................................... 207
   23.4.1 Свойства целостности и конфиденциальности SIP
              Заголовки ............................................. 207
   23.4.1.1 Целостность ........................................... 207
   23.4.1.2 Конфиденциальность ..................................... 208
   23.4.2 Целостность туннелирования и аутентификация .............. 209
   23.4.3 Туннельное шифрование ................................ 211
   24 Примеры ............................................ 213
   24.1 Регистрация ........................................ 213
   24.2 Настройка сеанса ....................................... 214
   25 Расширенный BNF для протокола SIP .................. 219
   25.1 Основные правила ......................................... 219
   26 соображения безопасности: модель угроз и безопасность
              Рекомендации по использованию ............................... 232
   26.1 Атаки и модели угроз ........................... 233
   26.1.1 Взлом регистрации .............................. 233
   26.1.2 Выдача себя за сервер .............................. 234
   26.1.3 Подделка тел сообщений ....................... 235
   26.1.4 Завершение сеансов............................... 235

   26.1.5 Отказ в обслуживании и усиление ................. 236
   26.2 Механизмы безопасности ................................. 237
   26.2.1 Безопасность транспортного и сетевого уровней ................ 238
   26.2.2 Схема URI SIPS ..................................... 239
   26.2.3 HTTP-аутентификация ................................. 240
   26.2.4 S / MIME ............................................ .. 240
   26.3 Реализация механизмов безопасности.................... 241
   26.3.1 Требования к разработчикам SIP ................ 241
   26.3.2 Решения безопасности .................................. 242
   26.3.2.1 Регистрация ........................................ 242
   26.3.2.2 Междоменные запросы ................................ 243
   26.3.2.3 Одноранговые запросы ............................... 245
   26.3.2.4 Защита от DoS-атак ...................................... 246
   26.4 Ограничения ......................................... 247
   26.4.1 Дайджест HTTP ......................................... 247
   26.4.2 S / MIME ............................................ .. 248
   26.4.3 TLS .............................................. ... 249
   26.4.4 SIPS URI ........................................... 249
   26.5 Конфиденциальность ............................................. 251
   27 Вопросы IANA ................................. 252
   27.1 Теги параметров ......................................... 252
   27.2 Коды предупреждений .......................................... 252
   27.3 Имена полей заголовка .................................. 253
   27.4 Коды метода и ответа ........................... 253
   27.5 Тип MIME "сообщение / sip". ....................... 254
   27.6 Новые регистрации параметров Content-Disposition ... 255
   28 Изменения по сравнению с RFC 2543 ............................... 255
   28.1 Основные функциональные изменения............................ 255
   28.2 Незначительные функциональные изменения ............................ 260
   29 Нормативные ссылки ................................ 261
   30 Информативные ссылки .............................. 262
   Таблица значений таймера ............................... 265
   Благодарности ................................................ 266
   Адреса авторов ............................................. 267
   Полное заявление об авторских правах ....................................... 269

1. Введение

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

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

2 Обзор функциональности SIP

   SIP - это протокол управления на уровне приложений, который может устанавливать,
   изменять и завершать мультимедийные сеансы (конференции), например
   Звонки по интернет-телефонии. SIP также может приглашать участников на
   уже существующие сеансы, например, многоадресные конференции.СМИ могут
   быть добавленным в существующий сеанс (и удаленным из него). ГЛОТОК
   прозрачно поддерживает службы сопоставления имен и перенаправления, которые
   поддерживает личную мобильность [27] - пользователи могут поддерживать единую
   внешне видимый идентификатор независимо от их расположения в сети.

   SIP поддерживает пять аспектов установления и завершения мультимедиа.
   коммуникации:

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

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

      Возможности пользователя: определение медиа и медиа параметров
           быть использованным;

      Настройка сеанса: «звонок», установка параметров сеанса на
           как вызываемый, так и вызывающий абонент;

      Управление сеансом: включая передачу и завершение
           сеансы, изменение параметров сеанса и вызов
           Сервисы.SIP - это не вертикально интегрированная система связи. SIP - это
   скорее компонент, который можно использовать с другими протоколами IETF для
   построить полную мультимедийную архитектуру. Обычно эти
   архитектуры будут включать такие протоколы, как Транспорт в реальном времени
   Протокол (RTP) (RFC 1889 [28]) для передачи данных в реальном времени и
   обеспечение обратной связи QoS, протокол потоковой передачи в реальном времени (RTSP) (RFC)
   2326 [29]) для управления доставкой потокового мультимедиа, Медиа

   Протокол управления шлюзом (MEGACO) (RFC 3015 [30]) для управления
   шлюзы к коммутируемой телефонной сети общего пользования (PSTN) и
   Протокол описания сеанса (SDP) (RFC 2327 [1]) для описания
   мультимедийные сеансы.Следовательно, SIP следует использовать вместе
   с другими протоколами для предоставления полных услуг
   пользователей. Однако базовая функциональность и работа SIP делает
   не зависят ни от одного из этих протоколов.

   SIP не предоставляет услуги. Скорее, SIP предоставляет примитивы, которые
   можно использовать для реализации различных сервисов. Например, SIP может
   найти пользователя и доставить непрозрачный объект в его текущее местоположение.
   Если этот примитив используется для доставки описания сеанса, написанного на
   SDP, например, конечные точки могут согласовывать параметры
   сеанс.Если тот же примитив используется для доставки фотографии
   вызывающего абонента, а также описание сеанса, служба «АОН» может
   быть легко реализованным. Как показывает этот пример, единственный примитив - это
   обычно используется для предоставления нескольких различных услуг.

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

   SIP работает как с IPv4, так и с IPv6.

3 Терминология

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

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

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

   На рисунке 1 показан типичный пример обмена сообщениями SIP между
   два пользователя, Алиса и Боб.(Каждое сообщение помечено буквой
   "F" и число для ссылки в тексте.) В этом примере Алиса
   использует приложение SIP на своем ПК (называемое программным телефоном) для звонков
   Боб на своем SIP-телефоне через Интернет. Также показаны два SIP-прокси.
   серверы, которые действуют от имени Алисы и Боба для облегчения сеанса
   учреждение. Это типичное расположение часто называют
   «Трапеция SIP», как показано геометрической формой пунктирных линий
   на рисунке 1.

   Алиса «звонит» Бобу, используя его SIP-идентификатор, тип универсального ресурса.
   Идентификатор (URI) называется SIP URI.SIP URI определены в разделе
   19.1. Он имеет форму, аналогичную адресу электронной почты, обычно
   содержащий имя пользователя и имя хоста. В данном случае это
   sip: [email protected], где biloxi.com - это домен SIP Боба
   поставщик услуг. У Алисы есть SIP-URI sip: [email protected]
   Алиса могла ввести URI Боба или, возможно, щелкнуть гиперссылку
   или запись в адресной книге. SIP также предоставляет безопасный URI,
   называется SIPS URI. Например, sips: [email protected] Вызов
   в SIPS URI гарантирует, что безопасный, зашифрованный транспорт
   (а именно TLS) используется для передачи всех сообщений SIP от вызывающего абонента к
   домен вызываемого.Оттуда запрос безопасно отправляется на
   вызываемого, но с механизмами безопасности, которые зависят от политики
   домен вызываемого.

   SIP основан на HTTP-подобной модели транзакции запроса / ответа.
   Каждая транзакция состоит из запроса, который вызывает конкретный
   метод или функцию на сервере и хотя бы один ответ. В
   В этом примере транзакция начинается с отправки программного телефона Алисы
   запрос INVITE, адресованный на SIP URI Боба. INVITE - это пример
   метода SIP, определяющего действие, которое запрашивающая сторона (Алиса)
   хочет, чтобы сервер (Боб) взял.Запрос INVITE содержит номер
   полей заголовка. Поля заголовка - это именованные атрибуты, которые обеспечивают
   дополнительная информация о сообщении. Те, кто присутствует в
   ПРИГЛАСИТЬ: укажите уникальный идентификатор звонка, адресата
   адрес, адрес Алисы и информация о типе сеанса
   что Алиса хочет установить с Бобом. ПРИГЛАШЕНИЕ (сообщение F1 в
   Рисунок 1) может выглядеть так:

                     atlanta.com. . . biloxi.com
                 . прокси-сервер.. .
       Алисы. . . . . . . . . . . . . . . . . . . . Боба
      программный телефон SIP телефон
         | | | |
         | ПРИГЛАСИТЬ F1 | | |
         | ---------------> | ПРИГЛАСИТЬ F2 | |
         | 100 Попытка F3 | ---------------> | ПРИГЛАСИТЬ F4 |
         | <--------------- | 100 Попытка F5 | ---------------> |
         | | <-------------- | 180 Звонок F6 |
         | | 180 Звонок F7 | <--------------- |
         | 180 Звонок F8 | <--------------- | 200 ОК F9 |
         | <--------------- | 200 ОК F10 | <--------------- |
         | 200 OK F11 | <--------------- | |
         | <--------------- | | |
         | ACK F12 |
         | ------------------------------------------------- > |
         | Медиа-сессия |
         | <================================================ > |
         | BYE F13 ​​|
         | <------------------------------------------------ - |
         | 200 ОК F14 |
         | ------------------------------------------------- > |
         | |

         Рисунок 1: Пример настройки сеанса SIP с трапецией SIP

      ПРИГЛАСИТЬ глоток: bob @ biloxi.com SIP / 2.0
      Через: SIP / 2.0 / UDP pc33.atlanta.com; branch = z9hG4bK776asdhds
      Максимальное количество нападающих: 70
      Кому: Боб 
      От: Алиса ; tag = 1928301774
      Call-ID: [email protected]
      CSeq: 314159 ПРИГЛАСИТЬ
      Контакты: 
      Тип содержимого: application / sdp
      Длина содержимого: 142

      (SDP Алисы не показан)

   Первая строка текстового сообщения содержит имя метода.
   (ПРИГЛАШАТЬ).Следующие строки представляют собой список полей заголовка. Этот
   пример содержит минимально необходимый набор. Поля заголовка
   кратко описано ниже:

   Via содержит адрес (pc33.atlanta.com), по которому находится Алиса.
   ожидая получить ответы на этот запрос. Он также содержит
   параметр ветви, идентифицирующий эту транзакцию.

   Кому содержит отображаемое имя (Bob) и SIP или SIPS URI.
   (sip: [email protected]) к которому изначально был отправлен запрос
   направлен. Отображаемые имена описаны в RFC 2822 [3].From также содержит отображаемое имя (Алиса) и SIP или SIPS URI.
   (sip: [email protected]), указывающие на отправителя запроса.
   Это поле заголовка также имеет параметр тега, содержащий случайную строку
   (1928301774), который был добавлен к URI программным телефоном. Это использовано
   в целях идентификации.

   Call-ID содержит глобальный уникальный идентификатор для этого вызова,
   генерируется комбинацией случайной строки и программного телефона
   имя хоста или IP-адрес. Комбинация тегов To, From,
   и Call-ID полностью определяет одноранговые отношения SIP
   между Алисой и Бобом и называется диалогом.CSeq или Command Sequence содержит целое число и имя метода. В
   Номер CSeq увеличивается для каждого нового запроса в диалоговом окне и
   - традиционный порядковый номер.

   Контакт содержит SIP или SIPS URI, который представляет прямой путь к
   связаться с Алисой, обычно состоящий из имени пользователя с полным
   доменное имя (FQDN). Хотя полное доменное имя является предпочтительным, многие конечные системы делают
   не имеют зарегистрированных доменных имен, поэтому IP-адреса разрешены.
   В то время как поле заголовка Via сообщает другим элементам, куда отправлять
   ответ, поле заголовка контакта сообщает другим элементам, куда отправлять
   будущие запросы.Max-Forwards служит для ограничения количества переходов, которые может выполнить запрос.
   путь к месту назначения. Он состоит из целого числа, равного
   уменьшается на единицу на каждом шаге.

   Content-Type содержит описание тела сообщения (не показано).

   Content-Length содержит количество октетов (байтов) тела сообщения.

   Полный набор полей заголовка SIP определен в Разделе 20.

   Детали сеанса, такие как тип носителя, кодек или
   частота дискретизации, не описываются с использованием SIP.Скорее, тело
   SIP-сообщение содержит описание сеанса, закодированное в некоторых
   другой формат протокола. Одним из таких форматов является описание сеанса.
   Протокол (SDP) (RFC 2327 [1]). Это сообщение SDP (не показано в

   пример) передается в сообщении SIP аналогично
   вложение документа, передаваемое в сообщении электронной почты или в Интернете
   страница переносится в сообщении HTTP.

   Поскольку программный телефон не знает местонахождение Боба или SIP
   сервер в билокси.com домен, программный телефон отправляет ПРИГЛАШЕНИЕ на
   SIP-сервер, обслуживающий домен Алисы, atlanta.com. Адрес
   SIP-сервера atlanta.com можно было настроить в
   софтфон, или, например, он мог быть обнаружен DHCP.

   SIP-сервер atlanta.com - это тип SIP-сервера, известный как прокси.
   сервер. Прокси-сервер получает SIP-запросы и пересылает их на
   от имени отправителя запроса. В этом примере прокси-сервер получает
   запрос INVITE и отправляет ответ 100 (пытается) обратно в
   софтфон.Ответ 100 (Попытка) означает, что ПРИГЛАШЕНИЕ
   был получен, и что прокси работает от ее имени для маршрутизации
   ПРИГЛАШЕНИЕ в пункт назначения. В ответах SIP используется трехзначный
   код, за которым следует описательная фраза. Этот ответ содержит
   тот же To, From, Call-ID, CSeq и параметр ветвления в Via как
   ПРИГЛАСИТЬ, который позволяет программному телефону Алисы соотносить этот ответ с
   отправленное ПРИГЛАШЕНИЕ. Прокси-сервер atlanta.com находит прокси
   сервер на biloxi.com, возможно, путем выполнения определенного типа DNS
   (Служба доменных имен), чтобы найти SIP-сервер, который обслуживает
   билокси.com домен. Это описано в [4]. В результате это
   получает IP-адрес прокси-сервера biloxi.com и пересылает,
   или прокси, запрос INVITE там. Перед отправкой запроса,
   прокси-сервер atlanta.com добавляет дополнительное поле заголовка Via
   значение, которое содержит собственный адрес (ПРИГЛАШЕНИЕ уже содержит
   Адрес Алисы на первой Виа). Прокси-сервер biloxi.com
   получает ПРИГЛАШЕНИЕ и отвечает 100 (пытается) ответом на
   прокси-сервер atlanta.com, чтобы указать, что он получил
   ПРИГЛАСИТЬ и обрабатывает запрос.Прокси-сервер обращается к
   база данных, обычно называемая службой определения местоположения, которая содержит
   текущий IP-адрес Боба. (В следующем разделе мы увидим, как
   эта база данных может быть заполнена.) Прокси-сервер biloxi.com добавляет
   другое значение поля заголовка Via с собственным адресом для сообщения INVITE и
   проксирует его на SIP-телефон Боба.

   SIP-телефон Боба получает ПРИГЛАШЕНИЕ и предупреждает Боба о входящем
   звонок от Алисы, чтобы Боб мог решить, отвечать ли на звонок,
   то есть звонит телефон Боба.SIP-телефон Боба показывает это в 180
   (Ringing) ответ, который направляется обратно через два прокси в
   обратное направление. Каждый прокси использует поле заголовка Via для
   определить, куда отправить ответ и удаляет собственный адрес из
   вершина. В результате, хотя поиски DNS и службы определения местоположения
   требуется для маршрутизации начального ПРИГЛАШЕНИЯ, ответ 180 (звонок) может
   возвращаться вызывающей стороне без поиска или без состояния

   поддерживается в прокси. Это также имеет желаемое свойство:
   каждый прокси, который видит ПРИГЛАШЕНИЕ, также увидит все ответы на
   ПРИГЛАСИТЬ.Когда программный телефон Алисы получает ответ 180 (звонок), он проходит
   эту информацию Алисе, возможно, используя звуковой сигнал обратного вызова или
   отображение сообщения на экране Алисы.

   В этом примере Боб решает ответить на звонок. Когда он поднимает
   телефон, его SIP-телефон отправляет ответ 200 (OK), чтобы указать, что
   на звонок ответили. 200 (OK) содержит тело сообщения
   с медиа-описанием SDP типа сеанса, в котором Боб
   готов установить с Алисой.В результате получается двухфазный
   обмен сообщениями SDP: Алиса отправила одно Бобу, а Боб отправил одно
   обратно к Алисе. Этот двухфазный обмен обеспечивает базовое согласование
   возможностей и основан на простой модели предложения / ответа SDP
   обмен. Если Боб не хотел отвечать на звонок или был занят
   другой вызов, вместо
   200 (ОК), что привело бы к тому, что сеанс мультимедиа не
   установлено. Полный список кодов ответов SIP находится в разделе
   21.200 (OK) (сообщение F9 на рисунке 1) может выглядеть следующим образом:
   Боб отправляет его:

      SIP / 2.0 200 ОК
      Через: SIP / 2.0 / UDP server10.biloxi.com
         ; branch = z9hG4bKnashds8; получено = 192.0.2.3
      Через: SIP / 2.0 / UDP bigbox3.site3.atlanta.com
         ; branch = z9hG4bK77ef4c2312983.1; получено = 192.0.2.2
      Через: SIP / 2.0 / UDP pc33.atlanta.com
         ; branch = z9hG4bK776asdhds; получено = 192.0.2.1
      Кому: Боб ; tag = a6c85cf
      От: Алиса ; tag = 1928301774
      Идентификатор звонка: a84b4c76e66710 @ pc33.atlanta.com
      CSeq: 314159 ПРИГЛАСИТЬ
      Контакты: 
      Тип содержимого: application / sdp
      Длина содержимого: 131

      (SDP Боба не показан)

   Первая строка ответа содержит код ответа (200) и
   фраза причины (ОК). Остальные строки содержат поля заголовка.
   Поля заголовка Via, To, From, Call-ID и CSeq копируются из
   запрос INVITE. (Имеется три значения поля заголовка Via - одно
   добавлен SIP-телефоном Алисы, еще один добавлен atlanta.com прокси и
   один добавлен прокси biloxi.com.) SIP-телефон Боба добавил тег
   в поле заголовка Кому. Этот тег будет включен
   обе конечные точки в диалоговом окне и будут включены во все будущие

   запросы и ответы в этом звонке. Поле заголовка контакта
   содержит URI, по которому с Бобом можно напрямую связаться по его SIP-телефону.
   Content-Type и Content-Length относятся к телу сообщения (не
   показано), который содержит медиа-информацию SDP Боба.

   В дополнение к поисковым запросам DNS и службы определения местоположения, показанным в этом
   Например, прокси-серверы могут принимать гибкие «решения по маршрутизации» для
   решить, куда отправить запрос.Например, если SIP-телефон Боба
   вернул ответ 486 (здесь занято), прокси-сервер biloxi.com
   может проксировать ПРИГЛАШЕНИЕ на сервер голосовой почты Боба. Прокси-сервер может
   также отправьте ПРИГЛАШЕНИЕ в несколько мест одновременно. Этот
   Тип параллельного поиска известен как разветвление.

   В этом случае 200 (OK) маршрутизируется обратно через два прокси и
   принимается программным телефоном Алисы, который затем останавливает сигнал обратного вызова
   и указывает, что на звонок ответили. Наконец, Алиса
   программный телефон отправляет сообщение подтверждения, ACK, на SIP-телефон Боба
   для подтверждения получения окончательного ответа (200 (OK)).В этом
   Например, ACK отправляется прямо с программного телефона Алисы на SIP Боба.
   телефон, минуя два прокси. Это происходит потому, что конечные точки
   узнали адреса друг друга из полей заголовка контакта
   через обмен INVITE / 200 (OK), который не был известен, когда
   было отправлено первоначальное ПРИГЛАШЕНИЕ. Поиск, выполняемый двумя прокси
   больше не нужны, поэтому прокси выпадают из потока вызовов. Этот
   завершает трехстороннее рукопожатие INVITE / 200 / ACK, используемое для установления
   SIP-сессии.Полная информация о настройке сеанса находится в Разделе 13.

   Медиа-сессия Алисы и Боба уже началась, и они отправляют медиа
   пакеты, использующие формат, на который они согласились при обмене SDP.
   Как правило, сквозные медиапакеты идут по другому пути, чем
   сигнальные сообщения SIP.

   Во время сеанса Алиса или Боб могут решить изменить
   характеристики медиа-сеанса. Это достигается
   отправка повторного ПРИГЛАШЕНИЯ, содержащего новое описание мультимедиа. Это повторное
   INVITE ссылается на существующий диалог, чтобы другая сторона знала
   что это изменить существующий сеанс вместо того, чтобы устанавливать
   новая сессия.Другой абонент отправляет 200 (ОК), чтобы принять изменение.
   Запрашивающая сторона отвечает на 200 (ОК) ACK. Если другой
   сторона не принимает изменение, он отправляет ответ об ошибке, например
   488 (здесь неприемлемо), который также получает ACK. Тем не менее
   сбой re-INVITE не приводит к сбою существующего вызова -
   сеанс продолжается с использованием ранее согласованных
   характеристики. Полная информация о модификации сеанса находится в разделе
   14.

   По окончании разговора Боб сначала отключается (вешает трубку) и
   генерирует сообщение BYE.Это BYE направляется непосредственно к Алисе.
   софтфон, опять же в обход прокси. Алиса подтверждает получение
   BYE с ответом 200 (OK), который завершает сеанс и
   транзакция BYE. ACK не отправляется - ACK отправляется только в
   ответ на ответ на запрос INVITE. Причины этого
   специальная обработка для INVITE будет обсуждаться позже, но относится к
   механизмы надежности в SIP, время, которое может занять
   звонящий телефон, на который нужно ответить, и разветвление.Именно по этой причине,
   обработка запросов в SIP часто классифицируется как INVITE или не
   ПРИГЛАСИТЬ, имея в виду все другие методы, кроме ПРИГЛАШЕНИЯ. Полная информация
   о завершении сеанса - в Разделе 15.

   В разделе 24.2 полностью описаны сообщения, показанные на рисунке 1.

   В некоторых случаях это может быть полезно для прокси в сигнальном тракте SIP.
   чтобы увидеть весь обмен сообщениями между конечными точками в течение
   сессия. Например, если прокси-сервер biloxi.com хотел
   остаются в пути обмена сообщениями SIP за пределами первоначального ПРИГЛАШЕНИЯ, он
   добавьте в ПРИГЛАШЕНИЕ обязательное поле заголовка маршрутизации, известное как Запись-
   Маршрут, содержащий URI, разрешающий имя хоста или IP-адрес
   прокси.Эта информация будет получена как SIP Боба,
   телефон и (из-за того, что поле заголовка Record-Route передается обратно в
   программный телефон Алисы 200 (OK)) и сохраняется в течение всего
   диалог. Затем прокси-сервер biloxi.com получит и прокси-сервер
   ACK, BYE и 200 (OK) до BYE. Каждый прокси может независимо
   решают получать последующие сообщения, и эти сообщения пройдут
   через всех доверенных лиц, которые решили его получить. Эта возможность
   часто используется для прокси, которые предоставляют функции во время разговора.Регистрация - еще одна распространенная операция в SIP. Регистрация одна
   способ, которым сервер biloxi.com может узнать текущее местоположение Боба.
   При инициализации и через определенные промежутки времени SIP-телефон Боба отправляет
   РЕГИСТРАЦИЯ сообщений на сервер в домене biloxi.com, известный как SIP
   регистратор. Сообщения REGISTER связывают SIP или SIPS URI Боба.
   (sip: [email protected]) с машиной, в которой он сейчас
   регистрируется (передается как SIP или SIPS URI в поле заголовка контакта).Регистратор записывает эту ассоциацию, также называемую привязкой, в
   база данных, называемая службой определения местоположения, где она может использоваться
   прокси в домене biloxi.com. Часто сервер-регистратор для
   домен совпадает с прокси для этого домена. Это
   Важная концепция, что различие между типами SIP серверов
   логично, а не физически.

   Боб не ограничивается регистрацией с одного устройства. Например,
   и его SIP-телефон дома, и телефон в офисе могли отправлять
   регистрации.Эта информация хранится вместе в местоположении

   сервис и позволяет прокси-серверу выполнять различные типы поиска для
   найдите Боба. Аналогичным образом, более одного пользователя могут быть зарегистрированы на
   одно устройство одновременно.

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

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

   Полный набор сведений о SIP-сообщении для этого примера регистрации
   находится в разделе 24.1.

   Дополнительные операции в SIP, такие как запрос возможностей
   SIP-сервера или клиента с помощью OPTIONS или отмена ожидающего
   запрос с использованием CANCEL будет представлен в следующих разделах.

5 Структура протокола

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

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

   Самый низкий уровень SIP - это его синтаксис и кодировка.Его кодировка
   задается с использованием расширенной грамматики Бэкуса-Наура (BNF). В
   полный BNF указан в разделе 25; обзор SIP
   структуру сообщения можно найти в разделе 7.

   Второй уровень - это транспортный уровень. Он определяет, как клиент
   отправляет запросы и получает ответы и как сервер получает
   запрашивает и отправляет ответы по сети. Все элементы SIP
   содержат транспортный уровень. Транспортный уровень описан в
   Раздел 18.

   Третий уровень - это уровень транзакций.Сделки - это
   фундаментальная составляющая SIP. Транзакция - это запрос, отправленный
   клиентская транзакция (с использованием транспортного уровня) на сервер
   транзакции, а также все ответы на этот запрос, отправленные из
   серверная транзакция возвращается клиенту. Уровень транзакции обрабатывает
   повторные передачи на уровне приложений, сопоставление ответов на запросы,
   и таймауты на уровне приложения. Любая задача, которую клиент пользовательского агента
   (UAC) выполняется с помощью серии транзакций.Обсуждение транзакций можно найти в разделе 17. Пользовательские агенты.
   содержат уровень транзакций, как и прокси с отслеживанием состояния. Без гражданства
   прокси не содержат уровня транзакций. Уровень транзакции
   имеет клиентский компонент (называемый клиентской транзакцией) и
   серверный компонент (называемый серверной транзакцией), каждый из которых
   представлены конечным автоматом, который построен для
   обрабатывать конкретный запрос.

   Слой выше уровня транзакции называется пользователем транзакции.
   (ВТ).Каждый из SIP-объектов, кроме прокси без сохранения состояния, является
   пользователь транзакции. Когда TU хочет отправить запрос, он создает
   экземпляр клиентской транзакции и передает ему запрос вместе с
   IP-адрес назначения, порт и транспорт, на который нужно отправить
   запрос. ЕП, который создает клиентскую транзакцию, также может ее отменить.
   Когда клиент отменяет транзакцию, он запрашивает остановку сервера.
   дальнейшей обработки, вернуться к состоянию, которое существовало до
   транзакция была инициирована, и сгенерировать конкретный ответ об ошибке на
   та сделка.Это делается с помощью запроса CANCEL, который
   представляет собой собственную транзакцию, но ссылается на транзакцию как
   отменен (Раздел 9).

   Элементы SIP, то есть клиенты и серверы пользовательских агентов, без сохранения состояния
   прокси-серверы и регистраторы с отслеживанием состояния содержат ядро, которое
   отличает их друг от друга. Ядра, кроме безгражданства
   прокси, являются пользователями транзакций. Пока поведение UAC и UAS
   ядер зависит от метода, есть общие правила для всех
   методы (раздел 8).Для UAC эти правила регулируют построение
   запроса; для UAS они регулируют обработку запроса и
   создание ответа. Поскольку регистрации играют важную роль в
   SIP, UAS, который обрабатывает РЕГИСТР, получает специальное имя
   регистратор. Раздел 10 описывает поведение ядра UAC и UAS для
   РЕГИСТРАЦИЯ метод. Раздел 11 описывает поведение ядра UAC и UAS для
   метод OPTIONS, используемый для определения возможностей UA.

   Некоторые другие запросы отправляются в диалоговом окне.Диалог - это
   одноранговая связь SIP между двумя пользовательскими агентами, которая сохраняется
   на некоторое время. Диалог облегчает последовательность сообщений и
   правильная маршрутизация запросов между пользовательскими агентами. ПРИГЛАШЕНИЕ
   метод - единственный способ, определенный в этой спецификации, чтобы установить
   диалог. Когда UAC отправляет запрос, который находится в контексте
   диалог, он следует общим правилам UAC, как описано в Разделе 8, но
   также правила для запросов в середине диалога. В разделе 12 обсуждаются диалоги.
   и представлены процедуры их строительства и обслуживания,
   в дополнение к построению запросов в диалоге.Самый важный метод в SIP - это метод INVITE, который используется
   чтобы установить сеанс между участниками. Сессия - это
   сбор участников и потоков мультимедиа между ними, для
   цели общения. В разделе 13 обсуждается, как проходят занятия.
   инициируется, что приводит к появлению одного или нескольких диалогов SIP. Раздел 14.
   обсуждает, как характеристики этого сеанса изменяются посредством
   использование запроса INVITE в диалоговом окне. Наконец, раздел 15
   обсуждает, как завершается сеанс.Процедуры Разделов 8, 10, 11, 12, 13, 14 и 15 касаются
   полностью с ядром UA (Раздел 9 описывает отмену, которая
   применяется как к ядру UA, так и к ядру прокси). В разделе 16 обсуждается
   прокси-элемент, который упрощает маршрутизацию сообщений между пользователями
   агенты.

6 Определения

   Следующие термины имеют особое значение для SIP.

      Адрес записи: адрес записи (AOR) - это SIP или SIPS URI.
         который указывает на домен со службой определения местоположения, которая может отображать
         URI другого URI, где пользователь может быть доступен.Обычно служба определения местоположения заполняется через
         регистрации. AOR часто называют "общественным
         адрес »пользователя.

      Пользовательский агент с обратной связью: Пользовательский агент с обратной связью (B2BUA) является
         логический объект, который получает запрос и обрабатывает его как
         сервер пользовательского агента (UAS). Чтобы определить, как запрос
         нужно ответить, он действует как клиент пользовательского агента (UAC) и
         генерирует запросы. В отличие от прокси-сервера, он поддерживает диалог
         состояние и должен участвовать во всех запросах, отправленных в диалогах
         он установил.Поскольку это объединение UAC и
         UAS, никаких явных определений для его поведения не требуется.

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

      Call Leg: другое имя для диалога [31]; больше не используется в этом
         Технические характеристики.

      Состояние вызова: прокси-сервер имеет состояние вызова, если он сохраняет состояние для
         диалог от инициирующего ПРИГЛАШЕНИЯ к завершающемуся BYE
         запрос.Прокси-сервер с отслеживанием состояния вызова всегда имеет состояние транзакции,
         но обратное не всегда верно.

      Клиент: клиент - это любой сетевой элемент, который отправляет SIP-запросы.
         и получает ответы SIP. Клиенты могут или не могут взаимодействовать
         напрямую с человеком-пользователем. Клиенты и прокси-серверы пользовательских агентов
         клиентов.

      Конференция: мультимедийный сеанс (см. Ниже), содержащий
         несколько участников.

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

      Диалог: диалог - это одноранговые SIP-отношения между двумя
         UA, который сохраняется в течение некоторого времени. Диалог устанавливается
         Сообщения SIP, например ответ 2xx на запрос INVITE. А
         диалог идентифицируется идентификатором вызова, локальным тегом и
         удаленный тег. Диалог раньше назывался ветвью вызова в RFC.
         2543.Downstream: направление пересылки сообщений внутри транзакции.
         это относится к направлению, в котором поток запросов от пользователя
         клиент агента на сервер агента пользователя.

      Окончательный ответ: ответ, который завершает транзакцию SIP, как
         против предварительного ответа, которого нет. Все 2xx, 3xx,
         Ответы 4xx, 5xx и 6xx являются окончательными.

      Заголовок: заголовок - это компонент сообщения SIP, который передает
         информация о сообщении. Он структурирован как последовательность
         полей заголовка.Поле заголовка: поле заголовка является компонентом сообщения SIP.
         заголовок. Поле заголовка может отображаться как одно или несколько полей заголовка.
         ряды. Строки поля заголовка состоят из имени поля заголовка и нуля
         или несколько значений поля заголовка. Несколько значений поля заголовка в

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

      Значение поля заголовка: значение поля заголовка - это одно значение; а
         поле заголовка состоит из нуля или более значений поля заголовка.Домашний домен: домен, предоставляющий услуги пользователю SIP.
         Обычно это домен, присутствующий в URI в
         адрес записи регистрации.

      Информационный ответ: То же, что и предварительный ответ.

      Инициатор, вызывающий абонент, вызывающий абонент: сторона, инициирующая сеанс
         (и диалог) с запросом INVITE. Вызывающий сохраняет это
         роль с момента отправки начального ПРИГЛАШЕНИЯ, установленного
         диалоговое окно до его завершения.Приглашение: запрос INVITE.

      Приглашенный, приглашенный пользователь, вызываемая сторона, вызываемый: сторона, которая
         получает запрос INVITE с целью установления
         новая сессия. Вызываемый сохраняет эту роль с момента
         получает ПРИГЛАШЕНИЕ до завершения диалога
         установлено этим ПРИГЛАШЕНИЕМ.

      Служба определения местоположения: служба определения местоположения используется перенаправлением SIP или
         прокси-сервер для получения информации о возможных
         место (а).Он содержит список привязок адреса-оф.
         записывать ключи от нуля или более контактных адресов. Привязки
         можно создавать и удалять разными способами; эта спецификация
         определяет метод REGISTER, который обновляет привязки.

      Цикл: запрос, который поступает на прокси-сервер, пересылается, а затем
         возвращается на тот же прокси. Когда придет второй
         время его Request-URI идентичен первому разу, а другие
         поля заголовка, которые влияют на работу прокси, не изменяются, поэтому
         что прокси-сервер примет такое же решение об обработке
         запрос сделал с первого раза.Зацикленные запросы - это ошибки,
         и процедуры их обнаружения и обращения с ними
         описывается протоколом.

      Свободная маршрутизация: прокси-сервер считается свободным маршрутизацией, если он следует
         процедуры, определенные в данной спецификации для обработки
         поле заголовка маршрута. Эти процедуры разделяют
         место назначения запроса (присутствует в Request-URI) от

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

      Сообщение: данные, передаваемые между элементами SIP как часть протокола.
         Сообщения SIP представляют собой запросы или ответы.

      Метод: метод - это основная функция, для которой предназначен запрос.
         вызвать на сервере. Метод переносится в запросе
         само сообщение. Примеры методов - INVITE и BYE.

      Исходящий прокси: прокси, который получает запросы от клиента, даже
         хотя это может быть не сервер, разрешенный Request-URI.Обычно UA настраивается вручную с исходящим прокси,
         или можете узнать об одном из протоколов автоматической настройки.

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

      Прокси, прокси-сервер: посредник, который действует как
         сервер и клиент с целью отправки запросов на
         от имени других клиентов. Прокси-сервер в основном играет
         роль маршрутизации, что означает, что ее задача - гарантировать, что
         запрос отправляется другому объекту «ближе» к целевой
         пользователь.Прокси-серверы также полезны для применения политики (для
         например, убедитесь, что пользователю разрешено звонить). А
         прокси интерпретирует и при необходимости переписывает определенные части
         сообщение-запрос перед его пересылкой.

      Рекурсия: клиент повторяет ответ 3xx, когда он генерирует
         новый запрос к одному или нескольким URI в заголовке контакта
         поле в ответе.

      Сервер перенаправления: сервер перенаправления - это сервер пользовательского агента, который
         генерирует 3xx ответа на полученные запросы, направляя
         клиент для связи с альтернативным набором URI.Регистратор: Регистратор - это сервер, который принимает запросы РЕГИСТРАЦИИ.
         и помещает информацию, которую он получает в этих запросах, в
         служба определения местоположения для обрабатываемого домена.

      Обычная транзакция: Обычная транзакция - это любая транзакция с
         метод, отличный от INVITE, ACK или CANCEL.

      Запрос: SIP-сообщение, отправленное от клиента на сервер, для
         цель вызова определенной операции.

      Ответ: SIP-сообщение, отправленное с сервера клиенту, для
         с указанием статуса запроса, отправленного от клиента к
         сервер.Обратный звонок: Обратный звонок - это звуковой сигнал, издаваемый вызывающим
         заявка стороны, указывающая, что вызываемая сторона
         предупрежден (звонит).

      Набор маршрутов: набор маршрутов представляет собой набор упорядоченных URI SIP или SIPS.
         которые представляют собой список прокси, которые необходимо пройти, когда
         отправка конкретного запроса. Набор маршрутов можно узнать,
         через заголовки, такие как Record-Route, или его можно настроить.

      Сервер: Сервер - это сетевой элемент, который принимает запросы в
         заказывает их обслуживание и отправляет ответы тем
         Запросы.Примеры серверов: прокси, серверы пользовательских агентов,
         перенаправить серверы и регистраторы.

      Последовательный поиск: при последовательном поиске прокси-сервер пытается
         каждый контактный адрес последовательно, переходя к следующему
         только после того, как предыдущий произвел окончательный ответ. A 2xx
         или окончательный ответ класса 6xx всегда завершает последовательный
         поиск.

      Сессия: Из спецификации SDP: «Мультимедийный сеанс - это
         набор мультимедийных отправителей и получателей и потоков данных
         перетекает от отправителя к получателю.Мультимедийная конференция - это
         пример мультимедийного сеанса. "(RFC 2327 [1]) (сеанс
         как определено для SDP, может включать один или несколько сеансов RTP.) Как
         определено, вызываемый может быть приглашен несколько раз, разными
         звонки в тот же сеанс. Если используется SDP, сеанс
         определяется конкатенацией имени пользователя SDP, идентификатора сеанса,
         тип сети, тип адреса и элементы адреса в источнике
         поле.

      SIP-транзакция: SIP-транзакция происходит между клиентом и
         сервер и содержит все сообщения из первого отправленного запроса
         от клиента к серверу до окончательного (не 1xx) ответа

         отправлено с сервера клиенту.Если запрос INVITE
         и окончательный ответ не-2xx, транзакция также
         включает ACK в ответ. ACK для ответа 2xx на
         запрос INVITE - это отдельная транзакция.

      Спираль: спираль - это SIP-запрос, который направляется прокси,
         пересылается вперед и снова приходит к этому прокси, но
         на этот раз отличается, что приведет к другому
         решение обработки, чем исходный запрос. Обычно это
         означает, что Request-URI запроса отличается от предыдущего
         прибытие.В отличие от петли, спираль не является ошибкой. А
         Типичная причина этого - переадресация звонков. Пользователь звонит
         [email protected] Прокси-сервер example.com пересылает его Джо
         ПК, который, в свою очередь, пересылает его на адрес [email protected] Этот
         запрос передается обратно на прокси example.com. Однако,
         это не петля. Поскольку запрос нацелен на
         другого пользователя, это считается спиралью и является действительным
         состояние.

      Прокси-сервер с отслеживанием состояния: логический объект, который поддерживает клиента и
         конечные автоматы транзакций сервера, определенные этой спецификацией
         во время обработки запроса, также известного как транзакция
         прокси с отслеживанием состояния.Дальнейшее поведение прокси с отслеживанием состояния
         определено в Разделе 16. Прокси-сервер (транзакция) с отслеживанием состояния не
         то же, что и прокси-сервер с отслеживанием состояния вызова.

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

      Строгая маршрутизация: прокси-сервер называется строгой маршрутизацией, если он следует
         правила обработки маршрутов RFC 2543 и многие предыдущие работы в
         текущие версии этого RFC.Это правило заставляло прокси
         уничтожить содержимое Request-URI, когда заголовок Route
         поле присутствовало. Строгий режим маршрутизации в этом
         спецификации в пользу свободной маршрутизации. Прокси
         которые выполняют строгую маршрутизацию, также известны как строгие маршрутизаторы.

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

      Пользователь транзакции (TU): уровень обработки протокола, который
         находится над уровнем транзакции.Пользователи транзакции включают
         ядро UAC, ядро ​​UAS и ядро ​​прокси.

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

      Кодировка URL: строка символов, закодированная в соответствии с RFC 2396,
         Раздел 2.4 [5].

      Клиент пользовательского агента (UAC): клиент пользовательского агента является логическим объектом.
         который создает новый запрос, а затем использует клиента
         государственная машина транзакции для его отправки.Роль ОАК длится
         только на время этой транзакции. Другими словами, если
         часть программного обеспечения инициирует запрос, она действует как UAC для
         продолжительность этой транзакции. Если он получает запрос
         позже он принимает на себя роль сервера пользовательского агента для
         обработка этой транзакции.

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

      Сервер пользовательского агента (UAS): сервер пользовательского агента - это логическая сущность.
         который генерирует ответ на SIP-запрос.Ответ
         принимает, отклоняет или перенаправляет запрос. Эта роль длится
         только на время этой транзакции. Другими словами, если
         часть программного обеспечения отвечает на запрос, она действует как БПЛА для
         продолжительность этой транзакции. Если он генерирует запрос
         позже он принимает на себя роль клиента пользовательского агента для
         обработка этой транзакции.

      Ядро БПЛА: Набор функций обработки, необходимых для БПЛА, который
         находится над транзакционным и транспортным уровнями.Пользовательский агент (UA): логический объект, который может действовать как пользователь
         клиент агента и сервер пользовательского агента.

   Роль UAC и UAS, а также прокси-серверов и серверов перенаправления:
   определяется для каждой отдельной транзакции. Например, пользователь
   агент, инициирующий вызов, действует как UAC при отправке начального ПРИГЛАШЕНИЯ
   запроса и как UAS при получении запроса BYE от вызываемого.
   Точно так же одно и то же программное обеспечение может выступать в качестве прокси-сервера для одного
   запроса и в качестве сервера перенаправления для следующего запроса.Указанные выше прокси, серверы местоположения и регистраторы являются логическими.
   сущности; реализации МОГУТ объединить их в одно приложение.

7 сообщений SIP

   SIP - это текстовый протокол, использующий кодировку UTF-8 (RFC 2279
   [7]).

   Сообщение SIP - это либо запрос от клиента к серверу, либо
   ответ сервера клиенту.

   И запросы (раздел 7.1), и сообщения ответа (раздел 7.2) используют
   базовый формат RFC 2822 [3], хотя синтаксис отличается
   набор символов и особенности синтаксиса.(SIP допускает поля заголовка,
   не будут допустимыми полями заголовка RFC 2822, например.) Оба типа
   сообщений состоят из начальной строки, одного или нескольких полей заголовка,
   пустая строка, указывающая конец полей заголовка, и необязательный
   тело сообщения.

         generic-message = начальная строка
                             *Заголовок сообщения
                             CRLF
                             [тело сообщения]
         start-line = Строка запроса / Строка состояния

   Начальная строка, каждая строка заголовка сообщения и пустая строка ДОЛЖНЫ быть
   завершается последовательностью перевода строки с возвратом каретки (CRLF).Обратите внимание, что
   пустая строка ДОЛЖНА присутствовать, даже если тело сообщения отсутствует.

   За исключением указанной выше разницы в наборах символов, большая часть SIP
   синтаксис поля сообщения и заголовка идентичен HTTP / 1.1. Скорее
   вместо того, чтобы повторять здесь синтаксис и семантику, мы используем [HX.Y] для обозначения
   согласно разделу X.Y текущей спецификации HTTP / 1.1 (RFC 2616 [8]).

   Однако SIP не является расширением HTTP.

7.1 Запросы

   SIP-запросы отличаются наличием строки запроса для начала:
   линия.Строка запроса содержит имя метода, URI запроса и
   версия протокола, разделенная одним символом пробела (SP).

   Строка запроса заканчивается CRLF. CR или LF не допускаются, кроме
   последовательность CRLF конца строки. Линейные пробелы (LWS) не допускаются.
   в любом из элементов.

         Строка запроса = Метод SP URI запроса SP Версия SIP CRLF

      Метод: В этой спецификации определены шесть методов: РЕГИСТРАЦИЯ для
           регистрация контактной информации, ПРИГЛАШЕНИЕ, ПОДТВЕРЖДЕНИЕ и ОТМЕНА для
           настройка сеансов, BYE для завершения сеансов и
           ВАРИАНТЫ для запроса серверов об их возможностях.ГЛОТОК
           расширения, задокументированные в стандартах, отслеживают RFC, могут определять
           дополнительные методы.

      Request-URI: Request-URI - это SIP или SIPS URI, как описано в
           Раздел 19.1 или общий URI (RFC 2396 [5]). Это указывает
           пользователь или сервис, которому адресован этот запрос.
           Request-URI НЕ ДОЛЖЕН содержать неэкранированные пробелы или элементы управления.
           символы и НЕ ДОЛЖНЫ заключаться в "<>".

           Элементы SIP МОГУТ поддерживать Request-URI со схемами, отличными от
           "sip" и "sips", например схема URI "tel" в RFC
           2806 [9].Элементы SIP МОГУТ переводить не-SIP URI с использованием любых
           механизм в их распоряжении, в результате чего SIP URI, SIPS URI,
           или какая-то другая схема.

      Версия SIP: как сообщения запроса, так и сообщения ответа включают
           используемая версия SIP и следуйте [h4.1] (с заменой HTTP
           по SIP, а HTTP / 1.1 заменен на SIP / 2.0) относительно версии
           заказ, соответствие требованиям и обновление версии
           числа. Чтобы соответствовать этой спецификации,
           приложения, отправляющие сообщения SIP, ДОЛЖНЫ включать версию SIP.
           компании «СИП / 2.0 ". Строка SIP-Version не чувствительна к регистру,
           но реализации ДОЛЖНЫ отправлять заглавные буквы.

           В отличие от HTTP / 1.1, SIP рассматривает номер версии как буквальный
           строка. На практике это не должно иметь значения.

7.2 Ответы

   Ответы SIP отличаются от запросов наличием строки состояния.
   как их стартовая линия. Строка состояния состоит из версии протокола.
   за которым следует числовой код состояния и связанная с ним текстовая фраза,
   с каждым элементом, разделенным одним символом SP.CR или LF не разрешены, кроме последней последовательности CRLF.

      Строка состояния = Версия SIP SP Код состояния SP Причина-фраза CRLF

   Код состояния - это трехзначный целочисленный код результата, который указывает
   результат попытки понять и удовлетворить запрос. В
   Reason-Phrase предназначен для краткого текстового описания
   Статус-код. Статус-код предназначен для использования автоматами,
   в то время как фраза-причина предназначена для человека. Клиент
   не требуется изучать или отображать Фразу-причину.Хотя эта спецификация предлагает конкретную формулировку по причине
   фраза, реализации МОГУТ выбрать другой текст, например, в
   язык, указанный в поле заголовка Accept-Language
   запрос.

   Первая цифра кода состояния определяет класс ответа.
   Последние две цифры не имеют роли категоризации. За это
   причина, любой ответ с кодом состояния от 100 до 199 является
   называемый «ответ 1xx», любой ответ с кодом состояния
   между 200 и 299 как «ответ 2xx» и так далее.SIP / 2.0 позволяет
   шесть значений для первой цифры:

      1xx: Предварительно - запрос получен, обработка продолжается.
           запрос;

      2xx: Success - действие успешно получено, понято,
           и принято;

      3xx: перенаправление - необходимо предпринять дальнейшие действия, чтобы
           заполнить заявку;

      4xx: ошибка клиента - запрос содержит неверный синтаксис или не может быть
           выполняется на этом сервере;

      5xx: Ошибка сервера - серверу не удалось выполнить явно
           действительный запрос;

      6xx: Global Failure - запрос не может быть выполнен ни при каких условиях.
           сервер.Раздел 21 определяет эти классы и описывает отдельные коды.

7.3 Поля заголовка

   Поля заголовка SIP аналогичны полям заголовка HTTP в обоих синтаксисах.
   и семантика. В частности, поля заголовка SIP следуют за [h5.2]
   определения синтаксиса заголовка сообщения и правила для
   расширение полей заголовка на несколько строк. Однако последний
   указан в HTTP с неявными пробелами и сворачиванием. Этот
   спецификация соответствует RFC 2234 [10] и использует только явные
   пробелы и сворачивание как неотъемлемая часть грамматики.[h5.2] также указывает, что несколько полей заголовка одного поля
   имя, значение которого представляет собой список, разделенный запятыми, можно объединить в один
   поле заголовка. Это относится и к SIP, но конкретное правило
   разные из-за разной грамматики. В частности, любой SIP
   заголовок, грамматика которого имеет форму

      header = "имя-заголовка" Значение заголовка HCOLON * (значение заголовка ЗАПЯТАЯ)

   позволяет объединять поля заголовка с тем же именем в запятую.
   разделенный список. Поле заголовка контакта позволяет использовать разделенные запятыми
   list, если значение поля заголовка не равно «*».7.3.1 Формат поля заголовка

   Поля заголовка следуют тому же общему формату заголовка, что и приведенный в
   Раздел 2.2 RFC 2822 [3]. Каждое поле заголовка состоит из поля
   имя, за которым следует двоеточие (":") и значение поля.

      имя-поля: значение-поля

   Формальная грамматика для заголовка сообщения, указанная в разделе 25.
   позволяет использовать произвольное количество пробелов по обе стороны от
   двоеточие; однако реализации должны избегать пробелов между полями
   имя и двоеточие и используйте один пробел (SP) между двоеточием и
   значение поля.Тема: обед
      Тема: обед
      Тема: обед
      Тема: обед

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

   Поля заголовка можно расширить на несколько строк, поставив перед каждой
   дополнительная строка хотя бы с одной SP или горизонтальной табуляцией (HT). Линия
   break и пробел в начале следующей строки
   рассматривается как один символ SP. Таким образом, следующие
   эквивалент:

      Тема: Я знаю, что вы там, возьмите трубку и поговорите со мной!
      Тема: Я знаю, что ты там,
               возьми трубку
               и поговори со мной!

   Относительный порядок полей заголовка с разными именами полей не
   значительное.Однако РЕКОМЕНДУЕТСЯ, чтобы поля заголовка
   необходим для обработки прокси (Via, Route, Record-Route, Proxy-Require,
   Max-Forwards и Proxy-Authorization, например) появляются в направлении
   вверху сообщения, чтобы облегчить быстрый анализ. Относительная
   порядок строк поля заголовка с одинаковым именем поля важен.
   Несколько строк поля заголовка с одним и тем же именем поля МОГУТ присутствовать в
   сообщение тогда и только тогда, когда все значение поля для этого поля заголовка
   определяется как список, разделенный запятыми (то есть, если следует грамматике
   определено в разделе 7.3). ДОЛЖНА быть возможность комбинировать несколько
   строки поля заголовка в одну пару "имя-поля: значение поля", без
   изменяя семантику сообщения, добавляя каждый последующий
   значение поля до первого, каждое через запятую. Исключения
   к этому правилу относятся WWW-Authenticate, Authorization, Proxy-
   Поля заголовка Authenticate и Proxy-Authorization. Множественный заголовок

   строки полей с этими именами МОГУТ присутствовать в сообщении, но поскольку
   их грамматика не соответствует общей форме, указанной в разделе 7.3,
   они НЕ ДОЛЖНЫ быть объединены в одну строку поля заголовка.

   Реализации ДОЛЖНЫ иметь возможность обрабатывать несколько строк поля заголовка.
   с тем же именем в любой комбинации одного значения в строке или
   Формы значений, разделенных запятыми.

   Следующие группы строк поля заголовка допустимы и эквивалентны:

      Маршрут: 
      Тема: Обед
      Маршрут: 
      Маршрут: 

      Маршрут: , 
      Маршрут: 
      Тема: Обед

      Тема: Обед
      Маршрут: , ,
             

   Каждый из следующих блоков действителен, но не эквивалентен
   другие:

      Маршрут: 
      Маршрут: 
      Маршрут: 

      Маршрут: 
      Маршрут: 
      Маршрут: 

      Маршрут: , ,
             

   Формат значения поля заголовка определяется для каждого имени заголовка. Это
   всегда будет либо непрозрачной последовательностью октетов TEXT-UTF8, либо
   сочетание пробелов, токенов, разделителей и строк в кавычках.
   Многие существующие поля заголовка будут соответствовать общей форме
   значение, за которым следует последовательность имени параметра, разделенная точкой с запятой,
   пары параметр-значение:

         имя-поля: значение-поля * (; имя-параметра = значение-параметра)

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

      Контакты: ; истекает = 3600

   эквивалентно

      КОНТАКТ: ; ExPiReS = 3600

   а также

      Content-Disposition: сеанс; обработка = необязательно

   эквивалентно

      content-disposition: Session; ОБРАБОТКА = НЕОБЯЗАТЕЛЬНО

   Следующие два поля заголовка не эквивалентны:

      Предупреждение: 370 devnull "Выберите трубу побольше"
      Предупреждение: 370 devnull "ВЫБЕРИТЕ БОЛЬШУЮ ТРУБУ"

7.3.2 Классификация поля заголовка

   Некоторые поля заголовка имеют смысл только в запросах или ответах. Эти
   называются полями заголовка запроса и полями заголовка ответа,
   соответственно. Если поле заголовка появляется в сообщении, не соответствующем
   свою категорию (например, поле заголовка запроса в ответе), он ДОЛЖЕН
   игнорировать. Раздел 20 определяет классификацию каждого заголовка.
   поле.

7.3.3 Компактная форма

   SIP предоставляет механизм для представления общих имен полей заголовков в
   сокращенная форма.Это может быть полезно, когда сообщения иначе
   стать слишком большим, чтобы его можно было перевозить на доступном ему транспорте
   (превышение максимальной единицы передачи (MTU) при использовании UDP, для
   пример). Эти компактные формы определены в разделе 20. Компакт
   форма МОЖЕТ быть заменена более длинной формой имени поля заголовка в
   в любое время без изменения семантики сообщения. Заголовок

   имя поля МОЖЕТ появляться как в длинной, так и в краткой форме в пределах одного
   сообщение. Реализации ДОЛЖНЫ принимать как длинные, так и короткие формы.
   каждого имени заголовка.7.4 Органы

   Запросы, включая новые запросы, определенные в расширениях к этому
   В спецификации МОЖЕТ содержать тела сообщения, если не указано иное.
   Интерпретация тела зависит от метода запроса.

   Для ответных сообщений метод запроса и статус ответа.
   код определяет тип и интерпретацию любого тела сообщения. Все
   ответы МОГУТ включать тело.

7.4.1 Тип тела сообщения

   Тип Интернет-носителя тела сообщения ДОЛЖЕН быть задан
   Поле заголовка Content-Type.Если тело подвергалось какой-либо кодировке
   например, сжатие, то это ДОЛЖНО быть указано в Content-
   Поле заголовка кодировки; в противном случае ДОЛЖНО быть опущено Content-Encoding.
   Если возможно, набор символов тела сообщения указывается как
   часть значения поля заголовка Content-Type.

   "Multipart" MIME-тип, определенный в RFC 2046 [11], МОЖЕТ использоваться в
   тело сообщения. Реализации, отправляющие запросы
   содержащие составные тела сообщения ДОЛЖНЫ отправлять описание сеанса
   как тело сообщения, не состоящее из нескольких частей, если удаленная реализация запрашивает
   это через поле заголовка Accept, которое не содержит multipart.Сообщения SIP МОГУТ содержать двоичные тела или части тела. Когда нет
   явный параметр charset предоставляется отправителем, подтипы медиа
   типа "текст" определены, чтобы иметь значение кодировки по умолчанию
   «UTF-8».

7.4.2 Длина тела сообщения

   Длина тела в байтах предоставляется заголовком Content-Length.
   поле. Раздел 20.14 описывает необходимое содержимое этого заголовка.
   поле подробно.

   Кодирование передачи HTTP / 1.1 "по частям" НЕ ДОЛЖНО использоваться для SIP.
   (Примечание: фрагментированная кодировка изменяет тело сообщения по порядку
   передать его как серию кусков, каждый со своим размером
   показатель.)

7.5 Фрейминг сообщений SIP

   В отличие от HTTP, реализации SIP могут использовать UDP или другие ненадежные
   протоколы дейтаграмм. Каждая такая дейтаграмма содержит один запрос или
   ответ. См. Раздел 18 об ограничениях на использование ненадежных
   транспорты.

   Реализации, обрабатывающие SIP-сообщения с потоковой ориентацией
   транспорты ДОЛЖНЫ игнорировать любые CRLF, появляющиеся перед стартовой строкой
   [h5.1].

      Значение поля заголовка Content-Length используется для определения конца
      каждое сообщение SIP в потоке. Он всегда будет присутствовать, когда SIP
      сообщения отправляются через потоковый транспорт.8 Общее поведение агента пользователя

   Пользовательский агент представляет собой конечную систему. Он содержит пользовательский агент
   клиент (UAC), который генерирует запросы, и сервер пользовательского агента
   (UAS), который им отвечает. UAC может генерировать
   запрос, основанный на некотором внешнем стимуле (пользователь нажимает кнопку,
   или сигнал на линии PSTN) и обработка ответа. БПЛА - это
   способен принимать запрос и генерировать ответ на основе
   пользовательский ввод, внешний стимул, результат выполнения программы или
   какой-то другой механизм.Когда UAC отправляет запрос, запрос проходит через некоторое количество
   прокси-серверы, которые перенаправляют запрос к UAS. Когда
   UAS генерирует ответ, ответ пересылается в UAC.

   Процедуры UAC и UAS сильно зависят от двух факторов. Во-первых, на основе
   от того, находится ли запрос или ответ внутри или вне диалога,
   во-вторых, в зависимости от метода запроса. Обсуждаются диалоги
   полностью в Разделе 12; они представляют собой одноранговые отношения
   между пользовательскими агентами и устанавливаются определенными методами SIP, такими как
   как ПРИГЛАСИТЬ.В этом разделе мы обсуждаем независимые от метода правила для UAC и
   Поведение UAS при обработке запросов вне диалога.
   Это, конечно, включает запросы, которые сами по себе устанавливают
   диалог.

   Процедуры безопасности для запросов и ответов вне диалога
   описаны в Разделе 26. В частности, существуют механизмы для
   UAS и UAC для взаимной аутентификации. Ограниченный набор конфиденциальности
   функции также поддерживаются за счет шифрования тел с использованием
   S / MIME.8.1 Поведение UAC

   В этом разделе рассматривается поведение UAC вне диалога.

8.1.1 Генерация запроса

   Действительный SIP-запрос, сформулированный UAC, ДОЛЖЕН как минимум содержать
   следующие поля заголовка: To, From, CSeq, Call-ID, Max-Forwards,
   и Via; все эти поля заголовка обязательны для всех SIP
   Запросы. Эти шесть полей заголовка являются фундаментальным элементом
   блоки сообщения SIP, так как они совместно обеспечивают большую часть
   службы маршрутизации критических сообщений, включая адресацию
   сообщения, маршрутизация ответов, ограничение распространения сообщений,
   упорядочивание сообщений и уникальная идентификация транзакций.Эти поля заголовка дополняют обязательную строку запроса,
   который содержит метод, Request-URI и версию SIP.

   Примеры запросов, отправленных вне диалога, включают ПРИГЛАШЕНИЕ на
   установить сеанс (раздел 13) и ОПЦИИ для запроса
   возможности (Раздел 11).

8.1.1.1 Request-URI

   Первоначальный Request-URI сообщения ДОЛЖЕН быть установлен на значение
   URI в поле Кому. Одно примечательное исключение - РЕГИСТР.
   метод; поведение для установки Request-URI для REGISTER приведено в
   Раздел 10.Это также может быть нежелательно по соображениям конфиденциальности или
   удобство установки в этих полях одного и того же значения (особенно если
   исходящий UA ожидает, что Request-URI будет изменен во время
   транзит).

   В некоторых особых случаях наличие уже существующего маршрута
   set может повлиять на Request-URI сообщения. Существующий ранее маршрут
   set - это упорядоченный набор URI, который идентифицирует цепочку серверов, чтобы
   который UAC будет отправлять исходящие запросы, не входящие в диалог.
   Обычно они настраиваются на UA пользователем или поставщиком услуг.
   вручную или через какой-либо другой механизм, отличный от SIP.Когда провайдер
   желает настроить UA с исходящим прокси, РЕКОМЕНДУЕТСЯ
   чтобы это было сделано, предоставив ему уже существующий маршрут, установленный с
   единственный URI исходящего прокси.

   При наличии уже существующего набора маршрутов процедуры для
   заполнение полей Request-URI и Route, подробно описанных в разделе
   12.2.1.1 ДОЛЖЕН выполняться (даже если диалоговое окно отсутствует), используя
   желаемый Request-URI в качестве удаленного целевого URI.

8.1.1.2 Кому

   В поле заголовка To в первую очередь указывается желаемый
   "логический" получатель запроса или адрес записи
   пользователь или ресурс, являющийся целью этого запроса.Это может или может
   не быть конечным получателем запроса. Поле заголовка Кому
   МОЖЕТ содержать URI SIP или SIPS, но может также использовать другой URI
   схемы (например, телефонный URL (RFC 2806 [9])), когда это необходимо.
   Все реализации SIP ДОЛЖНЫ поддерживать схему SIP URI. любой
   реализация, поддерживающая TLS, ДОЛЖНА поддерживать схему SIPS URI.
   Поле заголовка «Кому» позволяет отображать имя.

   UAC может узнать, как заполнить поле заголовка To для конкретного
   запрос несколькими способами.Обычно пользователь предлагает Кому
   поле заголовка через человеческий интерфейс, возможно, ввод URI
   вручную или выбрав его из какой-то адресной книги. Часто,
   пользователь вводит не полный URI, а скорее строку цифр
   или буквы (например, «боб»). Это на усмотрение UA.
   выбрать, как интерпретировать этот ввод. Используя строку для формирования
   пользовательская часть SIP URI подразумевает, что UA желает, чтобы имя было
   разрешено в домене справа (RHS) от входа в систему
   SIP URI (например, sip: bob @ example.com). Использование строки для
   пользовательская часть SIPS URI подразумевает, что UA желает
   безопасно общаться, и что имя должно быть разрешено в
   домен справа от знака at. RHS часто будет
   домашний домен отправителя запроса, что позволяет домашнему домену
   обработать исходящий запрос. Это полезно для таких функций, как
   «быстрый набор», требующий интерпретации абонентской части дома
   домен. URL-адрес телефона может использоваться, когда UA не желает указывать
   домен, который должен интерпретировать телефонный номер, который был
   ввод пользователем.Вернее, каждый домен, через который поступает запрос
   пропускам будет предоставлена ​​такая возможность. Например, пользователь в
   аэропорт может входить в систему и отправлять запросы через исходящий прокси в
   аэропорт. Если они введут «411» (это номер телефона местного
   справочная служба в США), что необходимо
   интерпретируется и обрабатывается исходящим прокси в аэропорту, а не
   домашний домен пользователя. В этом случае тел: 411 будет правильным
   выбор.

   Запрос вне диалога НЕ ДОЛЖЕН содержать тега To; тег в
   Поле To запроса идентифицирует однорангового участника диалога.поскольку
   диалог не установлен, тег отсутствует.

   Для получения дополнительной информации о поле заголовка Кому см. Раздел 20.39.
   Ниже приведен пример действительного поля заголовка To:

      Кому: Кэрол 

8.1.1.3 Из

   Поле заголовка From указывает логический идентификатор инициатора.
   запроса, возможно, адрес записи пользователя. Как Кому
   поле заголовка, оно содержит URI и, возможно, отображаемое имя. это
   используются элементами SIP, чтобы определить, какие правила обработки применять к
   запрос (например, автоматический отказ от звонка).Таким образом, это
   очень важно, чтобы URI отправителя не содержал IP-адресов или FQDN.
   хоста, на котором запущен UA, поскольку это не журнал 

alexkg1

: 11.11.2008
#: 73,157
: 1266

: 30, 2018 16:30:

_________________
()
!

UmmaGumma

: 06.08.2003
#: 8,524
: 3623
:.

: 54

: 31, 2018 1:25: Re:

_________________

alexkg1

: 11.11.2008
#: 73,157
: 1266

: 31, 2018 14:19:

_________________
()
alexkg1

: 11.11.2008
№: 73,157
: 1266

: 31, 2018 14:40:

_________________
()
rex_3
Windows guru

: 23.02.2005
#: 24,533
: 13257
:

: 132

: 31, 2018 16:55:

_________________
,.
.
alexkg1

: 11.11.2008
#: 73,157
: 1266

: 01, 2018 8:51:

_________________
()
alexkg1

: 11.11.2008
№: 73,157
: 1266

: 07, 2018 19:46:

_________________
()
rex_3
Windows guru

: 23.02.2005
#: 24,533
: 13257
:

: 132

: 07, 2018 22:59:

_________________
,.
.
alexkg1

: 11.11.2008
#: 73,157
: 1266

: 07, 2018 23:11:

_________________
()
alexkg1

: 11.11.2008
№: 73,157
: 1266

: 07, 2018 23:21:

_________________
()

.

Добавить комментарий

Ваш адрес email не будет опубликован.