Токовые нагрузки сип 4: Здравствуйте, не подскажите какая максимальная нагрузка в кВт на провод СИП 2х16 и СИП 2х25 мм — Технические вопросы по кабелю — Технический форум — groupnk.ru — Группа НК — комплексные поставки электрооборудования в Москве и регионах

Содержание

Провод СИП-4 4х50

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

Технические характеристики

Номинальное напряжение: 0.6/1кВ
Температура окружающей среды при эксплуатации кабеля от -60°С до +50°С
Минимальная температура прокладки кабеля без предварительного подогрева -20°С
Предельная длительно допустимая рабочая температура жил 90°С
Предельно допустимая температура нагрева жил кабелей в аварийном режиме или режиме перегрузки 130°С
Максимальная температура нагрева жил при коротком замыкании 250°С
Минимально допустимый радиус изгиба при прокладке 7,5 диаметров кабеля
Срок службы, не менее 30 лет
Гарантийный срок эксплуатации кабеля 3 года
Провода после выдержки в воде при температуре (20±10)°C в течение 10 минут должны выдерживать на строительной длине испытание переменным напряжением частотой 50Гц в течение не менее 5 минут: самонесущие изолированные – 4кВ; защищенные на номинальное напряжение 20кВ-6кВ

Пробивное напряжение защитной изоляции защищенных проводов после выдержки в воде при температуре (20±5)°С в течение не менее 1 часа должно быть: для проводов на номинальное напряжение 20кВ, не менее-24 кВ переменного тока частотой 50Гц

Марка	Кол-во жил	Сечение жилы, мм ²	Материал жилы	Расчётная масса, кг/км	Наружный диаметр, мм
СИП-4 4х50	4	50	Алюминий	730	27,4

Допустимые токовые нагрузки проводов марки СИП-4 4х50

Допустимый ток нагрузки, А, не более	Допустимый ток односекундного короткого замыкания, кА, не более	Электрическое ссопротивление токопрводящих жил на длине 1 км, Ом, не более
195	4,6	0,641

Categories: Самонесущий изолированный провод(кабель) СИП-4

Провод СИП | elesant.

Вступление

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

Особенности проводов СИП

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

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

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

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

Технические и эксплуатационные характеристики проводов СИП:

Номинальное напряжение 0,6/1,0 кВ
Температура окружающей среды от -50˚С до +50˚С
Относительная влажность воздуха 98%
Минимальная рабочая температура для прокладки провода без подогрева -20°С
Предельно допустимая рабочая температура жил +90˚С
Предельно допустимая температура нагрева жил в аварийном режиме, а такжепри режиме перегрузки: +130˚С
Максимальная температура нагрева жил при коротком замыкании +250˚С
Срок службы 40 лет

Разберем номенклатуру проводов СИП и их характеристики.

Провод СИП 1

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

Импортный аналог: AXKA

Провод СИП 2

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

Импортные аналоги: AXKA-T, AsXSn (Польша), Torsada (Франция), AsXS.

Номинальные значения токопроводящих жил провода СИП 1 и СИП 2, в таблице ниже:

Номинальное сечение фазной токопроводящей жилы, мм2	Число проволок в жиле, штук.	Наружный диаметр токопроводящей жилы, мм.	Электрическое сопротивление 1 киллометра фазной жилы постоянному току, Ом, не более
16	1	4,35-4,45	1,910
16	7	4,60-5,10	1,910
25	7	5,7-6,1	1,200
35	7	6,7-7,1	0,868
50	7	7,85-8,35	0,641
70	7	9,45-9,95	0,443
95	7	11,1-11,7	0,320
95	19	11,0-12,0	0,320
120	19	12,5-13,1	0,253
150	19	14,0-14,5	0,206

Номинальные значения нулевых, несущих жил провода СИП 1 и СИП 2,в таблице ниже:

Номинальное сечение несущих жил, мм2	Допустимый ток нагрузки, А, не более	Допустимый ток односекундного короткого замыкания, кА, не более
16	100	1. 5
25	130	2.3
35	160	3.2
50	195	4.6
70	240	6.5
95	300	8.8
120	340	10.9
150	380	13.2

Провод СИП 3

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

Аналоги:PAS, SAX (Финляндия)

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

Номинальное сечение основных жил, мм2	Допустимый ток нагрузки, А, не более	Допустимый ток односекундного короткого замыкания, кА, не более
35	200	3,0
50	245	4,3
70	310	6,0
95	370	8,2
120	430	10,3
150	485	12,9

Провод СИП 4

Токопроводящие жилы алллюминевые, многопроволочные, круглые. Число жил 2-4.Жилы уплотненные (компактированные). Сечение жил 16-150 мм2.При прокладке допустимый радиус изгиба 7,5 диаметра провода

Номинальное сечение основных жил, мм2	Допустимый ток нагрузки, А, не более	Допустимый ток односекундного короткого замыкания, кА, не более
35	200	3,0
50	245	4,3
70	310	6,0
95	370	8,2
120	430	10,3
150	485	12,9

Аналог: NFA2X; ALUS (Швеция).

Диаметр жил провода СИП

Без проводов для освещения:

Число жил и сечение	Наружный диаметр провода, мм
1х16+1х25	17
3х16+1х25	22
3х25+1х35	26
3х35+1х50	30
3х50+1х50	33
3х50+1х70	35
3х70+1х70	38
3х70+1х95	41
3х95+1х70	43
3х95+1х95	44
3х120+1х95	47
3х150+1х95	49
4х25+1х25	22
4х25+1х35

С проводами для освещения:

Число жил и сечение	Наружный диаметр провода, мм
3х25+1х35+1х16	28
3х25+1х35+1х16(ож)	28
3х35+1х50+1х16	30
3х35+1х50+1х25	30
3х50+1х50+1х16	33
3х50+1х50+1х25	33
3х50+1х70+1х16	35
3х50+1х70+1х25	35
3х70+1х70+1х16	38
3х70+1х70+1х25	38
3х70+1х95+1х16	40
3х70+1х95+1х25	40
3х95+1х70+1х16	42
3х95+1х70+1х25	42
3х95+1х95+1х16	44
3х95+1х95+1х25	44
3х120+1х95+1х16	47
3х150+1х95+1х16	50
3х120+1х95+1х25	47
4х25+1х35+1х16	29
3х25+1х35+2х16	28
3х25+1х54,6+2х16	30
3х25+1х54,6+2х25	30
3х35+1х50+2х16	30
3х35+1х54,6+2х16	32
3х35+1х54,6+2х25	32
3х50+1х50+2х16	33
3х50+1х54,6+2х25	35
3х70+1х70+2х16	35
3х70+1х54,6+2х16	38
3х70+1х54,6+2х25	38
3х70+1х70+2х16	38
3х70+1х95+2х16	40
3х95+1х70+2х16	42
3х95+1х95+2х16	44
3х120+1х95+2х16	47

Еще статьи

Провод СИП назначение, применение, технические характеристики — Офремонт

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

Что такое кабель СИП

Маркировка кабеля в себе несет существенную информацию. Так кабель СИП расшифровывается так:

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

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

Кабель СИП почасту применяют если нужно провести электричество к дому по воздуху

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

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

Виды и назначение

Кабель СИП — востребованная марка продукции кабельной сферы, так как он оптимален для подсоединения электричества к приватному дому. Имеет сравнительно небольшую цену, хорошие технические специфики. Есть 3-х видов:

с нагой несущей нейтралью;
изолированной несущей нейтралью;
самонесущий.

Его часто можно заметить у часников и не только

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

С неизолированной нейтралью (СИП-1)

Кабель СИП с неизолированной нейтралью это АМКА по евростандарту. Он состоит из:

1-4 металлических проводящих ток проводников в изоляции из светостабилизированного полиэтилена сшитого типа;
1 несущего неизолированного провода из сплава алюминия или из чистого алюминия.

Приблизительно так смотрится кабель СИП 1

СИП1 применяют при прокладывании магистральных линий передачи и отводов от них в сухом и нормальном воздухе с низкой степенью загрязненности. Предназначаются для сетей с номинальным напряжением 0,6 кВ и 1 кВ (различные типы, нужно смотреть в технических спецификах) п частотой 50 Гц.

Самые большие токовые нагрузки СИП-1

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

При установке вес подвешенного кабеля несет жила без изоляции — ее цепляют на растяжки, прикрепляют до столбов и т.д. Собственно для увеличения несущей способности ее выполняют большего размера чем другие. В большинстве случаев этот оголенный проводник применяют как нейтраль. Токоведущие жилы изолированные. Применяют термопластичный полимерный этилен, который выдержит долгий нагрев до 60-70°С, непродолжительный — до 125°С. Линия электропередач, сооруженная на СИП-1 может держать солидные нагрузки снега.

Технические специфики Провода СИП-1

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

Кабель СИП с изолированной нейтралью (СИП-2, СИП-3)

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

1-4 токопроводящие (фазные) жилы в оболочке из светостабилизированного полиэтилена сшитого типа;
1 несущий кабель в аналогичный изоляции.

Внешний вид провода СИП-2

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

Самые большие токовые нагрузки СИП-2

СИП-3 имеет аналогичную структуру, но более толстую оболочку и именуется защищенным проводом. Этот самонесущий кабель может применяться в сетях с очень высоким номинальным напряжением: СИП-3-20 — до 20 кВ, СИП-3-35 — до 35 кВ. По техническим показателям (температуре эксплуатации, самому большому нагреву и т.д.) этот кабель аналогичный как и СИП-1. Так что эти сведения можно взять из таблицы в предыдущем пункте. Выделяются возможные токовые нагрузки (смотрите таблицу).

Самые большие токовые нагрузки СИП-3 в зависимости от сечения фазовых жил

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

Самонесущие провода без несущих жил (СИП-4, СИП-5, СИП-7)

Конструктивно эти самонесущие провода выделяются от предыдущих модификаций. У них нет несущего проводника и нагрузка делится на все жилы. По своей прочности они уступают модификациям с отмеченным несущим проводом. Потому в регионах со снежными зимами или частым обледенением их применять не стоит. Кол-во проводников в самонесущих проводах — от 2 до 4, могут быть с одним или 2-мя дополнительными осветительными проводами. Все провода скручены относительно общего центра с конкретным шагом. Одна из жил применяется как нейтральная, другие — как фазные.

Кабель СИП-4 рассчитывается на сети с самым большим напряжением 0,6 кВ или 1 кВ. За счёт отсутствия более толстой несущей жилы этот провод намного гибче — очень маленький радиус изгиба — 7,5 радиусов кабеля.

СИП-4 выделяется тем, что физнагрузка от массы кабеля и осадков распределена между всеми жилами

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

