Sinch Community

If you are submitting a bind request (SMPP bind_req), and are unable to establish a connection, the cause may be because: You are trying to bind more times than your account allows per bind type (Tx, Rx or TRx), which means that Digital Interconnect respond with a rejection and a 'Maximum Sessions Exceeded' message will be recorded in the SMPP log files. You are trying to bind in too early, before the previous session has timed out on the Digital Interconnect side. When you try to bind again, the previous session is still seen as alive and so the bind request is rejected because of the existing live sessions.  Solution When you attempt to bind again, the bind request is rejected because you have reached the maximum number of binds. This will continue until either:   You manage to log out cleanly from your live session (a confirmed unbind) before attempting to bind again You drop the session long enough for it to time out on the Digital Interconnect side You restart the application from your end. You must wait for at least a minute, and then you should be able to successfully bind, because all the live and 'dead' connections that were holding SMPP server resources when trying to bind repeatedly will have been released. When bind issues happen, you must disconnect from all established binds originating from the same IP address, and wait at least one minute before attempting to reconnect (the time-out period is 1 minute from the last traffic sent or received from the IP address). This will ensure that the Digital Interconnect SMPP server can correctly time out and release any threads, sessions and resources that are held for the binds allocated to your account. Once these resources are released your new binds should connect correctly and the resources will be correctly managed.   If you find you still cannot connect, please contact the Digital Interconnect Service Desk. Please refer to the Digital Interconnect Customer Support Document for full details of the Support Process and the guidelines for determining what information you need to include in your ticket email.   ... View more

NG SMPP customers can send and receive MT and MO traffic encoded in either the Default GSM character set or Latin1 character set (ISO/IEC 8859-1).   Digital Interconnect SMPP support for latin1 The NG SMPP account can be configured to use either the Default GSM character set or the Latin1 character set. If you wish to use the Latin1 character set to send and receive MT / MO traffic, you will not be able to use the default GSM characters, and you will still be required to send the correct DCS value to the Digital Interconnect NG SMPP platform for each character set.   If you choose to send traffic using the Latin1 character set, the Digital Interconnect NG SMPP Swiftlet servers will decode the Latin1 MT messages sent by your platform or encode the MO messages into Latin1 for delivery to your platform. The setting is account specific and will not affect any of your other accounts binding from the same IP address.   If you want to provision your account to use Latin1 encoding it is recommended that you discuss the requirement with your Account Manager.   NOTES: This feature is available on the NG SMPP accounts on port 6xxxx range and does not apply to any legacy SMPP accounts or for HTTP accounts. No character encoding changes will be made to any of the Character Mappings used to support this feature. Refer to the MT and MT Mapping File and Characters not in the DGCS document for details of the mappings for MT and MO and the Characters not in DGCS. ... View more

A CSR is a Certificate Signing Request - it is needed for the purchase of a certificate for a URL.   If your require a CSR for a URL, please send your request to your Digital Interconnect Account Manager. ... View more

Question What version of SMPP is supported?   Answer   Swiftlet Only Version 3.4 is supported. SMPP NG Version 3.4 is supported, however, this version is 99% backward compatible so in most cases this will be fine. ... View more

The CWTA - CASL Overview Document outlines Canada’s Anti-Spam Legislation for Common Short Code Applicants, Content Providers and Aggregators. ... View more

Question What aspects of SMS delivery are outside of Digital Interconnect control?   Answer Once an SMS is delivered to an operator’s Short Message Service Center (SMSC), the SMSC then has full control over the delivery of the message. This includes changing a messaging validity period, throttling message delivery, and supporting handset acknowledgements (ACKs).   Typically most SMS messages are delivered in several seconds, but during periods of heavy volume (for example, New Year’s Eve) delivery can take much longer. ... View more

