Opened 8 years ago
Closed 8 years ago
#202 closed баг (готово)
Предположительная потеря дескриптора соединения
Reported by: | alx | Owned by: | alx |
---|---|---|---|
Priority: | высокий | Milestone: | 1 очередь |
Component: | VE-01 | Keywords: | |
Cc: |
Description
- Окончание FXO получает вызывной сигнал и отправляет вызов группе 803.
- Телефоны 101, 102, 103, 104 и 201 звенят.
- На телефоне 103 снимается трубка.
- Устанавливается соединение, остальные телефоны звенеть перестают.
- абонент 103 нажимает flash, однако признаков посылки REINVITE в логе нет, у окончания FXO по-прежнему остается активный RTP поток!
- абонент 103 получает CallDisconnect от FXO (неизвестно как сформированный).
- абонент 103 вызывает 102.
- аппарат 102 звенит.
- практически одновременно абонент 103 кладет трубку, абонент 102 снимает трубку.
- Устанавливается соединение 103 <--> 102.
- 103 получает CallDisconnect для нового соединения и отправляет BYE, который не доставляется прокси-сервером (Message failed).
- через некоторое время абонент 102 (который, видимо, ничего не слышал в трубке) кладет трубку.
В результате всего этого остается неотбитое соединение канального окончания FXO, которое при этом рефрешится по UPDATE/200 OK!
Судя по всему, при нажатии flash абонентом 103 соединение не было переведено на hold, но и отбито тоже не было. Оно осталось существовать в виде дескриптора соединения, "привязанного" к каналу 3, в то время как канал 3 об этом соединении ничего не знает.
При каждом рефреше сессии канал 3 получал уведомление о получении ответа 200.
Change History (5)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
По пункту 5: REINVITE был послан, но не дошел до получателя из-за ошибки прокси (No other DNS entries to try (7,111)). Это и было причиной одностороннего CallDisconnect, в результате которого канальное окончание FXS "забыло" о соединении, при том что дескриптор остался существовать.
comment:3 by , 8 years ago
Установлено, что иногда сообщения не проходят через прокси из-за того что по каким-то причинам прокси выбирает для отправки сообщения шлюзу транспорт TCP, которого у шлюза нет. Замечено, что это происходит довольно редко и касается только запросов.
Варианты решения:
- Добавить шлюзу транспорт TCP.
- Заменить шлюзу существующий транспорт UDP на транспорт TCP.
- Изменить настройки транспортов прокси-сервера таким образом, чтобы внешние (существующие) транспорты слушали только внешние адреса, и дополнительно добавить специальный транспорт для связи со шлюзом на адресе 127.0.0.1 в надежде что для отправки на адрес 127.0.0.1 всегда будет выбираться именно он.
comment:4 by , 8 years ago
Установлено, что в TransportSelector::transmit() иногда вызывается с target 127.0.0.1:6060 и протоколом TCP. Откуда происходит вызов, пока непонятно.
В качестве временного решения применен такой патч:
-
TransportSelector.cxx
old new 822 822 823 823 if (msg->isRequest()) 824 824 { 825 if(target.isV4() && target.isLoopback() && target.getPort() == 6060) { 826 target.setType(UDP); 827 } 825 828 transport = findTransportByVia(msg, target, source); 826 829 if (!transport) 827 830 {
Проблему потери сообщений из-за выбора неверного транспорта он решает.
comment:5 by , 8 years ago
Resolution: | → готово |
---|---|
Status: | new → closed |
Патч включен в дерево сборки проекта.
Лог: