forum.technoforward.ru

Ситуация такая. Подали мне для тестирования три городских ХХХ-800, ХХХ-801, ХХХ-802. Первые три цифры одинаковые. Поток идет через Cisco.
Вариант 1. Конвертацию делают на Cisco все работает хорошо.
Вариант 2. Когда внутренний соответствует трем приходящим с потока цифрам то все работает.
Вариант 3. На Cisco отрезают три первых цифры шлют мне три последних. Я програмлю.
3518>24:0
3512>24:2
7600>800:000
7600>801:001
7600>802:002
7601>000:3000
7601>001:3001
7601>002:3002
Ничего не работает.

У меня в нум плане 8 код выхода на маршрут.
200>8:A129
делаю
200>8:801
конвертация начинает работать.

Поток рабочий на PN-DTB(QSIG).

_________________
Одна голова это хорошо, а две это уже мутант.

так в 3512>24:3 надо ставить.
Вы же ловите 4х значку (3ххх), на сколько я понял.

_________________
С уважением

Коллега!
Будьте бдительны!
Топикстартер в явном виде написал:
...На Cisco отрезают три первых цифры шлют мне три последних...

_________________
С уважением,
Валерий Петров.
www.tarificator.ru

Да, прошу прощения
Тогда, как я понимаю: Вариант №3 - шлют три цыфры и строка
7601>000:3000, все равно не "сростаится"
З.Ы. еще раз прошу прощение за мое "не понимание" - "час в перед это не шутки "

_________________
С уважением

Те входящие наборы, которые NEAX принимает по DID и передает на конвертацию (первое данное команды 7600, в Вашем случае - 800, 801 и 802) воспринимаются системой как местный номер, который ей велят преобразовать. Этот номер должен быть соответствующим образом определен в нумерационном плане - командой 200. Именно поэтому, как только вы изменили "8" с выхода в LCR (A129) на местную нумерацию (801), пусть и однозначную, входящие вызовы стали проходить. Зато, вероятно, вас не устраивает, как теперь обрабатываются наборы на "8" от абонентов NEAX. Поэтому, я бы порекомендовал сначала выяснить, как будут выглядеть входящие наборы не в тестовом, а в "боевом" варианте, а затем можно будет придумать, как быть с ними, чтобы и волки, и овцы...

Получается в любом случае получаемый номер должен быть определен в нум плане? А по другому можно сделать?
В "боевом" варианте диапазон номеров будет тысяча 797000 - 797999. Входящий набор мне могут сделать любой. Хоть 3 хоть 4 цифры.

_________________
Одна голова это хорошо, а две это уже мутант.

А разве нельзя задействовать Development Table 1? пусть с cisco шлют все цифры:
200>797:806
35170>24:0
35171>24>06
7690>797000:000
7690>797001:001
7690>797002:002
7601>000:3000
7601>001:3001
7601>002:3002
Вряд ли у вас в нумерационном плане что-то будет конфликтовать с кодом 797

P.S. сорри, если сморозил глупость, с QSIG дела не имел пока

_________________
Связь, она как воздух:
Когда она есть - ее не замечают; когда ее нет - задыхаются...

Делал я Development Table 1. Только конвертировал то что приходило. То есть 3 последние цифры. Не работало.
У меня все цифры кроме 6 заняты или нум планом или кодами выхода на маршруты.

_________________
Одна голова это хорошо, а две это уже мутант.

Половина сведений уже есть! Отлично! Теперь бы еще узнать, что будет реально набираться в других узлах сети для вызова абонентов 797ххх?
Собственно, скорее всего это и будут ровно такие же наборы. Тогда вообще непонятно, зачем Вам что-то конвертировать. Ведь с CISCO вы коннектитесь по QSig, если я правильно понял. Ну и пусть она ничего не отрезает, присылает все 6 цифр. 200>797=806 у Вас и так должно быть прописано. Закройте конвертацию, о все само должно случиться (если, конечно, все запрограммировать строго по QSig Manual). Ну уж если CISCO очень нужно что-нибудь отрезать, пусть режет первые две цифры, а Вы их добавите обратно через 3517 и 5000.

я тоже задам парочку вопросов по аналогичной теме....

на одном из присоединений к городу по isdn pri ГТС шлёт мне 6 цифр номера абонента... Плата 30 prta принимает 4 (когда включена конвертация с потока насколько я знаю). Внимание вопрос - почему работает схема: ГТС шлет 20-03-90, плата принимает 0390, через 7600, 7601 0390 вешается на 3390, при всем том, что 0 прописан как A129 на один из потоков?

и второй вопрос: на другом присоединении ГТС обещала присылать последние 3 цифры номера, которые совпадали с 3-х значным нумерационным планом АТС. Не работало... начали конвертировать. Ловил через 7600 и 7601 по 3 цифрам - нет. Просил прислать все, ловил через 4 - нет. Работало только через 2. Думал, может, они ошибаются и шлют 2??? Но итоге остановился но варианте, когда в 3002 прописал 21, что отключает конвертацию... тогда и заработал первый вариант с тремя присылаемыми/совпадаемыми цифрами. Почему?

