В коммуникационных приложениях для общения посредством компьютерных сетей, аудио и видеоконференций в режиме реального времени, использующих транспортный протокол реального времени (RTP), применяются различные варианты описания технических параметры потоков медиа-данных, переносимых в мультимедиа сессии (например протокол описания сеанса (SDP) или H.245). Такой набор параметров RTP потока мультимедиа-данных и методы его кодирования известен как профиль RTP, или 'RTP audio video profile' ( 'RTP / AVP' ). Каждый профиль определен с помощью стандартного идентификатора типа полезной нагрузки (payload type) для каждого типа медиа-данных с использованием соответствующего кодека.^[1]

Сообщения SDP с параметрами медиа-сессии используются в протоколах IP-телефонии — например в таких как SIP, MGCP. Протокол SIP или MGCP служит для процедур инициации и установления соединения, а встраиваемые сообщения SDP — для описания возможных параметров формируемой медиа-сессии между устройствами.

Рассмотрим, как тип мультимедиа-данных определяется в SDP на конкретном примере.

v=0
o=- 1815849 0 IN IP4 194.67.15.181
s=Cisco SDP 0
c=IN IP4 194.67.15.181
t=0 0
m=audio 20062 RTP/AVP 99 18 101 100
a=rtpmap:99 G.729b/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202

В приведенном выше сообщении SDP содержится следующая информация. Медиа-трафик будет ожидаться на устройстве с IP-адресом (IPv4) 194.67.15.181, порту 20062. Данное устройство поддерживает несколько разновидностей аудио-трафика (кодеков), описанных при помощи типов (payload type) 99, 18, 100 и 101. Это указано в строке m=audio. Ниже, в строчках a=rtpmap приводится уточнение параметров типов данных, так как некоторые типы являются динамическими и не могут быть определены однозначно, просто по строке m=audio. Так, под типом данных 99 данное устройство подразумевает голосовой кодек G.729b (G.729 Annex B, то есть с поддержкой подавления шума). Динамически тип данных 101 в данном случае, это возможность приёма тональных сигналов DTMF (telephone event) по стандарту, описанному в RFC 2833. Для payload type 18 уточнений нет, и это может означать, что устройство поддерживает голосовой кодек G.729, вместе с более простой вариацией того же кодека описанного в приложении Annex A (или кодек G.729a), так как тип данных 18 однозначно закреплён за этими кодеками.

В RFC 3551 перечислены детали каждого формата полезной нагрузки (payload type) или ссылка на подробное описание. Идентификаторы с 0 по 95, зарезервированы для конкретных типов данных статически. Идентификаторы полезной нагрузки с 96 по 127 используется для полезной нагрузки, определяемой динамически в процессе установления сессии. Документ рекомендует динамические назначенные номера портов, хотя номера портов 5004 и 5005 были зарегистрированы для использования профиля при динамическом назначении порт не требуется. Стандарт также описывает процесс регистрации новых типов полезной нагрузки в IANA.

Приложения, работающие с этими профилями должны всегда поддерживать PCMU (кодек G.711 с μ-законом, тип полезной нагрузки 0). Ранее DVI4 (тип полезной нагрузки 5) также рекомендовался в таком качестве, но эта рекомендация была удалена в августе 2013 году RFC 7007, потому что «многие реализации RTP не поддерживают DVI4, и есть мало оснований, чтобы использовать его, когда доступны гораздо более современные кодеки.»

• RTP/RTCP
• Media Gateway Control Protocol
• Session Initiation Protocol
• Session Description Protocol
• H.323
• Сравнение цифровых аудиоформатов

• IANA assignments of Real-Time Transport Protocol (RTP) Parameters