Так именно таким образом было снято то что можно видеть на скриншотах с wireshark'а. Я, конечно попробую выловить, в этих логах, по call-id, все пакеты связанные с данной сессией. Но не уверен что они будут все. Т.к. само собой, за время праздников, всё не рассосется, после праздников, поставлю tcpdump снимать пакеты с конкретного хоста (телефона) внутри сети, чтобы лишнего "мусора" в логах не было, и выложу сюда.
Krasnov ( 2014-11-01 10:49:53 +0400 )редактироватьСкриншоты... хорошо конечно, но вот вам они помогли осознать проблему ? Мне кажется что нет. Для нас они так же почтибесполезны.
Если собирать все пакеты, то они не могут быть "не все". Так же для сопоставления добавить в dialplan:
exten => s,n,SIPAddHeader(X-orig-call-id: ${SIP_HEADER(Call-ID)})
exten => 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 --> 195.xxx.xxx.49:5060
m=audio 11798 RTP/AVP 8 0 101
195.xxx.xxx.49:5060 --> 95.xxx.xxx.90:5060
m=audio 10068 RTP/AVP 8 0 101
Во втором:
95.xxx.xxx.90:5060 --> 195.xxx.xxx.49:5060
m=audio 17852 RTP/AVP 8 0 101
195.xxx.xxx.49:5060 --> 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 )редактировать
пойди туда не знаю куда. Взрослый вроде человек: порядочные астерискеры не кладут на комьюнити выкладывая скрины 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 )редактировать