Альтернативный индекс DMT Опции

[vdf]

Привет ВСЕМ !

В доке написанно "Если при исходящем вызове невозможно использовать внешнюю линию из заданной группы, будет использован определенный в этом пункте индекс DMT для выбора свободной линии"

что понимать под "невозможно использовать внешнюю линию", особенно в DSS это как понимать.
Послали SETUP пришло RELEASE COMPLETE c cause "No circuit/channel available", невозможно использовать внешнию линию, перейдет ли на альтернативный индекс DMT

Спасибо

[All is not what ...]

ДУМАю что нет, а почему просто не попробуете?

[vdf]

ДУМАю что нет, а почему просто не попробуете?

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

[harris]

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

ИМХО, в данном случае - нет. Невозможно, это если все каналы заняты, поток упал (D-канал отсутствует), станция "не видит" плату PRIB (удалена из станции)... Но, если есть возможность, то лучше проверить...

[All is not what ...]

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

ну почему вы думаете что сдесь есть люди перепробовавшие станцию во всех извесных позах...
ваш случай ещё постаратся нада смоделировать, а если у вас он имеет место быть почему не попробовать и не поделится с остальными?

[vdf]

ну почему вы думаете что сдесь есть люди перепробовавшие станцию во всех извесных позах...

Сетевой разум это сила, да прибудет она с нами
Всегда найдется тот кто уже наступал на грабли, главное чтобы он расказал об этом.

ваш случай ещё постаратся нада смоделировать, а если у вас он имеет место быть почему не попробовать и не поделится с остальными?

Задача следующая, сделать насколько возможно, альтернативные пути для исходящих звонков, при возникющих проблемах на основном пути.
Пока все в теории, надо применить на практике
Возможные пролеммы
1. Полное падение основного канала
2. Полная занятость основного канала
3. Где то на сети при вызове через основной канал, вызов не проходит (возможно по кучи причин например, "No circuit/channel available", всем понятная причина)

Возможно еще что но я не придумал еще

Как я понял из обсуждения "Альтернативный индекс DMT" будет только работать только по тем причинам которые может проверить сама PBX (сбой оборудования ....).

Посомтрим что покажет эксплуатация.

Спасибо

[All is not what ...]

Сетевой разум это сила, да прибудет она с нами
Всегда найдется тот кто уже наступал на грабли, главное чтобы он расказал об этом.

так внесите свой вклад!

1. Полное падение основного канала
2. Полная занятость основного канала
3. Где то на сети при вызове через основной канал, вызов не проходит (возможно по кучи причин например, "No circuit/channel available", всем понятная причина)

первые два случая должны сработать

А у вас есть резервный канал и какой?

[vdf]

так внесите свой вклад!
первые два случая должны сработать

Проверенно при потере потока переходит на альтернативный маршрут,
забить 30 каналов, пока не когда, а по данным оператора у нас занимаюся не больше 15 каналов, а вот если бы по DSS cause бы обрабатывались так ценны бы не было, так как не прозвон или нехватка каналов у провайдера, такое быть может

To:harris
А кореякам подбросить мысль обрабатывать DSS для использования альтернативного маршрута, или это не кому не надо, или уже так не патчится код.

А у вас есть резервный канал и какой?

Пока аналоговые CO, ГТС-ные.

[harris]

Проверенно при потере потока переходит на альтернативный маршрут,
забить 30 каналов, пока не когда, а по данным оператора у нас занимаюся не больше 15 каналов, а вот если бы по DSS cause бы обрабатывались так ценны бы не было, так как не прозвон или нехватка каналов у провайдера, такое быть может

To:harris
А кореякам подбросить мысль обрабатывать DSS для использования альтернативного маршрута, или это не кому не надо, или уже так не патчится код.

LCR выбирает маршрут исходя из доступности системного ресурса в самой станции, а не исходя из условий в TфОП. Как только маршрут выбран (поток стоит, есть свободный канал), текущая задача LCR завершается и отсылается Setup. Вы же хотите, чтобы LCR полностью следила за процессом установления соединения по сигнальным сообщениям и получив от провайдера отбой с ОПРЕДЕЛЕННЫМИ причинами (нет канала/ресурс недоступен и т.п.) искала альтернавное соединение, т.е. решала бы проблемы провайдера. Это совсем другой уровень контроля соединения.
А почему провайдер не обеспечивает выбор альтернативного маршрута из имеющихся у него ресурсов, ведь в данной ситуации между вашей станцией и провайдером канал есть, а вот дальше по сети у провайдера нет ресурсов. ИМХО, это проблема провайдера.
Нет, конечно, задать такой вопрос корейцам можно, но ИМХО ответ заранее известен. (Например, поменяйте провайдера на более надежного и с большими ресурсами).
Кроме того, по сути Ваш изначальный вопрос был чисто теоретическим, поскольку реально-то проблем с провайдером нет...

