asterisk.ru

Добрый день!

Одна локалка, сервер с воткнутыми huwei е1550 (chan_datacard), asterisk 1.8.16.0, ubuntu 12.04 lts, freepbx, пиры в локалке, внешних пиров нет.
Иногда, если вызов идет ИЗнутри наружу, через chan_datacard, то происходит обрыв связи. Обычно, через 10 сек.
Если второй раз оператор перезванивает - то обрыва скорее всего не будет.
Свитч поменял.
Кабеля переобжал.
Конечное оборудование (китайские сип-телефоны) местами менял.

Код: Выделить всё

Called Datacard/i:352445045442705/0675363261_copy_4
    -- Datacard/datacard1-ac03 is making progress passing it to SIP/220-00000000
[2012-09-18 15:43:40] WARNING[19665]: chan_sip.c:18957 handle_request_info: Unable to convert DTMF event signal code to a valid value for INFO message on call 7a86daf9-94d37150@192.168.1.220
    -- Datacard/datacard1-ac03 answered SIP/220-00000000
[2012-09-18 15:44:04] WARNING[19665]: chan_sip.c:3687 retrans_pkt: Retransmission timeout reached on transmission 7a86daf9-94d37150@192.168.1.220 for seqno 22 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 6400ms with no response
[2012-09-18 15:44:04] WARNING[19665]: chan_sip.c:3716 retrans_pkt: Hanging up call 7a86daf9-94d37150@192.168.1.220 - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).
    -- Executing [h@macro-dialout-trunk:1] Macro("SIP/220-00000000", "hangupcall,") in new stack
    -- Executing [s@macro-hangupcall:1] GotoIf("SIP/220-00000000", "1?theend") in new stack

Ничего подходящего в интернетах по проблеме не нашел, (ведь все у меня в локалке находится, правда?)

Натолкните на мысль, пожалуйста, бо операторы кусаются

Лог, действительно, есть.
Интернета начитался уже.

Рекомендуют в интернетах:
1. Если у вас * за натом (у меня не за натом), то прописать externip, localnet. Прописал.
2. qualify = yes/no - Пробовал.
3. https://wiki.asterisk.org/wiki/display/ ... nsmissions - читал, про то что могут теряться пакеты. Свитч менял.
4. Есть мысль, что на 1.8.*.* - это бывает. А на 1.6.*.* - не бывает.

Переформулирую вопрос:
Какими средствами (и в каком порядке) Вы бы пользовались для отлова данной ошибки?

slavikus писал(а):1. Если у вас * за натом (у меня не за натом), то прописать externip, localnet. Прописал.

А зачем прописывать если нет клиентов/транков приходящих из-за NAT'а?

slavikus писал(а):huwei е1550 (chan_datacard), asterisk 1.8.16.0, ubuntu 12.04 lts

Я бы сменил старый и неподдерживаемый chan_datacard на его более новую и стабильную реинкарнацию - chan_dongle

Поставил chan_dongle. Поменял сетевуху на сервере.
Обрывы точно такие - же, ничего не изменилось.

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

Также, очень не нравится

Код: Выделить всё

chan_sip.c:18957 handle_request_info: Unable to convert DTMF event signal code to a valid value for INFO message on call 92150d6f-94e53850@192.168.1.220

который предшествует обрыву.
По нему есть какой то патч https://reviewboard.asterisk.org/r/1722/, но он не совсем в тему.

nat прописал - т.к есть отлично, без претензий работающий внешний транк. Обрывы только при исходящих на e1550.

Может у кого еще какие идеи есть для проверки?

с софтфона протестировать надо бы

... паралельно пингая астериска.

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

Подскажите, кроме sip debug - что использовать для отладки? Что-то мне не нравится ошибка про dtmf, как ее отловить-анализировать?

выставите на всех софтфонах и железе передачу dtmf по RFC-2833
в астериск на пирах
dtmfmode=rfc2833
canreinvite=no

и не будет вываливаться "...for INFO message..."

а сигналку снимать лучше снифером с записью в файл http://wiki.freeswitch.org/wiki/Packet_Capture
потом анализировать wireshark-ом

Пока загадка осталась, на софтфонах все изумительно. Так как повлиять на железячные телефоны DVP-100 практически невозможно (настроек там мало), поставил каждому оператору по софтфону и по железяке.

dtmfmode=rfc2833
canreinvite=no
и не будет вываливаться "...for INFO message..."

Поставил, не оно, вываливается и обрывается.
Достало.

Отложил дебаг до лучших времен, так сказать. Про дальнейшее расследование буду информировать уважаемых коллег.

asterisk.ru

Retransmission timeout reached

Retransmission timeout reached

Re: Retransmission timeout reached

Re: Retransmission timeout reached

Re: Retransmission timeout reached

Re: Retransmission timeout reached

Re: Retransmission timeout reached

Re: Retransmission timeout reached

Re: Retransmission timeout reached

Re: Retransmission timeout reached