Тема: Требуется "помощь клуба"

Уважаемые коллеги!!!
Кому-нибудь приходилось прописывать в Speed-ячейку только часть номера вызываемого абонента????
Как часто это требуется????
Для каких целей???
Сейчас при посылке En-block’ом нужно прописывать в ячейку только полный номер (что в ячейке, то и уйдет к провайдеру сразу же, без ожидания)... Нужно ли ожидать, что абонент захочет прописать в ячейку только часть номера, а потом донаберет следующие цифры до полного номера перед посылкой???
Например, только коды городов:
8812
8343
81038044
и т.п.
Речь идет только о линиях ISDN и посылке номера способом Enblock!!!!!

тема похожая была!!! мой провайдер после такого как мой end-block срабатывал,плюс у меня эндблок с задержкой в 2 секунды, больше донабора не принимал, и происходило следующие что пытаюсь набрать еще цифры а они уже не набираются но я думаю что все зависит от провайдера!!!!он это объясняет тем что у него вроде как 4 сек ждет и все и так же end-blocko м уходит дальше! по крайней мере у меня так было!извините если не в кассу...

Все “в кассу”...
При Enblock’е станция отсылает номер, записанный в Speed-ячейке, с признаком Sending_Complete (все цифры отправлены), поэтому станция на стороне провайдера больше ничего не ждет....
Об этом и речь. А кому-нибудь требуется прописывать в ячейку только часть номера???? Или же в ячейку всегда прописывается полный номер (тогда нет необходимости переделывать софт)????

нет такой нужды я не слышал??? это только избалованным! 😊)))если только в этом вопрос!

harris !
Если вопрос не праздный отвечу развернуто.
Такое требуется ОЧЕНЬ ЧАСТО практически во всех более или менее крупных городах России!
И относится это не только к ячейкам SPEED, но и (особенно) к LCR.
Необходимость возникает при записи в ячейку кода доступа к провайдеру IP-телефонии. Особенно сильно при ен-блоке бьет невозможность вставить паузу между номером дозвона до платформы провайдера и ПИН-кодом!
Предполагается, что такая ячейка - общая для всех, а собственно междугородный номер будет донабираться пользователем ручками.
По Москве такими услугами пользуется чуть ли не каждая 2-ая фирма. Если представить у скольких из них - LDK на потоке - то получишь потребность в этом в первом приближении.
и еще, уж коли речь о ячейках - было бы не плохо предусмотреть возможность регулировать количество общих ячеек в широких пределах.
Простой пример: надо занести московский номер в SSD.
- заносим номер 558-25-31 в ячейку 2531.
- с аналогового телефона вызов ячейки: 5582531
:D
Смешно?
Вот и мне было бы смешно, если бы не было так грустно.
И если с 558 еще можно что-то сделать, то оставшиеся 4 цифры - незыблемы (по крайней мере я не нашел способа их сократить! Если он есть - подскажи, пожалуйста!) Ну скажите, зачем 2000 ячеек ВЕЗДЕ? Было бы разумней дать возможность их число РЕГУЛИРОВАТЬ!

1. Почему не удается вставить паузу???
Если в ячейке прописано: хххххххРууууууу,
то ххххххх уйдет Enbloc’ом, а уууууу - тоном после установления соединения.
2. Но я имел в виду другое: что в ячейки прописывают не полные номера (которые надо отправить Enbloc’ом), а часть номера, например только коды городов:
8812 (Питер)
8343 (Екат-рг)
81038044 (Киев)
и т.п.
Т.е. из ячейки набирается 8812, после чего станция ждет пока пользователь донаберет питерский 7-ми значный номер и только после этого отправит к провайдеру все цифры Enbloc’ом. (Подчеркиваю речь идет только об Enbloc’e !!!)
3. Насчет кодов доступа к Speed-ячейкам - я согласен. Это неудобно.
Попробуем запросить корейцев об изменении способа доступа к ячейкам.

