Верификация мобильных номеров – часть 2

Описание: в этой статье мы продолжим разбор возможности проверки существования мобильного номера и его доступности.

Все инструкции тестировались на следующем оборудовании:

CentOS Linux release 7.5.1804

• Asterisk 13.21.0
• PHP 5.6.36
• Apache/2.2.15
• MySQL/10.1.33-MariaDB

Используемые технологии:

• PHP
• MySQL
• Dialplan asterisk

В первой части мы разобрали настройки, которые необходимо внести в asterisk для работы сервиса (Верификация мобильных номеров – часть 1), теперь рассмотрим API-скрипт. В нём есть функции коннекторы к mysql и AMI, их описывать здесь не будем, а перейдём сразу к исполнительной части. Она подразделяется на три большие блока:

1. Инициация вызова
2. Возврат статуса
3. Ротация транков

1. Инициация вызова

Выполняется при следующем запросе:

. https://ip_asterisk/verphone/?phone=8961******6&idblank=0001

Т.е. требует наличия двух параметров:

• phone – проверяемый мобильный номер
• idblank – номер договора

При получении такого запроса, скрипт инициирует вызов написанного нами ранее контекста с передачей аргументов.

$action  = "Action: Originate\r\n";
$action .= "Channel: Local/$phone@phone-verification\r\n";
$action .= "Exten: h\r\n";
$action .= "Context: phone-verification\r\n";
$action .= "Priority: 1\r\n";
$action .= "Variable: idblank=$idblank\r\n";
$action .= "Async: yes\r\n\r\n";
ami_request($action);

Далее asterisk берёт из базы, в которой хранится список транков, id очередной городской линии и делает попытку дозвона. При неудаче берётся следующий транк и операция повторяется, в противном случае данный транк маркируется, как использованный, и указатель «сдвигается» на следующий. Это позволяет при недоступности одного из транков позвонить через следующий, а так же выполняет ещё одну задачу, но о ней в описании третьего блока.

• Возврат статуса

Второй значительный блок – позволяет по номеру телефона и договора получить статус последней попытки дозвона.

https://ip_asterisk/verphone/?phone=8961******6&idblank=0001&loop

• phone – проверяемый мобильный номер
• idblank – номер договора
• loop – возврат результата

Формально это обращение к, уже сформированной, внутренней базе данных, а запрос выглядит следующим образом:

MariaDB [asteriskcdrdb]> SELECT src,dst,disposition FROM cdr WHERE dst LIKE "%'.substr($phone, -10, 10).'" AND userfield="'.$idblank.'" ORDER BY calldate desc LIMIT 1;

Здесь через php мы подставляем полученный номер и осуществляем поиск. В зависимости от результатов, API возвращет три результата:

1. «404 – result is empty» — в базе не найдено соответствия поисковому запросу
2. «400 — call not accepted» — соответствие найдено, и вызов не был отвечен
3. «200 — call accepted» — соответствие найдено и на вызов отвечен

Отвечающий за это код:

if(!empty($sqlArray)){
	$answer['code'] = substr($sqlArray[0]['src'],7);
	$answer['reason'] = $sqlArray[0]['disposition'];
	switch ($sqlArray[0]['disposition']){
		case 'ANSWERED':
			$answer['status'] = 200;
			$answer['reason'] = 'call accepted';
		break;
		default:
			$answer['status'] = 400;
			$answer['reason'] = 'call not accepted';
		break;
	}
}
else{
	$answer['status'] = 404;
	$answer['reason'] = 'result is empty';
}

Так же следует заметить, что вместе с кодом ответа и его расшифровкой в результате будут содержаться последние 4 цифры транка, через который прошёл вызов.

• Ротация транков

Последний и самый сложный в реализации блок API. Он вызывается не снаружи через http-запрос, а изнутри, из dialplan asterisk. Его задача получить и вернуть два параметра номер (CID) и идентификатор транка, с учётом двух условий. Первое: все транки должны последовательно перебираться. Второе: на один и тот же номер не должны осуществляться повторные вызовы с того же транка ранее чем через пять итераций.

Запрос принимает единственный параметр:

• revolver – который содержит номер вызываемого абонента

Что происходит далее разберём подробно.

$sqlArray = bd_bridge('asteriskcdrdb','SELECT line FROM lasttrunk');
$link = $sqlArray[0]['line'];

Получили из базы и сохранили в переменную порядковый номер текущего указателя.

$sqlStr = 'SELECT trunkid,channelid,outcid FROM trunk_list AS resource LEFT JOIN (SELECT src FROM cdr WHERE dst LIKE "%'.substr($revolver,-10,10).'" AND disposition<>"FAILED" ORDER BY calldate DESC LIMIT 5) AS filter ON outcid=src WHERE src IS NULL LIMIT '.$link.',2';
$sqlArray = bd_bridge('asteriskcdrdb',$sqlStr);

Получаем из базы id и cid транка по всем необходимым критериям: не использовался вместе с этим клиентом менее пяти раз и статус звонка не содержал ошибку.

echo ($sqlArray[0]['channelid'])? $sqlArray[0]['channelid'].'|'.$sqlArray[0]['outcid'] : '';

Посольку вернуть мы можем только один аргумент,  а передаваемых значений – пара, конкатенируем их через разделитель, а после уже в диалплане разделим вновь.

$sqlStr = (count($sqlArray)==2) ? 'update lasttrunk set line = (line+1)' : 'UPDATE lasttrunk SET line="0"';
bd_bridge('asteriskcdrdb', $sqlStr);

Последним действием мы либо смещаем указатель на следующий транк, либо при исчерпании списка – сбрасываем его на первое значение.

Рассмотрим API в действии. Отправлять запросы будем через запросы из адресной строки браузера, а состояние мониторить в консоли сервера. Осуществляем первый запрос:

https://ip_asterisk/verphone/?phone=8961******6&idblank=0001

Ждём 10 секунд и смотрим, что получилось в консоли:

Здесь хорошо видно, что первый транк на момент звонка был недоступен и была повторная инициация вызова. Она прошла успешно, но в течении 10 секунд клиент не ответил на вызов. Проверим статус через запрос:

Делаем ещё одну проверку, но в этом случае отвечаем на вызов сразу:

Дозвон успешно осуществлён через первый найденный транк и вызов был отвечен. Смотрим статус через API:

В то же время на телефоне получена следующая информация:

Что соответствует данным со стороны лога asterisk и данным из API. Поставленная задача выполнена: мы поучили приложение, которое:

1. Осуществляет дозвон клиенту посредством чередующихся транков
2. При недоступности одного из транков берётся следующий, не чаще пяти раз на один клиентский номер
3. Статус звонка записывается во внутреннюю базу данных и возвращается по запросу