Нормативная полезная нагрузка на перекрытие: Нормативная нагрузка на перекрытие жилого дома

09.08.2023

0 Comment

Содержание

Коэффициенты надежности при сборе нагрузок

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

Наименование нагрузки	Нормативная в кг/кв. м	Коэффициент	Расчетная в кг/кв. м
Ламинат	8
Подложка	0,6
Фанера	7,8
Брус 75 х 40 мм с шагом 508 мм	2,95
Дощатый настил 40 мм	20
Дощатый настил 25 мм. 12,5 кг	12,5
Каркас ГКЛ. 5 кг	5
Лист ГКЛ 9,5 мм. 7,5 кг	7,5
Шпатлевка. 3кг	3
Краска 2кг	2
Полезная нагрузка	150
Итого:	219,35

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

Допустим, на основании расчета мы определили что балка сечением 10х20 см выдержит подсчитанную нагрузку. При этом, запас прочности примерно равен нулю. Это значит что при превышении нагрузки хотябы на 1 кг/м балка разрушится. Но, что если дощатый настил по факту оказался толщиной не 40 мм, а 41. Тогда значение нагрузки уже будет превышать рассчетное. Если по каждому материалу в составе перекрытия будет превышение, то, в итоге, фактическое значение нагрузки может отличаться от теоретического на 5-10 %.

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

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

Конструкции сооружений и вид грунтов	Коэффициент надежности по нагрузке γ_f
Конструкции
Металлические, за исключением случаев, указанных в 7.3	1,05
Бетонные (со средней плотностью свыше 1600 кг/м³), железобетонные, каменные, армокаменные, деревянные	1,1
Бетонные (со средней плотностью 1600 кг/м³ и менее), изоляционные, выравнивающие и отделочные слои (плиты, материалы в рулонах, засыпки, стяжки и т. п.), выполняемые:
в заводских условиях	1,2
на строительной площадке	1,3
Грунты
В природном залегании	1,1
На строительной площадке	1,15
Примечание. При определении нагрузок от грунта следует учитывать нагрузки от складируемых материалов, оборудования и транспортных средств, передаваемые на грунт.

Считаем по порядку.

Ламинат.
Нормативная нагрузка 8 кг/кв. м
Коэффициент (отделочный слой, выполненный в заводских условиях) 1,2
Расчетная нагрузка 8 х 1,2 = 9,6 кг/кв. м
Подложка.
Нормативная 0,6 кг/кв. м
Коэффициент 1,2
Расчетная 0,6 х 1,2 = 0,72 кг/кв. м
Фанера.
Нормативная 7,8
Коэффициент 1,2
Расчетная 7,8 х 1,2 = 9,36 кг/кв. м
Брус. 2,95 х 1,1 = 3,25 кг/кв. м
Дощатый настил 40 мм. 20 х 1,1 = 22 кг/кв. м
Дощатый настил 25 мм. 12,5 х 1,1 = 13,75 кг/кв. м
Каркас ГКЛ. 5 х 1,05 = 5,25 кг/кв. м
Лист ГКЛ 9,5 мм. 7,5 х 1,2 = 9 кг/кв. м
Шпатлевка. 3 х 1,3 = 3,9 кг/кв. м
Краска. 2 х 1,3 = 2,6 кг/кв. м

Последнее значение нормативной нагрузки — полезная нагрузка в жилых помещениях 150 кг/кв. м. В пункте 8.2.2 СНиПа на этот случай указано принимать коэффициент надежности равный 1,3 для нагрузки менее 2 кПа (что примерно 200 кг/кв. м) и 1,2 для нагрузки более 2 кПа.

Получается 150 х 1,3 = 195 кг/кв. м.

Заполняем пустые ячейки в таблице.

Наименование нагрузки	Нормативная в кг/кв. м	Коэффициент	Расчетная в кг/кв. м
Ламинат	8	1,2	9,6
Подложка	0,6	1,2	0,72
Фанера	7,8	1,2	9,36
Брус 75 х 40 мм с шагом 508 мм	2,95	1,1	3,25
Дощатый настил 40 мм	20	1,1	22
Дощатый настил 25 мм. 12,5 кг	12,5	1,1	13,75
Каркас ГКЛ. 5 кг	5	1,05	5,25
Лист ГКЛ 9,5 мм. 7,5 кг	7,5	1,2	9
Шпатлевка. 3кг	3	1,3	3,9
Краска 2кг	2	1,3	2,6
Полезная нагрузка	150	1,3	195
Итого:	219,35		274,43

В итоге, мы получили второе значение нагрузки — расчетное. Для определения прогиба нужно использовать нормативную нагрузку — 219,35 кг/кв. м, а для определения прочности необходимо использовать повышенную соответствующими коэффициентами расчетную нагрузку 274,43 кг/кв. м.

Материалы

Из чего строят здания

Проектирование

Сбор нагрузок, расчёты

Инструменты

Чем строят здания

Контроль

Контроль качества на стройке

Конструкции

Части зданий или отдельные

Оборудование

Чем оборудуют помещения

Изделия

Готовые части зданий

Услуги

