Исходящие через OpenVox

[ded]

Вариантов немного:
1) аутентифицироваться при помощи username & secret
2) аутентифицировать вызов при помощи Caller ID

[corpse]

аутентифицироваться при помощи username & secret

Я понимаю, что с тупыми вопросами уже должен пойти читать мануалы, но я по факту и авторизуюсь с username и secret (Authorization: Digest ...):
Регистрация Avaya, все отлично работает:

Код: Выделить всё

REGISTER sip:192.168.1.241 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.198:5060;rport;branch=z9hG4bKcf604d8e9178f1219c4a861a96cb4065
From: <sip:1122@192.168.1.241>;tag=b2bbd249477df2d6
To: <sip:1122@192.168.1.241>
Call-ID: 52f0882ece1e8fd0e6bbf95ad176b457@192.168.1.189
CSeq: 1516170244 REGISTER
Contact: "Unknown" <sip:1122@192.168.1.198:5060;transport=udp>
Expires: 60
Authorization: Digest username="1122",realm="asterisk",nonce="1bb595ae",response="0366d11ff4861d51c6a14a667732cfab",uri="sip:192.168.1.241"
Max-Forwards: 70
User-Agent: IP Office 6.1 (12)
Supported: timer
Content-Length: 0

Регистрация Asterisk, где ни черта не работает:

Код: Выделить всё

REGISTER sip:192.168.1.241 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.251:5060;branch=z9hG4bK4905dc13
Max-Forwards: 70
From: <sip:790XXXXX623@192.168.1.241>;tag=as291e41df
To: <sip:790XXXXX623@192.168.1.241>
Call-ID: 07032fe52963e6d51fe4fff87b028d19@192.168.1.251
CSeq: 103 REGISTER
User-Agent: FPBX-2.11.0(11.20.0)
Authorization: Digest username="790XXXXX623", realm="asterisk", algorithm=MD5, uri="sip:192.168.1.241", nonce="51c87ad0", response="7cf18c851ef78ce7f9c0c6d69d5cbcbe"
Expires: 120
Contact: <sip:790XXXXX623@192.168.1.251:5060>
Content-Length: 0

[ded]

Не понимаю.
User-Agent: IP Office 6.1 (12) с адреса 192.168.1.198:5060 регистрирует (на OpenVOX?) номер 1122 через прописанный secret, так?

А User-Agent: FPBX-2.11.0(11.20.0) с адреса 192.168.1.251:5060 не может зарегистрировать (на OpenVOX?) номер 790XXXXX623 через прописанный secret,? А что отвечает OpenVOX? Что он показывает на
sip show peers ?

Что-то тут не так.

[corpse]

не может зарегистрировать (на OpenVOX?) номер 790XXXXX623 через прописанный secret,?
Что-то тут не так.

Добрый день.
Видимо я не корректно выразил мысль.
Проблема все та же:

Но на Asterisk-e, он почему-то подставляет всегда один и тот же транк (790YYYYY623)

Один из вариантов предложенного Вами решения, позволяющего однозначно идентифицировать требуемый транк, при условии что не возможности идентифицировать по IP/port:

1) аутентифицироваться при помощи username & secret

Я и привел пример, что у меня сейчас именно так, транки и регистрируются с участием username и secret, но основной проблемы это не снимает: Подставляется первый попавшийся транк из множества установленных между шлюзом и АТС.

[ded]

Если внимательно прочесать форум, то увидите, что эта проблема присутствует во многих вариантах, много раз. В основном в классической ситуации -
-- "Мне провайдер выделил 5 городских номеров, я их все зарегистрировал как 5 транков, но звонок приходит только на первый транк!"
-- "Потому что все 5 регистраций для провайдера приходят с одного и того же вашего ИП адреса и порта. И для него это один транк, а не пять. Туда и направляет, в первый из них"
-- "И что мне делать?"
-- "Разруливать по номерам DIDs."
-- "Но я прописал их в разные контексты! Мне надо их в разные стороны развести!"
-- "Контекст приёмный один, а там ставьте хоть через Goto -
exten => 9012345678,1,Goto(inbound-rom1,${EXTEN},1)
exten => 9087654321,1,Goto(inbound-rom2,${EXTEN},1) "

