Opened 3 weeks ago
Last modified 3 weeks ago
#444 reopened улучшение
Интерпретация "Занятости" абонента при поиске маршрута
Reported by: | san | Owned by: | alx |
---|---|---|---|
Priority: | средний | Milestone: | 1 очередь |
Component: | any | Keywords: | |
Cc: |
Description
У пользователя возникла небольшая проблема с настройкой маршрутов в плате VE-01.
Он для некоторых вызовов использует резервные маршруты, т.е. чекбокс "Прекратить поиск после нахождения маршрутов" снят.
Также есть некоторые маршруты у которых нет резервного. При вызове через этот маршрут, если удалённый абонент занят, плата VE-01 ищет следующий маршрут и не находя его говорит "номер не существует". Т.е. звонящий пользователь, вместо ожидаемого ответа "занято", получает "номер не существует" и оказывается введён в заблуждение.
Пользователь просит рассмотреть возможность решения этой проблемы.
В качестве варианта решения, пользователь предлагает добавить в плату какой-то вариант настройки для алгоритма обхода маршрутов, чтобы пользователь мог указать, что занятость можно было считать "успешным" вызовом.
Change History (10)
comment:1 by , 3 weeks ago
Resolution: | → готово |
---|---|
Status: | new → closed |
Type: | улучшение → задача |
follow-ups: 3 5 comment:2 by , 3 weeks ago
Например создать окончание FXO, не соединенное ни с каким каналом - оно будет неисправно (так как при замыкании шлейфа не получит dialtone), и на все вызовы будет возвращать 480.
Пользователь так и сделал, в качестве обходного пути. Но в таком случае звонящий всё-равно не получает реальной причины отбоя, он всегда будет получать занято, если вызов не состоялся, что конечно, уже лучше воспринимается чем "номер не существует".
Я не знаю, что такое "алгоритм обхода маршрутов"
Имелось в виду предложение внести изменения в прошивку платы, в её алгоритм.
Может быть имеет смысл чекбокс "Прекратить поиск после нахождения маршрутов" сделать не общим, а индивидуально на каждый маршрут?
Мне это кажется логичным, т.к. у пользователей есть маршруты у которых нет резерва и дальше поиск продолжать нет смысла.
comment:3 by , 3 weeks ago
Resolution: | готово |
---|---|
Status: | closed → reopened |
Type: | задача → улучшение |
Replying to san:
Имелось в виду предложение внести изменения в прошивку платы, в её алгоритм.
А, значит я неправильно понял предложение пользователя.
comment:4 by , 3 weeks ago
Replying to san:
В качестве варианта решения, пользователь предлагает добавить в плату какой-то вариант настройки для алгоритма обхода маршрутов, чтобы пользователь мог указать, что занятость можно было считать "успешным" вызовом.
Это предложение я считаю деструктивным, так как оно "сломает" логику работы альтернативных маршрутов. Поэтому отклоняю это предложение.
comment:5 by , 3 weeks ago
Replying to san:
Может быть имеет смысл чекбокс "Прекратить поиск после нахождения маршрутов" сделать не общим, а индивидуально на каждый маршрут?
А вот это предложение уже более интересное. Только здесь есть большая проблема: такой настройки у маршрутов нет. :) Возможно, ее можно добавить, наверное стоит попробовать.
И еще возникает вопрос: как этот индивидуальный параметр маршрута должен сосуществовать с имеющимся глобальным параметром? Как ты себе это представляешь?
follow-up: 7 comment:6 by , 3 weeks ago
Я представил так, что глобального параметра вообще не будет.
Т.е. если в старой конфигурации стоит глобальная галочка прекратить, то в новой конфигурации это воспринимать как все галочки установлены, если же глобальный чекбокс снят - все индивидуальные чекбоксы сняты.
comment:7 by , 3 weeks ago
Replying to san:
Я представил так, что глобального параметра вообще не будет.
Это нарушит обратную совместимость. На такой вариант я вряд ли соглашусь.
follow-up: 9 comment:8 by , 3 weeks ago
Да, обратную совместимость действительно нарушит, об этом я не думал.
А какой критерий "обратной совместимости"? Любая новая настройка, будучи использована пользователем, нарушит обратную совместимость. Выходит, надо чтобы пользователь в новой прошивке, не трогая новую настройку, создал конфиг и этот конфиг работал так-же в плате со старой прошивкой.
Тогда предлагаю такой вариант:
Если глобальный флаг "прекратить поиск" установлен, то после нахождения первого подходящего маршрута поиск заканчивается. А если глобальный флаг не установлен, то после нахождения подходящего маршрута, анализируется значение индивидуального флага и поиск либо прекращается либо продолжается.
follow-up: 10 comment:9 by , 3 weeks ago
Replying to san:
Да, обратную совместимость действительно нарушит, об этом я не думал.
А какой критерий "обратной совместимости"?
Старая плата с новой конфигурацией должна работать так же, как и до появления новой функции. Хотя не уверен, что правильно понял твой вопрос.
Любая новая настройка, будучи использована пользователем, нарушит обратную совместимость.
Почему же? Это зависит от того, как новая настройка реализована. Вот, предположим, была плата с одним портом, а потом ей добавили второй порт. Соответственно, в конфиг платы добавили конфиг этого второго порта. Если стара плата просто проигнорирует конфиг второго порта (которого у нее нет), и применит конфиг первого - будет обратная совместимость. А если старая плата при получении нового конфига, допустим, зависнет - значит обратная совместимость нарушена.
Выходит, надо чтобы пользователь в новой прошивке, не трогая новую настройку, создал конфиг и этот конфиг работал так-же в плате со старой прошивкой.
Один из возможных вариантов дать маршрутам два конфигурационных флага. Установка одного означает "продолжать поиск", установка другого - "прекратить поиск", а если ни один не установлен - следовать глобальным флагам (по умолчанию флаги, естественно, не установлены). В веб-интерфейсе можно два радио-батона сделать.
Тогда предлагаю такой вариант:
Если глобальный флаг "прекратить поиск" установлен, то после нахождения первого подходящего маршрута поиск заканчивается. А если глобальный флаг не установлен, то после нахождения подходящего маршрута, анализируется значение индивидуального флага и поиск либо прекращается либо продолжается.
Годный вариант. Менее уноварсальный, зато более простой. Надо будет подумать.
Я смотрел код repro, думаю, что реализовать фичу будет несложно, хотя я до конца не разобрался, как там это работает...
comment:10 by , 3 weeks ago
Replying to alx:
А какой критерий "обратной совместимости"?
Старая плата с новой конфигурацией должна работать так же, как и до появления новой функции.
Имелось в виду, что работа маршрутов, не имеющих новой настройки, не должна измениться.
Replying to san:
Я не знаю, что такое "алгоритм обхода маршрутов", но мне в голову приходит такой вариант решения описанной проблемы: создать всегда занятое канальное окончание, которое будет принимать описанные вызовы. Например создать окончание FXO, не соединенное ни с каким каналом - оно будет неисправно (так как при замыкании шлейфа не получит dialtone), и на все вызовы будет возвращать 480.