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

От: Dmitry Akindinov <CGatePro_at_mx_ru>
Дата: Wed 06 Dec 2006 - 19:38:42 MSK

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

Dmitry Panov wrote:
> Добрый вечер,
>
> On Wed, 2006-12-06 at 18:30 +0300, Dmitry Akindinov wrote:

>> Здравствуйте,
>>
>> 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?
>>

>
> У приложения -- пусто, у voicemail -- 5 sec.

Хмм. По идее, приложение должно бы первым принять звонок.

Но в логе про voicemail не было ничего...

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

>
> С этим конечно трудно спорить, тут все зависит от точки зрения :) Но мне
> все-таки кажется, что более правильным было бы не очищать список, а
> давать им возможность тоже побороться за звонок. Ведь если я сделаю два
> правила fork, выполнение второго не очистит список? Почему же тогда
> redirect должен это делать?

Потому, что redirect - это не fork. Если надо добавить URI и дать всем побороться - используйте fork.

> Пусть убивает только те, что были в списке
> изначально, а не явились результатом fork.

Redirect на несколько URI тоже можно сделать, кстати.

> Best regards,

-- 
Best regards,
Dmitry Akindinov

Получено Wed Dec 06 16:38:52 2006