Список форумов Asterisk Forum Asterisk Forum
The Asterisk Open Source PBX - Russian Community
 
 FAQFAQ   ПоискПоиск   ПользователиПользователи   ПравилаПравила   ГруппыГруппы   ИзбранноеИзбранное    LinksСсылки   РегистрацияРегистрация 
 RSSRSS   ПрофильПрофиль   Войти и проверить личные сообщения   ВходВход 

Нужно проверить баг с переименованием пиров в sip.conf, Asterisk 1.4.24.1

 
Список форумов Asterisk Forum -> Asterisk-Dev    вывод темы на печать
Предыдущая тема :: Следующая тема  
Автор Сообщение
Romik
Модератор


Зарегистрирован:
10.03.2005
Сообщения: 767

Статус: Оффлайн 

СообщениеДобавлено: Чт Июн 04, 2009 15:24    Заголовок сообщения: Нужно проверить баг с переименованием пиров в sip.conf, Asterisk 1.4.24.1

Кажется баг... только что после добавления пирам alterfon & sipnet qualify=yes сделал sip reload и сразу sip show peers, пиров с именами trunk_1 и trunk_2 у меня в помине нет (раньше так назывались alterfon & sipnet, но я их переименовал уже полтора дня как), однако получил в консоли:
Код:
102/102                    192.168.1.248    D   N      27864    UNREACHABLE
101/101                    192.168.1.174    D   N      26024    OK (101 ms)
125/125                    (Unspecified)    D   N      0        UNKNOWN
199/199                    xxx.xxx.xxx.xxx     D   N      5063     OK (37 ms)
alterfon/xxxxxxxx             83.219.240.148       N      5060     UNREACHABLE
sipnet/xxxxxxx             212.53.40.40         N      5060     UNREACHABLE
76 sip peers [Monitored: 5 online, 71 offline Unmonitored: 0 online, 0 offline]
iris*CLI>
iris*CLI>
iris*CLI>
    -- Got SIP response 405 "Method Not Allowed" back from 83.219.240.148
[Jun  4 18:12:44] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'trunk_1' is now Reachable. (15ms / 2000ms)
[Jun  4 18:12:44] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'trunk_2' is now Reachable. (15ms / 2000ms)
[Jun  4 18:12:48] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'sipnet' is now Reachable. (15ms / 2000ms)
[Jun  4 18:12:48] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'alterfon' is now Reachable. (15ms / 2000ms)
iris*CLI>


Попробуйте воспроизвести.
1. заводишь пару пиров-френдов с qualify... каким-нибудь, или 0
2. sip reload
3. sip show peers
4. переименовываешь пиры в конфиге
2. sip reload и сразу
3. sip show peers
4. должно выскочить.

Позже у меня повлялось:
Код:
    -- Got SIP response 405 "Method Not Allowed" back from 83.219.240.148
