Opened 5 months ago

Closed 4 months ago

Last modified 4 months ago

#424 closed улучшение (fixed)

Выделение приоритетных каналов PRI

Reported by: san Owned by: alx
Priority: средний Milestone: 1 очередь
Component: any Keywords:
Cc:

Description

  1. Пользователям требуется возможность явно указывать определённые каналы окончания PRI для приоритетных вызовов.

Сторонняя АТС выделяет определённый канал PRI, например 10-й, для абонента Петя. В этот канал со стороны АТС может позвонить только Петя и никто другой. При вызовах со стороны IP, даже если остальные каналы заняты разговорами, 10-й канал не должен заниматься никем другим.
Т.е. в плате VE для каждого канала PRI должна быть настройка - флаг, назовём его "выделенный канал", при установке которой, со стороны IP этот канал никогда не должен заниматься.

  1. Т.к. пользователи используют на сторонних АТС возможность выделения определённого канала для определенного пользователя, может быть и нам стоит предусмотреть такую возможность. Например, при установленном флаге "выделенный канал" для определённого канала PRI, принимать вызовы в этот канал со стороны IP только если параметр line в вызываемом URI совпадает номером канала. Ну либо ещё каким-то образом идентифицировать вызовы.

Change History (7)

in reply to:  description comment:1 by alx, 5 months ago

Replying to san:

Т.е. в плате VE для каждого канала PRI должна быть настройка - флаг, назовём его "выделенный канал", при установке которой, со стороны IP этот канал никогда не должен заниматься.

Возражений нет, и вроде бы на первый взгляд это реализовать несложно. Только предложенное название мне не очень нравится - из него не очевидна суть настройки. Я бы предпочел что-то типа "Запрет исходящих", чтобы можно было догадаться, не открывая РЭ... :)

...может быть и нам стоит предусмотреть такую возможность. Например, при установленном флаге "выделенный канал" для определённого канала PRI, принимать вызовы в этот канал со стороны IP только если параметр line в вызываемом URI совпадает номером канала.

Суть предложенной функции понятна, но непонятен ее смысл - как эта функция улучшает нашу аппаратуру.

comment:2 by san, 5 months ago

Суть предложенной функции понятна, но непонятен ее смысл - как эта функция улучшает нашу аппаратуру.

Если пользователь Вася находится со стороны VE, то таким образом можно выделить для него отдельный канал в PRI. Пользователь может добавлять к вызовам Васи параметр line в URI(с помощью маршрута или другим способом), тогда вызовы Васи будут попадать в выделенный для него канал PRI, а вызовы остальных пользователей не будут.
Раз пользователи используют функцию выделения какала PRI для абонента на другом оборудовании, значит она востребована, возможно она им пригодится и в нашей плате VE.
Так-же и в случае примера из п.1(где для Пети выделен канал 10) пользователь сможет настроить чтобы и вызовы к Пете попадали только в 10-й канал, не занимая лишних каналов.

comment:3 by alx, 5 months ago

Перечитал предложение свежим взглядом и понял, что суть улучшения по первому пункту (запрет исходящих вызовов по определенному каналу) мне тоже непонятна. Поясни, пожалуйста, если можешь, в чем суть этого улучшения.

comment:4 by san, 5 months ago

Допустим некая АТС подключена "в город" через PRI, также на этой АТС есть приоритетный абонент, он всегда должен иметь возможность позвонить в город, даже если желающих звонить больше чем ёмкость PRI. И ему "из города" тоже должны всегда дозваниваться. Для этого АТС и "город" должны каким-то образом выделить один из каналов PRI для звонков от приоритетного абонента или к приоритетному.
VE в этом примере может быть стороной "город" (п.1) или стороной АТС(п.2).

comment:5 by alx, 4 months ago

Resolution: fixed
Status: newclosed

In 2336/sip_ua:

Канальному окончанию ISDN PRI добавлен конфигурационный параметр
blkOut, содержащий битовую карту таймслотов, которые запрещено
занимать при исходящем вызове (в сторону TDM). Closes #424.

comment:6 by alx, 4 months ago

Реализовано первое из двух предложений тикета. Второе предложение мне не понравилось - я считаю, что такая реализация неудобна/непрактична.

comment:7 by alx, 4 months ago

По поводу второго предложения создал новый тикет #432. После изучения вопроса я пришел к выводу, что это действительно может быть полезно, но мотивация несколько иная - результаты размышлений изложены в тикете.

Note: See TracTickets for help on using tickets.