Тема: Transit-Out на LDK-100, всю голову уже сломал.

to Alex_Q:

Правильно ли я уповаю на то, что ваша реализация транзита работает без активации QSIG?

Ну не работает, почему то не рожна эта схема. Уже всяк искрутился. Такой вопрос: если на оконечке, в таблицах LCR указывать группу voip-каналов для транзитного кода (XYZ), то каким образом оконечка догадается на какой IP-шник транзитной станции слать набор (если только это явно не прописать в сетевом плане нумерации оконечки). Все делаю так как описал KIP, понял я его также как и Bencli и код транзитный у меня не совпадает ни с одним нумерационным планом, но НЕ РАБОТАЕТ. Я - в запой!

вот у меня такое ощущение что это только по потоку работает

сегодня вечером буду проверять

2Bencli:
Давайте всетаки раберемся с определениями - два коммуникационных устройства не могут работать друг с другом через внутренние порты - для этого нужен как минимум шлюз, но это уже больше касается SIP-протокола. Вы же насколько я понимаю, владеете классикой, т.е. H323. Поэтому общение с любым внешним устройством - только через транки. В данном случае транком у вас ямляется плата VoIB. Поэтому формула XYZ касается только исходящего направления.
Но в этом то весь и вопрос - речь идет же о транзите.  Поэтому цифры XYZ - это и есть наш маршрут, кот. прописывается в таблице 324 оконечной станции и там же указывается адрес транзитной станции, т.е. ее транковая плата VoIB. А на транзитке эти цифры в той же таблице 324 вы перенапрвляете на PSTN, т.е. уже на городские транки.
Ну вот - максимально попробовал объяснить не-KIP-овским способом.
А про PRI я не думал - там все максимально понятно.

2Товарищ Бендер: вы правы - транзит реализован без активации QSIG и все надо прописывать в сетевом плане. Боюсь, что у вас теже ошибки, что и Bencliу.
Попробуйте пока транзит без LCR, с 9. В доках это первое, что дается как пример. Помоему это наглядно показано в презентации по Networking. Добьетесь успехов здесь - потом будете экспериментить с LCR.
Удачи.

Ура 😊 все заработало

Спасибо огромное KIP’у за предоставленные идеи и спасибо Alex_Q за разъяснения - последний Ваш пост поставил все точки над “и”.

Кстати, перекрестный транзит тоже заработал, через разные естественно XYZ 😊

эх вот тока эхо на одной из станций побороть никак не могу :(( и никто не знает как

2 KIP:
Уважаемый KIP. ИМХО, Вы все-таки вводите народ в заблуждение. Как уже совершенно верно ответил уважаемый Panasonic_2002, LCR при транзите НЕ работает. Функция LCR доступна только внутренним абонентам станции. В случае Transit_Out (т.е. в случае вызовов, приходящих от другой станции) таблицы LCR не работают (это не предусмотрено в станции).
Тут, видимо, путаница в терминологии: Вы, наверное, подразумеваете под “транзитом” выход с оконечной станции на линии межстанционной связи. Но вообще-то, обычно под транзитом подразумевают саму транзитную АТС и соотвествующие транзитные операции.

Создано KIP
...LCR при транзите прекрасно работает, только точкой входа является сетевой план. Об этом я много писал на этом форуме и на IP-LDK форуме. Вообще правильно через сетевой план, но при этом не работают COS, вот и пришлось извращаться, а получилось еще лучше.

Да, но только тогда нужно пояснить, что LCR и “точка входа” находятся на разных станциях: LCR задействована на оконечной АТС, а “точка входа” (сетевой план) – это уже на транзитной АТС. Ну, и где здесь функция LCR для транзита???? Так «голову сломает» не только Товарищ Бендер.😊
Об этом Вам и написал Panasonic_2002. А все остальное верно.
Так я повторюсь: при транзитных вызовах (на самой транзитной АТС) функция LCR не будет работать, маршрутизация транзитных вызовов - только по Сетевым таблицам (ПГМ322, ПГМ324) и без всяких преобразований... Естественно, что абонентам самой транзитной АТС доступны как таблицы LCR, так и таблицы Networking.
Вовсе не умаляя значение проделанной Вами работы, все-таки хочу заметить, что “открытия” в обнаруженных Вами функциях станции нет. В доке действительно впрямую не описано, но вполне подразумевается (описать ВСЁ -невозможно).
Транзитной АТС (начиная с версии 2.2) совершенно наплевать на то, каким образом сформирован код «Transit_Out» на стороне оконечной станции: через таблицы Networking, с помощью LCR или просто набрано «ручками». Лишь бы только принимаемые транзитной АТС цифры соответствовали прописанным в ПГМ324 кодам для транзита (Code Type=PSTN). Именно поэтому для транзитной LDK не имеет значения, какая АТС используется в качестве оконечной. Это может быть вовсе не LDK и вовсе не LG (давным-давно это успешно использовано на практике). Но при такой схеме можно использовать только линии PRI для межстанционной связи, поскольку LCR не позволяет использовать каналы VoIP.
Кроме того, один и тот же код может быть прописан и как вход в LCR и как транзитный код. В этом случае для внутренних абонентов будут срабатывать таблицы LCR, а для транзитных вызовов (от другой станции) – сетевые таблицы, с соответствующей маршрутизацией.

Возможно, я ошибаюсь, т.е. если я не до конца понял суть описанного Вами метода  – тогда поясните более детально ваш передовой опыт (желательно нарисовать схему, поскольку слова могут быть восприняты неоднозначно).

2 Alex_Q:
Корейцы об этих возможностях знают, именно поэтому вариант транзита на первых версиях LDK (аналогичный транзиту GDK-162) был заменен на нынешний, да и сделали это не своей воле - спасибо Европе...Но до функциональности нормального транзитного узла станциям LDK еще очень далеко...(впрочем, они на это и не рассчитаны).

С уважением, harris

Добрый день всем участникам.Я не ожыдал такой бурной реакции на моё сообщение,и не пытался дать рекомендации,просто описал вожность решения проблемы.Конкретные рекомендации я давал тем,кто присылал *.USR файлы станций. Таким образом решал несколько задач:1- организация выхода на внешние линии через любую станцию с рабой Cos,т.к.при организации через сетевой план Cos не работают;2-выход на внешние линии через другую станцию при занятости или недоступноти своих.                                                              To Harris:я очень благадарен за уточнения и пояснения,и никаким образом не пытаюсь присвоить открытие этих возможностей станции,прсто привел один из вариантов решения этой задачи.Я занимаюсь эксплуатацией АТС на крупном промышленном предприятии расположеном на перифирии и информации у меня намного меньше чем в сервисных центрах,а получить конкретные рекомендации удаленно из сервесного центра не обладая полной информацией -просто не реально,вот и приходится заниматься поиском.

Для Товарища Бендера:

Это план программирования Transit-Out, который вчера у меня заработал 😊

141 pgm
CO (АТС 1) - группа 1,
СО (АТС 2) - группа 2

Возмем номер XYZ – свободное 3-х значное число, которое НЕ должно быть прописано в плане нумерации, например в моем случае это 333

АТС 1(оконечная станция, c которой будут выходить на СО другой АТС при занятости своих линий )

LCR Access(pgm 220) – enable

pgm 221
index 0
LCR TYPE- INT
LCR code -9
DMT -1

pgm 222
index 1
Number of Remove - 1
CO Line Group - 1
Alternative DMT Index - 2

index 2
Added Digit – 333
Number of Remove - 1
CO Line Group – 2

На этой же АТС 1:

324
System usage - PSTN
Numbering plan code - 333
NET CO group – 1
Digit Repeat – on
CPN/IP info – например 192.168.***.***(IP транзитной АТС 2)

АТС 2(транзитная)

pgm 322
CO 1-N будут в PSTN
Net group - 2

А в pgm 324
System usage - PSTN
Numbering plan code – 333
NET CO group – 2

Соответственно, если нужен транзит еще и в другую сторону, то естественно нужно выбрать другие XYZ отличные от плана нумерации, и проделать все эти же операции в точности да наоборот.

Делай и проверяй 😊)

2 KIP:

Коллега, я вовсе не хотел Вас чем-нибудь “зацепить” или обидеть. Вы действительно самостоятельно нашли решение, которое нигде впрямую не описано. Я тоже совершенно не претендую на роль первооткрывателя. (Приритет за корейцами:) ).
По вашим ответам на форумах вполне очевидно, что Вы профессионально, на очень хорошем уровне освоили оборудование LG. Примите мое искреннее уважение. Если же мое предыдущее послание было с излишней долей иронии, то прошу пардону (грешен - порой прорывается...).
Целью моего послания было совсем иное: объяснить необходимость более четких формулировок, пояснений в вопросах и ответах... Иначе это приводит к неоднозначности. Например, упоминание о том, что “LCR работает при транзите”, заставило меня (а возможно и других) в очередной раз проверять наличие такой возможности, поскольку я понял эту фразу “в лоб”. Корейцы отказались измененить ПО так, чтобы LDK отрабатывала таблицы LCR для транзитных вызовов. Но кто их знает..., поэтому я и проверил. Увы!
По поводу информации: сервис-центры так же, как и Вы, вынуждены накапливать достаточно большую часть информации по крупицам на основе собственного опыта и ошибок. Им, конечно, проще, поскольку перидически есть возможность получить информацию из “первых рук”, но это не всегда выручает... У меня за спиной тоже не стоит кореец... (а жаль, :D ). В общем, все познается на практике.
Успехов!

2harris: благодаря таким исследователям как KIP продукция LG не пасет последних. Это лично мое мнение и хотелось бы знать мнение и остальных.
Да это решение нельзя назвать чистым для транзитного LCR. Но какая разница потребителю – есть у него «чистый» транзит LCR или нет – ему надо звонить без 9 на «оконечке» так же, как это делают на «транзитке» - и он это делает благодаря взаимодействию настроек LCR и таблицы 324.
Теперь скажите – разве это не решение!?
У меня решение KIP`а работает и я доволен, а пользователь и не подозревает, каким дорогим оно могло бы ему обойтись, если бы пришлось выполнять его на другой платформе (не говорю уже про S8700).
А вам надо доступно передать корейцам эту информацию и поведать, чего народ хочет – по-моему в этом и заключается «обратная» дистрибьютерская связь (упаси бог – я вас не учу, просто хочу еще раз напомнить, что мы выбрали эту платформу, и нам не безразлично более расторопное ее продвижение). Будет это решение более прозрачнее строиться – кто-ж будет возражать. Но то что оно сегодня нужно – вот вам ответ.
Вот если-бы еще VOIB более интегрирована была с MPB, а то у меня до сих пор то решение по Transit-IN жрет 2 канала VOIB – жаба давит, в межстанционной они же не учавствуют.

2KIP: ТАК держать!

С уважением, Alex_Q.

P.S. Когда был набран текст, увидел упреждающий ответ Harris`a, но наверное дело не в нем, затронута важная нота взаимодействия в цепочке “разработчика-поставщика-инсталлятора”, а механизмов, кроме форума, не видно, по-этому думаю пусть лучше высветится...

Создано Alex_Q
Да это решение нельзя назвать чистым для транзитного LCR. Но какая разница потребителю – есть у него «чистый» транзит LCR или нет – ему надо звонить без 9 на «оконечке» так же, как это делают на «транзитке» - и он это делает благодаря взаимодействию настроек LCR и таблицы 324.
Теперь скажите – разве это не решение!?

2 Alex_Q
Коллега, зря Вы так горячитесь.
1. Никто не оспаривает право на существования такого метода выхода на линии межстанционной связи: не через сетевые таблицы (Networking), а посредством таблиц LCR (или любым другим способом). Тем более, что так и было задумано разработчиками... Я Вам уже ответил, что именно с этим связана замена старого протокола QSIG на новый (начиная с версии 2.2).
2. Вы вправе настроить станцию так, как считаете наиболее удобным.
Я же обратил внимание на неправильную формулировку, которая многих вводит в заблуждение или просто в “ступор”.
Извините, но вот, например, Вы опять упомянули “транзитный LCR” - как это понять??? Что это??? Это выполнение функций LCR на транзитной станции??? LCR для внутренних абонентов транзитной станции??? LCR для транзитных вызовов на транзитной АТС???
НЕТ! Оказывается, Вы, в соответствии с пояснениями уважаемого KIPa, имеете в виду функции LCR НА ОКОНЕЧНОЙ АТС, посредством которых выполняется выход на линии межстанционной связи (т.е. на транзитную АТС).
Прочитав это, многие начнут рыться в доках в поисках “транзитного LCR” и крыть матом “бестолковых” корейцев за отсутствие описания оного.
Или как понять «благодаря взаимодействию настроек LCR и таблицы 324»? Какое такое ВЗАИМОдействие?? Это в одной станции или в разных??? 
Конечно, я преувеличиваю, но…разговор идет о терминах и грамотных, понятных формулировках... Иначе можно окончательно запутаться.
3. Дистрибьютеры и Представительство LG и так нагружают корейцев информацией. Но результат в большей мере зависит не от дистрибьютеров, а от планов и возможностей разработчиков. Кроме того, “народ” хочет очень многое и подешевле..., и при этом “народ” тоже разный и зачастую одно требование противоречит другому.
Если есть какие-то требования, пожелания по станциям - пишите дистрибьютерам. Часть проблем, которые встретились непосредственно на форумах, удалось “донести” до корейцев, что-то уже решено... В меру сил, так сказать...

2 KIP:
Кстати, а что за проблема была у Вас с COS’ми?? Я проверял работу запретов по COS на оконечной станции при маршрутизации по таблицам Networking - вроде все нормально работает...

2 harris:
Спасибо за ответы, но горячиться и не думал. Идет нормальный диспут, а в нем, как известно, рождается истина. Насчет «транзитный LCR» извиняюсь – не поставил кавычки, наверное в спешке.
Вот удручает на форуме частая “полутехническая” лексика  вперемешку со сленгом - это да, с этим надо что-то делать. Иначе уважать перестанут.

Создано Alex_Q
...Вот удручает на форуме частая “полутехническая” лексика  вперемешку со сленгом - это да, с этим надо что-то делать... 

Полностью согласен!

Добрый день.На форуме идет нормальная дискуссия,мы делимся опытом,и сами учимся.Никаких обид быть не может.Хочу затронуть ещё одну тему,которая прямого отношения к этой не имеет.Я не консерватор,но пока для нормальной работы межстанционной связи признаю только PRI.IP-считаю просто “приложением” при безвыходном положении,либо как временное решение.Основания говорить так у меня следующие:у меня 4 LDK-300 соединенные по PRI.К комп.сети подключены по LAN MPB для администрирования.Одно время у меня начали периодически блокироваться потоки,это исчезло когда я отключил LAN.Тогда я особого значения этому не придал.Но вот недавно у меня ночью остановились все станции,в прямом смысле остановились,MPB-стоп.Запустил я станции отключив LAN.Причем при остановке станции все состояния трактов сохраняются,а при отключении LAN станция прдолжала работу,но уже с “глюками”.Сброс станции при отключенном LAN-станция начинала работать в нормальном режиме,но при подключении LAN через некоторое время сначала блокировался поток,затем MPB-стоп.Выяснилось всё через несколько часов.Одна компания ,копорая на предприятии занимается консалтингом,подключила к сети свой ноутбук,он и “посадил” всю сеть(сетью занимается отдел информационных технологий).Все это время отключив LAN мои станции работали без проблем.При непрерывном цикле работы предприятия и “политике”руководства,если бы межстанционная связь была через VOIB я был бы уже безработным.

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

Спасибо за поддержку. И я того же мнения. Скажу более – как «прилежные ученики мы должны прислушиваться к совету старейшин ..» (не помню откуда это, толи с древних манускриптов, толи с клятвы пионера...)

Создано KIP
Я не консерватор,но пока для нормальной работы межстанционной связи признаю только PRI.

И я не консерватор. Но жизнь поставила перед выбором - ставить межстанционным соединением классику, т.е. PRI, при этом покупать дорогие мультиплексоры для оптики (Е1-Ethernet-оптическая среда), которые в дальнейшем не пригодятся никому, или довериться уже шлифующемуся техническому решению VoIP, который дальше использует более-менее стандартную обвязку Ethernet. С учетом мнения заказчика остановились на последнем варианте. И ... после многих дней и ночей страданий внедрения .... я об этом не жалею.

И вот почему:
во 1-ых - вместе с внедрением такого вида корпоративного соединения открылись сильные и слабые стороны станции, сразу стали понятными многие принципы работы станции. Слабой стороной VOIB считаю прошитый в ней BIOS, поддерживающий стек протоколов H.323 ver.2 (явно недостаточно «фичей» для полноценной работы в сети). В VOIBE уже кажется поддерживается H.323 ver.4 – но возможность оценить разницу как-то еще не была предоставлена.

во 2-ых - само соедиение VoIP более-менее мониторится благодаря стандартным протоколам TCP/IP и разнообразным примочкам, связанным с этим действием (чего не скажешь про PRI - сразу покупай анализатор-дешифратор для Е1, хотя сейчас уже вроде есть внутренние средства станции для мониторинга потока, но все равно нужен дешифратор, а это опять либо «железо», либо на поклон к производителю).

в 3-их - благодаря правильной настройке сети все платы VoIB при желании мониторятся извне, поэтому (и не только...) организация отказалась от необходимсти иметь в своем штате лишнюю единицу - администратора станции – немалый плюс для малых предприятий. Собственно, качество станций на сегодня не отстает от качества компьютеров, и те классические функции, которые раньше выполнял стандартный коммутатор, после настройки эти станции выполняют безукоризненно. Поэтому, как встречается в нашей рекламе – навищо платыты зайви гроши.
А есть и другой пример – организация имеет целый штат телефонистов, а обращается к нам за анализом в случае «падения» потока!

Считаю, что ISDN вынули из тумбочки и отряхнули от пыли благодаря волне компьютеризации и росту качества компьютерных, а за ними и телефонных сетей.
И удачно... Но кто-кого должен «тянуть» в условиях создания сетей следующего поколения (я об NG) – это пока еще вопрос времени, и, наверное не нам его решать.

И вообще, тема будущего – это удел фантастов. Наверное только они от этого получают полный комплекс удовлетворения, а иногда (к сожалению только иногда успеваем фильм засмотреть ) и мы ... от их творчества.
Посему, придадимся мудрости разработчиков и будем их ловить на мелочах – вот собственно то, что мы можем сделать сегодня на этом форуме.

Лично я буду выбирать то решение, которое для данного случая экономически и технически будет оправданным – благо у LG есть выбор, а у меня есть какой-то опыт. И это меня радует. А тому, кто думает иначе – не смею даже возражать…

P.S.  2 KIP
Я правильно понял идею темы... , коллега?
А то, что у вас «зашивалась» компьютерная сеть, коллега, так это наверное либо от отсутствия администратора  сети, либо от ненадлежащего исполнения им обязанностей, либо сеть вообще неправильно построена. Обратитесь к профессионалам – слава богу специалистов по компьютерным сетям много больше нашего брата...
Правда из них действительных немного. Но это уже другая история...

Да, и еще...
Давече мне позвонил друг из Японии, слышимость была как буд-то рядом из соседнего кабинета. Я даже обалдел, думал что он приехал. Угадайте с 3-х раз – по какому каналу он звонил – ЯЯ, по тому-же злощастному VoIP, выбирал и проверял провайдера, как он мне объяснил.
Так что пока мы тут пытаемся „опустить” нетрадиционные виды связи, они там „паразиты ... стыдно сказать,..... деньги зарабатывают без ущерба для клиента”.

И еще... Может я где-то и ошибаюсь, и действительно есть глюки в LAN MPB, тогда надо более детально описать ситуацию, не мне вам рассказывать как ...

YESS! ЗАРАБОТАЛО! Всем откликнувшимся - КIPу, harris’y, Alex’y и др. огр. спасибо. Bencli - особый респект, за подробный текст.