Конструкции защищенных изоляцией проводов марки «SAX» и провода СИП-3 фирмы Заря | ВЛ и провода

Провода «SAX» отечественного производства (фирма «Заря», Санкт-Петербург) относятся к группе защищенных воздушных проводов для напряжений 6-10 кВ. Провода «SAX» подвешивают на изоляторах. Монтаж этих проводов выполняют также как и монтаж неизолированных проводов. Провода «SAX» изолируются атмосферостойким сшитым полиэтиленом, выдерживающим вибрации проводов и в течение определенного времени даже массу поваленного дерева. Изоляционная защита провода создает возможность значительного уменьшения расстояния между фазами и сузить трассу.
Основные конструктивные параметры проводов «SAX» приведены в табл. 1, а электрические характеристики в табл. 3.
Конструкция проводов «SAX» обеспечивает также защиту от электрической дуги по всему протяжению линии, не требуя для этого специальных мероприятий по защите. Метод подвески проводов обеспечивает защиту проводов от вибрационных повреждений.

Конструктивные параметры проводов «SAX»

Марка провода. Сечение жилы, мм2	Номинальный диаметр токопроводящей жилы провода, мм	Номинальный диаметр провода с изоляцией, мм	Масса провода, кг/км	Разрушающее усилие, кН
SAX 35	6,9	11,5	160	10,3
SAX 50	8,0	12,7	200	14,2
SAX 70	9,7	14,3	270	20,6
SAX 95	11,3	16,0	350	27,9
SAX 120	12,8	17,5	425	35,3
SAX 150	14,2	18,9	510	43,4
SAX 185	15,7	20,5	620	54,3
SAX 240	18,1	22,8	785	70,6

Примечание:

1. Разрушающее механическое напряжение жилы из алюминиевого сплава — 294 Н/мм².
2. Маркировка провода выполнена несмываемой краской по всей длине с интервалом 200 мм; указан тип — завод-изготовитель— марка и сечение — год изготовления, например:

«PAS-NOKIA-SAX 120-1999»

Допустимые механические напряжения в проводах «SAX» BЛ3 6-10 кВ

Марка провода	Допустимое напряжение, % предела прочности при растяжении		Допустимое напряжение, даН/мм2
	при наибольшей нагрузке и низшей температуре	при среднегодовой температуре	при наибольшей нагрузке и низшей температуре	при среднегодовой температуре
SAX 35. ..SAX 50	35	30	10,3	8,8
SAX 70.. SAX 95	40	30	11,7	8,8
SAX 120… SAX 150	45	30	13,2	8,8

Основные электрические характеристики проводов «SAX»

Марка провода. Сечение жилы, мм2	Минимальное сопротивление постоянному току при температуре окружающего воздуха +20 °С, Ом/ км	Длительно допустимый ток при температуре окружающего воздуха +20 °С, А	Максимально допустимый ток термической стойкости (при односекундном к. з.) при температуре окружающего воздуха +40 °С, кА
SAX 35	0,986	200	3,2
SAX 50	0,720	245	4,3
SAX 70	0,493	310	6,4
SAX 95	0,363	370	8,6
SAX 120	0,288	430	11,0
SAX 150	0,236	485	13,5
SAX 185	0,188	560	17,0
SAX 240	0,145	625	22,3

Защищенные провода СИП-3 отечественного производства (фирма «Заря, Санкт-Петербург)» имеют следующую конструкцию:
токопроводящая жила— многопроволочная, из алюминиевого сплава
или сталеалюминиевая, уплотненная; изоляция           — сшитый атмосферостойкий полиэтилен;
Провода изготовляются по ТУ 16 К71-272-97, им присвоена марка СИП-3 и торговое кодовое обозначение «Заря».

Технические характеристики проводов СИП-3 фирмы «Заря»

Номинальное сечение токопроводящей жилы, мм2	Номинальный наружный диаметр жилы, мм	Разрывная прочность жилы, кН, не менее	Электрическое сопротивление жилы постоянному току на длине 1 км, Ом, не более	Номинальный наружный диаметр, мм
50	8,1	14,2	0,720	12,6
70	9,7	20,6	0,493	14,3
95	11,3	27,9	0,363	16,0
120	12,8	35,2	0,288	17,4
150	14,2	43,4	0,236	18,8

Допустимый нагрев токопроводящей жилы провода не должен превышать 90 С при нормальном режиме и 250 °С при коротком замыкании                   

 

Допустимый ток нагрузки проводов СИП-3 фирмы «Заря»

Номинальное сечение токопроводящей жилы, мм2	Допустимый ток нагрузки, А	Односекундный ток КЗ, не более, кА
50	245	4,3
70	310	6,4
95	370	8,6
120	430	11,0
150	485	13,5

П2.

9. Технические характеристики проводов пзв и пзвг

Сечение жилы, мм2	Наружный диаметр провода, мм		Масса провода, кг/км
	ПЗВ	ПЗВГ	ПЗВ	ПЗВГ
35	13,3	14,7	196	228
50	14,5	15,9	244	279
70	16,1	17,5	317	355
95	17,8	19,2	405	447
120	19,2	20,6	486	531
150	20,6	22,0	575	622
185	22,2	23,6	670	738
240	24,5	25,9	850	910

П2.

10. Электрические параметры проводов сип-1, сип-1а, (сип-2, сип-2а)

Количество жил и их сечение, мм2

Омическое сопротивление фазной жилы, Ом/км

Омическое сопротивление несущей жилы, Ом/км

Допустимый ток фазной жилы, А

Термическая стойкость фазной жилы Iкз1, кА

1	2	3	4	5
2х16	1,91	—	75 (105)	1,0
3х16	1,91	—	70 (100)	1,0
4х16	1,91	—	70 (100)	1,0
2х25	1,2	—	100 (135)	1,6
3х25	1,2	—	95 (130)	1,6
4х25	1,2	—	95 (130)	1,6
1х16+1х25	1,91	1,38	75 (105)	1,0 (1,5)
3х16+1х25	1,91	1,38	70 (100)	1,0 (1,5)
3х25+1х35	1,20	0,99	95 (130)	1,6 (2,3)
3х35+1х50	0,87	0,72	115 (160)	2,3 (3,2)
3х50+1х50	0,64	0,72	140 (195)	3,2 (4,6)
3х50+1х70	0,64	0,49	140 (195)	3,2 (4,6)
3х70+1х70	0,44	0,49	180 (240)	4,5 (6,5)
3х50+1х95	0,44	0,36	180 (240)	4,5 (6,5)
3х95+1х70	0,32	0,49	220 (300)	5,2 (6,9)
3х95+1х95	0,32	0,36	220 (300)	5,2 (6,9)
3х120+1х95	0,25	0,36	250 (340)	5,9 (7,2)
4х16+1х25	1,91	1,38	70 (100)	1,0 (1,5)
4х25+1х35	1,20	0,99	95 (130)	1,6 (2,3)

Примечание. Термическая стойкость жилы указана по отношению к односе­кундному току к.з. I_кз1. При другой продолжительности к.з. этот ток следует умножить на поправочный коэффициентk=1/.

П2.11. Электрические параметры проводов сип-4, сиПн-4, (сиПс-4)

Количество жил и их сечение, мм2, (n=2, 3, 4)	Омическое сопротивление фазной и нулевой жилы, Ом/км	Допустимый ток фазной жилы Iдоп, А	Термическая стойкость фазной и нулевой жилы Iкз1, кА
nх25	1,20	95 (130)	1,6 (2,3)
nх35	0,89	115 (160)	2,3 (3,2)
nх50	0,64	140 (195)	3,2 (4,6)
nх70	0,44	180 (240)	4,5 (6,5)
nх95	0,32	220 (290)	6,0 (7,0)
nх120	0,25	250 (340)	7,6 (7,6)

ТУ 16-705.

500-2006 Провода самонесущие изолированные

Технические условия

(Взамен ТУ 16.К71-268-98 и ТУ 16.К71-272-98)
Дата введения 01.07.2006

 

Настоящие технические условия распространяются на самонесущие изолированные провода для воздушных линий электропередачи на номинальное напряжение до 0,6/1 кВ включительно и провода самонесущие защищенные для воздушных линий электропередачи на номинальное напряжение 20 кВ (для сетей на напряжение 10, 15 и 20 кВ) и 35 кВ (для сетей на напряжение 35 кВ) номинальной частотой 50 Гц, в дальнейшем именуемые «провода».
Провода по конструктивному исполнению, техническим характеристикам и эксплуатационным свойствам соответствуют национальному стандарту Российской Федерации ГОСТР 52373-2005.
Климатическое исполнение проводов — В, категории размещения -1, 2 и 3 по ГОСТ 15150-69.
Примеры записи условного обозначения при заказе и в документации другого изделия:
— провода самонесущего изолированного марки СИП-1 с тремя основными жилами номинальным сечением 70 мм2, с не изолированной несущей жилой номинальным сечением 95 мм2, на номинальное напряжение 0,6/1 кВ:
«Провод СИП-13х70+1х95-0,6/1 ТУ 16-705. 500-2006»:
— провода самонесущего изолированного марки СИП-2 с тремя основными жилами номинальным сечением 50 мм2, с изолированной несущей жилой номинальным сечением 70 мм2, с двумя вспомогательными жилами номинальным сечением 16 мм2, на номинальное напряжение 0.6/1 кВ:
«Провод СИП-2 Зх50+1х70+2х16-0,6/1ТУ 16-705.500-2006»:
— провода защищенного марки СИП-З с жилой номинальным сечением 120 мм2, на номинальное напряжение 20кВ: «Провод СИП-3 1×120-20 ТУ 16-705.500-2006».

 

1. Технические требования

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

1.2 Марки и размеры
1.2.1 Марки проводов, их наименование и преимущественная область применения приведены в таблице 1.

Таблица 1

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

Таблица 2

Расчетные масса и наружный диаметр проводов приведены в качестве справочного материала.
1.2.3 Провода марок СИП-1 и СИП-2 с нулевой несущей жилой сечением 50 мм и более могут изготавливаться с 1, 2 или 3 вспомогательными жилами.
Номинальное сечение вспомогательных жил для цепей наружного освещения 16, 25 или 35 мм2, для цепей контроля -1,5; 2,5 или 4 мм2.
1.2.4 Строительная длина проводов согласовывается при заказе

1.3 Требования к конструкции
1.3.1 Основные и вспомогательные жилы для цепей освещения должны быть скручены из круглых алюминиевых проволок, иметь круглую форму и быть уплотненными. Вспомогательные жилы для цепей контроля должны быть медными однопроволочными и соответствовать ГОСТ 22483-77.
Допускается сварка алюминиевых проволок при их обрыве или сходе в процессе скрутки. Число соединений проволок не должно быть более шести на строительной длине, расстояние между соседними соединениями проволок должно быть не менее 50 м.
Прочность при растяжении алюминиевых проволок до их скрутки в жилу должна быть не менее 120 Н/мм2. Число проволок в основной токопроводящей жиле и наружный диаметр основных токопроводящих жил должны соответствовать значениям, указанным в таблице 3.

Таблица 3

1.3.2. Нулевая несущая жила и токопроводящая жила защищенных проводов должны быть скручены из круглых проволок из алюминиевого сплава, иметь круглую форму ибыть уплотненными.
Прочность при растяжении проволок из алюмнниевого сплава до скрутки в жилу должна быть не менее 295 Н/мм2, относительное удлинение при разрыве — не менее 4 %, модуль упругости — не менее , коэффициент линейного расширения — не более .
Число проволок в нулевой несущей жиле и токопроводящей жиле защищенных проводов и их наружный диаметр должны соответствовать значениям, указанным в таблице 4.

Таблица 4

1.3.3. Разность между максимальным и минимальным диаметрами жил, измеренными во взаимно-перпендикулярных направлениях одного сечения не должна быть более 0,2 мм.
1.3.4 Диаметр проволок, коэффициент заполнения сечения жил должны быть указаны в технологической документации предприятия-изготовителя, утвержденной в установленном порядке, и должны сообщаться заказчику по его запросу.
1.3.5 Жилы герметизированных проводов должны содержать водоблокирующий элемент или элементы, исключающие миграцию влаги вдоль жилы провода, в виде нити, ленты или порошка.
Способ герметизации провода должен быть указан в технологической документации предприятия-изготовителя.
1.3.6 Изоляция основных и вспомогательных токопроводящих жил, изоляция (при наличии) нулевой несущей жилы и защитная изоляция защищенных проводов должна быть экструдирована (выпрессована) из светостабилизированного сшитого полиэтилена. Изоляция должна быть черного цвета.
Номинальная толщина изоляции основных жил, нулевой несущей жилы и вспомогательных жил проводов на напряжение 0,6/1 кВ должна соответствовать указанной в таблице 5.

Таблица 5

Номинальная толщина защитной изоляции защищенных проводов на номинальное напряжение 20 кВ — 2,3 мм. на номинальное напряжение 35 кВ — 3,5мм.
Нижнее предельное отклонение от номинальной толщины изоляции — , где — номинальная толщина изоляции, мм. Верхнее предельное отклонение не нормируется
1.3.7 Изолированные основные и вспомогательные жилы должны быть скручены вокруг нулевой несущей жилы при ее наличии.
Изолированные жилы проводов без нулевой несущей жилы должны быть скручены между собой. Скрутка жил должна иметь правое направление.
Шаг скрутки изолированных жил проводов с нулевой несущей жилой должен соответствовать указанному в таблице 6.
Шаг скрутки изолированных жил проводов без нулевой несущей жилы должен быть не более 45 см.

Таблица 6

1.3.8 Материалы, применяемые для изготовления проводов, должны соответствовать требованиям ГОСТР 52373-2005 и следующим нормативно-техническим документам:
— катанка алюминиевая — ГОСТ 13843-78;
— проволока алюминиевая круглая марки АВЛ -ТУ 16-705. 472-87;
— катанка из алюминиевого сплава — ТУ 16-705.493-2006*;
*С 01.12.2006 г.
— пруток из сплава алюминия — ГОСТР 51834-2001;
— проволока из сплава алюминия:
марки ABE — ГОСТ 20967-75,
марки 6101 тип В — МЭК 60104. 1987*;
*С 01.12.2006 -ТУ 16-705.494-2006 «Проволока круглая из алюминиевого сплава электротехническая»
— композиция светастабилизированного силанольносшиваемого полиэтилена марок LE 4421/LE 4472 и LE 4423 LE 4472 — по нормативной документации ф. Borealis;
— водоблокирующие материалы (порошок, нити, ленты) — по нормативной документации фирм «Freudeburs», «Gesa Tapes»;
— медная проволока марки ММ — ТУ16-705.492-2005.
Допускается применение других равноценных материалов по согласованию с разработчиком настоящих технических условий и при выполнении процедуры, установленной ГОСТ Р51651-2000.

1.4 Требования к электрическим параметрам
1.4.1 Электрическое сопротивление основных и вспомогательных жил постоянному току, пересчитанное на температуру 20 °С и 1 км длины, соответствующее ГОСТ 22483-77, приведено в таблице 3.
Электрическое сопротивление нулевой несущей жилы и токопроводящей жилы защищенных проводов постоянному току, пересчитанное на температуру 20 °С и 1 км длины, должно соответствовать указанному в таблице 4.
1.4.2 Удельное объемное сопротивление изоляции и защитной изоляции при длительно допустимой температуре нагрева токопроводящих жил, должно быть не менее .
1.4.3 Провода после выдержки в воде при температуре (20±10) °С в течение не менее 10 мин должны выдерживать на строительной длине испытание переменным напряжением частотой 50 Гц в течение не менее 5 мин:
— самонесущие изолированные — 4 кВ:
— защищенные на номинальное напряжение 20 кВ — 6 кВ:
— защищенные на номинальное напряжение 35 кВ — 10 кВ.
1.4.4 Самонесущие изолированные провода должны выдерживать на образцах испытание переменным напряжением 10 кв частотой 50 Гц в течение не менее 30 мин после выдержки вводе при температуре (20=10) °С не менее 24 ч.
1.4.5 Защищенные провода на номинальное напряжение 20 кВ должны выдерживать на образцах испытание напряжением 24 кВ, на номинальное напряжение 35 кВ — 40 кВ переменного тока частотой 50 Гц в течение не менее 5 мни.
1.4.6 Пробивное напряжение защитной изоляции защищенных проводов после выдержки в воде при температуре (20±5) °С в течение не менее 1 ч должно быть для проводов на номинальное напряжение 20 кВ — не менее 24 кВ, для проводов на номинальное напряжение 35 кВ — не менее 40 кВ переменного тока частотой 50 Гц.
1.4.7 Расчетные значения активного и индуктивного сопротивления проводов приведены в приложении Б.

