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

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

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

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

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

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

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

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

Я добавил два файла дампа звонка от телефона к астеру и от астера к прову. К сожалению, 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|

в 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 и переносится на диск.

Очень плохо что в приложенном дампе вырезаны временные метки. Из дампа видно что со стороны прова в ответ на ивайт со стороны вашего сервера идут инвайты, после того как вызов через него состоялся, но ваш Астер ничего не отвечает на эти пакеты. Далее истекает таймаут на поднятие 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.

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

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

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

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

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

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

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

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

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

Позавчера, когда начал разбираться со всем этим, заметил такой момент. Все данные по звонкам пишутся в БД, был звонок который был отмечен в БД как 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 в одну (провайдеру) или другую (телефону) сторону.

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