Тема: TDA200 и TDA30. Проблема выхода в город.

Здравствуйте. Появилась проблема, по форуму полазил, есть похожие, но прямо такой не встречал.
Есть TDA200, с городскими номерами (PRI). Есть удаленные TDA30. Соединение через IPGW.
На TDA200 в 4.1.1 в ISDN CLIP ID прописан номер, который будет отправлен, как исходящий при звонке в город через 9.
Появилась задача - удаленные TDA30 через IP подключаются к TDA200 и уходят в город через нее.
Маршрутизацию я настроил (коряво правда, зато сам) сл. образом -

TDA30
1) 2.6.2 - быстрый набор - 8=*59810 (т.е. выход на TIE с набором 810);
2) 9.1 - ловим 810, ничего не добавляем и не убираем и отправляем на TG с IPGW.
3) В IPGW в 1.6.2 отправляем все номера с 810 в начале (8102, 8103,...,81089) по айпишке на TDA200.

TDA200
4) В IPGW в 1.5 прописано 810 - Hunt Pattern1
5) 9.1 - ловим 810, ничего не добавляем, убираем 3 цифры и отправляем на TG с PRI.

Как видно львиная доля идей, за исключением ARS, была взята из амитековской инструкции.
Звонки проходят. Т.е. я выхожу на нужную линию и звоню на гор. номера.
А проблема в том, что номер в этом случае передается внутренний (трехзначный) - это я выяснил путем трассировки. Это означает неприятные разговоры с поставщиком (типа, че это Вы с левых номеров звоните), да и у людей, кому звноим, не определяются наши номера.

В документации (Feature_guide, стр. 218) написано “При использовании частной сети для идентификации исходящих/входящих вызовов передаются внутренние номера, назначенные внутренним линиям посредством системного программирования”. Видимо, это мой случай.

Не подскажите, как передать не внутренний номер, а тот какой я хочу. Понятное дело, прописывание на TDA30 в 4.1.1 в ISDN CLIP ID нужного номера, ничего не дает.
Спасибо.

С 30-ки нужно “ходить” в город не через TIE, а через Locall Access (9-ка).

Если через “9”, то они будут ходить “через себя”, а нам надо, чтобы через нас (TDA200) ходили.  На “тридцатке” нету PRI.
Они сейчас через свои линии ходят в город через “9”, но мы собираемся от этого отказаться, поэтому и надо такой маршрут организовать, чтоб через нас все звонки исходящие шли.

Ну вот и замени в Locall Access аналоговые транкгруппы на транкгруппы с PRI.
Модификацию (добавить 9-ку для 200-ки) можно сделать там же в 3.4 (Dialing Plane).

А можно чуть-чуть поподробнее. Опыта у меня пока немного.
У меня в консоли в 3.4 нет Dialing Plane, там Paging Group.

На тридцатке нет платы с PRI. Следовательно нет и транковых групп с PRI. Есть транковые группы аналоговые и на IPGW.
На двухсотке плата PRI есть. И на двухсотке через “9” я попадаю на транковые группы с PRI и уже через них звоню в город.

И вот из Вашего ответа непонятно как и где прописать “пришные” транковые группы. Если на двухсотке, то они там и так прописаны, а если на тридцатке, то “пришных” транковых групп там нет...

3.1.5.
Имелись ввиду Qsig транки (IPGW).

запустите ars и в ней пропишите маршрут, пусть там добавляется 9 и отправляется все это в транк с ipgw.

Верификацию от VPS.. но это если ничего другого не получится.

2Maxtel: Попробовал Ваш вариант. То же самое. Только 9 добавлять не надо, т.к. он и так выходит на нужные транки, и добавленную “девятку” воспринимает, как часть набираемого номера.

Причем сегодня попробовал не из доп.офисов выходить, а прямо на своей TDA200 (т.е. в обход “девятки”, через выход на саму плату). Ситуация такая же (как через TIE, так и через ARS). Т.е. дело не в том, что у доп офисов нет “пришных” плат и, следовательно, не работает ISDN (как я до этого предполагал).

И еще вопрос появился - а может как-то влиять, что связь идет не по QSIG, а по IP? Насколько я понял связь по QSIG идет между платами PRI (или BRI), а в моем случае используется IP, следовательно, и протокол идет VoIP.

1. Крутить надо 30-ку, а не 200-ку, да еще и непосредственным выходом на транки. ТОЛЬКО через Locall Access.
2. Dialing Plan 3.1.4. добавьте 9-ку, или какой у вас там выход на 200-ке, и измените приоритет выхода 3.1.2. (то, что victorkrasnodar советовал)

зы. У H323 QSIG внутри.

все quick dial удалить
1)по амитеку настроить две станции, чтобы  они видели друг друга через other pbx ext
2)далее на TDA30 прописать clip id, на который договорились с провом, т.е.  как в TDA200
3)настроить ARS на 30-ке, чтобы отправляла набраный номер и добавляла 9
4) в dn2ip прописать то что в other pbx, и добавить 9
если так не получится то делать верификацию от VPS.

ДА! Заработало!
Спасибо всем огромное за советы. Все они мне в той или иной степени пригодились (кроме VPS, до него не дошел).

На всякий случай подробно опишу свои настройки для тех, у кого может будет похожая ситуация.
1) Выполняем два первых пункта из совета Maxtela (на обеих АТС выход на внешку через 9 (2.6.1))
2)
Удаленная АТС
8.2 - прописываем 9<номер>. 9-выход на внешку; номер - первые цифры нужного номера (например, (9)89 - для сотовых); кол-во ожидаемых цифр (в данном примере - 9)
8.5 - поставщик - 1. Для него на соседней вкладке, убираем все кроме IPGW (группу для IPGW смотрим в 10.1).
8.1 - включаем ars.
IPGW удаленной АТС
1.6.2 - прописываем 9<номер>, и уводим маршрут на основную АТС. (то же самое 989, плюс ждем 9 цифр)

Т.е. набираемый номер будет 99<номер телефона>. 9-выход на ars, а след. 9 вместе с номером, согласно указанному маршруту идет на основную АТС. (т.е. 9989ХХХХХХХХХ)

3)
IPGW основной АТС
1.6.2 - прописываем 9<номер>, и уводим маршрут на основную АТС.
1.5 - прописываем 9 для вх. номера.
Основная АТС.
Здесь ars настраивать не обязательно, единственное, у меня звонки сыпались на первый COS, так что пришлось с косами там немного переделать.
Основная АТСка получает вызов 989ХХХХХХХХХ. Вот здесь мне повезло и в отличие от многих со схожей проблемой, 9 определилась не как часть номера, а именно как выход на внешку. Короче, она выходит на внешку (через первый КОС) и передает номер 89ХХХХХХХХХ.