Услуги в сфере строительства

Право

Сертификация, разрешения

Рынок

Недвижимость, цены, аналитика

Пресс релизы

О компаниях и их продукции, услугах

2.

Конструктивное решение | КриоРус

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

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

Бескаркасная схема подземной части из монолитного железобетона;

Каркасная схема центральной части из металлических колонн Г-образной формы и металлических балок для устройства колокольной части и купола;

Каркасная схема прилегающих помещений (тамбура, притворов, приделов, служебных помещений), представляющая собой систему колонн, балок и плит перекрытий. Шаг колонн – 6 м, пролет балок — 4,2 м: 7,2 м и 9 м.

Так как основанием фундамента является скальный грунт, то для обеспечения конструктивной жесткости подземной и надземной частей, в качестве фундамента принят монолитный железобетон. Стены подземной части и плиты перекрытия также принимаем из железобетона класса В12,5 с армированием арматурой периодического профиля класса АIII.

Монолитная плита перекрытия подземной части на отметке -0,45 выполнена в виде плиты с консольными свесами.

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

Колонны и балки каркаса прилегающих частей (тамбура, притворов, приделов и служебных помещений) также запроектированы из сварных прокатных элементов. Балки длиной 4,2 м приняты из прокатного двутавра. По балкам укладываются железобетонные пустотные плиты перекрытия толщиной 22 см, шириной 1 м: 1,2 м: 1.5 м и длинной 6 м и 6,3 м заводского изготовления.

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

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

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

Расчет многопустотной плиты перекрытия в помещении притвора храма

Исходные данные:

Класс бетона: В — 12,5
R_B = 7,5 мПа

Класс арматуры A – III
R_S = 355 мПа

Временная нагрузка на перекрытие – 3,50 н/м²

Многопустотная панель с круглыми пустотами L=6,3 м; ширина В=1,0 м; высота h=22 см

Решение:

1. Определяем нагрузки на 1 м длины панели шириной 100 см (кг/м)

№ п/н	Нагрузки	Нормативная нагрузка	Коэффициент надежности	Расчетные нагрузки
1	Полезная нагрузка (кратковременная) Р^н	3,50	1,3	4,55
2	Вес пола	0,7	1,1	0,77
3	Собственный вес ж/б плиты	2,0	1,1	2,2
	Итого: полная нагрузка q₁ = q+p	q^н =6,2		q^p = 7,5

Расчет нагрузки на 1 м:

q = q₁^P = 7,5 * 1,0 = 7,5 Кн

Расчетный изгибающий момент от полной нагрузки

М = q*l₀²/8 = 7,5 x 6,2²/8 = 36,12 Кн*м = 3612000 нсм; где L₀=6,3-0,2/2 = 6,2 м

Подбор арматуры

Панель рассчитываем как балку прямоугольного сечения с заданными размерами b*h=100*22 (где b-номинальная ширина, h-высота панели).

Проектируем панель прямоугольной:

Вычисляем А₀= M / (R_b * b_f * h₀²)= 3 612 000 / 7,5 * 100 * 97 * 19² = 0,232; где h₀ = h-a = 22-3=19см

По таблице 4 «Методических указаний для выполнения курсового проекта» находим η = 0,865, ξ = 0,27.

Площадь сечения продольной арматуры: As = M / (η * h₀ * R_s) =3 612 000 / (0,866*19*355*100) = 3 612 000 / 583 443 =10,48 см²

Принимаем 6 ∅ 16 АIII, As = 12,06 см²

Содержание

RFC 5391 — Формат полезной нагрузки RTP для Рекомендации ITU-T G.711.1

Javascript отключен? Как и другие современные веб-сайты, IETF Datatracker использует Javascript. Пожалуйста, включите Javascript для полной функциональности.

