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

Но если каждая поездка по-прежнему зависит от обычного телефонного звонка между двумя личными мобильными номерами, возникают другие проблемы. Действительно ли пассажиру и водителю нужно видеть настоящие номера друг друга? Что делать, если пассажир находится за границей и традиционный голосовой роуминг обходится дорого? Смогут ли они связаться, если голосовая сеть оператора перегружена, но мобильная передача данных продолжает работать? И после завершения поездки должна ли у кого-либо из сторон оставаться личная контактная информация, которая уже не имеет отношения к этой операции?

Встроенные VoIP-звонки дают один из способов решить эти вопросы. Когда Uber внедрил VoIP-звонки в 2018 году, платформа уже поддерживала SMS, чат внутри приложения и обычные телефонные звонки. VoIP был не просто ещё одной кнопкой «Позвонить». Он перенёс голосовое общение в реальном времени глубже во внутреннюю коммуникационную среду приложения.

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

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

Голосовые звонки во время поездки обычно короткие, но требуют быстрой реакции. Пассажиру может быть достаточно сказать: «Я у восточного входа», а водитель может ответить: «Здесь нельзя остановиться. Пройдите, пожалуйста, примерно 50 метров вперёд». Такие разговоры тесно связаны с конкретной поездкой и обычно имеют значение только пока она активна.

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

Этот подход прост, но создаёт несколько структурных ограничений.

• Коммуникационная идентичность привязана к реальному номеру телефона. Без маскирования номера или другого механизма защиты конфиденциальности пассажир и водитель могут увидеть личные мобильные номера друг друга.

• Звонок отделён от бизнес-процесса.  Переход с экрана поездки в штатное приложение для звонков ослабляет прямую связь между разговором и активным заказом.

• Стоимость международных звонков может быть непредсказуемой. Путешественник может столкнуться с расходами на роуминг или международную голосовую связь, если звонит местному водителю с иностранной SIM-карты.

• Доступность зависит от голосовой услуги оператора.  Даже если мобильный интернет продолжает работать, проблемы в традиционной голосовой сети могут помешать совершить звонок.

VoIP меняет эту границу. Голос передаётся как IP-данные через интернет-соединение, поэтому пользователю не обязательно устанавливать обычный PSTN-звонок или голосовой звонок через оператора, используя номер телефона другой стороны.

Какие проблемы на самом деле решает VoIP внутри приложения?

Для пользователя эта функция может выглядеть всего лишь как кнопка «Позвонить». Однако с точки зрения платформы VoIP меняет и способ установления звонка, и то, как сам разговор связан с приложением.

Голосовая связь больше не обязана полностью зависеть от традиционной телефонной сети

VoIP передаёт голосовой медиапоток через интернет-соединение. Если мобильные данные или Wi-Fi обеспечивают достаточное качество связи, приложение может установить голосовой сеанс в реальном времени без полной зависимости от обычной голосовой услуги оператора.

Это не означает, что VoIP автоматически надёжнее в любой ситуации. Качество звонка по-прежнему зависит от задержки, джиттера, потери пакетов, пропускной способности и переключений между сетями. VoIP даёт дополнительный канал связи. Если у пользователя уже есть рабочее соединение передачи данных для приложения, голос потенциально может использовать ту же сетевую среду.

Международная связь может меньше зависеть от стоимости голосового роуминга

Это особенно полезно в поездках и для мобильных приложений, работающих в разных странах. Пассажир, который за рубежом использует SIM-карту своей страны, может платить за роуминг при звонке местному водителю через традиционную телефонную сеть.

Встроенный VoIP-звонок в основном использует передачу данных. Если у путешественника уже есть местный мобильный интернет, международный пакет данных или доступ к Wi-Fi, разговор не обязательно тарифицируется так же, как обычный международный голосовой звонок. Расходы на данные всё равно возможны, но модель затрат отличается от традиционного голосового роуминга.

Поэтому VoIP особенно актуален для сервисов заказа поездок, туристических платформ, гостиничных услуг и международной клиентской поддержки. Голосовая связь остаётся доступной, но её транспортная и тарифная модель смещается от традиционной телефонной сети к соединению передачи данных приложения.

Связь остаётся внутри приложения

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

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

С точки зрения архитектуры продукта связь становится собственной бизнес-функцией платформы, а не внешней возможностью, добавленной к приложению.

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

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

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

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

Это особенно ценно для водителей. За день водитель может общаться со многими незнакомыми пассажирами. Если каждая поездка раскрывает его личный номер телефона, риск для конфиденциальности со временем накапливается.

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

