Asterisk, почему обрываются звонки?

Question

[Денис Афонин]

Всем доброго времени суток. С недавнего времени началась проблема, что во время разговора между внутренними абонентами он обрывается. С помощью телефона Yealink снял дампы нескольких звонков, среди которых есть и проблемный. Wireshark-ом открыл проблемный звонок, там вот такая картина:

В этом же дампе открыл звонок чуть меньший по длительности, но завершившийся корректно, там вот так:

Подскажите, куда копать, где искать проблему? Разницу вижу только в том, что в проблемном звонке не видно RTP пакетов, хотя по факту они в дампе есть и их можно прослушать. Там же слышно, что разговор обрывается на полуслове.
Секция BYE проблемного звонка:

Session Initiation Protocol (BYE)
    Request-Line: BYE sip:asterisk@172.25.2.1:5063 SIP/2.0
        Method: BYE
        Request-URI: sip:asterisk@172.25.2.1:5063
            Request-URI User Part: asterisk
            Request-URI Host Part: 172.25.2.1
            Request-URI Host Port: 5063
        [Resent Packet: False]
    Message Header
        Via: SIP/2.0/UDP 172.25.2.191:5060;branch=z9hG4bK1001928642
            Transport: UDP
            Sent-by Address: 172.25.2.191
            Sent-by port: 5060
            Branch: z9hG4bK1001928642
        From: <sip:2350@172.25.2.191>;tag=1001694514
            SIP from address: sip:2350@172.25.2.191
                SIP from address User Part: 2350
                SIP from address Host Part: 172.25.2.191
            SIP from tag: 1001694514
        To: "Братов Т.Н." <sip:2902@172.25.2.1>;tag=06b9f807-8bf2-461d-b59f-73afacc7d2ef
            SIP to display info: "Братов Т.Н."
            SIP to address: sip:2902@172.25.2.1
                SIP to address User Part: 2902
                SIP to address Host Part: 172.25.2.1
            SIP to tag: 06b9f807-8bf2-461d-b59f-73afacc7d2ef
        Call-ID: 58c4e2e9-adfb-46ed-a888-32d18256d9df
        [Generated Call-ID: 58c4e2e9-adfb-46ed-a888-32d18256d9df]
        CSeq: 2 BYE
            Sequence Number: 2
            Method: BYE
        Contact: <sip:2350@172.25.2.191:5060>
            Contact URI: sip:2350@172.25.2.191:5060
                Contact URI User Part: 2350
                Contact URI Host Part: 172.25.2.191
                Contact URI Host Port: 5060
        Max-Forwards: 70
        User-Agent: Yealink SIP-T27G 69.86.0.15
        Content-Length: 0

Answer 1

[Талян]

Скиньте на яндекс диск или еще куда-нибудь оба дампа и выложите. Хочу посмотреть подробнее. Но было бы еще лучше оба дампа писать на самом астериске а не с Yealink'ов.

Или на сервере астериска можно смотреть в реальном времени в консоли утилитой nsgrep.

Так же в консои астериска:

core set debug 9
core set verbose 9

и посмотреть что творится с точки зрения астериска.

Проверьте на Yealin'ках у обоих разговаривающих сторон, настройки в SIP разделе. У меня под рукой к сожалению ничего сипового нет, но помнится там был раздел что-то типа SipProxy. Отличается ли он у звонящих?

Дамп нужен с самого астериска потмоу что будет видно - виновата звонящая сторона или принимающая.

Comments

[Денис Афонин]

Понял. Завтра буду снимать дамп на самом астериске. Настройки всех телефонов абсолютно одинаковые.

[Rsa97]

Только утилита sngrep, а не nsgrep.

[Денис Афонин]

Вот только что снял дам сбойного звонка: ДАМП

[Денис Афонин]

Вот еще пара звонков, которые специально сделали подряд с номером на котором чаще всего разрывы(2350): ССЫЛЬ

[Талян]

Rsa97,

только утилита sngrep, а не nsgrep.

Конечно ). Опечатался

[Талян]

Денис Афонин,

У вас дампы без RTP.

Как от 1100 номера приходит BYE?
Это абонент 1100 кладет трубку?

Мне интересны подробности, которых я не вижу в дампе который вы выложили в Я.Диск.

Судя по диаграмме на скриншоте выше, я вижу что после INVITE поток RTP длился 72 секунды, и завершился нормальным BYE от абонента 1850@172.25.2.191.

BYE само по себе без причины не отправляется, поэтому и спрашиваю - Абонент 1850 услышал тишину, потом сам положил трубку?

Или абонент просто разговаривал, и вдруг внезапно без какой либо паузы - отрубается связи и слышны короткие гудки?

Или тишина?

Нужны подробности.

Еще советую посмотреть в сторону RTP портов. Обычно на стороне SIP сервера есть настройка диапазона RTP портов (15000-30000) или типа того.

Проверьте, совпадает ли диапазон сервера с клиентами. В YeaLink где то в разделе SIP по-моему я видел.

[Вадим]

Талян, диапазон портов RTP с разных сторон не должен совпадать, согласовали в SDP, и хорошо. У Yealink он по умолчанию 11780-12780.
Почему BYE приходит, и от кого, от астера или абонента, вот вопрос.

[Денис Афонин]

Талян, в этих звонках трубку никто не ложил, обрыв происходил сам по себе и в трубках короткие гудки. Просматривая SIP логи увидел такой параметр как Session-Expires: 90;refresher=uac. Это время очень похоже на то, через какое время обрывается сессия. Поменял во всех телефонах этот параметр на 1800, завтра помониторю что изменится. Но предварительно это помогло, т.к. тестовый звонок с проблемным абонентом провисел 4 минуты, пока я сам не положил трубку.

[Талян]

Вадим, про порты - может так и есть. У меня с этим проблем никогда не было, но вот однажды звонили с ЦИТа, мы пока с их GrandSteram не согласовали порты, связь бывало рвалась. Порты согласовали - все ок стало. Возможно особенность GrandStream. С нашей стороны был SoftSwitch НТЦ Протей.

[Денис Афонин]

В общем проблема решилась увеличением времени жизни SIP сессии. Странно что 4 года работало без проблем ...

[Талян]

Денис Афонин, подскажи где этот параметр лежит? На будущее пригодится.

[Денис Афонин]

Для телефонов Yealink: Аккаунт-Расширенные-Session Expires(90~7200сек). У меня стояло 30, поставил с запасом 1800
В конфигурационных файлах файлах можно прописать так:

account.1.session_timer.enable = 1
account.1.session_timer.expires = 1800

[Талян]

Денис Афонин, ааа так это на самом Yealink! Понял) А то думаю - что за фигня, даже в дефолтной конфигурации астериска такой параметр если и есть (а вроде как есть), то не такой же он должен был быть маленький.

[Денис Афонин]

Ну вообще ограничение срабатывало на 90 секундах. Скорее всего в расчет берется наибольшее значение. На астериске стоит 90, в телефоне было 30 и оно просто не учитывалось. А когда в телефонах поставил 1800, именно этот лимит стало видно в логах.