1.5 Требования к механическим параметрам
1.5.1 Прочность при растяжении нулевой несущей жилы и токопроводящей жилы защищенных проводов должна соответствовать указанной таблице 4.
1.5.2 Изоляция нулевой несущей жилы (при наличии) должна плотно прилегать к поверхности жилы. Усилие сдвига изоляции нулевой несущей жилы должно быть не менее значений, указанных в таблице 7.

Таблица 7

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

1.6 Требования по стойкости к внешним воздействующим факторам
1. 6.1 Провода должны быть стойкими к воздействию температуры окружающей среды до 50 °С.
1.6.2 Провода должны быть стойкими к воздействию температуры окружающей среды до минус 60 °С.
1.6.3 Провода должны быть стойкими к воздействию солнечного излучения.
1.6.4* Провода должны быть стойкими к циклическому воздействию комплекса атмосферных факторов, включающего:
— воздействие солнечного излучения;
— воздействие температуры (70±2) °С;
— воздействие дождя;
— воздействие температуры минус (40±2) °С.
*С 01.01.2008 г.
1.6.5 Герметизированные провода должны быть устойчивы к продольному распространению воды. Распространение воды вдоль провода от места ее проникновения не должно превышать 3 м.

1.7 Характеристики изоляции и защитной изоляции жил должны соответствовать требованиям ГОСТР 52373-2005.

1.8 Срок службы проводов должен быть не менее 40 лет.

1.9 Маркировка и упаковка проводов должна соответствовать требованиям ГОСТР 52373-2005.

2 Требования безопасности

2. 1 Требования электробезопасности обеспечиваются выполнением требований пп. 1.4.3 — 1.4.6.

3 Правила приемки

3.1 Правила приемки должны соответствовать требованиям ГОСТ 15.309-98. ГОСТ Р 53272-2005 с дополнениями, изложенными в настоящем разделе.

3.2 Приемосдаточные испытания
3.2.1 Провода предъявляют к приемке партиями.
За партию принимают провода одного маркоразмера, одновременно предъявляемые к приемке. Объем партии — от 1 до 50 строительных длин провода.
Время выдержки проводов после изготовления в нормальных климатических условиях по ГОСТ 15150-69 до предъявления к приемке должно быть не менее 16ч.
3.2.2 Проверку по пп.1.2.2 — 1.2.4 1.3.1 — 1.3.7 1.4.1 1.4.3 1.7 (проверка тепловой деформациии золяции) и 1.9 проводят при приемосдаточных испытаниях.
Проверку строительной длины (п. 1.2.4) проводят в процессе производства.

3.3 Периодические испытания
3.3.1 Периодические испытания проводят не реже 1 раза в год на проводах, прошедших приемосдаточные испытания. Проверку по пп.1.4.4 — 1.4.6 1.5.1 — 1.5.3 1.6.5. 1.9 (проверка прочности маркировки) проводят при периодических испытаниях.

3.4 Типовые испытания
3.4.1 Испытания проводят по ГОСТ Р 53272-2005 при изменении конструкции проводов, замене материалов или при измененни технологических процессов по программе, утвержденной в установленном порядке.

4 Методы контроля

4.1 Методы контроля должны соответствовать требованиям ГОСТР 52373-2005 с дополнениями, изложенными в настоящем разделе.

4.2 После завершения испытаний на стойкость к циклическому воздействию комплекса атмосферных факторов (п. 1.6.4) образцы подвергают испытаниям по определению прочности при растяжении R и относительного удлинения при разрыве А по ГОСТР МЭК 60811-1-1-98:
— эталонная партия — ;
— вторая партия — ;
— третья партия — .
Измеренные средние значения физико-механических характеристик образцов должны удовлетворять следующим соотношениям:

4.3 Проверку срока службы проводов (п. 1.8) проводят по методике ОАО «ВНИИКП»МИ.К00-101-97.

5. Транспортирование и хранение

5.1. Транспортирование и хранение должно соответствовать требованиям ГОСТР 52373-2005.

6 Указания по эксплуатации

6.1 Изолированные провода допускается эксплуатироватъ при температуре окружающей среды от минус 60 °С до плюс 50 °С

6.2 Монтаж проводов рекомендуется проводить при температуре окружающей среды не ниже минус 20 °С

6.3 Подвеска проводов в воздушных линиях электропередачи должна соответствовать требованиям Правил устройства электроустановок.
Самонесущие изолированные провода на номинальное напряжение 0,6/1 кВ без нулевой несущей жилы марки СИП-4 предназначены для выполнения ответвлений от ВЛ к вводу, для прокладки по стенам зданий или сооружений.
Механические напряжения в проводах при их монтаже следует принимать в соответствии с ПУЭ и типовыми проектами опор ВЛ.

6.4 Расстояние от защищенных проводов до ветвей и кроны деревьев следует принимать в соответствии с ПУЭ.

6.5 Радиус изгиба при монтаже и установленного на опорах провода должен быть 10D, где D — расчетный наружный диаметр провода, мм.

6.6 Допустимый нагрев токопроводящих жил при эксплуатации не должен превышать 90 °С в нормальном режиме и 250 °С — при коротком замыкании.

6.7 Допустимые токовые нагрузки проводов, рассчитанные при температуре окружающей среды 25 °С, скорости ветра 0.6 м/с и интенсивности солнечной радиации 1000 Вт/м2, и допустимые токи односекундного короткого замыкания должны соответствовать указанным в таблице 8.

Таблица 8

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

Таблица 9

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

где t — продолжительность короткого замыкания, с.

7 Гарантии изготовителя

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

ПРИЛОЖЕНИЕ А
(обязательное)

Таблица А.1 — Коды ОКП и контрольные числа (КЧ)

Таблица А.2 — Девятый и десятый разряды кода маркоразмеров

Приложение Б
(Справочное)

Таблица Б.1 — Активное сопротивление токопроводящих жил проводов при 90 °С на частоте 50 Гц

Таблица Б.2 — Расчетные значения индуктивного сопротивления изолированных проводов

Упрощенные стандарты тока утечки

| mddionline.com

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

Леонард Эйснер

Роберт М. Браун

Дан Моди

Стандарт IEC 60601-1 «Медицинское электрическое оборудование. Часть 1: Общие требования к безопасности и основным характеристикам» описывает испытания на ток утечки, как и ряд соответствующих национальных стандартов. ¹ Эта статья призвана упростить эти тесты и требования соответствующих стандартов, а также объяснить их обоснование. Для обзора других тестов в стандарте IEC 60601-1, пожалуйста, обратитесь к «Основы для IEC 60601-1». ²

Ток утечки

Как указано в NFPA 99: «Стандарт для медицинских учреждений», издание 2002 г. , всего три условия, возникающие одновременно, могут привести к электрошоку у пациента или лица, осуществляющего уход:

• Одна часть тело контактирует с проводящей поверхностью.
• Другая часть того же тела контактирует со второй проводящей поверхностью.
• Источник напряжения пропускает ток через тело между этими двумя точками контакта. ³

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

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

Рисунок 1. Электрический ток и точки анализа для медицинских устройств (щелкните, чтобы увеличить).

Измерения тока утечки выполняются при включенном приборе и в любых условиях, таких как режим ожидания и полная работа. Напряжение питания обычно подается на изделие через изолирующий трансформатор. Согласно IEC 60601-1, напряжение сети должно быть на уровне 110% от наивысшего номинального напряжения питания и при наивысшей номинальной частоте питания. Это означает, что продукт, рассчитанный на работу при 115 В переменного тока, 60 Гц и 230 В переменного тока, 50 Гц, будет испытываться при 253 В переменного тока и частоте сети 60 Гц.

Измерительный прибор

Рисунок 2. Модель человеческого тела согласно IEC 60601-1 (щелкните, чтобы увеличить).

Измерительное устройство, как определено в IEC 60601-1, состоит из двух частей. Один из них — вольтметр с входным сопротивлением ½1-Mž и плоской частотной характеристикой от постоянного тока до 1 МГц. Прибор должен показывать истинное среднеквадратичное значение напряжения на измерительном импедансе. Погрешность индикации не должна превышать ± 5%.Вторая часть измерительного устройства представляет собой схему, показанную на рисунке 2. Схема обеспечивает сопротивление около 1000 ž и частотные характеристики, которые учитывают человеческое тело и риск фибрилляции желудочков.

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

Рисунок 3.Частотная характеристика модели человеческого тела по IEC 60601-1 (нажмите, чтобы увеличить).

Данные исследования показали, что риск фибрилляции желудочков наиболее высок для частот от 10 до 200 Гц. Риск немного снижается на частоте 1000 Гц. Он быстро уменьшается для частот выше 1000 Гц. Частотная характеристика схемы, показанная на рисунке 3, предназначена для имитации риска фибрилляции желудочков. Он имеет относительно ровную частотную характеристику до 1000 Гц, затем быстрый спад.

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

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

Условия измерения тока утечки

a Общее оборудование. b Нет доступных частей защитного заземления, нет средств защитного заземления другого устройства, передвижной рентгеновский снимок оборудование, мобильное оборудование с минеральной изоляцией (см. примечания 2 и 4, таблица IV, IEC 60601-1). c Постоянно установленный провод защитного заземления (см. Примечание 3, таблица IV, IEC 60601-1) (щелкните, чтобы увеличить).

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

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

Имеется ряд состояний единичной неисправности.К ним относятся размыкание защитного заземления и размыкание каждого провода в сети питания по одному.

Для медицинских устройств могут потребоваться дополнительные условия единичного отказа в зависимости от классификации медицинского оборудования. Они могут включать 110% сетевого напряжения, приложенного к частям ввода / вывода сигнала (SIP / SOP) во время испытаний на утечку через пациента и герметичность корпуса. Другое неисправное состояние — это напряжение сети на рабочих частях.

Подключение

Подключение для большинства испытаний простое, с измерительным устройством, подключенным к проверяемой точке проводимости.Например, если измерительное оборудование в металлическом корпусе, измерительное устройство подключается к неокрашенной части корпуса. Для проведения измерений на изделии, имеющем корпус или другую точку измерения, изготовленную из изоляционного материала, кусок проводящей фольги размером не более 20 ¥ 10 см (имитирующий размер ладони) помещается в непосредственном контакте с точкой измерения. Если поверхность, с которой контактирует пациент или оператор, превышает 20 20 10 см, размер фольги соответственно увеличивается. Фольгу обычно сдвигают, чтобы определить максимальное значение тока утечки.

Допустимые уровни тока утечки

Рисунок 4. Ток утечки на землю (щелкните, чтобы увеличить).

IEC 60601-1 устанавливает допустимые пределы для измерения тока утечки. Эти пределы зависят от выполняемого испытания, классификации применяемых частей, а также от нормальных условий или условий единичного отказа.Пределы утечки для IEC 60601-1 показаны в таблице I.

Испытания на утечку

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

Рисунок 5. Ток утечки корпуса (щелкните, чтобы увеличить).

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

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

Рис. 6. (a) Ток утечки пациента для рабочей детали типа B, (b) ток утечки пациента для рабочей детали типа BF и (c) ток утечки пациента для рабочей детали типа CF (щелкните, чтобы увеличить).

На рисунке 4 показано базовое измерение тока утечки на землю в медицинском оборудовании с использованием стандартного съемного шнура питания. Такие измерения выполняются как в нормальных условиях, так и в условиях единичного отказа, то есть прерывания одного источника питания. воздуховод (линейный или нейтральный) за один раз.

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

Ток утечки на пациента. Это ток утечки, измеренный от любой приложенной детали к земле. В зависимости от типа применяемой детали (B, BF или CF) существуют разные требования к способу проведения испытаний на герметичность и типу условий отказа.К рабочим деталям типа CF предъявляются самые строгие требования к испытаниям.

Рисунок 7. Напряжение сети на рабочих частях (щелкните для увеличения).

Ток утечки для рабочих частей типа B измеряется между всеми подключенными частями, связанными вместе и землей, как показано на рисунке 6a.
Рабочие части типа BF должны быть разделены на рабочие части, выполняющие разные функции. Ток утечки измеряется между всеми подключенными частями с аналогичной функцией и землей.См. Рисунок 6b.

Ток утечки для рабочих частей типа CF должен измеряться от каждой рабочей части до земли отдельно. См. Рисунок 6c.

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

Рисунок 8. Напряжение сети на SIP / SOP (нажмите, чтобы увеличить).

Напряжение сети на рабочих частях. К рабочим деталям типа F предъявляются дополнительные требования IEC 60601-1. Ток утечки каждой части измеряется при подаче 110% сетевого напряжения через токоограничивающий резистор. Во время этого теста части входа и выхода сигнала заземляются. Полярность сетевого напряжения к приложенной части меняется на обратную, и ток утечки измеряется для обоих условий. См. Рисунок 7.

Напряжение сети на сигнальном входе и сигнальном выходе.Рабочие части типа B должны иметь дополнительное состояние единичного отказа, когда 110% сети подается на все части входа и выхода сигнала во время измерения утечки через пациента. Это применимо только к рабочим деталям типа B, если проверка цепи показывает, что существует угроза безопасности. См. Рисунок 8.

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

Национальные различия по току утечки

Рис. 9. Вспомогательный ток утечки пациента (щелкните, чтобы увеличить).

США. Между стандартами IEC 60601-1 и UL 60601-1 есть три основных различия в измерении тока утечки. ⁴ Стандарт UL включает требования NFPA 99 и ANSI / AAMI ES1, «Безопасные пределы тока для электромедицинских аппаратов.” ⁵ NFPA 99 включает в себя требования национального электротехнического кодекса США (NFPA 70), относящиеся к медицинским учреждениям. ANSI / AAMI ES1 определяет безопасные пределы тока утечки в трех параметрах: частота, функция оборудования и преднамеренный контакт с пациентом. Вероятно, что ANSI / AAMI ES1 будет отозван, когда третье издание IEC 60601-1 будет принято в США ANSI / AAMI.

UL 60601-1 различает оборудование для ухода за пациентами (6 футов вокруг и 7.5 футов над пациентом) и оборудование, не относящееся к пациенту, для испытаний на ток утечки. Типичные значения тока утечки для устройства класса I составляют 300 мкА в зоне ухода за пациентом и 500 мкА за ее пределами. Для устройства класса II значения составляют 150 мкА в зоне ухода за пациентом и 250 мкА за ее пределами.

UL 60601-1 позволяет одновременно отключать заземляющий провод и одно из подключений питания для оборудования, не предназначенного для ухода за пациентами. Это будет считаться двойной ошибкой согласно IEC 60601-1.

Европейский Союз и Австралия. В настоящее время нет различий между IEC 60601-1, EN 60601-1 и AS / NZS 3200.1 в отношении тока утечки. ⁶

Рис. 10. Схема измерения тока утечки в Японии (щелкните, чтобы увеличить).

Канада. Есть одно различие между IEC 60601-1 и CAN / CSA C22.2 № 601.1 в отношении тока утечки. ⁷ Если медицинское изделие должно иметь маркировку CSA, необходимы испытания на герметичность производственной линии.

Япония. Между IEC 60601-1 и JIS T 0601-1 есть лишь несколько незначительных различий по току утечки. ⁸

Чтобы различать различные измерения утечки пациента (нормальные и одиночные неисправности), JIS T 0601-1 добавляет уточняющую номенклатуру Patient Leakage I для утечки пациента в нормальном состоянии, Patient Leakage II для утечки пациента в состояние единичного отказа сетевого напряжения на SIP / SOP и утечка пациента III для утечки через пациента в состоянии единичного отказа сетевого напряжения на плавающей рабочей части пациента.

JIS T 0601-1 также указывает, что риск внешнего напряжения на SIP / SOP очень низок для устройства, которое было оценено в соответствии с IEC 60601-1-1 с его принадлежностями. Следовательно, измерения тока утечки в условиях единичного отказа с сетью, подключенной к SIP / SOP, не должны выполняться для такого продукта.

В Японии существует только одно существенное национальное отклонение для измерения тока утечки. Для токов утечки с частотной составляющей более 1 кГц токи утечки не должны превышать 10 мкА.Используется измерительный прибор IEC 60601-1, но с резистором 10 кОм, отключенным переключателем. См. Рис. 10.

Заключение

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

Описанные здесь испытания на герметичность основаны на требованиях к испытаниям на соответствие МЭК 60601-1. В этом стандарте нет особых требований к измерениям тока утечки во время производственных испытаний. Тем не менее, производитель должен провести такое тестирование. Это может быть надлежащая производственная практика, стандартные производственные испытания или отбор образцов.

Ссылки

