Как можно прописать в системный SPD набор номера по определенным направлениям PSTN из сетевого плана нумерации.
Например, в сетевом плане прописано направление по "5"ке выход на IP-направление через VOIB.
Как можно указать при программировании SPD что надо набирать номер по этому направлению.

LDK300, вер. 3.6Df

Пробовал через Speed Editor, но что-то по указанию NET заставить его работать не получилось.

да действительно при указании NET в Speed Editor в системе эти поля оказываются просто пустыми

работает как не странно обычным образом - указываем или непосредсвенно CO или Grp CO, а в поле номера предворяем сам номер цифрами из сетевого плана нумерации

Внимание вопрос вышестоящим что в Speed Editor делает NET?

Да. Это работает, но есть одно "но".
В наборе уходит и префикс выхода на направление.
Digit repeat стоит в off.

Если тип линий указан как NET, то вместо СО/CO Gr. должен быть указан индекс ячейки (т.е. номер строки) в сетевой таблице (ПГМ324), в которой прописан нужный сетевой код выхода на PSTN.
К примеру: Если код 5 прописан в ПГМ324 в ячейке №8, то в SPD Editor'е нужно было бы прописать тип линий=NET, а вместо СО указать -8.
Но видимо, к сожалению, это так до конца и не сделали... Не работает!
Кстати, а на каких версиях ПО Вы сейчас экпериментируете со SPD-ячейками???

Мне собственно, не нужно, но только что попробовал на 3.5Bk - не работает!

Это не работает...
Но путем долгих экспериментов было понято, что при указании COGrp в SPD-ячейки, выбирается первая попавшаяся запись из ПГМ 324 в которой указано направление PSTN для линий из этой группы (COGrp) и по ней делается набор без всяких префиксов... Соответственно digit repeat тоже не отрабатывается.

Нет, никакая "первая попавшаяся запись из ПГМ324" не выбирается. Указание NET в SPD-ячейке не сохраняется. При записи в ячейку кода Net Transit Out (в вашем случае=5), этот код воспринимается как набор кода LOOP (если CO/COG не указано), он попросту отбрасывается, остальные цифры уходят в набор. Выбора направления по таблице Networking не происходит, соотвественно и нет никакого Digit Repeat. Зато можно задействовать LCR и добавить нужные цифры...

Теперь и я понял, почему мне приходилось группы NET и СО делать одинаковыми, когда нужен был транзит через SPD-ячейки - просто в этом случае работал LCR.
Спасибо и на том.

Не сочтите за "дятла", но этот факт еще раз доказывает, что ядро менять надо.
Просто хочется чтобы все было по уму, а не косо-криво...

Менять ядро фактически означает изменить полностью весь софт. Это нереально.
ИМХО, можно и в рамках существующего ПО довести станцию до нужной кондиции, тем паче что она (станция в целом) и в настоящий момент вполне даже неплохая... Просто требуется сгладить некоторые шероховатости. А где их нет????

Я бы отсутствие логики в маршрутизации, пусть даже и частичное, "некоторыми шероховатостями" не называл!
Вы заметили, что большая часть серьезных вопросов на этом форуме касается именно маршрутизации?!
Серьезными я считаю вопросы, на которые нет однозначных ответов, но через нерешение которых нельзя перепрыгнуть.

А Вы заметили, что в основном эти станции пытаются применить для случаев, для которых они изначально не предназначены???
Я же считаю, что в целом логика в маршрутизации есть, иначе бы никто ничего не смог запустить. А большинство с задачей справляется. Значит уже не все так плохо. Значит остаются только "шероховатости".
Кстати, я уже задавал вопрос о готовности платить за станции в 2 раза больше при наличии нового ПО. Ответа на этот риторический вопрос я не получил.
ИМХО, нет смысла спорить по этому вопросу. Форум все равно такие вопросы не разрешит. Об обнаруженных проблемах нужно писать дистрибьютеру.
Нету в мире совершенства

Мои клиенты готовы платить за плату процессора в 2 раза больше, если там будет реализована прозрачная маршрутизация!!!

Ну, тогда осталась самая малость - уговорить разработчиков...
Уважаемый Alex_Q:
Вы же не первый год занимаетесь станциями LG, Вы весьма квалифицированный и опытный спец.
Неужели для Вас маршрутизация LDK так уж непрозрачна??? A положа руку на ... Руководство по программированию????
Так давайте не будем нашими дебатами сбивать с толку и отпугивать от этих станций остальных пользователей, участников форума... Если есть неоходимость продолжить это обсуждение, то лучше пишите мне в личку или позвоните...

