0
3
Добрый день,
Возникла определенная проблема с конкретным локальным SIP провайдером — Астериск теряет регистрацию если сервер провайдера временно уходит offline (например они ребутят свое оборудование), при это если смотреть список пиров Астериска «sip show peers» то пир показывается как Online (то есть получается что Астериск думает что с пиром всё ок), а на самом деле звонки через этого пира отлупливаются Forbidden. Провайдер говорит что нашей регистрации не видит на своем сервере. Проблема лечится руками через reload — астериск заново регистрируется, но это какое-то неправильное решение. Существует ли в Астериске какой-нибудь функционал чтобы решить данную проблему, то есть чтобы Астериск сам мониторил состояние пира и перерегистрировался в случае если пир ушел оффлайн и потом вернулся?
[locsip]
type=friend
regexten=124444
context=office
host=sip.localgw.ru
defaultuser=124444
authuser=124444
secret=XXXXXXXXXXXXXX
insecure=port,invite
qualify=yes
nat=no
call-limit=20
busylevel=20
Версия астериска — Asterisk 1.8.11.1-1digium1~squeeze
Comments
In discussion it came up that lnd currently sends an onion error with the PERM bit set when the peer is offline. This actually informs the sender that they should fully remove the channel from the graph and not attempt to route back over the channel again, losing out on routing revenue. Instead, temporary_channel_failure is intended to cover this, per the BOLT spec.
Our behavior is based on this fragment:
if the receiving peer specified by the onion is NOT known:
return an unknown_next_peer error.
So IMO the wording can be tightened up here, as temporary_channel_failure is expressed sort of as a catch all («an otherwise unspecified»), so perhaps we need to define a stricter ordering here w.r.t interpretation and also enumerate all the cases that temporary_channel_failure should actually be sent.
Agreed the BOLTs should be tightened, but the peer is clearly known, even if they’re offline. The other point is the definition of PERM is much more clear, and unknown_next_peer has the PERM bit set.
FWIW, the use of temporary_channel_failure as a bit of a catch-all is also a deliberate decision to provide a more general protection/strategic ambiguity as to balance probing, so there’s very good reason for it to be very broad.
C-Otto
added a commit
to C-Otto/lnd
that referenced
this issue
Aug 6, 2022
Only return a permanent "unknown next peer" error if we are unable
to find the channel link. In other cases, especially if the peer
is just offline, return a "temporary channel failure" so that future
retries are encouraged.
fixes lightningnetwork#6603
C-Otto
added a commit
to C-Otto/lnd
that referenced
this issue
Aug 6, 2022
Only return a permanent "unknown next peer" error if we are unable
to find the channel link. In other cases, especially if the peer
is just offline, return a "temporary channel failure" so that future
retries are encouraged.
fixes lightningnetwork#6603
Since LND will automatically send out a disabled update for an offline peer, maybe the error should be channel disabled
I think this is already done by another implementation
Hmm, good point, both would be valid here, I assume, in either case you’d include a channel_udpate with the disabled bit set, which ultimately the sender should treat the same — they mostly look at the channel_update and apply it to their graph, less look at the specific issue.
Такая ошибка может быть вызвана любыми неполадками подключения к Интернету непосредственно самой 1С.А подключаться она может по разным причинам, например проверка обновления или загрузка курсов валют. Также возможен вариант, что выход 1С в интернет заблокирован вашим системным администратором через фаервол или прокси. В этом случае вам необходимо, чтобы ваш системный администратор настроил доступ для 1С.
Если у вас нет необходимости загружать автоматически курсы валют, то загрузку можно отключить в настройках.
Для Бухгалтерии ред.2
Сервис – Настройки пользователя.
Хотите узнать больше по этому вопросу?
Подпишитесь на нашу рассылку новостей
Подписаться
Чтобы задать вопрос или предложить тему статьи, нажмите на кнопку ниже:
Предложить статью
I have this problem too (and others) that are driving me crazy for a week now. I’m seeding 115 torrents (my own files, I created them**) and I don’t download. Things were fine until last week when the upload lowered from 20-50 kBps to 0.1 to 3 kBps. I was using version 2.1.1. When I started logging the trafic I noticed that:
1. I was beeing flooded with «no such torrent» and about 10 incomming connections per second (aha! that’s why my traffic was so heavy in the «local connection» window). I think this is the so dreaded DoS (Denial of Service).
2. After upgrading to version 3 and re-adding all the torrents (I changed my disc), when it starts my own IP is an incomming connection and is refused with the message «disconnect: same ID» and is banned, in another message in this forum was refered to as «loopback». ALL the torrents I upload do this, and for each one a port is opened (is it closed?), and consumes 10 minutes doing it. Until now I found no solution. I thought it was the «initial seed» parameter in the torrent, but reading its explanation seems that’s not it.
3. The public trackers I use are «timed out» for days (now one is back), i.e., tracker.openbittorrent and tracker.publicbt.
4. The network sign was green, but when I checked the network it said «port is not open (but you can still download)». It lasted for days, now it’s ok.
Following and advise in this forum I disabled: DHT, uPnP, NAT-PMP, ask tracker for scrape, uTP, Local Peer Discovery, resolve IPs. I also lowered the «global maximum number of connections» to 25 (was 120) and «randomize port each start». The number of incomming connections lowered dramatically and my traffic is normal (almost no activity), but:
5. 99% of the incomming connections are disconnected with «Is seed» or «peer error: offline (timed out)» (after 21 seconds or 9 seconds if it is uTP). My searches to resolve it went nowhere, like this topic.
What’s happening? I contacted my ISP, they advised me to turn off my modem for eight hours to change my IP but it didn’t change. Is it the software, the ISP, my modem (Motorola SBV5121i)? Does the DoS affect the upload speed? I tryed Vuze but I didn’t like it, it took me hours to learn to use it and I gave up. I was happy yesterday, someone could upload one torrent (230 MB) at 47 kBps but the next client (foreign, a portuguese) for the same torrent, starting right after the other finished, was uploading at 0.1-3 kBps and lost connection after 5 min, and coudn’t reconnect (peer error: offline). There’s a pattern when the speed is low: it starts at 3.x kBps and drops 0.5-0.1 kBps each second, when it reaches 0.1 returns to 3 kBps.
** I’m recording The Dog Whisperer from TV, in Brazil it’s «O Encantador de Caes». You can find the torrents in Seedpeer and BTJunkie.
Loading