Не очень тривиальная задачка SPD+NetPlan Опции

[Starter]

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

LDK300, вер. 3.6Df

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

[All is not what ...]

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

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

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

[harris]

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

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

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

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

[Starter]

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

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

[harris]

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

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

[Alex_Q]

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

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

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

[harris]

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

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

[Alex_Q]

Менять ядро фактически означает изменить полностью весь софт..... Просто требуется сгладить некоторые шероховатости. А где их нет????

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

[harris]

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

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

[Starter]

А Вы заметили, что в основном эти станции пытаются применить для случаев, для которых они изначально не предназначены???

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

Я же считаю, что в целом логика в маршрутизации есть, иначе бы никто ничего не смог запустить. А большинство с задачей справляется. Значит уже не все так плохо. Значит остаются только "шероховатости".

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

ИМХО, нет смысла спорить по этому вопросу. Форум все равно такие вопросы не разрешит. Об обнаруженных проблемах нужно писать дистрибьютеру.
Нету в мире совершенства

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

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