Пожалуйста, войдите здесь. Часто задаваемые вопросы О нас
Задайте Ваш вопрос

Астер рвет звонок.

0

Доброго времени суток, уважаемое сообщество.

Есть система, FreeBSD 8.4 + Asterisk 1.8.31 (Нет, не та что в предыдущем вопросе.)

На 3х узлах эта связка работает на ура, никаких проблем нет но, есть один из узлов на котором иду постоянные обрывы связи, причем, все астеры настроены совершенно идентично.

Сегодня решил tcpdump'ом снять пакеты которые проходят от телефона до астера... image description

и, от астера к провайдеру...

image description

и увидел то, что астер в какой-то определенный момент отсылает в сторону провайдера CANCEL а оттуда приходит Request terminated. И, как говорит человек который говорил по телефону, связь рвется.

Есть какие-нибудь предположения, по каким причинам астер отправляет в сторону провайдера CANCEL? И что он хотит этим CANCEL'ом отменить?

ЗЫ. Естественно, принудительно разговор ни кто не обрывал. Я сначала тоже думал что сами трубки кидают а потом жалуются на обрывы но, статистика собранная за вчера/сегодня, показывает что обрывы не по вине пользователей. Судя по количеству пакетов с CANCEL'ом связь рвется часто, не всегда но часто. И это только на одном астере из 5 которые есть.

Что нужно ещё чтобы было более понятней?

update... general и настройки провайдера и телефона

    [general]
context = dialin
regcontext = dialin
allowguest = no
allowoverlap = yes
;bindport = 5060
;bindaddr = 0.0.0.0
srvlookup = no
externip = 95.XXX.XXX.90
externrefresh = 60
rtpkeepalive = 60
rtptimeout = 120
rtupdate = yes
alwaysauthreject=yes
rtcachefriends = yes
localnet = 192.168.29.0/255.255.255.224
localnet = 192.168.26.0/255.255.255.0
nat=no
t38pt_udptl = no
canreinvite = no
sipdebug = no
musicclass=native-random
language = ru
videosupport = no
notifyringing = no
notifyhold = no
useclientcode = yes
subscribecontext=blf-group
allowsubscribe=yes
limitonpeers = yes
tos=0x18
disallow=all
allow=alaw
allow=ulaw

register => 0000000:123123123@sip01.xxxxxx.ru/2399

[2399]
type=friend
username=0000000
fromuser=0000000
secret=123123123
host=sip01.xxxxxx.ru
qualify=yes
port=5060
nat=no
call-limit=6
insecure=invite,port
dtmfmode=rfc2833
context=dialin
t38pt_udptl=yes
t38pt_rtp=yes
t38pt_tcp=no
canreinvite=no
notyfyringing=no
disallow=all
allow=alaw
allow=ulaw


[phones](!)
type=friend
host=dynamic
secret=111111
dtmfmode=rfc2833
qualify=yes
context=c-dialout
transfer=yes
nat=no
port=5060
t38pt_udptl=yes
t38pt_rtp=no
t38pt_tcp=no
canreinvite=no
cancallforward=yes
notyfyringing=no
call-limit=2
disallow=all
allow=alaw
allow=ulaw

[2301](phones)
username=2301
callerid="User <2301>"
...
[2308](phones)
username=2308
callerid="Semina <2308>"

Update...

Отловил ещё один обрыв:

По ссылкам, два pcap-лога от телефона до aster'а и от aster'а до провайдера. (все приводить не имеет смысла оба лога по 400-500 строк)

Трафик звонка с телефона до астериска

Пакеты звонка от астериска до провыйдера

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

По обоим звонкам есть записи первая запись обрывается на полуслове вторая заканчивается нормально.

удалить закрыть спам изменить тег редактировать

спросил 2014-10-31 19:40:05 +0400

Krasnov Gravatar Krasnov
207 7 10

обновил 2014-11-11 16:44:47 +0400

Comments

пойди туда не знаю куда. Взрослый вроде человек: порядочные астерискеры не кладут на комьюнити выкладывая скрины wireshark, дают sip debug. Еще обычно телепатически сложно понять SIP конфигурацию относительно NAT, выкладывают секции general и пира из sip.conf. Уважайте остальных, будет Вам счастье...