СИПн-4. Выделяется изоляцией не распространяющей горение.
СИПcн-4. Изоляция негорючая, в конструкции есть 1 или 2 дополнительных провода для освещения. Как правило имеет 1,2 или 3 подсобные жилы для цепей контроля (медные, сечением 1,5 мм?, 2,0 мм?, 4,0 мм?. В подобном случае в формулу, описывающую провод, прибавляются через плюс кол-во сигнальных или осветительных жил. К примеру: СИП-4 2*30 +1*16 (4-ре токопроводящие жилы диаметром 30 мм и одна запасная диаметром 16 мм).
СИПгсн-4. От предыдущего типа выделяется тем, что имеет водоблокирующий компонент в проводящей ток жиле.

В климате с малоснежными жилами от столба до дома магистраль можно довести СИП-4

Варианты СИПсн-4 и СИПгсн-4 имеют европейский аналог AsXSn, сходный по большинству характеристик и назначению.

Есть еще кабель СИП-5. Выделяется тем, что не как правило имеет дополнительных осветительных или сигнальных жил. Только изолированные токопроводящие жилы одного и того же диаметра. Кол-во жил- две, три 4-ре. Одна из них нейтральная, другие — фазы.

Вид СИП-7 — кабель одножильный с укрепленной многослойной изоляцией:

экрана по жиле из электропроводящего ПЭ;
изоляционного слоя из сшитого ПЭ;
слоя атмосферостойкого трекинго-стойкого ПЭ.

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

Преобразование телефона Cisco 7940/7960 CallManager в телефон SIP и обратный процесс

IP-телефоны Cisco 7940/7960 могут поддерживать протокол SCCP для работы с Cisco CallManager, протокол инициации сеанса (SIP) (см. RFC 2543) или протокол управления медиашлюзом (MGCP), но не более одного одновременно. Это возможно, потому что они загружают разные версии прошивки при загрузке. Эта функция прозрачна для конечного пользователя, и вы активируете ее путем внесения изменений в базовые текстовые файлы конфигурации, которые телефоны загружают с сервера упрощенного протокола передачи файлов (TFTP).

Дополнительные сведения об IP-телефоне Cisco SIP см. В Руководстве пользователя IP-телефона Cisco 7960/7940 для SIP.

1	ЖК
2	Кнопки линии или быстрого набора
3	Регулировка подножки
4	Программные клавиши
5	i кнопка
6	Кнопки экранного режима
7	Кнопки громкости
8	Переключение функций
9	Клавиша прокрутки
10	Телефонная панель
11	Трубка

Требования

Cisco рекомендует вам знать следующие темы:

Используемые компоненты

Информация в этом документе основана на следующих версиях программного и аппаратного обеспечения:

Примечание: Убедитесь, что протокол SIP поддерживается Cisco Unified Callmanager с моделью телефона Cisco IP, используемой для преобразования.Например, протокол SIP для телефонов Cisco IP 7906G и 7911G поддерживается только с Cisco Unified Communication Manager версии 5.x и выше.

Условные обозначения

См. Раздел «Условные обозначения технических советов Cisco» для получения дополнительной информации об условных обозначениях в документе.

Выполните следующие действия, чтобы включить функцию SIP:

Загрузите эти файлы из программного обеспечения Cisco SIP IP Phone 7940/7960 (только для зарегистрированных клиентов) и поместите их в корневой каталог своего TFTP-сервера (tftpboot на машине UNIX):

P0S30100.bin — это образ SIP. Загрузите файл в двоичном формате, чтобы убедиться, что он не поврежден.

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

SIP Release 2.3 или более ранней версии: P0S3 xxyy .bin — переменная xx — это номер версии, а yy — это номер подверсии.
SIP, выпуск 3.0 и новее: P0S3- xx — y — zz .bin — переменная xx является основным номером версии, y — второстепенным номером версии, а zz — номером подверсии. .
SIP Release 5.0 и новее: после установки этой версии вы не сможете вернуться к версиям ранее, чем 5.0. Вы по-прежнему можете перейти с образов SCCP на образы SIP, но оба они должны быть версии 5.0 или более поздней. См. Примечания к выпуску для IP-телефона Cisco SIP 7940/7960, выпуск 5.0 для получения дополнительной информации.

В этой таблице описаны значения первых четырех символов в именах двоичных файлов:

Первая цифра	Вторая цифра	Третья цифра	Четвертая цифра
P представляет собой телефон.	0 означает, что это комбинированный образ (приложение и DSP).	Представляет телефонный протокол: 0 для Skinny и S для SIP.	3 представляет процессор ARM.

Примечание: Выберите «Настройки »> «Состояние»> «Версии микропрограммного обеспечения », чтобы проверить, какой образ используется в телефоне. В разных моделях телефонов используются разные процессоры. Эта четвертая цифра может помочь определить модель телефона, для которой используется файл.

OS79XX.TXT — Этот файл сообщает Cisco 7940/7960, какой двоичный файл загружать с сервера TFTP.Этот файл чувствителен к регистру и должен содержать только имя файла, который вы хотите загрузить, без расширения .bin. Например, если вы пытаетесь загрузить программное обеспечение SIP версии 2.3, оно должно содержать только строку P0S30203. Если вы попытаетесь загрузить версии 3.0 и новее, имя файла должно быть в формате P0S3-xx-y-zz. Например, если вы пытаетесь загрузить программное обеспечение SIP версии 7.1, OS79XX.TXT должен содержать строку P0S3-07-1-00. Указанный здесь двоичный файл также должен присутствовать в корневом каталоге TFTP.Без этого файла телефон не знает, какой файл ему нужно получить, чтобы заменить существующее программное обеспечение.
SIPDefaultGeneric.cnf — этот файл является примером файла конфигурации по умолчанию. Этот файл содержит информацию о конфигурации, относящуюся ко всем телефонам.
SIPConfigGeneric.cnf — этот файл похож на предыдущий, за исключением того, что он содержит информацию, относящуюся к конкретному телефону, а не ко всем телефонам.
RINGLIST.DAT — список аудиофайлов, которые являются опциями настраиваемого типа звонка для телефонов. Аудиофайлы, перечисленные в файле RINGLIST.DAT, также должны находиться в корневом каталоге сервера TFTP.
ringer1.pcm — этот файл представляет собой образец мелодии звонка, который используется Cisco 7940/7960.

Примечание. В версии 3.0 и новее универсальный загрузчик приложений позволяет добавлять дополнительные функции телефона по всем протоколам. Эта функция также устраняет необходимость в отдельном OS79XX.TXT-файл, который раньше требовался для загрузки между протоколами.

Примечание: Универсальный загрузчик приложений для SIP поставляется в виде ZIP-файла, который размещается на сайте Cisco.com. Для SCCP универсальный загрузчик приложений автоматически устанавливается как часть исполняемой оболочки установки phone_load, которая используется в Cisco CallManager. ZIP-файл для SIP содержит пять файлов:

OS79XX.TXT — этот файл всегда содержит образ универсального загрузчика приложений.
P003 ……… bin — Небезопасный универсальный загрузчик приложений для обновлений с образов до 5.x.
P003 ……… sbn — Безопасный универсальный загрузчик приложений для обновлений с образов 5.x или новее.
P0 a 3 ……… load — файл, содержащий универсальный загрузчик приложения и образ приложения, где a представляет протокол файла образа приложения LOADS: 0 для SCCP и S для ГЛОТОК.
P0 a 3 ……… sb2 — Образ микропрограммы приложения, где a представляет образ микропрограммы приложения: 0 для SCCP и S для SIP.

Примечание: Создание файлов SIP CNF выходит за рамки этого документа. Дополнительные сведения см. В разделе «Начало работы с IP-телефоном Cisco SIP».

В текстовом редакторе (vi или «Блокнот») переименуйте файл SIPDefaultGeneric.cnf в SIPDefault.cnf (используется для глобальных параметров на всех телефонах).
В текстовом редакторе переименуйте файл SIPConfigGeneric.cnf в SIP mac_address .cnf для каждого телефона (например, SIP002094D245CB.cnf).
MAC-адрес должен быть указан заглавными буквами, а расширение (.cnf) должно быть в нижнем регистре. MAC-адрес телефона можно найти на наклейке, которая находится в нижней части телефона, или его можно найти на ЖК-экране телефона (выберите «Настройки »> «Конфигурация сети»> «MAC-адрес »).
Примечание: Разрешить чтение и запись файлов на сервере TFTP для этих файлов:
- На TFTP-серверах UNIX введите команду chmod 777 file_name UNIX.
- На серверах под управлением Windows см. Документацию по программному обеспечению.
Отсоедините шнур питания или шнур Ethernet (если используется линейное питание), чтобы перезагрузить телефоны. Убедитесь, что телефоны могут найти сервер TFTP.Вручную настройте IP-адрес телефона, адрес шлюза и адрес TFTP-сервера; или настройте параметры телефонной сети с сервера протокола динамической конфигурации хоста (DHCP). Рекомендуется не использовать TFTP-сервер в Cisco CallManager, если он у вас есть в вашей текущей системе.
Примечание: Если установка программного обеспечения SIP 3.x или 4.x не удалась, попробуйте сначала преобразовать в образ SIP 2.3, а затем перейти к 3.x. Это обычное явление, когда вы используете особенно старую версию программного обеспечения Cisco 7940/7960 SCCP.Это пример вывода tftp log debug , который показывает, как выглядит сбой:
```
, среда, 06 ноября, 11:58:51 2002: отправка файла OS79XX.TXT в 10.1.1.1
в двоичном режиме
Ср, 06 ноября, 11:58:51 2002: Успешно.
Ср, 06 ноября, 11:58:51 2002: отправка файла P0S30300.bin в 10.1.1.1
в двоичном режиме
Ср, 06 ноября, 11:58:52 2002: сбой (ошибка состояния).
Ср, 06 ноября, 11:59:00 2002: отправка файла P0S30300.bin в 10.1.1.1.
в двоичном режиме
Ср, 6 ноября, 11:59:02 2002: сбой (ошибка состояния).Ср, 06 ноября, 11:59:10 2002: отправка файла P0S30300.bin в 10.1.1.1
в двоичном режиме
Ср, 06 ноября, 11:59:13 2002: сбой (ошибка состояния). 
```

Настройка параметров телефонной сети вручную

Выполните следующие действия, чтобы вручную настроить параметры телефонной сети:

Нажмите кнопки ** # , чтобы разблокировать телефон. (Этот шаг блокирует или разблокирует параметры в зависимости от текущего состояния.)
Нажмите Настройки .
Нажмите стрелку вниз, чтобы выбрать Network Configuration , и нажмите программную клавишу Select . В правом верхнем углу ЖК-дисплея есть значок разблокированного замка.
Используйте кнопку переключения и клавиши со стрелками для изменения любых параметров. При вводе IP-адресов ключ * используется для десятичных знаков.
Нажмите программную клавишу Сохранить , чтобы сохранить изменения.
Примечание: Чтобы заблокировать настройки телефона, нажмите ** # .
Дополнительные сведения см. В разделе «Начало работы с IP-телефоном Cisco SIP».

Настройка параметров телефонной сети через DHCP

Вы также можете настроить параметры телефонной сети с сервера протокола динамической конфигурации хоста (DHCP). Для SIP-телефонов убедитесь, что DHCP-сервер использует опцию 66 для TFTP-сервера. Эти параметры DHCP обычно настраиваются с сервера DHCP:

IP-адрес (опция 50 DHCP)
Маска подсети (вариант 1 DHCP-сервера)
Шлюз IP по умолчанию (вариант 3 DHCP)
Адрес DNS-сервера (вариант DHCP 6)
Сервер TFTP (опция 66 DHCP)
Доменное имя (параметр 15 DHCP-сервера)

Примечание. Сisco CallManager использует Опцию 150 для TFTP-сервера, тогда как SIP-телефоны ожидают Опцию 66 для TFTP-сервера.

Дополнительные сведения см. В разделе «Начало работы с IP-телефоном Cisco SIP».

Образ SCCP 3.x / более ранней версии в образ SIP 6.x / более ранней версии и из образа SCCP 5.x в образ SIP 5.x / 6.x

Это процедура для преобразования образа SCCP 3.x или более ранней версии в желаемый образ SIP 6.x или более ранней версии или для преобразования образа SCCP 5.x в желаемые образы SIP 5.x или 6.x:

Каждый телефон запрашивает файл начальной настройки OS79XX.TXT.
Примечание: Убедитесь, что вы используете точно такое же имя, потому что имена файлов на сервере TFTP и имя образа SIP в OS79XX.TXT чувствительны к регистру.
Каждый телефон загружает двоичный файл прошивки, указанный в файле OS79XX.TXT. После того, как правильный файл BIN загружен, он заменяет программное обеспечение, которое запускает с этим новым образом. Чтобы вернуться к другой версии программного обеспечения, необходимо перезагрузить телефон, чтобы программное обеспечение можно было снова загрузить.
Каждый телефон загружает образ SIP, указанный в файле начальной настройки. В этом случае загружается файл P0S30100.bin.
Каждый телефон загружает файл SIPDefault.cnf. Этот файл содержит основные параметры конфигурации, общие для всех телефонов.
Каждый телефон загружает свою конкретную информацию о конфигурации из файла SIP mac_address .cnf. MAC-адрес необходимо указывать заглавными буквами.

Образ SCCP 3.x / ранее и 5.x в образ SIP 7.x

Это процедура преобразования образа SCCP 3.x или более ранней версии в желаемый образ SIP 7.x или преобразовать образ SCCP 5.x в нужный образ SIP 7.x:

Скопируйте желаемый двоичный образ с Cisco.com в корневой каталог сервера TFTP.
Укажите образ в параметре образа файла конфигурации для протокола, в который вы конвертируете (load_information для SCCP или image_version для SIP).
Удалите все файлы конфигурации протокола, которые не используются для указанного протокола.
Например, для SIP значение SIPDefault.cnf и SIP файлы mac_address .cnf загружаются при перезагрузке телефона. Этот файл содержит параметр image_version, который сообщает телефону, какой образ запускать. Таким образом, если вы попытаетесь загрузить программное обеспечение SIP версии 7.1, SIPDefault.cnf должен содержать image_version: P0S3-07-1-00. Если загруженное изображение отличается от того, которое в настоящее время загружено в телефон, телефон связывается с сервером TFTP для преобразования в новый образ.

Образ SCCP 6.x / более поздней версии и Образ SIP 7.х / позже

Для текущего образа SCCP 6.x или новее и для образа SIP 7.x или новее используйте универсальный загрузчик приложений и выполните следующие действия:

Распакуйте файл software_version .zip в корневой (верхний уровень) каталог TFTP.
Перезагрузите телефон.
Телефон связывается с сервером TFTP и запрашивает его файлы конфигурации. Телефон сравнивает изображение, определенное в OS79XX.TXT и файлах конфигурации протокола, с изображением, сохраненным во флэш-памяти.Если телефон определяет, что образ, определенный в файлах, отличается от образа во флэш-памяти, он загружает определенный образ (который хранится в корневом каталоге на сервере TFTP). После загрузки нового образа телефон запрограммирует его во флэш-память и перезагрузится.

Это образец файла журнала с сервера TFTP, который показывает полную процедуру загрузки:

, понедельник, 11 сентября, 15:24:53 2000: отправка файла OS79XX.TXT на адрес 10.1.1.10
в двоичном режиме
#
Пн 11 сентября 15:24:53 2000: Успешно.
Пн, 11 сентября, 15:24:53 2000: отправка файла P0S30100.bin на адрес 10.1.1.10.
в двоичном режиме
########################################################################## #########################
########################################################################## #########################
########################################################################## #########################
########################################################################## #########################
########################################################################## #########################
########################################################################## #########################
########################################################################## #########################
########################################################################## #########################
########################################################################## ##################
Пн 11 сентября 15:24:55 2000: Успешно.Пн, 11 сентября, 17:15:25 2000: отправка файла OS79XX.TXT в 10.1.1.10
в двоичном режиме
#
Пн 11 сентября 17:15:25 2000: Успешно.
11 сентября, понедельник, 17:15:26 2000: отправка файла «SIPDefault.cnf» на адрес 10.1.1.10.
в двоичном режиме
###
Пн 11 сентября 17:15:26 2000: Успешно.
Пн, 11 сентября, 17:15:26 2000: отправка файла «SIP003094C29C71.cnf» в 10.1.1.10
в двоичном режиме
##
Пн 11 сентября 17:15:26 2000: Успешно.
Пн, 11 сентября, 17:15:26 2000: отправка файла "RINGLIST.DAT" на адрес 10.1.1.10.
в двоичном режиме
#
Пн 11 сентября 17:15:27 2000: Успешно.
Пн, 11 сентября, 17:15:37 2000: Отправка 'ringer2.pcm 'в 10.1.1.10
в двоичном режиме
################
Пн 11 сентября 17:15:37 2000: Успешно.

Следующий пример выходных данных взят из файла журнала TFTP, и он показывает, что не удалось загрузить образ SIP на IP-телефон. Чтобы решить эту проблему, попробуйте сначала преобразовать загрузку SIP-телефона в 2.3, а затем перейти на 3.x или 4.x.

, среда, 06 ноября, 11:58:51 2002: отправка файла OS79XX.TXT в 10.1.1.1
в двоичном режиме
Ср, 06 ноября, 11:58:51 2002: Успешно.
Ср, 6 ноября, 11:58:51 2002 г .: Отправка «P0S30300.bin 'в 10.1.1.1
в двоичном режиме
Ср, 06 ноября, 11:58:52 2002: сбой (ошибка состояния).
Ср, 06 ноября, 11:59:00 2002: отправка файла P0S30300.bin в 10.1.1.1.
в двоичном режиме
Ср, 6 ноября, 11:59:02 2002: сбой (ошибка состояния).
Ср, 06 ноября, 11:59:10 2002: отправка файла P0S30300.bin в 10.1.1.1
в двоичном режиме
Ср, 06 ноября, 11:59:13 2002: сбой (ошибка состояния).

Для возврата SIP-телефона обратно к телефону Cisco CallManager Skinny отредактируйте файл OS79XX.TXT, чтобы изменить ссылку имени файла обратно на идентификатор загрузки Cisco CallManager.В следующий раз, когда телефон подключается к TFTP-серверу, он загружает файл загрузки CallManager.

Перейдите на страницу загрузки программного обеспечения Cisco7940 / 7960 SCCP в разделе Загрузки Cisco (только для зарегистрированных клиентов): щелкните Voice Software , а затем щелкните SIP IP Phone 7940/7960 . Загрузите последнюю версию программного обеспечения 7940/7960. Если вы выполняете преобразование из более ранней версии программного обеспечения 7940/7960 SIP (3.x или более ранней), попробуйте выполнить преобразование до последней версии SCCP 4.x перед преобразованием в цепочку SCCP 5.x. После преобразования в цепочку 5.x вы не сможете вернуться к более раннему образу. Дополнительные сведения о различиях между версиями см. В Примечаниях к выпуску для IP-телефона Cisco SIP 7940/7960 версии 5.0.

Образы SIP 4.x / более ранние в образы SCCP 5.x / более ранние

Если у вас текущий образ SIP 4.x или более ранней версии, выполните следующие действия, чтобы преобразовать в нужные образы SCCP версии 5.x или более ранней:

Запустите исполняемый файл, чтобы установить программное обеспечение SCCP.Убедитесь, что новые файлы находятся в вашей основной папке TFTP.
Измените файл OS79XX.TXT, чтобы он отражал новое имя файла.
Например, если вы загружаете версию 5.0 (1.1), ваш BIN-файл будет P00305000101.bin. Измените текст в файле OS79XX.TXT, чтобы отразить это имя файла без расширения .bin.
Сбросьте настройки каждого телефона.
Примечание: Перед перезагрузкой телефонов убедитесь, что все необходимые файлы Cisco CallManager находятся на сервере TFTP.

Образы SIP 4.x / более ранние в образы SCCP 6.x / более поздние

Если у вас текущие образы SIP версии 4.x или более ранней, выполните следующие действия, чтобы преобразовать в нужные образы SCCP версии 6.x или новее:

Выполните следующие действия, чтобы сначала преобразовать в образ 6.3:
1. Скопируйте желаемый двоичный образ с Cisco.com в корневой каталог сервера TFTP.
2. Откройте OS79XX.TXT с помощью текстового редактора и отредактируйте файл, включив в него желаемое изображение.
3. Укажите желаемый образ в файлах конфигурации протокола.
4. Сбросьте настройки каждого телефона.
  Телефон связывается с сервером TFTP и запрашивает его файлы конфигурации. Телефон сравнивает изображение, заданное в файле конфигурации, с изображением, которое он хранит во флэш-памяти. Если телефон определяет, что изображение в файле конфигурации отличается от изображения во флэш-памяти, он загружает изображение в файл конфигурации (который хранится в корневом каталоге на сервере TFTP).После загрузки нового образа телефон запрограммирует его во флэш-память и перезагрузится.
Выполните следующие действия, чтобы преобразовать в желаемое изображение:
1. Распакуйте файл software_version .zip в корневой (верхний уровень) каталог TFTP.
2. Перезагрузите телефон.
  Телефон связывается с сервером TFTP и запрашивает его файлы конфигурации. Телефон сравнивает изображение, определенное в OS79XX.TXT и файлы конфигурации протокола к изображению, которое хранится во флэш-памяти. Если телефон определяет, что образ, определенный в файлах, отличается от образа во флэш-памяти, он загружает определенный образ (который хранится в корневом каталоге на сервере TFTP). После загрузки нового образа телефон запрограммирует его во флэш-память и перезагрузится.

Образы SIP 5.x, 6.x в образы SCCP 5.x / более поздние

IP-телефон Cisco SIP 7940/7960, выпуск 5.0 функционально эквивалентен Cisco SIP IP Phone 7940/7960 Release 4.4 во всех отношениях, за исключением цифровой подписи. Добавление подписанных двоичных файлов предотвращает понижение версии 5.0 IP-телефона Cisco SIP 7940/7960 до более ранней версии.

Если ваш текущий образ SIP — 5.x или 6.x, выполните следующие действия, чтобы преобразовать в требуемые образы SCCP 5.x или более поздней версии:

Загрузите последнюю загрузку SIP для вашего 7940/7960 и разархивируйте / tar в каталог tftp.
Загрузите последнюю загрузку SCCP для 7940/7960 и разархивируйте / tar в каталог tftp.
Найдите файл с именем gkdefault.txt в загрузке SIP и откройте его в текстовом редакторе (например, в Блокноте).
Откройте gkdefault.txt и перейдите к строке кода обновления: 3,0×601,0x0400,0x0100,0.0.0.0,69,0x060412a, CP7940080001SIP060412A.sbin.
Ссылка на образ SIP.Измените gkdefault.txt на имя файла SCCP, который вы хотите загрузить. Вам необходимо заменить 060412a на 051117a и CP7940080001SIP060412A.sbin на CP7940080001SCCP051117A.sbin в зависимости от того, какую версию образа SCCP вы загрузили.
Например, если вы загрузили cmterm-7940-7960-sccp.8-0-4.zip, он может выглядеть так: код обновления: 3,0×601,0x0400,0x0100,0.0.0.0,69,0x051117a, CP7940080001SCCP051117A. сбин
После сохранения изменений запустите cfgfmt -tsip_ptag.dat gkdefault.txt gkdefault.cfg . Файлы cfgfmt.exe и sip_ptag.dat поставляются с загрузкой SIP.
Убедитесь, что на телефоне настроен IP-адрес tftp-сервера и они могут обмениваться данными.
Теперь телефон должен загрузить файл gkdefault.cfg и файл SCCP, на который вы ссылались в gkdefault.txt .

Образы SIP 7.x / позже в образы SCCP 5.x / более поздние

Если ваш текущий образ SIP — 7.x или новее, выполните следующие действия, чтобы преобразовать в нужные образы SCCP версии 5.x или новее:

В файле конфигурации для протокола, который в настоящее время работает на телефоне, измените изображение в параметре load_information (SCCP) или параметре image_version (SIP), чтобы представить протокол, который вы хотите запустить.

Например, если изображение на телефоне — это SIP, а желаемое изображение — SCCP, измените параметр image_version, чтобы он отражал образ SCCP (P00306000200).

Обратитесь к этим документам для получения дополнительной информации о том, как настроить DHCP, TFTP или Cisco CallManager:

Преобразование телефонов SCCP в SIP и обратное в Cisco Unified Communication Manager 5.x и 6.x

Выполните эти шаги, чтобы преобразовать IP-телефоны SCCP в SIP:

Перейдите в Cisco CallManager Administration и выберите Bulk Administration > Phones > Migrate Phones > SCCP to SIP .
Щелкните Найти после выбора / ввода соответствующих критериев поиска, чтобы перечислить телефоны, которые необходимо перенести.
Щелкните Далее и выберите шаблон телефона из раскрывающегося списка.
Введите описание задания в области «Информация о задании».
Щелкните Запустить немедленно для немедленного переноса телефонных записей или щелкните Запустить позже , чтобы выполнить миграцию позже.
Щелкните Отправить , чтобы создать задание для переноса телефонных записей.
Примечание: После того, как вы отправите задание на миграцию телефонов с SCCP на SIP, убедитесь, что вы сбросили эти телефоны. Для сброса телефонов выберите Bulk Administration > Phones > Reset / Restart Phones > Query .
При отправке задания миграции выберите Bulk Administration > Job Scheduler , чтобы запланировать и / или активировать это задание.
Если он остается в состоянии ожидания, вам может потребоваться активировать Bulk Provisioning Service на странице Serviceability > Tools > Service Activation page. Дополнительные сведения см. В разделе «Активация службы массовой подготовки».
Перейдите в Администрирование Cisco CallManager, выберите System > Enterprise Parameters и измените телефонный протокол автоматической регистрации на SIP (по умолчанию используется SCCP).Затем перезапустите службу Cisco CallManager. Дополнительные сведения см. В разделе «Авторегистрация с поддержкой нескольких протоколов».
Примечание: Чтобы вернуться к SCCP, вам необходимо удалить SIP-телефон, установить для телефонного протокола автоматической регистрации значение SCCP и затем позволить телефону повторно зарегистрироваться как SCCP.

Доступность TFTP и влияние на сеть

Если вы хотите обновить только один телефон в производственной сети, обязательно используйте другой TFTP-сервер, чем тот, который указан на DHCP-сервере.Если вы используете указанный сервер TFTP, вы потенциально можете заставить все телефоны в сети перейти на новую прошивку. Если вы пытаетесь преобразовать только один телефон, используйте другой сервер TFTP и введите IP-адрес сервера вручную в настройках телефона (Настройки > Конфигурация сети> Альтернативный сервер TFTP [Изменить на Да]> Сервер TFTP [Изменить Айпи адрес]). Всегда проявляйте особую осторожность при обновлении телефонов, поскольку изменения в этих конфигурациях могут вывести из строя всю телефонную систему, если они не будут реализованы должным образом.

Получить микропрограмму SCCP

Файлы образа SCCP в разделе загрузок Cisco (только для зарегистрированных клиентов) содержатся в исполняемом файле. После выполнения этого файла запускается программа установки, которая определяет наличие Cisco Call Manager и его корневую папку TFTP. Как только это местоположение определено, установщик копирует все необходимые файлы в корневую папку TFTP. После этой установки все еще необходимо внести соответствующие изменения в файл OS79XX.TXT, как упоминалось ранее в этом документе.

Ошибка TFTP W210: буфер переполнен. Ошибка

В более старых версиях программного обеспечения SIP (версии 2.x) есть ошибка, из-за которой телефон не может загрузить файл SIPDefault.cnf, если он больше определенного размера. Телефон может отображать ошибку TFTP W210: буфер заполнен. Чтобы решить эту проблему, убедитесь, что эти файлы имеют указанные характеристики:

OS79XX.TXT должен содержать только имя файла микропрограммы без расширения .bin (например, P0S30203 для P0S30203.бункер).
SIPDefault.cnf должен содержать только версия_образа: имя_файла , где имя_файла — это имя файла микропрограммы без расширения .bin.

Это позволяет Cisco 7940/7960 загружать более новое программное обеспечение. После преобразования вы можете заменить SIPDefault.cnf своей конфигурационной информацией, так как телефон может загрузить этот более крупный файл.

SIP-телефон не принимает нагрузку SCCP

Для программного обеспечения SIP версии 2.1 и ранее телефон не принимает загрузку SCCP, имя файла которой превышает восемь символов. Есть два варианта решения этой проблемы:

Обновите программное обеспечение SIP до более новой версии, затем вернитесь к программному обеспечению SCCP.
Переименуйте файл загрузки SCCP, чтобы он соответствовал стандартному соглашению об именах 8.3 DOS (максимальная длина имени файла составляет xxxxxxxx.yyy ).

Ошибка «Недопустимое приложение протокола»

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

ZIP-пакет не был распакован в корневой каталог TFTP.
Файлы были вручную скопированы на сервер TFTP (пакет ZIP не использовался).
Универсальный загрузчик приложений не смог загрузить новый образ приложения во флэш-память (ошибка аутентификации образа, несуществующий образ, ошибки TFTP и т. Д.).
Файл OS79XX.TXT должен содержать только имя файла, который вы пытаетесь загрузить, без расширения.расширение bin. Например, если вы пытаетесь загрузить программное обеспечение SIP версии 2.3, оно должно содержать только строку P0S30203. Если вы попытаетесь загрузить версии 3.0 и новее, имя файла должно быть в формате P0S3-xx-y-zz. Например, если вы пытаетесь загрузить программное обеспечение SIP версии 7.4, оно должно содержать строку P0S3-07-4-00.
Файлы SIPDefault.cnf и SIP mac_address .cnf загружаются при перезагрузке телефона. Эти файлы содержат параметр image_version, который сообщает телефону, какой образ он должен запустить.Таким образом, если вы попытаетесь загрузить программное обеспечение SIP версии 7.4, файлы SIPDefault.cnf и SIP mac_address .cnf должны содержать image_version: P0S3-07-4-00.

Ошибка «Ошибка аутентификации изображения»

Это сообщение об ошибке означает, что новый образ приложения, который будет загружен, не прошел проверку подписи.

Ошибка «Нет нагрузки»

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

IP-телефоны переходят в неподготовленное состояние

Обычная причина перехода телефона в состояние Unprovisioned — отсутствие правильного синтаксиса в файле OS79XX.TXT. Файл OS79XX.TXT должен содержать только имя файла, который вы пытаетесь загрузить, без расширения .bin.

Если вы переходите с SCCP на SIP, а версия, которую вы пытаетесь загрузить, является программным обеспечением SIP 2.3 или более ранней, OS79XX.TXT должен быть в формате POS3 xxyy . Например, если версия программного обеспечения SIP — 2.2, файл должен содержать POS30202.

Если вы конвертируете из SCCP в SIP и пытаетесь загрузить версию программного обеспечения SIP 3.0 или новее, OS79XX.TXT должен иметь формат POS3- xx — y — zz . Например, если версия программного обеспечения SIP — 7.4, файл должен содержать POS3-07-4-00.

При преобразовании SIP в SCCP файл OS79XX.TXT должен быть в формате P003 aabbccdd . Например, если версия программного обеспечения SCCP — 7.2 (3), файл должен содержать P00307020300.

Советы по устранению неполадок

Чтобы решить проблемы с аутентификацией изображения и ZIP-файлом, убедитесь, что изображение извлечено из ZIP-файла (не копируйте изображение на TFTP-сервер вручную).
Для решения проблем с изображением приложения добавьте желаемый образ в файлы конфигурации и перезагрузите телефон, чтобы загрузить образ приложения.
Для устранения неудачной попытки преобразования запустите перехват сниффера.
Чтобы помочь с любыми дальнейшими ошибками или неудачными попытками преобразования, порт RS-232 на телефоне обеспечивает доступ к консоли для поиска и устранения неисправностей. См. Раздел «Функции устранения неполадок» для получения дополнительной информации о доступе к консоли.

Примечание: Наиболее распространенные предостережения в этой процедуре преобразования перечислены в этом документе.Большинство проблем возникает из-за использования более старого программного обеспечения или из-за отсутствия правильного синтаксиса в файле OS79XX.TXT. Прежде чем открывать обращение в службу технической поддержки, попробуйте перейти на последние версии программного обеспечения телефона, поскольку это решает многие проблемы, относящиеся к телефонам серии Cisco 7940/7960.

Схема безопасного снижения нагрузки и распределения для защиты SIP-сервера

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

1. Введение

Огромный рост VoIP играет активную роль в бизнес-приложениях на базе IP, которые предоставляют многочисленные мультимедийные услуги в реальном времени.Из-за более низкой стоимости и большей гибкости клиенты используют различные услуги VoIP, такие как голосовые вызовы, сообщения экземпляра и видеоконференции. В этих услугах VoIP использует SIP в качестве протокола сигнализации для создания, управления и завершения мультимедийного сеанса. Транспортный протокол реального времени (RTP) передает медиапотоки через протокол пользовательских дейтаграмм (UDP) [1]. На рисунке 1 показан пример мультимедийного разговора на основе SIP. Транзакция SIP выполняется путем передачи текстовых сообщений запроса и ответа.Транзакция SIP состоит из двух фаз, а именно, фазы установления и завершения сеанса. На этапе установления сеанса за сообщением INVITE, следует соответствующее сообщение ACK , тогда как на этапе завершения сеанса за сообщением BYE следует соответствующее ответное сообщение ACK . Сервер SIP играет две жизненно важные роли; один из них — использование сервера местоположения для определения местоположения вызываемого абонента, а другой отвечает за маршрутизацию сообщений.Сообщения с запросами SIP проходят через несколько прокси-серверов, которые находятся либо в одном, либо в разных доменах VoIP. Точно так же связанные ответы пересылаются на одни и те же прокси-серверы в обратном порядке.

В IP-телефонии на основе SIP возникает проблема узких мест, потому что сигнальная часть обрабатывает огромное количество сообщений, а мультимедийная часть обрабатывает медиапотоки. Следовательно, и сигнализация, и медиа-часть напрямую влияют на масштабируемость сети VoIP.Кроме того, в обзоре литературы указаны причины перегрузки СИП [2–6]. Во-первых, чтобы обеспечить надежную передачу, запросы повторно передаются по UDP в течение определенного периода времени [2, 3]. Затем сообщения SIP передаются между клиентами через несколько прокси-серверов и соседние узлы в той же или другой сети. Впоследствии сообщения SIP используются как сообщения сеанса в реальном времени; следовательно, они очень чувствительны [4]. Наконец, поскольку голосовые вызовы передаются через незащищенный Интернет, злоумышленник может легко внедрить атакующие пакеты как обычные пакеты [5].В результате сервер увеличивает частоту неудачных вызовов, снижает пропускную способность, увеличивает задержку установления вызова и большую часть времени тратит на отклонение запроса [6].
Основной целью предлагаемой работы является устранение состояния перегрузки путем обнаружения и устранения нежелательных сообщений. В работе также рассматривается алгоритм распределения нагрузки, обеспечивающий равномерное распределение нагрузки между серверами. Эта работа также максимизирует использование ЦП, пропускную способность, сводя к минимуму время отклика и время выполнения сервера.Для достижения этих целей вводятся обработчик и алгоритм LSTT, которые обеспечивают равномерное распределение нагрузки путем выбора подходящего сервера на основе наименьшего времени завершения сеанса.
2. Сопутствующие работы
Ключевой вопрос при поддержке сквозной защиты медиапотока заключается в том, какой уровень должен обеспечивать безопасность мультимедиа, сетевой уровень или какой-либо более высокий уровень. В настоящее время наиболее доступными альтернативами для передачи данных на основе TCP являются безопасность протокола Интернета (IPSec) [7] (сетевой уровень) или безопасность транспортного уровня (TLS) (транспортный / прикладной уровень) [8].Стандартный протокол аутентификации SIP — это дайджест-аутентификация HTTP, который использует доверенный общий секретный ключ для выполнения криптографической хеш-функции. Экспериментальные результаты Salsano et al. [9] продемонстрировали, что даже дайджест-аутентификация HTTP вызывает значительные накладные расходы на протокол SIP. В трафике UDP в реальном времени основными альтернативами являются безопасный транспортный протокол реального времени (SRTP) [10] (транспорт / приложение) и IPSec. Chen et al. [11] разработал протокол обмена ключами, который защищает медиапоток и смягчает влияние спама по IP-телефонии (SPIT) с использованием взаимной аутентификации.Юн и др. [12] установили, что некоторые схемы аутентификации SIP небезопасны против атак, таких как атаки с подстановкой пароля в автономном режиме, атаки Деннинга-Сакко и атаки с использованием украденного верификатора.
В целом алгоритмы балансировки нагрузки подразделяются на статические и динамические. В статических методах нагрузка назначается во время компиляции в соответствии с предварительным решением знаний. Основным недостатком этих методов является то, что решение о балансировке нагрузки известно заранее, и, следовательно, статические методы менее эффективны, чем динамические алгоритмы.И наоборот, нагрузка распределяется динамически на основе динамического алгоритма, реализованного на сервере, и обеспечивает хорошую производительность. Многочисленные исследовательские работы проводятся для динамического управления перегрузкой SIP с учетом различных параметров, таких как обратная связь [4, 13–17], отклонение вызова [18–21], информация о сеансе [22, 23], время отклика [24, 25]. , и приоритет [26, 27].
В схемах управления перегрузкой на основе обратной связи [4, 13–17] перегруженный сервер вычисляет ограничения на свою сгенерированную нагрузку в соответствии с текущей нагрузкой и распределяет такие ограничения на свое непосредственное окружение, которое помещается перед сервером перегрузки с помощью механизма обратной связи. .Основываясь на этом ограничении, соседний сервер решает, должен ли трафик перенаправляться на сервер перегрузки или нет. Ограничение этих работ состоит в том, что дополнительные накладные расходы добавляются к серверу перегрузки, когда ограничения нагрузки вычисляются и распределяются. В схемах отклонения вызовов [18–21] перегруженный сервер использует алгоритм управления локальной перегрузкой для генерации ответов об ошибках (503 Service Unavailable) в условиях большой нагрузки. В зависимости от скорости реакции на ошибку входящий трафик ограничивается.Хотя эти алгоритмы приводят к лучшему решению, в реальном времени оно ограничивается поставщиком услуг. Кроме того, большое количество отказов может привести к сбоям в сети SIP. Следовательно, этот подход может эффективно применяться только на слегка перегруженных серверах.
Метод с учетом сеанса [22, 23] содержит три алгоритма, а именно: наименьшее количество вызовов, наименьшая транзакция и взвешенная наименьшая транзакция. В этом методе нагрузка распределяется по наименьшему количеству активных вызовов на сервере.Это неосуществимое решение, потому что каждый вызов занимает разное время. Следующий вариант — алгоритм наименьшего количества транзакций, который выбирает сервер на основе наименьшего количества активных транзакций, которые сервер в настоящее время обрабатывает. Основным ограничением этого алгоритма является то, что запрос INVITE занимает больше времени, чем запрос BYE . Третий алгоритм — это транзакция с наименьшим взвешиванием, которая присваивает вес 0,75 для BYE и 1 для INVITE .В этом алгоритме каждый сервер должен поддерживать состояние сеанса и транзакции для отдельного пользователя. Метод назначения веса полезен только в том случае, если сервер в кластере не имеет такой же емкости.
В [24, 25] среднее время ответа каждого сервера поддерживается в отдельном окне, и нагрузка распределяется на сервер, который имеет наименьшее время ответа. В этом исследовании важно учитывать общее время отклика на этапе установления сеанса. Эта схема становится неэффективной при увеличении задержки в очереди и скорости потери пакетов.Более того, SIP передает максимум 8 повторных передач для каждого исходного запроса. Следовательно, общее время отклика при установлении сеанса будет увеличено. Кроме того, сигнальные сообщения прерываются, чтобы повысить производительность сети SIP во время медиа-диалога [28–30]. Например, сообщения сигнализации INVITE , 183 Session in progress , UPDATE , 200 OK, и ACK прерываются во время медиа-диалога для повышения безопасности SIP, как показано на рисунке 2.

В результате вычисление времени отклика между INVITE и ACK не является возможным решением. Существующий планировщик на основе веса [22, 23] приводит к зависанию, так как он не предоставляет способ для запроса с большим весом, и поэтому повторная передача происходит в течение определенного периода. Таким образом, к балансировщику нагрузки добавляется дополнительная проблема с перегрузкой. В нескольких исследовательских работах [26, 27] предложен метод, который снижает скорость повторной передачи вместо уменьшения исходной скорости передачи.Это решение предлагает меньшее количество блокировок вызовов и больший доход для операторов связи. Производительность SIP-сервера увеличивается в очереди приоритетов [26], в которой запросов INVITE и имеют низкий приоритет, а всем остальным запросам — высокий приоритет. Авторы в [27] используют сообщение об ошибке (503 Service Unavailable) , которое останавливает запрос на повторную передачу. Но этот метод создает дополнительную проблему для сервера. Исследователи уделяют больше внимания угрозам безопасности, создаваемым балансировщиком нагрузки [31–33].Kim et al. [31] исследовали производительность протокола SSL для обеспечения безопасного обслуживания на кластерном сервере приложений и предложили метод внутренней пересылки для повышения производительности сервера за счет лучшей балансировки нагрузки. Авторы [32] реализовали схему обнаружения распределенного отказа в обслуживании (DDoS) в балансировщике нагрузки. Здесь диспетчерский модуль сервера Kamailio действует как балансировщик нагрузки. Эта схема обнаруживает низкоскоростные и многоатрибутные DDoS-атаки. Однако практических результатов недостаточно.Авторы в [33] реализовали уровень аутентификации для архитектуры балансировки нагрузки. Таким образом, только аутентифицированные пользователи могут отправлять задания, и внутри облачной платформы не происходит перегрузки, а балансировщик нагрузки оплачивает минимальные потери ресурсов. В предыдущей работе [34] Honeywall является основным вкладом в снижение нагрузки на балансировщик нагрузки. Сервер SIP настроен для принятия решения о выборе сервера с наименьшим количеством активных вызовов и методом BYE_ACK. В этой работе скорость, задержка и крайний срок поступления сообщений SIP используются для вычисления нагрузки в очереди.
3. Предлагаемая двухуровневая модель
Во многих случаях только балансировщик нагрузки тратит больше времени на обработку злонамеренных пакетов, повторной передачи и сигнального трафика, и в последнем случае эти сообщения могут быть отклонены [5, 35]. Следовательно, время обработки вместе с задержкой распределения нагрузки увеличивается. Чтобы преодолеть эти проблемы, в этой работе разработан обработчик, который отбрасывает вредоносный и нежелательный трафик перед обслуживанием балансировщика нагрузки. Работа обработчика не зависит от работы балансировщика нагрузки, как показано на рисунке 3.Обработчик — это первый объект, реализованный до балансировщика нагрузки, который принимает весь входящий и исходящий SIP-трафик. Обработчик обеспечивает обнаружение аномального трафика, предотвращение и снижение нагрузки. В результате уменьшается рабочая задача балансировщика нагрузки и увеличивается доступность ресурсов сервера.

Алгоритм LSTT второго уровня определяет три процесса, а именно: распределение, решение и выбор. Главный аспект алгоритма LSTT состоит в том, что он решает выбрать подходящий сервер для новых и существующих SIP-сообщений.На основе идентификатора вызова и последовательности вызовов (Cseq) в заголовке сообщения процесс распределения исследует, является ли входящее сообщение новым или существующим. Если входящее сообщение является существующим, то идентифицируется предыдущий соответствующий сервер обработки запросов, и нагрузка может быть распределена. В противном случае к новому сообщению применяется процесс принятия решения, который выбирает подходящий сервер. Здесь алгоритм LSTT динамически вычисляет время завершения сеанса, измеряя временную метку между BYE и его соответствующим ACK .Затем процесс выбора выбирает подходящий сервер с наименьшим временем завершения сеанса в окне истории. Каждый сервер поддерживает точное состояние, и балансировщик нагрузки периодически обновляется. В это время каждый сервер обновит время задержки сообщения и совокупное время завершения сеанса в заранее определенном временном интервале.
3.1. Handler
SIP имеет множество управляющих сообщений с открытым выбором, и его можно легко смонтировать с помощью генератора трафика SIP. В SIP только несколько сообщений (REGISTER, INVITE и BYE) и его поля сообщений, такие как URI и Call-ID , защищены.Все другие сигнальные сообщения, такие как 100 Trying , 180 Ringing , 200 OK и ACK , а также поля сообщений, такие как From , To и SDP, не защищены [36]. Следовательно, трафик сигнализации увеличивается с 20 до 40% [5, 36–38] в сети VoIP. Этот сигнальный трафик увеличивает время обработки балансировщиком нагрузки и, таким образом, увеличивается коэффициент сброса вызовов на стороне жертвы. Поэтому в данной работе предлагается эффективная схема обнаружения и предотвращения сигнального трафика.Сигнальный трафик и его изменения вычисляются по тому, где — сигнальный трафик-го пользователя и увеличивается скорость сигнального трафика в периоде.
Обработчик развертывается на граничном маршрутизаторе невинного хоста и проверяет управляющие сообщения SIP, которые входят и уходят через граничный маршрутизатор. Обработчик работает на трех этапах, а именно: скорость вызова, управление и сброс. На этапе скорости вызова используются модифицированные хеш-таблицы для двух счетчиков (установление сеанса и завершение сеанса), как показано на рисунке 4.Каждое SIP-сообщение ( INVITE — ACK и BYE — ACK ) хешируется и записывается в базу данных обработчика. Для любого действующего сеанса SIP существует уникальное взаимно-однозначное сопоставление между INVITE-ACK и BYE-ACK . Эти два счетчика ясно показывают ненормальное трехстороннее рукопожатие.

Изначально фильтр Блума был разработан Блумом [39] и модифицирован для защиты от атак флуда [40, 41]. Фильтр Блума имеет вектор битов и установлен в 0 в начальном состоянии.Пусть элемент; позиции битов в устанавливаются равными 1. Если любой из битов равен 0, то. Исходный фильтр Блума не может обрабатывать парные сообщения трехстороннего рукопожатия. Поэтому 0 и 1 заменяются счетными целыми числами в фильтре Блума. Для каждого входящего сообщения INVITE и BYE обработчик увеличивает соответствующий счетчик на 1 и уменьшает на 1 для пары 200 OK и ACK . Каждый спаренный счетчик INVITE-ACK и BYE-ACK остается равным нулю, а остальные битовые позиции в счетчике сохраняют ненулевое значение.Положение бита переполнения в счетчике показывает нежелательный трафик, который намеревается повлиять на SIP-сервер. Обработчик уведомляет затронутую позицию счетчиков с помощью где — количество сообщений сигнализации ‘ (INVITE, BYE) , скорость при нормальном трафике, является средним значением сообщения сигнализации и является стандартным отклонением сообщений сигнализации.
Пороговое значение может быть установлено в соответствии с количеством пользователей и сгенерированным ими сигнальным трафиком. В этой работе максимальное значение должно быть установлено на максимальное значение 8000 вызовов в секунду (cps).Следующим шагом является идентификация нарушенных SIP-сообщений и их устранение, чтобы обеспечить безопасную среду. В частности, каждый цикл обнаружения, который отклоняется от времени между прибытиями сообщения, считается нежелательным сообщением. Для каждого вызова сообщения сигнализации возникают с минимальным временем приема-передачи, как указано в
. Во-первых, наблюдаются различные типы трафика сигнализации, которые содержат различные формы сообщений SIP от законных пользователей. Затем распределение временных интервалов между первым и предыдущим сообщениями одного и того же пользователя характеризуется, как показано на рисунке 5.

Сигнальный трафик каждого сообщения одного и того же типа идентифицируется по тому, где — это наблюдение за сообщением сигнализации типа и где — наблюдение за сообщением сигнализации типа.
Например, сигнальный трафик ( REGISTER , INVITE, и BYE ) и неправильно сформированные пакеты (поддельный BYE, поддельный BUSY, поддельный BYE отбрасывание) идентифицируются по тому, где находится первый пакет INVITE в момент времени и это следующий пакет INVITE того же пользователя.
Затем вычисляется среднее время между прибытием каждого сообщения SIP по формуле где — количество сообщений из-го наблюдения.
Дисперсия времени между прибытиями сообщений SIP вычисляется по
Наконец, этап контроля сравнивает нарушенные сообщения с пороговым значением и удаляет его по правилу отбрасывания. Таким образом, в балансировщик нагрузки передаются только контролируемые и необходимые запросы, а все остальные запросы исключаются. Наконец, в нашу архитектуру добавлен второй этап, называемый балансировщиком нагрузки LSTT.
3.2. Алгоритм LSTT для распределения нагрузки
Основная цель архитектуры второго уровня состоит в том, чтобы ни один из серверов не находился в простаивающем и сильно загруженном состоянии. Второй уровень измеряет наименьшее время завершения сеанса, которое представляет собой время приема-передачи (RTT) между BYE и ACK , как показано на рисунке 6.

В этой работе используется балансировщик нагрузки на основе организации очереди M / M / 1. модель, которая состоит из бесконечного числа клиентов, в которой каждый сервер поддерживает очередь с пуассоновской скоростью поступления и временем обслуживания, которые экспоненциально распределены со средним значением.Чтобы определить статус сервера, считается, что это количество клиентов, находящихся в настоящее время в системе, которые будут следовать цепочке Маркова с состояниями. Когда приходит клиент, состояние сервера равно 0 или 1, и говорят, что он находится в состоянии ожидания или BUSY соответственно. Данный случайный процесс представляет собой процесс рождения-смерти, и, следовательно, коэффициенты равны
Позвольте быть средним числом загрузок или загрузок на сервере. Если, SIP-сервер сильно загружен; в противном случае сервер слегка загружен.Распределение нагрузки сигнализации для различных типов вызовов может быть охарактеризовано эмпирическим измерением, как указано в
Let будет набором сообщений, используемых для завершения сеанса. Предполагается, что каждый вызов является вероятностной моделью, и пусть будет вероятностью обработки для типов вызовов, где. Вероятность средней скорости прибытия для типов вызовов определяется как: где — средняя скорость прибытия th сообщений для типов вызовов, — средняя скорость прибытия th сообщений для типов вызовов и — вероятность th и th сообщения для типов вызовов. .
Использование сервера для вызовов вычисляется по
Вероятность того, что сообщения попадут в очередь для обслуживания, равна вероятности того, что все серверы ЗАНЯТЫ . Таким образом, среднее значение для каждого сообщения в наборе вычисляется как
Общее время завершения сеанса для завершения вызова может быть определено как добавление времени ввода сообщения и времени ожидания, которое умножается на время обслуживания. Время завершения сеанса () вычисляется как среднее время обслуживания.
Распределенные сообщения ожидают в очереди в течение определенного периода времени перед обработкой, поэтому это время ожидания влияет на планировщик, основанный на времени ответа. Предлагаемая работа сокращает время ожидания сообщения; таким образом, среднее время отклика сводится к минимуму.
3.2.1. Минимизация среднего времени отклика
На рисунке 7 показан балансировщик нагрузки, который принимает непрерывный поток сообщений для обработки в наборе сообщений как где = 1, 2 и 3.

Эти сообщения требуют времени обработки, которое варьируется. на несколько порядков (размер, стоимость и т. д.). На рисунке 7 клиенты и созданные ими сообщения закрашены разными цветами. Вызов client1 завершается после обслуживания сообщений INVITE и . Завершение вызова зависит от стоимости сообщения, что означает, что сообщение INVITE требует больше времени для завершения вызова, чем сообщение BYE [23]. Следовательно, любой алгоритм планирования на основе времени отклика должен учитывать задержку, которая определяет эффективность алгоритма. Предполагается, что сервер имеет емкость, и сумма размеров сообщения в наборе должна быть меньше или равна.Используемые параметры показывают обозначения, используемые в этой работе.
Известно, что дисциплина обслуживания на каждом сервере — это FIFO, в котором время планирования и передачи незначительно. Поступающее SIP-сообщение проводит в системе определенное время, которое обозначается как время ожидания и вычисляется как Взвешенное общее время ответа сообщения указано в Весах времени ожидания есть другой индекс нагрузки, такой как
Чтобы минимизировать время ожидания для каждого сообщения в наборе сообщений учитывается фактор задержки с известными факторами времени прибытия и крайний срок каждого сообщения SIP.Например, сообщение INVITE ожидает до мс, а соответствующее ему ответное сообщение ожидает до [1]. Таким образом, предлагаемая система измеряет, как долго сообщение задерживается по сравнению с его крайним сроком. Время задержки измеряется согласно времени ожидания сообщения в очереди. Таким образом, минимизация взвешенного среднего времени ожидания эквивалентна минимизации взвешенного общего времени ожидания. Чтобы минимизировать общее время ожидания, существующая работа требует максимального времени потока и максимального растяжения (задержки) [42, 43].Эти метрики желательны для приложения реального времени, но метрики максимального потока увеличивают последовательность скорости поступления сообщений, что приводит к зависанию. Максимальное время задержки вместо максимального потока применяется, чтобы избежать голодания, которое рассчитывается с помощью where.
Уравнение (17) переписывается как Время задержки сообщения — это время его ожидания, деленное на время его обработки, как указано в
Чтобы уменьшить среднее время ответа, процесс принятия решения назначает оптимальное время задержки каждому сообщению и сортирует сообщение. последовательности в соответствии с неубывающим временем задержки.Затем балансировщик нагрузки выбирает сообщение SIP с максимальной задержкой и отправляет его на соответствующий сервер. Алгоритм LSTT вычисляет среднее время завершения сеанса для каждого сервера, где — это время завершения сеанса сервера, это совокупное время завершения сервера,, где, Сеанс — это время завершения сеанса, и это время завершения нового сеанса, полученного сервером.
Наконец, процесс выбора идентифицирует сервер в окне истории с помощью (21).Можно отметить, что сообщения одинакового размера с одинаковым временем задержки, которые выполняются в режиме FIFO. Балансировщик нагрузки распределяет сообщения в соответствии с наименьшими затратами времени завершения сеанса между серверами.
4. Экспериментальная установка
На рисунке 8 изображен экспериментальный стенд, который состоит из различных экспериментальных компонентов, перечисленных в таблице 1.
Экспериментальные компоненты Функции
Клиент генерирует сигнальный трафик SIP
OPenSER Прокси-сервер обрабатывает тысячи вызовов VoIP в секунду
NMON Предоставляет информацию о процессоре, памяти и сети
Wireshark Анализатор сетевых протоколов

4.1. Генерация вызовов
Для создания огромного объема трафика вызовов используется как инструмент с открытым исходным кодом, кодированный с помощью XML, для реализации. Когда новый вызов генерируется сообщением INVITE , прокси-сервер SIP пересылает его соответствующему клиенту, и будет получен соответствующий ответ. После успешного инициирования вызова происходит обмен медиаданными; затем завершение сеанса происходит с помощью стандартного сообщения BYE и соответствующего ему сообщения ACK .был сконфигурирован таким образом, что нагрузка генерируется непрерывно без перебоев. Максимальная емкость прокси-сервера и его производительность были измерены в условиях большой нагрузки.
4.2. Аппаратная реализация
OpenSIP express версии 1.1 (OpenSER) — это прокси-сервер с открытым исходным кодом, написанный на C, и считается, что он обладает высокой эффективностью при минимальной функциональности. База данных хранит данные конфигурации OpenSER и регистрирует информацию о клиентах.Для проведения этих экспериментов используется блейд-сервер IBM с 4 ГБ ОЗУ и дисками ATA на 100 ГБ. В ходе исследования было замечено, что циклы ЦП проводят больше времени в прокси с отслеживанием состояния. Однако прокси с отслеживанием состояния записывает маршрут для использования в будущем.
4.3. Схема балансировщика нагрузки
Также было замечено, что без механизма обработчика сервер отбрасывает сообщения, что приводит к повторной передаче. С другой стороны, SIP-сервер отправляет ответы 503 Service Unavailable , чтобы избежать нежелательных повторных передач соответствующим клиентам [30].Этот сценарий ответа не может обеспечить лучшую производительность из-за относительно высокой стоимости обработки. Первоначально набор экспериментов проводится с обработчиком перед балансировщиком нагрузки, и эту комбинацию можно использовать для проверки сеансов тестовых вызовов. Полный сеанс фиксируется и анализируется в двухуровневой модели, чтобы гарантировать общее количество сеансов для вызова от клиента к серверу и наоборот. Балансировщик нагрузки поддерживает активную таблицу для отслеживания скорости входящей нагрузки и количества активных сеансов на сервере.Таймер установлен на 1 секунду для регулярного обновления активной таблицы. Предлагаемый алгоритм дает время паузы в среднем 1 мин и отклонение 30 сек.
5. Сравнение производительности
Нагрузка, создаваемая в этом эксперименте, варьируется до 8000 вызовов. Затем измеряется частота обнаружения обработчика, пропускная способность сервера, время отклика, загрузка ЦП и частота ошибок. Полученные результаты сравниваются с существующими алгоритмами (время отклика [25], минимальная работа транзакции 1.75 [22]). Чтобы определить производительность двухуровневой модели, выполняются две разные реализации. Первый — это балансировщик нагрузки с обработчиком, а второй — без обработчика. Каждая реализация измеряется в среднем в течение 10 минут, и каждое событие измеряется в течение периода разогрева 120 секунд и 5 секунд. Каждый тест запускается от 10 до 20 раз для проверки результатов и анализа средних значений различных параметров.
5.1. Распределение пакетов атаки
На рис. 9 показаны наблюдаемые пакеты атаки с использованием сигнализации SIP до обслуживания обработчика.Можно заметить, что поддельный и лавинный трафик приводят к значительным изменениям в сети VoIP. За неделю наблюдается 1821 флуд и 632 фальшивых SIP-сообщения. В дополнение к этому также получается 97 тайм-аутов и 117 пакетов повторной передачи. Следовательно, требуется надежный механизм защиты, чтобы отбросить нежелательный трафик.

5.2. Скорость обнаружения обработчика
Генерирует нормальный трафик и смешивается с атакующими пакетами от 100 до 400 пакетов в секунду (pps).Эксперимент повторяют от нескольких запусков до 20 раз. Предлагаемый процесс на обработчике способен определять более низкую скорость поступления 50 пакетов в секунду. Продолжительность скорости обнаружения варьируется от 5 до 10 секунд для увеличения коэффициента Пуассона от 100 до 400. Частота обнаружения рассчитывается из относительных пропорций атрибутов SIP в течение того же периода времени. Было обнаружено, что он имеет определенные большие колебания, как показано на рисунках 10 (a) и 10 (b). Существующие методы обнаружения на основе расстояния Хеллингера [36] требуют максимального порогового значения = 0.4. Предлагаемый обработчик использует только = 0,08 для лавинной рассылки, а поддельное сообщение потребляет максимум = 0,05.
5.3. Частота ложных тревог: ложные сообщения
На рисунке 11 показана частота ложных тревог для ложных сигнальных пакетов. Обнаружено, что предложенный обработчик оказывает хорошее влияние на правильную идентификацию ложных пакетов сигнализации. По мере увеличения количества вызовов частота ложных срабатываний ошибочно классифицированного пакета ложного сигнала достигает менее 0,2 для предлагаемого обработчика и 0,5 для существующей системы.

5.4. Время отклика
В таблицах 2, 3 и 4 показано среднее время отклика предлагаемой двухуровневой модели и существующего алгоритма. В этом эксперименте используется максимум 3 сервера, а производительность сервера варьируется от 300 до 500 cps. Среднее время отклика также варьируется при увеличении нагрузки до максимальной 1000 cps. Существующий алгоритм [25] занимает максимум 2,8 мс, тогда как LSTT поддерживает менее 1,41 мс для 1000 cps. Аналогичным образом применяется скорость обслуживания 1 мс и соответственно изменяется, для чего алгоритм LSTT дает максимум 1.Время отклика 9 мс и 0,3 мс соответственно, как указано в таблицах 3 и 4.
Сгенерированная нагрузка Время отклика (мс)
Планировщик на основе времени отклика [25] Предлагаемая двухуровневая модель
200 0,5 0,1
400 1,5 0,8
600 2 1.2
800 2,5 1,3
1000 2,8 1,41
00000 п. 00000
00000 п. 00000 00000 п. 00000
00000 п. 00000
00000 п. 00000
00000 п. 00000
00000 п. 00000 00000 п. 00000
00000 н. 00000
00000 п. 00000 00000 н. 00000
00000 п. 00000
00000 п. 00000 00000 п. 00000 00000 п. 00000 00000 п. 00000 00000 п. 00000 00000 п. 00000850 #.Светодиод линий начнет мигать красным. Телефон будет казаться выключенным, но стирает загрузчик и все еще загружает файлы с tftp. Ты должен быть терпеливым. !!!! ВАЖНО НЕ ВКЛЮЧАТЬ ТЕЛЕФОН, ПОТОМУ ЧТО БУДЕТ БЕСПОЛЕЗНЫ !!!!!!, по моему опыту, этот процесс может занять более 3 минут в модели 79X2, а иногда и 5 минут в семье 79X1.
После загрузки и запуска версии 8.5.2 вы можете без проблем перейти к версии 9.3 или 9.4. Для этого следует заменить строку SCCP41.9-4-2-1S с версией прошивки, будет зависеть от версии и модели вашего телефона, от вашего файла SEPMAC.cnf.xml.
Примечания: Восстановление заводских настроек: подключите телефон и удерживайте кнопку #, пока индикаторы внутренних линий не замигают желтым… 123456789 0 # Полный сброс к заводским настройкам: подключите телефон и удерживайте кнопку #, пока индикаторы добавочного номера не замигают желтым… затем нажмите 34850 #
79×1 / 79×2 / 79×5 / 797x (на основе Java)
Примечания: Восстановление заводских настроек: подключите телефон и удерживайте кнопку #, пока индикаторы внутренних линий не замигают желтым цветом… 123456789 0 # Полный сброс к заводским настройкам: подключите телефон и удерживайте кнопку #, пока индикаторы добавочного номера не замигают желтым… затем нажмите 34850 #
XML По умолчанию.cnf.xml:
8945
Решено: IP7000 завис при загрузке sip_401b.ld
Это моя последняя попытка ответить на ваши вопросы.
Источник:
7 октября 2011 г. Вопрос : Какое значение имеют файлы 000000000000.cfg или .cfg?
Разрешение : Отметьте => здесь <=
Телефон при загрузке с сервера Provisioning Server всегда будет искать свой собственный .cfg и загрузите его, если он найдется.
.cfg можно создать, открыв исходный 000000000000.cfg и сохранив его с MAC-адресом телефона.
ПРИМЕЧАНИЕ: .cfg — это просто заполнитель в этом объяснении для реального уникального MAC-адреса телефона.
В случае отсутствия физического лица .cfg Телефон загрузит 000000000000.cfg .
Выше четко объясняется, что делает телефон. Он проверяет наличие .cfg и, если его там нет, загружает 000000000000.cfg
Если вы используете несколько устаревших телефонов, вам понадобится только файл 000000000000.cfg, который поставляется, например, с загрузкой UCS 4.0.2 Rev B.
Это отдельные разделы для текущих телефонов:
<ПРИЛОЖЕНИЕ APP_FILE_PATH = "sip.ld "CONFIG_FILES =" "MISC_FILES =" "LOG_FILE_DIRECTORY =" "OVERRIDES_DIRECTORY =" "CONTACTS_DIRECTORY =" "LICENSE_DIRECTORY =" "USER_PROFILES_DIRECTORY =" "" CALL_LISTS_DIRECTORY3 = ">» CALL_LISTS_DIRECTORY3 = »
и в качестве примера (там их больше) для SPIP301
..

..
Выше снова наглядно видно, что телефоны загрузят, если нет индивидуального .cfg.
«Новые» телефоны загрузят sip.ld, но не загрузят конфигурацию (так как у нас ничего нет в CONFIG_FILES = «»)
SPIP301 загрузит sip_318.ld, phone1_318.cfg и sip_318.cfg (как мы указали в CONFIG_FILES_SPIP301 = «phone1_318.cfg, sip_318.cfg» />)
Я не могу выразиться более ясно, и вся эта информация задокументирована и успешно используется в течение многих лет бесчисленным количеством пользователей.
Затем вы можете использовать метод подстановки и предоставить отдельные файлы в пределах 0000000000000.cfg через:
…
!! Новый телефон с UCS !! ==== >>>
…
!! Старый телефон с SIP !! ==== >>>
…
Выше потребуется создать 3 файла.
Файл 1 для составленного Mac из 123456789012 называется 123456789012-extension.cfg
Файл 2 для составленного Mac из 123456789013 называется 123456789013-extension.cfg
Файл 3, который будет содержать конфигурацию для вашего сайта с деталями Sip-сервера и другими настройками, применимыми к нескольким телефонам.
Все телефоны будут загружать свое программное обеспечение SIP / UCS и соответствующее BootROM / Updater
Ваш новый телефон загрузит File1 и File 3
Затем ваш SPIP301 загрузит файл 2, файл 3, phone1_318 и sip_318
Для любого дополнительного телефона потребуется только индивидуальный [PHONE_MAC_ADDRESS] -extension.cfg
ПРИМЕЧАНИЕ: !! Это мой последний ответ, и любая дополнительная бесплатная поддержка должна исходить от любого другого члена сообщества Polycom, который желает более детально, как я уже сделал !!
ДОБАВЛЕНА ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ, ЧТОБЫ ВЫДЕЛИТЬ РАЗНИЦУ МЕЖДУ СТАРЫМ И НОВЫМ
С уважением
Штеффен Байер
—————-
Название Polycom Employee & Community Manager — это настройка сообщества, и не отражает мою роль.Я всего лишь простой волонтер в сообществе, как и все остальные. Все сообщения и слова принадлежат мне и не отражают точку зрения работодателя.
—————-
Примечание: этот форум сообщества не является официальным ресурсом поддержки Poly, поэтому ответы сотрудников, партнеров и клиентов Poly в равной степени являются наилучшими попытками поделиться полученными знаниями. Если вам нужна немедленная и / или официальная помощь, откройте заявку на обслуживание через соответствующие каналы поддержки.
Убедитесь, что вы всегда проверяете VoIP, конечную точку видео, Skype для бизнеса, PSTN или RPM FAQ

Переключатель потока / затяжки
Нежный глоток или затяжка трубки может быть проще и более подходящей для некоторых, чем более традиционный адаптивный переключатель.Как и традиционный переключатель, наши переключатели затяжки можно использовать для доступа ко всем устройствам, активируемым переключателем — устройствам, генерирующим речь, компьютерам, планшетам, мобильным телефонам, системам контроля окружающей среды и другим устройствам, предназначенным для сканирования переключателей.
Если вы можете использовать трубочку для питья, вы можете использовать наш переключатель «глоток / затяжка».
При выборе решения с переключателем затяжки и затяжки необходимо учитывать несколько моментов. Во-первых, это пользовательский интерфейс. Мы предлагаем два стандартных варианта размещения мундштука, гарнитуру и гибкий вал с универсальным зажимом.Однако вы можете присоединить ротовую трубку к другому устройству, уже расположенному рядом с пользователем. В этом случае у нас есть дополнительные трубки для настраиваемого интерфейса. Наша многопользовательская гарнитура оснащена одноразовым мундштуком и фильтром, которые легко заменяются. Это санитарное решение идеально подходит для центров оценки и ситуаций, когда несколько человек будут использовать один и тот же переключатель глоток / затяжка. Наш гибкий интерфейсный вал также оснащен навинчиваемыми и одноразовыми мундштуками с фильтром.
Используйте второе поколение Sip / Puff Breeze ™ для доступа к iPad, iPhone и iPod touch с помощью функции Apple Switch Control.
Второе соображение — возможность подключения. Устройство, которое превращает глотки и затяжки в электрические сигналы (часто называемое «переключателем интерфейса») для компьютера или устройства AAC, доступно в двух формах. Если требуется простое замыкание переключателя на стандартный разъем 3,5 мм, то пассивный переключатель Sip / Puff будет правильным выбором. Если требуется выход USB, то Sip / Puff Breeze ™ — правильный выбор.
Sip / Puff Breeze ™
Breeze второго поколения основывается на оригинальном комплексном переключателе глотка и затяжки и решении компьютерного интерфейса, добавляя возможность генерировать события Apple iOS Switch Control. Это первоклассный датчик давления / затяжки со встроенным компьютерным интерфейсом USB. Используйте встроенный DIP-переключатель Breeze, чтобы сообщить ему, какие события нужны вашему приложению, подключите его, подключите пневматическую трубку, и ваше приложение будет готово для доступа.
Sip / Puff Breeze теперь поддерживает iOS Switch Control.С адаптером для камеры Apple USB, Breeze теперь может обеспечить полный доступ к вашему iPad, iPhone или iPod touch.
Присоедините интерфейс пользователя с креплением к голове или гибкой стойкой к датчику ветра с помощью простого навинчиваемого пневматического разъема. Используя доступные трубки, вы даже можете создать свой собственный интерфейс. Чувствительный электронный датчик давления в Breeze распознает глоток или затяжку и преобразует эти события в щелчки кнопок мыши, нажатия кнопок джойстика или символы клавиатуры и передает их на подключенное хост-устройство USB.
Эмуляция кнопки мыши
Эмуляция кнопки джойстика
Эмуляция клавиатуры
События управления переключателем Apple iOS
Низкая задержка
Низкое энергопотребление
Работает со стандартными драйверами USB Human Interface Device (HID) для Windows, Mac и Linux
Питание от USB
Высокоскоростное USB-устройство
Стандартное давление на входе и выходе составляет примерно 3 дюйма водяного столба ниже и выше атмосферного давления
Настройка высокой чувствительности — приблизительно 2 дюйма водяного столба с повышенным гистерезисом
Режим Joystick Plus с показаниями манометра в реальном времени в виде значений X и Y джойстика (± 4 кПа)
2- по 0.8 на 0,5 дюйма (51 на 20 на 13 мм)
Вес — 14 г (полунции)
Перейдите по этой ссылке для получения дополнительной информации о Breeze и объяснения режима Joystick Plus.
Sip / Puff Switch ™
Все решения с пользовательским интерфейсом могут быть подключены к отдельному двойному реле давления с помощью простого навинчиваемого пневматического разъема. Два реле давления имеют нормально разомкнутые контакты, которые замыкаются, когда пользователь делает глоток или делает затяжку из прикрепленного мундштука.Эти переключатели сигнализации низкого напряжения и тока предназначены для подключения к электронному устройству — они не предназначены для переключения силовых нагрузок.
Пороговые значения давления нагнетания и затяжки составляют примерно 3 дюйма водяного столба ниже и выше атмосферного давления
Коммутаторы выдерживают 40 миллиампер при переменном / постоянном токе –30 вольт или меньше с резистивной нагрузкой на миллионы циклов
Двойной переключатель давления имеет два разъема 3,5 мм (1/8 дюйма для наушников). Один разъем обеспечивает как глоток, так и затяжку с помощью стереокабеля
Простой ползунковый переключатель можно использовать для изменения восприятия сигналов Sip и Puff на стереоразъеме
Пассивные реле давления не требуют батарей или внешнего источника питания
В корпус встроены контрольные переключатели «sip» и «puff»
Предложения продуктов для глотка / затяжки
Решения Sip / Puff продаются отдельно и в следующих комплектах:
К отдельным компонентам и заменам относятся:

Переключатель Sip / Puff с гарнитурой

Переключатель «глоток / затяжка» переводит глотки и затяжки в независимые замыкания переключателя.Переключатель Sip / Puff имеет два (2) порта 3,5 мм для подключения двух стандартных монокабелей или одного стереокабеля, а также имеет встроенные кнопки тестирования для помощи в тестировании приложений.
Sip / Puff Headset — это удобная регулируемая оправа для головы. Мягкая гарнитура надевается на уши и за голову. Сменная горловина удерживается на месте с помощью встроенной формовочной проволоки из нержавеющей стали. Трубку и проволоку можно сгибать и разрезать в соответствии с индивидуальными потребностями.
Переключатель Sip / Puff с гарнитурой включает:
Переключатель Sip / Puff со встроенными реле давления «sip» и «Puff» (внешнее питание не требуется)
Гарнитура Sip / Puff с прикрепленным 6-футовым (1.8-метровая воздушная трубка и поворотный соединитель для подсоединения к переключателю Sip / Puff
Два (2) 5-футовых кабеля, один моно и один стерео
Четыре (4) трубки для рта Sip / Puff со встроенной формирующей проволокой из нержавеющей стали (одна прикреплена к гарнитуре Sip / Puff)
Документация
Ограниченная гарантия на 1 год
Купить переключатель Sip / Puff с гарнитурой
Купить сменные насадки для рта Sip / Puff (10 шт.)

Переключатель Sip / Puff с гибкой стойкой

Переключатель «глоток / затяжка» переводит глотки и затяжки в независимые замыкания переключателя.Переключатель Sip / Puff имеет два (2) порта 3,5 мм для подключения двух стандартных монокабелей или одного стереокабеля, а также имеет встроенные кнопки тестирования для помощи в тестировании приложений.
Прочный, легкий и универсальный, Sip / Puff Gooseneck имеет универсальное крепление, которое надежно прикрепляется к столешницам, кроватям и инвалидным креслам. Гибкая стальная гусиная шея и шарнирное крепление позволяют легко и надежно установить мундштук. Мундштук с фильтром можно заменить, а тонкая гибкая соединительная трубка соединяет мундштук с переключателем глоток / затяжка с помощью простого поворотного соединителя.
Переключатель Sip / Puff с гибкой стойкой включает:
Переключатель Sip / Puff со встроенными реле давления «sip» и «Puff» (внешнее питание не требуется)
Гусиная шея Sip / Puff с универсальным креплением
6-футовая (1,8-метровая) трубка с поворотными соединителями
Кабели (1 моно и 1 стерео)
Четыре (4) мундштука на гибкой стойке с фильтром
Документация
Ограниченная гарантия на 1 год
Купить переключатель Sip / Puff с гибкой стойкой
Купить сменные мундштуки на гибкой стойке (10 шт.)

Sip / Puff Breeze с гарнитурой

Sip / Puff Breeze — это усовершенствованный USB-переключатель sip / puff в чрезвычайно компактном корпусе.Он подключается напрямую к стандартным USB-портам на компьютерах, ноутбуках и устройствах AAC и обеспечивает аппаратную эмуляцию кнопок мыши или функций джойстика.
Sip / Puff Headset — это удобная регулируемая оправа для головы. Мягкая гарнитура надевается на уши и за голову. Сменная горловина удерживается на месте с помощью встроенной формовочной проволоки из нержавеющей стали. Трубку и проволоку можно сгибать и разрезать в соответствии с индивидуальными потребностями.
Sip / Puff Breeze с гарнитурой включает:
Sip / Puff Breeze с встроенным фильтром
Гарнитура Sip / Puff с прикрепленным 6-футовым (1.8-метровая воздушная трубка и поворотный соединитель для крепления к Sip / Puff Breeze
Четыре (4) трубки для рта Sip / Puff со встроенной формирующей проволокой из нержавеющей стали (одна прикреплена к гарнитуре Sip / Puff)
Документация
Ограниченная гарантия на 1 год
Купить Sip / Puff Breeze с гарнитурой
Купить сменные насадки для рта Sip / Puff (10 шт.)
Купить сменные встроенные фильтры Breeze (10 шт.)

Sip / Puff Breeze с гусиной шеей

Sip / Puff Breeze — это усовершенствованный USB-переключатель sip / puff в чрезвычайно компактном корпусе.Он подключается напрямую к стандартным USB-портам на компьютерах, ноутбуках и устройствах AAC и обеспечивает аппаратную эмуляцию кнопок мыши или функций джойстика.
Прочный, легкий и универсальный, Sip / Puff Gooseneck имеет универсальное крепление, которое надежно прикрепляется к столешницам, кроватям и инвалидным креслам. Гибкая стальная гусиная шея и шарнирное крепление позволяют легко и надежно установить мундштук. Мундштук с фильтром можно заменить, а тонкая гибкая соединительная трубка соединяет мундштук с Sip / Puff Breeze с помощью простого поворотного соединителя.
Sip / Puff Breeze с гусиной шеей включает:
Sip / Puff Breeze с встроенным фильтром
Гусиная шея Sip / Puff с универсальным креплением
6-футовая (1,8-метровая) трубка с поворотными соединителями
Четыре (4) мундштука на гибкой стойке с фильтром
Документация
Ограниченная гарантия на 1 год
Купить Sip / Puff Breeze с гусиной шеей
Купить сменные мундштуки на гибкой стойке (10 шт.)
Купить сменные встроенные фильтры Breeze (10 шт.)

Многопользовательский переключатель Sip / Puff с гарнитурой
Многопользовательский переключатель глотка / затяжки с гарнитурой предназначен для медицинских учреждений, центров оценки, больниц и т. Д.со средствами поддержки нескольких пользователей, уменьшая при этом озабоченность по поводу санитарии. Кнопки тестирования «Sip» и «Puff» интегрированы для помощи в тестировании приложений.
Многопользовательская гарнитура Sip / Puff разработана специально для поддержки одноразовых мундштуков. Одноразовый мундштук прикрепляется за секунды с помощью защелкивающейся застежки и включает встроенный асептический фильтр, обеспечивающий гигиеничный и беспроблемный доступ для нескольких пользователей. Система упакована в компактный кейс для удобства хранения и транспортировки.
Многопользовательский переключатель Sip / Puff с гарнитурой включает:
Многопользовательская гарнитура Sip / Puff
Переключатель Sip / Puff со встроенными реле давления «sip» и «Puff» (внешнее питание не требуется) и встроенными тестовыми кнопками для помощи пользователям
1,8-метровая воздушная трубка с быстроразъемными соединениями для крепления переключателя гашения / затяжки и узла одноразового мундштука
Два (2) 5-футовых кабеля 3,5 мм, один моно и один стерео для работы с одним или двумя кабелями
Пять (5) одноразовых мундштуков в сборе, каждая закрыта перчатками и инструкцией
Переносной жесткий пластиковый чемодан с подушкой из поролона для безопасной транспортировки и хранения
Документация
Ограниченная гарантия на 1 год
Купить многопользовательский переключатель Sip / Puff с гарнитурой
Купить сменные одноразовые мундштуки (10 шт.)

Переключатель потока / затяжки
Все решения с пользовательским интерфейсом могут быть подключены к отдельному двойному реле давления с помощью простого навинчиваемого пневматического разъема.Два реле давления имеют нормально разомкнутые контакты, которые замыкаются, когда пользователь делает глоток или делает затяжку из прикрепленного мундштука. Эти переключатели сигнализации низкого напряжения и тока предназначены для подключения к электронному устройству — они не предназначены для переключения силовых нагрузок.
Пороговые значения давления нагнетания и затяжки составляют примерно 3 дюйма водяного столба ниже и выше атмосферного давления
Коммутаторы выдерживают 40 миллиампер при переменном / постоянном токе –30 вольт или меньше с резистивной нагрузкой на миллионы циклов
Двойное реле давления имеет два 3.Разъемы 5 мм (1/8 дюйма для наушников). Один разъем обеспечивает как глоток, так и затяжку с помощью стереокабеля
Простой ползунковый переключатель можно использовать для изменения восприятия сигналов Sip и Puff на стереоразъеме
Пассивные реле давления не требуют батарей или внешнего источника питания
В корпус встроены контрольные переключатели «sip» и «puff»
Ограниченная гарантия на 1 год
Купить переключатель Sip / Puff

Глоток / Пух Бриз
Все решения пользовательского интерфейса могут быть подключены к отдельному датчику ветра с помощью простого навинчиваемого пневматического разъема.Электронный датчик давления в Breeze распознает глоток или затяжку и преобразует эти события в щелчки кнопок мыши или нажатия кнопок джойстика и передает их на подключенное хост-устройство USB (обычно ПК или компьютер Mac).
Пороговые значения давления нагнетания и затяжки составляют примерно 3 дюйма водяного столба ниже и выше атмосферного давления
Эмуляция кнопки мыши
Эмуляция кнопки джойстика
Чрезвычайно низкая задержка
Работает со стандартными драйверами USB Human Interface Device (HID) для Windows, Mac и Linux
Питание от USB
Манометрическое давление в реальном времени может отображаться в виде значений X и Y джойстика (± 4 кПа)
2- по 0.8 на 0,5 дюйма (51 на 20 на 13 мм)
Вес — 14 г (полунции)
Ограниченная гарантия на 1 год
Купить Sip / Puff Breeze
Купить сменные встроенные фильтры Breeze (10 шт.)

Сменная трубка для рта Sip / Puff для однопользовательской гарнитуры

Сменная трубка для рта Sip / Puff имеет формовочную проволоку из нержавеющей стали, которая позволяет расположить трубку в удобном месте рядом со ртом.Для достижения наилучших результатов пластиковая трубка должна доходить до пластикового крепления трубки из нержавеющей стали гарнитуры.
Сменная трубка для рта Click Sip / Puff (10 шт.)
Сменная трубка для рта Click Sip / Puff (100 шт.)

Сменный мундштук на гибкой стойке

Сменный загубник на гибкой стойке с фильтром имеет простой поворотный соединитель.
Купить сменный мундштук на гибкой стойке (10 шт.)
Купить сменный мундштук на гибкой стойке (20 шт.)

Сменный встроенный фильтр

Этот фильтр необходим для Breeze и настоятельно рекомендуется для переключателя Sip / Puff.Гарнитура Origin Instruments Sip / Puff спроектирована таким образом, что сила тяжести обычно сводит к минимуму слюну, проходящую мимо гарнитуры. Если слюна проходит через гарнитуру, требуется встроенный фильтр. Нет необходимости вставлять более одного фильтра. Например, мундштук на гибкой стойке имеет встроенный фильтр, поэтому второй фильтр использовать не следует.
Купить сменные встроенные фильтры (10 шт.)
Купить сменные встроенные фильтры (20 шт.)

Универсальное крепление
Гибкий вал поставляется с регулируемым суперзажимом.Зажим поддерживает жесткое крепление к столешницам, полкам или цилиндрическим стержням диаметром до 2,1 дюйма (53 мм) и весом 33 фунта (15 кг). Гибкий вал имеет стандартную резьбу 1 / 4-20 для использования с поставляемым супер зажимом, штативами или другим специальным монтажным оборудованием.
Рукоятка зажима имеет храповой механизм, облегчающий затягивание зажима до упора.
V-образная канавка зажима облегчает его прикрепление к цилиндрическому объекту. Используйте клиновую вставку для максимальной поддержки при прикреплении к плоским предметам.Для цилиндрических объектов снимите клин и поместите его под Т-образную гайку, как показано на изображении выше.
Дополнительные ресурсы
Загрузить руководства пользователя по продукту для глотания / затяжки
9001 Скорость ответа 900 время (мс)
Планировщик на основе времени отклика Предлагаемая двухуровневая модель
0,2 2.3 1
0,4 3,1 1,4
0,6 3,5 1,6
0,8 4,7 1,9
90
Использование Время отклика (мс)
Планировщик на основе времени отклика Предлагаемая двухуровневая модель
0.2 2,4 0,9
0,4 1,8 0,5
0,6 1,2 0,4
0,8 0,9 0,3
5.5. Пропускная способность балансировщика нагрузки
Пропускная способность существующих алгоритмов [22, 25] сравнивается с предложенным алгоритмом, представленным в таблицах 5 и 6. Результаты по пропускной способности получены для создания нагрузки 8000 cps без паузы.Из таблицы 5 видно, что LSTT достигает максимальной пропускной способности 99%. Однако существующее время отклика [25] достигает только 90%, а TLWL 1,75 [22] достигает максимума 91,6%.
%
Сгенерированные вызовы Пропускная способность (%)
TLWL 1,75 [22] Планировщик на основе времени отклика Предлагаемая двухуровневая модель
17 910 1000 78.2% 78% 93,3%
2000 81% 82,66 95,7%
3000 86,6% 86,6% 99,45
87,5% 99,28%
5000 88,8% 86,32% 98,43
6000 91,6% 90,325% 99,37%
.32 71,32 81,32%
8000 61,25% 60,13% 74,84%
17 910 Количество клиентов 900 Пропускная способность (Кбит / с)
TLWL 1,75 Планировщик на основе времени отклика Предлагаемая двухуровневая модель
2 13 15 18
18
30 33 38
6 41 44 50
8 45 52 72
10 50 55 55 900
Количество клиентов увеличено до 10 максимум для 3 серверов.Полученные результаты по пропускной способности представлены в таблице 6, и очевидно, что предложенный алгоритм работает лучше, несмотря на увеличение количества клиентов. Эффективность алгоритма LSTT проверяется путем удаления первого уровня, и было замечено, что LSTT линейно увеличивает пропускную способность максимум до 6821 cps без обработчика и 7420 cps с обработчиком, как показано на рисунке 12.

5.6. Загрузка ЦП
Таблица 7 суммирует время выполнения алгоритма LSTT и соответствующую загрузку ЦП.Время выполнения процесса оценки алгоритма LSTT — это отметка времени между запросом BYE от клиента и его соответствующим ACK от сервера. Двухуровневая модель использует меньше времени для выполнения SIP-транзакции, поскольку она тратит минимальное количество времени на анализ сообщения, тогда как остальные алгоритмы отслеживают и анализируют большое количество сообщений.
Загрузка ЦП (%) Алгоритм LSTT
10 0.034
20 0,033
30 0,033
40 0,0333
50 0,0334
60 0,0314
60 0,0314
80 0,0337
100 0,0339
5,7. Частота ошибок
На рисунке 13 показана частота ошибок различных алгоритмов балансировки нагрузки.Частота ошибок — это процент неудачных запросов, которые не получают соответствующие серверы, поскольку балансировщик нагрузки тратит больше времени на анализ сообщений.

Из рисунка 13 видно, что лучший алгоритм балансировки нагрузки увеличивает скорость принятия нагрузки и отклоняет запрос, который тратит больше времени на потребление ресурсов. Кроме того, скорость поступления чрезмерных запросов в балансировщик нагрузки требует больше времени на обработку, и эти запросы не требуются для служб.Если тратить больше времени на анализ этих запросов, увеличивается количество ошибок. Однако удаление этих сообщений может привести к максимальной пропускной способности. Результат по частоте ошибок ясно показывает, что существует ряд запросов, которые не распределяются эффективно из-за условий тайм-аута. Предложенный алгоритм LSTT достигает 5% частоты ошибок при предлагаемой нагрузке 4500 cps, а TLWL 1,75 генерирует 15% частоты ошибок.
6. Заключение
В этой статье была предложена двухуровневая модель для устранения вредоносного трафика на первом уровне и обеспечения равномерного распределения нагрузки на втором уровне.Предлагаемый алгоритм LSTT гарантирует, что все входящие / исходящие сообщения SIP направляются на соответствующий сервер, который имеет наименьшее время завершения сеанса на данный момент. Результаты реализации феноменально впечатляют, и предлагаемая модель значительно улучшает пропускную способность и использование ЦП на 99%, даже когда предлагаемая нагрузка составляла максимум 8000 циклов в секунду. В то же время система мгновенно реагирует на изменение генерируемой нагрузки и обеспечивает лучшую производительность с уменьшенным коэффициентом ошибок на 5%.Таким образом, можно сделать вывод, что предлагаемая двухуровневая система обеспечивает повышенную производительность с гарантированным QoS.
Используемые параметры
: SIP-сообщения
: Время прибытия
: Время обработки
: Время ожидания
Срок действия
: Задержка
: Время завершения сообщения
: Время замедления или холостого хода
WT: Вес.
Конфликт интересов
Авторы заявляют об отсутствии конфликта интересов.
% PDF-1.6 % 3224 0 объект> эндобдж xref 3224 106 0000000016 00000 н. 0000004473 00000 н. 0000004796 00000 н. 0000004849 00000 н. 0000005239 00000 п. 0000005646 00000 н. 0000006063 00000 н. 0000006957 00000 н. 0000006995 00000 н. 0000012973 00000 п. 0000013554 00000 п. 0000013632 00000 п. 0000014834 00000 п. 0000015375 00000 п. 0000016266 00000 п. 0000019385 00000 п. 0000019804 00000 п. 0000020192 00000 п. 0000020419 00000 п. 0000026047 00000 п. 0000026557 00000 п. 0000026933 00000 п. 0000027264 00000 н. 0000029011 00000 п. 0000030041 00000 п. 0000030622 00000 п. 0000038573 00000 п. 0000038968 00000 п. 0000039368 00000 п. 0000040931 00000 п. 0000041528 00000 п. 0000041724 00000 п. 0000041979 00000 п. 0000042202 00000 п. 0000044000 00000 н. 0000044754 00000 п. 0000050111 00000 п. 0000050631 00000 п. 0000050999 00000 н. 0000051333 00000 п. 0000052711 00000 п. 0000054016 00000 п. 0000055537 00000 п. 0000056892 00000 п. 0000084975 00000 п. 0000087646 00000 п. 0000087720 00000 п. 0000087809 00000 п. 0000087955 00000 п. 0000088044 00000 п. 0000088098 00000 п. 0000088270 00000 п. 0000088441 00000 п. 0000088495 00000 п. 0000088676 00000 п. 0000088838 00000 п. 0000088959 00000 п. 0000089013 00000 п. 0000089128 00000 п. 0000089285 00000 п. 0000089339 00000 п. 0000089511 00000 п. 0000089620 00000 н. 0000089673 00000 п. 0000089768 00000 н. 0000089920 00000 н. 00000
00000 п. 00000
00000 п. 00000
00000 п. 00000
00000 п. 00000
00000 п. 00000 00000 н. 00000
00000 п. 00000
00000 п. 00000
00000 п. 0000092424 00000 п. 0000092478 00000 п. 0000092532 00000 п. 0000092719 00000 н. 0000092773 00000 п. 0000092926 00000 п. 0000092980 00000 п. 0000093137 00000 п. 0000093191 00000 п. 0000093245 00000 п. 0000093299 00000 н. 0000004235 00000 н. 0000002469 00000 н. трейлер ] >> startxref 0 %% EOF 3329 0 obj> поток х ڔ V Pu {wy {-p * Mb & ZTW ٸ YvR} qNf9} @EdIF Մ L3M ݓ @ s {3} g
изменить прошивку с sip на sccp
Обновить микропрограмму на телефонах Cisco просто.Им просто нужен tftp-сервер для обновления его прошивки, и он даже не должен находиться в самой системе звездочки / телефона. Обновление телефонов Cisco происходит в два этапа. Загрузчик, затем приложение. После обновления загрузчика все пароли и сетевая информация на телефоне будут удалены. Но что важно при обновлении этих телефонов, так это DHCP-сервер с включенной опцией 150 — опция для автоматического предоставления IP-адреса tftp-сервера, когда DHCP-сервер передает обычный IP-адрес телефону.
Без автоматически настроенного адреса tftp-сервера телефон выполнит только половину обновления и выдаст сообщение об ошибке «протокол приложения недействителен». Это просто означает, что телефону не удалось завершить вторую половину обновления и необходимо указать IP-адрес tftp. Проблема только в том, что нет запущенного приложения, негде указать адрес! Слава богу, есть опция DHCP 150, которая делает это за нас, когда телефон захватывает IP-адрес после загрузки загрузчика.
Дополнительная информация о:
Изменение прошивки на телефоне cisco зависит от модели. Мы предполагаем, что вы уже скачали необходимую версию прошивки. Инструкции по установке для конкретной модели ниже:
Общие инструкции:
В этом разделе мы используем телефон 7960 в качестве шаблона, чтобы показать, как работает общий процесс установки прошивки на телефоны cisco.
Теперь при обновлении телефонов cisco 7940/7960 следует учитывать несколько моментов.Но эмпирическое правило состоит в том, что если у вас есть SCCP на вашем телефоне, вам нужно использовать файл XMLDefault.cnf.xml, чтобы указать тег информации о загрузке прошивки, с помощью которого телефон может узнать, какую нагрузку он должен установить. В оставшейся части этого руководства я просто предполагаю, что вы хотите преобразовать SCCP в SIP.
Самый простой способ установить SIP на свой телефон — это установить универсальный загрузчик приложений. Я обнаружил, что версия 8.0.9 SCCP (P00308000900) имеет наиболее совместимый загрузчик, который позволяет легко переключаться между текущими загрузками SIP и SCCP.Поэтому лучше всего обновить свой телефон SCCP с помощью более новой нагрузки SCCP перед переключением на SIP. Если у вас очень старая версия SCCP, вы обнаружите, что не можете сразу перейти на эту версию. В этом случае просто загрузите версию 3 (P00303010102), затем загрузите версию 5 (P00305000500), а затем перейдите к версии 8.0.9 (P00308000900). Для этого вам необходимо загрузить эти версии прошивки и просто распаковать их все в один каталог. Вышеупомянутые версии прошивки зависят от модели, проверьте ниже инструкции для каждой версии модели.
Теперь загрузите файл XMLDefault.cnf.xml и поместите этот файл в каталог прошивки. Убедитесь, что ваша конкретная модель телефона уже есть в файле (и при необходимости отредактируйте). После загрузки файла отредактируйте тег loadInformation в файле XMLDefault.cnf.xml, указав микропрограмму, которую вы хотите установить на свой телефон. Не добавляйте расширение имени файла, только имя файла (например, P00308000500). Сохраните и переходите к следующему шагу.
Затем подключите телефон с помощью перекрестного кабеля или коммутатора Ethernet к компьютеру, на котором запущен этот сервер (убедитесь, что вы отключили все устройства, подключенные к сети, которые разрешают IP через DHCP, так как это будет конфликтовать с любым другим сервером DHCP на сеть).
Выключите и снова включите телефон и очистите конфигурацию, удерживая клавишу # и затем подключив телефон. После того, как все индикаторы на телефоне начнут мигать, отпустите клавишу # и нажмите 123456789 * 0 #, а затем клавишу 2 (это называется сбросом к заводским настройкам, разные модели могут иметь разные последовательности сброса к заводским настройкам, проверьте ниже). Индикаторы станут красными, но если этого не произошло, повторите этот шаг. Затем телефон сотрет флэш-память и загрузит любую прошивку, указанную в каталоге tftp — если телефон просто продолжает загружать термин.defaults, просто выполните инкрементное обновление до нужной версии прошивки). Это очистит все настройки телефона и установит для него значения по умолчанию. После перезагрузки телефон получит IP-адрес с сервера DHCP на машине Windows, на которой запущен сервер DHCP. DHCP также назначит телефону IP-адрес для tftp-сервера, используя опцию 150, и телефон должен начать скачивать файлы с сервера после того, как получит IP-адрес.
Если вы выполняете инкрементное обновление до версии 8.0.9, просто продолжайте редактировать файл XMLDefault.cnf.xml со следующей версией прошивки и сохраните, а затем перезагрузите телефон (после того, как он завершит загрузку и загрузчика, и приложения). Телефон должен обнаружить, что ему необходимо обновить себя, пока вы не перестанете редактировать файл с новой информацией о прошивке.
После того, как телефон перейдет на SCCP версии 8.0.9, все, что вам нужно сделать, это просто загрузить нужную версию прошивки SIP и затем извлечь ее в отдельный каталог. Укажите TFTP Deamon, чтобы использовать этот каталог, скопируйте XMLDefault.cnf.xml в этот каталог и отредактируйте тег loadInformation, указав имя файла POS-xxx, которое находится в этом каталоге, и перезагрузите телефон. Телефон автоматически переключится на загрузку прошивки SCCP. Телефоны 79 × 1/79 × 2/79 × 5/7970 занимают немного больше времени, чтобы полностью завершить процесс прошивки, поскольку они используют больше и больше файлов, чем телефоны серии 7940/60. Если телефоны просто сидят, как будто ничего не делают, подождите еще немного, и они должны вернуться. Нередко на выполнение всего процесса на одном телефоне уходит до 4-5 минут.
Вот и все, и теперь, когда в телефоне есть хороший универсальный загрузчик приложений, у вас не будет проблем с переключением между SIP и SCCP, просто указав на телефоне соответствующий каталог.
6921/6941/6961
Инструкции
7905/7912
7940/7960
См. Раздел Устранение неполадок IP-телефонов Cisco серий 7940 и 7960
7941/7961
Если у вас есть телефон Cisco 79XX с прошивкой SIP и вы хотите вернуться к SCCP:
Настройте сервер TFTP и установите версию прошивки Cmterm79XX версии 8.5.2 Эта версия — то, что нужно для перехода к другой более новой версии, например SCCP 9.4. Если вы попытаетесь выполнить обновление сразу до 9.4, но не сразу до 8.5.2, процесс обновления завершится ошибкой: Auth Failed.
Выполните сброс настроек до заводских, выключив телефон. Затем снова включите питание, удерживая нажатой кнопку #, пока светодиоды не начнут мигать, выполните 123456789 0 #. Иногда в зависимости от установленной в настоящее время версии (SIP или SCCP) этот процесс завершится ошибкой из-за версии загрузчика, поэтому вам придется выполнить 34
RFC 7200 — протокол инициации сеанса (SIP), даже контроль нагрузки (RFC7200)

Инженерная группа Интернета (IETF) К. Шен Запрос комментариев: 7200 H. Schulzrinne Категория: Стандарты Track Columbia U.ISSN: 2070-1721 А. Койке NTT Апрель 2014 г. Пакет событий управления загрузкой протокола инициации сеанса (SIP) Абстрактный Эта спецификация определяет пакет событий управления нагрузкой для Протокол инициации сеанса (SIP). Это позволяет объектам SIP распространять политики фильтрации нагрузки на другие объекты SIP в сеть.Политики фильтрации нагрузки содержат правила для ограничения вызовов. от конкретного пользователя или на основе их исходного или целевого домена, префикс телефонного номера. Механизм помогает предотвратить сигнализацию перегрузки и дополняет усилия по контролю перегрузки SIP на основе обратной связи. Статус этой памятки Это документ Internet Standards Track. Этот документ является продуктом Инженерной группы Интернета. (IETF). Он представляет собой консенсус сообщества IETF. Она имеет получил публичное рецензирование и был одобрен к публикации Инженерная группа управления Интернетом (IESG).Дополнительная информация о Интернет-стандарты доступны в разделе 2 RFC 5741. Информация о текущем статусе этого документа, исправлениях, а о том, как оставить отзыв, можно узнать по адресу http://www.rfc-editor.org/info/rfc7200. Уведомление об авторских правах Авторские права (c) IETF Trust 2014 г. и лица, указанные в качестве авторы документа. Все права защищены. Этот документ подпадает под действие BCP 78 и Правового регулирования IETF Trust. Положения, касающиеся документов IETF (http: // попечитель.ietf.org/license-info) действует на дату публикация этого документа. Пожалуйста, просмотрите эти документы внимательно, поскольку они уважительно описывают ваши права и ограничения к этому документу. Компоненты кода, извлеченные из этого документа, должны включить упрощенный текст лицензии BSD, как описано в Разделе 4.e Правовые положения Trust и предоставляются без гарантии, как описано в упрощенной лицензии BSD. Оглавление 1. Введение .................................................... 3 2. Условные обозначения ............................................... ...... 3 3. Обзор фильтрации нагрузки SIP ..................................... 4 3.1. Формат политики фильтрации нагрузки ............................... 4 3.2. Расчет политики фильтрации нагрузки .......................... 4 3.3. Распределение политики фильтрации нагрузки ......................... 4 3.4. Применимые сетевые домены ................................. 8 4. Пакет событий управления нагрузкой...................................... 9 4.1. Имя пакета событий ......................................... 9 4.2. Параметры пакета событий ................................... 9 4.3. ПОДПИСАТЬСЯ на органы ........................................... 9 4.4. ПОДПИСАТЬСЯ Продолжительность ......................................... 9 4.5. Уведомление органов ............................................. 10 4.6. Уведомляющая обработка запросов на ПОДПИСКУ ................. 10 4.7. Уведомление Генерация запросов NOTIFY.................... 10 4.8. Обработка подписчиками запросов NOTIFY .................. 10 4.9. Обработка разветвленных запросов ............................... 12 4.10. Скорость уведомлений .................................... 12 4.11. Состояние Дельта .............................................. 12 5. Документ по контролю нагрузки .......................................... 13 5.1. Формат ................................................. ... 13 5.2. Пространство имен ................................................. 13 5.3. Условия ................................................ 14 5.3.1. Идентификация вызова ...................................... 14 5.3.2. Метод ............................................. 16 5.3.3. Целевая SIP-сущность .................................. 17 5.3.4. Срок действия ........................................... 18 5.4. Действия ................................................. ..18 6. Определение схемы XML для управления нагрузкой......................... 20 7. Соображения безопасности ........................................ 23 8. Вопросы IANA ............................................ 24 8.1. Регистрация пакета событий управления нагрузкой ................... 24 8.2. application / load-control + xml Регистрация типа носителя ...... 24 8.3. Регистрация подпространства имен URN ............................ 25 8.4. Регистрация схемы управления нагрузкой .......................... 26 9. Благодарности ............................................... 27 10. Ссылки ............................................... ..... 27 10.1. Нормативные ссылки ..................................... 27 10.2. Информационные ссылки ................................... 28 Приложение A. Определения ........................................... 30 Приложение B. Требования к конструкции ................................... 30 Приложение C. Обсуждение соответствия данной спецификации требованиям Требования RFC 5390.............................. 31 Приложение D. Полные примеры ..................................... 36 D.1. Примеры документов по контролю нагрузки ............................ 36 D.2. Примеры потока сообщений ..................................... 40 Приложение E. Сопутствующие работы ......................................... 41 E.1. Связь с фильтрацией нагрузки в PSTN .................... 41 E.2. Связь с другими усилиями IETF по контролю перегрузки SIP .42 1. Введение Механизмы управления нагрузкой SIP необходимы для предотвращения коллапса перегрузки [RFC6357] в случаях перегрузки SIP-сервера [RFC5390].Есть два типы подходов к регулированию нагрузки. В первом подходе обратная связь управления, SIP-серверы обеспечивают ограничение нагрузки на вышестоящие серверы, чтобы уменьшить входящую скорость всех SIP-запросов [SIP-OVERLOAD]. Эти вышестоящие серверы затем отбрасывают или задерживают входящие SIP-запросы. Обратная связь управление является реактивным и влияет на сигнальные сообщения, которые уже был выдан клиентскими агентами пользователя. Этот подход хорошо работает, когда SIP прокси-серверы в основных сетях (основные прокси-серверы) или прокси-серверы SIP для конкретных целей в пограничных сетях (граничные прокси-серверы) перегружены.По своей природе они должны распространять информацию о скорости, отбрасывании или окне по всем вышестоящим SIP прокси-серверов и обычно одинаково влияют на все вызовы, независимо от место назначения. В данной спецификации предлагается дополнительный, дополнительный контроль нагрузки. механизм, называемый «фильтрация нагрузки». Это наиболее применимо для ситуации, когда всплеск трафика и его источник / пункт назначения распределение можно спрогнозировать заранее. В таких случаях сеть операторы создают политики фильтрации нагрузки, которые указывают на вызовы определенные направления или из определенных источников должны быть ограничены по скорости или случайно уронили.Эти политики фильтрации нагрузки затем распространяется на SIP-серверы и, возможно, SIP-пользовательские агенты, которые может вызвать звонки в затронутые пункты назначения или из затронутые источники. Фильтрация нагрузки работает лучше всего, если она предотвращает вызовы как как можно ближе к исходным клиентам пользовательских агентов. В применимость фильтрации нагрузки SIP также может быть расширена за контроль перегрузки, например, для реализации соглашения об уровне обслуживания обязательства. 2. Условные обозначения Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом документ следует интерпретировать, как описано в [RFC2119].3. Обзор фильтрации нагрузки SIP 3.1. Формат политики фильтрации нагрузки Политики фильтрации нагрузки задаются наборами правил. Каждое правило содержит как условия фильтрации нагрузки, так и действия. Загрузка- условия фильтрации определяют личности фильтруемых целей (Раздел 5.3.1). Например, есть два типичных ограничения ресурсов в случае возможной перегрузки, т. е. ограничения места назначения человека (количество звонящих) и лимиты пропускной способности узла. Фильтрация нагрузки целями в этих двух случаях могут быть конкретные номера вызываемых абонентов или целевой домен, соответствующий перегрузке.Фильтрация нагрузки условия также указывают на конкретный тип сообщения, которое необходимо сопоставить (Раздел 5.3.2), с каким целевым SIP-объектом применяется политика фильтрации. связанный (раздел 5.3.3), и период времени, когда фильтрация политика должна быть активирована и деактивирована (раздел 5.3.4). Нагрузка- действия фильтрации описывают желаемые функции управления, такие как удерживая частоту запросов ниже заданного уровня (раздел 5.4). 3.2. Расчет политики фильтрации нагрузки При вычислении политик фильтрации нагрузки необходимо учитывать учитывать информацию, такую как время перегрузки, объем и сеть топология, а также политики обслуживания.Также важно сделать убедитесь, что нет цикла распределения ресурсов и что сервер мощность распределяется таким образом, чтобы предотвратить перегрузку и максимизирует эффективную пропускную способность (обычно называемую хорошей пропускной способностью). В некоторых случаях, чтобы лучше использовать системные ресурсы, это может быть предпочтительно использовать алгоритм, который динамически вычисляет нагрузку. политики фильтрации, основанные на текущем наблюдаемом состоянии загрузки сервера, вместо использования чисто статической политики фильтрации.В алгоритм вычисления для политик фильтрации нагрузки выходит за рамки данной спецификации. 3.3. Распространение политики фильтрации нагрузки Для распространения политик фильтрации нагрузки эта спецификация определяет пакет событий SIP для управления нагрузкой, который является «инстанцией» общей структуры уведомления о событиях SIP [RFC6665]. Этот спецификация также определяет XML-схему документа управления загрузкой (Раздел 5), который используется для кодирования политик фильтрации нагрузки. Для правильного распределения политик фильтрации нагрузки каждый способный SIP-объект в сети подписывается на SIP load-control пакет событий каждого SIP-объекта, которому он отправляет сигнализацию Запросы.SIP-объект, который принимает запросы на подписку, называется «уведомитель» (раздел 4.6). Подписка инициирована и поддерживается при нормальной работе сервера. Подписка соседнего SIP объекты должны быть постоянными, как описано в разделах 4.1 и 4.2. из [RFC6665]. Процедура обновления описана в разделе 4.7. ниже. Подписчики могут прекратить подписку, если они не сделали этого. получил уведомления за длительный период времени и может повторно подписаться, если они определят, что сигнализация с уведомителем снова становится активным.Пример архитектуры показан на рисунке 1, чтобы проиллюстрировать загрузку SIP. распространение политики фильтрации. Этот сценарий состоит из двух сети, принадлежащие поставщику услуг A и поставщику услуг B, соответственно. Сеть каждого провайдера состоит из двух SIP-ядер. прокси-серверы и четыре пограничных прокси-сервера SIP. Основной прокси серверы и пограничные прокси-серверы поставщика услуг A обозначаются как От CPa1 до CPa2 и от EPa1 до EPa4; основные прокси-серверы и пограничный прокси серверы поставщика услуг B обозначены как CPb1 - CPb2 и EPb1 - EPb4.+ ----------- + + ----------- + + ----------- + + ---------- - + | | | | | | | | | EPa1 | | EPa2 | | EPa3 | | EPa4 | | | | | | | | | + ----------- + + ----------- + + ----------- + + ---------- - + \ / \ / \ / \ / \ / \ / + ----------- + + ----------- + | | | | | CPa1 | ------------------ | CPa2 | | | | | + ----------- + + ----------- + | | Сервис | | Провайдер A | | | | ================================================== =============== | | Сервис | | Провайдер B | | | | + ----------- + + ----------- + | | | | | CPb1 | ------------------ | CPb2 | | | | | + ----------- + + ----------- + / \ / \ / \ / \ / \ / \ + ----------- + + ----------- + + ----------- + + ---------- - + | | | | | | | | | EPb1 | | EPb2 | | EPb3 | | EPb4 | | | | | | | | | + ----------- + + ----------- + + ----------- + + ---------- - + Рисунок 1: Пример сетевого сценария с использованием события управления нагрузкой SIP Пакетный механизм На этапе инициализации прокси-серверы сначала идентифицируют все их исходящие сигнальные соседи и подписаться на них.Услуга провайдеры могут предоставлять соседей, или прокси-серверы могут постепенно узнавайте, кто их соседи, проверяя сигнализацию сообщения, которые они отправляют и получают. Предполагая, что вся сигнализация отношения на рисунке 1 являются двунаправленными, после этого этап инициализации, каждый прокси-сервер будет подписан на все свои соседи. Случай I. EPa1 обслуживает горячую линию телепрограмм и решает ограничить общее количество входящих звонков на горячую линию во избежание перегрузки. Для этого EPa1 отправляет уведомление CPa1 по конкретной горячей линии. номер, время активации и общая допустимая скорость звонков.В зависимости от алгоритма расчета политики фильтрации нагрузки CPa1 может распределить полученную общую приемлемую скорость вызова между своими соседей, а именно EPa2, CPa2 и CPb1, и уведомить их о полученное распределение вместе с номером горячей линии и активацией время. CPa2 и CPb1 могут выполнять дальнейшее распределение между своими собственными соседей и уведомить соответствующие прокси-серверы. Этот процесс продолжается до тех пор, пока все пограничные прокси-серверы в сети не будут информированы о событии и имеют надлежащие политики фильтрации нагрузки настроен.В приведенном выше случае сетевой объект, в котором действует политика фильтрации нагрузки. впервые представлен SIP-сервер, обеспечивающий доступ к ресурсу что создает ситуацию перегрузки. В остальных случаях сеть точкой входа для внедрения политики фильтрации нагрузки также может быть сущность, на которой размещен этот ресурс. Например, оператор может разместить сервер приложений, который выполняет бесплатный номер («номер 800») службы перевода. Сам сервер приложений может быть SIP прокси-сервер или агент пользователя SIP Back-to-Back (B2BUA).Если один из бесплатные номера, размещенные на сервере приложений, создают условие перегрузки, могут быть введены политики фильтрации нагрузки с сервера приложений, а затем распространяется на другой прокси-сервер SIP серверы в сети. Случай II: Ураган поражает регион, охватываемый CPb2, EPb3 и EPb4. Все три прокси-сервера SIP перегружены. В команда спасателей определяет, что исходящие звонки более ценны, чем входящие звонки в этой конкретной ситуации. Следовательно, EPb3 и EPb4 настроены с политиками фильтрации нагрузки, чтобы принимать больше исходящих звонки, чем входящие звонки.CPb2 может быть настроен таким же образом или получать динамически вычисляемые политики фильтрации нагрузки от EPb3 и EPb4. В зависимости от алгоритма вычисления политики фильтрации нагрузки, CPb2 может также отправлять уведомления своим внешним соседям, а именно: CPb1 и CPa2, определяющие предел допустимой скорости входящих звонки в ответственный домен CPb2. CPb1 и CPa2 могут впоследствии уведомить своих соседей об ограничении звонков в зону CPb2. В тот же процесс может продолжаться до тех пор, пока все пограничные прокси-серверы не будут уведомлены и настроили политики фильтрации нагрузки.Обратите внимание, что эта спецификация не определяет инициализацию интерфейс между стороной, которая определяет политику фильтрации нагрузки и точка входа в сеть, где вводится политика. Один из параметры для интерфейса подготовки - это расширяемая разметка Язык (XML) Протокол доступа к конфигурации (XCAP) [RFC4825]. 3.4. Применимые сетевые домены Эта спецификация ДОЛЖНА применяться внутри «доверенного домена». В концепция доверенного домена аналогична той, которая определена в [RFC3324] и [RFC3325].Доверенный домен для фильтрации нагрузки SIP - это набор объектов SIP, таких как прокси-серверы SIP, которым доверяют обменять политики фильтрации нагрузки, определенные в этой спецификации. В В простейшем случае Trust Domain представляет собой сеть SIP-объектов. принадлежащий одному поставщику услуг, который его развертывает и точно знает поведение этих SIP-объектов. Такие простые доверенные домены могут быть объединены в более крупные доверенные домены по двусторонним соглашениям между поставщиками услуг субъектов SIP.Ключевое требование доверенного домена для нагрузки SIP фильтрация заключается в том, что поведение всех SIP-объектов в заданном Известно, что доверенный домен соответствует следующему набору технические характеристики. o SIP-объекты в Доверительном Домене согласовывают механизмы, используемые для защищать связь между объектами SIP в рамках Trust Домен. o SIP-объекты в Доверительном Домене согласовывают способ, используемый для определить, какие объекты SIP являются частью доверенного домена.o Сущности SIP в домене доверия соответствуют SIP [RFC3261]. o SIP-объекты в Trust Domain соответствуют SIP-Specific Уведомление о событии [RFC6665]. o Сущности SIP в домене доверия соответствуют этому Технические характеристики. o Сущности SIP в домене доверия соглашаются, какие типы вызовов могут быть затронутым этим механизмом фильтрации нагрузки SIP. Например, элементы условия (раздел 5.3.1) и может быть ограничено описанием с помощью определенных префиксов.o SIP-объекты в доверенном домене согласовывают пункты назначения для какие вызовы могут быть перенаправлены, когда действие "перенаправить" (Раздел 5.4). Например, URI может соответствовать данный набор доменов. Фильтрация нагрузки SIP эффективна только в том случае, если все соседи возможные источники сигналов участвуют и обеспечивают соблюдение назначенных политики фильтрации нагрузки. В противном случае один несоответствующий сосед может сделать все усилия по фильтрации бесполезными из-за чрезмерной перекачки трафик для перегрузки сервера.Таким образом, SIP-сервер, который распространяет политики фильтрации нагрузки, необходимые для принятия контрмер по отношению к любым неподходящим соседям. Простой способ - отказаться от чрезмерное количество запросов с ответными сообщениями 503 «Служба недоступна» как если бы они подчинялись норме. Учитывая затраты на отказ, a более сложным, но более справедливым методом было бы размещение на перегруженный сервер такой же объем обработки для комбинации как нормальная обработка, так и отклонение, поскольку перегруженный сервер посвящать обработке запросов для соответствующего вышестоящего сервера SIP.Эти подходы работают до тех пор, пока общая стоимость отказа не перегружают все ресурсы сервера. Кроме того, SIP-серверам необходимо правильно обрабатывать приоритеты сообщений при выполнении загрузки фильтрация, описанная в разделе 4.8. 4. Пакет событий управления нагрузкой Механизм фильтрации нагрузки SIP определяет пакет событий управления нагрузкой. для SIP на основе [RFC6665]. 4.1. Имя пакета событий Имя этого пакета событий - «load-control». Это имя переносится в заголовке Event и Allow-Events, как указано в [RFC6665].4.2. Параметры пакета событий Параметры поля заголовка события для конкретного пакета не определены для этот пакет мероприятий. 4.3. ПОДПИСАТЬСЯ на органы Эта спецификация не определяет содержание тел SUBSCRIBE. В будущих спецификациях могут быть определены тела для сообщений ПОДПИСАТЬСЯ, для пример, чтобы запросить определенные типы событий управления нагрузкой уведомления. Запрос SUBSCRIBE, отправленный без тела, подразумевает значение по умолчанию поведение подписки, как указано в разделе 4.7. 4.4. ПОДПИСАТЬСЯ Продолжительность Срок действия по умолчанию для подписки на фильтрацию нагрузки. политика один час.Поскольку желаемое время истечения может варьироваться значительно для подписок между SIP-объектами с разными сигнальные отношения, подписчики и уведомители РЕКОМЕНДУЕТСЯ явно согласовывать подходящую продолжительность подписки когда доступны знания о взаимных сигнальных отношениях. 4.5. УВЕДОМЛЕНИЕ о телах Тело запроса NOTIFY в этом пакете событий содержит load- политики фильтрации. Формат тела запроса NOTIFY ДОЛЖЕН быть в один из форматов, определенных в поле заголовка Accept ПОДПИСАТЬСЯ на запрос или использовать формат по умолчанию, как указано в [RFC6665].Формат данных по умолчанию для тела запроса NOTIFY этот пакет событий - «application / load-control + xml» (определен в Раздел 5). Это означает, что когда тело запроса NOTIFY существует, но нет Поле заголовка Accept указывается в запросе SUBSCRIBE, NOTIFY тело запроса ДОЛЖНО содержать контент, соответствующий "приложению / load-control + xml "формат. 4.6. Уведомляющая обработка запросов на подписку Уведомитель принимает новую подписку или обновляет существующую подписка при получении действительного запроса ПОДПИСАТЬСЯ.Если идентификатор подписчика, отправившего запрос SUBSCRIBE, не разрешено получать политики фильтрации нагрузки, уведомитель ДОЛЖЕН вернуть ответ 403 «Запрещено». Если ни один из типов носителей, указанных в заголовке Accept Поддерживаются запросы SUBSCRIBE, уведомитель ДОЛЖЕН вернуть 406 "Неприемлемый" ответ. 4.7. Уведомление Генерация запросов NOTIFY Уведомитель ДОЛЖЕН отправить запрос NOTIFY с его текущей фильтрацией нагрузки. политики для подписчика после успешного принятия или обновления подписка.Если не нужно распространять политику фильтрации нагрузки когда подписка получена, уведомителю СЛЕДУЕТ отправить УВЕДОМЛЕНИЕ запрос без тела к подписчику. Заголовок типа содержимого поле этого запроса NOTIFY ДОЛЖНО указывать правильный формат тела как если тело присутствовало (например, "application / load-control + xml"). Уведомители могут отправлять запросы NOTIFY без тела, когда подписка инициируется впервые, например, когда объект SIP просто вводится, потому что не может быть запланированных событий, которые требуется фильтрация нагрузки в это время.Уведомитель ДОЛЖЕН генерировать NOTIFY запрашивает каждый раз при изменении политики фильтрации нагрузки с максимальная частота уведомлений, не превышающая значений, определенных в Раздел 4.10. 4.8. Подписчик Обработка запросов NOTIFY Подписчик - это сервер фильтрации нагрузки, который обеспечивает выполнение нагрузки. политики фильтрации, полученные от уведомителя. Путь подписчиков обработка запросов NOTIFY зависит от политик фильтрации нагрузки передается в уведомлениях. Обычно политики фильтрации нагрузки состоят из правил, определяющих действия, которые будут применяться к запросам соответствие определенным условиям.Подписчик получает уведомление сначала устанавливает эти правила, а затем применяет соответствующие действия к запросы, соответствующие этим условиям, например, ограничение отправки скорость запросов на вызов, предназначенных для конкретного вызываемого абонента. В случае, когда политики фильтрации нагрузки указывают срок действия в будущем, возможно, что по истечении срока действия подписка конкретному уведомителю, который передал правила, истек. В в этом случае РЕКОМЕНДУЕТСЯ, чтобы подписчик повторно активировал свой подписка с соответствующим уведомителем.Несмотря на погоду или нет, повторная активация подписки успешна, когда срок действия истек, подписчик ДОЛЖЕН обеспечить соблюдение соответствующие правила. При получении запроса NOTIFY с заголовком Subscription-State поле, содержащее значение «прекращена», статус подписки с действие конкретного уведомителя будет прекращено. Между тем, подписчики ДОЛЖЕН также прекратить действие ранее полученных политик фильтрации нагрузки от этот уведомитель. Абонент ДОЛЖЕН отказаться от неизвестных тел.Если запрос NOTIFY содержит несколько тел, ни один из которых не поддерживается, ДОЛЖЕН отказаться от подписки, если он не знает, что он, возможно, получит NOTIFY запросы с поддерживаемыми телами от этого уведомителя. УВЕДОМЛЕНИЕ запрос без тела означает, что политика фильтрации нагрузки не требуется. быть обновленным. Когда подписчик применяет политики фильтрации нагрузки, он должен расставьте приоритеты запросов и выберите те запросы, которые необходимо отклонено или перенаправлено. Этот выбор во многом зависит от местных политика.Ожидается, что подписчик будет следовать местной политике. пока результат сокращения трафика соответствует алгоритм перегрузки, действующий на этом узле. Соответственно, нормативное поведение, описанное в следующих трех параграфах, должно быть интерпретируется с пониманием того, что подписчик будет стремиться максимально сохранить местную политику. o Абонент ДОЛЖЕН соблюдать локальную политику приоритизации SIP. запросы, такие как политики, основанные на типе сообщения, e.г., ПРИГЛАШАЕТ по сравнению с запросами, связанными с существующими сеансами. o Абонент ДОЛЖЕН соблюдать локальную политику приоритизации SIP. запросы на основе содержимого заголовка Resource-Priority (RPH, [RFC4412]). Конкретное (namespace.value) содержимое RPH может указать высокоприоритетные запросы, которые должны быть сохранены по возможности при перегрузке. Содержимое RPH также может указывать на запрос с низким приоритетом, который может быть отброшен в разное время перегрузки.o Абонент ДОЛЖЕН соблюдать локальную политику приоритизации SIP. запросы, связанные с вызовами службы экстренной помощи, как указано в SOS URN [RFC5031], указывающий на экстренный запрос. Можно ожидать, что локальная политика объединит оба типа запроса SIP. и отметки приоритета и ДОЛЖНЫ соблюдаться при перегрузке условия преобладают. 4.9. Обработка разветвленных запросов Разветвление не применимо, когда этот пакет событий управления нагрузкой механизм используется в пределах односкачкового расстояния между соседними SIP-сущности.Если область связи события управления нагрузкой пакетный механизм находится среди нескольких переходов, разветвление также не ожидается, потому что запрос на подписку адресован четко определенный объект SIP. Однако в маловероятном случае, когда разветвление действительно происходит, пакет событий управления нагрузкой разрешает только первое потенциальное сообщение об установлении диалога для создания диалога, как указано в разделе 5.4.9 [RFC6665]. 4.10. Скорость уведомлений Частота уведомлений вряд ли вызовет беспокойство для этого местного механизм пакета событий управления, когда он используется не в реальном времени режим для относительно статических политик фильтрации нагрузки.Тем не менее, если действительно возникает ситуация, когда довольно часто используемая нагрузка необходимо обновление политики фильтрации, РЕКОМЕНДУЕТСЯ, чтобы уведомитель не генерирует уведомления с частотой более одного раза за второй во всех случаях, чтобы избежать самого запроса NOTIFY перегрузка системы. 4.11. Государственная Дельта Вероятно, что обновления определенных политик фильтрации нагрузки сделано путем изменения только части параметров политики (например, приемлемый частота запросов или процент, но не совпадающие личности).Это будет обычно из-за того, что использование ресурса зависит от перегрузка зависит от динамических неизвестных, таких как время выдержки и относительное распределение предлагаемых нагрузок по подписывающимся SIP-объектам. Обновления могут исходить вручную или определяться автоматически. с помощью алгоритма, который динамически вычисляет политики фильтрации нагрузки (Раздел 3.2). Другой фактор, который обычно точно не известен, или необходимо вычислять автоматически - продолжительность события требующие фильтрации нагрузки.Следовательно, это также было бы обычным для срок действия часто меняется. Этот пакет событий позволяет использовать дельту состояний, как в [RFC6665], чтобы приспосабливать частые обновления частичных параметров политики. Для каждого NOTIFY транзакции в подписке, номер версии увеличивается ровно на один ДОЛЖЕН быть включен в тело запроса NOTIFY, когда тело присутствует. Когда подписчик получает дельту состояния, он связывает частичные обновления с конкретной политикой путем сопоставления соответствующий идентификатор правила (Приложение D).Если подписчик получает Запрос NOTIFY с номером версии, увеличенным более чем на один, он знает, что он пропустил дельту состояния и должен запросить полный снимок состояния. Таким образом, подписчик игнорирует сообщение NOTIFY запрос, содержащий дельту состояния, и повторно отправляет запрос SUBSCRIBE для принудительного выполнения запроса NOTIFY, содержащего полный снимок состояния. 5. Документ по контролю нагрузки 5.1. Формат Документ управления нагрузкой - это документ XML, описывающий нагрузку. политики фильтрации.Он наследует и усиливает общую политику документ, определенный в [RFC4745]. Документ общей политики содержит список правил. Каждое правило состоит из трех частей: условия, действия и преобразования. Часть условий представляет собой набор выражения, содержащие такие атрибуты, как личность, домен и информация о сроках действия. Каждое выражение оценивается как ИСТИНА или ЛОЖНЫЙ. Условия подбираются по стилю "равенство" или "больше чем" сравнение. Соответствие регулярному выражению отсутствует.Условия оценивается при получении начального SIP-запроса для диалога или автономная транзакция. Если запрос соответствует всем условиям в набор правил, часть действия и часть преобразования консультируются чтобы определить «разрешение» на обработку запроса. Каждый действие или преобразование указывает положительное предоставление политики сервер для выполнения результирующих действий. Четко определенный механизм доступны для комбинирования действий и преобразований, полученных из более одного источника.5.2. Пространство имен URI пространства имен для элементов, определенных в этой спецификации, является Единое пространство имен ресурсов (URN) ([RFC2141]) с использованием пространства имен идентификатор "ietf", определенный [RFC2648] и расширенный [RFC3688]. URN выглядит следующим образом: urn: ietf: params: xml: ns: load-control 5.3. Условия [RFC4745] определяет три элемента условия: , и <действительность>. Эта спецификация определяет новые элементы условия и повторно использует элемент .Элемент не используется. 5.3.1. Идентификация вызова Поскольку проблемное пространство данной спецификации отличается от этого из [RFC4745], элемента [RFC4745] недостаточно для использовать с фильтрацией нагрузки. Во-первых, фильтрация нагрузки может применяться к различные идентификаторы, содержащиеся в запросе, включая идентификаторы как получатель, так и отправляющий объект. Во-вторых, важность аутентификации меняется, когда разные идентификаторы просьба обеспокоены.Эта спецификация определяет новую идентичность условия, которые могут учитывать степень детализации конкретного SIP поля заголовка идентификатора. Требование аутентификации зависит от на каком поле должно быть сопоставлено. Условие идентичности для фильтрации нагрузки задается Элемент и его подэлемент . Элемент сам содержит подэлементы, представляющие отправку и получение SIP поля заголовка идентификатора: , , и.Все эти подэлементы относятся к расширенному форма элемента [RFC4745] . В дополнение к суб- элементы, включая , и в элемент из [RFC4745], расширенная форма добавляет два новых подэлемента, а именно, и , которые будут объяснены позже в эта секция. Элементы [RFC4745] и могут содержать "id". атрибут, который представляет собой URI отдельного объекта, который нужно включить, или исключен из условия.При использовании в , , и, это значение "id" URI, содержащийся в соответствующем поле заголовка SIP, то есть From, To, Request-URI и P-Asserted-Identity. Когда элемент содержит несколько суб- элементов, результат объединяется с помощью логического ИЛИ. Когда <от>, Элементы , и содержат несколько субэлементов , или , результатом будет также объединены с использованием логического ИЛИ.Когда подэлемент дальше содержит один или несколько подэлементов , или когда подэлемент дополнительно содержит один или несколько подэлементов , результат каждого подэлемента или объединяется с использованием логического ИЛИ, аналогичного [RFC4745] элемент. Однако, когда элемент содержит несколько , Подэлементы , и, результат объединяется с помощью логического И.Это позволяет идентифицировать вызов должно быть указано несколькими полями SIP-запроса одновременно, например, поля заголовка From и To. Ниже показан пример элемента , который соответствует запросам на вызов, чье поле заголовка To содержит SIP URI "sip: [email protected]" или URI "tel" «тел: + 1-212-555-1234». <один /> <один /> Перед оценкой условий абонент должен преобразовать URI, полученные в полях заголовка SIP, в каноническую форму согласно [RFC3261], за исключением того, что параметр "phone-context" не должен быть удалено, если есть.Элементы [RFC4745] и могут иметь "домен" атрибут. Атрибут "domain" определяет доменное имя, которое будет соответствует доменной части идентичности кандидата. Таким образом, это позволяет сопоставить большое и, возможно, неизвестное количество объектов внутри домена. Атрибут «домен» хорошо подходит для SIP URI. Однако URI, идентифицирующий пользователя SIP, также может быть URI «tel». Следовательно, необходим аналогичный способ сопоставления группы URI «tel». Существует две формы URI "tel": для глобальных номеров и для локальных номеров. числа.Согласно [RFC3966], «Все номера телефонов ДОЛЖНЫ использовать глобальная форма, если они не могут быть представлены как таковые ... Местные числа ДОЛЖЕН быть помечен тегом 'phone-context' ". Глобальный номер URI 'tel' начинать с "+". Параметр "phone-context" местных номеров может быть помеченным как глобальное число или любое количество его первых цифр или доменное имя. Обе формы URI 'tel' делают результирующий URI глобально уникальный. 'tel' URI глобальных номеров могут быть сгруппированы по префиксам, состоящим из любое количество общих ведущих цифр.Например, префикс, образованный код страны или код страны и города идентифицируют телефон числа в пределах страны или области. Поскольку длина страны и код города для разных регионов различаются, длина префикс номера тоже различается. Это обеспечивает дополнительную гибкость, такую как группирование номеров по подобластям в пределах одного кода зоны. "тел" URI местных номеров можно сгруппировать по значению параметр "phone-context". Подэлементы и в элементе [RFC4745] не позволяют добавлять дополнительные атрибуты напрямую.Переопределение поведения их существующего атрибута "домена" создает проблемы обратной совместимости. Следовательно, эта спецификация определяет подэлементы и , которые расширяют [RFC4745] элемент . Оба они имеют атрибут «префикс». для группировки URI "tel", аналогично атрибуту "домен" для группировка SIP URI в существующих подэлементах и . Для глобальные числа, значение атрибута "префикс" содержит любое количество общие начальные цифры, например "+ 1-212" для телефонных номеров в США. в пределах кода города "212" или "+ 1-212-854" для организаций с США код города «212» и местный префикс «854».Для местных номеров значение атрибута "prefix" содержит параметр "phone-context" ценить. Следует отметить, что визуальные разделители (например, "-" sign) в URI 'tel' не используются для сравнения URI согласно [RFC3966]. В следующем примере показано использование атрибута «префикс» вместе с с атрибутом «домен». Он соответствует тем запросам, которые обращаются к номер «+ 1-202-999-1234», но не звонки с «+ 1-212» префикс или домен SIP From URI "manhattan.example.com ". <от> <многие> <один /> 5.3.2. Метод Нагрузка, создаваемая на SIP-сервере, зависит от типа начального SIP. запросы на диалоги или автономные транзакции. <Метод> определяет метод SIP, для которого выполняется фильтрация нагрузки. применяется. Когда этот элемент не включен, фильтрация нагрузки действия применимы ко всем применимым начальным запросам. Эти запросы включают ПРИГЛАШЕНИЕ, СООБЩЕНИЕ, РЕГИСТРАЦИЯ, ПОДПИСАТЬСЯ, ОПЦИИ и ПУБЛИКОВАТЬ. Не начальные запросы, такие как ACK, BYE и CANCEL, НЕ ДОЛЖНЫ подвергаться нагрузочной фильтрации.Кроме того, запросы SUBSCRIBE не фильтруется, если поле заголовка типа события указывает на событие пакет, определенный в этой спецификации. В следующем примере показано использование элемента в в случае, если фильтрующие действия должны применяться к запросам INVITE. ПРИГЛАСИТЬ 5.3.3. Целевая сущность SIP Сервер SIP, выполняющий фильтрацию нагрузки, может иметь несколько путей к запросы на маршрутизацию, соответствующие одному и тому же набору элементов идентификации вызова.В таких ситуациях серверу фильтрации нагрузки SIP может потребоваться преимущество альтернативных путей и применение только действий фильтрации нагрузки для сопоставления запросов для объекта SIP следующего перехода, который инициировал соответствующая политика фильтрации нагрузки. Для этого загрузка SIP- серверу фильтрации необходимо связать каждую политику фильтрации нагрузки с исходный объект SIP. Элемент определен для этой цели, и он содержит URI объекта, который инициировал политику фильтрации нагрузки, которая обычно соответствующий уведомитель.Уведомитель МОЖЕТ включить этот элемент как часть условия его политики фильтрации, отправляемой в подписчик, как показано ниже. sip: biloxi.example.com Когда сервер фильтрации нагрузки SIP получает политику с элемент , он ДОЛЖЕН записать его и поместить в учет при принятии решений по фильтрации нагрузки. Если нагрузка- сервер фильтрации получает политику фильтрации нагрузки, которая не содержат элемент , он МОЖЕТ записывать URI инициатор политики фильтрации нагрузки как информацию и учитывайте ее при принятии решений по фильтрации нагрузки.Ниже приведены два примера использования элемент. Вариант использования I. В сети есть пользователь A, подключенный к SIP Proxy 1 (SP1), пользователь B подключен к SIP Proxy 3 (SP3), SP1 и SP3 подключен через SIP Proxy 2 (SP2) и SP2, подключенные к серверу приложений (В КАЧЕСТВЕ). В условиях нормальной нагрузки вызов от A к B направляется по следующему пути: A-SP1-SP2-AS-SP3-B. AS предоставляет несущественное обслуживание и может быть отменено в случае перегрузки.Теперь предположим, что AS перегружена и отправляет SP2 нагрузку. политика фильтрации, требующая, чтобы 50% всех запросов INVITE были упавший. SP2 может поддерживать AS в качестве для этого политика, чтобы он знал, что действие сброса 50% применимо только к запросы вызова, которые должны проходить через AS, не затрагивая те вызовы напрямую маршрутизируются через SP3 на B. Пример использования II. Служба перевода для бесплатных номеров - это установлен на двух серверах приложений, AS1 и AS2.Пользователь А подключен к SP1 и звонит 800-1234-4529, что переводится AS1 и AS2 в обычный номер E.164 в зависимости, например, от местонахождение звонящего. SP1 пересылает запросы INVITE с Request-URI = «Номер 800» для AS1 или AS2 в зависимости от стратегии балансировки нагрузки. Поскольку вызовы 800-1234-4529 создают состояние предварительной перегрузки в AS1, AS1 отправляет SP1 политику фильтрации нагрузки, запрашивающую, что 50% звонки на 800-1234-4529 будут отклонены. В этом случае SP1 может поддерживать AS1 как для правила, и только применять политику фильтрации нагрузки к входящим запросам, которые предназначен для отправки в AS1.Те запросы, которые отправляются в AS2, несмотря на соответствие фильтра, не будет затронутый. 5.3.4. Срок действия Политика фильтрации обычно связана со сроком действия. состояние. В этой спецификации повторно используется элемент из [RFC4745], в котором срок действия определяется парами Подэлементы и . Когда несколько периодов времени определено, условие достоверности оценивается как ИСТИНА, если текущее время попадает в любой из указанных периодов времени.То есть это представляет собой операцию логического ИЛИ для всех периодов действия. В следующем примере показан элемент , указывающий допустимый период с 12:00 до 15:00 по восточноевропейскому стандартному времени 31 мая 2008 года. <действительность> 2008-05-31T12: 00: 00-05: 00 2008-05-31T15: 00: 00-05: 00 5.4. Действия Действия, которые сервер фильтрации нагрузки выполняет с нагрузками, соответствующими нагрузке: Условия фильтрации определяются элементом в load- политика фильтрации, которая включает любой из трех подэлементов <ставка>, <процент> и <выигрыш>.Элемент обозначает абсолютное значение максимально допустимой скорости запросов в запросах в секунду; элемент указывает относительный процент входящих запросы, которые следует принимать; элемент описывает приемлемый размер окна, предоставляемый приемником, который применим в оконной фильтрации нагрузки. В статической политике фильтрации нагрузки сценарии конфигурации, РЕКОМЕНДУЕТСЯ использовать подэлемент потому что трудно обеспечить процентную ставку или оконную фильтрация нагрузки при поступлении нагрузки от восходящего потока или реакции от ниже по течению сомнительны.(Подробнее см. [SIP-OVERLOAD] и [RFC6357]. подробные сведения об управлении нагрузкой на основе скорости, потерь и окон.) Кроме того, элемент принимает необязательное «альтернативное действие». атрибут, который можно использовать для явного указания желаемого действия в случае, если запрос не может быть обработан. "Альтернативное действие" может занять одно из следующих трех значений: «отклонить», «перенаправить» или «отбросить». o Действие «отклонить» является значением по умолчанию для «альтернативного действия». Это означает, что сервер фильтрации нагрузки отклонит запрос с ответное сообщение 503 «Служба недоступна».o Действие "перенаправить" означает перенаправление запроса другому цель. Когда он используется, атрибут "alt-target" ДОЛЖЕН быть определенный. "Alt-target" указывает один URI или список URI. куда следует перенаправить запрос. Сервер отправляет перенаправить URI в ответном сообщении класса 300. o Действие "отбросить" означает просто игнорировать запрос без выполнения что угодно, что в определенных случаях может помочь сохранить обработку возможность при перегрузке.Например, когда SIP перегружен надежный транспорт, такой как TCP, действие "drop" не отправляет нет ответа на отказ, и он не закрывает транспорт связь. Однако при запуске SIP через ненадежный транспорт, такой как UDP, с помощью действия "drop" будет создано сообщение повторные передачи, которые еще больше усугубляют возможную перегрузку ситуация. Таким образом, любое действие "сброса", примененное к ненадежному транспорт ДОЛЖЕН рассматриваться как "отклоненный".Вышеупомянутая обработка "альтернативного действия" также может быть проиллюстрирована с помощью следующий псевдокод. ПЕРЕКЛЮЧАТЕЛЬ "альт-действие" "перенаправить": "перенаправить" "уронить": ЕСЛИ ненадежный транспорт ТО рассматривайте как "отклонить" ЕЩЕ "уронить" "отклонить": "отклонить" по умолчанию: "отклонить" КОНЕЦ В следующем примере элемента сервер принимает максимум 100 запросов на вызов в секунду.Остальные звонки перенаправлен на автоответчик. <действия> 100 6. Определение схемы XML для управления нагрузкой В этом разделе определяется схема XML для документа управления загрузкой. Он расширяет схему Common Policy в [RFC4745] двумя способами. Во-первых, он определяет два обязательных атрибута для элемент: «версия» и «состояние».Атрибут "версия" позволяет получатель уведомления правильно их заказывает. Версии запускаются на ноль и увеличиваться на единицу для каждого нового документа, отправленного в подписчик в рамках той же подписки. Версии ДОЛЖНЫ быть может быть представлен с использованием неотрицательного 32-битного целого числа. Штат" атрибут указывает, содержит ли документ полную загрузку- обновление политики фильтрации или только изменение состояния как частичное обновление. Во-вторых, он определяет новые члены и элементы. 7.Соображения безопасности Из этой спецификации вытекают два основных соображения безопасности. Один из них - это механизм распределения для политики фильтрации нагрузки, которая основан на структуре уведомлений о событиях SIP, а другой - механизм применения политики фильтрации нагрузки. Рассмотрены вопросы безопасности для механизмов пакетов событий SIP. в разделе 6 [RFC6665]. Особо актуальная проблема безопасности для этого пакета событий заключается в том, что если уведомители могут быть подделаны, злоумышленники могут отправлять поддельные уведомления с просьбой к подписчикам задушить весь трафик, ведущий к атакам типа «отказ в обслуживании» (DoS).Следовательно, этот механизм фильтрации нагрузки SIP ДОЛЖЕН использоваться в Trust Domain (Раздел 3.4). Но если законный уведомитель в домене доверия сам скомпрометирован, потребуются дополнительные механизмы для обнаружения атака. Соображения безопасности при применении политики фильтрации нагрузки зависят от очень много о содержании политики. Эта спецификация определяет возможное совпадение следующих полей заголовка SIP в загрузке политика фильтрации: , , и.Точное требование для аутентификации и авторизация этих полей зависит от поставщика услуг. В общем, если поле идентификатора представляет источник запроса, оно ДОЛЖНО быть аутентифицированы и авторизованы; если поле идентичности представляет место назначения запроса, аутентификация и авторизация по желанию. Кроме того, действие "перенаправления" (раздел 5.4) может облегчить отражение отказа в обслуживании. Если номер SIP прокси серверы в доверенном домене используют UDP и настроены для получения своих политики с центрального сервера.Злоумышленник подделывает центральный адрес сервера для отправки нескольких тел NOTIFY, сообщающих прокси серверы для перенаправления всех вызовов на почту жертвы@outside-of-trust-domain.com. Затем прокси-серверы перенаправляют все вызовы жертве, которая затем становится жертвой атаки отказа в обслуживании и становится недоступен из Интернета. Чтобы устранить этот тип угроз, эта спецификация требует, чтобы доверенный домен согласовал, какие типы звонков могут быть затронуты, а также на направлениях, в которые звонки могут быть переадресованы, как в Разделе 3.4. 8. Соображения IANA Эта спецификация регистрирует пакет событий SIP, новый тип носителя, новое пространство имен XML и новая схема XML. 8.1. Регистрация пакета событий управления нагрузкой В этом разделе регистрируется пакет событий на основе регистрации процедуры, определенные в [RFC6665]. Название пакета: load-control Тип: пакет Опубликованная спецификация: Настоящая спецификация Контактное лицо: Чарльз Шен, [email protected] 8.2. application / load-control + xml Регистрация типа носителя В этом разделе регистрируется новый тип носителя на основе процедур определено в [RFC6838] и рекомендациях в [RFC3023].Название типа: приложение Имя подтипа: load-control + xml Обязательные параметры: нет Необязательные параметры: такие же, как параметр charset в application / xml как указано в [RFC3023]. Рекомендации по кодированию: такие же, как и рекомендации по кодированию application / xml, как указано в [RFC3023]. Соображения безопасности: см. Раздел 10 [RFC3023] и раздел 7 документа эта спецификация. Соображения по совместимости: нет Опубликованная спецификация: Настоящая спецификация Приложения, использующие этот тип носителя: приложения, выполняющие загрузку контроль SIP-сущностей.Замечания по идентификатору фрагмента: то же, что и идентификатор фрагмента соображения application / xml, как указано в [RFC3023]. Дополнительная информация: Устаревшие псевдонимы для этого типа: нет Магический номер (а): нет Расширения файлов: .xml Код (ы) типа файлов для Macintosh: "ТЕКСТ" Лицо и адрес электронной почты для получения дополнительной информации: Чарльз Шен, [email protected] Предполагаемое использование: ОБЩИЕ Ограничения на использование: нет Авторы: Чарльз Шен, Хеннинг Шульцринне, Арата Койке Сменить контроллер: IESG Временная регистрация? (только дерево стандартов): нет 8.3. Регистрация подпространства имен URN В этом разделе регистрируется новое пространство имен XML в соответствии с рекомендациями в [RFC3688] URI: URI для этого пространства имен urn: ietf: params: xml: ns: load-control Контактное лицо для регистранта: рабочая группа IETF SOC , как указано IESG XML: НАЧИНАТЬ Пространство имен управления загрузкой SIP
Пространство имен для управления нагрузкой SIP
urn: ietf: params: xml: ns: load-control
См. RFC 7200 .
КОНЕЦ 8.4. Регистрация схемы управления нагрузкой URI: urn: ietf: params: xml: schema: load-control Контактное лицо для регистранта: рабочая группа IETF SOC, Чарльз Шен ([email protected]). XML: схема XML, содержащаяся в разделе 6, была зарегистрирована. Его первая строка и его последняя строка 9. Благодарности Авторы выражают благодарность Яри Аркко, Ричарду Барнсу, Стюарту. Брайант, Гонсало Камарильо, Бруно Шатрас, Бенуа Клез, Спенсер Докинз, Мартин Долли, Кейт Драге, Ашутош Датта, Дональд Истлейк, Адриан Фаррел, Стивен Фаррелл, Джанет Ганн, Виджей Гурбани, Брайан Хаберман, Фолькер Хилт, Джефф Хант, Кэролайн Джонсон, Хадриэль Каплан, Пол Кизиват, Барри Лейба, Перл Лян, Сальваторе Лорето, Тимоти Моран, Эрик Ноэль, Партасарати Р., Пит Резник, Адам Роуч, Дэн Ромаскану, Шида Шуберт, Роберт Спаркс, Мартин Штимерлинг, Шон Тернер, Фил Уильямс и другие члены SOC и SIPPING рабочие группы за множество полезных комментариев.В частности, Бруно Чатрас предложил условие и элементы наряду со многими другими улучшениями текста. Джанет Ганн предоставил подробные текстовые предложения, включая Приложение C. Эрик Ноэль предложено разъяснение по распределению политики фильтрации нагрузки процесс инициализации. Шида Шуберт внесла много предложений, таких как использование терминологии. Фил Уильямс предложил добавить поддержку дельты обновления. Ашутош Датта указал на телефонную связь общего пользования Сетевые (PSTN) ссылки.Адам Роуч предложил улучшения, связанные с в RFC 6665 и другие полезные пояснения. Ричард Барнс сделал много предложений, таких как ссылка на концепцию Trust Domain RFC 3324 и 3325, использование отдельного элемента для URI 'tel' группировка и устранение угрозы безопасности действий «перенаправление». 10. Ссылки 10.1. Нормативные ссылки [RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для обозначения Уровни требований », BCP 14, RFC 2119, март 1997 г.[RFC2141] Моутс, Р., «Синтаксис URN», RFC 2141, май 1997 г. [RFC3023] Мурата, М., Сен-Лоран, С., и Д. Кон, "XML Media Типы », RFC 3023, январь 2001 г. [RFC3261] Розенберг, Дж., Шульцринн, Х., Камарилло, Г., Джонстон, А., Петерсон, Дж., Спаркс, Р., Хэндли, М. и Э. Школьник, "SIP: протокол инициации сеанса", RFC 3261, Июнь 2002 г. [RFC3688] Миллинг, М., «Реестр XML IETF», BCP 81, RFC 3688, Январь 2004 г.[RFC3966] Шульцринн, Х., "URI телефона для телефонных номеров", RFC 3966, декабрь 2004 г. [RFC4745] Шульцринн, Х., Чофениг, Х., Моррис, Дж., Куэльяр, Дж., Полк, Дж. И Дж. Розенберг, «Общая политика: документ Формат для выражения предпочтений конфиденциальности », RFC 4745, Февраль 2007 г. [RFC6665] Roach, A., «Уведомление о событиях, связанных с протоколом SIP», RFC 6665, Июль 2012 г. [RFC6838] Фрид, Н., Кленсин, Дж., И Т. Хансен, "Тип носителя" Спецификации и процедуры регистрации », BCP 13, RFC 6838, январь 2013 г.10.2. Информативные ссылки [E.300SerSup3] ITU-T, "Североамериканский план точных звуковых сигналов", Дополнение 3 к Рекомендации серии E.300, ноябрь 1988 г. [E.412] ITU-T, "Средства управления сетевым управлением", Рекомендация. E.412-2003, январь 2003 г. [Q.1248.2] ITU-T, "Рекомендации по интерфейсам для интеллектуальной сети. Набор возможностей 4: интерфейс SCF-SSF ", Рекомендация Q.1248.2, июль 2001 г. [RFC2648] Моутс, Р., «Пространство имен URN для документов IETF», RFC 2648, Август 1999 г.[RFC3324] Уотсон, М., «Утвержденные краткосрочные требования к сети. Идентификация », RFC 3324, ноябрь 2002 г. [RFC3325] Дженнингс, К., Петерсон, Дж. И М. Уотсон, "Частный Расширения протокола инициации сеанса (SIP) для Подтвержденная идентификация в надежных сетях », RFC 3325, Ноябрь 2002 г. [RFC4412] Шульцринн, Х. и Дж. Полк, "Ресурсы связи Приоритет для протокола инициации сеанса (SIP) », RFC 4412, февраль 2006 г.[RFC4825] Розенберг, Дж., "Расширяемый язык разметки (XML) Протокол доступа к конфигурации (XCAP) », RFC 4825, май 2007 г. [RFC5031] Шульцринн, Х., "Унифицированное имя ресурса (URN) для Экстренные и другие общеизвестные услуги », RFC 5031, Январь 2008 г. [RFC5390] Розенберг Дж. «Требования к управлению перегрузкой в протокол инициации сеанса », RFC 5390, декабрь 2008 г. [RFC6357] Хилт В., Ноэль Э., Шен К. и А.Абделал, "Дизайн" Рекомендации по протоколу инициации сеанса (SIP) Контроль перегрузки », RFC 6357, август 2011 г. [ПЕРЕГРУЗКА SIP] Гурбани, В., Эд., Хилт, В., и Х. Шульцринн, "Сессия Протокол инициации (SIP) Overload Control », Работа в Прогресс, март 2014 г. Приложение А. Определения В этой спецификации повторно используются определения для «Пакет событий», «Уведомление», «Уведомитель», «Подписчик» и «Подписка», как в [RFC6665].Также используются следующие дополнительные определения. Фильтрация нагрузки: механизм управления нагрузкой, который применяет определенные действия с выбранными нагрузками (например, SIP-запросы), соответствующие определенным условия. Политика фильтрации нагрузки: набор из нуля или более правил фильтрации нагрузки, также известный как набор правил фильтрации нагрузки. Правило фильтрации нагрузки: условия и действия, применяемые к нагрузке фильтрация. Условие фильтрации нагрузки: элементы, описывающие, как выбирать нагрузки. применить действия по фильтрации нагрузки.Эта спецификация определяет , , и элементы состояния (раздел 5.3). Действие фильтрации нагрузки: операция, выполняемая при фильтрации нагрузки. сервер при нагрузках, соответствующих условиям фильтрации нагрузки. Этот спецификация разрешает такие действия, как принятие, отклонение и перенаправление нагрузок (раздел 5.4). Сервер фильтрации нагрузки: сервер, выполняющий фильтрацию нагрузки. В В контексте данной спецификации сервер фильтрации нагрузки подписчик, который получает политики фильтрации нагрузки от notifier и применяет эти политики во время фильтрации нагрузки.Документ управления нагрузкой: XML-документ, описывающий нагрузку. политики фильтрации (раздел 5). Он наследует и усиливает документ общей политики, определенный в [RFC4745]. Приложение Б. Требования к конструкции Механизм фильтрации нагрузки SIP должен удовлетворять следующим требованиям: требования: o Для простоты решение должно быть сосредоточено на методе контроль нагрузки SIP, а не общий прикладной уровень механизм. o Политика фильтрации нагрузки должна быть эффективно распределена по возможно большое подмножество всех элементов SIP.o Решение должно повторно использовать существующие механизмы протокола SIP для снизить сложность внедрения и развертывания. o Для предсказуемых ситуаций перегрузки, таких как праздники и массовые вызывающих событий, политика фильтрации нагрузки должна указывать во время в какое время его применять, чтобы информация могла быть распространен досрочно. o Для ситуаций перегрузки, специфичных для пункта назначения, фильтрация нагрузки политика должна описывать целевой домен или вызываемый.o Для устранения случайных и преднамеренных генераторов большого количества вызовов, политика фильтрации нагрузки должна иметь возможность указывать вызывающего абонента. o Вызывающий и вызываемый абоненты должны быть указаны как SIP URI и 'tel'. URI [RFC3966] в политиках фильтрации нагрузки. o Должна быть возможность указать конкретную информацию в SIP заголовки (например, префиксы в телефонных номерах), которые позволяют загружать фильтрация по ограниченным перегрузкам, ориентированным на регион. o Решение должно основываться на опыте связанных PSTN механизмы [Q.1248.2] [E.412] [E.300SerSup3], если применимо. o Решение должно быть расширяемым для удовлетворения будущих потребностей. Приложение C. Обсуждение соответствия данной спецификации требованиям RFC 5390 В этом разделе оценивается, является ли пакет событий управления нагрузкой механизм, определенный в этой спецификации, удовлетворяет различным SIP требования к управлению перегрузкой, изложенные в [RFC5390]. Как уже упоминалось в Разделе 1 эта спецификация дополняет другие усилия по общее пространство для решения SIP по управлению нагрузкой.Следовательно, не все RFC 5390 признаны применимыми к данной спецификации. Этот В спецификации результаты оценки классифицируются как Да ( требование выполнено), P / A (частично применимо), Нет (необходимо использовать в в сочетании с другим механизмом для удовлетворения требований) и N / A (Непригодный). REQ 1: Механизм перегрузки должен стремиться поддерживать общую полезная пропускная способность (с учетом качества сервисные потребности использующих приложений) SIP-сервера в разумные уровни, даже когда входящая нагрузка на сеть намного превышает его возможности.Общая пропускная способность под нагрузкой является окончательной мерой величины защиты от перегрузки. механизм. P / A. Цель фильтрации нагрузки - предотвратить перегрузку или поддержать общая полезная мощность во время перегрузки, но она зависит от прогнозы нагрузки и расчеты, а также распространение политик фильтрации. Если прогнозы нагрузки или вычисления политики фильтрации неверны, или политика фильтрации неправильно распределен, механизм будет менее эффективным.С другой стороны, если можно точно спрогнозировать нагрузку и политики фильтрации должны быть рассчитаны и распределены соответствующим образом, это требование может быть выполнено. REQ 2: Когда один элемент сети выходит из строя, переходит в состояние перегрузки или страдает пониженной производительностью обработки, механизм должен стремиться ограничить влияние этого на другие элементы в сеть. Это помогает предотвратить мелкомасштабный отказ от становится повсеместным отключением. Н / Д, если политики фильтрации нагрузки установлены заранее и не изменение во время периода потенциальной перегрузки, P / A, если фильтрация нагрузки политики динамически корректируются.Алгоритм динамического вычисление политик фильтрации нагрузки выходит за рамки этого спецификация, а раздача обновленной фильтрации policy использует механизм пакетов событий, описанный в этой спецификации. REQ 3: Механизм должен стремиться минимизировать количество конфигурация, необходимая для работы. Например, это лучше избегать необходимости настраивать сервер с его SIP-сообщением пропускная способность, поскольку такие количества трудно определить.Нет. Этот механизм полностью зависит от предварительной настройки, на основе предварительных знаний. Чтобы удовлетворить REQ 3, он должен быть используется совместно с другими механизмами, не основанными на предварительная конфигурация. REQ 4: Механизм должен иметь возможность работать с элементами, которые не поддерживают его, поэтому сеть может состоять из смеси элементы, которые поддерживают и не поддерживают его. Другими словами, механизм не должен работать только в средах, где все элементы поддержите это.Разумно предположить, что он лучше работает в такие среды, конечно. В идеале должно быть постепенное улучшение общей пропускной способности сети по мере все большее количество элементов в сети поддерживает механизм. Нет. Этот механизм полностью зависит от участия всех возможные соседи. Чтобы удовлетворить REQ 4, его следует использовать в в сочетании с другими механизмами, некоторые из которых описаны в Раздел 3.4. REQ 5: Механизм не должен предполагать, что он будет только развернуты в средах с полностью доверенными элементами.Это должны стремиться работать как можно более эффективно в окружающей среде где другие элементы являются вредоносными; это включает предотвращение вредоносные элементы от получения более чем справедливой доли услуга. Нет. Этот механизм полностью зависит от не вредоносных участие всех возможных соседей. Чтобы удовлетворить REQ 5, его следует использовать вместе с другими механизмами, некоторые из которых описаны в разделе 3.4. REQ 6: Когда перегрузка сигнализируется с помощью специального сообщения, в сообщении должно быть четко указано, что оно отправлено из-за перегрузка, в отличие от других отказов, не связанных с перегрузкой условия.Это требование призвано избежать некоторых проблемы, возникшие из-за повторного использования кода ответа 503 для нескольких целей. Конечно, перегрузка также сигнализируется отсутствие ответа на запросы. Это требование распространяется только на явные сигналы перегрузки. Нет данных. Этот механизм сигнализирует о предполагаемой перегрузке, а не о фактической перегрузке. перегрузка. Однако сигналы в этом механизме не используются для любая другая цель. REQ 7: Механизм должен обеспечивать возможность для элемента регулировать объем трафика, который он получает от восходящего потока элемент.Это дросселирование должно быть оценено так, чтобы оно не было полностью или ничего, как с нынешним механизмом 503. Это признает тот факт, что "перегрузка" не является двоичным состоянием и что существуют степени перегрузки. да. Этот пакет событий допускает перегрузку на основе скорости / потерь / окон. параметры управления, как описано в Разделе 5.4. REQ 8: Механизм должен гарантировать, что, когда запрос не был обработано успешно из-за перегрузки (или сбоя) нижестоящий элемент, запрос не будет повторяться на другом элемент, который также перегружен или статус которого неизвестен.Этот требование вытекает из REQ 1. Неприменимо к самому механизму пакета событий управления нагрузкой. REQ 9: запрос был отклонен из-за перегруженного элемента не должны чрезмерно ограничивать возможность этого запроса быть отправлено и обработано элементом, который не перегружен. Это требование вытекает из REQ 1. да. Например, политика фильтрации нагрузки (раздел 3.1) может включать альтернативные направления пересылки для отклоненных запросов. REQ 10: Механизм должен поддерживать серверы, которые получают запросы. от большого количества различных восходящих элементов, где множество элементов восходящего потока не перечислим.Нет. Поскольку этот механизм требует предварительной настройки специально идентифицированные соседи, он не поддерживает среды где количество и идентичность вышестоящих соседей неизвестны заранее. Чтобы удовлетворить REQ 10, его следует использовать в соединение с другими механизмами. REQ 11: Механизм должен поддерживать серверы, которые получают запросы. из конечного набора вышестоящих элементов, где набор вышестоящих элементов перечислимо. да. См. Также ответ на REQ 10.REQ 12: Механизм должен работать между серверами в разных домены. да. Механизм пакета событий управления нагрузкой не ограничивается границы домена. Тем не менее, это, вероятно, более применимо во внутри- доменных сценариев, чем в междоменных сценариях из-за безопасности и другие проблемы (см. также раздел 3.4). REQ 13: Механизм не должен диктовать конкретный алгоритм для приоритетность обработки работы в прокси во время перегрузка. Он должен разрешать прокси-серверу определять приоритеты запросов на основе любая местная политика, так что определенные (например, призыв к службы экстренной помощи или звонок с определенным значением Поле заголовка Resource-Priority [RFC4412]) дается предпочтительным лечение, например, отказ от отказа, получение дополнительных повторная передача или обработка раньше других.P / A. Этот механизм конкретно не касается определения приоритетов работы во время перегрузок. Но это не исключает никаких особая местная политика. REQ 14: Механизм должен обеспечивать недвусмысленные указания клиентов о том, когда им следует повторить запрос и когда им следует нет. Это особенно относится к установлению TCP-соединения и SIP-регистрации для предотвращения лавинного перезапуска. Неприменимо к самому механизму пакета событий управления нагрузкой.REQ 15: В случаях, когда сетевой элемент выходит из строя, настолько перегружен что он не может обрабатывать сообщения или не может общаться из-за сбой сети или сетевой раздел, он не сможет предоставить четкие указания на характер сбоя или его уровни скопления. Механизм должен исправно работать в эти случаи. P / A. Поскольку политики фильтрации нагрузки подготавливаются заранее, на них не влияет перегрузка или отказ другой сети элементы.С другой стороны, в этих случаях они не смогут для защиты перегруженных сетевых элементов (см. REQ 1). REQ 16: Механизм должен пытаться минимизировать накладные расходы обмен сообщениями об управлении перегрузкой. да. Используется стандартизированный механизм пакетов событий SIP [RFC6665]. REQ 17: Механизм перегрузки не должен обеспечивать возможности для злонамеренная атака, включая DoS- и DDoS-атаки. P / A. Этот механизм действительно предоставляет потенциальную возможность для злонамеренных атаки.Следовательно, механизмы безопасности для пакетов событий SIP, в общем, [RFC6665] и раздел 7 данной спецификации должны быть использовал. REQ 18: Механизм перегрузки должен однозначно определять, индикация загрузки применяется к определенному IP-адресу, хосту или URI, так что восходящий элемент может определить нагрузку объекта на который должен быть отправлен запрос. да. Идентичность индикации нагрузки описана в определение формата политики фильтрации в разделе 3.1. REQ 19: Спецификация механизма перегрузки должна содержать руководство о том, какие типы сообщений могут быть желательны для обработки другие во время перегрузки, в зависимости от протокола SIP соображения. Например, может быть выгоднее обрабатывать обновление SUBSCRIBE с Expires равным нулю, чем обновление SUBSCRIBE с ненулевым истечением (поскольку первое снижает общий количество нагрузки на элемент), или для обработки повторных ПРИГЛАШЕНИЙ поверх новых ПРИГЛАШАЕТ.Неприменимо к самому механизму пакета событий управления нагрузкой. REQ 20: В смешанной среде элементов, которые действуют и не действуют реализовать механизм перегрузки, нет непропорциональной выгоды достаются пользователям или операторам элементов, которые не реализовать механизм. Нет. Этот механизм полностью зависит от участия всех возможные соседи. Чтобы удовлетворить REQ 20, его следует использовать в в сочетании с другими механизмами, некоторые из которых описаны в Раздел 3.4. REQ 21: Механизм перегрузки должен гарантировать, что система остается стабильным. Когда предлагаемая нагрузка падает сверху, общая пропускная способность сети ниже общей пропускной способности, пропускная способность должна стабилизироваться и сравняться с предлагаемой нагрузкой. Неприменимо к самому механизму пакета событий управления нагрузкой. REQ 22: Должна быть предусмотрена возможность отключения отчета о нагрузке. информация в отношении вышестоящих целей, основанная на личности эти цели. Это позволяет администратору домена, который считает загрузка их элементов конфиденциальной информацией, ограничить доступ к этой информации.Конечно, в таких случаях нет никаких ожиданий, что сам механизм перегрузки помочь предотвратить перегрузку от этого целевого объекта восходящего потока. Неприменимо к самому механизму пакета событий управления нагрузкой. REQ 23: Механизм перегрузки должен работать в случаи, когда балансировщик нагрузки перед фермой прокси. да. Механизм пакета событий управления нагрузкой не исключает его использовать в сценарии с фермами серверов. Приложение D. Полные примеры Д.1. Примеры документов по контролю нагрузки В этом разделе представлены два полных примера документов по контролю нагрузки. действителен по отношению к схеме XML, определенной в разделе 6. В первом примере предполагается, что набор горячих линий установлен в sip: [email protected] и tel: + 1-212-555-1234. В горячие линии работают с 12:00 до 15:00 по восточно-американскому стандартному времени 31 мая 2008 г. Цель состоит в том, чтобы ограничить входящие звонки на горячие линии до 100 запросов в секунду. Звонки, превышающие тариф limit явно отклонены. <набор правил xmlns = "urn: ietf: params: xml: ns: common-policy" xmlns: lc = "urn: ietf: params: xml: ns: load-control" version = "0" state = "full"> <правило> <условия> <один /> <один /> ПРИГЛАСИТЬ <действительность> 2008-05-31T12: 00: 00-05: 00 2008-05-31T15: 00: 00-05: 00 <действия> 100 Второй пример оптимизирует использование ресурсов сервера во время трехдневный период после урагана.Входящие звонки на домен "sandy.example.com" или для вызова пунктов назначения с префиксом "+ 1-212" будет быть ограничена скоростью 100 запросов в секунду, за исключением тех звонки, исходящие из определенного домена спасательной службы "rescue.example.com". Исходящие звонки из домена Hurricane или звонки внутри локального домена никогда не ограничиваются. Все звонки, которые дросселируется из-за ограничения скорости, будет перенаправлен отвечающему машина с обновленной информацией о спасении от урагана. <набор правил xmlns = "urn: ietf: params: xml: ns: common-policy" xmlns: lc = "urn: ietf: params: xml: ns: load-control" version = "1" state = "full"> <правило> <условия> <многие> ПРИГЛАСИТЬ <действительность> 2012-10-25T09: 00: 00 + 01: 00 2012-10-28T09: 00: 00 + 01: 00 <действия> 100 Иногда может случиться так, что несколько правил в наборе правил определяют действия, соответствующие одним и тем же методам, идентификатору вызова и действительности. В В этих случаях используется принцип «первый матч - выигрывает». Например, в следующем наборе правил первое правило требует, чтобы все вызовы от Домен example.com будет отклонен. Несмотря на то, что следующее правило тот указывает, что звонки от "sip: alice @ example.com "быть перенаправлены на конкретную цель "sip: [email protected]", звонки от "sip: [email protected]" все равно будет отклонен, потому что у них уже соответствует более раннему правилу. <набор правил xmlns = "urn: ietf: params: xml: ns: common-policy" xmlns: lc = "urn: ietf: params: xml: ns: load-control" version = "1" state = "full"> <правило> <условия> ПРИГЛАСИТЬ <действительность> 2013-7-2T09: 00: 00 + 01: 00 2013-7-3T09: 00: 00 + 01: 00 <действия> 0 <правило> <условия> <один /> ПРИГЛАСИТЬ <действительность> 2013-7-2T09: 00: 00 + 01: 00 2013-7-3T09: 00: 00 + 01: 00 <действия> 0 D.2. Примеры потока сообщений В этом разделе представлен пример потока сообщений при использовании load- механизм пакета событий управления, определенный в этой спецификации. Атланта Билокси | F1 ПОДПИСАТЬСЯ | | ------------------> | | F2 200 ОК | | <------------------ | | F3 УВЕДОМЛЕНИЕ | | <------------------ | | F4 200 ОК | | ------------------> | F1 ПОДПИСАТЬСЯ на atlanta.example.com -> biloxi.example.com ПОДПИСАТЬСЯ на sip: biloxi.example.com SIP / 2.0 Через: SIP / 2.0 / TCP atlanta.example.com; branch = z9hG4bKy7cjbu3 От: sip: atlanta.example.com; tag = 162ab5 Кому: sip: biloxi.example.com Call-ID: [email protected] CSeq: 2012 ПОДПИСАТЬСЯ Контакты: sip: atlanta.example.com Событие: load-control Максимальное количество нападающих: 70 Принять: application / load-control + xml Срок годности: 3600 Content-Length: 0 F2 200 OK biloxi.example.com -> atlanta.example.com SIP / 2.0 200 ОК Через: SIP / 2.0 / TCP biloxi.example.com; branch = z9hG4bKy7cjbu3 ; получил = 192.0.2.1 Кому: ; tag = 331dc8 От: ; tag = 162ab5 Call-ID: [email protected] CSeq: 2012 ПОДПИСАТЬСЯ Срок годности: 3600 Контакты: sip: biloxi.example.com Content-Length: 0 F3 УВЕДОМЛЕНИЕ biloxi.example.com -> atlanta.example.com УВЕДОМЛЕНИЕ sip: atlanta.example.com SIP / 2.0 Через: SIP / 2.0 / TCP biloxi.example.com; branch = z9hG4bKy71g2ks От: ; tag = 331dc8 Кому: ; tag = 162ab5 Call-ID: [email protected] Событие: load-control Состояние подписки: активно; истекает = 3599 Максимальное количество нападающих: 70 CSeq: 1775 УВЕДОМЛЕНИЕ Контакты: sip: biloxi.example.com Тип содержимого: приложение / управление нагрузкой + xml Content-Length:... [Документ по контролю нагрузки] F4 200 ОК atlanta.example.com -> biloxi.example.com SIP / 2.0 200 ОК Через: SIP / 2.0 / TCP atlanta.example.com; branch = z9hG4bKy71g2ks ; получил = 192.0.2.2 От: ; tag = 331dc8 Кому: ; tag = 162ab5 Call-ID: [email protected] CSeq: 1775 УВЕДОМЛЕНИЕ Content-Length: 0 Приложение E. Сопутствующие работы E.1. Связь с фильтрацией нагрузки в PSTN Известно, что существующая сеть PSTN также использует фильтрацию нагрузки. механизм предотвращения перегрузки и настройка политики фильтрации выполняется вручную, за исключением особых случаев, когда Интеллектуальная Используется сетевая архитектура [Q.1248.2] [E.412]. Эта спецификация определяет механизм фильтрации нагрузки на основе события SIP структура уведомлений, которая позволяет автоматизировать политику фильтрации распространение в подходящей среде. Контроль перегрузки PSTN использует сообщения, которые определяют исходящий контроль список, продолжительность перерыва в вызове и продолжительность управления [Q.1248.2] [E.412]. Эти предметы примерно соответствуют личности, действию и времени. поля политики фильтрации нагрузки SIP, определенной в этом Технические характеристики. Однако политика фильтрации нагрузки, определенная в этом спецификация гораздо более универсальна и гибка, чем ее Аналог PSTN.Во-первых, фильтрация нагрузки PSTN применяется только к телефонным номерам. В Идентификационный элемент политики фильтрации нагрузки SIP позволяет использовать как SIP URI, так и телефонные номера (через URI 'tel') должны быть указаны. Эти идентификаторы могут быть произвольно сгруппированы по доменам SIP или любому количеству ведущие префиксы телефонных номеров. Во-вторых, действие фильтрации нагрузки PSTN обычно ограничивается вызовом разрыв. Поле действия в политике фильтрации нагрузки SIP позволяет больше гибкие возможности, такие как дроссель скорости и другие.В-третьих, поле продолжительности в фильтрации нагрузки PSTN указывает значение в секундах только для продолжительности фильтрации нагрузки, а разрешенное значения отображаются в набор значений. Поле времени в SIP load- политика фильтрации может указывать не только продолжительность, но и будущее время активации, которое может быть особенно полезно для автоматизации загрузки фильтрация для прогнозируемых перегрузок. Фильтрация нагрузки PSTN может выполняться как в граничных коммутаторах, так и в транзитные переключатели; фильтрация нагрузки SIP также может применяться в обоих пограничные прокси-серверы и основные прокси-серверы, и даже способный пользователь агенты.Фильтрация нагрузки PSTN также имеет специальные возможности для High Вероятность завершения (HPC) вызовов, которые были бы похожи на вызовы, обозначенные заголовками приоритета ресурсов SIP [RFC4412]. В Механизм фильтрации нагрузки SIP также позволяет приоритизировать обработку этих звонков, указав для них благоприятные действия. Фильтрация нагрузки PSTN также предоставляет возможность администрирования для маршрутизация неудачных попыток вызова на тональный сигнал переупорядочивания [E.300SerSup3] с указанием условий перегрузки или специального записанного объявления.А аналогичная возможность может быть предоставлена в SIP-фильтрации нагрузки. механизм, указав соответствующий атрибут "alt-action" в SIP поле действия фильтрации нагрузки. E.2. Связь с другими усилиями IETF по контролю перегрузки SIP Политики фильтрации нагрузки в этой спецификации состоят из личность, действие и время. Идентичность может варьироваться от одного от конкретного пользователя к произвольной совокупности пользователей, доменам или областям. В Пользователь может быть идентифицирован либо по источнику, либо по месту назначения.Когда пользователь идентифицируется источником, и благоприятное действие указан, результат до некоторой степени похож на идентификацию приоритетный пользователь на основе авторизованных заголовков приоритета ресурсов [RFC4412] в запросах. Указание идентификатора исходного пользователя с неблагоприятное действие вызовет эффект, до некоторой степени похожий на обратный механизм приоритета ресурсов SIP. Политика фильтрации нагрузки, определенная в этой спецификации, является общей. и ожидается, что он будет применим не только к фильтрации нагрузки механизма, но и к механизму контроля перегрузки обратной связи в [SIP-ПЕРЕГРУЗКА].В частности, оба механизма могут использовать определенные или идентификаторы с подстановочными знаками для управления нагрузкой и могут совместно использовать хорошо известную нагрузку управляющие воздействия. Поле продолжительности времени в фильтре нагрузки политика также может использоваться в обоих механизмах. Как упоминалось в Раздел 1, механизм распределения политики фильтрации нагрузки и Механизм контроля перегрузки с обратной связью обращается к дополнительным областям в проблемное пространство управления перегрузкой. Фильтрация нагрузки более активна и фокусируется на распространении политик фильтрации по отношению к источнику трафик; Поэтапный подход, основанный на обратной связи, является реактивным и уменьшает трафик, уже принятый сетью.Поэтому они также могут по-разному использовать общую политику фильтрации нагрузки. компоненты. Например, механизм фильтрации нагрузки может использовать поле времени в политике фильтрации, чтобы указать не только элемент управления продолжительность, но также и время активации в будущем, чтобы учесть предсказуемая перегрузка, например, вызванная поздравлением с Днем матери или программа телезрительского голосования; управление на основе обратной связи может не понадобиться использовать поле времени или можно использовать поле времени, чтобы указать длительность немедленного контроля нагрузки.Адреса авторов Чарльз Шен Колумбийский университет Департамент компьютерных наук 1214 Амстердам-авеню, MC 0401 Нью-Йорк, NY 10027 Соединенные Штаты Америки Телефон: +1212854 3109 Электронная почта: [email protected] Хеннинг Шульцринне Колумбийский университет Департамент компьютерных наук 1214 Амстердам-авеню, MC 0401 Нью-Йорк, NY 10027 Соединенные Штаты Америки Телефон: +1212939 7004 Электронная почта: schulzrinne@cs.
By alexxlab
Добавить комментарий Отменить ответ
Ваш адрес email не будет опубликован. Обязательные поля помечены *
Комментарий *
Имя *
Email *
Сайт

Найти:
Рубрики
Виды
Генератор
Конденсатор
Подключение
Проводка
Своими руками
Схемы
Электродвигатель
Разное
2025 © Все права защищены.