Question How quickly are handset or SMSC acknowledgements delivered back?   Answer Short Message Service Center (SMSC) acknowledgements are returned almost instantly to the Digital Interconnect's Hub, but may not be processed instantly. Instead, it may take 5 to 10 seconds for our system to process and deliver the SMS acknowledgement.   The timing of the return of handset acknowledgements depends upon the transit times through the operator systems. This can take up to 24 hours in certain situations. Upon receipt into the Digital Interconnect system, the acknowledgements are typically processed and delivered within 10-20 seconds. ... View more

The default GSM Alphabet character set (DGSM), as per the GSM338 standards document, supports only a limited set of characters because it is 7-bit encoded.   If you want to send other characters you will need to encode messages in UCS2, which is 16-bit encoded and allows you to send messages using a variety of characters sets, such as, Chinese, Arabic, Russian and accented characters not present in DGSM.   If Content Providers (CPs) don’t know how to encode messages in UCS2 they should use the Digital Interconnect UTF8 interface (HTTP only). They will need to encode a message written from an operating system in UTF8 in Base64 to force the UTF8 encoding - and submit messages to our platform. The A2P platform will check if any character is outside of the DGCS and if there is at least one, then the system will encode the message in UCS2.   Because UCS2 is using 2 bytes and because an SMS is 140 bytes UCS2 messages have a maximum of 70 characters. CPs will need to control the message length or they can use the SplitText parameter and concatenated messages will be generated if the message length > 140 bytes.   For Latin alphabet languages the normal usage for CPs is NOT to use characters outside of DGCS. End-users are usually used to receive messages with missing accents. ... View more

The support process for enterprise services customers is outlined in the Sinch Digital Interconnect Enterprise Services Customer Support Document. ... View more

The Customer Management Portal enables Digital Interconnect customers to create and manage campaign requests for their short codes and to raise support tickets using the Enterprise Messaging Support Ticket tool.   A SAP Digital Interconnect administrator will provide customers with access to the Customer Management Portal.   For more information, read the Customer Management Portal Customer Guide. ... View more

Canada's Anti-Spam Legislation (CASL) will begin to take effect on July 1, 2014 when most of its provisions enter into force. The new law and its associated regulations will apply broadly to any individual, business or organization that makes use of commercial electronic messages (CEMs), is involved with the alteration of transmission data, or produces or installs computer programs. However, the provisions dealing with CEMs are of particular but not exclusive relevance to Common Short Codes. For full details of the CASL - refer to the CMA website.    Once the law is in force, anyone who makes use of CEMs must comply with the applicable requirements and prohibitions under CASL, which apply to the sending of CEMs over most types of platforms, including those delivered via Common Short Codes. The Government of Canada explains that a CEM “is any electronic message that encourages participation in a commercial activity, regardless of whether there is an expectation of profit” and summarizes the requirements applicable to CEMs by noting that “the sender will need to obtain consent from the recipient before sending the message and will need to include information that identifies the sender and enables the recipient to withdraw consent.” All Common Short Code Applicants and Content Providers are responsible for ensuring that any CEMs they send using a Common Short Code fully comply with the requirements of CASL as of July 1, 2014. CWTA is not responsible for ensuring CASL compliance within the Common Short Code Programs. This remains the individual responsibility of each Applicant and Content Provider. CWTA recommends that Applicants and Content Providers leasing Common Short Codes familiarize themselves with the CASL requirements including the legislation and associated regulations to ensure compliance and seek independent legal advice or contact the CRTC where required. Information on CASL, including FAQs and other facts, the law and regulations, oversight and management and enforcement can be found at fightspam.ca. In the coming weeks, CWTA will provide additional summaries of CRTC and Industry Canada guidance materials as they become available that may assist with compliance. ... View more

The US Cellular Campaign Playbook is attached below: ... View more

The following external links may prove useful for finding additional information related to USA and Canada mobile best practices:   MMA Best Practices http://www.mmaglobal.com/bestpractice CWTA – Consumer Rights Wireless Code of Conduct https://crtc.gc.ca/eng/phone/mobile/code.htm   ... View more

