Extended generic SMPP with SMSC name 'CLX' issues DCS value 241 by default - is this right?

Hi Jim,

The answer I get from experts would be to check this point with your provider.

As mentioned in the documentation (on the very page you pointed to in your first message):

The mapping between the data_coding value and the encoding actually used is standardized. Nevertheless, certain SMSC have their own specific mapping: in this case, your Adobe Campaign administrator needs to declare this mapping. Check with your provider to find out more.

I will double check with other teams to see if your specific case has already been encountered. In the meantime, please keep us posted with what you hear from your provider.

Hope this helps,

Florent

Hi Florent

Thank you for getting back to me. Actually we already have CLX's steer on this - far from requesting their own specific mapping, CLX are requesting any standard one that is consistent with SMPP v3.4 as a resolution to soft bounces and transmission delays - and asserting that 241 is not a standard value.

"Data Coding is a field and part of the SMPP 3.4 whitepaper. It appears that your submissions were submitted with a DCS (Data Coding Scheme) outside the range of the SMPP protocol (your DCS is set to 241 in the current examples). Please change the DCS to be within the SMPP 3.4 specifications, or let us know why it might be outside the range?"

In the absence of any specific mapping required by CLX, should we perhaps attempt to reestablish the default behaviour my adding an explicit mapping of GSM 03.38 (7 bit) to data_coding=0? There are no mappings currently declared.

I'd happily do this, but ideally would first understand why this isn't happening out of the box, and where the DCS=241 value is coming from (for example, there is no forced character encoding in the associated SMS delivery component).

Given CLX's response, do you suggest we simply work around the problem by adding an explicit mapping to reinstate the usual default behaviour, or should we be worried by the 241 value reported by CLX?

Thank you again

Jim

Hi Jim,

Possible actions depend on the Campaign version you are running.

From build 8770, we introduced a new SMPP connector that is compliant with the SMPP 3.4 protocol. It follows the rules defined in the encoding mapping table of the external account. Documentation is available here: Mobile channel

If you are running an older version of Campaign and by extension of the SMPP Connector, the answer I got from our experts is that it switches to unicode as soon as it cannot encode a message in GSM, there is nothing we can do to change this.

Hope this helps,

Florent.

Hi Florent,

Thank you for following up. We are exactly on build 8770 of version 6.1.1, so the 241 value is strange. Nonetheless we have now added a mapping from GSM 03.38 to data_coding=0 to reinstate the default behaviour and are working with CLX to assess whether this makes a difference.

Regards

Jim

Hi Jim,

Indeed it's strange if you're already on a recent build. Were you able to work this out?

Let me know,

Florent.

Hi Florent

Our client is still to try an explicit mapping of GSM 03.38 (7 bit) to data_coding=0, which I am hopeful will resolve the problem. We will let you know on this point.

Meantime CLX are reporting a separate issue in relation to transmit and receive bindings. Apparently Campaign is requesting multiple transmit bindings, whereas CLX is expecting a maximum of two bindings: one transmit and one receive. With both CLX bindings allocated to transmit, it is finding no way to routinely return delivery reports. I cant spot any console configuration options in relation to this. I did wonder whether there might be a problem in relation to the allocation of SMPP accounts to our two Campaign installations (staging and production), for example if staging were to use the same account as production when transmitting, but this isn't the case - production and staging are using separate accounts. Any thoughts for us?

Regards

Jim

Hello Jim,

Answer I get from our experts is:

When establishing connections, each SMPP connector thread creates a configurable amount of connections. The number of connections is defines in the external account, whereas the number of connector threads is defined in the config-instance.xml file. Bear in mind that each running MTA will spawn its own set of threads, so the total number of connections to the provider is defined like this:

Total connections = connections per thread * number of MTA child * number of running MTAs

To avoid database contention it is recommended to keep the number of SMPP threads low (1 or 2). It is much more efficient to increase the number of connections per thread, which decreases CPU context switches.

So my guess is that the configuration you are looking for is to be done in the configuration file of the instance. In case of hosted implementation, changes to this file can be done after contacting support.

Hope this helps,

Florent

Hi Florent,

Which is the best channel to contact support on for this issue?

Will we need Adobe tech ops to work directly with CLX for this issue, or can it be solved just by Adobe?

Thanks,

Andy