[Jun  4 18:12:44] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'trunk_1' is now Reachable. (15ms / 2000ms)
[Jun  4 18:12:44] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'trunk_2' is now Reachable. (15ms / 2000ms)
[Jun  4 18:12:48] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'sipnet' is now Reachable. (15ms / 2000ms)
[Jun  4 18:12:48] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'alterfon' is now Reachable. (15ms / 2000ms)
[Jun  4 18:13:48] NOTICE[23967]: chan_sip.c:16652 sip_poke_noanswer: Peer 'trunk_1' is now UNREACHABLE!  Last qualify: 15
[Jun  4 18:13:48] NOTICE[23967]: chan_sip.c:16652 sip_poke_noanswer: Peer 'trunk_2' is now UNREACHABLE!  Last qualify: 15
[Jun  4 18:13:52] NOTICE[23967]: chan_sip.c:16652 sip_poke_noanswer: Peer 'sipnet' is now UNREACHABLE!  Last qualify: 15
[Jun  4 18:13:52] NOTICE[23967]: chan_sip.c:16652 sip_poke_noanswer: Peer 'alterfon' is now UNREACHABLE!  Last qualify: 15
[Jun  4 18:14:47] NOTICE[23967]: chan_sip.c:7715 sip_reg_timeout:    -- Registration for 'xxxxxxxxxxx@sipnet.ru' timed out, trying again (Attempt #1)
    -- ast_get_srv: SRV lookup for '_sip._udp.sipnet.ru' mapped to host sipnet.ru, port 5060
[Jun  4 18:15:07] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'sipnet' is now Reachable. (15ms / 2000ms)
[Jun  4 18:15:07] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'alterfon' is now Reachable. (15ms / 2000ms)
[Jun  4 18:15:11] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'trunk_1' is now Reachable. (14ms / 2000ms)
[Jun  4 18:15:11] NOTICE[23967]: chan_sip.c:13019 handle_response_peerpoke: Peer 'trunk_2' is now Reachable. (15ms / 2000ms)

_________________
Человек мира. RHCE + clustering.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
IgorG
Модератор


Зарегистрирован:
21.11.2005
Сообщения: 1054
Откуда: Россия, Омск

Статус: Оффлайн 

СообщениеДобавлено: Чт Июн 04, 2009 16:37    Заголовок сообщения:

Подтверждаю
_________________
OpenSUSE 11.2 / Asterisk-trunk / Celeron 1100 (512mb) / chan_lcr / Linksys / Aastra 9112i
http://igorg.ru
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора Skype Name Jabber ID
Romik
Модератор


Зарегистрирован:
10.03.2005
Сообщения: 767

Статус: Оффлайн 

СообщениеДобавлено: Чт Июн 04, 2009 17:01    Заголовок сообщения:

Версия Asterisk-trunk 1.4 или 1.6? // Из подписи не понятно Embarassed
_________________
Человек мира. RHCE + clustering.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
IgorG
Модератор


Зарегистрирован:
21.11.2005
Сообщения: 1054
Откуда: Россия, Омск

Статус: Оффлайн 

СообщениеДобавлено: Чт Июн 04, 2009 17:31    Заголовок сообщения:

У меня все есть. Проверял на 1.4.24 и на 1.4-svn. Посмотрел код. Скорее всего при sip reload где-то запланированная отправка OPTIONS пакетов не отменяется, а данные остаются в памяти на старые пиры. Проверь ещё на 1.6, там эта часть кода переписана и такой ошибки может не быть.

А вообще переводи все что написал в первом сообщении на инглиш и отправляй на issues.asterisk.org

_________________
OpenSUSE 11.2 / Asterisk-trunk / Celeron 1100 (512mb) / chan_lcr / Linksys / Aastra 9112i
http://igorg.ru
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора Skype Name Jabber ID
Romik
Модератор


Зарегистрирован:
10.03.2005
Сообщения: 767

Статус: Оффлайн 

СообщениеДобавлено: Чт Июн 04, 2009 18:08    Заголовок сообщения:

https://issues.asterisk.org/view.php?id=15274
_________________
Человек мира. RHCE + clustering.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
ddv



Зарегистрирован:
01.06.2009
Сообщения: 10

Статус: Оффлайн 

СообщениеДобавлено: Пт Июн 05, 2009 13:22    Заголовок сообщения:

У меня аналогичная проблема с OPTIONS пакетами в версии 1.6.1.0 в режиме Realtime. Суть в том, что если в режиме qualify=yes клиент уходит не разрегистрировавшись, то астериск начинает забрасывать клиента OPTIONS пакетами. И будет он это делать каждые 10 секунд до посинения (независимо от того существует такой пир или нет) пока клиент не появится снова и судя по коду chan_sip никакого таймаута не предусмотренно. Если клиент появится в сети снова, то по идее все восстанавливается. Но иногда, по непонятным причинам, он продолжает слать по старому OPTIONS пакеты каждые 10 секунд и после появления клиента. И если клиент опять некорректно пропадет, то высылается уже пара пакетов OPTIONS...Именно так я и заметил эту проблему, когда после двух дней тестов телефона мне начало приходить десяток пакетов OPTIONS в секунду. При этом иногда на астериске появляются зависшие SIP OPTIONS транзакции. Кроме того я выяснил, что если в таком режиме поиграться с sip qualify peer, то можно заставить астериск прекратить посылку OPTIONS пакетов. Но в моем случае все хуже, потому что если сделать sip reload, то все недоступные realtime пиры пропадают и я уже не могу сделать sip qualify peer, хотя астериск по прежнему посылает им OPTIONS.
Анализируя код chan_sip я выяснил что рассылкой OPTIONS пакетов занимается функция sip_poke_peer. Причем один раз попав туда обратного пути уже нет, так как она начинает сама добавлять себя в scheduler для посылки очередного пакета. Например, в случае не прихода ответа от пира вызывается sip_poke_noanswer которая в любом случае планирует запуск sip_poke_peer через фиксированный интервал времени DEFAULT_FREQ_NOTOK. И ей наплевать что пира уже может не существовать, потому что , насколько я понял, они делают reference на пир и сами его хранят. Так что даже если chan_sip уберет пир из своего списка, то sip_poke_peer все равно будет хранить эту ссылку в scheduler.
Скорее всего разработчики где то пропустили очистку scheduler'а при перезагрузке или удалении пиров.

Дмитрий
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
Romik
Модератор


Зарегистрирован:
10.03.2005
Сообщения: 767

Статус: Оффлайн 

СообщениеДобавлено: Пт Июн 05, 2009 15:55    Заголовок сообщения:

В багтрекер комментарием добавьте, пожалуйста.

Added after 2 hours 25 minutes:

ddv, thanks

_________________
Человек мира. RHCE + clustering.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
ddv



Зарегистрирован:
01.06.2009
Сообщения: 10

Статус: Оффлайн 

СообщениеДобавлено: Пт Июн 05, 2009 16:00    Заголовок сообщения:

Вы можете попробовать в sip_registry_destroy (chan_sip) после

AST_SCHED_DEL(sched, reg->expire);

добавить

AST_SCHED_DEL(sched, reg->pokeexpire);

По идее это должно отменить вызов следующего sip_poke_peer при удалении пира из sip registry.

Дмитрий
Вернуться к началу
Посмотреть профиль Отправить личное сообщение Посетить сайт автора
Список форумов Asterisk Forum -> Asterisk-Dev Ответить на тему
Страница 1 из 1

Добавить в Избранное

 
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
You cannot attach files in this forum
You cannot download files in this forum