Re: Вопрос про fork

От: Dmitry Akindinov <CGatePro_at_mx_ru>
Дата: Wed 06 Dec 2006 - 18:30:13 MSK

Здравствуйте,

Dmitry Panov wrote:
> On Wed, 2006-12-06 at 05:51 -0800, Vladimir A. Butenko wrote:

>> Первое - не баг, а фича: когда началось правило "VoiceMail" - в нем стоит 
>> "Redirect #voicemail". А раз редирект - значит, оно посылает CANCEL всем, 
>> кому форкнуло.
>>
>> То, что Ваше приложение "не успело взять трубу" - увы. Кто не успел, тот 
>> опоздал.
>>

>
> Правильно ли я понимаю, что при отсутствии регистраций все правила
> начинают выполняться сразу независимо от stage?

Порядок их применения от stage зависит, но ожидания по таймеру не будет.

> Всё равно непонятно
> почему моё приложение не успевает. У него тоже AcceptCall() первой
> строчкой, а приоритет правила выше чем у voicemail.

А stage?

> И почему редирект должен посылать CANCEL всем остальным тоже непонятно.
> Это касается данного конкретного диалога, какое ему дело до остальных?

Диалога еще нет. Есть набор отдельных транзакций, которые надо прекратить.

При поступлении сигнала сервер построил список URI, которым этот сигнал надо отправить. Изначально там URI от всех активных регистраций. Операция Fork добавляет новые URI в этот список. Для каждого элемента списка создается маленький SIP Client (SIPC в логах), который будет отрабатывать транзакцию с назначенным ему URI. По всему списку рассылается сигнал (INVITE). Время идет, (или даже не идет, если нет регистраций) и до применения следующего правила серевер мог успеть разослать запрос по части URI из списка. Если правила требуют выполнить Redirect, то текущий список URI мы должны убить и заменить теми URI, что указаны в парамтрах действия. Но часть SIPC могла уже разослать INVITE. Поскольку мы в те URI уже больше не хотим звонить, надо послать CANCEL.

>> Второе - надо логи смотреть. Причем подробные.
>>

>
> Сделаем и вышлем на support.

Спасибо, получили. Разбираемся.

И, похоже, проблема именно с отправкой CANCEL. Сейчас сервер не отправляет его вслепую вслед за только что ушедшим INVITE. Потому что, навстречу уже может идти 200, который "гасить" надо с помощью ACK и BYE. Но с другой стороны, непонятно - есть ли кто живой на другом конце. Поэтому SIPC ждет T2 (4 секунды) реакции с другой стороны (предположительно - 100 или 18x) и уже тогда шлет CANCEL. Проблема, похоже, в том, что приход 1хх ответа заставляет забыть этот, в общем-то уже не нужный никому SIPC объект, что он приговорен к отмене. Поправим.

>> On Wed, 06 Dec 2006 16:42:50 +0300
>>   "Dmitry Panov" <CGatePro@mx.ru> wrote:
>>> Добрый день.
>>>
>>> Решили тут сделать один эксперимент (на CGP 5.1.3). Идея такая:
>>> пользовательским правилом делается fork на какое-то приложение так,
>>> чтобы это правило срабатывало до редиректа на voicemail и при
>>> определенных условиях делало AcceptCall(), перехватывая таким образом
>>> звонок. В тестах приложение просто делало AcceptCall() всегда, после
>>> чего проигрывало файл "welcome", после чего делало Disconnect(), и
>>> завершалось.
>>>
>>> Первый облом случился сразу же, поскольку при отсутствии регистрации
>>> задача, которая повешена на fork, не запускается, хотя судя по логам
>>> правило сработало, и fork был:
>>>
>>> 13:57:05.641 4 SIGNALRULE-000046 rule(test) conditions met
>>> 13:57:05.641 2 SIGNALRULE-000046 forked
>>> 13:57:05.641 4 SIGNAL-000046 AOR added: sip:test1#dop@********
>>> 13:57:05.641 2 SIGNAL-000046 dop@******** has no registration,
>>> trying '
>>> no response' rules
>>> 13:57:05.641 4 SIGNAL-000046 cancelling all
>>> 13:57:05.641 4 SIGNALRULE-000046 rule(#MailOnTimer) conditions met
>>> 13:57:05.641 2 SIGNALRULE-000046 redirected
>>> 13:57:05.641 4 SIGNAL-000046 cancelling all
>>> 13:57:05.641 4 SIGNAL-000046 skipping 1 AORs
>>> 13:57:05.641 4 SIGNAL-000046 AOR added:
>>> sip:voicemail#dop@*********
>>> 13:57:05.641 5 SIGNAL-000046 timeout set for 5 secs
>>> 13:57:05.641 2 SIGNAL-000046 INVITE sip:voicemail#dop@*********
>>> via sip:
>>> voicemail#dop@*********
>>> 13:57:05.641 5 NODE 76: enqueued
>>> 13:57:05.641 2 PBXLEG-000076 enqueued
>>> 13:57:05.641 2 PBXLEG-000076 'voicemail' created for
>>> dop@********
>>>
>>> При этом не имеет значения как включен voicemail, обычной галкой в Call
>>> Control или сложным правилом. 
>>>
>>> Вторая проблема выявилась после того, как эксперимент повторили когда
>>> пользователь был зарегистрирован. Звонящему сказали "welcome" и повесили
>>> трубку, но при этом телефон пользователя продолжал звонить. После снятия
>>> трубки клиент в ответ на свои OK ничего не получал. Когда после таймаута
>>> он послал BYE, в ответ пришло 481 "Transaction Does Not Exist". 
>>>
>>> Беглый анализ трафика показал, что удаленному абоненту пришел всего один
>>> Trying. Это вроде бы нормально, это значит что прокси взял на себя
>>> обязательство эти диалоги разрулить. Но после положительного final
>>> response от первого диалога (приложение сказало AcceptCall()) второй не
>>> был отменен как логично было бы предположить. Зато уже после того, как
>>> разговор с приложением завершился, видимо в момент снятия трубки,
>>> звонящему пришел OK от второго диалога, который естественно был
>>> проигнорирован. 
>>>
>>> Оба эти момента очень похожи на баги в CGP, было бы очень интересно
>>> послушать комментарии разработчиков.
>>>
>>> Best regards,
>>> -- 
>>> Dmitry Panov
>>> Chief Technology Officer
>>> Itoolabs.

-- 
Best regards,
Dmitry Akindinov

Получено Wed Dec 06 15:30:17 2006