Аннотация
В этом документе описывается, как прозрачно переносить данные канала со скоростью 64 кбит/с в пакетах RTP, используя псевдокодек под названием «Clearmode». Он также служит в качестве регистрации для соответствующего типа MIME, называемого «audio / clearmode».
«Clearmode» является основной функцией VoIP Media Gateways.
Скачать оригинальный документ на английском языке RFC 4040 PDF
Оглавление
1. Введение
2. Условные обозначения, используемые в этом документе
3. Обработка потока данных 64 кбит/с и параметры заголовка RTP
4. Соображения IANA
5. Отображение на параметры протокола описания сеанса (SDP)
6. Вопросы безопасности
7. Ссылки
7.1. Нормативные ссылки
7.2. Информационные ссылки
8. Благодарности
Статус этой заметки
Этот документ определяет протокол отслеживания стандартов Интернета для интернет-сообщества и запрашивает обсуждение и предложения по улучшению. Пожалуйста, обратитесь к текущей редакции «Официальных стандартов протокола Интернета» (STD 1), чтобы узнать о состоянии стандартизации и статусе этого протокола. Распространение этой заметки не ограничено.
Уведомление об авторских правах
Copyright (C) Интернет-общество (2005).
1. Введение
Медиа-шлюзы с передачей голоса по IP (VoIP) должны передавать через IP-сеть все возможные потоки данных, генерируемые аналоговыми терминалами или терминалами цифровой сети с интеграцией служб (ISDN).
В этом документе VoIP Media Gateway — это устройство, которое преобразует (цифровой или аналоговый) линейный поток данных в цифровой пакетированный поток данных или наоборот. Обратитесь к RFC 2719 [10] за введение в базовую архитектуру сети на основе медиашлюза.
Обычно VoIP Media Gateway выполняет некоторую обработку данных, которые он преобразует, помимо пакетирования или депакетирования; т.е. эхоподавление или двухтональное многочастотное обнаружение (DTMF), и особенно кодирование / декодирование. Но существует класс потоков данных, который не полагается и не допускает какую-либо обработку данных в шлюзе VoIP, за исключением пакетирования или депакетирования. Терминалы данных ISDN, то есть будут генерировать потоки данных, которые не совместимы с нелинейным кодированием, используемым для голоса.
Для таких приложений существует необходимость в прозрачной ретрансляции потоков данных со скоростью 64 кбит / с в пакетах транспортного протокола в реальном времени (RTP) [4]. Этот режим часто упоминается как «данные чистого канала» или «неограниченная скорость 64 кбит / с». В этом случае не требуется кодер / декодер, но необходим уникальный тип полезной нагрузки RTP, и связанный тип MIME должен быть зарегистрирован для целей сигнализации.
Clearmode не ограничивается примерами, описанными выше. Он может использоваться любым приложением, которое не требует специального кодирования / декодирования для передачи через RTP-соединение.
Этот документ формата полезной нагрузки описывает псевдокодек под названием «Clearmode» для ориентированных на выборку потоков данных со скоростью 64 кбит / с с 8 битами на выборку. Это соответствует RFC 2736 [1], который предоставляет руководство для спецификации новых форматов полезной нагрузки RTP.
Примерами текущего использования Clearmode являются передача «голоса ISDN 7 кГц» и «данные ISDN» в шлюзах VoIP.
Этот документ также служит регистрацией типов MIME в соответствии с RFC 2045 [2] и RFC 2048 [3], в которых определены процедуры регистрации новых типов MIME в дереве IETF.
2. Условные обозначения, используемые в этом документе
Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119].
3. Обработка потока данных 64 кбит/с и параметры заголовка RTP
Clearmode не использует кодирование или декодирование. Это просто обеспечивает пакетирование.
Clearmode предполагает, что обрабатываемые данные ориентированы на выборку с одним октетом (8 бит) на выборку. Нет ограничений на количество выборок на пакет, кроме ограничения в 64 Кбайт, наложенного протоколом IP. Число выборок ДОЛЖНО быть меньше, чем максимальная единица передачи тракта (MTU) минус длина объединенного заголовка пакета. Если ожидается, что среда будет иметь туннели или инкапсуляцию безопасности как часть операции, число выборок ДОЛЖНО быть уменьшено, чтобы обеспечить дополнительное пространство заголовка.
Пакетирование / депакетирование полезной нагрузки для Clearmode аналогично обработке импульсно-кодовой модуляции (PCMU или PCMA), описанной в RFC 3551 [5]. Каждый октет Clearmode ДОЛЖЕН быть выровнен по октету в RTP-пакете. Знаковый бит каждого октета ДОЛЖЕН соответствовать наиболее значимому биту октета в пакете RTP.
НЕОБХОДИМО использовать частоту дискретизации 8000 Гц.
Это рассчитывает до скорости передачи 64 кбит / с на канал.
Временная метка ДОЛЖНА быть установлена, как описано в RFC 3550 [4].
Бит маркера всегда равен нулю. Подавление тишины не применимо для потоков данных Clearmode.
Тип полезной нагрузки назначается динамически и не представлен в этом документе.
Поля заголовка RTP, не упомянутые здесь, ДОЛЖНЫ использоваться, как указано в RFC 3550 [4] и любом применимом профиле.
Этот документ определяет использование RTP по одноадресной и многоадресной UDP, а также по TCP. (Это не исключает использования этого определения, когда RTP переносится другими протоколами нижнего уровня.)
4. Соображения IANA
Этот документ регистрирует следующий подтип MIME: audio / clearmode.
To: ietf-types@iana.org
Тема: Регистрация MIME медиа типа аудио / clearmode
MIME имя типа носителя: аудио
Имя подтипа MIME: clearmode
Обязательные параметры: нет
Необязательные параметры: ptime, maxptime
- «ptime» задает отрезок времени в миллисекундах, представленный средой в пакете, как описано в RFC 2327 [6].
- «maxptime» представляет максимальное количество мультимедиа, которое может быть инкапсулировано в каждый пакет, выраженное как время в миллисекундах, как описано в RFC 3267 [9].
Вопросы кодирования: Этот тип определен только для передачи через RTP [4].
Соображения безопасности: см. Раздел 6 RFC 4040
Вопросы совместимости: нет
Опубликованная спецификация: RFC 4040
- Приложения, которые используют этот тип мультимедиа: шлюзы передачи голоса по IP, передача «данных ISDN 64 кбит / с», «голос ISDN 7 кГц» или другие потоки данных 64 кбит / с через соединение RTP.
- Примечание: выбор «аудио» MIME-типа верхнего уровня был сделан, поскольку ожидается, что доминирующее использование этого псевдокодека будет связано с телефонией и голосовым шлюзом. Тип «audio» позволяет использовать совместное использование порта в строке SDP «m =» с такими кодеками, как audio / g711 [6], [7], например. Это совместное использование является важным приложением и в противном случае было бы невозможно.
Дополнительная информация: нет
Использование по назначению: COMMON
Автор / контроллер изменений: IETF Рабочая группа по передаче аудио / видео, делегированная от IESG
5. Отображение на параметры протокола описания сеанса (SDP)
Параметры отображаются в SDP [6] стандартным способом.
- MIME-тип (аудио) указывается в SDP «m =» в качестве имени носителя.
- Подтип MIME (clearmode) идет в SDP «a = rtpmap» в качестве имени кодировки.
- Необязательные параметры «ptime» и «maxptime» входят в атрибуты SDP «a = ptime» и «a = maxptime» соответственно.
Пример сопоставления выглядит следующим образом:
audio/clearmode; ptime=10
m=audio 12345 RTP/AVP 97
a=rtpmap:97 CLEARMODE/8000
a=ptime:10
Обратите внимание, что имена формата (кодировки) полезной нагрузки, определенные в профиле RTP, обычно отображаются в верхнем регистре. Подтипы MIME обычно отображаются в нижнем регистре. Эти имена не чувствительны к регистру в обоих местах.
6. Вопросы безопасности
Реализации, использующие формат полезной нагрузки, определенный в этой спецификации, подчиняются соображениям безопасности, обсуждаемым в RFC 3550 [4]. Формат полезной нагрузки, описанный в этом документе, не определяет какие-либо другие службы безопасности. Основная функция этого формата полезной нагрузки заключается в добавлении прозрачного транспорта для потока данных со скоростью 64 кбит/с.
Конфиденциальность медиапотоков достигается с помощью шифрования, например, путем применения профиля Secure RTP [11].
Как и в случае любого протокола на основе IP, в некоторых случаях приемник может быть перегружен просто при получении слишком большого количества пакетов, либо желательных, либо нежелательных. Аутентификация сетевого уровня МОЖЕТ использоваться для отбрасывания пакетов из нежелательных источников, но стоимость обработки самой аутентификации может быть слишком высокой. Перегрузка также может возникнуть, если отправитель решит использовать меньший период пакетирования, чем может обработать получатель. Параметр ptime может использоваться для согласования соответствующей пакетизации во время настройки сеанса.
В целом RTP не является подходящим протоколом передачи для надежных потоков октетов. TCP лучше в этих случаях. Кроме того, потеря пакетов из-за перегрузки является такой же проблемой для режима очистки, как и для других форматов полезной нагрузки. Обратитесь к RFC 3551 [5], раздел 2, для обсуждения этой проблемы.
7. Ссылки
7.1. Нормативные ссылки
[1] Handley, M. and C. Perkins, «Guidelines for Writers of RTP Payload Format Specifications», BCP 36, RFC 2736, December 1999.
[2] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies», RFC 2045, November 1996.
[3] Freed, N., Klensin, J., and J. Postel, «Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures», BCP 13, RFC 2048, November 1996.
[4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, «RTP: A Transport Protocol for Real-Time Applications», STD 64, RFC 3550, July 2003.
[5] Schulzrinne, H. and S. Casner, «RTP Profile for Audio and Video Conferences with Minimal Control», STD 65, RFC 3551, July 2003.
[6] Handley, M. and V. Jacobson, «SDP: Session Description Protocol», RFC 2327, April 1998.
[7] Rosenberg, J. and H. Schulzrinne, «An Offer/Answer Model with Session Description Protocol (SDP)», RFC 3264, June 2002.
[8] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.
[9] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, «Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs», RFC 3267, June 2002.
7.2. Информационные ссылки
[10] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, «Framework Architecture for Signaling Transport», RFC 2719, October 1999.
[11] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, «The Secure Real-time Transport Protocol (SRTP)», RFC 3711, March 2004.
8. Благодарности
Редактор хотел бы поблагодарить Рабочую группу IETF AVT и, в частности, помощь Колина Перкинса и Магнуса Вестерлунда за их интенсивные рецензии и комментарии.
Адрес автора
Ruediger Kreuter
Siemens AG
81730 Munich, Germany
EMail: ruediger.kreuter@siemens.com
Kreuter
