Добрый день.
Есть связка Провайдер----E1-------Meridian(1xxx)---E1---Asterisk(2XXX).
Вопрос по маршрутизации между Meridian-Asterisk. На данный момент маршрутизация сделана через ACOD(60) - 602XXX. Есть желание сделать маршрутизиция без ACOD'a, чтоб сотрудники на Меридиане набирали "чистый" номер 2ХХХ. Понимаю, что это реализуется через NARS/BARS. Но в силу отсутствия опыта и обильного наличия 'прозрачной' документации сложно соориентироваться как это реализовать.
Просьба знающий людей соориентировать в нужную сторону и подсказать где копать решение задачи.
Благодарю.

Почитайте про CDP. Я бы реализовал задачу с помощью этого механизма.

Например, в ld 87

FEAT cdp
TYPE tsc
TSC 2
FLEN 4
RLI х - в RLI х прописываете роут который на Asterysk, а также в зависимости от того сколько цифр в DMI довавляете или отнимаете сколько нужно

Всех благодарю.
Попробую - отпишусь.

Немного почитав, попробовал сделать через CDP/DSC

REQ prt
CUST 0
FEAT cdp
TYPE dsc
DSC
DSC 2
FLEN 0
DSP DN
RRPA NO
RLI 5
NPA
NXX


REQ prt
CUST 0
FEAT rlb
RLI 5

RLI 5
ENTR 0
LTER NO
ROUT 5
TOD 0 ON 1 ON 2 ON 3 ON
4 ON 5 ON 6 ON 7 ON
CNV NO
EXP NO
FRL 0
DMI 0
FCI 0
FSNI 0
SBOC NRR
CBQ NO

ISET 0
NALT 5
OVLL 0


>ld 21
PT1000

REQ: prt
TYPE: rdb
CUST 0
ROUT 5

TYPE RDB
CUST 00
DMOD
ROUT 5
DES ASTERISK_VOIP
TKTP TIE
NPID_TBL_NUM 0
ESN NO
RPA NO
CNVT NO
SAT NO
RCLS INT
DTRK YES
BRIP NO
DGTP PRI2
ISDN YES
MODE PRA
IFC EURO
CNTY ETSI
SBN NO
NCNA NO
NCRD NO
CTYP CDP
INAC YES
ISAR NO
CPFXS NO
HNTN
HLCL
SDID NO
DAPC NO
INTC NO
DSEL VOD
PTYP DTT
AUTO NO
DNIS NO
ICOG IAO
SRCH RRB
TRMB YES
STEP
ACOD 60
TCPP NO
TARG 01 02 03 04 05 06 07 08 09
BILN NO
OABS
INST
IDC NO
DCNO 0 *
NDNO 0
DEXT NO
SIGO STD
MFC NO
ICIS YES
OGIS YES
TIMR ICF 512
OGF 512
EOD 13952
NRD 10112
DDL 70
ODT 4096
RGV 640
GTO 896
GTI 896
SFB 3


PAGE 002

NBS 2048
NBL 4096
TFD 0
DTD NO
SCDT NO
2 DT NO
DRNG NO
CDR NO
NATL YES
SSL
CFWR NO
IDOP NO
MUS NO
PANS YES
FRL 0 0
FRL 1 0
FRL 2 0
FRL 3 0
FRL 4 0
FRL 5 0
FRL 6 0
FRL 7 0
TTBL 0
ATAN NO
PLEV 2
OPR NO
ALRM NO
ART 0
PECL NO
DCTI 0
SGRP 0
ANIE 0
CAC_CIS 3
AACR NO


получаю моментальный отбой.

Я конечно не гарантирую, что все правильно понимаю, но если на Asterysk должно передаваться не более 4х цифр, то:
DSC 2
FLEN 4

И покажите что такое DMI 0

Спасибо, выставил FLEN=4 - пошли вызовы.
Но вместе с этим подтянулась другая проблема, не знаю, связана ли с настройкой cdp.
При звонках с Меридиана на астериск и наоборот -все ок. При звонке из города на номер 2ХХХ (на Астериске), Меридиан держит линию даже после того, как звонивший абонент положил трубку. Раньше такого не наблюдалось. Как cdp мог повлиять?


