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

От: Vladimir A. Butenko <CGatePro_at_mx_ru>
Дата: Wed 06 Dec 2006 - 16:51:42 MSK

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

То, что Ваше приложение "не успело взять трубу" - увы. Кто не успел, тот опоздал.

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

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.
> 
> 
> ##################################################################
> Вы получили это сообщение потому, что подписаны на список рассылки
>  <CGatePro@mx.ru>.
> 
> Чтобы отписаться, отправьте сообщение на адрес <CGatePro-off@mx.ru>
> Чтобы переключиться в режим дайджеста - mailto:<CGatePro-digest@mx.ru>
> Чтобы переключиться в индексный режим - mailto:<CGatePro-index@mx.ru>
> Для административных запросов адрес <CGatePro-request@mx.ru>
> Архив списка: http://mx.demos.su/lists/cgp-russian/
> 
> 
> 

Sincerely,
Vladimir Получено Wed Dec 06 13:50:14 2006

Этот архив был сгенерирован hypermail 2.1.8 : Fri 24 Apr 2015 - 16:15:21 MSK