1. IEC 60601-1, «Медицинское электрическое оборудование. Часть 1: Общие требования к безопасности и основным характеристикам» (Женева: Международная электротехническая комиссия, 1995).
2. Леонард Эйснер, Роберт М. Браун и Дэн Моди, «Введение в IEC 60601-1», MD&DI 25, вып. 9 (2003): 48–58.
3. Национальная ассоциация противопожарной защиты, NFPA 99, «Стандарт для медицинских учреждений» (Куинси, Массачусетс: NFPA, 2002).
4. UL 60601-1, «Медицинское электрическое оборудование, часть 1: Общие требования безопасности» (Northbrook, IL: Underwriters Laboratories, 2003).
5. ANSI / AAMI ES1: 1993, «Безопасные пределы тока для электромедицинских аппаратов» (Арлингтон, Вирджиния: AAMI, 1993).
6. AS / NZS 3200.1, «Медицинские электрические системы» (Сидней: Стандарты Австралии, 1998).
7. CAN / CSA-C22.2 NO. 601.1, «Медицинское электрическое оборудование — Часть 1: Общие требования безопасности» (Миссиссауга, Онтарио, Канада: Канадская ассоциация стандартов, 1995).
8. JIS T 0601-1, «Медицинское электрическое оборудование. Часть 1: Общие требования безопасности» (Токио: Японская ассоциация стандартов, 2000).

Авторские права © 2004 Медицинское оборудование и диагностическая промышленность

Прямая маршрутизация телефонной системы — Microsoft Teams

• 28.01.2019
• 18 минут на чтение

• Применимо к:

  Microsoft Teams

В этой статье

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

Обработка входящего запроса: поиск арендатора и пользователя

Перед обработкой входящего или исходящего вызова между SIP Proxy и SBC происходит обмен сообщениями OPTIONS. Эти сообщения OPTIONS позволяют прокси-серверу SIP предоставлять разрешенные возможности для SBC.Важно, чтобы согласование OPTIONS было успешным (ответ 200OK), чтобы обеспечить дальнейшую связь между SBC и SIP Proxy для установления вызовов. Заголовки SIP в сообщениях OPTIONS для прокси-сервера SIP представлены в качестве примера ниже:

Примечание

Заголовки SIP не содержат информацию о пользователе в используемом SIP URI. Согласно RFC 3261, раздел 19.1.1, часть userinfo URI является необязательной и МОЖЕТ отсутствовать, если хост назначения не имеет представления о пользователях или когда сам хост является идентифицируемым ресурсом.Если знак @ присутствует в SIP URI, пользовательское поле НЕ ДОЛЖНО быть пустым.

При входящем вызове прокси-сервер SIP должен найти арендатора, которому предназначен вызов, и найти конкретного пользователя в этом арендаторе. Администратор арендатора может настроить номера без DID, например +1001, для нескольких арендаторов. Поэтому важно найти конкретного клиента, на котором будет выполняться поиск номеров, поскольку номера, не относящиеся к DID, могут быть одинаковыми в нескольких организациях Microsoft 365 или Office 365.

В этом разделе описывается, как прокси-сервер SIP находит арендатора и пользователя и выполняет аутентификацию SBC при входящем соединении.

Ниже приведен пример сообщения приглашения SIP при входящем вызове:

Название параметра	Пример значения
Request-URI	INVITE sip: [email protected] SIP /2.0
Через заголовок	Через: SIP / 2.0 / TLS sbc1.adatum.biz:5058;alias;branch=z9hG4bKac2121518978
Заголовок Max-Forwards	Максимальное количество нападающих: 68
Из заголовка	Из заголовка От:
В заголовок	Кому: sip: [email protected]
Заголовок CSeq	CSeq: 1 INVITE
Заголовок контакта	Обращение:

При получении приглашения прокси-сервер SIP выполняет следующие шаги:

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

   • Вариант 1. Полное доменное имя, указанное в заголовке «Контакт», должно совпадать с альтернативным именем общего имени / альтернативного имени субъекта представленного сертификата.

   • Вариант 2. Доменная часть FQDN-имени, представленного в заголовке Contact (например, adatum.biz в FQDN-имени sbc1.adatum.biz), должна соответствовать значению подстановочного знака в Common Name / Subject Alternative Name (например, *. adatum.biz).

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

   Проверьте, зарегистрировано ли полное доменное имя из заголовка контакта (sbc1.adatum.biz) как DNS-имя в любой организации Microsoft 365 или Office 365.Если он найден, поиск пользователя выполняется в клиенте, у которого полное доменное имя SBC зарегистрировано как доменное имя. Если не найден, применяется шаг 3.

3. Шаг 3 применяется, только если шаг 2 завершился неудачно.

   Удалите часть хоста из FQDN, представленного в заголовке Contact (FQDN: sbc12.adatum.biz, после удаления части хоста: adatum.biz), и проверьте, зарегистрировано ли это имя как DNS-имя в любом Microsoft 365 или Организация Office 365. Если он найден, поиск пользователя выполняется в этом клиенте.Если не найден, вызов не выполняется.

4. Используя номер телефона, представленный в Request-URI, выполните обратный поиск номера в арендаторе, найденном на шаге 2 или 3. Сопоставьте представленный номер телефона с URI пользователя SIP в арендаторе, найденном на предыдущем шаге.

5. Применить настройки соединительной линии. Найдите параметры, установленные администратором клиента для этого SBC.

   Microsoft не поддерживает наличие стороннего прокси-сервера SIP или сервера пользовательского агента между прокси-сервером Microsoft SIP и парным SBC, которые могут изменить URI запроса, созданный парным SBC.

   Требования к двум поискам (шаги 2 и 3), необходимые для сценария, в котором один SBC подключен ко многим клиентам (сценарий оператора связи), рассматриваются далее в этой статье.

Подробные требования к заголовку контакта и Request-URI

Контактный коллектор

Для всех входящих SIP-сообщений (OPTIONS, INVITE) на прокси-сервер Microsoft SIP заголовок Contact должен содержать парное полное доменное имя SBC в имени хоста URI, как показано ниже:

Синтаксис: Контакт:

Согласно RFC 3261, раздел 11.1, поле заголовка контакта МОЖЕТ присутствовать в сообщении OPTIONS. В прямой маршрутизации заголовок контакта обязателен. Для сообщений INVITE в формате, указанном выше, для сообщений OPTIONS информация о пользователе может быть удалена из SIP URI, и только полное доменное имя может быть отправлено в следующем формате:

Синтаксис: Контакт:

Это имя (FQDN) также должно быть в полях «Общее имя» или «Альтернативное имя субъекта» представленного сертификата. Microsoft поддерживает использование подстановочных знаков имени (имен) в полях сертификата Common Name или Subject Alternative Name.

Поддержка подстановочных знаков описана в RFC 2818, раздел 3.1. В частности:

«Имена могут содержать подстановочный знак *, который считается соответствующим любому отдельному компоненту доменного имени или фрагменту компонента. Например, * .a.com соответствует foo.a.com, но не bar.foo.a.com. F *. com соответствует foo.com, но не bar.com «.

Если SBC отправляет более одного значения в заголовке Contact, представленном в сообщении SIP, используется только часть FQDN первого значения заголовка Contact.

Как правило, для прямой маршрутизации важно, чтобы для заполнения SIP URI вместо IP использовалось полное доменное имя. Входящее сообщение INVITE или OPTIONS на прокси-сервер SIP с заголовком Contact, где имя хоста представлено IP, а не FQDN, в соединении будет отказано с 403 Forbidden.

Request-URI

Для всех входящих вызовов Request-URI используется для сопоставления телефонного номера с пользователем.

В настоящее время Телефонный номер должен содержать знак плюса (+), как показано в следующем примере.

  ПРИГЛАСИТЬ sip: [email protected] SIP /2.0
  

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

Согласно RFC 3261, раздел 8.1.1.8, заголовок Contact требуется в любом запросе, который может привести к новому диалоговому окну. Маршрут записи требуется только в том случае, если прокси-сервер хочет оставаться на пути будущих запросов в диалоговом окне.Если прокси-сервер SBC используется с оптимизацией локальных носителей для прямой маршрутизации, необходимо настроить маршрут записи, поскольку прокси-сервер SBC должен оставаться в маршруте.

Microsoft рекомендует использовать только заголовок контакта, если прокси-сервер SBC не используется:

• Согласно RFC 3261, раздел 20.30, Record-Route используется, если прокси-сервер хочет оставаться на пути будущих запросов в диалоговом окне, что несущественно, если прокси-сервер SBC не настроен, поскольку весь трафик проходит между прокси-сервером Microsoft SIP и парный SBC.

• Прокси-сервер Microsoft SIP использует только заголовок Contact (не Record-Route) для определения следующего прыжка при отправке параметров исходящего запроса ping. Настройка только одного параметра (Контакт) вместо двух (Контакт и Запись-Маршрут) упрощает администрирование, если прокси-сервер SBC не используется.

Для вычисления следующего перехода прокси-сервер SIP использует:

• Приоритет 1. Маршрут записи верхнего уровня. Если Record-Route верхнего уровня содержит имя FQDN, имя FQDN используется для исходящего соединения в диалоговом окне.

• Приоритет 2. Заголовок контакта. Если Record-Route не существует, прокси-сервер SIP будет искать значение заголовка Contact, чтобы установить исходящее соединение. (Это рекомендуемая конфигурация.)

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

Использование имени FQDN в контакте или маршруте записи

Использование IP-адреса не поддерживается ни в Record-Route, ни в Contact.Единственный поддерживаемый вариант — это полное доменное имя, которое должно совпадать либо с общим именем, либо с альтернативным именем субъекта сертификата SBC (поддерживаются подстановочные знаки в сертификате).

• Если IP-адрес представлен в Record-route или Contact, проверка сертификата не удалась, и вызов не удался.

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

Входящий вызов: описание диалога SIP

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

Название параметра	Режим без байпаса	Режим байпаса
Медиа-кандидаты в 183 и 200 сообщениях из	Медиа-процессоры	Клиенты
Количество 183 сообщений, которые SBC может получить	Один за сеанс	Несколько
Звонок возможен с предварительным ответом (183)	Есть	Есть
Звонок возможен без предварительного ответа (183)	Есть	Есть

Обходной поток без среды

Пользователь Teams может иметь несколько конечных точек одновременно.Например, клиент Teams для Windows, клиент Teams для iPhone и телефон Teams (клиент Teams для Android). Каждая конечная точка может сигнализировать об остановке HTTP следующим образом:

• Ход вызова — преобразуется прокси-сервером SIP в сообщение 180 SIP. При получении сообщения 180 SBC должен генерировать локальный звонок.

• Ответ мультимедиа — преобразован прокси-сервером SIP в сообщение 183 с кандидатами мультимедиа в протоколе описания сеанса (SDP). При получении сообщения 183 SBC ожидает подключения к кандидатам мультимедиа, полученным в сообщении SDP.

  Примечание

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

• Вызов принят — преобразован прокси-сервером SIP в сообщение 200 SIP с SDP. При приеме сообщения 200 ожидается, что SBC отправит и получит мультимедийные данные предоставленным кандидатам SDP и от них.

  Примечание

  Direct Routing не поддерживает приглашение с отложенным предложением (приглашение без SDP).

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

1. При получении первого приглашения от SBC прокси-сервер SIP отправляет сообщение «SIP SIP / 2.0 100 Trying «и уведомляет все конечные точки пользователей о входящем вызове.

2. После уведомления каждая конечная точка начнет звонить и отправлять сообщения «Ход выполнения вызова» на прокси-сервер SIP. Поскольку у пользователя Teams может быть несколько конечных точек, прокси-сервер SIP может получать несколько сообщений о ходе выполнения вызова.

3. Для каждого сообщения о ходе вызова, полученного от клиентов, прокси-сервер SIP преобразует сообщение о ходе вызова в сообщение SIP «SIP SIP / 2.0 180 Trying».Интервал отправки таких сообщений определяется интервалом получения сообщений от контроллера вызовов. На следующей диаграмме прокси-сервером SIP генерируются два сообщения 180. Эти сообщения поступают от двух конечных точек Teams пользователя. Каждый клиент имеет уникальный идентификатор тега. Каждое сообщение, поступающее от другой конечной точки, будет отдельным сеансом (параметр «тег» в поле «Кому» будет другим). Но конечная точка может не сгенерировать сообщение 180 и сразу же отправить сообщение 183, как показано на следующей диаграмме.

4. Как только конечная точка сгенерирует сообщение Media Answer с IP-адресами кандидатов мультимедиа конечной точки, прокси-сервер SIP преобразует полученное сообщение в сообщение «SIP 183 Session Progress», в котором SDP от клиента заменяется SDP от Media Processor. На следующей диаграмме конечная точка из ответвления 2 ответила на вызов. Если транк не обходится, сообщение 183 SIP генерируется только один раз (либо Ring Bot, либо Client End Point). 183 может появиться на существующей развилке или начать новую.

5. Сообщение о приеме вызова отправляется с последними кандидатами конечной точки, которая приняла вызов. Сообщение о приеме вызова преобразуется в сообщение SIP 200.

Несколько конечных точек звонят без предварительного ответа

1. При получении первого приглашения от SBC прокси-сервер SIP отправляет сообщение «SIP SIP / 2.0 100 Trying» и уведомляет все конечные точки пользователей о входящем вызове.

2. После уведомления каждая конечная точка начнет звонить и отправлять сообщение «Ход выполнения вызова» на прокси-сервер SIP.Поскольку у пользователя Teams может быть несколько конечных точек, прокси-сервер SIP может получать несколько сообщений о ходе вызова.

3. Для каждого сообщения о ходе вызова, полученного от клиентов, прокси-сервер SIP преобразует сообщение о ходе вызова в сообщение SIP «SIP SIP / 2.0 180 Trying». Интервал отправки сообщений определяется интервалом получения сообщений от контроллера вызовов. На рисунке ниже показаны два сообщения 180, сгенерированные прокси-сервером SIP, что означает, что пользователь вошел в три клиента Teams, и каждый клиент отправляет информацию о ходе вызова.Каждое сообщение будет отдельным сеансом (параметр «тег» в поле «Кому» отличается)

4. Сообщение о приеме вызова отправляется с последними кандидатами конечной точки, которая приняла вызов. Сообщение о приеме вызова преобразуется в сообщение SIP 200.

Обводной поток среды

Те же сообщения (100 попыток, 180, 183) используются в сценарии обхода мультимедиа.

На схеме ниже показан пример обходного потока вызовов.

Примечание

Медиа-кандидаты могут поступать с разных конечных точек.

Заменяет опцию

SBC должен поддерживать приглашение с заменой.

Размер соображений SDP

Интерфейс прямой маршрутизации может отправить сообщение SIP размером более 1500 байт. В первую очередь это обусловлено размером SDP. Однако, если за SBC есть магистраль UDP, она может отклонить сообщение, если оно перенаправлено с прокси-сервера Microsoft SIP на магистраль без изменений.Microsoft рекомендует удалять некоторые значения в SDP на SBC при отправке сообщения по магистральным каналам UDP. Например, кандидаты ICE или неиспользуемые кодеки могут быть удалены.

Перевод вызова

Direct Routing поддерживает два метода передачи вызовов:

• Вариант 1. Процессы прокси-сервера SIP обращаются от клиента локально и действуют как Рефери, как описано в разделе 7.1 RFC 3892.

  При использовании этой опции прокси-сервер SIP завершает передачу и добавляет новое приглашение.

• Вариант 2. Прокси-сервер SIP отправляет ссылку на SBC и действует как отправитель, как описано в разделе 6 RFC 5589.

  С этой опцией прокси-сервер SIP отправляет ссылку на SBC и ожидает, что SBC полностью обработает передачу.

Прокси-сервер SIP выбирает метод на основе возможностей, сообщаемых SBC. Если SBC указывает, что он поддерживает метод «Refer», прокси-сервер SIP будет использовать вариант 2 для передачи вызовов.

Ниже приведен пример SBC, отправляющего сообщение о том, что поддерживается метод ссылки:

  РАЗРЕШИТЬ: ПРИГЛАСИТЬ, ОПЦИИ, ИНФОРМАЦИЯ, ПОКА, ОТМЕНИТЬ, ПОДТВЕРДИТЬ, НАПРАВИТЬ, ОБНОВИТЬ, ОБНОВИТЬ, ПОДПИСАТЬСЯ, УВЕДОМЛЕНИЕ
  

Если SBC не указывает, что «Ссылка» является поддерживаемым методом, прямая маршрутизация будет использовать Вариант 1 (прокси-сервер SIP действует как Рефери).SBC также должен сигнализировать о том, что он поддерживает метод уведомления:

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

  РАЗРЕШИТЬ: ПРИГЛАСИТЬ, ПОДТВЕРДИТЬ, ОТМЕНИТЬ, ПОКА, ИНФОРМАЦИЯ, УВЕДОМЛЕНИЕ, ПРЕДУПРЕЖДЕНИЕ, ОБНОВЛЕНИЕ, ОПЦИИ
  

SIP-прокси обрабатывает обращение от клиента локально и действует как рефери

Если SBC указал, что метод Refer не поддерживается, прокси-сервер SIP действует как рефери.

