Peers Unreachable для телефонов, находящихся в одной сети с *
Откуда: Москва
Сообщений: 770
|
Re: Peers Unreachable для телефонов, находящихся в одной сети с *
Да, srvlookup=no не помогает. Я пробовал уже давно.
Во второй редакции трикса без слез описывается эта проблема.
В случае падения DNS астериск пытается последовательно зарегать транки. При этом каждая итерация длится до нескольких секунд. В это время не получается ни звонить, ни принимать звонки.
Если у вас один-два транка, то проблема будет проявляться лишь частично - звонки в обе стороны будут идти с задержкой, иногда сразу проходя, иногда сразу срываясь.
Если транков много, то позвонить ниоткуда и никуда не удастся.
Это - проблема дизайна астеиска. Пока она не решена, и толком не ясно, решается ли.
|
Сообщений: 6521
|
Re: Peers Unreachable для телефонов, находящихся в одной сети с *
Типа, как мне звонить через sipnet, если падает интернет?
|
Откуда: Москва
Сообщений: 770
|
Re: Peers Unreachable для телефонов, находящихся в одной сети с *
ded: Типа, как мне звонить через sipnet, если падает интернет?
Не совсем.
Как раз таки проблема в сабже: внутренние телефоны отваливаются от астериска, и даже если каналы в город через TDM, то звонить ни в город, ни по офису, ни принимать звонки из города по FXO.
|
Сообщений: 6521
|
Re: Peers Unreachable для телефонов, находящихся в одной сети с *
А у наших клиентов не отваливаются, каналы в город через TDM, звонят в город, и по офису.
Только не спрашивайте "Но как, Холмс?"
Скучно и надоело.
|
Откуда: Москва
Сообщений: 770
|
Re: Peers Unreachable для телефонов, находящихся в одной сети с *
Несомненно, srvlookup=no.
Я это понял по предыдущим постам.
Просто у нас - неправильный фен-шуй.
|
Сообщений: 6521
|
Re: Peers Unreachable для телефонов, находящихся в одной сети с *
Да-дад, и это, и то, искуственную пальму надо не в угол а напротив входа.
|
Сообщений: 156
|
Re: Peers Unreachable для телефонов, находящихся в одной сети с *
Я даже сталкивался с таким простым случаем (я о нем уже писал в этом форуме). Астериск и 5 SIP телефонов в одной сети, испытывались BLF на Томсонах. Никаких внешних линий, никаких имен hostname (только ИП-адреса), все адреса - статичные. ДНСом был один Win2008 который определял имена для хостов внутри сети, а остальные запросы форвардил на провайдера ИНета.
Наблюдались огромные задержки в работе BLF на всех телефонах. Лампочка о статусе BUSY загоралась на телефонах через 3-5 секунд и соответственно наооборот - человек уже положил трубку - а у всех он BUSY. Та же история с PICKUP.
Телефоны не отваливались - но работать было не возможно. Тогда же заметил, что при обычном подключение по SSH (через Putty), между вводом имени пользователя и приглашением ввести пароль - была задержка в те же 3-5 секунд.
Ну и естественно все проблемы решились проверкой WIN2008 - оказалось, что форварды он по ошибке пересылал на несуществующий ДНС где-то в Инете.
|
Откуда: Москва
Сообщений: 770
|
Re: Peers Unreachable для телефонов, находящихся в одной сети с *
Да, вот кстати, то про что я писал несколько выше:
ALL PHONES UNUSABLE IF INTERNET CONNECTION IS LOST.
This only happens if users are using SIP Trunks. Luckyly, those using IAX trunks only
are spared from this issue.
Some say it is not a bug but to me if users have to make modification to get all the
phones to work locally and accept PSTN calls, something is terribly wrong and therefore it
is a bug and I think it is a fundamental flaw in the design of Asterisk.
Asterisk is assuming that when a call is being made, the call is going to be made via a
trunk IF a sip trunk is recorded and enabled. Therefore Asterisk will scan for SIP trunks
availability. Once Asterisk finds a trunk it will start sip. If it does not find an available trunk
it will give up and start sip then you can make a call. However if you have more than one
SIP trunks, it will scan for all enabled SIP trunks until the verification times out. If you also
happen to have 10 SIP trunks, all 10 will be verified first before you can even use your
phones.
In normal cases where internet connection is available, this will only take a couple of
seconds to complete, but if internet connection is out, the verification process will take for
ever till it just die away and all your extensions rendered useless.
If no SIP trunk is recorded or enabled at all, then it will start sip immediately and you can
make a call. This issue only appears for those using SIP trunks, especially multiple SIP
trunks.
This is not a major issue if you only have 1 sip trunk because when Asterisk failed on that
trunk, it will give up and start sip. The only thing you notice will be a slight delay between
your dialling and the other phone ringing. Normally it is just a slight irritation - nothing
more.
The problem starts when you have multiple SIP trunks. If you have 2 SIP trunks, the delay
before Asterisk gives up is a little longer and you can still dial internal number after a long
delay. In many cases the delay is enough for users to think that nothing is happening, but
if you keep waiting it will dial.
However if you have 3 or more trunks, the delay becomes so long for Asterisk to cycle
through all your SIP trunks and the phone system becomes unusable, just gave up and
dies.
This is where the fundamental flaw is.
Asterisk should dial the number without scanning for SIP trunk (even if you have SIP
trunks) unless the number dialed is part of an outbound route that requires SIP trunk.
IAX is spared this hassle why not SIP?
I tested this by adding 1 sip trunk then 2 sip trunks etc. The delay becomes progressively
longer and longer the more sip trunks I added.... which brought me to the above
conclusion.
Question is; how do we get around this? There is a way but it is a kludge. It works and
you don’t have to fiddle with codes or create a local DNS or BIND and what not that the
normal digger would not know how.
This is a project you should try.
|
Сообщений: 6521
|
Re: Peers Unreachable для телефонов, находящихся в одной сети с *
alphil: Тогда же заметил, что при обычном подключение по SSH (через Putty), между вводом имени пользователя и приглашением ввести пароль - была задержка в те же 3-5 секунд.
Ну и естественно все проблемы решились проверкой WIN2008 - оказалось, что форварды он по ошибке пересылал на несуществующий ДНС где-то в Инете.
Отличное наблюдение!
Я тоже всегда точно знаю, если при установке новой станции удалённо, при ssh логине задумывается долго - проблема ДНС. Чаще всего - провайдерская. Вот поэтому то мы и держим свою сеть ДНС, которые не просто кэширующие столбики, вот поэтому каждая новая станция получает имя FQDN, которое нормально резольвится, в общем - с ДНС не так просто всё, но если настроено - нет гимора вообще. И вот клиентские то станции и имеют ход к нам только по IAX, как-то вот так и сложилось интуитивно.
|
|