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

Разработка и отладка Asterisk и его приложений.

Модераторы: Admins, Модераторы

Ответить
Romik
Модератор
Сообщения: 767
Зарегистрирован: 10 мар 2005, 20:06
Контактная информация:

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

Сообщение Romik » 04 июн 2009, 15:24

Кажется баг... только что после добавления пирам 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
Модератор
Сообщения: 1054
Зарегистрирован: 21 ноя 2005, 05:59
Откуда: Россия, Омск
Контактная информация:

Сообщение IgorG » 04 июн 2009, 16:37

Подтверждаю
OpenSUSE 11.2 / Asterisk-trunk / Celeron 1100 (512mb) / chan_lcr / Linksys / Aastra 9112i
http://igorg.ru

Romik
Модератор
Сообщения: 767
Зарегистрирован: 10 мар 2005, 20:06
Контактная информация:

Сообщение Romik » 04 июн 2009, 17:01

Версия Asterisk-trunk 1.4 или 1.6? // Из подписи не понятно :oops:
Человек мира. RHCE + clustering.

Аватара пользователя
IgorG
Модератор
Сообщения: 1054
Зарегистрирован: 21 ноя 2005, 05:59
Откуда: Россия, Омск
Контактная информация:

Сообщение IgorG » 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

Romik
Модератор
Сообщения: 767
Зарегистрирован: 10 мар 2005, 20:06
Контактная информация:

Сообщение Romik » 04 июн 2009, 18:08

Человек мира. RHCE + clustering.

ddv
Сообщения: 10
Зарегистрирован: 01 июн 2009, 04:19
Контактная информация:

Сообщение ddv » 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
Модератор
Сообщения: 767
Зарегистрирован: 10 мар 2005, 20:06
Контактная информация:

Сообщение Romik » 05 июн 2009, 15:55

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

Added after 2 hours 25 minutes:

ddv, thanks
Человек мира. RHCE + clustering.

ddv
Сообщения: 10
Зарегистрирован: 01 июн 2009, 04:19
Контактная информация:

Сообщение ddv » 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.

Дмитрий

Ответить