Запрос ссылки, исходящий от клиента, будет завершен на прокси-сервере SIP.(Запрос ссылки от клиента показан как «Переадресация вызова Дейву» на следующей диаграмме. Дополнительные сведения см. В разделе 7.1 RFC 3892.

Прокси-сервер SIP отправляет ссылку на SBC и действует как отправитель

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

Стандарт поясняется в разделе 6 RFC 5589.Соответствующие RFC:

Этот параметр предполагает, что прокси-сервер SIP действует как отправитель и отправляет сообщение «Ссылка» на SBC. SBC действует как получатель и обрабатывает ссылку для создания нового предложения о передаче. Возможны два случая:

• Вызов переведен на внешнего участника PSTN.
• Вызов передается от одного пользователя Teams другому пользователю Teams в том же клиенте через SBC.

Если вызов передается от одного пользователя Teams к другому через SBC, ожидается, что SBC выдаст новое приглашение (запустит новый диалог) для цели передачи (пользователя Teams), используя информацию, полученную в сообщении «Ссылка».

Чтобы заполнить поля To / Transferor для транзакции запроса внутри, прокси-сервер SIP должен передать эту информацию внутри заголовков REFER-TO / REFERRED-BY.

Прокси-сервер SIP сформирует REFER-TO в виде URI-адреса SIP, состоящего из полного доменного имени прокси-сервера SIP в имени хоста и одного из следующих значений:

• Телефонный номер E.164 в части имени пользователя URI в случае, если целью передачи является номер телефона, или

• Параметры x-m и x-t, кодирующие MRI цели полной передачи и идентификатор клиента соответственно

Заголовок REFERRED-BY — это SIP URI с закодированным в нем MRI передающей стороны, а также ID клиента передающей стороны и другие параметры контекста передачи, как показано в следующей таблице:

Параметр	Значение	Описание
х м	МРТ	Полная МРТ передающей / переносящей мишени в соответствии с CC
х-т	ID арендатора	x-t Tenant ID Дополнительный идентификатор арендатора, заполненный CC
х-ти	Идентификатор корреляции передающей стороны	Идентификатор корреляции звонка плательщику
x-tt	URI передачи целевого вызова	URI замены кодированного вызова

Размер заголовка ссылки в этом случае может составлять до 400 символов.SBC должен поддерживать обработку сообщений Refer с размером до 400 символов.

Таймер сеанса

Прокси-сервер SIP поддерживает (всегда предлагает) таймер сеанса для вызовов без обхода, но не предлагает его для вызовов с обходом. Использование таймера сеанса SBC не является обязательным.

Использование параметра Request-URI user = phone

Прокси-сервер SIP анализирует Request-URI, и, если присутствует параметр user = phone, служба обрабатывает Request-URI как номер телефона, сопоставляя номер с пользователем.Если параметр не указан, прокси-сервер SIP применяет эвристику для определения типа пользователя Request-URI (номер телефона или SIP-адрес).

Microsoft рекомендует всегда применять параметр user = phone, чтобы упростить процесс настройки вызова.

Заголовок исторической информации

Заголовок History-Info используется для перенаправления SIP-запросов и «предоставляет стандартный механизм для сбора информации истории запросов, чтобы обеспечить широкий спектр услуг для сетей и конечных пользователей.Для получения дополнительной информации см. RFC 4244 — раздел 1.1. Для Microsoft Phone System этот заголовок используется в сценариях Simulring и Call Forwarding.

При отправке историческая информация включается следующим образом:

• Прокси-сервер SIP вставит параметр, содержащий связанный номер телефона, в отдельные записи History-Info, которые составляют заголовок History-Info, отправляемый в контроллер PSTN. Используя только записи с параметром номера телефона, контроллер PSTN перестроит новый заголовок History-Info и передаст его провайдеру магистрали SIP через прокси-сервер SIP.

• Заголовок History-Info будет добавлен для случаев одновременной переадресации звонков и звонков.

• Заголовок History-Info не добавляется для случаев передачи вызовов.

• Отдельная запись истории в реконструированном заголовке History-Info будет содержать параметр номера телефона в сочетании с полным доменным именем прямой маршрутизации (sip.pstnhub.microsoft.com), установленным в качестве хостовой части URI; параметр «user = phone» будет добавлен как часть SIP URI.Любые другие параметры, связанные с исходным заголовком History-Info, за исключением параметров контекста телефона, будут переданы в реконструированном заголовке History-Info.

  Примечание

  Записи, которые являются частными (как определено механизмами, определенными в разделе 3.3 RFC 4244), будут пересылаться как есть, потому что провайдер магистрали SIP является доверенным партнером.

• Информация о входящей истории игнорируется.

Ниже приведен формат заголовка History-info, отправляемого прокси-сервером SIP:

  ;index=1.2,
  

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

Пример заголовка:

  История:
; index = 1
; index = 1.1
  

История-информация защищена обязательным механизмом TLS.

Подключение SBC к механизму прямой маршрутизации и аварийного переключения

См. Раздел Механизм переключения при отказе для сигнализации SIP в Плане прямой маршрутизации.

Retry-After

Если центр обработки данных с прямой маршрутизацией занят, служба может отправить на SBC сообщение Retry-After с интервалом в одну секунду. Когда SBC получает сообщение 503 с заголовком Retry-After в ответ на INVITE, SBC должен разорвать это соединение и попробовать следующий доступный центр обработки данных Microsoft.

Обработка повторных попыток (ответ 603)

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

SBC должен поддерживать перезапуск ICE, как описано в RFC 5245, раздел 9.1.1.1.

Перезапуск в Direct Routing осуществляется в соответствии со следующими параграфами RFC:

Чтобы перезапустить ICE, агент ДОЛЖЕН изменить и ice-pwd, и ice-ufrag для медиапотока в предложении.Обратите внимание, что допустимо использовать атрибут уровня сеанса в одном предложении, но предоставлять тот же самый ice-pwd или ice-ufrag в качестве атрибута уровня носителя в последующем предложении. Это не изменение пароля, а просто изменение его представления и не вызывает перезапуска ICE.

Агент устанавливает остальные поля в SDP для этого медиапотока, как это было бы в первоначальном предложении этого медиапотока (см. Раздел 4.3). Следовательно, набор кандидатов МОЖЕТ включать в себя некоторых, ни одного или всех предыдущих кандидатов для этого потока и МОЖЕТ включать в себя совершенно новый набор кандидатов, собранный, как описано в Разделе 4.1.1.

Если вызов был первоначально установлен с обходом мультимедиа, а вызов передается на клиент Skype для бизнеса, для прямой маршрутизации необходимо вставить мультимедийный процессор — это связано с тем, что прямую маршрутизацию нельзя использовать с клиентом Skype для бизнеса с обходом мультимедиа. . Прямая маршрутизация запускает процесс перезапуска ICE, изменяя ice-pwd и ice-ufrag и предлагая новых медиа-кандидатов в повторном приглашении.

% PDF-1.4 % 2 0 obj > поток B \ ogoa`cE.0U3 63 * UNT9cDe2 = 56 + = C`e5 \ o> P — # (DaW!; SRU`IS \ i

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

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

Решения

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

Однако, поскольку услуги VoIP по-прежнему зависят от интернет-соединений, невозможно полностью устранить прерывания, вызванные задержкой.Самый большой из них — ужасный ДЖИТТЕР.

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

VoIP = Пакеты данных

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

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

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

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

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

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

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

Что такое задержка?

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

Задержка

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

Говоря простым языком, и в частности для VoIP, задержка обычно возникает двумя способами:

• Задержка между говорящим человеком и получателем на другом конце телефона, слышащим эти слова
• Время, необходимое VoIP-решению для фактической обработки и преобразования голосовой информации в пакеты данных

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

В текущих обстоятельствах решения VoIP, а также современные сетевые технологии и оборудование просто не могут принимать вводимые данные (например, ваш голос), анализировать их, преобразовывать в пакеты, передавать их по воздуху в другое физическое место во времени и пространство, и «развернуть» этот пакет данных, чтобы передать его как голосовую запись другому человеку, абсолютно мгновенно — или со скоростью света.Мы просто пока не можем этого сделать.

Что увеличивает задержку?

Задержка может быть увеличена множеством различных факторов, в том числе:

• Сетевое оборудование — Например, некоторые маршрутизаторы могут передавать данные только с ограниченной скоростью и имеют ограниченную вычислительную мощность.

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

• Сетевое программное обеспечение и конфигурация — Программные брандмауэры, которые неправильно настроены, настройки качества обслуживания или настройки NAT могут задерживать передачу данных
• Расположение — Самая большая и наиболее частая причина задержки — расстояние. Чем дальше, тем больше времени потребуется для передачи этих данных.
• Перегрузка — Думайте о своей сети как о шоссе, а о пакетах данных как о машинах.Пропускная способность — это размер дороги, скорость сети — это скорость движения автомобилей, а задержка — это перегрузка, вызванная дополнительным трафиком. Управление позволяет избежать переподписки.

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

Измерение задержки с помощью теста Ping

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

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

Тест ping действительно прост: чтобы измерить время, которое требуется вашей сети для отправки и получения пакета данных, вы можете указать своему устройству отправить «ping», очень простой пакет данных, другому устройству. Затем устройство-получатель отправляет ответный «пинг», и время, необходимое для выполнения всего этого, измеряется, чаще всего в миллисекундах (мс) .

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

Онлайн-тесты Ping

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

С помощью теста Ping мы хотим отправить несколько последовательных запросов ping. Затем следует усреднить рассчитанную по времени задержку каждого эхо-запроса, чтобы получить общую среднюю задержку. Вы можете сделать это с помощью онлайн-инструментов, например:

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

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

Ручное Ping-тестирование

Как указано в моем сообщении о потере пакетов, пользователи могут вручную отправлять эхо-запросы через командную строку Windows с помощью команды ping. Это отправит команду «ping» на выбранный вами IP-адрес или веб-сайт и вернет ответ. Задержка — это количество времени, которое требуется для отправки и получения сигнала (или пинга) в миллисекундах.

Открыв командную строку, вы должны ввести команду:

ping -n 100 <имя хоста>

Имя хоста — это ваш собственный выбор веб-сайта или сервера.Вы даже можете просто использовать google.com, чтобы упростить процесс. Эта команда отправит 100 пингов на выбранный вами хост и, надеюсь, вернет 100 пингов. Но если вы отправляете 100, а получено только 50, вы обнаружили 50% потерю пакетов. По завершении пинга вы должны получить сообщение, подобное этому:

100 пакетов передано, 50 получено, 50% потеря пакетов, время 201 мс

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

Что такое джиттер?

Хотя джиттер напрямую связан с задержкой, это не совсем то же самое, что и задержка. Фактически, Cisco определяет джиттер как «вариацию задержки полученных пакетов», что означает, что джиттер на самом деле представляет собой различие в задержке (или задержке) между каждым пакетом данных.

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

Что увеличивает джиттер?

Проще говоря, джиттер наиболее вероятен и обычно связан с увеличенной задержкой в ​​сети, которая возникает из-за увеличения перегрузки. Как я уже упоминал выше:

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

Недостаточная пропускная способность для обработки вызовов VoIP приведет к тому, что пакеты будут отброшены или доставлены не по порядку.

• Беспроводные сети — в то время как беспроводная сеть обеспечивает мобильность и освобождает нас от кабелей, проходящих через офис, есть вероятность, что у вас будет ухудшенное сетевое соединение.Хотя Wi-Fi подходит для наших мобильных устройств, он не всегда достаточно мощный или стабильный, чтобы использовать его для телефонных звонков.
• Плохое оборудование — наши интернет-сети обычно состоят из пары различных аппаратных средств, по крайней мере, модема и маршрутизатора, а иногда и коммутаторов. Плохое оборудование, такое как устаревший модем, поврежденный кабель Ethernet или неправильно настроенный маршрутизатор, может привести к проблемам с качеством связи.

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

Измерение джиттера с помощью теста скорости

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

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

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

Задержка, джиттер и VoIP

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

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

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

Итак, что приемлемо?

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

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

«Задержка односторонней передачи (из уст в ухо) не должна превышать 150 мс (согласно рекомендации G.114 [протокол])».

Это означает, что когда вы проверяете связь с другим пользователем или сетью, это не должно занимать более 150 мсек, чтобы достичь этого получателя. Помимо этого, Cisco также рекомендует:

«Задержка приема-передачи не должна превышать 300 мс, когда это возможно.”

По мере увеличения перегрузки и, следовательно, задержки увеличивается и джиттер. Опять же, согласно Cisco:

«Средний односторонний джиттер должен быть меньше 30 мсек»

Следовательно, мы смотрим на допустимые пределы следующим образом:

Макс. Односторонняя задержка: 150 мс

Макс. Задержка туда и обратно: 300 мс

Макс. Джиттер: 30 мс

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

Улучшение ситуации

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

Это могло бы решить проблему, но это могло быть не единственной проблемой.

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

1. Обновленное и доступное оборудование

Внутренняя сеть состоит из большого количества физических аппаратных компонентов. Физические межсетевые экраны, пограничные контроллеры сеансов, аналого-цифровые преобразователи, физические сетевые кабели и линии, модемы, коммутаторы, компоненты Wi-Fi — все вместе создает вашу сеть.

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

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

2. Не пропускайте маршрутизатор

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

Маршрутизаторы

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

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

3. Настройка QoS и других параметров

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

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

Услуги

VoIP также используют «кодеки» для преобразования этих данных в голоса и из них. Некоторые кодеки могут накладывать ограничения на ваши вызовы или даже увеличивать задержку.

4. Будьте осторожны с буферами джиттера

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

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

5. Инвестируйте в достаточную пропускную способность

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

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

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

Итог

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

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

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

% PDF-1.6 % 758 0 объект > эндобдж xref 758 212 0000000016 00000 н. 0000005020 00000 н. 0000005147 00000 п. 0000005183 00000 п. 0000005482 00000 н. 0000005628 00000 н. 0000005769 00000 н. 0000006122 00000 н. 0000006532 00000 н. 0000007071 00000 н. 0000007515 00000 н. 0000007920 00000 н. 0000008266 00000 н. 0000008767 00000 н. 0000009231 00000 п. 0000009732 00000 н. 0000009943 00000 н. 0000010034 00000 п. 0000053875 00000 п. 0000054104 00000 п. 0000054612 00000 п. 0000054716 00000 п. 0000104647 00000 н. 0000104871 00000 н. 0000105518 00000 п. 0000105632 00000 н. 0000105664 00000 н. 0000105750 00000 н. 0000105824 00000 н. 0000107857 00000 н. 0000107929 00000 п. 0000108063 00000 н. 0000108177 00000 н. 0000108354 00000 п. 0000108467 00000 н. 0000108589 00000 н. 0000108759 00000 н. 0000108894 00000 н. 0000109015 00000 н. 0000109212 00000 п. 0000109344 00000 п. 0000109482 00000 н. 0000109679 00000 н. 0000109827 00000 н. 0000109969 00000 н. 0000110166 00000 п. 0000110312 00000 п. 0000110466 00000 н. 0000110639 00000 п. 0000110802 00000 н. 0000110977 00000 н. 0000111154 00000 н. 0000111357 00000 н. 0000111509 00000 н. 0000111624 00000 н. 0000111779 00000 п. 0000111917 00000 н. 0000112020 00000 н. 0000112204 00000 н. 0000112355 00000 н. 0000112528 00000 н. 0000112646 00000 н. 0000112770 00000 н. 0000112918 00000 н. 0000113068 00000 н. 0000113245 00000 н. 0000113354 00000 н. 0000113477 00000 н. 0000113666 00000 н. 0000113774 00000 н. 0000113892 00000 н. 0000114059 00000 н. 0000114172 00000 н. 0000114273 00000 н. 0000114451 00000 п. 0000114563 00000 н. 0000114665 00000 н. 0000114793 00000 н. 0000114920 00000 н. 0000115050 00000 н. 0000115191 00000 н. 0000115318 00000 п. 0000115464 00000 н. 0000115561 00000 н. 0000115707 00000 н. 0000115817 00000 н. 0000115945 00000 н. 0000116086 00000 н. 0000116206 00000 н. 0000116317 00000 н. 0000116457 00000 н. 0000116614 00000 н. 0000116739 00000 н. 0000116878 00000 н. 0000116988 00000 н. 0000117129 00000 н. 0000117259 00000 н. 0000117388 00000 н. 0000117535 00000 н. 0000117704 00000 н. 0000117853 00000 н. 0000117984 00000 н. 0000118164 00000 н. 0000118307 00000 н. 0000118442 00000 н. 0000118617 00000 н. 0000118751 00000 н. 0000118880 00000 н. 0000119021 00000 н. 0000119204 00000 н. 0000119331 00000 п. 0000119458 00000 н. 0000119598 00000 н. 0000119728 00000 н. 0000119891 00000 н. 0000120004 00000 н. 0000120117 00000 н. 0000120247 00000 н. 0000120376 00000 н. 0000120505 00000 н. 0000120626 00000 н. 0000120762 00000 н. 0000120902 00000 н. 0000121033 00000 н. 0000121191 00000 н. 0000121358 00000 н. 0000121796 00000 н. 0000122081 00000 н. 0000122413 00000 н. 0000122558 00000 н. 0000122703 00000 н. 0000122883 00000 н. 0000123067 00000 н. 0000123245 00000 н. 0000123496 00000 н. 0000123637 00000 н. 0000123915 00000 н. 0000124127 00000 н. 0000124341 00000 п. 0000124503 00000 н. 0000124723 00000 н. 0000124966 00000 н. 0000125212 00000 н. 0000125485 00000 н. 0000125670 00000 н. 0000125841 00000 н. 0000126031 00000 н. 0000126208 00000 н. 0000126407 00000 н. 0000126667 00000 н. 0000126866 00000 н. 0000127037 00000 н. 0000127246 00000 н. 0000127414 00000 н. 0000127608 00000 н. 0000127753 00000 н. 0000127938 00000 п. 0000128113 00000 н. 0000128284 00000 н. 0000128447 00000 н. 0000128653 00000 н. 0000128838 00000 н. 0000129023 00000 н. 0000129180 00000 н. 0000129410 00000 н. 0000129586 00000 н. 0000129755 00000 н. 0000129925 00000 н. 0000130078 00000 н. 0000130208 00000 н. 0000130351 00000 п. 0000130498 00000 п. 0000130649 00000 н. 0000130813 00000 н. 0000130975 00000 н. 0000131129 00000 н. 0000131265 00000 н. 0000131402 00000 н. 0000131528 00000 н. 0000131660 00000 н. 0000131779 00000 п. 0000131935 00000 н. 0000132086 00000 н. 0000132243 00000 н. 0000132384 00000 н. 0000132546 00000 н. 0000132709 00000 н. 0000132842 00000 н. 0000132988 00000 н. 0000133143 00000 н. 0000133307 00000 н. 0000133452 00000 н. 0000133617 00000 н. 0000133749 00000 н. 0000133871 00000 н. 0000133998 00000 н. 0000134127 00000 н. 0000134277 00000 н. 0000134429 00000 н. 0000134563 00000 н. 0000134716 00000 н. 0000134842 00000 н. 0000134979 00000 п. 0000135106 00000 п. 0000135228 00000 н. 0000135359 00000 н. 0000135491 00000 п. 0000135636 00000 н. 0000135813 00000 н. 0000135922 00000 н. 0000136031 00000 н. 0000004536 00000 н. трейлер ] / Назад 970799 >> startxref 0 %% EOF 969 0 объект > поток hb«b`2g`c«bb @

