SMPP protocol deep dive and troubleshooting

Transcript

Hello everyone, and welcome to the fourth SMS setup video. I’m Jean Mathieu, and together we’ll dive deep into the SMS protocol, and we’ll see how to troubleshoot SMPP connections. First, we’ll see how SMPP connections are made. Then we’ll see how SMPP exchanges data by the means of PDUs. Then we’ll see the most useful PDUs, namely the bind operation, the submit SM and deliver SM operations. And finally, we’ll have a first approach to how to troubleshoot connections. And before we begin, this video will show you extracts of the short message peer-to-peer protocol specification. This is the document used to describe the SMPP protocol. It is available on smpp.org. You don’t have to read the whole document, but knowing what’s inside can be helpful to refer to this document when communicating with the provider, or searching for precise error codes. So now we’re ready to have a look at SMPP connections. SMPP uses TCP or SSL, or now TLS connections. The connection is always initiated by campaign, to the provider. SMPP connections are supposed to be permanent and stable. This is very different from HTTP for example, where connections are made only when needed. It means that there is no polling or no batching of messages. Every message is a separate entity. Inside these connections, you send PDUs, meaning protocol data units. Both campaign and the provider can send and receive PDUs at any time. One PDU means one operation, and one operation PDU is followed by a resp PDU, meaning response. Operation PDUs and resp are matched by a field named sequence number. So let’s see what’s inside a PDU. All PDUs are formatted the same way. Command length, this is the size of the PDU. Command ID, which is the kind of PDU. The operation. The command status, which is basically an error code. And the sequence number, used to match operation and resp PDUs. And then depending on the command ID, the PDU can contain more fields. We’ll see a few examples later. So we said sequence number matches PDUs and resp. And command status is an error field. On the right you can see a table of the most common values for command status. The most important value here is zero, meaning no error. So basically when you have issues, if command status is not zero, then you know something’s wrong. The full table is available in the SMPP specification, but also many providers add specific command status values. So let’s see a few examples. For example the bind operation. A bind exchanges login and password. It’s the first PDU exchanged when establishing a connection. Exchanging login and password is for authentication and authorization purposes. But this is a very weak mechanism, so if you want better security you should use TLS. The bind operation is acknowledged by a bind resp PDU. And also when closing the connection, the connector will send an unbind operation and wait for unbind resp. This step is inherited from the old telco protocols. So it’s a bit meaningless nowadays, but we have to do it anyway. Beware that some providers call connections binds. If somebody tells you you have 5 binds available, then they probably mean 5 TCP connections at any time. There are 3 kinds of bind operations. They are bind transmitter, so this connection is used to send MTs. Bind receiver, so this connection can be used to receive MO and SR. And finally there is bind transceiver, which is able to both send and receive data. Of course transceiver mode is the one to prefer, because this is more efficient. And this is what you can find in a bind operation PDU. We won’t go into too much details right now, but you can see the system ID and password in the table 4.1, which is the bind operation PDU. And in the bind resp on the right hand table, you’ll see command status, which indicates whether the bind was successful or not. This command status is really important, because it determines whether the connection was successful or not. So when you have connection issues, this is one of the first things you want to look at. Then let’s have a look at submit SM and deliver SM. Submit SM is used to send one MT to be delivered on a mobile phone. The PDU contains all the information needed to send an SMS. So the text, the encoding, the recipient phone number, and a lot of other things. The submit SM PDU is acknowledged by submit SM resp. Submit SM resp means that you successfully sent the SMS to the provider. But do not confuse submit SM resp and an SR. SR means that the SMS was successfully received by the mobile phone. So if you want to know if the SMS was delivered or not, you want to have a look at SR, not submit SM resp. Finally, for long messages, there are two cases. There is the normal way with UDH. There is one submit SM PDU per part. So if your SMS is split in two parts, you will see two submit SM PDUs. And if you enable the message payload, then a single submit SM PDU will be sent per long SMS. The provider will have to split the message on their side before sending it to the mobile phone. Here are a few values you can find in the submit SM and submit SM resp PDUs. You can see source address, destination address, which are the phone numbers, data coding indicating the text encoding for this message, SM length indicates the size of the message in bytes, and then the short message field that contains the actual message to transfer. And the submit SM resp PDU contains two important fields. That is the command status, again to know if the operation was successful or not, and the message ID, which is used to match the MT and the SR together. Now let’s talk about deliver SM. Deliver SM is for all incoming traffic, both MO and SR. It works basically like submit SM, but the other way around. It’s acknowledged by deliver SM resp, and you should know that campaign is 100% synchronous when handling deliver SM. It means that when deliver SM resp is sent by campaign, you can be sure that all processing is finished and data is secured. So if you have MO or SR issues, the first thing to check is the deliver SM resp. To differentiate between MO and SR, you may have a look at ESM class. This field usually is 0 for MO and 4 for SR. The message ID received from submit SM resp is sent into the text field of SR. In campaign, it is processed by regular expressions. And now a few hints to start troubleshooting a SMS connection. So first you have to make sure it is actually a SMS connector issue. If you have targeting, preparation, delivery analysis, typology or workflow issues, these are not specifically SMS issues, and they can be handled like issues for other channels in campaign. Also work with the provider first. You have to ask for a concrete proof that the issue is in campaign, meaning a network capture, a log with the PDUs or instructions of the provider showing something that does not match the SMPP specification. Just saying the connections are up or the statistics are poor is not enough. In campaign, you can obtain PDU traces via a network capture if you do not use TLS or using Verbox logs. For Adobe hosted instances, these logs can only be obtained by support. When you have these logs, check for potential defects. For example, a non-zero common status in any kind of resp PDU. Remember that if a resp PDU coming from the provider has a non-zero common status, then the issue is on the provider side. It works the same with missing PDUs or duplicated PDUs. Duplicated PDUs very often happen when there was a timeout and a retry. So if you see duplicated PDUs, search for missing PDUs such as expected resp or PDUs coming too late. Also check for resp PDUs with the wrong sequence number. For example, if you saw PDUs with sequence number 1, 2 and 3, and if you see a resp PDU with a sequence number of 104, then there is probably an issue somewhere. In fact, there is certainly an issue somewhere. And finally, if the connection is unbound or closed unexpectedly, then there is probably an issue somewhere. Remember that ACC does not keep all connections up at every time because of technical limitations. But if you see connections going up and down all the time, there may be an issue. When searching for solutions, first talk with the provider. They are here to help you. Also, the SMS tech note has many answers. Don’t hesitate to experiment a bit with external account settings. Trial and error is a very effective strategy for timeouts, throughputs, or window adjustments. And finally, if you have performance issues, if the performance issue is on the campaign side, you have to know that SMS is a very database intensive process. So having huge workflows running, huge data imports, or big campaigns being prepared while sending SMS may have an impact on throughput. And this concludes this video. Knowing the SMPP protocol is really useful when troubleshooting or setting up new connections. So I really encourage you to learn more about it and have a look at it when working on SMS with Campaign. That was Jean Mathieu, and thank you for watching.