Zavr2008 ( 2014-10-31 19:44:32 +0400 )редактировать

а еще не експерементируют на freebsd. проблема может быть в ОС.

meral ( 2014-10-31 20:00:27 +0400 )редактировать

meral, чего это ? я сижу под freebsd, экперементы и не только проходят на ура. Просто, как и всегда, нужно уметь "их готовить".

virus_net ( 2014-10-31 22:25:45 +0400 )редактировать

не вопрос. у меня и на роутерах были проекты. вопрос ведь в том, что глюки freebsd просто никому не известны.

meral ( 2014-11-01 00:00:54 +0400 )редактировать

2 meral Не спорю, проблема может быть и в ОС. НО, у меня ВСЕ астеры стоят на FreeBSD, и только вот нашлась одна единственная "паршивая овца" которая выбивается из стада.

Krasnov ( 2014-11-01 10:11:46 +0400 )редактировать

Конфигурация всех 3 офисных серверов общая, сервер выполняет сразу и функцию шлюза и функцию vpn сервера и функцию внутренней офисной АТС.

Порт 5060, на внешнем интерфейсе, открыт только для адреса провайдера IP-телефонии. Все остальные адреса блокируются ipfw. Т.е. провайдер подключается напрямую, без NAT. Телефоны из офиса подключаются тоже напрямую, вроде как в одной сети все устройства, тоже без NAT'а.

Все конфиги добавил в вопрос, sip debug выкладывать нет возможности потому как данные сбросы происходят не постоянно, может сбросить, а может и не сбросить, очень сложно отловить конкретный сброс.

Krasnov ( 2014-11-01 10:14:36 +0400 )редактировать

телефоны сидят за nat?

Zavr2008 ( 2014-11-01 13:43:36 +0400 )редактировать

так и продолжаем секретничать, от этого и ноль на выходе. Нужны сообщения SIP INVITE и SIP CANCEL через sip debug. Диаграмки приносят ноль информации, поскольку всем мало-мальски в теме они по ночам снятца.

Zavr2008 ( 2014-11-12 10:19:26 +0400 )редактировать

Zavr2008, он поправил первый пост, там в конце поста уже есть ссылки, на хоть и покоцанный, но tcpdump.

virus_net ( 2014-11-13 09:01:46 +0400 )редактировать

3 Ответа

0

Итак наконец то удалось получить хоть что-то.

Рассмотрим нелогичные вещи у пира [2399]:

1.username=0000000 - устарело, правильнее писать defaultuser=0000000

  1. nat=no - с какой стати? телефоны в 192.168.26.0.24, пров - на белом.

правильно: nat=yes, в general прописать externip=

  1. insecure=invite,port

Данная настройка - безграмотна, она подходит для транков без регистрации. заменить на insecure=invite или вообще выкинуть.

  1. canreinvite=no - УСТАРЕЛО. нужно использовать directmedia=no
  2. notyfyringing=no - объясните зачем оно тут?

Сдается мне, что ТС - нерадивый сотрудник прова, точнее очередного горе-облака типа манго. От этого и 2399 и 0000000 и скрытие имени/ip провайдера и дампов полных :)

ссылка удалить спам редактировать

ответил 2014-11-13 12:53:49 +0400

Zavr2008 Gravatar Zavr2008 flag of Russian Federation
2886 11 9 40
http://mh.otx.ru/
0

sip debug выкладывать нет возможности потому как данные сбросы происходят не постоянно

Но ведь никто не мешает включить его и складировать в логи. Так же никто не мешает запустить, например в скрине, tcpdump с сохранением в папку:

tcpdump -s0 -vi IFACENAME -w /path/to/save/dump-IFACENAME-sip_%s.pcap -G 300 port 5060