(PDF) QoS на основе SIP в IP-телефонии

Рисунок 13.Средний прямой и обратный джиттер для вызовов G711u

Из alaysis RTP мы показали средний джиттер в

на рисунке 13. Максимальная дельта (задержка) составляла 135,67 мс, а

средняя дельта составляла 19,5 мс. Среднее значение джиттера в прямом направлении

составляло от 0,62 мс до 0,67 мс и означает, что джиттер в обратном направлении составлял 1,0 мс

до 1,06 мс. Среднее количество пакетов RTP / сек = 50,00

Рисунок 14. График прямого и обратного джиттера и дельты во время вызова

На рисунке 14 график представляет прямую

и обратную дельту и джиттер для кодека G.711u.

VII. ЗАКЛЮЧЕНИЕ

В этой статье мы проанализировали несколько важных

критических качеств параметров обслуживания VoIP, таких как

средняя односторонняя задержка, средний прямой и обратный джиттер,

MOS и потеря пакетов для различных кодеков VoIP, таких как

G .711u, G.711a и G.729 относительно количества потоков вызовов VoIP

в этой проводной сети. Результаты моделирования

показывают, что кодек G.729 работает лучше, чем G.Кодек 711u и

G.711a при большой нагрузке в отношении задержки, джиттера,

MOS и потери пакетов в проводной сети. Показано, что

G.729 дает лучшую производительность с точки зрения изменения буфера джиттера

в среде LAN. Другой факт был обнаружен

, что увеличение размера буфера дрожания не является линейным

по отношению к уменьшению процента отбрасывания пакетов. Как и

, требования к пропускной способности для G.729,

, поэтому этот кодек в основном используется в приложениях VoIP

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

ПОДТВЕРЖДЕНИЕ

Авторы хотели бы поблагодарить Департамент

электротехники и электроники, Школа

инженерии и информатики, Независимый университет

, Бангладеш.

ССЫЛКИ

[1] Акбар Али, Нехал Ахмад, Мохд Шарике Ахтар, Адитья

Шривастава, «Протокол инициирования сеанса», Международный

Журнал научных и инженерных исследований, том.4,

№ 1, стр. 1–6, 2013.

[2] Стефан Масснер, Крис Рихтер, Уве Хаутцендорфер, ―SIP

Trunking — Общие требования для соединения

корпоративных сетей, ‖ Journal Of Networks, Vol. 8, No. 10,

pp.2195-2212, 2013.

[3] Мухаммад Еасир Арафат, Фероз Ахмед, М. Абдус

Собхан, «Безопасность SIP в IP-телефонии», ‖ Elastix world

2013, Мексика , 2013

[4] Хира Сату, Мохиб А.Шах, «Сравнение производительности кодеков

VoIP на нескольких операционных системах с использованием IPv4

,

и IPv6», «Международный журнал электронного образования, электронного бизнеса»,

, электронное управление и электронное обучение, Vol. 2, No. 2, pp.122-125,

2012

[5] Ск.Нагульмера, В.Т. Венкатесварлу, «Качество обслуживания

(QoS) Улучшение VOIP по WLAN», Int. J. of

Достижения в области компьютеров, электротехники и электроники

Engineering, Vol.2, No. Sp. Выпуск NCIPA, стр. 86-89,

2012

[6] Ф. Хавьер Ривас, Альмудена Диас, Педро Мерино, «Получение

более реалистичных межуровневых измерений QoS: вариант использования VoIP

через LTE, ‖ Журнал компьютерных сетей и

коммуникаций, Vol. 2013, № 10, с.48-55, 2013

[7] М. Вознак, Дж. Рожон, «Подход к стресс-тестам в среде SIP

на основе маржинального анализа», Springer

Telecommunication Systems, vol.10, No. 10, pp.1243-

1257, 2011.

[8] Ф. Альварес-Вакеро, Дж. Санс-Гонсалес, «Network VoIP для проектирования корпоративной среды

», In Proc. 7-я Международная конференция WSEAS

по телекоммуникациям и

информатике, Турция, стр. 194–198, 2008 г.

[9] Сяньху Че, Ли Дж. Кобли, «Производительность голосового IP по

различных протоколов внутренних шлюзов, Международный

Журнал коммуникационных сетей и информации

Безопасность (IJCNIS), Vol.1, No. 1, pp. 34-41, 2009.

[10] М. Вознак, Дж. Рожон, «Производительность инфраструктуры SIP»

Тестирование

, 9-я Международная конференция WSEAS по

Телекоммуникации и информатика, Катания, стр. 153-158,

2010

[11] Саид Эль-Брак, Мохаммед Бухорма, Мохамед Эль-Брак,

Ануар Богдхир, «Кодек на основе оценки качества речи

для VoIP через 802.11P», Международный журнал беспроводной связи

И мобильные сети (IJWMN), Vol.5, No. 2, pp. 75-87,

2013

[12] Priyanka Luthra, Manju Sharma, ―Performance Evaluation

Audio Codecs using VoIP Traffic in Wireless LAN

using RSVP, ‖ International Journal of Computer

Приложения, Vol. 40, No. 7, pp.88 — 97, 2012

[13] А. Ковач, М. Халас, М. Оргон, М. Вознак, ―E-модель

Улучшение оценки MOS с помощью пакета буфера джиттера

Потеря

Моделирование, In Advances in Electrical and Electronic

Engineering, Vol.9, № 5, с. 233-242, 2011

ЖУРНАЛ СЕТЕЙ, ТОМ. 9, № 12, ДЕКАБРЬ 2014

© 2014 ACADEMY PUBLISHER

Справочник по голосовым командам Cisco IOS — S-команды — показать голосовую трассировку при выключении (голосовой порт) [Cisco Unified Border Element]

Примеры

В следующем примере выходных данных отображается информация трассировки voip для вызова с идентификатором вызова 121. Идентификатор вызова может быть получен с помощью буферы покрытия трассировки шоу voip.

  маршрутизатор # показать идентификатор вызова VoIP-трассировки 121
------------------ Защитный буфер ---------------
Ключ поиска = sipp: 8765: 121
  Отметка времени = 9 ноября, 04:47: 39.427
  Buffer-Id = 1
  CallID = 121
  Peer-CallID = 122
  Коррелятор = 7
  Вызываемый номер = 8765
  Телефонный номер = sipp
  SIP CallID = [email protected]
  Идентификатор сеанса SIP = b91e516ba375585aae54b3f0abdd6f13
  GUID = 87954DCE80A7
-----------------------------------------------
1046: 9 ноября, 04:47:39.428: // 121 / 87954DCE80A7 / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Получено: сообщение SIP UDP от 8.41.17.71:7999 до 8.40.23.55:5060
ПРИГЛАСИТЬ sip: [email protected]: 5060 SIP / 2.0
Через: SIP / 2.0 / UDP 8.41.17.71:7999;branch=z9hG4bK-28575-1-0
От: sipp ; tag = 28575SIPpTag001
Кому: сут 
Call-ID: [email protected]
CSeq: 1 ПРИГЛАШАТЬ
Контакты: sip: [email protected]: 7999
Максимальное количество нападающих: 70
          
Тема: Тест производительности
Тип содержимого: приложение / sdp
Длина содержимого: 131

v = 0
o = user1 53655765 2353687637 ВХОД IP4 8.41.17.71
s = -
c = ВХОД IP4 8.41.17.71
т = 0 0
m = аудио 6008 RTP / AVP 0
a = rtpmap: 0 PCMU / 8000

1048: 9 ноября 04: 47: 39.428: // 121 / 87954DCE80A7 / CUBE_VT / SIP / FSM / SPI-State-Change: текущее состояние = STATE_NONE, следующее состояние = STATE_IDLE, текущее под-состояние = STATE_NONE, следующее под-состояние = STATE_NONE
1049: 9 ноября 04: 47: 39.430: // 121 / 87954DCE80A7 / CUBE_VT / SIP / MISC / Matched Dialpeer: Dir: Inbound, Peer-Tag: 100
1050: 9 ноября 04: 47: 39.436: // 121 / 87954DCE80A7 / CUBE_VT / SIP / FSM / Offer-Answer: Event = E_SIP_INVITE_SDP_RCVD, Current State = S_SIP_EARLY_DIALOG_IDLE, Next State = S_SIP_EARFFER_DIALOG_RCVD
1051: 9 ноября, 04:47:39.436: // 121 / 87954DCE80A7 / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_RCVD_SDP, текущее состояние = S_SIP_IWF_SDP_IDLE, следующее состояние = S_SIP_IWF_SDP_RCVD_AWAENT_PEER_AWAENT_PEER_
1052: 9 ноября 04: 47: 39.437: // 121 / 87954DCE80A7 / CUBE_VT / SIP / MISC / Параметры медиапотока: Тип потока = только голос, Состояние потока = STREAM_ADDING Согласованный кодек = g711ulaw, Согласованный тип DTMF = inband-voice, Индекс потока = 1
1053: 9 ноября 04: 47: 39.437: // 121 / 87954DCE80A7 / CUBE_VT / SIP / API: cc_api_update_interface_cac_resource (0)
1054: 9 ноября, 04:47:39.438: // 121 / 87954DCE80A7 / CUBE_VT / SIP / API: voip_rtp_allocate_port (8036)
1055: 9 ноября 04: 47: 39.439: // 121 / 87954DCE80A7 / CUBE_VT / SIP / MISC / Параметры медиапотока: Тип потока = только голос, Состояние потока = STREAM_ADDING Согласованный кодек = g711ulaw, Согласованный тип DTMF = внутриполосный голос, Индекс потока = 1
1056: 9 ноября 04: 47: 39.440: // 121 / 87954DCE80A7 / CUBE_VT / SIP / API: cc_api_call_setup_ind_with_callID (0)
1057: 9 ноября 04: 47: 39.442: // 121 / 87954DCE80A7 / CUBE_VT / SIP / FSM / SPI-State-Change: текущее состояние = STATE_IDLE, следующее состояние = STATE_RECD_INVITE, текущее под-состояние = STATE_NONE, следующее под-состояние = STATE_NONE
1062: 9 ноября, 04:47:39.449: // 121 / 87954DCE80A7 / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_SET_MODE, текущее состояние = CNFSM_CONTAINER_STATE, следующее состояние = CNFSM_NO_STATE_CHANGE
1063: 9 ноября 04: 47: 39.449: // 121 / 87954DCE80A7 / CUBE_VT / SIP / API: voip_rtp_create_session (0)
1064: 9 ноября 04: 47: 39.450: // 121 / 87954DCE80A7 / CUBE_VT / SIP / API: voip_rtp_set_non_rtp_call (0)
1065: 9 ноября 04: 47: 39.450: // 121 / 87954DCE80A7 / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
1066: 9 ноября 04: 47: 39.452: // 121 / 87954DCE80A7 / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_CC_CALL_PROCEEDING, текущее состояние = STATE_RECD_INVITE
1082: 9 ноября, 04:47:39.465: // 121 / 87954DCE80A7 / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Отправлено: сообщение SIP UDP с 8.40.23.55:5060 на 8.41.17.71:7999
SIP / 2.0 100 Пробуем
Через: SIP / 2.0 / UDP 8.41.17.71:7999;branch=z9hG4bK-28575-1-0
От: sipp ; tag = 28575SIPpTag001
Кому: сут 
Дата: пн, 09 ноя 2020, 04:47:39 GMT
Call-ID: [email protected]
CSeq: 1 ПРИГЛАШАТЬ
Разрешить-события: телефон-событие
Сервер: Cisco-SIPGateway / IOS-17.5.20201104.183617
Идентификатор сеанса: 00000000000000000000000000000000; удаленный = d5c7bba01d5c51038030ab5bd521474e
Content-Length: 0


1097: 9 ноября, 04:47:39.473: // 121 / 87954DCE80A7 / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_CC_CALL_ALERTING, текущее состояние = STATE_RECD_INVITE
1098: 9 ноября 04: 47: 39.475: // 121 / 87954DCE80A7 / CUBE_VT / SIP / FSM / SPI-State-Change: текущее состояние = STATE_RECD_INVITE, следующее состояние = STATE_SENT_ALERTING, текущее под-состояние = STATE_NONE, следующее под-состояние = STATE_NONE
1099: 9 ноября 04: 47: 39.475: // 121 / 87954DCE80A7 / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Отправлено: сообщение SIP UDP с 8.40.23.55:5060 на 8.41.17.71:7999
SIP / 2.0 180 Звонок
Через: SIP / 2.0 / UDP 8.41.17.71:7999;branch=z9hG4bK-28575-1-0
От: sipp ; tag = 28575SIPpTag001
Кому: сут ; tag = 621353-21F5
Дата: пн, 09 ноя 2020, 04:47:39 GMT
Call-ID: [email protected]
CSeq: 1 ПРИГЛАШАТЬ
Разрешить: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Разрешить-события: телефон-событие
Remote-Party-ID: ; party = called; screen = no; privacy = off
Контакты: 
Сервер: Cisco-SIPGateway / IOS-17.5.20201104.183617
Идентификатор сеанса: b91e516ba375585aae54b3f0abdd6f13; remote = d5c7bba01d5c51038030ab5bd521474e
Content-Length: 0


