Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#206 closed баг (fixed)

Ошибка при отправке NOTIFY

Reported by: alx Owned by: alx
Priority: средний Milestone: 1 очередь
Component: any Keywords:
Cc:

Description

При выполнении Call Transfer при получении REFER UA уведомляет инициатора трансфера о ходе трансфера отправкой NOTIFY. Иногда (замечено при создании конференции методом "REFER конференции", когда два REFER передаются в одно и то же соединение), что при попытке сформировать NOTIFY eXosip_call_build_notify() возвращает ошибку -3, что означает OSIP_WRONG_STATE.

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

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

Change History (3)

comment:1 by alx, 8 years ago

Пока в качестве (временного?) решения изменена логика тренсфера в конференцию: второй REFER отправляется не после получения ответа "202" на предыдущий, а после получения завершающего NOTIFY после предыдущего трансфера.

comment:2 by alx, 8 years ago

Resolution: fixed
Status: newclosed

In 1106/sip_ua:

Изменен процесс создания конференции методом "REFER конференции": теперь трансфре второго
соединения в конференцию выполняется не после получения ответа 202 на первый REFER, а после
получения завершающего NOTIFY (т.е. после полного окончания процесса трансфера). Closes #206.

comment:3 by alx, 7 years ago

In 1311/sip_ua:

Изменен алгоритм тарнсфера. Теперь при вызове канальным окончанием ua_refer_to()
формируется сообщение INVITE, затем отправляется NOTIFY c "100 Trying", а
сообщение INVITE не отправляется, а сохраняется в CallData (вместе с номером TS).
При получении любого ответа на NOTIFY (включая 1xx), если в CallData есть
сохраненный INVITE, он отправляется в сеть, а канальному окончанию передается
событие eCallReplace с указанием нового идентификатора вызова. Таким образом
устраняется ситуация, когда ответ на INVITE и следующая за ним попытка отправки
финального NOTIFY происходит до того, как получен ответ на первый NOTIFY.
See #206.

В окончаниях FXS отбой после завершения трансфера выполняется только если был
установлен флаг hangup_after_refer. Он устанавливается, если выполняется
"простой" трансфер, но не трансфер в конференцию.

Note: See TracTickets for help on using tickets.