Игорь, и вот каким боком моя задача выходит за рамки традиционного применения моей станции ?
Задача в следующем: Есть несколько направлений PSTN(поток, VOIB, CO), выбор которых должен осуществляться прозрачно для абонентов и с учетом требований вышестоящих операторов и еще при этом желательно не потерять функционала станции. Имхо вполне разумное требование с учетом того что LDK претендует на приставку "IP". Или эта приставка по мнению разработчика означает только возможность подключения IP-фонов ? А все остальное это "завышенные требования" ? Здесь не идет речи о транзите, о сети станций, QSIGе, каком либо допсервисе.
Почем тот же LCR, NetPlan и SPD прекрасно работают на потоке, но вот с VOIB увы недодумано... Точнее даже наверное недоделано.



Да, но это дается путем долгих экспериментов по изучению этой логики... И шаг влево, шаг вправо грозит "расстрелом". Как правило поиск решения сводится к поиску обходного решения очередных странностей логики LG.
При этом никто не отрицает нескольких параметров LG, которые позволяют им занимать определенную нишу рынка: цена, надежность, гибкость.
Вы, как человек знающий эти станции до "мозга костей", можете предоставить строгий алгоритм работы логики обработки исходящих вызовов ?



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

PS: И при всем при этом мне LDK нравится гораздо больше чем тот же панас. "Мыши плакали и кололись, но продолжали жрать кактус" (с) )))

И в каждой шутке есть доля шутки...


Спасибо за комплемент.
И я не забыл, как Вы мне помогали "тащить бегемота из болота".
И KIP-у спасибо за его експериментальные наработки, и до сих пор его приемчики работают...

Но вот беда - не ставя в течение полугода подобного решения ты забываешь все эти штучки и ухищрения. Я то не забыл... А вот, почитав лишь одно руководство, человек, впервые видящий такую станцию, но с упрямством и техническими навыками...
Ох, сомневаюсь я, что он ей лад даст.
Да и у спецов, вижу по форуму, есть непонятки ... а "зарываться" в форум не хотят.
Хотят чтобы все было на "ладони".


Я и не думал об этом.
По себе знаю, только специалист поймет о чем речь, а начинаюий мимо ушей пропустит.
LDK - станция многофункциональная.
Наоборот, после ознакомления с ее гибкостью как-то в Самсунгах ковыряться не хочется, не говорю уже о Панасониках.

1. Ну, это не комплемент, а констатация факта.
2. "Почитав лишь одно руководство, человек, впервые видящий такую станцию, но с упрямством и техническими навыками"... - естественно, не сразу во всем сможет разобраться. Нужно время, пратика, опыт. В конце концов, для этого и существуют курсы тренинга (обучения) в компаниях-дистрибьютерах. Невозможно написать документацию, которая ответила бы на все вопросы, удовлетворила бы людей с разной предварительной техн. подготовкой и опытом...Да еще требуется, чтобы дока была написана в форме Учебника, а не Справочника. Попробуйте почитать доку на Definity - там вообще с нуля самостоятельно невозможно разобраться... (ИМХО,куча документов, не связанных между собой логикой изложения материала, чисто справочное руководство) Но в целом, я, конечно, согласен, дока должна постоянно совершенствоваться - ну, вообщем- то так и происходит, но наверное медленнее, чем того хотелось.
Непонятки остаются у всех..., даже у разработчиков...
OK. Заканчиваю литературное отступление, пора поковыряться с очередными "непонятками".

Мы вунуждены курить траву чтоб понять что написали эти алкоголики

Я как раз из таких, из любопытных и с техническими навыками. По образованию вообще никаким боком не стоял к гражданской связи и АТС. Был локаторщиком.
На АТС ipLDK-300 версия 3.6Са, а толстая книжка по программированию думаю для версии 3.5. Некоторые вопросы программирования подсматривал в проге ARIA SOHO. Думаю, что там некоторые моменты описания как раз для версии 3.6Са

так скачайте доку 3.6

А действительно, что мешает скачать??? Можете скачать даже на 3.7!

