Не освободился канал PRI при ошибке создания соединения в MSP

[alx]

В процессе экспериментов возникла следующая ситуация:

• со стороны сети IP пришел INVITE, этот вызов был принят транком PRI, для него был занят таймслот 1 транка PRI (канал 130 платы VE-01).
• Удаленной стороне передали SETUP.
• В ответ на SETUP от удаленной стороны получено CALL PROCEEDING.
• От удаленной стороны получено ALERTING. В этот момент шлюз попытался создать соединение, но получил от MSP сообщение об ошибке:

  May 23 07:44:04 sip_ua[363]: comcerto.cpp:2165: !!!!! function SUPVSR_CREATE_CHANNEL (0x0010): error ERR_TDMDRV_INVTS (0xffbd):
  May 23 07:44:04 sip_ua[363]: comcerto.cpp:2166: TDM timeslot is invalid
  May 23 07:44:04 sip_ua[363]: comcerto.cpp:3053: createConnection() failed (result=-65469)
  May 23 07:44:04 sip_ua[363]: comcerto.cpp:6664: ts 129: createConnection() failed (result=-1)
  

После этого канал остался в состоянии Proceeding, соединение не было разорвано. Скриншот:

Полный лог здесь​.

В описанном сценарии есть сразу две проблемы:

1. MSP вернул ошибку в ответ на запрос создания соединения;
2. вызов не был завершен по инициативе местной стороны, и канал не вернулся в исходное состояние.

С первой проблемой мы вряд ли что-то можем сделать, разве что проверить, что мы передаем верный номер таймслота в запросе создания соединения. Скорее всего с этим у нас все в порядке, и ответ с ошибкой - это какой-то баг прошивки MSP.

По второй же проблеме при возникновении ошибки в процессе создания соединения вызов необходимо завершить, а канал, которому он был назначен, вернуть в исходное состояние.

[alx]

Здесь канал (соединение) создавалось внутри setRTPparams(). Если создание соединения не удалось, setRTPparams() возвращает ненулевое значение. В этом случае в обработчике eRTPparams каналу, который не удалось создать (в нашем случае канал 130, таймслот 129) посылается два события: eHangup и eDisconnectEvent.

При получении eHangup выполняется hangup(), в котором канал посылает отбой в сторону IP, вызвав ua_hangup() и очищает идентификатор активного соединения. При получении eDisconnectEvent уже ничего не происходит, так как идентификатора соединения уже нет, и канал не считает это событие отбоем своего соединения.

Похоже, для корректного отбоя в описанной ситуации PRI должен обрататывать событие eHangup аналогично eDisconnectEvent до того как оно обработается базовым классом, как это делается во всех прочих канальных окончаниях, например, 1IND.

[alx]

Синтетический тест баг воспроизвел: вызывающему в сеть IP передается отбой, а канал остался в состоянии Proceeding.

[alx]

In 1525/sip_ua:

Исправлена ошибка: при получении канальным окончанием PRI события eHangup
возникал односторонний отбой, так как eHangup обрабатывался только базовым классом.
Теперь канальному окончанию PRI добавлена обработка события eHangup. Closes #268.