Какие ошибки вы обнаружили, программируя SMS / оповещения?

Question

Я собираюсь приступить к созданию функции оповещения SMS в моем веб-приложении. Целью является предоставление двух услуг:

1. Хост платит - например, отправить SMS с предупреждением пользователям об отмене события
2. Пользователь платит - например, чтобы предупредить, что электронное письмо было отправлено, скажем, с подробностями нового события (очевидно, это требование пользователей, когда они находятся за пределами своих систем EMail!)

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

Из моего исследования:

1. Я могу использовать стороннего поставщика SMS-шлюза. Стоимость составляет около 0,05 фунтов стерлингов за сообщение. Я могу отправить сообщение по электронной почте на адрес 999999999@TheGatewayProvider.com или использовать HTTP-запрос с подходящими параметрами в URL.

2. Я могу отправить электронное письмо сетевому провайдеру пользователя (я полагаю, это доступно только в США)

РЕДАКТИРОВАТЬ : Существуют различные варианты того, как различные поставщики будут обрабатывать сообщения От / Тема и Сообщение, поэтому представление фактического отправленного сообщения может быть трудно предсказать.

3. Я могу настроить свой собственный шлюз (который, я думаю, выходит за рамки моих возможностей и может принести горе в наш центр обработки данных!)

Меня поражает, что:

E-mail, который мы отправляем, иногда задерживается в очереди SMTP моего сервера, не говоря уже о нисходящих очередях. Отправка электронной почты на SMS-шлюз сетевого оператора часто рассматривается как низкий приоритет.

Поэтому HTTP к стороннему провайдеру SMS-шлюза должен дать мне самую короткую задержку (важно для «Это событие после обеда отменено из-за плохой погоды»)

Когда я отправляю SMS-сообщение со своего мобильного телефона, иногда на это уходит несколько дней - я полагаю, это то, с чем нам просто нужно жить?

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

Мне также интересно, будет ли возможность пользователям эффективно использовать IM и Twitter, а также другим подобным методам на практике?

Из сторонних шлюзов, на которые я смотрел, кажется:

Некоторые используют сети более высокого класса, чем другие, это может повлиять на производительность? (или это просто маркетинговая фигня?)

Некоторые обеспечивают лучшую обратную связь, чем другие. Мне нужно свести аргументы за выставление счетов - и сколько именно «кредитов» клиент использовал - к минимуму; поэтому я получаю ответ «OK» / «Номер телефона не существует», поэтому мне кажется важным. Один провайдер, которого я нашел, ежедневно создает текстовый файл журнала, который можно загружать и который я могу согласовать со своим исходящим журналом.

Буду признателен за ваше мнение и опыт:

Пользователи будут вводить номера своих мобильных телефонов так, как они их знают. Нужно ли применять +9912345 ... чтобы я тоже получил код страны?

Что произойдет, если мобильный телефон иностранный (я нахожусь в Великобритании) Получатель оплачивает международную часть? или у провайдера шлюза, возможно, есть локальные службы передачи?

Что мне нужно делать с не альфа-символами? На ум приходит знак британского фунта "£" и CR / LF. Если они закодированы, это может привести к тому, что сообщение сразу после ограничения длины превысит его (после того, как оно будет закодировано (так что мне нужно встроить это в проверку формы создания сообщения). Новые линии CR + LF или только CR?

Есть ли у каких-либо шлюзов симуляции? чтобы я мог протестировать свое приложение без каких-либо фактических затрат на SMS-сообщения.

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

Буду очень признателен за любые ваши ошибки и предложения. Спасибо.

Answer 1

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

Когда кто-то отправляет вам сообщение, которое имеет срочное значение, а затем отправитель (владелец трубки) подходит к вам и спрашивает, получили ли вы сообщение, и это меня раздражает, может возникнуть ряд потому что вы можете утверждать, что не получили его, что заставляет отправителя испытывать чувство раздражения / недовольства / злости из-за того, что вы «проигнорировали их» или «не ответили», хотя на самом деле это связано с сетевыми проблемами провайдера.

И, как ни странно, примерно через час после ссоры ваш телефон издает звуковой сигнал, и ваше сообщение от отправителя прибыло !!!! Это случалось со мной несколько раз! Но что я могу сделать, даже не зная, что происходит на стороне отправителя (кризис, срочный запрос и т. Д.)

Так что будьте осторожны, если отправляете сообщение через ethernet (интернет) на телефонную трубку, так как ethernet не является на 100% стабильным (маршрутизаторы не работают, пропадают DNS, перебои в работе сервера и т. Д.), Поэтому стоит помнить об этом. Вроде вопрос как можно гарантировать мгновенную доставку смс? Это большой вопрос, и надежность должна придти, обычно для этого требуются дополнительные усилия ...

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

Извините, если это кажется бессвязным ...

Надеюсь, это даст вам пищу для размышлений, С наилучшими пожеланиями, Том.

Answer 2

SMS - это услуга телефонной связи, а не интернет-услуга. Это приходит с некоторыми другими правилами.

Для начала, многие конечные точки оплачиваются / оплачиваются и имеют контракты с одним поставщиком услуг. Это будет включать все ваши варианты использования.

Во-вторых, выставление счетов является контрактным вопросом как для отправляющей, так и для принимающей стороны. Вы просто не можете заявить в качестве отправителя, что «Хост платит», если вы не ограничиваете себя отправкой SMS в определенные страны. США является самым известным исключением. «Получатель платит» еще хуже. Из-за SMS-спама операторы, как правило, разрешают такой трафик только при наличии с ними договора

Сторонние SMS-операторы могут справиться со многими из этих проблем. Им очень легко быть более ориентированными на обслуживание, чем обычные операторы. Они могут даже быть в состоянии доставить международные SMS для вас.

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

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

SMS использует свой собственный алфавит, довольно неприятное мультисептатное кодирование (7/14/21 бит!) Ограничение в 160 символов, указанное в кавычках, происходит из полезной нагрузки в 140 байт. Это также может быть закодировано как 70 символов UTF-16.