Re: п▓п╬п©я─п╬я│ п©я─п╬ fork

Добрый вечер,

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.

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

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

Best regards,
--
 Dmitry Panov
 Chief Technology Officer
 Itoolabs. Получено Wed Dec 06 16:18:59 2006