[quote name='Alex_Q' date='Mar 15 2007, 02:47 AM' post='2979']
Но вот беда - не ставя в течение полугода подобного решения ты забываешь все эти штучки и ухищрения. Я то не забыл... А вот, почитав лишь одно руководство, человек, впервые видящий такую станцию, но с упрямством и техническими навыками...Ох, сомневаюсь я, что он ей лад даст.
Да и у спецов, вижу по форуму, есть непонятки ... а "зарываться" в форум не хотят.Хотят чтобы все было на "ладони"[quote]

Больные места у LDK где были у 2.x там у 3.5 и остались; эти 2 беды убивают все прелести:

1. Когда в PGM322 NET CO больше чем каналов от модулей VOIU (нужны и транзиты и внутрикорпоративка) часто случаются односторонние соединения как в старых версиях с PRI
2. VOIB жрали по 3 метра в час даже ночером

Сейчас между платами софтсвич (Н.323-SIP2.0); транзиты и схлопывания Tromboning(Н.450) трюками, зато без всяких "чудес" когда минимум 30% соединений по любому маршруту односторонние: один говорит- второй слушает, а чтобы наоборот то перезванивают несколько раз

Такой войп никому не нужен: знал бы сразу- воткнули бы PRIB в нормальный астериск и не тратились БЫ на эти VOIB которые абсолютно неликвидны. Астериксы тоже бывали всякие, но их можно пересобирать и перезагружать хоть трижды за ночь и всё начинает работать как надо. А лыжа своими VOIB зарекомендовала себя так что впарить такие платы некому

2 dvs///
День добрый...
Нуууу...
Во первых если у Вас в центре софтсвич, я могу предположить что работа происходит в СИПе...
Тогда Вы наверное должны знать, что вер.3.5 ТУГО дружит с этим протоколом ( что в действительности касается и Н323 )...Попробуйте поднять вер. атс...
Во вторых где уверенность что в односторонней слышимости виновата атс ( а не канал-к примеру )..
В третих, я конечно не большой спец...но потоков настроил на Лыже наверное с добрых 5-6 десятков ( причём и для провайдера в качестве ТРАНЗИТНОЙ), и НИРАЗУ я не встречал ГЛОБОЛЬНУЮ задачу с которой бы не справилась "коррейская малышка"...
Не понимаю что значит фраза "VOIB жрали по 3 метра в час даже ночером" но подозреваю что опровергнуть её получится.....
Поймите , я не умничаю, просто мне обидно за малыху...Она свои деньги отбивает на 110%...

1. SIP 2.0 поддерживает колсвич, в тутошних VOIB (БЕЗ буквы Е) такой поддержки нет. Версию сменю нескоро: ни нового АSMU ни модуля памяти для перезаливки руководство не купит. Был бы рад перезалить без DRAM, но как это сделать?

Сказано ждать пока появится очередной клиент чтобы отдать ему старую (после отправки на перепрошивку) и забрать-поставить новую. Но теперь в ходу больше соха, HiPath11xx & TDA100

2. Когда потребовались прямые транзиты (мимо колсвича) в PGM322 появилось больше PSTN CO чем каналов на модулях VOIB(VOIU). Переключил кол и станции на 3-фреймовый g729 - тот же результат: односторонняя связь возникала и при соединениях VOIB-VPN-VOIB. Пришлось всё вернуть взад к трюковым транзитам с DТМF через g723.1 с одним фреймом (рассказывал в соседней ветке). Винить можно бы и кол, но когда через него ходят софтфоны нет ничего похожего

3. А как ты делал ТransitIN c аналоговых СО?

Сейчас если саратовский секретарь включит безусловную переадресацию на внутрикорпоративный номер в Энгельс то звонки из саратовского офиса пойдут в энгельсский, НО заруленные на секретаря вызовы с аналоговых СO Cаратова будут потеряны ещё до входа в тоннель

ТРИ(!) Мегабайта в час непонятно_чего VOIB крутили когда видели друг друга напрямую (без кола) и ни один транковый светодиод не горел; админ проверял по биллингу ISP

Скупой платит дважды, а технарь, не умеющий обосновать необходимую комплектацию станции - трижды. Может это к вам отношения и не имеет, но на будущее - факт такой существует.

Так может проще VOIP построить на станциях типа HiPath11xx & TDA100?

