#444 closed улучшение (invalid)
Интерпретация "Занятости" абонента при поиске маршрута
| Reported by: | san | Owned by: | alx |
|---|---|---|---|
| Priority: | средний | Milestone: | 1 очередь |
| Component: | any | Keywords: | |
| Cc: |
Description
У пользователя возникла небольшая проблема с настройкой маршрутов в плате VE-01.
Он для некоторых вызовов использует резервные маршруты, т.е. чекбокс "Прекратить поиск после нахождения маршрутов" снят.
Также есть некоторые маршруты у которых нет резервного. При вызове через этот маршрут, если удалённый абонент занят, плата VE-01 ищет следующий маршрут и не находя его говорит "номер не существует". Т.е. звонящий пользователь, вместо ожидаемого ответа "занято", получает "номер не существует" и оказывается введён в заблуждение.
Пользователь просит рассмотреть возможность решения этой проблемы.
В качестве варианта решения, пользователь предлагает добавить в плату какой-то вариант настройки для алгоритма обхода маршрутов, чтобы пользователь мог указать, что занятость можно было считать "успешным" вызовом.
Change History (17)
comment:1 by , 2 months ago
| Resolution: | → готово |
|---|---|
| Status: | new → closed |
| Type: | улучшение → задача |
follow-ups: 3 5 comment:2 by , 2 months ago
Например создать окончание FXO, не соединенное ни с каким каналом - оно будет неисправно (так как при замыкании шлейфа не получит dialtone), и на все вызовы будет возвращать 480.
Пользователь так и сделал, в качестве обходного пути. Но в таком случае звонящий всё-равно не получает реальной причины отбоя, он всегда будет получать занято, если вызов не состоялся, что конечно, уже лучше воспринимается чем "номер не существует".
Я не знаю, что такое "алгоритм обхода маршрутов"
Имелось в виду предложение внести изменения в прошивку платы, в её алгоритм.
Может быть имеет смысл чекбокс "Прекратить поиск после нахождения маршрутов" сделать не общим, а индивидуально на каждый маршрут?
Мне это кажется логичным, т.к. у пользователей есть маршруты у которых нет резерва и дальше поиск продолжать нет смысла.
comment:3 by , 2 months ago
| Resolution: | готово |
|---|---|
| Status: | closed → reopened |
| Type: | задача → улучшение |
Replying to san:
Имелось в виду предложение внести изменения в прошивку платы, в её алгоритм.
А, значит я неправильно понял предложение пользователя.
comment:4 by , 2 months ago
Replying to san:
В качестве варианта решения, пользователь предлагает добавить в плату какой-то вариант настройки для алгоритма обхода маршрутов, чтобы пользователь мог указать, что занятость можно было считать "успешным" вызовом.
Это предложение я считаю деструктивным, так как оно "сломает" логику работы альтернативных маршрутов. Поэтому отклоняю это предложение.
comment:5 by , 2 months ago
Replying to san:
Может быть имеет смысл чекбокс "Прекратить поиск после нахождения маршрутов" сделать не общим, а индивидуально на каждый маршрут?
А вот это предложение уже более интересное. Только здесь есть большая проблема: такой настройки у маршрутов нет. :) Возможно, ее можно добавить, наверное стоит попробовать.
И еще возникает вопрос: как этот индивидуальный параметр маршрута должен сосуществовать с имеющимся глобальным параметром? Как ты себе это представляешь?
follow-up: 7 comment:6 by , 2 months ago
Я представил так, что глобального параметра вообще не будет.
Т.е. если в старой конфигурации стоит глобальная галочка прекратить, то в новой конфигурации это воспринимать как все галочки установлены, если же глобальный чекбокс снят - все индивидуальные чекбоксы сняты.
comment:7 by , 2 months ago
Replying to san:
Я представил так, что глобального параметра вообще не будет.
Это нарушит обратную совместимость. На такой вариант я вряд ли соглашусь.
follow-up: 9 comment:8 by , 2 months ago
Да, обратную совместимость действительно нарушит, об этом я не думал.
А какой критерий "обратной совместимости"? Любая новая настройка, будучи использована пользователем, нарушит обратную совместимость. Выходит, надо чтобы пользователь в новой прошивке, не трогая новую настройку, создал конфиг и этот конфиг работал так-же в плате со старой прошивкой.
Тогда предлагаю такой вариант:
Если глобальный флаг "прекратить поиск" установлен, то после нахождения первого подходящего маршрута поиск заканчивается. А если глобальный флаг не установлен, то после нахождения подходящего маршрута, анализируется значение индивидуального флага и поиск либо прекращается либо продолжается.
follow-up: 10 comment:9 by , 2 months ago
Replying to san:
Да, обратную совместимость действительно нарушит, об этом я не думал.
А какой критерий "обратной совместимости"?
Старая плата с новой конфигурацией должна работать так же, как и до появления новой функции. Хотя не уверен, что правильно понял твой вопрос.
Любая новая настройка, будучи использована пользователем, нарушит обратную совместимость.
Почему же? Это зависит от того, как новая настройка реализована. Вот, предположим, была плата с одним портом, а потом ей добавили второй порт. Соответственно, в конфиг платы добавили конфиг этого второго порта. Если стара плата просто проигнорирует конфиг второго порта (которого у нее нет), и применит конфиг первого - будет обратная совместимость. А если старая плата при получении нового конфига, допустим, зависнет - значит обратная совместимость нарушена.
Выходит, надо чтобы пользователь в новой прошивке, не трогая новую настройку, создал конфиг и этот конфиг работал так-же в плате со старой прошивкой.
Один из возможных вариантов дать маршрутам два конфигурационных флага. Установка одного означает "продолжать поиск", установка другого - "прекратить поиск", а если ни один не установлен - следовать глобальным флагам (по умолчанию флаги, естественно, не установлены). В веб-интерфейсе можно два радио-батона сделать.
Тогда предлагаю такой вариант:
Если глобальный флаг "прекратить поиск" установлен, то после нахождения первого подходящего маршрута поиск заканчивается. А если глобальный флаг не установлен, то после нахождения подходящего маршрута, анализируется значение индивидуального флага и поиск либо прекращается либо продолжается.
Годный вариант. Менее уноварсальный, зато более простой. Надо будет подумать.
Я смотрел код repro, думаю, что реализовать фичу будет несложно, хотя я до конца не разобрался, как там это работает...
comment:10 by , 2 months ago
Replying to alx:
А какой критерий "обратной совместимости"?
Старая плата с новой конфигурацией должна работать так же, как и до появления новой функции.
Имелось в виду, что работа маршрутов, не имеющих новой настройки, не должна измениться.
comment:11 by , 4 weeks ago
Перечитал тикет и возник вопрос, который почему-то не возник у меня сразу (при первом прочтении).
Replying to san:
Он для некоторых вызовов использует резервные маршруты, т.е. чекбокс "Прекратить поиск после нахождения маршрутов" снят.
Что мешает пользователю установить отметку чекбокса "Прекратить поиск после нахождения маршрутов"? Это, наверное, решило бы проблему "вызываемый номер не существует" без костылей типа описанного в comment:1...
follow-up: 13 comment:12 by , 4 weeks ago
Тогда у пользователя перестанут работать другие маршруты, подразумевающие резервирование, ради которых это галочка и снята.
comment:13 by , 4 weeks ago
Replying to san:
Тогда у пользователя перестанут работать другие маршруты, подразумевающие резервирование, ради которых это галочка и снята.
Не понимаю, что за такое хитрое резервирование пользователь настраивает, что его нельзя настроить при установленной отметке "Прекратить поиск после нахождения маршрутов". Можно пример?
follow-up: 15 comment:14 by , 4 weeks ago
| Resolution: | → invalid |
|---|---|
| Status: | reopened → closed |
Не понимаю, что за такое хитрое резервирование пользователь настраивает, что его нельзя настроить при установленной отметке "Прекратить поиск после нахождения маршрутов". Можно пример?
Какой хороший вопрос.
Оказалось. пользователь не правильно понимал значение чекбокса, он думал что при установленном чекбоксе "Прекратить поиск после нахождения маршрутов" у него не будет вызываться следующий по порядку маршут, если вызов по первому маршруту завершился неудачно.
comment:15 by , 4 weeks ago
Replying to san:
Оказалось. пользователь не правильно понимал значение чекбокса, он думал что при установленном чекбоксе "Прекратить поиск после нахождения маршрутов" у него не будет вызываться следующий по порядку маршут, если вызов по первому маршруту завершился неудачно.
Хм... Нашел в РЭ описание этого параметра (п. 7.1.4.2). Обнаружил, что там в первом же предложении, видимо, по ошибке слово "маршрут" употреблено в единственном числе (обрати внимание, что в названии параметра оно во множественном!). А далее для иллюстрации используется пример, в котором маршрут, действительно, только один (точнее, их два, но с взаимоисключающими рег. выражениями, то есть только одно рег. выражение может совпасть).
Думаю, что стоит более подробно описать этот момент в РЭ и привести более "хитрый" пример с несколькими маршрутами, совпадающими с вызываемым URI... Да и вообще было бы неплохо более ясно описать, какие проверки и в каком порядке выполняются при приеме сообщения...
follow-up: 17 comment:16 by , 4 weeks ago
по ошибке слово "маршрут" употреблено в единственном числе
Эту ошибку В.А. скопировал из вики:
https://trac.adc-line.ru/sip_ua/wiki/FunctionsSipRouting#%D0%94%D0%B2%D0%B0%D1%80%D0%B5%D0%B6%D0%B8%D0%BC%D0%B0%D0%BF%D0%BE%D0%B8%D1%81%D0%BA%D0%B0%D1%86%D0%B5%D0%BB%D0%B8
Вообще мне описание функций в вики кажется более удобным, сам я туда хожу читать. Хорошо бы и в вики и в РЭ это описать.
comment:17 by , 4 weeks ago
Replying to san:
Хорошо бы и в вики и в РЭ это описать.
Дополнил описание в wiki-статье. Для корректировки РЭ создал тикет для @Vladimir с соответствующим предложением для @Vladimir.
Replying to san:
Я не знаю, что такое "алгоритм обхода маршрутов", но мне в голову приходит такой вариант решения описанной проблемы: создать всегда занятое канальное окончание, которое будет принимать описанные вызовы. Например создать окончание FXO, не соединенное ни с каким каналом - оно будет неисправно (так как при замыкании шлейфа не получит dialtone), и на все вызовы будет возвращать 480.