ЕСОЗ - публічна документація

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Purpose

We need to understand how stable and reliable current SMS channel is. 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:

Single SMS request

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

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

</message>

The response is received:

Single SMS response

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

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


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

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

And response will be next:

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

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

Next values are available for status:

  • 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

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

  • Field nameDescription 
    id
    phone_number
    body SMS text, for verifications SMS body='VERIFICATION' 
    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).




  • No labels