Sinch Community

Question What information do I need to provide when raising a support ticket to the Digital Interconnect Service Desk?   Answer If you are unable to find the solution for your issue by searching the Enterprise Knowledgebase or by using the Report Manager tool, then there are several key pieces of information, which must be gathered before you raise a ticket with the Service Desk and any investigation can take place.   The table below provides examples of the key information, required for any given investigation for most incident types:   Information element Element breakdown Element summary MSISDN An internationally formatted phone number which may be prefixed with a '+’ The MSISDN should be an international phone number format which includes a country code, an area code and a subscriber number without any local exchange access codes A good example would be +447912345678, where +44 is the Country Code ORDERID The unique system-generated identifier for the message This will be returned to the customer server once the MT has been correctly received and acknowledged Details of the issue experienced Logs Log excerpt showing the nature of the issue experienced Error Messages Error response and return codes Where connectivity issues are being raised TCPDump (where a ‘.PCAP’ file is produced, which can be opened using the network tools available) Traceroute Telnet Ping Originating IP Address and Port Destination IP Address and Port VPN Issues VPN Tunnel details, IP address and port, with destination IP and Port details, and the IP and Port details which SMS 365, enterprise service, should see. Time-stamps The Time-stamp detailing when the issue occurred with time-zone details     A completed example support template is shown below:   Support Template Support Template Question Response Order ID 1234567890 MSISDN +447912345678 What is the issue? Customer received delayed alert What is the timestamp when the customer is trying to do a transaction? 01/09/2013 09:21:05 AM GMT What is the timestamp when the issue occurs? 01/09/2013 09:21:05 AM GMT Has the customer received messages successfully before? Yes Is the customer roaming? <NA> Which operator is he roamed to? <NA> Which handset is the end-user is using? <NA> It is important to ensure that you check the Enterprise Knowledgebase and that you carry out some investigations using theReport Manager tool to check your MSISDN(s), before raising a ticket with the Service Desk. ... View more

4503 is a SMS 365, enterprise service status code indicating there is no operator found for the current MSISDN.   Reasons for a 4503 response   The reasons why the 4503 status code is returned, and the actions which should be taken, are described below:   Category Description Action Customer The end user’s MSISDN is not mapped to an Operator. The customer should contact the end-user to confirm that they are using a correct MSISDN and that the number is a valid full international format mobile number, for example, +91234657890.   ... View more

The CTIA Short Code Monitoring Handbook describes best practices for SMS, multimedia messaging service (MMS), and free-to-end-user (FTEU) short code programs with the primary goal of providing the best customer experience for end users. ... View more

The Digital Interconnect platform, load-balances the processing of notifications across multiple notification servers, as a result of which, the Mobile acknowledgements may arrive on a customer's application before SMSC acknowledgements.   Therefore, Digital Interconnect cannot guarantee the sequential delivery of SMSC acknowledgements before Mobile acknowledgements. ... View more

If you see the message status Failed message delivery (DB62) then this message may be for an Indian MSISDN, which has been affected by the Indian TRAI Regulations.  Note: DB62 is an SMS 365, enterprise service status code. Phone users in India are now allowed to specify which categories of messages are blocked or received. Therefore, in order to ensure your customers are receiving the required SMS, ensure the correct nature/category of each of your customer accounts is reviewed or registered.  ... View more

The Telecom Regulatory Authority of India (TRAI) issued a new regulation on the SMS industry in India, which went into effect on September 27, 2011.   These regulations are designed to significantly curb the sending of unsolicited commercial communications to consumers through enhanced enforcement of the National Do Not Call (NDNC) list, now renamed the National Customer Preference Registry (NCPR).   Due to the new regulation: 1 All messages sent by Digital Interconnect will be considered as Promotional Messages, except the following (which are considered as Transactional):  Information pertaining to the account of its customer sent to the customer by a licensee or Bank or financial institution or insurance company or credit card company or depositories registered with Securities and Exchange Board of India or Direct to Home Operators  Information given by Airlines or Indian Railways or its authorised agencies to its passengers regarding travel schedules, ticket booking and reservation  Information from a registered educational institution to its students or their parents or guardians  Any message transmitted by or on the directions of the Central Government or State Government, TRAI or any agency authorized by TRAI, or on the directions of bodies established under the Constitution. 2 For Promotional Messages, a configurable sender identifier (TPOA) will no longer be supported and all sender identifiers will be converted to a 5 or 6 digit shortcode assigned to Digital Interconnect by the Operators. Note: The TPOA identifies whom the message is from. The TPOA will be assigned automatically. For any queries, please contact your Account Manager. 3 For Transactional Messages, note that TPOA will be restricted to six alpha characters.   Further Reference The following links containing additional information have been provided for your reference:    The Telecom Commercial Communications Customer Preference Regulations, 2010: http://nccptrai.gov.in/nccpregistry/regulation1diccndiv.pdf    Amendments for the new regulations: http://nccptrai.gov.in/nccpregistry/AmendmentToRegulations.jsp    Telecom Commercial Communications Customer Preference Portal Search for Customers: http://www.nccptrai.gov.in/nccpregistry/search.misc    FAQ’s by TRAI: http://nccptrai.gov.in/nccpregistry/FAQs.pdf. ... View more

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