Re: SIP: Fork и unknown user account

Дмитрий, спасибо.
Я с позволения других читателей рассылки по аргументирую свою точку зрения.

>
> А звонящий знает, что он звонит в аккаунт? А если там вместо аккаунта -
> форвардер (на плохой номер) или роутинг совсем на другой SIP сервер?
Да, знает. В том-то и дело, что он набирает masha@pasha.com и не его дело, какой за этой машейпашей скрывается механизм доставки. Получая сообщение о неизвестном аккаунте он приходит к выводу, что аккуаунта больше нет: Маша с Пашей развелись, Машу из паши.ком уволили, короче случилось что-то непоправимое. На самом деле, ничего непоправимого-то не случилось.
Это тот случай, когда есть прямая аналогия с электронной почтой и мне кажется, что строго по аналогии и должен вести себя сервер.

обратная сторона этого вопроса - административная: после получения этой ошибки я провел несколько неприятных минут, пытаясь понять, в каком месте я сломал собственный аккаунт. Администратора это сообщение гонит в Domain-->Users, а не в лог.

>
> > Согласен кто-нибудь со мной, что это неверное сообщение и его надо
> > как-нибудь поправить?
>
> Я согласен, что, конечно, достаточно сказать - "не смогла", остальные
> детали могут только запутать звонящего. Сейчас "прозрачность" во вопросе
> показа настоящего кода ошибки звонящего - результат "прозрачности"
> отработки сигнала: форкинг правилом практически аналогичен форкингом на
> регистрации, в объект-сигнал просто добавляются дополнительные URI для
> обработки. А ошибкой обработки сигнала будет последняя фактическая ошибка.

Да, безусловное.
Но есть огромная разница между:
masha@pasha.com: unknow user account
и
masha@pasha.com: temporary error -- mashamobile@pasha-corp.com: unknown user account

Ср. с тем же е-мейлом:
pasha.com reports: no such user: masha@pasha.com mail3.pasha.com reports: user masha-mobile is out of quota

(в ответ на письмо на masha@pasha.com)
>
> Можно все это дело изолировать, но обработка сигнала усложнится и станет
> менее эффективной.
>
> Если такой подход крайне необходим, то решением может быть обработка
> звонкомв в локальные аккаунты через B2BUA приложение: его входное плечо
> может возвращать звонящему один и тот же код ошибки, вне зависимости от
> того, что было получено исходящим плечом.

Понятно, что это можно обойти. По моему мнению это -- системная вещь и я считаю, что дефолтное поведение -- неправильное.

-- 
С уважением,
Павел