1. Вставить-то ее удается, только после отправки Enbloc’ом ххххххх, никакие уууууу тоном не отправляются. Проверял уже не на одной клиентской станции.
2. А коды городов здесь именно потому никто и не додумывается отдельно прописывать, что вызов ячейки - слишком длинная комбинация (российские-то коды и так короткие, а вот Киев (8-10-380-44) и другие заграничные города прописывать приходилось и не раз (правда на панасониках, где вызов ячейки - *ХХ), но не на потоке и не очень часто. (с 2001 года - раз 30 может было) На мой взгляд, прописывание ТОЛЬКО кодов городов - не очень актуальная тема.

1. ОК. Попробую проверить и разобраться.
2. Запись Кодов городов я привел как пример. Можно ли считать, что вообще запись только начальных цифр номера (неполный номер) в ячейку практически никому не требуется???
Спрашиваю не просто так... Для версии 3.8 нами заказана новая функция для Enblock’a. Набираемый номер сразу же проверяется на соответствие по таблице префиксов и анализируется кол-во цифр. Перед отправкой провайдеру номер форматируется (локальный вызов/МГ/МН)... Если цифр меньше, чем указано для данного префикса, то станция ничего не отправит провайдеру, а освободит линию. С ручным набором- все четко. Как быть, если в ячейку прописан неполный номер (цифр меньше, чем того требуется при указанном префиксе) - отбивать сразу (считать, что ячейка запрограммирована неправильно) или же давать пользователю возможность вручную донабрать недостающие цифры (ожидать донабор, если таймер ожидания истек - отбивать)???

Осторожно выскажу пожелание не предлагать станции самой решать правильный набор или нет. С этим вполне справляется операторская техника, а уж LDK отбой оператора легко подхватит. Ведь план набора может быть некорректно оформлен (известно, что АТС устанавливают не только сертифицированные специалисты, да и среди них встречаются люди с разным уровнем знаний). И тогда мы просто получим очередной “глюк”, который сразу будет причислен к недостаткам станции! По крайней мере можно предусмотреть опцию контроля за номером, которую особо рьяные пользователи смогут включить, если им так захочется.
Даже если заносить часть номера требуется и не многим, не понимаю, зачем лишать такой возможности?
И еще, коли уж речь пошла о “заказе”, нельзя ли как-нибудь “заказать” Корейцам, чтобы отработали LCR по-полной.
Чтобы эта замечательная функция заработала, наконец во всей своей красе: на всех типах городских линий, при наборе как с системных, так и с аналоговых телефонов, в тоне и в пульсе, в ручном наборе и из SPEED-ячеек, и боком и р...м! Ну ей-богу, надоело изворачиваться!:)
Извините за последнюю фразу - наболело.

1. Конечно же, это дополнительная опция. Кому нужно, тот пропишет доп. таблицы и включит эту опцию. А “Укртелеком”, например, жестко требует наличие такого анализа на стороне пользователя.
Меня как раз и интересует:
а вообще, хоть кто-нибудь пользуется ли записью части номера в ячейку?? Пока никто утвердительно не ответил.
2. К сожалению, подстроится под наши тел.сети - весьма нелегкая задача. По тем проблемам (не только с LCR), которые удается обнаружить, мы делаем запросы в Корею. Пишите, информируйте...

Игорь привет.

Ой где то я уже встречал похожее. 😊)
Дык точно в Avaya. Она так и анализирует цифры в энблоке.(ну одна из возможностей)
Нужно ли это или нет? нуу. мое мнение - нужно. Это частный случай, но бывает.

Провайдер скорее всего не хочет лишней информации получать. вот и ограничивает клиента фиксированными цифрами.

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

Все это ИМХО.

Игорь, такие опросы, ИМХО, лучше на радиолинке делать.

1. По существу- опять же ИМХО- был бы более полезен “полноценный” Enblock, т е анализ по префиксу и длине номера. Тогда и проблем бы не было со спид ячейками- если начало от 0 до 8 и 9- тогда после 7 цифр посылаем Sending Complete, а далее отрабатывается пауза и все остальное. А по таймеру с блоком получается еще хуже, чем без него- поскольку имеем Sending Complete на неполный набор “проключается” вся трасса, и только оконечка отвечает “Unassignet number”, или что то типа того. Т Е каналы занимаются совершенно напрасно.

