Sinch Community

Question Why are OrderIDs not always unique?   Answer OrderIDs generated by Digital Interconnect are reset periodically once they reach a certain level, therefore, OrderIDs will not always be unique.   If you want to use the OrderID as a unique key in your system, it is recommended that you use both the OrderID combined with the date/timestamp. ... View more

When the connection to an operator’s SMSC is not available, alerts are generated from the Digital Interconnect Enterprise Services NOC: If the connection is used for Push traffic, the connection is then “turned off” which automatically re-routes incoming traffic to backup routes. If the connection is used for RS traffic, it is not turned off as backup routes typically do not exist for premium traffic. ... View more

The MSISDNs in your subscriber lists are constantly changing. Subscribers change numbers, subscribers switch mobile operators and other events occur that impact the accuracy of your lists. Operators and industry groups have mandated that content provides maintain up-to-date subscriber lists.   The Universal Deactivation Manager (UDM) service provides you with an aggregate view of changed or deactivated subscriber MSISDNs on a daily basis. The UDM service combines deactivation feeds from mobile operators and combines them into country specific files for use as you update and manage your subscriber lists.   Read the Universal Deactivation Manager User Guide attached below for more information about the UDM service: ... View more

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