DB52 is a SMS 365, enterprise service status code meaning ‘Rejected by operator’. DB52 is a final and intermediate status code as described in the sections below.   DB52 is used when there is no configured mapping between standard API error codes and SDI API error codes. The table below shows the SMPP Status Report code alongside the configured Sinch SDI API mapping. Any number not in the list below, for example, error codes 1, 2, 3, 4 and 5, will be mapped to DB52:   Nobill Code Configured SDI Mapping  0  '450A'  9  'DB63'  10  'DB63'  11  'DB52'  16  'DB05'  17  '4503'  18  'DB52'  40  'DBA6'  61  'DB05'  62  'DB05'  63  'DB05'  64  'DB05'  74  'DB62'  100  'DB63'  102  'DB77'  103  'DB60'  104  'DB60'  107  'DBA6'  109  'DB63'  110  'DBF2'  113  'DB77'  114  '4527'  150  'DB63'  151  '4524'  152  'DB43'  153  'DBA4'  155  'DB77'  156  'DB60'  157  'DB60'  158  'DB44'  159  'DBA3'  200  'DB63'  201  'DB63'  202  'DB63'  205  'DB63'  207  'DB77'  208  'DB60'  209  'DB60'  217  'DB62'  250  'DB05'  251  'DB05'  252  'DB05'  253  'DB05'  254  'DB05'  255  'DB05'  256  'DB05'  257  'DB05'  300  'DB48'  301  'DB48'  302  'DB48'  303  'DB48'  310  'DB48'  311  'DB48'  312  'DB48'  330  'DB23'  331  'DB23'  334  'DB23'  335  'DB23'  336  'DB23'  337  'DB23'  338  'DB23'  339  'DB23'  340  'DB23'  341  'DB23'  342  'DB23'  343  'DB23'  344  'DB23'  345  'DB23'  346  'DB23'  347  'DB23'  348  'DB23'  349  'DB52'  399  'DB52'  Any other code  'DB52'     Possible Reasons for a DB52 response There are a number of reasons why the DB52 status code is returned. Some of these along with the actions that should be taken, are detailed below:   Category Description Action Operator The MT message encountered an error while sending due to error which occurred during the sending process to operator.  DB52 may be returned in intermediate delivery receipts. The customer should retry the service after a short period to confirm if the issue persists. Operator The MT message encountered an error while sending due to error which occurred during the sending process to operator. DB52 may be returned in intermediate delivery receipts. Raise a single user issue (SUI) ticket to the Service Desk (SD), detailing the OrderID, MSISDN and date/time the MT message was sent, so that the SD team can investigate.   Additional information: https://developers.sinch.com/docs/sms/smpp/error-codes/#status-reports-error-codes ... View more

DB05 is a SMS 365, enterprise service status code meaning ‘Call barred by destination operator’ or ‘Rejected by destination operator’, which indicates that the MT message could not be delivered and cannot be retried.   Possible Reasons for a DB05 response   There are a number of reasons why the DB05 status code is returned, some of which along with the actions that should be taken, are detailed below:   Category Description Action End User The end user’s operator has restrictions set on the account based on the tariff and the associated terms and conditions of the account. The end user should contact their network operator, to either remove the restrictions in place, or change the contract to a tariff which permits the SMS MT services.   For example, a daily or monthly usage limit has been set End User MSISDN is barred The end user should contact their network operator, to either remove the restrictions in place. The MSISDN may be blacklisted or not permit certain SMS based transactions End User The end user does not have short code messaging enabled on their account, or is using an MVNO service of an operator that does not support messaging The end user should contact their network operator to either enable the short code messaging.   Where the operator is a MVNO, the end user should confirm that their operator has no contractual restrictions in place with the backbone operator - i.e., The operator used by the MVNO to supply its products and services to end users. Customer ALL MT traffic using a specific service number with a specific US operator have returned DB05 The customer should supply the Campaign ID when submitting the MT to Digital Interconnect, when sending traffic to US based end users. Operator Rejected By operator due to the campaign not being active on the operator network Raise a single user issue (SUI) ticket to the Service Desk (SD), detailing the OrderID, MSISDN and date/time the MT message was sent, so that the SD team can investigate.   ... View more