1110: 9 ноября 04: 47: 49.481: // 121 / 87954DCE80A7 / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_PEER_CAPS, текущее состояние = CNFSM_CONTAINER_STATE, следующее состояние = CNFSM_NO_STATE_CHANGE
1111: 9 ноября 04: 47: 49.482: // 121 / 87954DCE80A7 / CUBE_VT / SIP / API: cc_api_caps_ack (0)
1112: 9 ноября 04: 47: 49.483: // 121 / 87954DCE80A7 / CUBE_VT / SIP / API: cc_api_caps_ack (0)
1125: 9 ноября 04: 47: 49.489: // 121 / 87954DCE80A7 / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_PEER_MULTIMEDIA_CHANNEL_ACK, текущее состояние = S_SIP_IWF_SDP_RCVD_AWAIT_PEER_State_
1126: 9 ноября, 04:47:49.490: // 121 / 87954DCE80A7 / CUBE_VT / SIP / MISC / Параметры медиа-потока: Тип потока = только для голоса, Состояние потока = STREAM_ADDING Согласованный кодек = g711ulaw, Согласованный тип DTMF = inband-voice, Индекс потока = 1
1127: 9 ноября 04: 47: 49.490: // 121 / 87954DCE80A7 / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
1128: 9 ноября 04: 47: 49.490: // 121 / 87954DCE80A7 / CUBE_VT / SIP / API: cc_api_call_mode_update_ind (0)
1129: 9 ноября 04: 47: 49.490: // 121 / 87954DCE80A7 / CUBE_VT / SIP / FSM / Media-State: событие = E_IPIP_MEDIA_SERV_EV_PEER_CHNL_ACK, текущее состояние = S_IPIP_MEDIA_SERV_STATE_IDLE, следующее состояние = CNFS_MED_STATE_IDLE
1131: 9 ноября, 04:47:49.494: // 121 / 87954DCE80A7 / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
1132: 9 ноября 04: 47: 49.494: // 121 / 87954DCE80A7 / CUBE_VT / SIP / API: voip_rtp_set_non_rtp_call (0)
1133: 9 ноября 04: 47: 49.494: // 121 / 87954DCE80A7 / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
1134: 9 ноября 04: 47: 49.495: // 121 / 87954DCE80A7 / CUBE_VT / SIP / API: cc_api_bridge_done (0)
1135: 9 ноября 04: 47: 49.496: // 121 / 87954DCE80A7 / CUBE_VT / SIP / API: ccsip_bridge (0)
1142: 9 ноября 04: 47: 49.501: // 121 / 87954DCE80A7 / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_CALL_CONNECT, текущее состояние = CNFSM_CONTAINER_STATE, следующее состояние = CNFSM_NO_STATE_CHANGE
1143: 9 ноября, 04:47:49.502: // 121 / 87954DCE80A7 / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_CC_CALL_CONNECT, текущее состояние = STATE_SENT_ALERTING
1144: 9 ноября 04: 47: 49.503: // 121 / 87954DCE80A7 / CUBE_VT / SIP / FSM / Offer-Answer: Event = E_SIP_INVITE_RESP_SDP_SENT, текущее состояние = S_SIP_EARLY_DIALOG_OFFER_RCVD, следующее состояние = S_SIP_ARLY_DIALOG_OFFER_RCVD, следующее состояние = S_SIPOFF_SIP_SIP
1145: 9 ноября 04: 47: 49.504: // 121 / 87954DCE80A7 / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_SENT_SDP, текущее состояние = S_SIP_IWF_SDP_RCVD_AWAIT_PEER_EVENT, следующее состояние = S_DDP_D_S_D
1146: 9 ноября, 04:47:49.505: // 121 / 87954DCE80A7 / CUBE_VT / SIP / FSM / SPI-State-Change: текущее состояние = STATE_SENT_ALERTING, следующее состояние = STATE_SENT_SUCCESS, текущее под-состояние = STATE_NONE, следующее под-состояние = STATE_NONE
1147: 9 ноября 04: 47: 49.506: // 121 / 87954DCE80A7 / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Отправлено: сообщение SIP UDP с 8.40.23.55:5060 на 8.41.17.71:7999
SIP / 2.0 200 ОК
Через: SIP / 2.0 / UDP 8.41.17.71:7999;branch=z9hG4bK-28575-1-0
От: sipp ; tag = 28575SIPpTag001
Кому: сут ; tag = 621353-21F5
          
Дата: пн, 09 ноя 2020, 04:47:39 GMT
Call-ID: 1-28575 @ 8.41.17.71
CSeq: 1 ПРИГЛАШАТЬ
Разрешить: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Разрешить-события: телефон-событие
Remote-Party-ID: ; party = called; screen = no; privacy = off
Контакты: 
Поддерживается: заменяет
Поддерживается: sdp-anat
Сервер: Cisco-SIPGateway / IOS-17.5.20201104.183617
Идентификатор сеанса: b91e516ba375585aae54b3f0abdd6f13; remote = d5c7bba01d5c51038030ab5bd521474e
Поддерживается: таймер
Тип содержимого: приложение / sdp
Content-Disposition: сеанс; обработка = требуется
Длина содержимого: 184

v = 0
o = CiscoSystemsSIP-GW-UserAgent 8590 9304 IN IP4 8.40,23,55
s = SIP-вызов
c = ВХОД IP4 8.40.23.55
          
т = 0 0
m = аудио 8036 RTP / AVP 0
c = ВХОД IP4 8.40.23.55
a = rtpmap: 0 PCMU / 8000
a = ptime: 20

1149: 9 ноября 04: 47: 49.507: // 121 / 87954DCE80A7 / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Получено: сообщение SIP UDP от 8.41.17.71:7999 до 8.40.23.55:5060
ACK sip: [email protected]: 5060 SIP / 2.0
Через: SIP / 2.0 / UDP 8.41.17.71:7999;branch=z9hG4bK-28575-1-5
От: sipp ; tag = 28575SIPpTag001
Кому: сут ; tag = 621353-21F5
Call-ID: 1-28575 @ 8.41.17.71
CSeq: 1 ACK
Контакты: sip: [email protected]: 7999
Максимальное количество нападающих: 70
Тема: Тест производительности
Content-Length: 0


1150: 9 ноября 04: 47: 49.507: // 121 / 87954DCE80A7 / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_NEW_MESSAGE, текущее состояние = STATE_SENT_SUCCESS
  

В следующем примере выходных данных отображается информация о трассировке VoIP для вызова ipv6:

  маршрутизатор # показать идентификатор вызова VoIP-трассировки 39
------------------ Защитный буфер ---------------
Ключ поиска = sipp: 5678: 39
  Отметка времени = * 25 декабря 22:09:00.068
  Buffer-Id = 1
  CallID = 39
  Peer-CallID = 40
  Коррелятор = 16
  Вызываемый номер = 5678
  Телефонный номер = sipp
  SIP CallID = 1-8921 @ 2001: 420: 54ff: 13 :: 312: 71
  Идентификатор сеанса SIP = d921890ab3aa557891b6dd2888b0602b
  GUID = 9FF305D88076
-----------------------------------------------
2232: * 25 декабря 22: 09: 00.068: // 39 / 9FF305D88076 / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Получено: сообщение SIP UDP от [2001: 420: 54FF: 13 :: 312: 71]: 10000 до [2001: 420: 54FF: 13 :: 652: 23]: 5060
ПРИГЛАСИТЬ sip: 5678 @ [2001: 420: 54ff: 13 :: 652: 23]: 5060 SIP / 2.0
Через: SIP / 2.0 / UDP [2001: 420: 54ff: 13 :: 312: 71]: 10000; branch = z9hG4bK-8921-1-0
От: sipp ; tag = 8921SIPpTag001
Кому: sut 
Call-ID: 1-8921 @ 2001: 420: 54ff: 13 :: 312: 71
CSeq: 1 ПРИГЛАШАТЬ
Обращайтесь: sip: sipp @ [2001: 420: 54ff: 13 :: 312: 71]: 10000
          
Максимальное количество нападающих: 70
Тема: Тест производительности
Тип содержимого: приложение / sdp
Длина содержимого: 161

v = 0
o = user1 53655765 2353687637 IN IP6 [2001: 420: 54ff: 13 :: 312: 71]
s = -
c = IN IP6 2001: 420: 54ff: 13 :: 312: 71
т = 0 0
m = аудио 6001 RTP / AVP 0
a = rtpmap: 0 PCMU / 8000

2234: * 25 декабря, 22:09:00.067: // 39 / 9FF305D88076 / CUBE_VT / SIP / FSM / SPI-State-Change: текущее состояние = STATE_NONE, следующее состояние = STATE_IDLE, текущее под-состояние = STATE_NONE, следующее под-состояние = STATE_NONE
2235: * 25 декабря 22: 09: 00.069: // 39 / 9FF305D88076 / CUBE_VT / SIP / MISC / Matched Dialpeer: Dir: Inbound, Peer-Tag: 3
2236: * 25 декабря 22: 09: 00.069: // 39 / 9FF305D88076 / CUBE_VT / SIP / FSM / Offer-Answer: Event = E_SIP_INVITE_SDP_RCVD, текущее состояние = S_SIP_EARLY_DIALOG_IDLE, следующее состояние = S_SIP_EARFFERLY_DIAL_OG
2237: * 25 декабря 22: 09: 00.069: // 39 / 9FF305D88076 / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_RCVD_SDP, текущее состояние = S_SIP_IWF_SDP_IDLE, следующее состояние = S_SIP_IWVD_WF_SDP_AWF_AWF_DP_A_RC_A
2238: * 25 декабря, 22:09:00.070: // 39 / 9FF305D88076 / CUBE_VT / SIP / MISC / Параметры медиа-потока: Тип потока = только для голоса, Состояние потока = STREAM_ADDING Согласованный кодек = g711ulaw, Согласованный тип DTMF = inband-voice, Индекс потока = 1
2239: * 25 декабря 22: 09: 00.071: // 39 / 9FF305D88076 / CUBE_VT / SIP / API: cc_api_update_interface_cac_resource (0)
2240: * 25 декабря 22: 09: 00.071: // 39 / 9FF305D88076 / CUBE_VT / SIP / API: voip_rtp_allocate_port (8020)
2241: * 25 декабря 22: 09: 00.071: // 39 / 9FF305D88076 / CUBE_VT / SIP / MISC / Параметры медиапотока: Тип потока = только голос, Состояние потока = STREAM_ADDING Согласованный кодек = g711ulaw, Согласованный тип DTMF = inband-voice , Индекс потока = 1
2242: * 25 декабря, 22:09:00.071: // 39 / 9FF305D88076 / CUBE_VT / SIP / API: cc_api_call_setup_ind_with_callID (0)
2243: * 25 декабря 22: 09: 00.072: // 39 / 9FF305D88076 / CUBE_VT / SIP / FSM / SPI-State-Change: Current State = STATE_IDLE, Next State = STATE_RECD_INVITE, Current Sub-State = STATE_NONE, Next Sub-State = STATE_NONE
2248: * 25 декабря 22: 09: 00.073: // 39 / 9FF305D88076 / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_SET_MODE, текущее состояние = CNFSM_CONTAINER_STATE, следующее состояние = CNFSM_NO_STATE_CHANGE
2249: * 25 декабря 22: 09: 00.074: // 39 / 9FF305D88076 / CUBE_VT / SIP / API: voip_rtp_create_session (0)
2250: * 25 декабря, 22:09:00.074: // 39 / 9FF305D88076 / CUBE_VT / SIP / API: voip_rtp_set_non_rtp_call (0)
2251: * 25 декабря 22: 09: 00.074: // 39 / 9FF305D88076 / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
2252: * 25 декабря 22: 09: 00.074: // 39 / 9FF305D88076 / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_CC_CALL_PROCEEDING, текущее состояние = STATE_RECD_INVITE
2272: * 25 декабря 22: 09: 00.077: // 39 / 9FF305D88076 / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Отправлено: сообщение SIP UDP от [2001: 420: 54FF: 13 :: 652: 23]: 5060 до [2001: 420: 54FF: 13 :: 312: 71]: 10000
SIP / 2.0 100 Пробуем
Через: SIP / 2.0 / UDP [2001: 420: 54ff: 13 :: 312: 71]: 10000; branch = z9hG4bK-8921-1-0
От: sipp ; tag = 8921SIPpTag001
Кому: sut 
Дата: пт, 25 декабря 2020 г., 22:09:00 GMT
Call-ID: 1-8921 @ 2001: 420: 54ff: 13 :: 312: 71
CSeq: 1 ПРИГЛАШАТЬ
Разрешить-события: телефон-событие
Сервер: Cisco-SIPGateway / IOS-17.5.20201117.131853
Идентификатор сеанса: 00000000000000000000000000000000; удаленный = e714644e7e385e90a1d75a34855ef73a
Content-Length: 0  

В следующем примере выходных данных отображается информация о трассировке VoIP для вызова в Media Proxy:

    Опора анкера:  
router # показать идентификатор вызова VoIP-трассировки 1
------------------ Защитный буфер ---------------
Ключ поиска = 1111: 9999: 1
  Отметка времени = 9 ноября 02:36:34.941
  Buffer-Id = 1
  CallID = 1
  Peer-CallID = 2
  Коррелятор = 1
  Вызываемый номер = 9999
  Телефонный номер = 1111
  SIP CallID = [email protected]
  SIP Session ID = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
  GUID = 96ABC1F680AA
  Опора якоря = ДА
  Связанные CallID = 2, 4,
-----------------------------------------------
0: 9 ноября 02: 36: 34.941: // 1 / 96ABC1F680AA / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Получено: сообщение SIP UDP от 8.41.17.71:40000 до 8.40.23.55:5060
ПРИГЛАСИТЬ sip: 9999 @ 8.40.23.55: 5060 SIP / 2.0
Через: SIP / 2.0 / UDP 8.41.17.71:40000;branch=z9hG4bK-20038-1-0
От: sipp ; tag = 20038SIPpTag001
Кому: cube_proxy 
Call-ID: [email protected]
CSeq: 1 ПРИГЛАШАТЬ
Максимальное количество нападающих: 70
Cisco-Guid: 2527838710-1106383336-2158658254-3746786232
Разрешить: ПРИГЛАШЕНИЕ, ОПЦИИ, ИНФОРМАЦИЯ, ПОКА, ОТМЕНА, ПОДТВЕРЖДЕНИЕ, ПРЕДУПРЕЖДЕНИЕ, ОБНОВЛЕНИЕ, ОБНОВЛЕНИЕ, ПОДПИСАТЬСЯ, УВЕДОМЛЕНИЕ
Идентификатор сеанса: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa; удаленный = 00000000000000000000000000000000
Срок действия сеанса: 1800; refresher = uac
Тема: Тест производительности
Контакт: 
Тип содержимого: приложение / sdp
Длина содержимого: 150

v = 0
o = user1 53655765 2353687637 IN IP4 8.41.17.71
s = SIP-вызов
c = ВХОД IP4 8.41.17.71
т = 0 0
m = аудио 6025 RTP / AVP 0
a = rtpmap: 0 PCMU / 8000
a = sendonly

2: 9 ноября 02: 36: 34.941: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / SPI-State-Change: текущее состояние = STATE_NONE, следующее состояние = STATE_IDLE, текущее под-состояние = STATE_NONE, следующее под-состояние = STATE_NONE
3: 9 ноября 02: 36: 34.949: // 1 / 96ABC1F680AA / CUBE_VT / SIP / MISC / Matched Dialpeer: Dir: Inbound, Peer-Tag: 600
4: 9 ноября 02:36:34.961: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Предложение-ответ: событие = E_SIP_INVITE_SDP_RCVD, текущее состояние = S_SIP_EARLY_DIALOG_IDLE, следующее состояние = S_SIP_EARLY_DIALOG_OFFER_RCVD
5: 9 ноября 02: 36: 34.961: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_RCVD_SDP, текущее состояние = S_SIP_IWF_SDP_IDLE, следующее состояние = S_SIP_IWF_SDP_RCVA_RAC
6: 9 ноября 02: 36: 34.962: // 1 / 96ABC1F680AA / CUBE_VT / SIP / MISC / Параметры медиапотока: Тип потока = только голос, Состояние потока = STREAM_ADDING Согласованный кодек = g711ulaw, Согласованный тип DTMF = inband-voice, Индекс потока = 1
7: 9 ноября 02:36:34.963: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_update_interface_cac_resource (0)
8: 9 ноября 02: 36: 34.964: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_allocate_port (8000)
9: 9 ноября 02: 36: 34.964: // 1 / 96ABC1F680AA / CUBE_VT / SIP / MISC / Параметры медиапотока: Тип потока = только голос, Состояние потока = STREAM_ADDING Согласованный кодек = g711ulaw, Согласованный тип DTMF = внутриполосный голос, Индекс потока = 1
10: 9 ноября 02: 36: 34.966: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_call_setup_ind_with_callID (0)
11: 9 ноября 02:36:34.966: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / SPI-State-Change: текущее состояние = STATE_IDLE, следующее состояние = STATE_RECD_INVITE, текущее под-состояние = STATE_NONE, следующее под-состояние = STATE_NONE
17: 9 ноября 02: 36: 34.979: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_SET_MODE, текущее состояние = CNFSM_CONTAINER_STATE, следующее состояние = CNFSM_NO_STATE_CHANGE
18: 9 ноября 02: 36: 34.979: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_create_session (0)
19: 9 ноября 02: 36: 34.979: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_set_non_rtp_call (0)
20: 9 ноября 02:36:34.979: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
21: 9 ноября 02: 36: 34.979: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_CC_CALL_PROCEEDING, текущее состояние = STATE_RECD_INVITE
37: 9 ноября 02: 36: 34.983: // 1 / 96ABC1F680AA / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Отправлено: сообщение SIP UDP с 8.40.23.55:5060 на 8.41.17.71:40000
SIP / 2.0 100 Пробуем
Через: SIP / 2.0 / UDP 8.41.17.71:40000;branch=z9hG4bK-20038-1-0
От: sipp ; tag = 20038SIPpTag001
Кому: cube_proxy 
Дата: пн, 09 ноя 2020 02:36:34 GMT
Call-ID: [email protected]
CSeq: 1 ПРИГЛАШАТЬ
Разрешить-события: телефон-событие
Сервер: Cisco-SIPGateway / IOS-17.5.20201104.183617
Идентификатор сеанса: 52cfadb8d2ff567d93c40769eb164427; remote = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Content-Length: 0


