Модель предложения / ответа SDP с несовпадением DTMF rtpmap/fmtp

Question

Представьте себе предложение SDP, которое имеет одну строку "m", содержащую кодеки 8 и 101 для DMTF, помеченные как sendrecv:

m = audio 35904 RTP/AVP 8 101
a = rtpmap:8 PCMA/8000
a = rtpmap:101 telephone-event/8000
a = fmtp:101 0-15
a = sendrecv

Получает ответ SDP с одной строкой "m", содержащей кодеки 8, но 120 для DTMF и аналогично помеченной как sendrecv:

m = audio 1235 RTP/AVP 8 120
a = rtpmap:8 PCMA/8000
a = rtpmap:120 telephone-event/8000
a = fmtp:101 0-15
a = sendrecv 

Из RFC 3264:

Для потоков, помеченных в ответе как sendrecv, строка "m=" ДОЛЖНА содержать хотя бы один кодек, который ответчик готов отправлять и получать из числа перечисленных в предложении. Поток МОЖЕТ указывать дополнительные форматы мультимедиа, не указанные в соответствующем потоке в предложении, которые ответчик желает отправить или получить (конечно, он не сможет отправлять их в это время, поскольку он не был указан в предлагает).

Выше части RFC3264, доказывает, что отправка другой DTMF-fmtp(от 120 до 101) в ответе SDP соответствует RFC3264, поскольку кодек 8(G711a) совпадает с предложением SDP.

Будет ли сигнализация DTMF в порядке или возможно возникновение проблем DTMF?

Любые отзывы приветствуются.

Answer 1

В общем:

Номера типов полезной нагрузки RTP 0-95 обозначают статическую кодировку мультимедиа. Например, тип полезной нагрузки 8 означает звук PCMA с тактовой частотой 8000 Гц ( RFC3551). Таким образом, это описание не должно (но должно) включаться в описание формата мультимедиа предложения / ответа SDP с использованием атрибутов "a=rtpmap:" и "a=fmtp:" ( RFC4566).

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

Обе стороны, участвующие в переговорах, могут выбрать свой собственный номер типа динамической полезной нагрузки для представления одной и той же кодировки мультимедиа, это не обязательно должен быть один и тот же номер. Это может быть полезно, когда сторона уже присвоила конкретный номер типа динамической полезной нагрузки другой кодировке. В вашем примере одна сторона использует 101 в m-строке, а другая - 120, но эти числа представляют одну и ту же кодировку мультимедиа (см. Строки "a=rtpmap:"). Каждая сторона сообщает другой: "когда вы отправляете RTP с использованием кодировки X, вы должны включить номер типа полезной нагрузки Y в заголовки пакетов RTP.

Номер типа полезной нагрузки включен в поле PT заголовков пакетов RTP ( RFC 3550)

В этом случае:

Атрибут "a=fmtp:" в ответе указывает номер типа полезной нагрузки 101 вместо 120. Это означает, что он не применяется к полезной нагрузке телефонных событий, и нет никакой информации о том, какие события DTMF поддерживаются ( RFC 4733), Я думаю, что это ошибка реализации, и атрибут fmtp предназначен для применения к полезной нагрузке телефонных событий.

Это признак того, что следует ожидать проблем с DTMF. Но это также может работать нормально. Попробуйте...