SDP и payload type: число 101 не является универсальным названием кодека
Фотография конкретного исполнения не приложена.
Динамический номер RTP payload type получает смысл из согласования конкретного сеанса. Если анализатор или шлюз жёстко связывает одно число с определённым форматом, исправный поток может быть разобран неправильно. Нужна действующая пара offer и answer.
RFC 3264 описывает согласование media formats и их параметров. RTP payload type указывает, как интерпретировать полезную нагрузку в соответствующем контексте. Для динамических назначений учитывают rtpmap и связанные параметры. Одинаковое число в другом вызове не обязано обозначать тот же формат.
Offer с несколькими форматами не доказывает, что все они были приняты ответом. Также важны clock rate, каналы и format-specific ограничения. Одно совпадение имени кодека не подтверждает полную совместимость профиля. При изменении SDP внутри диалога нужно установить, с какого момента действует новое согласование.
В приёмке сравнивают фактические RTP-пакеты с согласованным SDP в обоих направлениях. Проверяют изменение динамических номеров и предусмотренную смену формата. Содержимое анализируют по актуальной карте, а не по постоянной таблице из чужого примера. Получение пакетов ещё не доказывает, что декодер использует правильную интерпретацию.
Основание — Numbered IETF voice and NAT-traversal RFCs with selected RFC8863 ICE update; protocol scopes identified per task, разделы RFC3264 Offer/Answer media formats; RTP payload type mapping; RFC3550 Payload type field. Сохранён текст публичной справочной публикации; конкретная реализация может поддерживать только часть возможностей. Основание — указанные номерные RFC о SIP, SDP, RTP и NAT traversal; рассматриваются конкретные границы поведения, а не полный современный профиль реализации или защиты. Реальные шлюзы, АТС, терминалы и медиапотоки не проверялись; вызовы и записи звука не выполнялись.