PRI2 LOOP 5 - ENBL
REF CLK: DSBL
SERVICE RESTORE: YES
ALARM STATUS: ACCEPTABLE
CH 01 - IDLE TIE VOD * CH 02 - IDLE TIE VOD *
CH 03 - IDLE TIE VOD * CH 04 - IDLE TIE VOD *
CH 05 - IDLE TIE VOD * CH 06 - IDLE TIE VOD *
CH 07 - IDLE TIE VOD * CH 08 - IDLE TIE VOD *
CH 09 - IDLE TIE VOD * CH 10 - IDLE TIE VOD *
CH 11 - IDLE TIE VOD * CH 12 - IDLE TIE VOD *
CH 13 - IDLE TIE VOD * CH 14 - IDLE TIE VOD *
CH 15 - BUSY TIE VOD * CH 16 - IDLE TIE VOD *
CH 17 - IDLE TIE VOD * CH 18 - IDLE TIE VOD *
CH 19 - IDLE TIE VOD * CH 20 - IDLE TIE VOD *
CH 21 - IDLE TIE VOD * CH 22 - IDLE TIE VOD *
CH 23 - IDLE TIE VOD * CH 24 - IDLE TIE VOD *
CH 25 - IDLE TIE VOD * CH 26 - IDLE TIE VOD *
CH 27 - IDLE TIE VOD * CH 28 - IDLE TIE VOD *
CH 29 - IDLE TIE VOD * CH 30 - IDLE TIE VOD *
CH 31 - DCH 12

В DMI есть CTYP.
Попробуйте поиграться с этим параметром CDP, NPA ...
Включите трассировку D-канала - возможно будет видна причина.
Хотя если не сразу звонок отбивается - это не смертельно, может через полминуты всё-таки отбивается ?

1 мин точно висит, после, сам астериск по time-ауту сбрасывает.

Debug D-channel:
DCH 12 UIPE_OMSG CC_SETUP_REQ REF 00000071 CH 5 8 TOD 15:39:54
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:49XXX64 NUM PLAN: E164 TON: LOCL
CALLED #:2041 NUM PLAN: E164 TON: UNKNOWN

DCH 12 UIPE_IMSG CC_PROCEED_IND REF 00000071 CH 5 8 TOD 15:39:54

DCH 12 UIPE_IMSG CC_SETUP_CONF REF 00000071 CH 5 8 TOD 15:39:54
PROGRESS: TERMINATING END IS NOT ISDN

DCH 12 UIPE_IMSG CC_FAC_IND REF 00000071 CH 5 8 TOD 15:39:54

DCH 12 UIPE_OMSG CC_FAC_REQ REF 00000071 CH 0 TOD 15:39:54

Со стороны звонящего (город) ложим трубку и в логах "0"

Сбрасывает со стороны принимающего абонента и в логах видим:
DCH 12 UIPE_IMSG CC_DISC_IND REF 00000071 CH 5 8 TOD 15:40:20
CAUSE: #16 - NORMAL CALL CLEARING

DCH 12 UIPE_OMSG CC_RELEASE_REQ REF 00000071 CH 5 8 TOD 15:40:20
CAUSE: #16 - NORMAL CALL CLEARING

DCH 12 UIPE_IMSG CC_RELEASE_CONF REF 00000071 CH 5 8 TOD 15:40:20
CAUSE: #16 - NORMAL CALL CLEARING

не совсем понятно для чего применяется FLEN. В моем случаи после прописания вышеуказанной конфигурации с указанием flen=4 все городские номера начинающиеся на 2ХХ-ХХ-ХХ тоже зароутились на Астериск. Предполагалось, что FLEN указывает лимит длины номера, но видимо ошибался. Пока для дозвона на город на план 2ХХ-ХХ-ХХ пришлось временно организовать через 0.
Так а на что влияет FLEN?

FLEN - нужен для определения длины набранного номера. То, что у Вас набор в ведомственную сеть и в город пересекается, говорит о бардаке на станции. Вам нужно или пригласить специалиста или разобраться в видах маршрутизации и составить соответствующую карту.

Если у Вас выход на город без "9", то тогда надо придумать как АТС будет отличать Asterysk от города. Например, назначьте "9" для Asteryskа, то есть 9ХХХ, ну и перенастройте все соответственно.
И да, FLEN 4 - воспринимает первые 4 набранные цифры номера, а остальные игнорирует.

Если у Вас выход на город без "9", то тогда надо придумать как АТС будет отличать Asterysk от города. Например, назначьте "9" для Asteryskа, то есть 9ХХХ, ну и перенастройте все соответственно.
И да, FLEN 4 - воспринимает первые 4 набранные цифры номера, а остальные игнорирует.
В очередной раз восхищаюсь Вашим желанием оказать содействие и дать конструктивный совет/консультацию. Жалко, что нельзя поставить несколько раз подряд + в карму.

По теме: с меридианом только начинаю "дружить", раньше выступал по Астериску. Вот и предположил, что для Меридиана, как и для Астериска есть разница в сравнении шаблонов _2XXX и _2XXXXXX. Выход на город осуществляется без добавочных цифр.
Исходя из этого и делал выводы, что можно прописать, например, cdp,чтоб номер формата _2ХХХ роутился на Астериск, а формата _2ХХХХХХ отправлялся по дефолтному роуту - на Оператора.