[nikol]

А не много ли Вы хотите от LDK???? К примеру на AVAYA есть вещи, которые описал в шутку harris. Но там цена такая, что наш спец, по AVAYA, почитав наш форум, просто судорожно хихикал!! Просто господа, контролируйте свои запросы...

[harris]

А не много ли Вы хотите от LDK???? К примеру на AVAYA есть вещи, которые описал в шутку harris. Но там цена такая, что наш спец, по AVAYA, почитав наш форум, просто судорожно хихикал!! Просто господа, контролируйте свои запросы...

Да, на Definity похожая фича есть, но это уже не LCR.
Еще раз повторюсь: можно запросить разработчиков насчет внедрения такого сервиса, но мне кажется, что скорее всего в ответ будет отказ (ведь есть же более насущные задачи для LDK), либо они возьмутся за разработку и "сломают" уже отработанный софт (а это, увы, не раз бывало).
Тут нужно руководствоваться принципом "Не навреди", как хирургам...

[nikol]

Да, на Definity похожая фича есть, но это уже не LCR.
Еще раз повторюсь: можно запросить разработчиков насчет внедрения такого сервиса, но мне кажется, что скорее всего в ответ будет отказ (ведь есть же более насущные задачи для LDK), либо они возьмутся за разработку и "сломают" уже отработанный софт (а это, увы, не раз бывало).
Тут нужно руководствоваться принципом "Не навреди", как хирургам...

Да Игорь, по моему мнению, этот сервис на х.. не нужен!!! Иначе это будет уже не LDK!!!! Хотя, по моему мнению, добавить его не сложно.....

[harris]

Да Игорь, по моему мнению, этот сервис на х.. не нужен!!! Иначе это будет уже не LDK!!!! Хотя, по моему мнению, добавить его не сложно.....

Да, нет же... Я-то как раз думаю наоборот, что впихнуть такой сервис в рамки существующего LCR весьма проблематично, но, наверное, наличие такого сервиса может оказаться в определенных ситуациях достаточно полезным... ИМХО, чем больше возможностей, тем лучше... Но...(см. выше)...
И пока неясно, насколько такой сервис в действительности востребован. На данный момент только один человек (vdf) задался этим вопросом, и то гипотетически...

[Гость_новенький_*]

День добрый...
Если позволите выскажу свои соображения....
То что ЛДК отрабатывает альт. маршрут это имеет место быть...Так как есть несколько банков где по условиям в атс подключено несколько потоков от разных провайдеров, как раз потому что потеря связи там чревато последствиями ( слижком много модемных пулов клиент банк там завязано на ЛДК ).
Так вот, при пропадании 1 уровня одного потока атс идеально отрабатывает переход по альт. маршруту( плюс похожая схема на стороне прова), НО...только при пропадании конкретно 1-го уровня.
К примеру СРС не отрабатывается( по крайней мере со стороны ЛДК)...Поэтому когда городские колодцы заливает водой и поток не ложится полностью, а начинае "прыгать" админам приходится жостко вытаскивать шнурок с платы - это к примеру
Так вот я думаю что данная фича была-бы очень полезна на атс ( имеется ввиду что б атс понимала ошибки в потоке )...
С другой стороны я полностью поддерживаю harrisа , и думаю что это не тот уровень атс, и коррейцы НИЧЕГО не сделают в данном направлении...Как сказал один из наших бывших президентов "Имеем то - что имеем"

[sendi]

Полнстью поддерживаю, иметь желание чтоб АТС отрабатывала за провайдера, а зачем нужен такой провайдер?
На своем опыте знаю, у провайдеров "все всегда работает", пока не ткнеш лицом, как нашкодившего котенка. Деньги им за что платите? После нескольких таких стычек, отношение провайдеров к Нам изменеилось в лучшую сторону.

[ЛыЖник]

Полнстью поддерживаю, иметь желание чтоб АТС отрабатывала за провайдера, а зачем нужен такой провайдер?
На своем опыте знаю, у провайдеров "все всегда работает", пока не ткнеш лицом, как нашкодившего котенка. Деньги им за что платите? После нескольких таких стычек, отношение провайдеров к Нам изменеилось в лучшую сторону.

Полностью согласен по провайдерам. Пинать их надо чаще и больнее, тогда начинают шевелить задним местом.