2. прописывать часть номера не приходилось- извращение это! Есть же LCR, зачем извращаться со спиддайлом. Повторюсь- ИМХО!

Именно так. Провайдер (указанный выше) хочет (требует!!) свои проблемы переложить на оконечную АТС, т.е. на сторону пользователя. Ему плевать, что у пользователя стоит маленькая недорогая станция, которая и НЕ должна выполнять такой анализ набора...
Ну да ладно... На самом деле при Enbloc’е - это полезная вещь. Можно не нажимать # в конце номера и не ждать окончания таймера для отправки номера.
Мы и заказывали нечто похожее на Avaya (префикс, min цифр, max цифр, ...). Это все работает. Остался вопрос, что делать со Speed-ячейками, если в ячейке записано меньше цифр, чем минимум для данного префикса. Сразу отбить и ждать возможного дополнения номера.
Сейчас (без новой) функции, станция отправляет номер как он есть к провайдеру, а уже провайдер отбивает линию из-за того, что номер неполный.
Я как раз и пытаюсь собрать все “ИМХО”
:(

2 Alexander073:
Естественно, как мы заказали, так и сделано...
Прописывается:
-префикс
-мин. кол-во цифр
-макс. кол-во цифр
-тип номера (Subscriber\National\International)
-Sending_Complete (посылать или нет для данного префикса)
-план нумерации (Unknown\ISDN\private и т.п.)

Если в ячейке неполный номер (цифр меньше, чем MIN) и пользователь ничего дополнительно не набрал (до MIN), то LDK все равно ничего провайдеру не отправит, освободит зарезервированный канал, пользователю даст зуммер ошибки. Но это произойдет с задержкой на время Enbloc Timer (ожидание набора цифры).  Если же сделать по другому, то: раз цифр в ячейке не хватает до MIN, то отбивать сразу без задержки на ожидание донабора. Вот и вся разница.

Создано harris
Именно так. Провайдер (указанный выше) хочет (требует!!) свои проблемы переложить на оконечную АТС, т.е. на сторону пользователя.

Остался вопрос, что делать со Speed-ячейками, если в ячейке записано меньше цифр, чем минимум для данного префикса. Сразу отбить и ждать возможного дополнения номера.
Сейчас (без новой) функции, станция отправляет номер как он есть к провайдеру, а уже провайдер отбивает линию из-за того, что номер неполный.
Я как раз и пытаюсь собрать все “ИМХО”
:(

1. Как представитель провайдера я его очень понимаю.

2. Именно для набора Enbloc - не посылать. Почему- написал выше- это ж маразм- приходит признак Sending Complete (заметтьте- сообщение немандаторное!!), а номер не весь!

ЗЫ- а вообще работа оконечки блоком- опять же на мой взгляд- излишество. Анализировать номер должна вышестоящая АТС, и Overlap подходит к этому случаю лучше. Если только в качестве вышестоЯщей не стоИт какой нибудь убогий VoIP шлюз....

Создано harris
2 Alexander073:
Естественно, как мы заказали, так и сделано...
Прописывается:
-префикс
-мин. кол-во цифр
-макс. кол-во цифр
-тип номера (Subscriber\National\International)
-Sending_Complete (посылать или нет для данного префикса)
-план нумерации (Unknown\ISDN\private и т.п.)

Если в ячейке неполный номер (цифр меньше, чем MIN) и пользователь ничего дополнительно не набрал (до MIN), то LDK все равно ничего провайдеру не отправит, освободит зарезервированный канал, пользователю даст зуммер ошибки. Но это произойдет с задержкой на время Enbloc Timer (ожидание набора цифры).  Если же сделать по другому, то: раз цифр в ячейке не хватает до MIN, то отбивать сразу без задержки на ожидание донабора. Вот и вся разница.

1. Даже по префиксам посылать или нет Sending_Complete ?? Жму Вам руку!!!

2. Черт его знает... склоняюсь ко второму. Ведь если пришел неполный номер- все равно донабора не получится, канал то уже проключен... Или первый вариант, но не посылать тогда Sending_Complete.