Сетевая рабочая группа А. Солло
Запрос комментариев: 5391 France Telecom
Категория: Трек стандартов, ноябрь 2008 г.
Формат полезной нагрузки RTP для Рекомендации ITU-T G.711.1
Статус этого меморандума
Этот документ определяет протокол отслеживания стандартов Интернета для
Интернет-сообщество, а также запросы на обсуждение и предложения по
улучшения. Пожалуйста, обратитесь к текущему выпуску «Интернет
Стандарты официальных протоколов» (STD 1) для состояния стандартизации
и статус этого протокола. Распространение этой памятки не ограничено.
Уведомление об авторских правах
Copyright (c) IETF Trust, 2008 г., и лица, указанные в качестве
авторы документа. Все права защищены.
Этот документ регулируется BCP 78 и юридическими документами IETF Trust.
Положения, касающиеся документов IETF (http://trustee.ietf.org/
лицензия-информация), действующая на дату публикации этого документа.
Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права.
и ограничения в отношении этого документа.
Абстрактный
Этот документ определяет полезную нагрузку транспортного протокола реального времени (RTP).
формат, который будет использоваться для стандартизации электросвязи ITU
Аудиокодек Sector (ITU-T) G.711.1. Две регистрации типа носителя
также включены.
Отслеживание стандартов Sollaud [Страница 1]
RFC 5391 Формат полезной нагрузки RTP для G.711.1, ноябрь 2008 г.
Оглавление
1. Введение ............................................... .....2
2. Предыстория ...................................................... .......2
3. Использование заголовка RTP ....................................... ...3
4. Формат полезной нагрузки ....................................... ....4
4.1. Заголовок полезной нагрузки ......................................4
4.2. Аудиоданные ................................................................ .5
5. Параметры формата полезной нагрузки ......................................6
5.1. Регистрация типа носителя PCMA-WB ................................7
5.2. Регистрация типа носителя PCMU-WB ............................... .8
5.3. Сопоставление с параметрами SDP ................................95.3.1. Соображения по модели «предложение-ответ»... 9
5.3.2. Декларативные аспекты SDP ................................11
6. Функциональная совместимость G.711 ......................................11
7. Контроль перегрузки .............................................12
8. Вопросы безопасности ......................................12
9. Соображения IANA ................................................12
10. Ссылки ....................................................... .....13
10.1. Нормативные ссылки ......................................13
10.2. Информативные ссылки ......................................13
1. Введение
Сектор стандартизации электросвязи ITU (ITU-T)
Рекомендация G.711.1 [ITU-G.711.1] представляет собой встроенный широкополосный
расширение аудиокодека Рекомендации G.711 [ITU-G.711]. Этот
документ определяет формат полезной нагрузки для пакетирования G. 711.1
закодированные аудиосигналы в транспортный протокол реального времени (RTP).
Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН»,
"СЛЕДУЕТ", "НЕ СЛЕДУЕТ", "РЕКОМЕНДУЕТСЯ", "МОЖЕТ" и "ДОПОЛНИТЕЛЬНО" в этом
документ должны интерпретироваться, как описано в [RFC2119].
2. Фон
G.711.1 — это встроенное широкополосное кодирование речи и звука G.711.
алгоритм, работающий на скоростях 64, 80 и 96 кбит/с. При скорости 64 кбит/с G.711.1
полностью совместим с G.711. Таким образом, эффективное развертывание в
существующая инфраструктура передачи голоса по IP (VoIP) на базе G.711
предвидится.
Кодек работает с кадрами длительностью 5 мс, а частота дискретизации по умолчанию равна
16 кГц. Вход и выход на частоте 8 кГц также поддерживаются для узкополосных
режимы.
Отслеживание стандартов Sollaud [Страница 2]
RFC 5391 Формат полезной нагрузки RTP для G.711.1, ноябрь 2008 г.
Кодер создает встроенный битовый поток, структурированный в три слоя.
соответствующие трем доступным битрейтам: 64, 80 и 96 кбит/с.
битовый поток может быть усечен на стороне декодера или любым компонентом
система связи для настройки «на лету» скорости передачи данных
желаемое значение.
В следующей таблице приведены более подробные сведения об этих слоях.
+-------+----------+-----------+
| Слой | Описание | Битрейт |
+-------+----------+-----------+
| L0 | Совместимость с G.711 | 64 кбит/с |
| Л1 | узкополосное усиление | 16 кбит/с |
| L2 | широкополосное расширение | 16 кбит/с |
+-------+----------+-----------+
Таблица 1: Описание слоев
Комбинации этих трех слоев приводят к определению
четыре режима в соответствии со следующей таблицей.
+------+----+----+----+-------------+----------+
| Режим | L0 | Л1 | L2 | Аудио группа | Битрейт |
+------+----+----+----+-------------+----------+
| Р1 | х | | | узкополосный | 64 кбит/с |
| R2a | х | х | | узкополосный | 80 кбит/с |
| R2b | х | | х | широкополосный | 80 кбит/с |
| Р3 | х | х | х | широкополосный | 96 кбит/с |
+------+----+----+----+-------------+----------+
Таблица 2: Описание режимов
3. Использование заголовка RTP
Формат заголовка RTP указан в [RFC3550]. Полезная нагрузка
формат, определенный в этом документе, использует поля заголовка в
способом, соответствующим этой спецификации.
маркер (М):
G.711.1 не определяет ничего конкретного относительно прерывистого
Передача (DTX), также известная как подавление тишины. Кодек-независимый
могут использоваться механизмы, такие как общая полезная нагрузка комфортного шума
формат, определенный в [RFC3389].
Для приложений, которые либо не отправляют пакеты, либо время от времени
пакеты комфортного шума во время тишины, первый пакет
talkspurt -- то есть первый пакет после периода молчания
во время которого пакеты не были переданы непрерывно --
Отслеживание стандартов Sollaud [Страница 3]
RFC 5391 Формат полезной нагрузки RTP для G.711.1, ноябрь 2008 г.
СЛЕДУЕТ различать установку бита маркера в данных RTP.
заголовок к одному. Бит маркера во всех других пакетах равен нулю.
начало разговора МОЖЕТ использоваться для настройки задержки воспроизведения
чтобы отразить изменение сетевых задержек. Приложения без тишины
подавление ДОЛЖНО установить бит маркера в ноль.
тип полезной нагрузки (ПТ):
Назначение типа полезной нагрузки RTP для этого формата пакета:
выходит за рамки данного документа и не будет указан
здесь. Ожидается, что профиль RTP, под которым
используется формат полезной нагрузки, назначит тип полезной нагрузки для этого
кодек или укажите, что тип полезной нагрузки должен быть привязан динамически
(см. раздел 5.3).
отметка времени:
Тактовая частота метки времени RTP такая же, как и по умолчанию.
частота дискретизации: 16 кГц.
G.711.1 также может работать с частотой дискретизации 8 кГц.
входные/выходные сигналы. Это не влияет на битовый поток, и
декодер не требует априорных знаний о дискретизации
скорость исходного сигнала на входе энкодера.
Поэтому в зависимости от реализации и аудиоакустического
возможности устройств, вход энкодера и/или
выход декодера можно настроить на 8 кГц; однако
Всегда ДОЛЖНА использоваться тактовая частота RTP 16 кГц.
Продолжительность одного кадра составляет 5 мс, что соответствует 80 выборкам на
16 кГц. Таким образом, метка времени увеличивается на 80 для каждого
последовательный кадр.
4. Формат полезной нагрузки
Полная полезная нагрузка состоит из заголовка полезной нагрузки из 1 октета,
за которым следует один или несколько последовательных аудиокадров G.711.1 одного и того же
режим.
Режим может меняться между пакетами, но не внутри пакета.
4.1. Заголовок полезной нагрузки
Заголовок полезной нагрузки показан ниже.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 0 0 0 0| Ми |
+-+-+-+-+-+-+-+-+
Отслеживание стандартов Sollaud [Страница 4]
RFC 5391 Формат полезной нагрузки RTP для G.711.1, ноябрь 2008 г.
Пять старших битов зарезервированы для дальнейшего расширения и
ДОЛЖЕН быть установлен на ноль и ДОЛЖЕН игнорироваться приемниками.
Поле индекса режима (MI) (3 бита) дает режим следующего
кадр(ы) в соответствии с таблицей:
+------------+---------------+------------+
| Индекс режима | Режим G. 711.1 | Размер кадра |
+------------+---------------+------------+
| 1 | Р1 | 40 октетов |
| 2 | R2a | 50 октетов |
| 3 | R2b | 50 октетов |
| 4 | Р3 | 60 октетов |
+------------+---------------+------------+
Таблица 3: Режимы в заголовке полезной нагрузки
Все остальные значения MI зарезервированы для использования в будущем и НЕ ДОЛЖНЫ
использовал.
Полезные нагрузки, полученные с неопределенным значением MI, ДОЛЖНЫ быть отброшены.
Если сигнализацией установлен ограниченный набор режимов (см.
Раздел 5), полезные данные, полученные со значением MI, не входящим в этот набор, ДОЛЖНЫ
быть отброшены.
4.2. Аудиоданные
После этого заголовка полезной нагрузки последовательные аудиокадры упаковываются в
порядок времени, то есть сначала самый старый. Все кадры ДОЛЖНЫ быть одинаковыми
режим, указанный полем MI заголовка полезной нагрузки.
Внутри кадра слои всегда располагаются в одном и том же порядке: L0, затем
L1 для режима R2a, L0, затем L2 для режима R2b, L0, затем L1, затем L2 для режима
Р3. Это показано ниже.
Отслеживание стандартов Sollaud [Страница 5]
RFC 5391 Формат полезной нагрузки RTP для G.711.1, ноябрь 2008 г.
+--------------------------------+
Р1 | L0 |
+--------------------------------+
+-------------------------------+---------+
R2a | L0 | Л1 |
+-------------------------------+---------+
+-------------------------------+---------+
R2b | L0 | L2 |
+-------------------------------+---------+
+-------------------------------+---------+-------- +
Р3 | L0 | Л1 | L2 |
+-------------------------------+---------+-------- +
Размер одного кадра определяется режимом согласно таблице 3, а
фактическое количество кадров легко определить по размеру аудио
часть данных:
nb_frames = (размер_аудио_данных) / (размер_одного_кадра).
Должны рассматриваться только полные кадры. Итак, если есть остаток
деление выше, соответствующие оставшиеся байты в полученном
полезная нагрузка ДОЛЖНА игнорироваться.
5. Параметры формата полезной нагрузки
В этом разделе определяются параметры, которые могут использоваться для настройки
дополнительные функции в передаче G.711.1 RTP.
И A-закон, и мю-закон G.711 поддерживаются на базовом уровне L0, но
между А-законом и мю-законом нет взаимодействия. Так что два СМИ
будут определены типы с одинаковыми параметрами: audio/PCMA-WB для
Ядро A-закона и аудио/PCMU-WB для ядра мю-закона. Это последовательно
с разделением типов носителей audio/PCMA и audio/PCMU для G.711
аудио.
Параметры определяются здесь как часть подтипа носителя.
регистрации для кодека G.711.1. Отображение параметров
в протокол описания сеанса (SDP) [RFC4566] также
предоставляется для тех приложений, которые используют SDP. В протоколах управления
которые не используют MIME или SDP, параметры типа носителя должны быть сопоставлены
в соответствующий формат, используемый с этим протоколом управления.
Отслеживание стандартов Sollaud [Страница 6]
RFC 5391 Формат полезной нагрузки RTP для G. 711.1, ноябрь 2008 г.
5.1. Регистрация типа носителя PCMA-WB
Эта регистрация выполняется с использованием шаблона, определенного в [RFC4288] и
после [RFC4855].
Название типа: аудио
Название подтипа: PCMA-WB
Обязательные параметры: нет
Дополнительные параметры:
набор режимов: ограничивает активный набор режимов кодека подмножеством всех
режимы. Возможные значения — список режимов, разделенных запятыми.
из набора: 1, 2, 3, 4 (см. индекс режима в таблице 3 RFC
5391). Режимы перечислены в порядке предпочтения; первый это
предпочтительно. Если указан набор режимов, кадры, закодированные с режимами
за пределами подмножества НЕ ДОЛЖНЫ отправляться в какой-либо полезной нагрузке RTP. Если
отсутствует, разрешены все режимы кодека.
ptime: рекомендуемая продолжительность времени (в миллисекундах)
представленный носителем в пакете. Это должно быть целое число
кратно 5 мс (размер кадра). См. Раздел 6 RFC 4566.
maxptime: максимальное время (в миллисекундах), которое может
быть инкапсулированы в пакет. Должно быть целое кратное
5 мс (размер кадра). См. Раздел 6 RFC 4566.
Соображения по кодированию: Этот тип носителя имеет фреймы и содержит
бинарные данные. См. Раздел 4.8 RFC 4288.
Вопросы безопасности: см. раздел 8 RFC 539.1.
Вопросы совместимости: нет
Опубликованная спецификация: RFC 5391.
Приложения, использующие этот тип мультимедиа: аудио- и видеоконференции.
инструменты.
Дополнительная информация: нет
Контактное лицо и адрес электронной почты для получения дополнительной информации: Aurelien
Солло, [email protected]
Предполагаемое использование: ОБЩИЙ
Отслеживание стандартов Sollaud [Страница 7]
RFC 5391 Формат полезной нагрузки RTP для G.711.1, ноябрь 2008 г.
Ограничения на использование: этот тип носителя зависит от кадрирования RTP и
следовательно, он определен только для передачи через RTP.
Автор: Орельен Солло.
Контроллер изменений: делегирована рабочая группа IETF Audio/Video Transport
от IESG
5.2. Регистрация типа носителя PCMU-WB
Эта регистрация выполняется с использованием шаблона, определенного в [RFC4288] и
после [RFC4855].
Название типа: аудио
Название подтипа: PCMU-WB
Обязательные параметры: нет
Дополнительные параметры:
набор режимов: ограничивает набор режимов активного кодека подмножеством всех
режимы. Возможные значения — список режимов, разделенных запятыми.
из набора: 1, 2, 3, 4 (см. индекс режима в таблице 3 RFC
5391). Режимы перечислены в порядке предпочтения; первый это
предпочтительно. Если указан набор режимов, кадры, закодированные с режимами
за пределами подмножества НЕ ДОЛЖНЫ отправляться в какой-либо полезной нагрузке RTP. Если
отсутствует, разрешены все режимы кодека.
ptime: рекомендуемая продолжительность времени (в миллисекундах)
представленный носителем в пакете. Это должно быть целое число
кратно 5 мс (размер кадра). См. Раздел 6 RFC 4566.
maxptime: максимальное время (в миллисекундах), которое может
быть инкапсулированы в пакет. Должно быть целое кратное
5 мс (размер кадра). См. Раздел 6 RFC 4566.
Соображения по кодированию: Этот тип носителя имеет фреймы и содержит
бинарные данные. См. Раздел 4.8 RFC 4288.
Вопросы безопасности: см. раздел 8 RFC 539.1.
Вопросы совместимости: нет
Опубликованная спецификация: RFC 5391.
Приложения, использующие этот тип мультимедиа: аудио- и видеоконференции.
инструменты.
Отслеживание стандартов Sollaud [Страница 8]
RFC 5391 Формат полезной нагрузки RTP для G.711.1, ноябрь 2008 г.
Дополнительная информация: нет
Контактное лицо и адрес электронной почты для получения дополнительной информации: Aurelien
Солло, [email protected]
Предполагаемое использование: ОБЩИЙ
Ограничения на использование: этот тип носителя зависит от кадрирования RTP и
следовательно, он определен только для передачи через RTP.
Автор: Орельен Солло.
Контроллер изменений: делегирована рабочая группа IETF Audio/Video Transport
от IESG
5.3. Сопоставление с параметрами SDP
Информация, содержащаяся в спецификации типа носителя, имеет
конкретное сопоставление с полями в протоколе описания сеанса (SDP)
[RFC4566], который обычно используется для описания сеансов RTP. Когда СДП
используется для указания сеансов с использованием кодека G.711.1, отображение
как следует:
o Тип медиа ("аудио") указывается в SDP "m=" как имя медиа.
o Подтип носителя («PCMA-WB» или «PCMU-WB») указывается в SDP «a=rtpmap».
как имя кодировки. Тактовая частота RTP в «a=rtpmap» ДОЛЖНА быть
16000 для G.711.1.
o Параметр "mode-set" входит в атрибут SDP "a=fmtp"
скопировав его как строку "mode-set=".
o Параметры "ptime" и "maxptime" идут в SDP "a=ptime" и
Атрибуты "a=maxptime" соответственно.
5.3.1. Соображения по модели «предложение-ответ»
Следующие соображения применимы при использовании предложения-ответа SDP.
процедуры [RFC3264] для согласования использования полезной нагрузки G.711.1 в RTP:
o Так как G.711.1 является расширением G.711, предлагающий СЛЕДУЕТ
объявить о поддержке G.711 в своей строке «m = audio» с G.711.1
предпочтительно. Это позволит взаимодействовать как с G.711.1, так и с G.711.1.
Стороны, поддерживающие только G.711. Это делается путем предложения PCMA
подтип носителя в дополнение к PCMA-WB и/или PCMU в дополнение к
ПКМУ-ВБ.
Отслеживание стандартов Sollaud [Страница 9]
RFC 5391 Формат полезной нагрузки RTP для G.711.1, ноябрь 2008 г.
Ниже приведен пример части такого предложения для A-law:
m=аудио 54874 RTP/AVP 96 8
a=rtpmap:96 PCMA-WB/16000
a=rtpmap:8 PCMA/8000
Напоминаем, что формат полезной нагрузки для G.711 определен в разделе
4.5.14 [RFC3551].
o Параметр "mode-set" является двунаправленным; т. е. ограниченный
mode-set применяется к медиа как для приема, так и для отправки
декларирующее юридическое лицо. Если в предложении указан набор режимов,
ответчик ДОЛЖЕН вернуть либо тот же набор режимов, либо подмножество этого
набор режимов. Ответчик МОЖЕТ изменить порядок предпочтений. Если нет
набор режимов был указан в предложении, ответчик МОЖЕТ вернуть режим-
установлен для ограничения возможных режимов. В любом случае, режим, установленный в
тогда ответ применяется как к предлагающему, так и к отвечающему.
предлагающий НЕ ДОЛЖЕН отправлять кадры режима, который был удален
ответчик.
Для сеансов многоадресной рассылки, если в предложении указано «mode-set»,
ответчик ДОЛЖЕН участвовать в сеансе, только если он поддерживает
предлагаемый набор режимов.
o Параметры "ptime" и "maxptime" в большинстве случаев не
влияют на интероперабельность. Обработка предложения-ответа SDP
Параметр "ptime" описан в [RFC3264]. "максимальное время"
параметр ДОЛЖЕН обрабатываться таким же образом.
o Любой неизвестный параметр в предложении ДОЛЖЕН игнорироваться получателем.
и НЕ ДОЛЖНЫ быть включены в ответ.
Ниже приведены некоторые примеры обмена предложениями и ответами SDP.
о Пример 1
Предложение: G.711.1 для всех режимов с откатом G.711, предпочтение отдается мю-закону.
м=аудио 54874 RTP/AVP 96 97 0 8
a=rtpmap:96 PCMU-WB/16000
a=rtpmap:97 PCMA-WB/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
Ответ: принимаются все моды, как мю-, так и А-законы.
m=аудио 59452 RTP/AVP 96 97
a=rtpmap:96 PCMU-WB/16000
a=rtpmap:97 PCMA-WB/16000
Отслеживание стандартов Sollaud [Страница 10]
RFC 5391 Формат полезной нагрузки RTP для G.711.1, ноябрь 2008 г.
о Пример 2
Предложение: G.711.1 для всех режимов с откатом G.711, предпочтение отдается закону A.
м=аудио 54874 RTP/AVP 96 97 8 0
a=rtpmap:96 PCMA-WB/16000
a=rtpmap:97 PCMU-WB/16000
Ответ: хочет только режим A-law R3
м=аудио 59452 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a = fmtp: 96 набор режимов = 4
о Пример 3
Предложение: G. 711.1 A-закон с двумя режимами, R2b и R3, с предпочтительным R3
м=аудио 54874 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
a=fmtp:96 набор режимов=4,3
Ответ: принято
м=аудио 59452 RTP/AVP 96
a=rtpmap:96 PCMA-WB/16000
а=FMTP:96 режим-набор=4,3
Если бы ответчик хотел ограничиться одним режимом, он бы
отвечает только одним значением в наборе режимов, например, режим-
set=3 для режима R2b.
5.3.2. Декларативные аспекты SDP
Для декларативного использования SDP ничего конкретного для этого не определено.
формат полезной нагрузки. Конфигурация, заданная SDP, ДОЛЖНА использоваться, когда
отправка и/или получение мультимедиа в сеансе.
6. Функциональная совместимость G.711
Уровень L0 G.711.1 полностью совместим с G.711 и
встроен во все режимы G.711.1. Это обеспечивает простой G.711.1 -
Процесс транскодирования G.711.
Шлюз или любое другое сетевое устройство, получающее пакет G.711.1, может
легко извлечь полезную нагрузку, совместимую с G. 711, без необходимости декодирования
и перекодировать звуковой сигнал. Он просто должен взять аудиоданные
полезной нагрузки и снять верхние слои (L1 и/или L2), если таковые имеются.
Если пакет G.711.1 содержит несколько кадров, объединение
Уровни L0 каждого кадра будут формировать полезную нагрузку, совместимую с G.711.
Отслеживание стандартов Sollaud [Страница 11]
RFC 5391 Формат полезной нагрузки RTP для G.711.1, ноябрь 2008 г.
7. Контроль перегрузки
Управление перегрузкой для RTP ДОЛЖНО использоваться в соответствии с [RFC3550].
и любой подходящий профиль (например, [RFC3551]).
Встроенная природа аудиоданных G.711.1 может быть полезна для
управление перегрузкой, так как режим кодирования с более низкой скоростью передачи данных может быть
выбирается при необходимости. Это свойство можно использовать только при наличии нескольких
согласованы режимы (либо нет параметра "mode-set" в SDP
или «набор режимов» по крайней мере с двумя режимами).
Количество кадров, инкапсулированных в каждую полезную нагрузку RTP, влияет на
общая пропускная способность потока RTP из-за служебных данных заголовка.
Упаковка большего количества кадров в каждую полезную нагрузку RTP может уменьшить количество
отправленных пакетов и, следовательно, накладные расходы заголовка за счет
повышенная задержка и сниженная устойчивость к ошибкам.
8. Вопросы безопасности
Пакеты RTP, использующие формат полезной нагрузки, определенный в этой спецификации.
подчиняются общим соображениям безопасности, обсуждаемым в
Спецификация RTP [RFC3550] и любой соответствующий профиль (например,
[RFC3551]).
Поскольку этот формат передает закодированную речь/аудио, основная защита
проблемы включают конфиденциальность, защиту целостности и
аутентификация самой речи/аудио. Сам формат полезной нагрузки
не имеет встроенных механизмов безопасности. Любой подходящий
внешние механизмы, такие как безопасный транспортный протокол в реальном времени
(SRTP) [RFC3711], МОЖЕТ использоваться.
Этот формат полезной нагрузки и кодировка G.711.1 не содержат никаких
значительная неравномерность вычислительной нагрузки на стороне приемника,
и, таким образом, они вряд ли будут представлять угрозу отказа в обслуживании из-за
получение патологических дейтаграмм. Кроме того, они не
содержат любой тип активного контента, например скрипты.
9. Рекомендации IANA
Добавлены два новых подтипа мультимедиа (аудио/PCMA-WB и аудио/PCMU-WB).
зарегистрирована IANA. См. разделы 5.1 и 5.2.
Отслеживание стандартов Sollaud [Страница 12]
RFC 5391 Формат полезной нагрузки RTP для G.711.1, ноябрь 2008 г.
10. Ссылки
10.1. Нормативные ссылки
[ITU-G.711.1] Международный союз электросвязи, "Широкополосные
встроенное расширение для импульсно-кодовой модуляции G.711",
Рекомендация ITU-T G.711.1, март 2008 г.
[RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для указания
Уровни требований», BCP 14, RFC 2119, март 1997 г.
[RFC3264] Розенберг, Дж. и Х. Шульцринн, «Предложение/ответ
Модель с протоколом описания сеанса (SDP)», RFC
3264, июнь 2002 г.
[RFC3550] Шульцринн Х., Каснер С., Фредерик Р. и В.
Джейкобсон, «RTP: транспортный протокол для реального времени».
Приложения», STD 64, RFC 3550, июль 2003 г.
[RFC3551] Шульцринн, Х. и С. Каснер, «Профиль RTP для аудио».
и видеоконференции с минимальным контролем», STD 65,
RFC 3551, июль 2003 г.
[RFC4288] Фрид, Н. и Дж. Кленсин, "Спецификации типов носителей
и процедуры регистрации», BCP 13, RFC 4288,
декабрь 2005 г.
[RFC4566] Хэндли М., Джейкобсон В. и К. Перкинс, "SDP:
Протокол описания сеанса», RFC 4566, июль 2006 г.
[RFC4855] Casner, S., «Регистрация типа носителя для полезной нагрузки RTP.
Форматы», RFC 4855, февраль 2007 г.
10.2. Информативные ссылки
[ITU-G.711] Международный союз электросвязи, "Импульсный код
модуляция (ИКМ) голосовых частот», МСЭ-Т
Рекомендация G.711, 19 ноября88.
[RFC3389] Zopf, R., "Полезная нагрузка транспортного протокола реального времени (RTP)".
для комфортного шума (CN)», RFC 3389, сентябрь 2002 г.
[RFC3711] Богер, М., МакГрю, Д., Наслунд, М., Каррара, Э., и
К. Норрман, "Безопасный транспортный протокол в реальном времени".
(SRTP)", RFC 3711, март 2004 г.
Отслеживание стандартов Sollaud [Страница 13]
RFC 5391 Формат полезной нагрузки RTP для G.711.1, ноябрь 2008 г.
Адрес автора
Орельен Солло
Франция Телеком
2 авеню Пьер Марзен
Ланнион Седекс 22307
Франция
Телефон: +33 2 96 05 15 06
Электронная почта: [email protected]
Отслеживание стандартов Sollaud [Страница 14]

Открытое моделирование VICO

Qué hacemos

Desde 1990, nuestra misión es:

Integramos la diversidad para fortalecer la cohesion

Facilitamos una organización eficaz y eficiente 9 0023
Aceleramos la transición hacia la digitalización inteligente
Mejoramos los resultsados operativos y financieros
Generamos conocimiento de los datos compartidos

Услуги

Формасьон

Академия ВИКО

Cursos de Pre-Certificación

Сертификат специалиста HL7 FHIR® R4
- • Сервоприводы FHIR® и приложения Smart-On FHIR®
HL7 V2. 8 Специалист по управлению ISO27931
- • Intercambio electronico de datos con mensajería
HL7 CDA Специалист ISO27932
- • El documento clinico para una interoperabilidad global

Тальерес «Практика»

OpenESB ENTERPRISE & BPEL в облаке
- • Стать открытым предприятием
ЛУЧШИЕ ПРАКТИКИ HL7 FHIR® в сочетании с HL7 CDA
- • Новое поколение стандартов взаимодействия
INTEROPERABILIDAD PARA GESTORES
- • Соответствие нормам HL7 и IHE

Присоединиться к Академии VICO

Солучионес
Публичная администрация
Интеграция с SEPE в соответствии с Esquema Nacional de Interoperabilidad.
Envío de datos comunes de formación de las CCAA al SEPE (Servicio Estatal para la Promoción del Empleo). Интеграция de todos los sistemas implicados en la captura, procesamiento, transferencia, control y depuración de errores, durante эль-процессо-де-envío аль SEPE. Implementación de una consola que Monitoring todas las transacciones y eventos generados, a través де ип BUS де servicios дие coreografía у analiza эль contenido е interacción де todos лос procesos.
Портал выпускников и App de Oferta de Formación Pública.
Каталог образовательных услуг. Búsquedas де especialidades docentes пор ubicación у ámbito де empleo. Резерва де inscripciones, matriculación, recepción de comunicaciones, recordatorios y orientaciones sobre las acciones formativas избранные. Заботы де becas y ayudas, descarga де дипломы y administración del expediente учебный план личный пункт содействия ла Promoción Laboral.
Салуд цифровой
Custodia y uso compartido de documentos clinicos en el CLOUD.
Transformación de los informes generados por la HCE (Historia Clínica Electrónica) по стандарту HL7 CDA ISO-27932. Publicación de los documentos en un DACS (Система архивирования и передачи документов), интегрированная с данными Laboratorio e Imágenes diagnósticas (PACS), ubicado en un CLOUD seguro, y auditado desde la HCE. Извлечение из conocimiento clinico пункт apoyar лас-decisiones médicas y де enfermería десде эль мисмо пунто де asistencia.
Портал Пасиенте.
Espacio de salud on-line para que los pacientes tengan a su alcance sus informes médicos en cualquier momento y desde cualquier dispositivo. Programación де Citas пункт Concertar Y пункт Modificar Visitas у Exploraciones diagnósticas. Servicios de portabilidad digital para facilitar los informes de exploraciones diagnósticas y empoderar al paciente con уна полная интеграция с HCE и ип estricto cumplimiento дель Reglamento General de Protección de Datos.
App de información clinica y soporte administrativo-asistencia
Todos los servicios facilitados desde el Portal del Paciente, al alcance desde cualquier dispositivo móvil, e интеградос с HCE. Comunicaciones, recordatorios y orientaciones sobre los procedimientos asistenciales. Facturación automática a entidades pagadoras de las asistencias Concertadas. Confirmación de la llegada de los pacientes a las dependencias de la organización de salud.
Удаленный мониторинг пациентов.
Integración de dispositivos remotos de electromedicina con la HCE para la captura y procesamiento de las Constantes жизненные силы. Desde los cuidados asistenciales en atención domiciliaria, hasta la supervisión médica en residencias гериатрии. A través de una interoperabilidad segura, orientada a monitorizar la salud y a facilitar el mejor tratamiento де лос pacientes, грех desplazarlos де су ámbito знакомый.
Отраслевые приложения
Plataforma de trazabilidad de transacciones.
Защищенный и неприкосновенный реестр данных о транзакциях, не связанных с чувственными данными, с использованием Blockchain и IHE ATNA (Audit Trail and Node Authentication), cumpliendo con el Reglamento General de Protección de Datos del Parlamento Европа. Консоль мониторинга процессов и операций с экспортом временных рядов данных поколение графиков.
OpenESB Enterprise for Educación, Empleo y Salud.
Дизайн, реализация и администрирование веб-сервисов, посредничество в стандартизации процессов estándar «Язык выполнения бизнес-процессов» (BPEL), a través de plataformas empresariales de sistemas abiertos, пункт abordar soluciones секториалес.