Прошу прощения, что может лезу не в свое...
Тут вот какая история, уважаемый dvs.
Однажды меня один уважаемый участник своевременно поправил на предмет как правильно пользоваться форумом, за что я ему очень благодарен.
Могу поделиться с Вами - пользуйтесь простым русским языком без сленгов и сокращений, и перечитывайте написанное вами для проверки понимания текста другой стороной - и тогда возимеете удивительный результат...
Помните - иногда даже неправильно поставленный знак препинания может именить смысл фразы на противоположный.

Если по мне, так я бы сделал трейс и проанализировал его, а что не понятно - выложил бы на форум.
А пока что ваши претензии к станции беспочвенны.
Конечно - что может быть легче, чем похулить станцию в невозможности ее работы, чем разбираться в целом комплексе трейсов.
А вот у меня то она как раз и работает в режиме SoftPhone(не родной)-VPN-VOIB-GSM_gate-GSM_gate-PSTN c кодеком g729!
Но при этом конечно-же немаловажный фактор имеют прошивки - я использую 3.6Df

день добрый...
К сожалению я не строил капитальных транзитов на СО-линиях, потому как считаю это гемором( причём слышал что не только на ЛЫЖЕ)...
GSM-шлюзы использую только на BRI, данные задачи я подымаю перед Заказчиком ещё до утверждения проекта. Но в этом Вы правы, ЛЖ действительно не дружит с СО ( точнее плохо дружит)..
И вообще я удивлён что у ВАс СИП поднялся на VOIB , насколько я знаю корейцы не заявляли поддержку данного протокола на данных платах...

Действительно, есть ли внятное ("пошаговое") решение/руководство по настройке УАТС ipLDK для маршрутизации внешних вызовов по аналоговым СО одной УАТС на внутренние номера другой УАСТ (соединенных QSIG или IP-Networking).
Кнопка "Поиск" в этом форуме (и в electoseti.ru) меня уже скоро игнорировать будет -- так я её "изнажимал" в поисках решения.

Если внутренний номер второй УАТС (на который нужно маршрутизировать внешние вызовы, поступающие на первую УАТС) заносить в системную speed-ячейку, потом организовывать на УАТС 1 специальную группу номеров, в поле overflow которой прописать номер этой ячейки, то на имеющимихся у меня под руками УАТСках (ipLDK-100 и -300 ver. 3.7) происходит следующее:

- Если звонить на группу с местной линии, то выбирается одна из доступных внешних линий и в нее запуливается тоновым набором номер, забитый в speed-ячейку (слышно в телефоне звонящего как УАТС тоновым набором надирает и потом, в логах, видно что был набор номера в другой аналоговы СО). Даже если в качестве исходящей линии или группы указать линию или группу линий, через которые УАТС соединены (по IP)
- Если звонить на внешнюю линию, для которой настроено, что вызов с нее будте маршрутизирован на специальную группу, то звонящий слышит один длинный гудок, потом идут которкие гудки (УАТС не смогла перекинуть вызов куда-то дальше?).

"Ручной" перевод вызова работает.

Для перенаправления входящих вызовов с аналоговой СО линии на другую станцию корпаративной сети:
- на версиях 3.6 -3.7: в ПГМ144 назначить вызов на какого-либо одного (только на одного!!!) абонента (STA). На указанном телефоне установить переадресацию на Net Number (на номер абонента другой станции). Можно также использовать CFWD Off-net - через Speed ячейку. Но тогда линии между станциями д.б. прописаны как PSTN.
- на версии 3.8: в ПГМ144 добавлена возможность непосредственно прописать Net Number (номер абонента другой станции в этой корпаративной сети). Кроме того, маршрутизация выполняется без замыкания шлейфа СО линии (шлейф замыкается только при ответе абонента другой станции).
Версия 3.8 будет доступна в конце декабря - начале января.

К сожалению, эта схема не работает.
Версия 3.7.
В ПГМ 144 назначаю маршрутизацию вызова с аналоговой СО-линии на одного внутреннего абонента (STA) (например, номер 100). Проверяю, что внешний вызов штатно передается на эту линию (номер).
Далее, на телефонном аппарате, который подключен к внутренней линии 100 набираю *554 1 200 , где 200 - номер внутренней линии второй УАТС, а *554 - в номерном плане так обозначена установка переадресации, 1 -- безусловная переадресация. Слышу короткий гудок подтверждения команды. кладу трубку, поднимаю её внось, чтобы убедиться, что теперь линия работает в режиме переадресации (в этом режиме в трубке слышытся прерывистый сигнал вместо ровного зума). Звоню для проверки с другой внутренней линии (например, со 101) на номер 100, убеждаюсь, что переадресация на номер 200 срабатывает.
Звоню на СО, вижу, что маршрутизация срабатывает -- внешний вызов с СО-линии передается на внутреннюю линю 100. И телефон 100 начинает звонить (звук звонка сигнализирует о том, что пришел внешний вызов). Т.о. переадресация (безусловная на Net-номер) не срабатывает, если идет внешний вызов.
Может быть есть какие-то подводные камни? Например, в ПГМ 142 в поле Open loop detect timer что-нить отличное от нуля ввести? (это я к примеру).
---------
Межстанционные вирутальные IP-линии в моей концигурации все уазаны как NET, а не как PSTN.

