Бонжур. Нарвался на грабли. Есть великолепный Addpac 1005, на него заведены 4 линии. Проблем с ним никогда не знал, но.

Надо чтобы звонок с определенного экстеншна проходил на определенную линию заведенную в Addpac. На вход настроил без проблем,, проблема с исходящими, т.к. шлюз всеравно звонок кидает на линию согласно приоритетам.

вот фрагменты конфига Addpac:

!
! FXO
voice-port 0/3
connection plar 298
caller-id enable
caller-id type etsi-dtmf
!

- звонит на астер на экстен 298, все как надо

!
dial-peer voice 3 pots
destination-pattern T
port 0/3
user-name 1013
user-password %%%%%
preference 9
huntstop
!

huntstop поставил сегодня. с ним, или без него, всеравно идут звонки по приоритетам.

в extension.conf:

Dial(SIP/${EXTEN}@1013,60,rT) - т.е. звоним через 1013 , он должен переправить звонок на 0/3 , чего, собственно, и не происходит.


Где я прокололся? и какие могут быть варианты решения задачки? думаю довешивать в астериские номер всякими закорючками, и потом городить диалплан в Addpac, чтобы хоть по закорючкам отправлял на нужный порт. Но это немного через пень, хочу девайс понять.

custom contexts?

йес, контексты разные. астер честно звонит через линию 1013, и она честно зарегена, но адпак валит звонок не на тот FXO порт

Может destination-pattern'ов ему поконкретней расписать?

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

Я так понимаю, что через 0/3 должен кто-то конкретный звонить?
Тогда на dial-peer voice 3 pots мало destination-pattern T, добавте фильтр по incoming number
!
dial-peer voice 3 pots
destination-pattern - тут тоже лучше сузить назначение, в городе не любой значности номера, и не с любых цифр.
answer-address - вот это то, что имел ввиду
port 0/3
user-name 1013
user-password %%%%%
preference 9
huntstop
!
И в него будут уходить звонки с ожидаемых CallerID

Спасибо, суть ясна. Дам заданному порту высшее предпочтение для звонков и отфильтрую всех, кроме заданного exten.

Можно не только по заданному exten, а по группе, используя шаблон. Например
answer-address 12. даст возможность звонить только экст. 120, 121, 122, и т.д.
answer-address 13[12] даст возможность звонить только экст. 131 и 132
# answer-address ?
<[0-9#*]|[].T> Address Pattern String


Так же как ИП пакеты телефонные звонки можно фильтровать по source - CallerID, и по destination - DID.
На любом участке прохождения. Делать трансляции (преобразования номера) для этого - крайняя мера, не очень оправдано.

где-то я прокололся, сейчас в destination-pattern прописал первые цифры своего мобильника, а адпак всеравно звонит не через тот FXO, на который завязан паттерн, а тот который более приоритетен для исходящих.

729 <SIP 6859> : Receive INVITE Request
730 <NetCon 6859> : Found inbound voip peer by dest-pattern id(1020)
731 <Call 6859> : From Net - calledParty(8921%%%%%%) callingParty(207)
732 <Call 6859> : MatchedPerfect
733 <Call 6859> : MatchAllProcess After Sorted
<0> id(1) dest(T) prefer(3) selected(191)
<1> id(2) dest(T) prefer(5) selected(743)
<2> id(0) dest(T) prefer(8) selected(0)
<3> id(3) dest(8921...) prefer(9) selected(3749)
734 <Call 6859> : Initiate callee with dial-peer(T) status(CalleeDeterminedAll) id(00000000-0000-0000-0000-000000000000)

понятное дело, что паттерны разные попробовал. И алгоритм выбора линии стоит нулевой (самое длинное совпадение, явное предпочтение). Т.е. 8921...T должен быть на первом месте, а он всегда четко на последнем.
Huntstop не работает, паттерны - тоже...
Уже смотрю в угол с пыльным д-линк 4022, решить задачу в лоб.

У вас существуют пиры с destination T и высшими преференциями 3, 5, 8 таким образом матчинг 8921....... игнорируется преференциями
<0> id(1) dest(T) prefer(3) selected(191)
<1> id(2) dest(T) prefer(5) selected(743)
<2> id(0) dest(T) prefer(8) selected(0)

1) Убирайте preference с пиров.
2) Не используйте букву Т
3) Считайте точки внимательней.