Что меняется в архитектуре, когда VoIP становится возможностью платформы?

С инженерной точки зрения встроенный VoIP — это намного больше, чем добавление захвата звука с микрофона и воспроизведения аудио в мобильный клиент. Для надёжной работы за приложением должен существовать полноценный тракт связи в реальном времени.

Типичную архитектуру встроенной голосовой связи можно разделить на несколько логических компонентов:

• Мобильные клиенты:  Обрабатывают исходящие и входящие звонки, захват звука с микрофона, воспроизведение удалённого аудио и функции устройства, такие как громкая связь и переключение на Bluetooth-гарнитуру.

• Идентификация и бизнес-логика:   Определяют, кто кому может звонить. Например, общение можно разрешить только пассажиру и водителю, связанным с текущей активной поездкой.

• Управление вызовами:   Управляет установлением звонка, сигналом вызова, ответом, завершением и состоянием сеанса.

• Передача медиа: Передаёт аудио в реальном времени и обрабатывает прохождение через сети, изменение условий подключения и, при необходимости, ретрансляцию медиапотока.

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

Для этой архитектуры нет единственного обязательного протокола. Система может использовать SIP, WebRTC или другой фреймворк связи в реальном времени. Для бизнес-платформы важнее связать идентичность пользователя, авторизацию поездки и голосовой сеанс.

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

С этой точки зрения ценность VoIP заключается не просто в «оцифровке телефонного звонка». Приложение получает возможность управлять голосовой связью так же, как оно уже управляет сообщениями, местоположением, платежами и статусом заказа.

Успешный мобильный VoIP требует большего, чем просто установление звонка

На демонстрации продукта VoIP может казаться готовым, как только два телефона способны разговаривать друг с другом. Реальные мобильные сети гораздо менее предсказуемы.

Пользователь может переключиться с Wi-Fi на 4G или 5G, войти в подземную парковку, оказаться в лифтовом холле или дойти до границы покрытия сети. Задержка меняется, пакеты могут теряться, а доступная пропускная способность — колебаться от момента к моменту.

Поэтому зрелые мобильные VoIP-системы обычно уделяют внимание нескольким эксплуатационным возможностям:

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

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

VoIP переводит коммуникацию от телефонных номеров к бизнес-идентичности

С точки зрения долгосрочной архитектуры продукта одно из важнейших изменений, которые приносит встроенный VoIP, состоит не в том, что голос передаётся по IP. Главное — логика, определяющая, «кто с кем может общаться», может перестать зависеть от телефонных номеров.

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

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

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

Когда транзакция заканчивается, вместе с ней может завершиться и коммуникационная связь.

Именно поэтому роль VoIP в мобильных приложениях выходит далеко за рамки снижения стоимости звонков. Платформа может объединить голос, сообщения, идентичность пользователя и бизнес-состояние в одной модели коммуникации.

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

Часто задаваемые вопросы

Требуется ли для VoIP внутри приложения традиционная IP PBX?

Не обязательно. IP PBX полезна, когда системе также нужно управлять корпоративными внутренними номерами и SIP-терминалами, но мобильное приложение может использовать отдельную RTC-платформу, архитектуру WebRTC или облачный коммуникационный сервис.

Необходимость IP PBX во многом зависит от того, должно ли приложение также подключаться к SIP-телефонам, PSTN-номерам, контакт-центрам или другим корпоративным голосовым системам.

Почему VoIP-звонки сложнее, когда приложение работает в фоновом режиме?

Мобильные операционные системы ограничивают длительную фоновую активность, чтобы экономить заряд батареи и системные ресурсы. Поэтому входящие VoIP-звонки обычно должны использовать push-уведомления, системные фреймворки телефонии и восстановление сеанса на уровне приложения, а не рассчитывать на то, что приложение постоянно активно.

Должен ли VoIP быть единственным способом связи для экстренных вызовов?

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

Стандартный VoIP внутри приложения лучше подходит для деловой связи, например звонков между пассажиром и водителем, клиентской поддержки или общения между выездными сотрудниками.

Что компании следует протестировать в первую очередь при добавлении VoIP в собственное мобильное приложение?

Тестирование должно выходить за рамки базового установления звонка. Уже на раннем этапе следует проверять слабые сети, переходы между Wi-Fi и мобильной сетью, входящие звонки в фоновом режиме, переключение Bluetooth-гарнитуры, эхо, дорожный шум и стабильность длительных разговоров.

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