Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

...

We need to understand how stable, reliable  and what is the performance of SMS channel processes. In order to be able to do that there are must be predefined metrics related to SMS process and  we need to store counters and log data.

Logic

As for now there are 2 types of SMS - for verifications and for receiving info related to reimbursement.

We use IP2SMS to send SMS:

Info
titleSingle SMS request

<message>
<service id="
single" start="время начала" validity="период  source="исходящий номер"/>
<to ext_id=«опциональный ид. сообщения»>номер получателя</to>

<body content-type="тип содержимогоencoding="кодировка"
тело
</body>

</message>

The response is received:

Info
titleSingle SMS response

<status id="ид сообщения" date="дата и время" ext_id=”опциональный ид. сообщения если был передан”>

<state error="сообщение об ошибке">статус</state> </status>


To receive additionally info about SMS status next request must be sent:


Info
titleSingle SMS status request
<request id="ид сообщения">status<request>

And response will be next:


Info
titleSingle SMS status response

<status id="ид сообщения" date="Wed, 28 Mar 2007 12:35:00 +0300">

<state>Delivered</state>
</status>


Next values are available for statuses:


SMS StatusDescription
AcceptedSMS was accepted by IP2SMS platform, but without attempt to deliver it yet
EnrouteSMS still in the delivery process
DeliveredSMS was successfully delivered
ExpiredTime limit was richer and there won't be attempt to deliver SMS
DeletedSMS was deleted from system by admin
UndeliverableSMS can't be delivered
RejectedSMS was rejected because had some errors
UnknownSMS status is unknown
UnacceptedSMS can't be accepted

Terminated

SMS was processed (got one of the statuses: accepted, enroute, unknown, pending), but not delivered due to timeout

UnacceptedPending

SMS can't be acceptedin progress of delivery


All data must be stored in the table verification.sms_log which has next fields and updated according to the job (sms statuses update)


Field nameDescription 
id
phone_number
type('verification', 'medication_request)
body SMS text 
gateway_idstatus_id from response
gateway_statusSMS Status (see the table above)
status_changed_atdate from status response 
updated_atTIMESTAMP
inserted_atTIMESTAMP

As soon as there is a new verification SMS in verification.verifications table it's also must be replicated to verification.sms_log, though only one time (in table verification.verifications there are also field attempts count which must be ignored).