Обнаружение отказа от звонков в Twilio Dial

Обнаружение обрывов звонков в Twilio вызовах

Для обнаружения обрывов звонков в Twilio вызовах необходимо отслеживать события прогресса звонка через вебхуки StatusCallback и анализировать временные интервалы между событиями. Наиболее надежный метод включает отслеживание последовательности состояний звонка (инициирован → звонит → отвечен/завершен) и сравнение временных меток для определения, прервал ли звонивший до достижения состояния ответа.

Содержание

• Понимание обнаружения обрывов звонков
• Использование StatusCallbackEvent для отслеживания прогресса
• Использование параметра AnsweredBy
• Анализ длительности звонка как индикатора
• Практические примеры реализации
• Лучшие практики обнаружения обрывов

Понимание обнаружения обрывов звонков

Обрыв звонка происходит, когда звонящий прерывает вызов до достижения состояния “отвечен”. Это обычно происходит в фазе звонка, когда звонящий теряет терпение или решает не ждать ответа.

Согласно документации Twilio по отслеживанию статуса звонка, Twilio предоставляет несколько событий вебхуков, которые помогут вам отслеживать прогресс вызовов:

• initiated: Вызов инициирован
• ringing: Абонентская сторона вызывается
• answered: Звонок отвечен (человеком или автоматом)
• completed: Звонок завершен

Обрыв звонка можно обнаружить, когда вызов переходит из состояния initiated → ringing, но никогда не достигает answered, а переходит напрямую в completed.

Использование StatusCallbackEvent для отслеживания прогресса

Для эффективного обнаружения обрывов звонков необходимо настроить StatusCallback для получения соответствующих событий прогресса вызова. Это делается путем указания параметра statusCallbackEvent в глаголе или при создании ресурса Call.

Документация по вебхукам голосовых вызовов Twilio объясняет, что вы должны указать эти события в параметре StatusCallbackEvent: initiated, ringing, answered и completed.

Вот как это можно настроить в TwiML:

<Response>
  <Dial statusCallback="https://ваш-сервер.com/статус-звонка" 
        statusCallbackEvent="initiated,ringing,answered,completed"
        statusCallbackMethod="POST">
    <Number>1234567890</Number>
  </Dial>
</Response>

При получении этих вебхуков вы должны отслеживать временные метки и последовательность событий. Если вы получаете событие initiated, затем событие ringing, но нет события answered до завершения звонка, это указывает на обрыв.

Использование параметра AnsweredBy

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

Как объясняется в документации Twilio по детектированию автоответчика, когда детектирование автоответчика включено, Twilio отправляет параметр AnsweredBy со значениями, такими как:

• human - Ответил человек
• machine_end_beep - Автоответчик со звуком сигнала
• machine_end_silence - Автоответчик с тишиной
• machine_end_other - Автоответчик с другими индикаторами
• unknown - Не удалось определить, что ответило

Для использования этого в обнаружении обрывов, вы должны включить детектирование автоответчика в глаголе :

<Response>
  <Dial machineDetection="Enable" 
        statusCallback="https://ваш-сервер.com/статус-звонка"
        statusCallbackEvent="initiated,ringing,answered,completed">
    <Number>1234567890</Number>
  </Dial>
</Response>

В вашем обработчике вебхуков вы можете проверять как состояние звонка, так и параметр AnsweredBy для определения сценариев обрывов.

Анализ длительности звонка как индикатора

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

Обсуждение на Stack Overflow об отслеживании обрывов звонков Twilio Dial показывает, что разработчики часто задаются вопросом, является ли длительность звонка лучшим индикатором. Однако существуют более подходящие методы:

1. Анализ последовательности событий: Отслеживайте прогресс состояний звонка, а не только длительность
2. Анализ времени звонка: Отслеживайте, как долго звонок звонил до обрыва
3. Сравнение временных меток: Сравнивайте временные метки между событиями initiated, ringing и completed

Например, если звонок переходит из initiated в completed, никогда не достигая ringing, он может быть заблокирован или немедленно отклонен. Если он проходит через ringing, но никогда не answered, это указывает на обрыв.

Вот как вы можете реализовать эту логику в вашем обработчике вебхуков:

# Псевдокод для обнаружения обрывов звонков
def handle_call_status(request):
    call_sid = request.POST.get('CallSid')
    call_status = request.POST.get('CallStatus')
    answered_by = request.POST.get('AnsweredBy', '')
    timestamp = request.POST.get('Timestamp')
    
    # Сохраняйте или извлекайте предыдущие состояния звонка для этого call_sid
    
    if call_status == 'completed' and not previously_answered:
        # Проверяем, был ли звонок, но без ответа
        if had_ringing_event:
            # Это обрыв - звонящий прервал во время звонка
            log_abandonment(call_sid, 'during_ringing')
        else:
            # Звонок не достиг состояния звонка
            log_abandonment(call_sid, 'failed_to_ring')

