Тема: Помогите с транзитом через LDK 300
Доброго времени суток всем! Образовалась проблема с транзитом через LDK 300. Ситуация следующая: есть станция LDK 300 и 4 станции GDK 162, объединенные в офисную тел. сеть. LDK 300 соединена с 2-я GDK 162 по потоку Е1. LDK 300 версия GS30P-3.8Bf, GDK 162 одна версии 5.5Ек, другая 5.5Fp, по остальным станциям вопросов нет. Нумерация трехзначная на LDK-c №100, GDK 162(офис2) с №200, GDK 162(ЭРК) с №600. Звонок с GDK 162(офис2 5.5Ек) на GDK 162(ЭРК 5.5Fp) через LDK проходит, а с GDK 162(ЭРК 5.5Fp) на GDK 162(офис2 5.5Ек) нет- после набора номера идет сигнал занятости. Хотя на LDK 300 из ЭРК связь работает. Просмотрел программы обеих GDK 162 криминала не нашел. Опыта у меня маловато, пишу первый раз(тапками не кидайте 😊 ), если не трудно, посмотрите пожалуйста бэкапы. Они лежат по адресу:
http://zalil.ru/32334750
http://zalil.ru/32334775
http://zalil.ru/32334780
1) В ПГМ321/1 (Net Transfer Mode) нужно убрать Reroute и поставить значение= JOIN.
2) В ПГМ322: удалить линии СО139-146 из NET CO GRP 3. Эти линии относятся не относятся к потоку PRI в офис 2 (там только СО109-138), а относятся к плате LCOB в слоту №7. Поэтому для СО139~146 нужно в ПГМ322 указать тип PSTN и номер группы удалить или поставить =0.
Уважаемый Harris, спасибо за быстрый ответ, сделал исправления, как Вы подсказали, но по прежнему транзит идет только в одном направлении с №200 на №600, с №600 на №200 после набора номера - отбой.
Я правильно понимаю, что вызов с 600 на 100 (на LDK) проходит нормально??
Да, Вы правильно понимаете, вызов с №600 на №100 проходит нормально
Стоп!!! А чего это у Вас планы нумерации в LDK и в GDK (ЭРК) пересекаются???
У Вас в LDK нумерация групп абонентов = 650~667, а сетевая нумерация GDK (ЭРК) = 6** !!
Это неправильно.
Поменяйте нумерацию групп абонентов в LDK в ПГМ106/1 = *650~*667 (добавьте * в номер группы).
Поменял, не помогло. Если я правильно понимаю, то перезагрузки станции не требуется?
Нет. Перезагрузка не требуется.
Попробуйте, изменить CO-to-CO COS в ПГМ166. Там сейчас =COS7. Класс сервиса COS7 вроде не должен препятствовать транзитным сетевым вызовам (типа Net-NET), тем более, что вызовы от 200 на 600 нормально проходят, но... все-таки лучше это проверить.
К сожалению, я сейчас врядли смогу просмотреть конфиги от GDK, чтобы понять как там настроено посылка номера и АОН...
Это нужно с установкой GDK AdminPro возиться...
И неплохо было бы посмотреть трассировку этого проблемного вызова.
Спасибо Harris, попробую завтра сделать изменения, сегодня меня из офиса уже попросили, сказали что так я все деньги заработаю, если буду до ночи сидеть. Ещё раз большое спасибо за помощь, ну а на счет трассировки вызова попробую разобраться как это делается, т.к. я этого ни разу не делал.
Мдя... У Вас повременка что ли??? 😊
ОК. Я попробую посмотреть конфиг GDK на старом компе. Там вроде AdminPro должен работать.
Ну я все-таки смог открыть конфиги станций GDK на старом компе (Win’98). К сожалению, у Вас в станциях не установлен модуль доп. памяти MEMU/SMEMU, поэтому в файле конфига нельзя посмотреть настройки LCR. Т.е. я не вижу, используете ли Вы таблицы LCR (ПГМ07) для вызова абонентов в других станциях или нет.
Поясните, как именно абоненты станции GDK (ЭРК) вызывают абонентов GDK (офис2) и абонентов LDK??
Они набирают просто 200 (100) или через 9-ку (9200 и 9100)??
Если набирают без 9-ки просто 200 (т.е. используется LCR), то тогда нужно очистить нумерацию абонентских портов, которая была назначена по умолчанию. Вы назначили нумерацию абонентов 600~647. Но на остальных абонентских портах остались номера по умолчанию: 148~291 !!!
Набирая номер 200 вызов не поступает в станцию LDK, а остается в станции GDK (ЭРК). Станция пытается отыскать внутри себя абонента №200, но у Вас физически его нет (нет платы). И станция дает отбой.
Поэтому нужно на абонентских портах удалить номера 148~291 (в ПГМ01/1), оставить только номера 600-647.
Доброго Всем времени суток! Уважаемый Harris я извиняюсь за отсутствие, но на работе у меня связь не единственная нагрузка. Сегодня почти весь день занимался другими делами.
Теперь по порядку: поставил COS1 в ПГМ166, ситуация без изменений. LCRы я использую, на GDK ЭРК можно посмотреть.
Набор происходит без 9 набором 100(200), также и на станции офис2 LCRы используются. Вроде бы работает нормально.
При наборе номера 100(200) из ЭРК я на дисплее вижу чтовыбирается нужная СО ( например 46), на номер 100 соединение проходит, а на 200 происходит отбой, причем, что интересно если я набираю при нажатой клавише MON то после набора номера проходит короткий “БИП” и дальше тишина, при поднятии трубки идет полноценный отбой. Не знаю есть ли в этом криминал. План нумерации в ЭРК(GDK 162 5.5Fp) я исправил. Но там были порты и с номерами на 1, но соединение на LDK проходило. Сейчас нумерация заканчивается №647. Но ситуация остается прежней-набор из ЭРК в офис2 через LDK не проходит. 😕
ОК. Посмотрим на конфиг LDK-300.
Мдя... Как то неаккуратно станция запрограммирована!!
- В ПГМ105 не удалены номера абонентов 200~399!! (Так же, как было в GDK (ЭРК)!!) Это необходимо очистить!
- в LDK-300, Вы тоже используете LCR. Зачем?? С какой целью??
И там тоже в ПГМ221 прописаны LCR коды 2 и 6, причем эти коды указаны как тип BOTH, т.е. они отрабатываются и как COL и как INT!!!
Т.е. у Вас не работает таблица Networking (ПГМ324).
Так вот коды INT - это посути расширение плана нумерации станции, причем с самым высоким приоритетом.
Приоритет:
INT LCR (ПГМ220-222) -> Numbering Plan (ПГМ106-107) -> Networking Table (ПГМ324) !!!
Для транзита нужно, чтобы коды 2 и 6 были прописаны ТОЛЬКО в таблице сетевой нумерации (ПГМ324) !! .
Не должно быть INT (или BOTH) LCR кодов “2” и “6”.
Иначе получается, что ВЫ звоните из станции LDK в станции LDK не за счет использования сетевых таблиц (сетевой машрутизации), а за счет маршрутизации по таблицам LCR.
Т.е. путаница в нумерационных планах (вообще удивительно, каким образом сейчас проходит вызов от 200 к 600 ??!!!!)
В станции LDK нумерация должна быть прописана:
- ПГМ105 - только номера 1ХХ
- ПГМ324:
1#** (NET CO GRP 0)
2**
6**
И не должно быть INT (или BOTH) LCR кодов = 1, 2, 6 (могут быть коды 1, 2, 6, но только типа COL, если это требуется).
Здравствуйте Всем! Уважаемый Harris, станцию запускал не я, а сторонние специалисты. Я только пытаюсь ее эксплуатировать, ну и заодно потихонечку осваивать. Может я сразу не описал всю конфигурацию тел.сети и поэтому создал Вам некоторые трудности. Сначала пять станций GDK162 , были объединены по физическим линиям, затем в головном офисе заменили GDK на LDK 300 и организовали поток Е1 между офисом 1, 2 и ЭРК. С остальными двумя станциями остались связи по физическим парам, поэтому наверное и появляются всяческие заморочки. Три станции GDK находятся на территории НПЗ, км примерно 5 от меня, сейчас еду в ЭРК скачаю Бэкап, и приеду назад править программу на LDK как ВЫ подсказали. Еще раз огромное спасибо за терпение и внимание к “чайнику”. 😊
Уважаемый Harris, приехал с завода, исправил план нумерации на LDK, не редактируя LCRы, и транзит заработал 🐛 . Но судя по Вашему посту, транзит заработал не “потому,что”, а “вопреки”. Сегодня сделаю перекур, спишу бэкап, а на следующей неделе буду причесывать программу по Вашим рекомендациям. Ещё раз огромное спасибо за помощь!!!
Просто нужно разобраться с LCR в станции LDK.
Для какой цели прописывали 2 и 6 в LCR?? Чтобы абоненты LDK могли выходить на абонентов станций GDK??
Так абоненты LDK могут звонить на GDK через Networking Table!!!
А у Вас получилось, что маршрут к станциям GDK указан дважды: в LCR и в Networking Table.
При этом для абонентов LDK срабатывает именно LCR, поскольку LCR имеет приоритет.
Что касается “вопреки”, то тут есть “разгадка”:
При входящем вызове станция не проверяет коды INT LCR (и не должна делать этого). Однако она проверяет в первую очередь Num Plan, и только потом Networking Table.
Поэтому:
Случай 1: при вызове от 600 на 200 станция проверяла нумерацию собственных абонентов (ПГМ105) и находила там абонента 200, на которого и пыталась направить вызова. Но у Вас физически нет такого абонента (нет платы). Поэтому LDK отбивала вызов.
Случай 2: при вызове с 200 на 600 станция проверяет свой нумерационный план и НЕ находит там номер 600, поэтому она далее проверяет Numbering Plan, находит там 6** и отправляет вызов транзитом в GDK.
Но.. если бы набирался номер 650~667 (а у Вас эта нумерация приписана к Hunt-группам), то вызов ушел бы на соответствующую группу абонентов (если она реально назначена) или был бы отбой (аналогично Случаю 1).
Все работает согласно заявленному производителем алгоритму. Просто нужно четко понимать его и не оставлять в программе “незачищенных хвостов”... Всему есть свое объяснение. Ну, в-общем, в итоге разобрались... 😊.