В версии 3.57.у нас обновилась библиотека SIPSorcery, через которую Сервер осуществляет SIP-вызовы. Возможно в ней изменилась логика проведения вызова, которую не учитывает ваш SIP-сервер. Либо ее разработчиками допущена ошибка. Пока что трудно сказать, так как воспроизвести ситуацию не удается.
Хотелось бы услышать других пользователей, использующих SIP-вызовы, как у них обстоят дела с вызовами через SIP.
Вот на последней версии ЛЭРС при падении контейнера возникает ошибка
Unhandled exception. System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'System.Threading.SemaphoreSlim'.
at System.Threading.SemaphoreSlim.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at System.Threading.SemaphoreSlim.Wait()
at SIPSorcery.SIP.App.SIPUserAgent.CallEnded(String callId)
at SIPSorcery.SIP.App.SIPUserAgent.ClientCallAnsweredHandler(ISIPClientUserAgent uac, SIPResponse sipResponse)
at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_1(Object state)
at System.Threading.QueueUserWorkItemCallback.Execute()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
Здесь так же упоминается эта библиотека
В первом приложенном журнале не зафиксировано остановки Сервера. В нем вызовы ставились в очередь, но их непосредственный вызов попросту переставал выполняться с какого-то момента времени. А значит падение контейнера само по себе не является причиной остановки вызовов. Пока что пытаемся воспроизвести ситуацию у себя. На данный момент у нас это никак не получается. Складывается ощущение, что это как то связано именно с используемым у вас SIP-сервером, так как у других пользователей, судя по отсутствию обращений по аналогичной проблеме с вызовами SIP и реакции в вашей теме, SIP-вызовы работают корректно. Если у вас все же есть возможность предоставить доступ к нему, будем очень рады, так как это должно упростить воспроизведение ситуации и ускорит ее анализ. Параметры доступа вы можете отправить нам на почту или в ЛС, чтобы не давать их публично.
Тот факт, что в данной библиотеке присутствуют ошибки, вызывающие падение контейнера, это неправильно, но мы не можем ее исправить, так как не являемся разработчиками данной библиотеки.
Версия ЛЭРС УЧЁТ: 3.59.4(docker)
Сервер БД: PostgreSQL
После обновления до 3.59.4 падает сервер каждые 5 минут
Unhandled exception. System.ObjectDisposedException: Cannot access a disposed object.
Object name: ‘System.Threading.SemaphoreSlim’.
at System.Threading.SemaphoreSlim.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at System.Threading.SemaphoreSlim.Wait()
at SIPSorcery.SIP.App.SIPUserAgent.CallEnded(String callId)
at SIPSorcery.SIP.App.SIPUserAgent.ClientCallAnsweredHandler(ISIPClientUserAgent uac, SIPResponse sipResponse)
at System.Threading.Tasks.Task.<>c.b__128_1(Object state)
at System.Threading.QueueUserWorkItemCallback.Execute()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
@anbeluaev то есть в 3.59.3 у вас данная проблема не наблюдалась? У нас библиотека “SIPSorcery” не обновлялась с версии 3.57, что уже обсуждалось в текущей теме, с которой была слита ваша тема. По стеку видно, что проблема возникает именно в ней. У нас нет информации что именно в данной библиотеки вызывает данную ошибку.
в 3.59.3 проблемы не было
хотел бы уточнить. в 3.59.3 сервер не падал каждые 5 минут. Были ли проблемы с sip-вызовами, мне не известно.
@anbeluaev, падение возникает при выполнении первого вызова через SIP? Покажите, пожалуйста, журнал работы Сервера за любой день, когда стало возникать описанное падение.
отправил на support@lers.ru
Спасибо за обращение! Мы поставили в план работ исправление данной ошибки. Как только она будет исправлена, обязательно сообщим в каком обновлении будет доступно исправление.
Судя по всему в используемой версии библиотеки действительно присутствует ошибка. Ситуация очень странная и воспроизводится только при вызове некоторых номеров и только в сборке под Docker.
С новой версией библиотеки ситуация не воспроизводится.
Исправление будет доступно в следующем обновлении 3.59.5. В нее будет добавлена новая версия библиотеки “SIPSorcery”.
Добрый день!
Обновление 3.59.5 (сборка 35910) от 27.11.2024 доступно для установки.
Здравствуйте. В версии 3.59.5 контейнер перестал падать при вызовах на номера, которые вызов сбрасывают. Но изначальная проблема сохраняется.
На почту отправил 2 архива с логами сервера, скриншотами журнала опроса и логами сетевых запросов от ЛЭРС к SIP
В первом варианте при звонке на номер, который сбрасывает вызов(BUSY): ЛЭРС пишет в журнал, что вызов совершен и ждет подключение модема. При этом к SIP-серверу ЛЭРС продолжает слать RTP-пакеты (SIP-сервер отвечает, что порт уже закрыт).
Во втором варианте, когда происходит соединение с номером(ANSWER), то от SIP-сервера приходит сигнал разрыва соединения через 1 секунду и обмен данными с ЛЭРС заканчивается. Но ЛЭРС в журнал не выводит информацию, что произошел вызов и все последующие вызовы он в SIP не отправляет.
При разрыве соединений от ЛЭРС как в первом так и во втором случае приходит подтверждение (OK).
Я правильно понимаю, один из вызываемыз контроллеров отвечает на звонок вместо того, чтобы сбросить вызов, в результате чего возникает описываемая ситуация? Не установлено ли на сим-карте функций голосовой почты или автоответчик?
Вызов сбрасывается устройством, но устанавливается соединение, инициированное оператором. Как уже писал выше, сейчас часто при сбросе вызова происходит ответ и звучит сообщение “Абонент не может ответить на вызов, мы не можем оставить ему сообщение т.к. не подключена голосовая почта”.
Если это возможно, попробуйте в какой либо точке учета поставить вызов на обычный телефон, который вам доступен, например на свой личный телефон, запустите опрос данной точки и ответьте на звонок. Проверьте воспроизведется ли ситуация после этого.
Уже пробовали ранее, проделал ещё раз. Сразу после запуска контейнера совершил прозвон из ЛЭРС своего номера телефона. На телефон вызов поступил, я на него ответил, вызов через секунду сбросился. ЛЭРС в журнале не пишет, что был совершен вызов и продолжает ждать, пока он осуществится
У нас при выполнении аналогичных шагов на нашем SIP-сервере и вызове через него собственного номера телефона данная ситуация не воспроизводится. Сервер ЛЭРС УЧЕТ успешно обнаруживает, что трубка была поднята модемом, выжидает 5 секунд и принудительно кладет трубку принудительно, после чего регистрирует SIP-вызов. Ниже приведена выдержка журнала работы Сервера ЛЭРС УЧЕТ при выполнении такого вызова:
2024-11-28 12:42:10.2689 D:54 Lers.Poll.GprsModemCaller Голосовой вызов модема на номер <номер телефона> осуществляется через подсистему сообщений сервера. 00-5d2fff15e2d906687959a11f2fdeedb4-1ea1e273e0b9ac20-00
2024-11-28 12:42:10.2689 D:54 Lers.Messaging.MessageService GPRS-вызов на '<номер телефона>' (Voice) поставлен в очередь для немедленной отправки 00-5d2fff15e2d906687959a11f2fdeedb4-1ea1e273e0b9ac20-00
2024-11-28 12:42:10.2745 D:56 Lers.Messaging.Sip.SoftPhone Регистрация на SIP сервере <адрес SIP-сервера>.
2024-11-28 12:42:10.3045 I:54 Lers.Poll.Request.ManualPollHandlerBase Запуск оператором опроса Новый объект, КМ-5-4 #111111, 111. Запрошены данные: суточные (только недостающие данные). 00-5d2fff15e2d906687959a11f2fdeedb4-1ea1e273e0b9ac20-00
2024-11-28 12:42:10.3660 D:62 Lers.Messaging.Sip.SipCallMessage Выполняется голосовой вызов через SIP сервер по номеру телефона <номер телефона>
2024-11-28 12:42:25.8234 D:62 Lers.Messaging.Sip.SipCallMessage После звонка на номер <номер телефона> модем поднял трубку. Ожидаем 00:00:05, чтобы он её положил.
2024-11-28 12:42:30.8221 D:56 Lers.Messaging.Sip.SipCallMessage Модем <номер телефона> не положил трубку за 00:00:05. Кладём трубку принудительно.
2024-11-28 12:42:30.8221 I:56 Lers.Messaging.SendMessageHandler Отправлено сообщение: SIP вызов модема '<номер телефона>'
Все таки подозрение падает на ваш SIP-сервер и/или на определенные номера ваших модемов. Для анализа ситуации нам нужно воспроизвести ее у себя, а для этого необходим доступ к вашему SIP-серверу и номер телефона модема, при вызове которого ситуация воспроизводится у вас. Пожалуйста, все же проработайте возможность их предоставления.
Похоже, что проблема из-за того, что ЛЭРС ждет 5 секунд, для того, чтобы положить трубку, а SIP её кладёт самостоятельно через секунду. Попробовали отключить сброс вызова через секунду на SIP-сервере и тогда вызовы в ЛЭРС стали отрабатывать корректно. Видимо ЛЭРС не воспринимает сброс вызова именно SIPом, хотя старые версии ЛЭРС с такой настройкой SIP-сервера работали без проблем. У нас сброс вызова через секунду сделан для того, чтобы не было лишних начислений, т.к. у нашего оператора даже за вызовы в 3 секунды оплата идет как за минуту, а вызовы в 1 секунду не тарифицируются вообще. При большом количестве “отвечающих” сим-карт ждать по 5 секунд будет очень накладно по финансам. Можно ли уменьшить время ожидания, что модем положит трубку со стороны ЛЭРС до 1 секунды? Мы тогда эту настройку на сервере SIP не будем включать для ЛЭРС.
Нет, данный таймаут жестко задан в программе и изменить его не представляется возможным. Вы можете внести соответствующее предложение по улучшению, в котором предложить добавление такого параметра настройки.
Судя по всему изменился алгоритм работы самой библиотеки, так как в ЛЭРС УЧЕТ, как уже писали выше, алгоритм работы с SIP с версии 3.43 не менялся, за исключением изменений в последнем обновлении. Хотелось бы все таки воспроизвести ситуацию у себя для ее более детального анализа, но собственный SIP-сервер используется в различных целях, поэтому задать ему внутренний таймут ожидания ответа, после которого он клал бы трубку самостоятельно, мягко скажем проблематично. Мы подумаем как это можно осуществить. Но если у вас есть возможность предоставить доступ к вашему SIP, будем этому рады.