"RFC 2833 RTP Event" Последовательные события и бит E "End"

Question

Почему я получаю звук dtmf, когда бит E равен 0, а звука нет, когда он равен 1? (RTP-пакеты появляются в wireshark в любом случае)

Справочная информация:

Я могу отправить событие RFC 2833 dtmf, как указано в http://www.ietf.org/rfc/rfc2833.txt получение следующего поведения, когда бит E НЕ установлен:

Если, например, нажаты клавиши 7874556332111111145855885#3, то ВСЕ события отправляются и отображаются в такой программе, как wireshark, однако звучит только 87456321458585#3. Таким образом, первый ключ (который, я полагаю, может быть отдельной проблемой) и любые повторения события (т.е. 11111) не звучат.

В разделе 3.9, рис. 2 вышеупомянутого связанного документа, они дают пример 911, где для всех, кроме последнего события, установлен бит E.

Когда я устанавливаю бит «E» на 1 для всех чисел, я никогда не получаю звук для события.

Я подумал о некоторых возможных причинах, но не знаю, являются ли они причиной:

1) на рисунке 2 показаны типы полезных данных 96 и 97 отправлено. Я не отправил эти заголовки. В разделе 3.8 коды 96 и 97 описаны как «динамические типы полезной нагрузки 96 и 97 были назначены для механизма резервирования и полезной нагрузки телефонных событий соответственно»

2) В разделе 3.5, «E:», «Отправитель МОЖЕТ задерживать установку конечного бита до повторной передачи последнего пакета для тонального сигнала, а не для его первой передачи». Есть ли у кого-нибудь представление о том, как на самом деле это сделать?

3) У меня есть отдельный выходной поток, который также звучит так интересно, не мешает ли он слышать этот поток.

4) также возился с временными метками и маркером RTP.

Любая помощь очень ценится. Вот пример захвата события wireshark соответствующих областей:

6590 31.159045000 xx.x.x.xxx --.--.---.-- RTP EVENT Payload type=RTP Event, DTMF Pound # (end)
Real-Time Transport Protocol
 Stream setup by SDP (frame 6225)
  Setup frame: 6225
  Setup Method: SDP
 10.. .... = Version: RFC 1889 Version (2)
 ..0. .... = Padding: False
 ...0 .... = Extension: False
 .... 0000 = Contributing source identifiers count: 0
 0... .... = Marker: False
 Payload type: telephone-event (101)
 Sequence number: 0
 Extended sequence number: 65536
 Timestamp: 2000
 Synchronization Source identifier: 0x15f27104 (368210180)
RFC 2833 RTP Event
 Event ID: DTMF Pound # (11)
 1... .... = End of Event: True
 .0.. .... = Reserved: False
 ..00 0000 = Volume: 0
 Event Duration: 1000

Обратите внимание: нулевой объем - это самый громкий доступный уровень, как описано в спецификации ietf.org/rfc/rfc2833.txt:

"том: для цифр DTMF и других событий, представляемых в виде тонов, это поле описывает уровень мощности тона, выраженный в дБм0 после удаления знака. Уровни мощности варьируются от 0 до -63 дБм0. Диапазон действительного DTMF составляет от 0 до -36 дБм0 (обязательно принимаем); должно быть отклонено ниже -55 дБм0 (TR-TSY-000181, МСЭ-Т Q.24A). Таким образом, большие значения обозначают меньший объем. это значение определяется только для цифр DTMF. Для других событий это отправитель устанавливает на ноль и игнорируется получателем. " Проблема заключается в том, что бит «Конец события» включен.

Answer 1

Я рекомендую начать с RFC 4733 по двум причинам:

1. Обсуждает RFC 2833 .
2. Глава 5. является отличным источником для понимания того, как создается цифра DTMF.

Вот мое понимание того, как должна быть отправлена ​​цифра DTMF:

• Отправляется стартовый пакет. У него установлен флаг M и флаг E сброшен. Отметка времени для события установлена.
• Излучается один или несколько пакетов продолжения (до тех пор, пока пользователь нажимает цифру). У них очищены флаги M и E. Они используют временную метку, определенную в начальном пакете, но их порядковые номера и их продолжительность увеличиваются (см. RFC для интервалов).
• Отправляется конечный пакет (когда пользователь перестает нажимать цифру). У него очищен флаг M и установлен флаг E.

Зачем отправлять несколько пакетов за одно событие? Потому что сеть не всегда идеальна и могут произойти некоторые потери:

• RFC заявляет (2.5.1.2. «Передача пакетов событий»), что:

  Для надежности отправителю СЛЕДУЕТ ретранслировать "государственные" события периодически.

• А (2.5.1.4. «Повторная передача окончательного пакета»), что:

  Окончательный пакет для каждого события и для каждого сегмента ДОЛЖНО быть отправлено
  Всего три раза на интервале используется источником для обновлений.
  Это гарантирует, что продолжительность событие или сегмент может быть распознан правильно, даже если экземпляр последний пакет потерян.

Что касается вашей проблемы:

Если, например, ключи 7874556332111111145855885 # 3 являются нажмите, тогда ВСЕ события отправляются и показать в программе, как Wireshark, однако только 87456321458585 # 3 звучат. Таким образом, первый ключ (который я думаю, мог отдельная тема) и любые повторы события (т.е. 11111) не в состоянии звук.

Без трассировки WireShark трудно сказать, что происходит, но я подозреваю, что повторяющиеся цифры 1 игнорируются, поскольку нет различия между последовательными событиями; первая цифра 1 распознается, а остальные считаются ретрансляциями события.

Answer 2

красота! Большое спасибо, Лоран. Я реализовал рабочее решение на основе ваших рекомендаций. (просто отправив в качестве другого ответа, чтобы получить лучшее форматирование текста - я дам вам награду)

Подводя итог, что было не так:

1. Мне нужна была избыточность пакетов.
2. Установка всех E в 0 означала, что повторяющиеся однотипные события игнорировались.
3. Установка всех E на 1 означала, что я сигнализировал об окончании события, но не фактическом событии - отсюда и молчание.

Вот краткий пример потока:

Event_ID    M    E    Timestamp      Duration    Sequence_number  
3           1    0    400            400          1
3           0    0    400            800          2
3           0    0    400            1200         3
3           0    0    400            1600         4
3           0    1    400            1600         5
3           0    1    400            1600         6
3           0    1    400            1600         7
7           1    0    800            400          8
7           0    0    800            800          9
7           0    0    800            1200         10
7           0    0    800            1600         11
7           0    1    800            1600         12
7           0    1    800            1600         13
7           0    1    800            1600         14

* примечание: только что посмотрел предложенный первый пример rfc4733 в разделе 5, и это здорово! намного лучше, чем 2833

Answer 3

Я заметил, что ваш Громкость установлена ​​на 0; это похоже на вероятную причину не слышать ни звука?