1IND: Ложный разрыв соединения по таймауту RTP

[san]

У пользователя все исходящие звонки через 1IND обрываются через 180 секунд.
Входящие звонки длятся положенное время.

В эксперименте пользователь совершает исходящий звонок с номера 491717 на номер 83422801186 и в 10:40:51 срабатывает RTP timeout. Хотя в настройках RTP timeout=60 секунд и паузы в разговоре были не более 5 секунд.

r43

Лог эксперимента и конфиг прилагаю.

[alx]

Судя по записи в строке 279 лога, соединение разорвано из-за таймаута RTP канального окончания 1IND. Таймаут RTP установлен в значение 60 секунд.

За минуту до истечения таймаута мы видим в логе записи:

comcerto.cpp:7146: ts 177: starting RTP stream to 02:ad:c3:00:00:ea
comcerto.cpp:7146: ts 15: starting RTP stream to 02:ad:c3:00:00:ea

Такие записи выводятся в функции arp_timeout() в случае, если обнаружено изменение MAC адреса получателя. И это странно, так как оба конца соединения находятся на плате VE-01, и адрес получателя - собственный адрес платы. Понятное дело, что он не изменялся... Примерный сценарий происходящего такой:

• При установке соединения (точнее, организации медиапотока):
  • определяется MAC адрес получателя и запоминается в переменной rtp_dst_mac;
  • включается RTP поток;
  • включается мониторинг RTP;
  • устанавливается 2-минутный таймер вызова arp_timeout();
  • запускается таймер таймаута RTP.
• При получении входящего потока RTP из MSP приходит сообщение о наличии потока, по нему останавливается таймер таймаута RTP.
• Через 2 минуты от начала соежинения старабывает таймер и вызывается arp_timeout(). В нем повторно выполняется определение MAC адреса получателя. По каким-то причинам результат не совпадает с адресом, запомненном в переменной rtp_dst_mac. В результате повторно выполняются действия по инициализации потока RTP, в том числе запуск таймера таймаута RTP. Однако на этот раз сообщение о наличии потока RTP уже не приходит (так как оно уже было две минуты назад!), и
• через минуту таймер RTP срабатывает и разрывает соединение.

[alx]

rtp_dst_mac "обнуляется" только при отключении потока RTP, чего в нашем сценарии не происходило. Больше она нигде "портиться" не должна...

Думаю, надо будет сделать какой-то дополнительный вывод в лог, и повторить эксперимент чтобы понять, что там происходит. Детализацию лога на этот раз хотелось бы более высокую (приложенный лог, насколько я вижу, следан не с максимальной детализацией), и получить лог полностью (в приложенном логе почему-то отсутствует собственно установка соединения).

[san]

Боюсь что повторный эксперимент на том блоке провести не получится.

[alx]

Жаль. Тогда остается только предложить пользователю не пользоваться таймаутом RTP.

[san]

Воспроизвелось на АТС "Суда"(Уинский район).
Пользователь сообщил, что происходят неожиданные разрывы связи через 3 минуты исходящего разговора(в разговоре речевой трафик не прерывается на время более ~5 сек). Воспроизводится при каждом исходящем вызове. Пользователь обновился до r50 и разрывы стали происходить по истечению 1 мин.
Логов пока нет.
Я, вспомнив этот тикет, предложил пользователю, в качестве быстрого эксперимента, установить у окончания 1IND "таймаут RTP" = 0. Помогло, связь не обрывается.
Затем пользователь провёл ещё эксперимент - установил таймаут RTP=140, связь оборвалась примерно через 140 сек.

Предположительно воспроизводится и на АТС "Ломь", там примерно прошлогодняя ревизия VE и пользователи жалуются на разрывы исходящих разговоров через 3 мин.

[alx]

О, у меня тоже вдруг воспроизвелось. Попробую поисследовать...

[alx]

In 1598/sip_ua:

Устранена проблема ложного разрыва соединений по таймауту RTP.
Раньше индикация появления/пропадания потока RTP включалась при
активации потока каналом и выключалась при деактивации, в результате
могли теряться сообщения о появлении потока. Теперь индикация включается
сразу после создания канала (до любых других настроек) и никогда не
отключается. Таймаут RTP теперь отсчитывается только от сообщения о
пропадании потока RTP. Если RTP не было принято вообще, разъединения
по таймауту не будет. Closes #276.