52: 9 ноября 02: 36: 34.986: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_CC_CALL_ALERTING, текущее состояние = STATE_RECD_INVITE
53: 9 ноября 02: 36: 34.986: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / SPI-State-Change: текущее состояние = STATE_RECD_INVITE, следующее состояние = STATE_SENT_ALERTING, текущее под-состояние = STATE_NONE, следующее под-состояние = STATE_NONE
54: 9 ноября 02:36:34.986: // 1 / 96ABC1F680AA / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Отправлено: сообщение SIP UDP с 8.40.23.55:5060 на 8.41.17.71:40000
SIP / 2.0 180 Звонок
Через: SIP / 2.0 / UDP 8.41.17.71:40000;branch=z9hG4bK-20038-1-0
От: sipp ; tag = 20038SIPpTag001
Кому: cube_proxy ; tag = 2077B-124C
Дата: пн, 09 ноя 2020 02:36:34 GMT
Call-ID: [email protected]
CSeq: 1 ПРИГЛАШАТЬ
Разрешить: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Разрешить-события: телефон-событие
ID удаленной стороны: ; party = called; screen = no; privacy = off
Контакты: 
Сервер: Cisco-SIPGateway / IOS-17.5.20201104.183617
Идентификатор сеанса: 52cfadb8d2ff567d93c40769eb164427; remote = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Content-Length: 0


63: 9 ноября 02: 36: 34.989: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_PEER_CAPS, текущее состояние = CNFSM_CONTAINER_STATE, следующее состояние = CNFSM_NO_STATE_CHANGE
64: 9 ноября 02: 36: 34.989: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_caps_ack (0)
65: 9 ноября 02:36:34.989: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_caps_ack (0)
78: 9 ноября 02: 36: 34.990: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_PEER_MULTIMEDIA_CHANNEL_ACK, текущее состояние = S_SIP_IWF_SDP_RCVD_AWAIT_PEER_ State_
79: 9 ноября 02: 36: 34.990: // 1 / 96ABC1F680AA / CUBE_VT / SIP / MISC / Параметры медиапотока: Тип потока = только голос, Состояние потока = STREAM_ADDING Согласованный кодек = g711ulaw, Согласованный тип DTMF = внутриполосный голос, Индекс потока = 1
80: 9 ноября 02:36:34.990: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
81: 9 ноября 02: 36: 34.990: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_call_mode_update_ind (0)
82: 9 ноября 02: 36: 34.990: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Media-State: событие = E_IPIP_MEDIA_SERV_EV_PEER_CHNL_ACK, текущее состояние = S_IPIP_MEDIA_SERV_STATE_IDLE, следующее состояние = CNFS_MEDIA_STATE_IDLE, следующее состояние
84: 9 ноября 02: 36: 34.991: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
85: 9 ноября 02: 36: 34.991: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_set_non_rtp_call (0)
86: 9 ноября 02:36:34.991: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
87: 9 ноября 02: 36: 34.991: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
88: 9 ноября 02: 36: 34.991: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_bridge_done (0)
89: 9 ноября 02: 36: 34.991: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: ccsip_bridge (0)
97: 9 ноября 02: 36: 34.997: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_CALL_CONNECT, текущее состояние = CNFSM_CONTAINER_STATE, следующее состояние = CNFSM_NO_STATE_CHANGE
98: 9 ноября 02:36:34.997: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_CC_CALL_CONNECT, текущее состояние = STATE_SENT_ALERTING
99: 9 ноября 02: 36: 34.998: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Offer-Answer: Event = E_SIP_INVITE_RESP_SDP_SENT, текущее состояние = S_SIP_EARLY_DIALOG_OFFER_RCVD, следующее состояние = S_SIP_INVITE_RESP_SDP_SENT
100: 9 ноября 02: 36: 34.998: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_SENT_SDP, текущее состояние = S_SIP_IWF_SDP_RCVD_AWAIT_PEER_EVENT, следующее состояние = S_SIP_D_S_D
101: 9 ноября 02:36:34.998: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / SPI-State-Change: текущее состояние = STATE_SENT_ALERTING, следующее состояние = STATE_SENT_SUCCESS, текущее под-состояние = STATE_NONE, следующее под-состояние = STATE_NONE
102: 9 ноября 02: 36: 34.998: // 1 / 96ABC1F680AA / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Отправлено: сообщение SIP UDP с 8.40.23.55:5060 на 8.41.17.71:40000
SIP / 2.0 200 ОК
Через: SIP / 2.0 / UDP 8.41.17.71:40000;branch=z9hG4bK-20038-1-0
От: sipp ; tag = 20038SIPpTag001
Кому: cube_proxy ; tag = 2077B-124C
Дата: пн, 09 ноя 2020 02:36:34 GMT
Call-ID: [email protected]
CSeq: 1 ПРИГЛАШАТЬ
Разрешить: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Разрешить-события: телефон-событие
Remote-Party-ID: ; party = called; screen = no; privacy = off
Контакты: 
Поддерживается: заменяет
Поддерживается: sdp-anat
Сервер: Cisco-SIPGateway / IOS-17.5.20201104.183617
Поддерживается: X-cisco-cubeproxy
Идентификатор сеанса: 52cfadb8d2ff567d93c40769eb164427; remote = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Поддерживается: таймер
Тип содержимого: приложение / sdp
Content-Disposition: сеанс; обработка = требуется
Длина содержимого: 196

v = 0
o = CiscoSystemsSIP-GW-UserAgent 7400 2674 IN IP4 8.40,23,55
s = SIP-вызов
c = ВХОД IP4 8.40.23.55
т = 0 0
m = аудио 8000 RTP / AVP 0
c = ВХОД IP4 8.40.23.55
a = recvonly
a = rtpmap: 0 PCMU / 8000
a = ptime: 20

105: 9 ноября 02: 36: 35.001: // 1 / 96ABC1F680AA / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Получено: сообщение SIP UDP от 8.41.17.71:40000 до 8.40.23.55:5060
ACK sip: [email protected]: 5060 SIP / 2.0
Через: SIP / 2.0 / UDP 8.41.17.71:40000;branch=z9hG4bK-20038-1-5
От: sipp ; tag = 20038SIPpTag001
Кому: cube_proxy ; tag = 2077B-124C
Call-ID: 1-20038 @ 8.41.17.71
CSeq: 1 ACK
Контакт: 
Максимальное количество нападающих: 70
Тема: Тест производительности
Content-Disposition: сеанс; обработка = требуется
Content-Length: 0


106: 9 ноября 02: 36: 35.001: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_NEW_MESSAGE, текущее состояние = STATE_SENT_SUCCESS
107: 9 ноября 02: 36: 35.001: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / SPI-State-Change: текущее состояние = STATE_SENT_SUCCESS, следующее состояние = STATE_ACTIVE, текущее под-состояние = STATE_NONE, следующее под-состояние = STATE_NONE
108: 9 ноября, 02:36:35.001: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Предложение-ответ: событие = E_SIP_DIALOG_ESTD, текущее состояние = S_SIP_EARLY_DIALOG_OFFER_ANSWER_COMPLETE, следующее состояние = S_SIP_MID_DIALOG_IDLE
109: 9 ноября 02: 36: 35.001: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_CALL_ACTIVE, текущее состояние = CNFSM_CONTAINER_STATE, следующее состояние = CNFSM_NO_STATE_CHANGE
110: 9 ноября 02: 36: 35.001: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Media-State: событие = E_IPIP_MEDIA_SERV_EV_CALL_ACTIVE, текущее состояние = CNFSM_CONTAINER_STATE, следующее состояние = CNFSM_NO_STATE_CHANGE
165: 9 ноября, 02:36:35.019: // 1 / 96ABC1F680AA / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Отправлено: сообщение SIP UDP с 8.40.23.55:5060 на 8.41.17.71:40000
ИНФОРМАЦИЯ sip: [email protected]: 40000; транспорт = UDP SIP / 2.0
Через: SIP / 2.0 / UDP 8.40.23.55:5060;branch=z9hG4bK4147D
От: cube_proxy ; tag = 2077B-124C
Кому: sipp ; tag = 20038SIPpTag001
Дата: пн, 09 ноя 2020 02:36:35 GMT
Call-ID: [email protected]
Пользовательский агент: Cisco-SIPGateway / IOS-17.5.20201104.183617
Максимальное количество нападающих: 70
Поддерживается: X-cisco-cubeproxy
Отметка времени: 1604889395
CSeq: 101 ИНФОРМАЦИЯ
Обращаться: 
Remote-Party-ID: ; party = called; screen = no; privacy = off
Идентификатор сеанса: 52cfadb8d2ff567d93c40769eb164427; remote = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Тип содержимого: приложение / x-cisco-прокси-запись-статус + xml
Длина содержимого: 341


    <регистратор>
         sip: [email protected]: 40001 
         Необязательно 
         Успех 
    
    <регистратор>
         sip: 9999 @ 8.41.17.71: 40002 
         Необязательно 
         Успех 
    


168: 9 ноября 02: 36: 35.020: // 1 / 96ABC1F680AA / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Получено: сообщение SIP UDP от 8.41.17.71:40000 до 8.40.23.55:5060
SIP / 2.0 200 ОК
Через: SIP / 2.0 / UDP 8.40.23.55:5060;branch=z9hG4bK4147D
От: cube_proxy ; tag = 2077B-124C
Кому: sipp ; tag = 20038SIPpTag001
Call-ID: 1-20038 @ 8.41.17.71
CSeq: 101 ИНФОРМАЦИЯ
Контакт: 
Content-Length: 0


169: 9 ноября 02: 36: 35.020: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_NEW_MESSAGE, текущее состояние = STATE_ACTIVE
170: 9 ноября 02: 38: 35.029: // 1 / 96ABC1F680AA / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Получено: сообщение SIP UDP от 8.41.17.71:40000 до 8.40.23.55:5060
BYE sip: [email protected]: 5060 SIP / 2.0
Через: SIP / 2.0 / UDP 8.41.17.71:40000;branch=z9hG4bK-20038-1-9
Откуда: sipp ; tag = 20038SIPpTag001
Кому: cube_proxy ; tag = 2077B-124C
Call-ID: [email protected]
CSeq: 2 BYE
Контакт: 
Максимальное количество нападающих: 70
Тема: Тест производительности
Content-Length: 0


171: 9 ноября 02: 38: 35.029: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_NEW_MESSAGE, текущее состояние = STATE_ACTIVE
172: 9 ноября 02: 38: 35.029: // 1 / 96ABC1F680AA / CUBE_VT / SIP / MISC / Отключение вызова: инициировано: 0x1702028, отправлено: 0x1702021, код причины = 16
173: 9 ноября, 02:38:35.029: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_call_disconnected (0)
174: 9 ноября 02: 38: 35.029: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / SPI-State-Change: Current State = STATE_ACTIVE, Next State = STATE_DISCONNECTING, Current Sub-State = STATE_NONE, Next Sub-State = STATE_NONE
175: 9 ноября 02: 38: 35.031: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_destroy_dp_session (0)
176: 9 ноября 02: 38: 35.031: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Media-State: событие = E_IPIP_MEDIA_SERV_EV_XCODER_RESET_STREAM, текущее состояние = CNFSM_CONTAINER_STATE, следующее состояние = S_IPERLE_MED_S_IPLE_MODE
177: 9 ноября, 02:38:35.031: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
178: 9 ноября 02: 38: 35.031: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_bridge_drop_done (0)
183: 9 ноября 02: 38: 35.031: // 1 / 96ABC1F680AA / CUBE_VT / SIP / MISC / Ошибка: ccsip_mf_disconnect_req: недопустимый контекст привязки для mspCallID 3
190: 9 ноября 02: 38: 35.033: // 1 / 96ABC1F680AA / CUBE_VT / SIP / MISC / Отключение вызова: инициировано: 0x260070A, отправлено: 0x260070B, код причины = 16
192: 9 ноября 02: 38: 35.033: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_update_interface_cac_resource (0)
193: 9 ноября 02:38:35.033: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_CC_CALL_DISCONNECT, текущее состояние = STATE_DISCONNECTING
194: 9 ноября 02: 38: 35.033: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_delete_dp_session (0)
195: 9 ноября 02: 38: 35.033: // 1 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_call_disconnect_done (0)
196: 9 ноября 02: 38: 35.033: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / SPI-State-Change: Current State = STATE_DISCONNECTING, Next State = STATE_DEAD, Current Sub-State = STATE_NONE, Next Sub-State = STATE_NONE
200: 9 ноября 02:38:35.034: // 1 / 96ABC1F680AA / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Отправлено: сообщение SIP UDP с 8.40.23.55:5060 на 8.41.17.71:40000
SIP / 2.0 200 ОК
Через: SIP / 2.0 / UDP 8.41.17.71:40000;branch=z9hG4bK-20038-1-9
От: sipp ; tag = 20038SIPpTag001
Кому: cube_proxy ; tag = 2077B-124C
Дата: пн, 09 ноя 2020 02:38:35 GMT
Call-ID: [email protected]
Сервер: Cisco-SIPGateway / IOS-17.5.20201104.183617
CSeq: 2 BYE
Причина: Q.850; причина = 16
Идентификатор сеанса: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa; remote = 52cfadb8d2ff567d93c40769eb164427
Content-Length: 0


216: 9 ноября 02:39:07.033: // 1 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Timer-Action: событие = SIP_TIMER_REMOVE_TRANSACTION, текущее состояние = STATE_DEAD
217: 9 ноября 02: 39: 07.033: // 1 / 96ABC1F680AA / CUBE_VT / SIP / MISC / Ошибка: sipSPIFlushDeferredQueue: недопустимая deferredQueue  

    Вилка:  
router # показать идентификатор вызова VoIP-трассировки 2
Ключ поиска = 1111: 9999: 2
  Отметка времени = 9 ноября 02:36: 34.978
  Buffer-Id = 2
  CallID = 2
  Peer-CallID = NA
  Коррелятор = 1
  Вызываемый номер = 9999
  Телефонный номер = 1111
  SIP CallID = 38023A2E-216B11EB-8007A966-FCB2BDFB @ 8.40,23,55
  Идентификатор сеанса SIP = 52cfadb8d2ff567d93c40769eb164427
  GUID = 96ABC1F680AA
  Раздвоенная нога = ДА
  Связанные CallID = 1, 4,