Практические примеры реализации

Вот полный пример реализации обнаружения обрывов звонков:

Обработчик вебхуков на стороне сервера (Node.js)

const express = require('express');
const app = express();
app.use(express.urlencoded({ extended: true }));

// Сохраняем состояния звонков в памяти (в продакшене используйте базу данных)
const callStates = {};

app.post('/call-status', (req, res) => {
    const { CallSid, CallStatus, AnsweredBy, Timestamp } = req.body;
    
    // Инициализируем состояние звонка, если оно не существует
    if (!callStates[CallSid]) {
        callStates[CallSid] = {
            initiatedAt: null,
            ringingAt: null,
            answeredAt: null,
            completedAt: null,
            abandoned: false
        };
    }
    
    const callState = callStates[CallSid];
    
    // Обновляем состояние звонка на основе текущего события
    switch (CallStatus) {
        case 'initiated':
            callState.initiatedAt = Timestamp;
            break;
            
        case 'ringing':
            callState.ringingAt = Timestamp;
            break;
            
        case 'answered':
            callState.answeredAt = Timestamp;
            break;
            
        case 'completed':
            callState.completedAt = Timestamp;
            
            // Проверяем на наличие обрыва
            if (!callState.answeredAt && callState.ringingAt) {
                callState.abandoned = true;
                const ringDuration = calculateDuration(callState.ringingAt, Timestamp);
                console.log(`Звонок ${CallSid} прерван после ${ringDuration} секунд звонка`);
                // Запускаем рабочий процесс для прерванных звонков
                handleAbandonedCall(CallSid, ringDuration);
            }
            break;
    }
    
    res.send('');
});

function calculateDuration(start, end) {
    // Реализуйте расчет разницы временных меток
}

function handleAbandonedCall(callSid, duration) {
    // Отправляем уведомление, обновляем аналитику и т.д.
}

app.listen(3000);

Ответ TwiML с расширенным отслеживанием

<Response>
  <Dial 
    statusCallback="https://ваш-сервер.com/статус-звонка"
    statusCallbackEvent="initiated,ringing,answered,completed"
    statusCallbackMethod="POST"
    machineDetection="Enable"
    timeout="30">
    <Number>1234567890</Number>
  </Dial>
</Response>

Лучшие практики обнаружения обрывов

1. Включите комплексное отслеживание событий: Всегда отслеживайте события initiated, ringing, answered и completed, чтобы получить полную картину прогресса звонка.

2. Сохраняйте состояния звонков постоянно: Используйте базу данных, а не хранилище в памяти, для отслеживания состояний звонков между перезапусками сервера.

3. Реализуйте обработку таймаутов: Устанавливайте соответствующие значения таймаута, чтобы различать нормальное завершение звонка и обрыв.

4. Используйте AnsweredBy для контекста: Детектирование автоответчика помогает понять, что произошло бы, если бы звонящий не прервал звонок.

5. Рассчитывайте значимые метрики: Отслеживайте показатели обрывов, среднее время звонка до обрыва и коррелируйте с другими бизнес-метриками.

6. Настройте уведомления: Настройте оповещения в реальном времени для необычных паттернов обрывов, которые могут указывать на проблемы с сервисом.

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

Согласно документации Twilio по статусу ресурса звонка, завершенный звонок указывает на то, что соединение было установлено и аудиоданные были переданы. Это может произойти, когда звонок отвечает человек, интерактивное голосовое меню (IVR) или даже автоответчик.

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

Источники

1. Tracking the Status of an Outbound Twilio Voice Call – Twilio Support
2. Voice Webhooks | Twilio
3. Answering Machine Detection | Twilio
4. Call resource | Twilio
5. Tracking Twilio call abandonment? - Stack Overflow
6. How to leave a voicemail using Twilio AMD? - Stack Overflow

Заключение

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

• Реализацию комплексного отслеживания StatusCallbackEvent для мониторинга полного прогресса состояний звонка
• Анализ последовательности и времени событий, а не reliance на единичные метрики
• Использование параметра AnsweredBy для понимания, что произошло бы, если бы звонок не был прерван
• Построение надежного отслеживания состояний, которое может различать различные типы результатов звонка

Длительность звонка сама по себе не является лучшим индикатором для обнаружения обрывов. Вместо этого сосредоточьтесь на отношениях между событиями звонка и реализуйте логику, которая может определять, когда звонок переходит из ringing в completed, не достигая состояния answered. Этот подход обеспечивает более точные и действенные сведения о поведении звонящих и паттернах обрывов.