есть труба Siemens 3000 Classic.
прописано в узле 2.
приехала труба в узел 1 и начялись интересные вещи.
при наборе ее родного номера с одной трубы - проключает.. тутже набираем с другой - войсгайд вещает что " абонент в данное время недоступен...."
обе трубы (с которых вызываем роуминговую) находятся в одной комнате.
иногда такое слышно и на проводных аппаратах.

случай другой..
приезжает труба из узла 1 в узел 2.
пытается набрать городской номер. в ответ войсгайд говорит " доступ к услуге или номеру не разрешон"
берем вторую такуюже трубу из первого узла - и все чудесно набирает.
вызываем эту (которая в город не набрала) по ее родному номеру - и все чюдно проходит. входящий звонок из узла 1 на трубу также проходит.

кароче мистика.

По первому случаю - надо смотреть в первую очередь загрузку баз, т.е. если труба то вызывается то нет - или нет ресурсов или проблемы с уровнем приема.
Со вторым случаем в первую очередь смотрим паблик нетворк категорию, с родного узла передан тоько номер категории, а содержимое будет смотреться на посещаемом сайте. Т.е. если третья категория на первом узле позволяет выходить на какую-то транковую группу, а в категории с таким же номером на втором узле стоит запрет на данную группу - выйти не сможете. Так-же бывает гемморой если выход сделан через специфические кнопки - supervision, substitution.
Соответственно легко может возникнуть ситуация когда входящая связь есть, а исходящей нет.
Смотрите нормально ли зарегистрировалась труба (dectsets и содержимое shell"а).
Еще интересно знать какой релиз, одинаковые ли они на разных станциях. Также в свое время писали что у DECT аппаратов (пришедшие в роуминге и номера шелов) не должны совпадать четыре последние цифры. Т.е. если аппарат 61234 прийдет и зарегистрируется в shell 71234 (или вообще такой есть) могут быть проблемы.



Редактировано 1 раз. Последний раз 11.03.2005 18:19 пользователем vad.

vad Написал:
-------------------------------------------------------
> По первому случаю - надо смотреть в первую очередь
> загрузку баз, т.е. если труба то вызывается то нет
> - или нет ресурсов или проблемы с уровнем
> приема.

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

когда перегруз или плохой прием - не так себя ведет аппарат. и это сказывается на несколько труб - проходил уже. зависла одна база в самом оживленном месте.



> Со вторым случаем в первую очередь смотрим паблик
> нетворк категорию

это погляжу детальнеее.

Так-же бывает гемморой если
> выход сделан через специфические кнопки -
> supervision, substitution.

нееее, это сложно, а нелюблю такие вещи... поэтому их не использую.



> Смотрите нормально ли зарегистрировалась труба
> (dectsets и содержимое shell"а).

проверял - регистрится нормально, и там и там есть.


> Еще интересно знать какой релиз, одинаковые ли они
> на разных станциях.

релиз один, даже патчи одинаковые.


R5.0Ux-d2.314-7-n-ru-c6s2

Business identification: R5.0Ux

Release:
DELIVERY d2.314
Patch identification: 7
Dynamic patch identification: n




Также в свое время писали что
> у DECT аппаратов (пришедшие в роуминге и номера
> шелов) не должны совпадать четыре последние цифры.

тут тоже нормально..

>
>
>
> Редактировано 1 раз. Последний раз 11.03.2005
> 15:19.
>

Насчет недозванивания, надеюсь connection категорией не баловались. такие проблемы бывали, но были связаны с радиотрактом (плохой прием), а тут я так понял с одной трубы на вашу не дозваниваются, на другие звонят без проблем, и с других до вас дозваниваются без проблем. Странно.

> надеюсь connection категорией не баловались

нее... не трогал. как с инсталили - так и стоит.

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

причем также может быть и с проводными.
были мысли что труба зацепилась за базу которая на обной плате - а другая труба на другой...
но вот сопоставить не могу данные команд dectview con и dectview ibs чтобы хоть отчегото оттолкнуться в поисках истины..

сдругими трубами токого непроисходит, тока с роуминговой.

Переинсталлируйте трубку.

ну это затруднитедльно - я на 2 узле раз в полгода появляюсь...

а случаем entity не передается между узлами?

Entity между узлами передается.

а тогда как себя поеведет труба с entity 7 из узла 1 на узле 2 в которой всего entity 1 и 2 в природе существуют.
может поэтому войсгайд вещает о " доступ к услуге или номеру не разрешон" при попытке набора городского номера.
а у втрой рабочей трубы entity совпали, ну чисто случайно...

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

номера шелов у меня на 2 узле 2999ХХ , на 1 узле 3999ХХ
сама нумерация на узле 2 20ХХ, на узле 1 - 3ХХХ

Выдержка из документации:
CAUTION
If a user numbering plan is set with more than 4 digits (QMCDU), the use of a same MCDU
for 2 or more handsets is to be banished on a same node including Roaming operation
(handset from an another node in visit in a shell).
Example
Do not have present on a same node an internal DECT handset with the QMCDU 61234 and a
DECT handset in visit in a shell with the QMCDU 51234 : their MCDU are identical.

А насчет Entity - у вас будут проблемы с исходящим звонком, поскольку при наборе префикса транковой группы соответствие между дискриминатором (логическим из группы) и реальным смотрится в entity/discriminator selector. Если Entity отсутствует, станция не знает каким дискриминатором воспользоваться. Если у вас entity не создалось по broadcast, создайте 7-е Entity ручками и проверьте правильность в entity/discriminator selector.

дак у меня совпадает или нет, последние 4 цифры.

а нафига тогда в шелах указывается entity или она не используется.
и както нелогично... а темболее если по броадкасту entity ппередать дак ваще лажа будет - если перетащится соответствие логического с филическим , а они отличяются у меня на разных узлах, то мне придется тащить и numbering discriminator чтоли?
а узлы находятся в разных городах и смысла они в чужом узле не имеют.
или я чегото не допонял опять.

При создании шела есть Entity, категории и тип аппарата, но при регистрации аппарата (роуминг) перетаскивается реальное содержимое аппарата (категория, тип аппарата, кнопки и т.п.)
А entity - тут все логично - у вас есть соответствие логического и реального дискриминатора, а содержимое в discriminator rules можете иметь разное.
Вам никто немешает на первом узле прописать 0 логический=0 реальный и в рулезах иметь 6-ти значную нумерацию, а на втором узле 0 логический=0 реальный и в рулезах 7-и значную нумерацию.

чюйствую надо на курсы очередные проситься :) а то чета нехватать инфы стало.

ну одну проблему победили...
осталась вторую - с моей трубой.

чета я совсем запутался... со словом entity.

в шелл прописывается та инфа которая имеется в home node?
если да - то в шелл пропишется только цифра из поля
user
entity number

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

Естественно соответствие будет смотреться на гостевом ноде.
Вообще при звонках в сети по жизни при исходящем звонке все смотрится там где в данный момент находится абонент, а при входящем, там где транковая группа.

вот теперь все встало на свои места... а то счяз наворотил бы делов..
тогда получается что логические и физические дискриминаторы могут быть разные на разных узлах. и нефиг заморачиваться... :)

спасиба Vad.