[corpse]

exten => 9012345678,1,Goto(inbound-rom1,${EXTEN},1)
exten => 9087654321,1,Goto(inbound-rom2,${EXTEN},1) "

Огромное спасибо за разъяснения, все стало понятно, но есть небольшая проблемка: у меня Elastix, который часть диалплана генерирует сам.
Буду признателен если подскажите или направите в правильное русло:
добавил контекст в транке context=from-gsm, добавил в него, как вы посоветовали, фильтр по номерам телефона:

Код: Выделить всё

[from-gsm]
exten => 7913XXXXX670,1,Goto(from-trunk-sip-7913XXXXX670,${EXTEN},1)
exten => 7906YYYYY623,1,Goto(from-trunk-sip-7906YYYYY623,${EXTEN},1)

Но уже в самом транке например: from-trunk-sip-7913XXXXXX670 он по сути направляет в контекст from-trunk, и ни чего не изменяет. То есть TDIAL_STRING остается такой же как была изначально на входе: SIP/7906YYYYY623-0000034e

Код: Выделить всё

    -- Executing [7913XXXXX670@from-gsm:1] Goto("SIP/7906YYYYY623-0000034e", "from-trunk-sip-7913XXXXX670,7913XXXXX670,1") in new stack
    -- Goto (from-trunk-sip-7913XXXXX670,7913XXXXX670,1)
    -- Executing [7913XXXXX670@from-trunk-sip-7913XXXXX670:1] Set("SIP/7906YYYYY623-0000034e", "GROUP()=OUT_4") in new stack
    -- Executing [7913XXXXX670@from-trunk-sip-7913XXXXX670:2] Goto("SIP/7906YYYYY623-0000034e", "from-trunk,7913XXXXX670,1") in new stack
    -- Goto (from-trunk,7913XXXXX670,1)
    -- Executing [7913XXXXX670@from-trunk:1] Set("SIP/7906YYYYY623-0000034e", "__FROM_DID=7913XXXXX670") in new stack
    -- Executing [7913XXXXX670@from-trunk:2] Gosub("SIP/7906YYYYY623-0000034e", "app-blacklist-check,s,1()") in new stack
        ...

Просто сделать транкб не работает:

Код: Выделить всё

[from-trunk-sip-7913XXXXX670]
exten => s,1,Dial()

[ded]

OpeVox засунуть в context=from-gsm,
а там написать

Код: Выделить всё

[from-gsm]
exten => 7913XXXXX670,1,Goto(from-trunk,${EXTEN},1)
exten => 7906YYYYY623,1,Goto(from-trunk,${EXTEN},1)

Соответственно во входящей маршрутизации (Inbound routes) добавляйте свои DIDs 791300000670, и там указывайте куда направить каждый из них

[murr]

ИМХО это так не разрулится.
Сначала находится неверный пир (ниже должен быть 3038 вместо 3037).
Канал создается раньше, чем пойдет обработка диалплана.

[2019-01-30 17:20:35] VERBOSE[2944][C-00001fb7] chan_sip.c: Found peer '3037' for '106' from 10.10.1.7:5060

А уже потом

[2019-01-30 17:20:35] VERBOSE[2944][C-00001fb7] chan_sip.c: Looking for 109 in from-fxo (domain 10.10.1.5)

