Тема: Ldk-300. Co-co
Всем здравствуйте!
Господа, такой вопрос. Есть следующая схема.
Две группы СО. 1-ая - это PRI
2-я - это аналоговые CO
Звонок приходит из 1 группы и (через 231) попадает на ячейку. В ячейке записан номер и выход этого номера на группу 2. Так вот, если все линии в группе 2 заняты, звонок, почему то, начинает валиться на attendant, а не отбиваться.
Как поправить данную проблему?
Заранее спасибо.
Это соответствует назначению для DID/DISA Error (ПГМ167/2). Если там прописать значение= Tone, то станция отобьет линию. Но, естественно, это изменение будет касаться и других DID/DISA вызовов в случае обработки по ошибке.
Понятно, спасибо. Уважаемый harris, попутно вопрос с попыткой как то выйти из этого положения, аналоговые СО могут выступать в качестве каких-либо (NET или PSTN) групп, если мы говорим об Networking-е (ну или при организации транзита)?
Да, аналоговые СО-линии можно использовать как PSTN линии (линии городской сети), но не как Net (корпаративная сеть).
А вариант звонка, в случае попытки организации транзита, когда PRI - PSTN и аналоговые CO - PSTN , на 300-ке прокатит? Или нужно обязательно, что бы одна была PSTN, а другая NET?
Прокатит. Только я пока не понимаю, как это поможет Вам решить исходную задачу...
to harris
Поясню свою мысль. Если в случае занятости аналоговых СО работает ПГМ167-2, то, как Вы правильно заметили, это приводит к печальным последствиям. У меня на АТС активирована DISA и в 167-2 стоит группа секретарей. Соответсвенно, если, работая через ячейки, от этого не уйти, то я подумал, может сделать Networking? Т.е., каксаемо данного случая, без ячеек. Может тогда 300-ка при занятости внешних аналоговых линий будет просто отбивать звонок? Поэтому я и интересовался возможностью организации звонка PSTN-PSTN.
ИМХО, так все равно проблему не удастся решить. Если транк будет занят, то по ошибке все равно станция отправит вызов по ПГМ167/2.
Есть другое предложение. Можно сделать через Reroute Destination.
Нужно оставить в ПГМ231 назначение на SPEED-ячейку, и там же в ПГМ231/5 (Reroute Dest.) прописать заведомо неподключенного абонента (ну, или Hunt-группу, по переполнению (таймер 1 с) -отбой). Так должно работать. У меня этот вариант сработал.
Странно, у меня эта идея сразу в голову пришла, я попробовал в 231-5 поставить VMIB# куда записал “линия занята...” у меня не работало....Сейчас пока не удается проверить мою идею, пока есть свободные линии... но попробую еще раз с 231-5
Нет, пардон. Я был неправ. “Не соблюдал чистоту эксперимента”... Reroute Dest. в этом случае не сработает... Увы.
Печально... Я попробовал сделать через СCR. Пока секретари, говорят, их не беспокоили. Attandant-ом назначил “левый” номер.
Что значит через ССR???
Attendant - левый, а что в ПГМ144 для каналов потока прописано????
У Вас режим DISA используется???
Записал приветсвие в сообщение номер 1
1) CCR для сообщения 1 - индекс 10 - номер attandanta (поставил в качестве системного “attendanta” левый номер ,пусть будет 111)
2) в 144 ПГМ для всех линий PRI поставил группу секретарей
3) в 167-2 поставилл Attandant
4) в 231 ПГМ то, что нужно идет на VMIB1 и это работает.... вроде все. Таким образом, если так или иначе работает 167-2, то пусть звонки валятся на “левый” attandant.
Нет....😊
Если ПГМ167/2 = ATTD, то это означает, что при ошибке (отсутствие донабора - это тоже ошибка) станция будет сначала проверять назначения в ПГМ144, если там что-либо назначено, то это и будет выполнено. Если в ПГМ144 для этих линий ничего не прописано, то только тогда станция отправит вызов на ATTD (кто назначен в ПГМ164).
Так, вот кажется рабочий вариант (возвращаемся к исходной задаче, отбить линию при переадресации по спид-ячейке и занятой линии):
- сделать пустую Hunt-группу (прописать какой-либо несуществующий номер абонента);
- в аттрибутах Hunt-группы указать:
Overflow Dest= SPEED № ячейки
Overflow Timer = 1 сек (минимальный)
- входящий вызов по ПГМ231 направить в эту Hunt-группу;
Т.е. через 1 сек вызов из Hunt-группы будет отправлен на SPD-ячейку. Если линия занята - станция отобьет линию (не будет обрабатывать по ПГМ167/2).
Проверьте.
Везде обложили))).... чего-то мне казалось, что данное утверждение справедливо только для аналоговых СО, а для PRI, attandant - это и есть attendant…
