PassThru mode autoswitch при запрещенном VBD

[alx]

Когда в конфигурации канального окончания установлена отметка чекбокса "Запрет VBD", функция VBD не должна работать. Однако в ходе работы над другим тикетом (#456) было замечено, что даже когда канальному окончанию установлен запрет VBD, в логе присутствуют строки, свидетельствующие о работе VBD - канал переключается в режим PassThru и обратно, например:

Apr 27 10:29:00 sip_ua[454]: sl.cpp:205: ---> ts=2, state=Connected: Tone detected, ts=2, flags=0000, data=18
Apr 27 10:29:00 sip_ua[454]: sl.cpp:205: ---> ts=2, state=Connected: PassThru mode autoswitch, ts=2, flags=0000, data=1
Apr 27 10:29:00 sip_ua[454]: comcerto.cpp:6132: ts 2: PassThru mode autoswitch to 1

См. лог 1​, лог 2​

[alx]

Добавлю, что у меня самого баг не воспроизводится.

[alx]

@roman_zhur, приложи, пожалуйста, конфигурацию платы VE-02 (в левом верхнем углу диалога конфигурации платы кликни на "гамбургер", и в появившемся меню кликни "Экспорт настроек").

[alx]

При более внимательном изучении второго лога​ я заметил там вот такое (строки 74-77):

Apr 27 13:41:58 sip_ua[454]: sl.cpp:205: ---> ts=2, state=Connected: RTP parameters, ts=2, flags=0000, data=10
Apr 27 13:41:58 sip_ua[454]: comcerto.cpp:7297: --> ts 2: 192.168.20.70[10004] --> 192.168.20.70[10002]
Apr 27 13:41:58 sip_ua[454]: comcerto.cpp:7298: --> ts 2: codec PCMA, VAD is on, red=0
Apr 27 13:41:58 sip_ua[454]: comcerto.cpp:7299: --> audio pt: 8/8, event pt: 101/101, VBD pt: 98/98

Здесь присутствует "VBD pt: 98/98", что говорит о том, что обе стороны договорились (в сообщениях SIP/SDP) использовать VBD (со сменой payload type на 98). Это вдвойне странно, так как канальное окончание FXS, с которым и договаривалось окончание SL, имеет в своих параметрах RTP "VBD pt: -1/-1", что говорит о прямо обратном - что стороны не договорились об использовании VBD (строки 65-68):

Apr 27 13:41:58 sip_ua[454]: fxs.cpp:434: ---> ts=1, state=Calling: RTP parameters, ts=1, flags=0000, data=9
Apr 27 13:41:58 sip_ua[454]: comcerto.cpp:7297: --> ts 1: 192.168.20.70[10002] --> 192.168.20.70[10004]
Apr 27 13:41:58 sip_ua[454]: comcerto.cpp:7298: --> ts 1: codec PCMA, VAD is on, red=0
Apr 27 13:41:58 sip_ua[454]: comcerto.cpp:7299: --> audio pt: 8/8, event pt: 101/101, VBD pt: -1/-1

Здесь все еще более странно, чем казалось сначала...
В первом логе картина аналогичная...

[alx]

Зметил, что сообщение "RTP parameters" в логе встречается 5 раз. Ожидал что будет 4 раза: сначала при получении предварительного ответа "183 Session Progress" окончания FXS и SL получают событие eRTPparams, а потом при получении окончательного ответа "200 OK" они снова получают событие eRTPparams. Но, судя по логам, после этого окончание SL получает параметры RTP третий раз, причем эти параметры отличаются от предыдущих (VBD pt приема и передачи равны 98). Это объясняет, почему VBD оказывается включенным. Осталось понять, откуда берется это дополнительное событие, и почему в нем такие параметры...

[alx]

Мне удалось частично воспроизвести зафиксированное в логах поведение - у меня тоже исходящее (IP --> TDM) окончание SL после ответа вызываемого абонента получает событие "RTP parameters" дважды (и еще один раз раньше, после передачи номера в канал). Только в моем случае все три раза там VBD pt: -1/-1...

[alx]

Ситуация прояснилась. Баг был внесен в r2133 (см. #409) заменой вот этой строки:

-sdp_message_t *rem_sdp = eXosip_get_sdp_info(je->type == EXOSIP_CALL_ACK ? je->ack : je->response);
+sdp_message_t *rem_sdp = eXosip_get_remote_sdp(context, je->did);

Фрагмент кода, в котором находится эта строка, отвечает за валидацию принятого ответа SDP, указатель на который и присваивался rem_sdp. Ответ SDP может быть принят либо в сообщении "200 OK", либо в сообщении ACK. Упомянутый фрагмент кода выполняется при получении обоих упомянутых сообщений.

Изначально rem_sdp получал ненулевое значение только если в принятом сообщении ("200 OK" или "ACK") действительно присутствует сообщение SDP. Но функция eXosip_get_remote_sdp() возвращает указатель на принятое сообщение SDP безотносительно текущего события. В наших случаях при приеме сообщения "ACK", в котором не было SDP, eXosip_get_remote_sdp() возвращало сообщение SDP, принятое ранее в сообщении "INVITE". Но это был не ответ, а предложение SDP! В результате этой ошибки предложение и ответ SDP оказывались перепутаны местами, что в конечном итоге и приводило к формированию неверных медиа-параметров. Удивительно, что на такую ошибку не было жалоб в течение без малого двух лет!

Самое обидное, что изменение этой строки не было необходимо для решения пробемы тикета #409. Скорее всего я просто решил попутно применить более удобную и, как мне казалось, эквивалентную функцию... :)

[alx]

In 2513/sip_ua:

Исправлена ошибка валидации ответа SDP

В r2133 была внесена ошибка, приводившая к тому,
что если входящее сообщение INVITE содержало предложение SDP,
то при последующем получении сообщения ACK, не содержащего SDP,
выполнялась валидация сообщения SDP из принятого INVITE как
если бы это был ответ. То есть при этой валидации предложение
и ответ SDP оказывались перепутаны. Это могло приводить к
формированию неверных медиапарамотров.
Closes #457. See #409.