SMS Outgoing Messages
From Triangle Wiki
IntroductionMT (Mobile Terminated) messages are any messages that are sent to a customer's handset or indeed pushed into the outgoing API by a client. The Outgoing API allows a client to push messages through the SMS system, using POST / XML over HTTP: any derivative of message you want can be transmitted through the system. APIThe Outgoing API script is located at [Outgoing API] simply POST the variables and values or send a urlencoded XML string wrapped in the variable XMLDATA to the address. You must supply the server IP address to Triangle to secure the transaction to the server. XML Over HTTP APIThe following parameters are required:
<?xml version="1.0"?> <Notification> <AccountID>2</AccountID> <KeywordID>186</KeywordID> <Message>This is an MT message.</Message> <MessageType>SMS</MessageType> <SenderType>Alpha</SenderType> <SenderID>The_Sender</SenderID> <CLI>447900000000</CLI> <Network>23410</Network> <SubAccount>ATest</SubAccount> <Note>A test note</Note> <Watershed>1234567890</Watershed> </Notification> POST pages/sms_center/api/sms_send.php HTTP/1.1 Host: xml1.triangle-solutions.com User-Agent: Mozilla/4.0 Content-Length: 27 Content-Type: application/x-www-form-urlencoded user=[USERNAME]&pass=[PASSWORD]&XMLDATA=[urlencoded(XML)] POST Over HTTP APIIn this case the client needs to send an HTTP POST string into the outgoing API script for processing.
POST pages/sms_center/api/sms_send.php HTTP/1.1 Host: xml1.triangle-solutions.com User-Agent: Mozilla/4.0 Content-Length: 27 Content-Type: application/x-www-form-urlencoded user=[USERNAME]&pass=[PASSWORD]&AccountID=[ACCOUNTID]& KeywordID=[KEYWORDID]&Message=[MESSAGE]&MessageType=[MESSAGETYPE]& SenderType=[SENDERTYPE]&SenderID=[SENDERID]&CLI=[CLI]&Network=[NETWORK]& SubAccount=[SUBACCOUNT]&Note=[NOTE]&Watershed=[WATERSHED] Elements
On a successful post the script will return the TransactionID this is then utilised later on to pair up delivery reports within your system. Message Validation ProcessEach message sent through the system will be fully validated on a number of specific elements that may cause it to fail at the gateway or network level. These are listed below. Sender Type And NameThe system will check the sender type and name combination. For instance choosing a short code sender type will only allow the name to be numeric and no longer that 15 characters. Work is in progress to tie in the sender types with the accounts also. For instance sending through a premium account will limit the sender type to short code only. Failure at this level will halt the entire send. De-duplicationThe system looks through the posted numbers and removes any duplicates sends, this is a silent operation. The system reports duplicates that are removed, but does not log them or the report. Automatic Number FixingThe system will attempt to repair the CLI by firstly removing all white space. Checking that the number is at least 10 digits long, if the number begins with a 0 it will replace this with the selected country code. Any numbers not conforming are logged as BADNUMBER. Client Defined BlacklistEach client can place any MSISDN number into a blacklist against any one of the allocated gateway accounts, or define a generic 'Type' these being either Bulk, Premium or ALL. This will effectively ban that number from receiving messages from that account / type. This is useful if the customer has opted out of marketing messages but still wishes to receive premium services. A blacklisted number is logged as BLACKLISTED in any send in which it is encountered. Clients are asked to prune there lists to remove these from future sends to speed up the system and reporting. Notes
Sender Type Explained
Lower case 'a' to 'z', upper case 'A' to 'Z', digits '0' to '9'. Subscribers are unable to reply to 'Alpha' originators. Text ReplacementThe system allows some smart replacement of elements to achieve some dynamic content. Placing the elements within the messages will result in the following replacements.
Character Encoding Certain characters are illegal within the contents of XML elements, as they cause confusion when the XML is parsed. These are ", ', <, >, and &. There are two methods which may be used by the Client to transmit these characters safely. Illegal characters - Replace with
Or the use of CDATA can be used <Message><![CDATA[This contains illegal chars "<>'&]]></Message> |