to МИХАник:
1. "Плата 30 prta принимает" столько цифр, сколько указал администратор АТС командами 3512\35170. Сие никак не зависит от того, включена или нет конвертация с данного потока (CM3518). Кроме конвертации командой 76 есть еще возможность добавления 1-2 цифр вперед к принятому номеру, и удаления 1-2 первых цифр (CM3517). Вот с учетом всего этого, а также - релиза ЦП, - можно говорить о принятом номере и его соответствии нумерационному плану. Скажем, в Вашем примере, если допустить, что 3512>rt=2, а 3517>rt=03 (возможны, разумеется, и другие работающие комбинации), то приниматься будет 3390, и вызов пойдет на этот экстеншн минуя анализ в команде 76.
2. В этом примере степень неопределенности - еще выше. "ГТС обещала..." - это как умножить то-ли 2, то-ли 7, на где-то около 4... Тем не менее, если ГТС слала таки именно 3 цифры, то при 3512>rt=2 это могло бы, и даже - должно было работать, а вот при 3512>rt=3 (умолч.) - нет! (не исключу, что так и было). Что касается "в 3002 прописал 21", то этот прием действительно иногда применяется для работы ОВЕРЛАПом (прием номера по одной цифре, а не блоком), но в протоколе PRI при одностороннем, несогласованном назначении этот прием - на грани фола, примерно как сеть на первенстве по спортивному рыболовству. Говорить здесь о каких-то закономерностях бессмысленно.

Вообще-то в DID addressing разобраться не так уж и сложно. Только торопиться не надо.

в первом случае:
тройку добавлять не пойдет,
у меня 3512>rt:3; можно и 2...
3517>rt:15;
так как я "вешаю" не только на 3390, но и, скажем, на 2101...
а прием четырех цифр типа "0390" и в то же время выход через "0" работал и когда релиз был 7, и сейчас, после подъема до 13...

во втором:
мне оставил кто-то зарытую собаку в виде - в 3512>rt:стоит 1.... блин

Я вот внимательно перечитал тему и мне кажется, что некоторое непонимание возникло из-за вот этих слов уважаемого NEAXMANа:

Отсюда этот вопрос:


Я сейчас тоже решаю одну нестандартную задачку с конвертацией номеров и пытаюсь вникнуть в суть. Насколько я понимаю, то, что сказал NEAXMAN про определение цифр входящего номера в нумерационном плане как местный номер это относится именно к Qsig? Ведь при PRI таких особенностей нет, а для QSig DID получается как "нештатный" режим... И еще мне сдается, что похожая картина получается при использовании "21" в команде 3002, такая пропись отменяет жесткое количество принимаемых цифр, но отменяет и конверсию цифр, даже если она включена, цифры обрабатыватся нумерационным планом. Однако если номер определен в нумерационном плане как внутренний (или отсылается в LCR, а там указан, как "intra-office termination"), то есть подозрение, что конверсия при совпадении цифр начинает работать, и при этом принимаются и номера другой разрядности. Скажите пожалуйста, уважаемый NEAXMAN, прав я или нет?
P.S. моя задача - принять по PRI, скажем так, произвольный номер, при совпадении с внутренним или сетевым терминировать на него, при несовпадении отправить по нум.плану на транзит, но при этом еще хочется сохранить DID с конверсией цифр, т.е. если пришло N цифр, определенных в 76 команде, то конвертировать и отправить на внутренний. Вот такие "волки и овцы".

Ещё как есть! Не скажу точно, до какого релиза, но точно есть.
Что касается Вашей "нестандартной" задачи, то, конечно, трудно сказать заранее, что из этого заработает, а что - нет. Конвертация при "21" не пропадает, другое дело, что в ее анализ попадает не фиксированное количество цифр от конца, а все пришедшие цифры - от начала. Так что можно поступить как скульптор: открыть всё по "21", прописать конвертацию, и смотреть, что заработало, а что нет. Далее - по ситуации. Не заработает конвертация - можно виртуальными номерами с переадресацией воспользоваться...

А вот у меня родился еще один вопрос по ходу проводимых экспериментов, зависит ли функционирование команд 35170...35172 от релиза самой поточной платы?
Дело в том, что имеется следующая картина: с PRI приходит пять цифр, конверсия включена, DID прописан в 7690. Ставлю 35170 в 0, 35172 в 05, 35171 в 05 и звонок не проходит ("в никуда"). Прописываю в 7690 номера из трех последних цифр, ставлю 35171 в 03 и все начинает работать. Для пробы меняю 35172 на 06,04 и 02 и все продолжает работать, т.е. эта команда как бы не влияет. По 3002/3003 при этом законные "18".
Особенность в том, что стоят древние 30DTC и SC01, не с этим ли связаны проблемы?