dlink dph-150s странное с RTP

[-sanches-]

Изредка есть проблема со слышимостью удаленной стороны. Поймал такой дамп

Код: Выделить всё

8326 2169.269077 192.168.1.66 → 8.8.8.8  SIP/SDP 851 Request: INVITE sip:88002500265@sip.site.ru;user=phone |
 8327 2169.355319  8.8.8.8 → 192.168.1.66 SIP 607 Status: 401 Unauthorized |
 8328 2169.358493 192.168.1.66 → 8.8.8.8  SIP 443 Request: ACK sip:88002500265@sip.site.ru;user=phone |
 8329 2169.361301 192.168.1.66 → 8.8.8.8  SIP/SDP 1033 Request: INVITE sip:88002500265@sip.site.ru;user=phone |
 8330 2169.447689  8.8.8.8 → 192.168.1.66 SIP 556 Status: 100 Trying |
 8331 2169.729551  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8332 2169.732297  8.8.8.8 → 192.168.1.66 SIP/SDP 848 Status: 183 Session Progress |
 8333 2169.749332  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8334 2169.769820 192.168.1.66 → 8.8.8.8  UDP 66 10015 → 10864 Len=24
 8335 2169.769927 192.168.1.66 → 8.8.8.8  UDP 66 10015 → 10864 Len=24
 8336 2169.770024 192.168.1.66 → 8.8.8.8  UDP 66 10015 → 10864 Len=24
 8337 2169.770120 192.168.1.66 → 8.8.8.8  UDP 66 10015 → 10864 Len=24
 8338 2169.770216 192.168.1.66 → 8.8.8.8  UDP 66 10015 → 10864 Len=24
 8339 2169.770898  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8340 2169.789982  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8341 2169.809825  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8342 2169.830689  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8343 2169.850940  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8344 2169.870941  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8345 2169.891118  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8346 2169.910911  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8347 2169.930558  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8348 2169.950174  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8349 2169.970138  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8350 2169.990392  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8351 2170.009939  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8352 2170.029781  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8353 2170.049736  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8354 2170.070390  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8355 2170.090639  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8356 2170.111146  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8357 2170.133630  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8358 2170.154514  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8359 2170.176076 192.168.1.66 → 8.8.8.8  RTCP 62 Receiver Report   Source description
 8360 2170.177335  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8361 2170.185986 192.168.1.66 → 8.8.8.8  UDP 214 10015 → 10864 Len=172
 8362 2170.194684  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8363 2170.205918 192.168.1.66 → 8.8.8.8  UDP 214 10015 → 10864 Len=172
 8364 2170.214982  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172

Внутри

Код: Выделить всё

8362 2170.194684  8.8.8.8 → 192.168.1.66 UDP 214 10864 → 10015 Len=172
 8363 2170.205918 192.168.1.66 → 8.8.8.8  UDP 214 10015 → 10864 Len=172

В пакетах примерно

Код: Выделить всё

Data: 80087252db707ad8690fc5fd555555555555555555555555...

в обе стороны.

RTCP


Кто-нибудь встречал подобное поведение где-либо?

[ded]

Подобное поведение чего-кого? Когда изредка есть проблема со слышимостью удаленной стороны? Тут наверное все встречали такое поведение.
Если можно рассматривайте дампы вот так:
http://asterisk.ru/knowledgebase/debug

То что Вы выше опубликовали мало информативно.

[-sanches-]

Отсутствует RTP. UDP гоняет одни и те же данные между телефоном и * по выделенным портам для RTP, которые никак не интерпретируются анализатором.

[awsswa]

Почитать про вот это
Status: 183 Session Progress |

[amateur]

которые никак не интерпретируются анализатором.

Ваша же картинка говорит о том, что Wireshark распознает в этих пакетах RTCP, содержащий только структуру SDES (Source DEScription). Ни RR (Receiver Report) ни SR (Sender Report) внутри RTCP нет, т.к. ни передача media ни обработка получаемого media Asterisk, судя по всему, еще не начались.

Мне думается, что Вы не там ищете. В обмене сообщениями на этой стороне не видно нарушений. Смотрите противоположную сторону (если она есть) и/или журнал Asterisk.

[amateur]

Почитать про вот это
Status: 183 Session Progress |

Очень туманно.
Ну вот я прочитал из RFC 3261:

21.1.5 183 Session Progress

The 183 (Session Progress) response is used to convey information
about the progress of the call that is not otherwise classified. The
Reason-Phrase, header fields, or message body MAY be used to convey
more details about the call progress.

Что из этого можно "пришить" к проблеме передачи media?

[ded]

Исследуя SIP диалог INVITE в Wireshark Вы увидите полную картину, а не часть её. Почти то же можно увидеть в CLI Астериска, включив sip debug для проблемного пира. Правильный диалог подробно рассказывает об ИП адресах и назначаемых RTP портах у пира и у Астериска. И информирует, если есть проблема. tcpdump не информирует.

Про некорректность session progress 183 как возможную причину:
https://www.voip-info.org/wiki/view/Ast ... ressinband