simul-call-limit-reached при схеме USER/Device

[ScoRpioN_]

День добрый. Подскажите, кто сталкивался с подобным багом.
Опишу ситуацию.
Стоит FreePBX 6.12.65-30 (Asterisk 13.5.0). Используется схема работы User/Device, когда сотрудники КоллЦентра логинятся на девайсы в начале смены.
Соответственно в базе /DEVICE/1111/user и /AMPUSER/1111/device могут иметь имеют разные значения. У каждого пользователя свой девайс и у каждого девайса свой пользователь.
Сразу оговорюсь, что нумерация пользователей и девайсов пересекается. И возможно это не самый лучший вариант, но уж так сложилось.

Проблема.
Обнаружилось, что при звонках на RingGroup с несколькими внешними номерами пользователи получают Playback(beep&im-sorry&your&simul-call-limit-reached&goodbye).

Поиск дал следующее. Playback идет из [macro-user-callerid]. Получается по причине проверки в 6ой строчке: exten => s,n,GotoIf($["${AMPUSER}" = "none"]?limit)
А "none" ставит 5ая строчка: exten => s,n,Set(AMPUSER=${DB(DEVICE/${REALCALLERIDNUM}/user)}).

И вот к ней у меня как раз и вопрос. Т.е. она берет номер пользователя совершающего звонок (например, REALCALLERIDNUM = 1111, а /AMPUSER/1111/device = 1112), ставит его в номер девайса (Device/1111) и уже у девайса берет пользователя (Device/1111/user = none). У девайса 1111 на данный момент может и не быть пользователя.
Это же в корне не верно. А главное почему так?
Даже если бы у меня нумерации девайсов и пользователей не пересекались, то я получал бы в 5ой строчке AMPUSER=${DB(DEVICE/${REALCALLERIDNUM}/user = "". Т.к. номер пользователя приводил бы к несуществующему номеру девайса. И только за счёт этого проверка 6ой строчки не вываливалась с ошибкой. Везение, но тоже работает не верно.

Этот кусок макроса работает верно только в одном случае, когда пользователи однозначно закреплены за девайсами, словами FreePBX схема работы c Extensions.

Может я что-то не понимаю? Может есть какой патч? Или как самому исправить ситуацию?

ЗЫ. Смена нумерации, чтобы не было пересечений, исправит ситуацию, но работать будет всё равно не верно.
Переписать данный макрос самому и заблокировать проверку можно, но к чему это может привести.
Есть ли ещё варианты.

Спасибо.

[ded]

1) Смена нумерации - это верное направление
2) Можно указать у пользователя SIP Alias - совсем другой номер, и тогда он будет подставляться в качестве CID.
3) Доработать макрос и переписать его в раздел _override_

[ScoRpioN_]

После некоторых копаний обнаружил ещё один затык.

В процессе вызова на группу этот макрос запускается несколько раз.
Первый при вызове номера группы. Тут макрос правильно отрабатывает. Т.к. видит номер звонящего как номеру девайса. Далее лезет в базу и берет по номеру девайса верного пользователя. Ставит его в AMPUSER. И далее в CALLERID(number).
Далее идем по диалплану. Попадаем в группу. Берем номера из группы. Начинаем звонить по номеру в группе.
Тут макрос вызывается второй раз и берет за основу всё тот же AMPUSER и CALLERID(number). Но их изменили первым запуском макроса. Номер звонящего пользователя, а не девайса кочует в REALCALLERIDNUM. И получается AMPUSER=${DB(DEVICE/${REALCALLERIDNUM}/user)} уже с неверными номером девайса. Отсюда неверная работа и отбой.

Правки макроса в _override_ контексте приводят к ещё большим проблемам. Т.к. изменения начинают влиять глобально на всю работу сервера. А есть ситуации, где макрос работает верно. Правда потом сам же себя и запутывает. Изменений в макрос не смог придумать.
Нашел иной путь решения, поменяв совсем логику вызова группы, чтобы не было такого зацикливания.