Если интерфейсов несколько, то запустить несколько tcpdump`ов, дабы точно собрать все пакеты для разбора. Если потрудиться, то из этих данных потом можно и вот такое получать: http://subnets.ru/img/sipanalyzersample_scheme.png

Включить в CLI

core set verbose 3

И затем, когда придет жалоба, посмотреть в логах что было в CLI при отработке проблемного вызова, а что было в SIP пакетах, кто/кому/что слал. После чего все должно встать на свои места.

ссылка удалить спам редактировать

ответил 2014-11-01 10:29:32 +0400

virus_net Gravatar virus_net flag of Russian Federation
302 1 6
http://www.mega-net.ru/

обновил 2014-11-01 10:32:42 +0400

Comments

Так именно таким образом было снято то что можно видеть на скриншотах с wireshark'а. Я, конечно попробую выловить, в этих логах, по call-id, все пакеты связанные с данной сессией. Но не уверен что они будут все. Т.к. само собой, за время праздников, всё не рассосется, после праздников, поставлю tcpdump снимать пакеты с конкретного хоста (телефона) внутри сети, чтобы лишнего "мусора" в логах не было, и выложу сюда.

Krasnov ( 2014-11-01 10:49:53 +0400 )редактировать

Скриншоты... хорошо конечно, но вот вам они помогли осознать проблему ? Мне кажется что нет. Для нас они так же почтибесполезны.

Если собирать все пакеты, то они не могут быть "не все". Так же для сопоставления добавить в dialplan:

exten =&gt; s,n,SIPAddHeader(X-orig-call-id: ${SIP_HEADER(Call-ID)})
exten =&gt; s,n,SIPAddHeader(X-unique-id: ${CHANNEL(uniqueid)})

В контексты для приема входящих вызовов и контекст для исходящих.

Собирать пакеты только от телефона = снова не получить полной картины. Нужно дампать и в сторону юзера и в сторону прова.

В первую очередь нужно будет это все самому проанализировать, а не сюда выкладывать. И ещё раз повторю, что необходим не только дамп, но и данные вербоза из CLI. Тогда в ваших руках будет полная картина места проишествия.

virus_net ( 2014-11-01 11:07:02 +0400 )редактировать

Я добавил два файла дампа звонка от телефона к астеру и от астера к прову. К сожалению, verbose снять не удалось Честно? я не совсем понимаю почему астер может сбрасывать звонок после нескольких INVITE'ов пришедших о провайдера. Вот схема звонка от астера к прову. Причем астер прову на INVITE отвечает ОК. В теории, так и должно быть, или я что-то упустил? 1 : |U------------INVITE----------->|

2 : |<-407 Proxy Authentication Re-U|

3 : |U-------------ACK------------->|

4 : |U------------INVITE----------->|

5 : |<------100 Trying/INVITE------U|

6 : |<-183 Session Progress/INVITE-U|

7 : |<--------200 OK/INVITE--------U|

8 : |<--------200 OK/INVITE--------U|

9 : |<--------200 OK/INVITE--------U|

10: |<--------200 OK/INVITE--------U|

11: |<--------200 OK/INVITE--------U|

12: |<--------200 OK/INVITE--------U|

13: |<--------200 OK/INVITE--------U|

14: |U------------CANCEL----------->|

15: |<--------200 OK/CANCEL--------U|

Krasnov ( 2014-11-11 17:36:14 +0400 )редактировать

в debug логе очень много записей типа

[Nov 11 15:34:58] DEBUG[-1] audiohook.c: Read factory 0x2b369020 and write factory 0x2b369a48 both fail to provide 160 samples

[Nov 11 15:34:58] DEBUG[-1] audiohook.c: Failed to get 160 samples from write factory 0x2b369a48

[Nov 11 15:34:58] DEBUG[-1] audiohook.c: Read factory 0x2b369020 and write factory 0x2b369a48 both fail to provide 160 samples

[Nov 11 15:34:58] DEBUG[-1] audiohook.c: Failed to get 160 samples from write factory 0x2b369a48

Может ли это сказываться на обрыве?

На сколько я читал в форумах такое поведение свойственно при включенном MixMonitor'е. Выключал, ничего не меняется. Создал диск в памяти для записи, вся запись разговоров ведется не на диск а в память, и оттуда скриптом кодируется в mp3 и переносится на диск.

Krasnov ( 2014-11-11 17:39:51 +0400 )редактировать

Очень плохо что в приложенном дампе вырезаны временные метки. Из дампа видно что со стороны прова в ответ на ивайт со стороны вашего сервера идут инвайты, после того как вызов через него состоялся, но ваш Астер ничего не отвечает на эти пакеты. Далее истекает таймаут на поднятие RTP (rtptimeout) и ваш астер шлет CANCEL в сторону прова и Declined в сторону клиента.

Разбираться нужно с тем почему ваш астер на INVITE со стороны прова молчит в ответ. М.б. он просто не "слышит" ? Причин может быть много, начиная от банального: криво настроенный firewall.

В первом вызове порты для RTP:

95.xxx.xxx.90:5060 --&gt; 195.xxx.xxx.49:5060 
m=audio 11798 RTP/AVP 8 0 101
195.xxx.xxx.49:5060 --&gt; 95.xxx.xxx.90:5060
m=audio 10068 RTP/AVP 8 0 101

Во втором:

95.xxx.xxx.90:5060 --&gt; 195.xxx.xxx.49:5060
m=audio 17852 RTP/AVP 8 0 101
195.xxx.xxx.49:5060 --&gt; 95.xxx.xxx.90:5060 
m=audio 54918 RTP/AVP 8 0 101

И я бы уменьшил "аппетит" на кодеки в Grandstream. Оставил бы alaw и ulaw.

virus_net ( 2014-11-12 09:41:13 +0400 )редактировать

Ещё: включите rtp debug до кучи

попробуйте совершить вызов через originate в какой нить контекст с музончиком, т.е. без участия телефона клиента и посмотрите что будет в этом случае

virus_net ( 2014-11-12 09:45:07 +0400 )редактировать

Да, а по поводу firewall, у меня в ipfw стоит правило

allow udp from 195.xxx.xxx.49 to me in via [внешний интерфейс]

т.е. весб udp трафик от провайдера на сервер разрешен. Ну и от сервака на любые адреса все протоколы тоже разрешены.

Krasnov ( 2014-11-13 14:22:15 +0400 )редактировать

такое поведение "свойственно" криво настроенному фаерволу. но поскольку вы не хотите приложить нерезаный дамп, то разбиратся прийдется вам лично

meral ( 2014-11-13 17:50:36 +0400 )редактировать

Всем спасибо, разобрался. :)

Krasnov ( 2014-11-17 11:56:54 +0400 )редактировать

Так озвучили бы что было в итоге.

virus_net ( 2014-11-18 09:02:31 +0400 )редактировать
0

cancel у вас идет через 32 секунды. может ему просто звонить надоело,не?*

ссылка удалить спам редактировать

ответил 2014-10-31 20:01:30 +0400

meral Gravatar meral flag of Ukraine
23347 24 20 177
http://pro-sip.net/

Comments

Не, не всегда.... Некоторые CANCEL'ы идут и через 15 минут а некоторые и через 3 секунды.

Krasnov ( 2014-11-01 08:52:46 +0400 )редактировать

Позавчера, когда начал разбираться со всем этим, заметил такой момент. Все данные по звонкам пишутся в БД, был звонок который был отмечен в БД как NO ANSWER последняя команда dialplan'а (lastapp) была hangup, duration был 30 секунд (в диалплане Dial(SIP/${EXTEN}@2399,30)), вроде бы всё правильно, был звонок, на той стороне не ответили, астер прервал связь но, на самом деле, при прослушивании записи (ведется запись звонков) было слышно что произошло соединение на 5-7й секунде а на 26-29й секунде обрыв. Я сначала думал что не дозваниваются, потом перезванивают и нормально разговаривают, ан нет, обрывы. И записи свидетельствуют об этом.

Так же, в БД есть записи, которые отмечены как NO ANSWER но у них lastapp был не hangup а dial и длительность соединения разная от 3-5 сек до 5-20 минут. Вот это точно обрывы.

И все звонки, которые я нашел, заканчиваются с CNACEL'а. Точнее обрыв начинается с отправки CANCEL в одну (провайдеру) или другую (телефону) сторону.

Krasnov ( 2014-11-01 09:59:37 +0400 )редактировать

ну и чего вас смущает? cancel посылает UA в случае если клиенту надоело звонить либо если нет потока звука. в кансел через 15 минут не верю, извините.

meral ( 2014-11-01 16:55:17 +0400 )редактировать

Ваш ответ

Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
[скрыть предварительный просмотр]

Закладки и информация

Добавить закладку

подписаться на rss ленту новостей

Статистика

Задан: 2014-10-31 19:40:05 +0400

Просмотрен: 1,328 раз

Обновлен: Nov 13 '14

Похожие вопросы:

Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией GNU GPL.