-----------------------------------------------
12: 9 ноября 02: 36: 34.978: // 2 / 96ABC1F680AA / CUBE_VT / SIP / MISC / Matched Dialpeer: Dir: Outbound, Peer-Tag: 601
13: 9 ноября 02: 36: 34.978: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / SPI-State-Change: текущее состояние = STATE_NONE, следующее состояние = STATE_IDLE, текущее под-состояние = STATE_NONE, следующее под-состояние = STATE_NONE
14: 9 ноября 02:36:34.978: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_SET_MODE, текущее состояние = CNFSM_CONTAINER_STATE, следующее состояние = CNFSM_NO_STATE_CHANGE
15: 9 ноября 02: 36: 34.978: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_PRE_SETUP, текущее состояние = S_SIP_IWF_SDP_IDLE, следующее состояние = CNFSM_NO_STATE_CHANGE
16: 9 ноября 02: 36: 34.979: // 2 / 96ABC1F680AA / CUBE_VT / SIP / MISC / Ошибка: sipSPI_ipip_build_consolidated_header_list: нет заголовков, связанных с тегом passthrulist: 0 и скопируйте
22: 9 ноя 02: 36: 34.979: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_PEER_MULTIMEDIA_CHANNEL_IND, текущее состояние = S_SIP_IWF_SDP_IDLE, следующее состояние = CNFS_MCHO_NO
23: 9 ноября 02:36:34.979: // 2 / 96ABC1F680AA / CUBE_VT / SIP / MISC / Параметры медиапотока: Тип потока = только голос, Состояние потока = STREAM_ADDING Согласованный кодек = Нет кодека, Согласованный тип DTMF = внутриполосный голос, Индекс потока = 1
24: 9 ноября 02: 36: 34.979: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Media-State: Событие = E_IPIP_MEDIA_SERV_EV_PEER_CHNL_IND, Текущее состояние = S_IPIP_MEDIA_SERV_STATE_IDLEIP, Следующее состояние = S_IPIP_MEDIA_SERV_STATE_IDLEIP_RAD_MODI
25: 9 ноября 02: 36: 34.980: // 2 / 96ABC1F680AA / CUBE_VT / SIP / MISC / Software-Error: Тип: Ошибка при резервировании транскодера, Расположение кода: 0x3004084
26: 9 ноября 02:36:34.980: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_CONTINUE_PRE_SETUP, текущее состояние = S_SIP_IWF_SDP_IDLE, следующее состояние = CNFSM_NO_STATE_CHANGE
27: 9 ноября 02: 36: 34.980: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_INIT_CALL_SETUP, текущее состояние = S_SIP_IWF_SDP_IDLE, следующее состояние = CNFSM_NO_STATE_CH
28: 9 ноября 02: 36: 34.980: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_allocate_port (8002)
29: 9 ноября 02: 36: 34.981: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_create_session (0)
30: 9 ноября 02:36:34.981: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_set_non_rtp_call (0)
31: 9 ноября 02: 36: 34.981: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
32: 9 ноября 02: 36: 34.981: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_update_interface_cac_resource (0)
33: 9 ноября 02: 36: 34.981: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_CC_CALL_SETUP, текущее состояние = STATE_IDLE
34: 9 ноября 02: 36: 34.981: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_call_proceeding (0)
35: 9 ноября 02: 36: 34.981: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Offer-Answer: Event = E_SIP_INVITE_SDP_SENT, текущее состояние = S_SIP_EARLY_DIALOG_IDLE, следующее состояние = S_SIP_EARLY_DIALOG_OAD
36: 9 ноября 02:36:34.981: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_SENT_SDP, текущее состояние = S_SIP_IWF_SDP_IDLE, следующее состояние = S_SIP_IWF_SDP_SENT_AWAIT_SDP
38: 9 ноября 02: 36: 34.983: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / SPI-State-Change: текущее состояние = STATE_IDLE, следующее состояние = STATE_SENT_INVITE, текущее под-состояние = STATE_NONE, следующее под-состояние = STATE_NONE
39: 9 ноября 02: 36: 34.983: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
40: 9 ноября 02: 36: 34.983: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_set_non_rtp_call (0)
41: 9 ноября 02:36:34.983: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
42: 9 ноября 02: 36: 34.984: // 2 / 96ABC1F680AA / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Отправлено: сообщение SIP UDP с 8.40.23.55:5060 на 8.41.17.71:40001
ПРИГЛАСИТЬ sip: [email protected]: 40001 SIP / 2.0
Через: SIP / 2.0 / UDP 8.40.23.55:5060;branch=z9hG4bK01EEE
Remote-Party-ID: "sipp" ; party = call; screen = no; privacy = off
От: "sipp" ; tag = 20777-4F7
Кому: 
Дата: пн, 09 ноя 2020 02:36:34 GMT
Call-ID: 38023A2E-216B11EB-8007A966-FCB2BDFB @ 8.40,23,55
Поддерживается: 100rel, таймер, приоритет ресурса, заменяет, sdp-anat
Мин-ЮВ: 1800
Cisco-Guid: 2527838710-1106383336-2158658254-3746786232
Пользовательский агент: Cisco-SIPGateway / IOS-17.5.20201104.183617
Разрешить: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 ПРИГЛАШАТЬ
Отметка времени: 1604889394
Контакты: 
Срок годности: 180
Разрешить-события: телефон-событие
Максимальное количество нападающих: 69
Идентификатор сеанса: 52cfadb8d2ff567d93c40769eb164427; удаленный = 00000000000000000000000000000000
Срок действия сеанса: 1800; refresher = uac
Тип содержимого: приложение / sdp
Content-Disposition: сеанс; обработка = требуется
Длина содержимого: 276

v = 0
o = CiscoSystemsSIP-GW-UserAgent 8332 7162 IN IP4 8.40,23,55
s = SIP-вызов
c = ВХОД IP4 8.40.23.55
т = 0 0
m = аудио 8002 RTP / AVP 0 101 19
c = ВХОД IP4 8.40.23.55
a = rtpmap: 0 PCMU / 8000
a = rtpmap: 101 телефонное событие / 8000
a = fmtp: 101 0-16
a = rtpmap: 19 CN / 8000
a = ptime: 20
a = sendonly

45: 9 ноября 02: 36: 34.985: // 2 / 96ABC1F680AA / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Получено: сообщение SIP UDP от 8.41.17.71:40001 до 8.40.23.55:5060
SIP / 2.0 100 Пробуем
Через: SIP / 2.0 / UDP 8.40.23.55:5060;branch=z9hG4bK01EEE
От: "sipp" ; tag = 20777-4F7
Кому: ; tag = 19688SIPpTag011
Call-ID: [email protected]
CSeq: 101 ПРИГЛАШАТЬ
Content-Length: 0


46: 9 ноября 02: 36: 34.985: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_NEW_MESSAGE, текущее состояние = STATE_SENT_INVITE
47: 9 ноября 02: 36: 34.985: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / SPI-State-Change: текущее состояние = STATE_SENT_INVITE, следующее состояние = STATE_RECD_PROCEEDING, текущее под-состояние = STATE_NONE, следующее под-состояние = STATE_SETUP_BUFFERED
48: 9 ноября 02:36:34.986: // 2 / 96ABC1F680AA / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Получено: сообщение SIP UDP от 8.41.17.71:40001 до 8.40.23.55:5060
SIP / 2.0 180 Звонок
Через: SIP / 2.0 / UDP 8.40.23.55:5060;branch=z9hG4bK01EEE
От: "sipp" ; tag = 20777-4F7
Кому: ; tag = 19688SIPpTag011
Call-ID: [email protected]
CSeq: 101 ПРИГЛАШАТЬ
Контакт: 
Content-Length: 0


49: 9 ноября 02: 36: 34.986: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_NEW_MESSAGE, текущее состояние = STATE_RECD_PROCEEDING
50: 9 ноября 02:36:34.986: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_call_alert (0)
51: 9 ноября 02: 36: 34.986: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / SPI-State-Change: текущее состояние = STATE_RECD_PROCEEDING, следующее состояние = STATE_RECD_PROCEEDING, текущее под-состояние = STATE_SETUP_BUFFERED, следующее под-состояние STATE_SETUP_BUFFERED
56: 9 ноября 02: 36: 34.987: // 2 / 96ABC1F680AA / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Получено: сообщение SIP UDP от 8.41.17.71:40001 до 8.40.23.55:5060
SIP / 2.0 200 ОК
Через: SIP / 2.0 / UDP 8.40.23.55:5060;branch=z9hG4bK01EEE
От: "sipp" ; tag = 20777-4F7
Кому: ; tag = 19688SIPpTag011
Call-ID: [email protected]
CSeq: 101 ПРИГЛАШАТЬ
Срок действия сеанса: 3600; refresher = uas
Идентификатор сеанса: bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb; удаленный = 52cfadb8d2ff567d93c40769eb164427
Тема: 52cfadb8d2ff567d93c40769eb164427;
Разрешить: ПРИГЛАШЕНИЕ, ОПЦИИ, ОБНОВЛЕНИЕ, ПОКА, ОТМЕНА, ПОДТВЕРЖДЕНИЕ, НАПРАВЛЕНИЕ, СООБЩЕНИЕ, ПОДПИСАТЬСЯ, УВЕДОМЛЕНИЕ, ИНФОРМАЦИЯ, РЕГИСТРАЦИЯ
Контакт: 
Тип содержимого: приложение / sdp
Длина содержимого: 143

v = 0
o = user1 53655765 2353687637 ВХОД IP4 8.41.17.71
s = -
c = ВХОД IP4 8.41.17.71
т = 0 0
m = аудио 6017 RTP / AVP 0
a = rtpmap: 0 PCMU / 8000
a = recvonly

58: 9 ноября 02: 36: 34.987: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_NEW_MESSAGE, текущее состояние = STATE_RECD_PROCEEDING
59: 9 ноября 02: 36: 34.989: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Offer-Answer: Event = E_SIP_INVITE_RESP_SDP_RCVD, текущее состояние = S_SIP_EARLY_DIALOG_OFFER_SENT, следующее состояние = S_SIP_ARLY_DIALOG_OFFER_SENT, следующее состояние = S_SIPOFFER_SIP_SIP
60: 9 ноября 02: 36: 34.989: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_RCVD_SDP, текущее состояние = S_SIP_IWF_SDP_SENT_AWAIT_SDP, следующее состояние = S_SIP_IWF
61: 9 ноября 02:36:34.989: // 2 / 96ABC1F680AA / CUBE_VT / SIP / MISC / Параметры медиа-потока: Тип потока = только для голоса, Состояние потока = STREAM_ADDING Согласованный кодек = g711ulaw, Согласованный тип DTMF = внутриполосный голос, Индекс потока = 1
62: 9 ноября 02: 36: 34.989: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_call_mode_update_ind (0)
66: 9 ноября 02: 36: 34.989: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_caps_ind (0)
67: 9 ноября 02: 36: 34.989: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / SPI-State-Change: текущее состояние = STATE_RECD_PROCEEDING, следующее состояние = STATE_RECD_PROCEEDING, текущее под-состояние = STATE_SETUP_BUFFERED = следующее под-состояние STATE_NONE
68: 9 ноября 02:36:34.989: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_call_connected (0)
69: 9 ноября 02: 36: 34.989: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / SPI-State-Change: текущее состояние = STATE_RECD_PROCEEDING, следующее состояние = SIP_STATE_RECD_SUCCESS, текущее под-состояние = STATE_NONE, следующее под-состояние = STATE_NONE
70: 9 ноября 02: 36: 34.989: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Offer-Answer: Event = E_SIP_DIALOG_ESTD, текущее состояние = S_SIP_EARLY_DIALOG_OFFER_ANSWER_COMPLETE, следующее состояние = S_SIPLEID_MOD
71: 9 ноября 02: 36: 34.989: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_CALL_ACTIVE, текущее состояние = CNFSM_CONTAINER_STATE, следующее состояние = CNFSM_NO_STATE_CHANGE
72: 9 ноября 02:36:34.989: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Media-State: событие = E_IPIP_MEDIA_SERV_EV_CALL_ACTIVE, текущее состояние = CNFSM_CONTAINER_STATE, следующее состояние = CNFSM_NO_STATE_CHANGE
73: 9 ноября 02: 36: 34.989: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / SPI-State-Change: Current State = SIP_STATE_RECD_SUCCESS, Next State = STATE_ACTIVE, Current Sub-State = STATE_NONE, Next Sub-State = STATE_NONE
74: 9 ноября 02: 36: 34.990: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_UPDATE_STREAM_CONTEXT, текущее состояние = S_SIP_IWF_SDP_DONE, следующее состояние = CNFS_M_NOGE_
75: 9 ноября 02:36:34.990: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
76: 9 ноября 02: 36: 34.990: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: Event = E_SIP_IWF_EV_PEER_CAPS_ACK ,, Текущее состояние = CNFSM_CONTAINER_STATE, следующее состояние = CNFSM_NO_STATE_CHANGE
77: 9 ноября 02: 36: 34.990: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: Event = E_SIP_IWF_EV_PEER_CAPS_ACK ,, Текущее состояние = CNFSM_CONTAINER_STATE, следующее состояние = CNFSM_NO_STATE_CHANGE
83: 9 ноября 02: 36: 34.990: // 2 / 96ABC1F680AA / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Отправлено: сообщение SIP UDP от 8.40.23.55: 5060 к 8.41.17.71:40001
ACK sip: [email protected]: 40001; транспорт = UDP SIP / 2.0
Через: SIP / 2.0 / UDP 8.40.23.55:5060;branch=z9hG4bK16C9
От: "sipp" ; tag = 20777-4F7
Кому: ; tag = 19688SIPpTag011
Дата: пн, 09 ноя 2020 02:36:34 GMT
Call-ID: [email protected]
Максимальное количество нападающих: 70
CSeq: 101 ACK
Разрешить-события: телефон-событие
Идентификатор сеанса: 52cfadb8d2ff567d93c40769eb164427; удаленный = bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
Content-Length: 0


90: 9 ноября 02:36:34.991: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / IWF: событие = E_SIP_IWF_EV_CALL_BRIDGE, текущее состояние = S_SIP_IWF_SDP_DONE, следующее состояние = CNFSM_NO_STATE_CHANGE
91: 9 ноября 02: 36: 34.991: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
92: 9 ноября 02: 36: 34.991: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_set_non_rtp_call (0)
93: 9 ноября 02: 36: 34.991: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
94: 9 ноября 02: 36: 34.991: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
95: 9 ноября 02:36:34.991: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_bridge_done (0)
96: 9 ноября 02: 36: 34.991: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: ccsip_bridge (0)
179: 9 ноября 02: 38: 35.031: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Media-State: событие = E_IPIP_MEDIA_SERV_EV_XCODER_RESET_STREAM, текущее состояние = CNFSM_CONTAINER_STATE, следующее состояние = SIA_IPLE_IPLEM_STATE
180: 9 ноября 02: 38: 35.031: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_update_callinfo (0)
181: 9 ноября 02: 38: 35.031: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_bridge_drop_done (0)
191: 9 ноября 02:38:35.033: // 2 / 96ABC1F680AA / CUBE_VT / SIP / MISC / Отключение вызова: инициировано: 0x260070A, отправлено: 0x260070B, код причины = 16
197: 9 ноября 02: 38: 35.033: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_update_interface_cac_resource (0)
198: 9 ноября 02: 38: 35.033: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_CC_CALL_DISCONNECT, текущее состояние = STATE_ACTIVE
199: 9 ноября 02: 38: 35.034: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / SPI-State-Change: Current State = STATE_ACTIVE, Next State = STATE_DISCONNECTING, Current Sub-State = STATE_NONE, Next Sub-State = STATE_NONE
201: 9 ноября, 02:38:35.034: // 2 / 96ABC1F680AA / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Отправлено: сообщение SIP UDP с 8.40.23.55:5060 на 8.41.17.71:40001
BYE sip: [email protected]: 40001; транспорт = UDP SIP / 2.0
Через: SIP / 2.0 / UDP 8.40.23.55:5060;branch=z9hG4bK637D
От: "sipp" ; tag = 20777-4F7
Кому: ; tag = 19688SIPpTag011
Дата: пн, 09 ноя 2020 02:36:34 GMT
Call-ID: [email protected]
Пользовательский агент: Cisco-SIPGateway / IOS-17.5.20201104.183617
Максимальное количество нападающих: 70
Отметка времени: 1604889515
CSeq: 102 BYE
Причина: В.850; причина = 16
Идентификатор сеанса: 52cfadb8d2ff567d93c40769eb164427; удаленный = bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
Content-Length: 0


210: 9 ноября 02: 38: 35.036: // 2 / 96ABC1F680AA / CUBE_VT / SIP / Msg / ccsipDisplayMsg:
Получено: сообщение SIP UDP от 8.41.17.71:40001 до 8.40.23.55:5060
SIP / 2.0 200 ОК
Через: SIP / 2.0 / UDP 8.40.23.55:5060;branch=z9hG4bK637D
От: "sipp" ; tag = 20777-4F7
Кому: ; tag = 19688SIPpTag011
Call-ID: [email protected]
CSeq: 102 BYE
Обращаться: 
Content-Length: 0


211: 9 ноября 02: 38: 35.036: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / Событие-действие: событие = SIPSPI_EV_NEW_MESSAGE, текущее состояние = STATE_DISCONNECTING
212: 9 ноября 02: 38: 35.036: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: voip_rtp_delete_dp_session (0)
213: 9 ноября 02: 38: 35.036: // 2 / 96ABC1F680AA / CUBE_VT / SIP / API: cc_api_call_disconnect_done (0)
214: 9 ноября 02: 38: 35.036: // 2 / 96ABC1F680AA / CUBE_VT / SIP / FSM / SPI-State-Change: текущее состояние = STATE_DISCONNECTING, следующее состояние = STATE_DEAD, текущее под-состояние = STATE_NONE, следующее под-состояние = STATE_NONE
215: 9 ноября 02:38:35.036: // 2 / 96ABC1F680AA / CUBE_VT / SIP / MISC / Ошибка: sipSPIFlushDeferredQueue: недопустимая deferredQueue

  

Примеры

Если вы настраиваете завершение работы команды CLI в подрежиме конфигурации трассировки, команда show не отображает информацию трассировки. Ниже приведен пример команды шоу. вывод для сценария:

  router # config terminal
Введите команды конфигурации, по одной в каждой строке.Закончите CNTL / Z.
router (config) # голосовая служба voip
маршрутизатор (conf-voi-serv) #trace
маршрутизатор (conf-serv-trace) # выключение
маршрутизатор (conf-serv-trace) # выход
маршрутизатор (conf-voi-serv) # выход
router (config) #end
router # показать трассировку VoIP все | sec Защитный буфер
router # показать VoIP трассировку все
                 Нет данных для отображения !!

router # показать идентификатор вызова VoIP-трассировки 7
                 Нет записей для указанного фильтра !!

роутер #
  

.