To jani4ar
Такой отзыв в три часа ночи звучит неоднозначно :D

Перепробовал разные вариации CTYP. При детальном изучении проблемы выяснилось:
1. При звонке с Меридиана(внут номер) на Астериск(внут номер) в случаи "положили трубку" со стороны звонящего Меридиан присылает
DCH 12 UIPE_OMSG CC_SETUP_REQ REF 000000B6 CH 5 29 TOD 15:11:12
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:1026 NUM PLAN: E164 TON: UNKNOWN
CALLED #:7041 NUM PLAN: E164 TON: NATL

DCH 12 UIPE_IMSG CC_PROCEED_IND REF 000000B6 CH 5 29 TOD 15:11:12

DCH 12 UIPE_IMSG CC_SETUP_CONF REF 000000B6 CH 5 29 TOD 15:11:12
PROGRESS: TERMINATING END IS NOT ISDN

DCH 12 UIPE_IMSG CC_FAC_IND REF 000000B6 CH 5 29 TOD 15:11:12

DCH 12 UIPE_OMSG CC_FAC_REQ REF 000000B6 CH 0 TOD 15:11:12

DCH 12 UIPE_OMSG CC_DISC_REQ REF 000000B6 CH 5 29 TOD 15:11:18
CAUSE: #16 - NORMAL CALL CLEARING

DCH 12 UIPE_IMSG CC_RELEASE_IND REF 000000B6 CH 5 29 TOD 15:11:18
CAUSE: #16 - NORMAL CALL CLEARING

DCH 12 UIPE_OMSG CC_RELEASE_RESP REF 000000B6 CH 5 29 TOD 15:11:18

2. При звонке из города на внешний номер который по idc пробрасывается на 7041(Астериск), в случаи отмены вызова со стороны города между оператором и
Меридианом вижу корректное завершение:
D-channel 11 - между Оператором и Меридианом
D-channel 12 - между Меридианом и Астериском
Инициализация звонка:

DCH 11 UIPE_IMSG CC_SETUP_IND REF 0000359F CH 1 2 TOD 15:52:26
PROGRESS: CALL IS NOT END TO END ISDN
CALLING #:095XXX9064 NUM PLAN: E164 TON: UNKNOWN
CALLED #:49XXXX8 NUM PLAN: E164 TON: LOCL

DCH 11 UIPE_OMSG CC_MORE_INFO_REQ REF 0000B59F CH 1 2 TOD 15:52:26

DCH 12 UIPE_OMSG CC_SETUP_REQ REF 000000BC CH 5 23 TOD 15:52:26
PROGRESS: CALL IS NOT END TO END ISDN
CALLING #:095XXX9064 NUM PLAN: E164 TON: UNKNOWN
CALLED #:7041 NUM PLAN: E164 TON: NATL

DCH 11 UIPE_OMSG CC_PROCEED_REQ REF 0000B59F CH 1 2 TOD 15:52:26

DCH 12 UIPE_IMSG CC_PROCEED_IND REF 000000BC CH 5 23 TOD 15:52:26

DCH 12 UIPE_IMSG CC_SETUP_CONF REF 000000BC CH 5 23 TOD 15:52:26
PROGRESS: TERMINATING END IS NOT ISDN

DCH 11 UIPE_OMSG CC_SETUP_RESP REF 0000B59F CH 1 2 TOD 15:52:26
PROGRESS: TERMINATING END IS NOT ISDN
PROGRESS: INTERWORKING WITH PRIVATE WORK

DCH 12 UIPE_IMSG CC_FAC_IND REF 000000BC CH 5 23 TOD 15:52:26

DCH 12 UIPE_OMSG CC_FAC_REQ REF 000000BC CH 0 TOD 15:52:26

DCH 11 UIPE_IMSG CC_SETUPCOMP_IND REF 0000359F CH 1 2 TOD 15:52:26


Со стороны города ложим трубку:

DCH 11 UIPE_IMSG CC_DISC_IND REF 0000359F CH 1 2 TOD 15:52:32
CAUSE: #16 - NORMAL CALL CLEARING
PROGRESS: INBAND INFO OR PATTERN IS AVAIL


Видно, что между Оператором и Меридианом сессия зачистилась, Между Меридианом и Астериском - Меридиан держит сессию.

В чем подвох?

Flen 4 - будет рубать 4 цифры если только на Д-канале не включен Оверлап. При Flen 0 - звонок должен был-бы пройти только по истечению тайм-аута. ИМХО напутали вы что-то с маршрутизацией. В классическом случае маршрутизации по CDP первые цифры городской нумерации, внутренней нумерации и нумерации Астериска не должны пересекаться иначе без доп. индексов не обойтись.