24.12.2019

Kamailio. uac_auth. cseq. t_relay fail.

чтобы увеличивать cseq нужно использовать модуль диалог.

modparam(“dialog”, “track_cseq_updates”, 1)

если вы используете в failure_route uac_auth, то учите что при несовпадении realm в запросе на авторизацию и в функции uac_auth вы получите ошибку

ERROR: {1 62503 INVITE } tm [t_fwd.c:1717]: t_forward_nonack(): no branches for forwarding
ERROR: {1 62503 INVITE } tm [tm.c:1679]: _w_t_relay_to(): t_forward_noack failed

А в 2016 был баг на эту тему в kamailio. сейчас видимо не баг.

5.07.2018

Kamailio. topos. topology hiding. bug.

В kamailio обнаружился баг с модулем topos. Проявляется так: Если во время звонка случается re-invite от клиента, то сообщения BYE обрабатываются некорректно. Этот BYE отправляется не дальше клиенту, а остается на kamailio, сам kamilio при этом выдает “Not here” и точка. Клиент не получает BYE в следствие чего звонок на конечной точке зависает.

Связано это с модулем topos который позволяет скрывать топологию сети после прохождения через sip-proxy. сам по себе модуль очень хорош – его достаточно загрузить и никаких настроек не надо.
но вот багесть. Разработчик уже поправил в исходном коде, но в пакеты пока не попал…

27.11.2017

High load. Высокая нагрузка на сервер Астериск.

В рамках проекта с высокой нагрузкой нужно было решить проблему, описание которой звучит так: После 360 секунд вызовы переставали попадать в биллинг. Первонаперво была выяснена причина это отсутствие некоторых переменных, получаемых через AGI интерфейс php скриптом. При этом, если использовать AGI то такой проблемы не наблюдалось.
В нашем случае используется FASTAGI и связка ASterisk, xinetd, phpagi-fastagi.php, myscript.php.

Поиск решений занял несколько дней, потому, что нагрузка на сервер была высокой итак: 1. Обнаружили что mysript.php не получает значение переменной DIALSTATUS после выполнения команды DIAL. И поиск в интернете ничего не давал, пока я не набрел на собственно код phpagi библиотеки на sourceforge.net. (https://sourceforge.net/p/phpagi)
И в багтреке были прикреплены несколько вопросов именно по поводу переменной DIALSTATUS. Но комментиариев с решением под ними не было, а были они в “обсуждениях”, вот здесь: https://sourceforge.net/p/phpagi/discussion/366892/thread/5a4c09f0/

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

Было два решения которые предложила система, это а) повторить запрос переменной несколько раз, пример:
function get_var($agi_in, $value)
{
$temp = $agi_in->get_variable($value);
$temp = $agi_in->get_variable($value);
$temp = $agi_in->get_variable($value);
$temp = $temp;
$agi_in->verbose($value." :".$temp);
return $temp;
}

б) решить вопрос кардинально, но я это решение реализовать не смог, т.к. до конца не понял как работают стримы и куда вставить код.

function evaluate($command)
{
//clear the buffer
stream_set_blocking($this->in,0);
do {
$line = fgets($this->in);
} while ($line);
stream_set_blocking($this->in,1);

Всем пока.

14.06.2015

ACK. OPENSIPS. SEMS. ROUTE

Столкнулся с проблемой при использовании SEMS. При звонке ACK отправлялся на тот же IP что и сервер. И не доходил до абонента. проблема решается удалением IP адреса из списка локальных доменов. решение было найдено в архиве за 2009 год.

Приятного Opensips всем.

10.06.2014

call_control cdrtool maxsessiontime

При работе функции Maxsessiontime система упорно не подгружает указанный лимит для пользователя

Причина кроета в код rating.php район строчки 8577:

if (!preg_match(“/^0/”,$CDR->CanonicalURINormalized)) {
$log=sprintf (“MaxSessionTime=unlimited Type=prepaid CallId=%s BillingParty=%s  DestId=None”,$NetFields[‘callid’],$CDR->BillingPartyId);
syslog(LOG_NOTICE, $log);
$this->logRuntime();
$ret=”none”.”\n”.”type=prepaid”;
return $ret; }

Если Зачем искать в номере начало на 0 – решительно не понятно…. иметь ввиду.

9.06.2014

call_control opensips application

При установке call_control возникает error: ‘Request’ object has no attribute ‘application’

Понятно, что где-то не передается свойства application. Исправляется таким способом:

заходим в sip.py из дистрибутивов

и self.application = “audio”

это конечно решение как говорится “влоб”, понятно что хорошо бы настроить передачу этого свойства от радиуса но мы этого делать не будем.

1.09.2012

uac_registrant

Относительно недавно в opensips появилась возможность регистрироваться на sip серверах. Собственно uac_registrant этим и занимается. Проблема с которой я столкнулся выглядела так: Попытка регистрации, sip-сервер возвращает ошибку WRONG_CREDENTIALS (6) и после этого uac_registrant  более не регистрируется до перезагрузки Opensips.
Логика в данном случае вроде бы правильная, не верно указанные данные не должны отправляться повторно, но в моем случае данные были верны и после перезагрузки регистрация проходила успешно.
Почему некоторые провайдеры выдают такую ошибку – сказать сложно, однако, такое случается. Asterisk в этом случае, кстати не стесняется – продолжает пытаться зарегистраироваться.
Разработчики Opensips сказали примерно следующее:

State 6 is WRONG_CREDENTIALS_STATE.
The reason that the server doesn’t try to re-register is because the
credentials are no longer valid.
The credentials should be updated and the server restarted to take
into account the updated credentials.

Если эту проблему не исправить, то в любой момент времени можно потерять регистрацию на сервере и перестать получать входящие вызовы. Решение для себя я заделал конечно по принципу костыля, но по большому счету за долгие месяцы – проблем не возникло:

В файле registrant.c, в районе 735 строчки, можно исключить данный код ошибки из списка тех, после которых попытки регистрации прекращаются.

at line: 735:
case REGISTERING_STATE:
case AUTHENTICATING_STATE:
break;
case WRONG_CREDENTIALS_STATE:
case REGISTER_TIMEOUT_STATE:
case INTERNAL_ERROR_STATE:

Привет!