OK. Сейчас еще раз проверю...

Проверил на версии 3.7Се. Все работает!!!
Таймер Open Loop не влияет на CFWD.
ПГМ 144 -> CO 61> STA300 (только на один телефон STA300, и именно напрямую на телефон, а не на Hunt-группу) - проверить по ПГМ145!!
В Networking прописано:
3#** - Net Grp 0 (своя станция)
4** - Net Grp 1 (другая станция)
СО 031 -060 (PRI) -> Net Grp 1
На STA300 включена переадресация: 554+1+400 Hold
У Вас между станциями сетка или PRI???
Не знаю, смогу ли сейчас проверить то же самое по сетке....


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

У нас сетка (IP-Networking).
И версия тоже как у Вас: GS30P-3.7Ce JUL/07

Call Forward и OFFNET Call Forward испытуемой станции (внутренней линии) разрешены.

Сетевые планы работают. Transfer-Out работает (не через LCR, а через те же сетевые планы).
Вот Transfer-In никак не покоряется... (ибо все внешние линии -- аналоговые СО).

Только что проверил еще раз... Соединил две станции по VOIP. Все работает.
Проверьте, куда назначен входящий вызов по требуемой СО -линии по ПГМ145!!!!

Доброго времени суток, уважаемые ...
Помнится мне, в свое время, я организовывал этот трансфер через Hunt группы (тип Ring), с последующим указанием на Speed ячейку в этих группах. Overflow timer=1. В группу вставлял незадействованные порты, к примеру - 198, 199. Ну и разумеется, Speed ячейку надо прописать примерно так, как было оговорено выше. Вот только не помню точно, это должна быть тип 8 или тип 9 переадресация...
Причем на этот вариант решения, по-моему, натолкнул меня уважаемый Игорь.
Попробуйте так, если решение еще не найдено ...
И все работало, как ни странно, да еще и на версии 3.0Сс...
Похоже - "ларчик" потихоньку переполняется?!...

Да, конечно, можно и так, как описал уважаемый Alex_Q (по переполнению из Hunt-группы на Speed-ячейку)... Но, в этом случае линии должны быть типа PSTN, а не Net (по ПГМ322).

Прошу прощения за дезу - при такой схеме у меня работала переадрессация тип 7.
А типа 5 тогда еще не было.
И вот, похоже, здесь мы и имеем траблы.
И все-таки, не взирая на это, Игорь - какой самый оптимальный вариант решения данной задачи в случае PMU v.3.6Xx?

Не понял, как это типа 5 не было??? На ранних версиях??? - Это было всегда.
Да, можно и тип 7 использовать. Смотря что конкретно требуется...
Нужно ли жестко отправлять в другую станцию или периодически включать/отключать эту переадресацию??? Давайте уточним задачу.
Какие именно траблы???

Извините за задержку с ответом.Настроена передача вызова с внешней аналоговой проводной линии (СО) на одну внутреннюю аналоговую проводную линию (на один телефон, не на группу) -- как Вы и указывали ранее.

Ну, ЧЕЗ (черт его знает), в чем причина...
Пришлите файл конфига, посмотрю... А вдруг чего-то выяснится...

Выслал. Извините что под НГ

Пардон, но я ничего не получил...
Если можно пожалуйста отправьте повторно...
Можно для подстраховки на второй адрес: garryhalf <> gmail <> com

Отправил повторно в оба адреса (10-го января). Дошло ли? Волнуюсь...

Нет, не получил... Странно сие... Почта вроде работает.
10-го января другие письма дошли. Еще раз мои координаты:
garry@lg-nortel.com и garryhalf@gmail.com

Сделал согласно Вашему предписанию и ЗАРАБОТАЛО!
Спасибо!