Здесь from-fxo аналог from-gsm от ded`а, DID - 109 и ему соответствует peer 3038, т.е. второй пир на шлюзе.

Вижу проблему в следующем (верно для FreePBX и, скорее всего и для Эластикса, раз там "под кожей" FreePBX).

Если линии используются только на вход или только на выход - ее не видно.
Проявляет себя нечасто в виде вопля оператора:
"А почему я слышу "Все линии заняты, если у нас только два входящих, а линий на шлюзе четыре?"

GSM-шлюз (к примеру мой GOIP, каждая линия - отдельный транк)
Пиры
3001 - принял звонок в канал SIP/3004-ххххххх
3002 - принял звонок в канал SIP/3003-ххххххх
3003 - звонков нет
3004 - звонков нет

Исходящая маршрутизация в том-же порядке, т.е 3001-3002-3003-3004

Оператор пытается совершить исходящий звонок
Система начинает перебирать транки.
Но она определяет занятость транка в макросе macro-dialout-trunk через
exten => s,n,GotoIf($[ ${GROUP_COUNT(OUT_${DIAL_TRUNK})} >= ${OUTMAXCHANS_${DIAL_TRUNK}} ]?chanfull)
Т.е. получает количество уже существующих каналов для транка и сравнивает с максимальным количеством исходящих, заданных для транка (наверно стоит у всех единица).

Для транка с каналом выглядит так

Executing [s@macro-dialout-trunk:7] GotoIf("SIP/198-00003b15", "0?nomax") in new stack
Executing [s@macro-dialout-trunk:8] GotoIf("SIP/198-00003b15", "1?chanfull") in new stack
Goto (macro-dialout-trunk,s,33)
Executing [s@macro-dialout-trunk:33] NoOp("SIP/198-00003b15", "max channels used up") in new stack

После чего идет переход к следующему транку

Получается
3001 - есть звонок, но канал создан для другого контекста и система считает его свободным.
При обращении к пиру идет отлуп 503 "Service Unavalaible"

3002 - есть звонок, но канал создан для другого контекста и система считает его свободным.
При обращении к пиру идет отлуп 503 "Service Unavalaible"

3003 - звонка нет, но есть канал SIP/3003-xxxx, и система считает его занятым

3004 - звонка нет, но есть канал SIP/3004-xxxx, и система считает его занятым

На выходе: "Все линии заняты, попробуйте позвонить позже".
Конкретно с GOIP проблема решаема через Use Remote Party ID и trustrpid=yes (замечательно работает).
Сейчас пытаюсь победить DVG-6004S. Не получается.

[corpse]

Добрый вечер!

а там написать
КОД: ВЫДЕЛИТЬ ВСЕ
[from-gsm]
exten => 7913XXXXX670,1,Goto(from-trunk,${EXTEN},1)
exten => 7906YYYYY623,1,Goto(from-trunk,${EXTEN},1)

Честно говоря это первое, что я попробовал вчера прежде чем писать сюда вчерашнее сообщение.
Во входящих маршрутах (Inbound routes) в DID Number у меня всегда был забит номер телефона симкарты. И создано столько маршрутов сколько симкарт и сип транков для связи с gsm шлюзом. См. изображение. https://my-files.ru/se22cb
Но ни чего не помогает, лог тот же самый, если не считать, что в from-trunk передается сразу:

Код: Выделить всё

     -- Executing [791XXXXX670@from-gsm:1] Goto("SIP/790YYYYY623-00000008", "from-trunk,791XXXXX670,1") in new stack
    -- Goto (from-trunk,791XXXXX670,1)
    -- Executing [791XXXXX670@from-trunk:1] Set("SIP/790YYYYY623-00000008", "__FROM_DID=791XXXXX670") in new stack
    -- Executing [791XXXXX670@from-trunk:2] Gosub("SIP/790YYYYY623-00000008", "app-blacklist-check,s,1()") in new stack
    -- Executing [s@app-blacklist-check:1] GotoIf("SIP/790YYYYY623-00000008", "0?blacklisted") in new stack
    -- Executing [s@app-blacklist-check:2] Set("SIP/790YYYYY623-00000008", "CALLED_BLACKLIST=1") in new stack
    -- Executing [s@app-blacklist-check:3] Return("SIP/790YYYYY623-00000008", "") in new stack
    -- Executing [791XXXXX670@from-trunk:3] Set("SIP/790YYYYY623-00000008", "CDR(did)=791XXXXX670") in new stack
      ...

Буду признателен, если посоветуете куда еще покопать.

[ded]

судя по последнему логу у вас там всё правильно прибегает. Но лог короткий, только начало. И в чём сейчас то проблема?