| Using NowSMS as SMPP2HTTP API |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through September 15, 2006 ⬆ |
◄ ► |
| Author | Message | ||||
| Maikel Lambregts New member Username: Silverstreet Post Number: 1 Registered: 05-2006 |
Forwarding SMPP login details to HTTP SMSC connection The thing I want to accomplish is to use NowSMS as the SMPP server between our customers and our own HTTP platform.Our customers now only connect to us using HTTP and we send back the delivery reports to a callback-url on their server. More of our customers however want to connect to us through SMPP. We plan to use NowSMS for that. It would be most convenient if we could just add our HTTP platform as one SMSC connection to NowSMS and that NowSMS will use the username/password that the SMPP customer binds with in the @@USERNAME@@ en @@PASSWORD@@ field. Is this possible or should we add every seperate HTTP account as a seperate SMSC connection? Supplying SMPP accounts with delivery reports Our HTTP platform accepts a unique messageid parameter, which will be send back to the callback-url together with a STATUS parameter. Does NowSMS support the use of such a parameter (@@MESSAGEID@@)? And to what NowSMS address/port should our HTTP platform send back the delivery reports and in with what parameter names and values? Does NowSMS remember internally what MessageID belongs to what SMPP bind? And then forward the received delivery report to the correct SMPP bind? | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5868 Registered: 10-2002 |
Hi Maikel, Those are interesting questions/configuration ideas. For the first one, there is currently no support for passing the original SMPP client username/password to an upstream HTTP SMSC. I don't see why we couldn't add those parameters ... adding the submit username would be very easy. Adding the submit password would be a little more complex, and would add some processing overhead. I'm going to give those issues some more thought. But as it stands today, it would require an HTTP SMSC definition for each account. On the second issue, there is support for this in NowSMS 2006. Unfortunately, right now there is only support for routing the receipts back to the submitting client ... there is not support for routing other received messages. However, I've just discussed this with one of my colleagues, and we will add a parameter to facilitate this other use in the next update. Let me describe how you can route back the receipts. It works a little different than what you describe. We don't pass a message id parameter to the HTTP SMSC. But we can parse the HTTP response that comes back to look for an SMSC assigned message id. It is then possible for a subsequent HTTP transaction from the SMSC to signal a delivery receipt (or failure) for that message id. Under the SMSGW.INI section that defines the HTTP SMSC connection, you need to add TrackHTTPReceipts=Yes. You also need to define MessageIDResponsePrefix=xxxxxx setting, where "xxxxxx" is some text for NowSMS to look for in the HTTP SMSC response. It is expected that the message id is the first non-blank text following this text string. The id is assumed terminated by a space, line break, period (.), comma (,) or semi-colon (;). For the SMSC to send back a receipt, it connects back to the NowSMS web interface in the same way as a user account would. It needs to include a username and password in the request (User= and Password= parameters). It must include a Phone= parameter to indicate who should receive the receipt (original sender). Then it should include ReceiptMessageId= to indicate the message id (should match what was returned in the HTTP response), and either ReceiptDelivered=Yes or ReceiptFailed=Yes to indicate the receipt type. NowSMS will look up the message id, and route an SMPP format receipt to the appropriate submitter account (and although you must include a Phone= parameter in the request, NowSMS will remember the original sender and recipient and insert them into the receipt as appropriate). -bn | ||||
| Maikel Lambregts New member Username: Silverstreet Post Number: 2 Registered: 05-2006 |
Hi Bryce, So for every customer that wants to connect to us through SMPP we need to add a "SMS User" account and a seperate "HTTP SMSC Connection". How can we tell NowSMS that all messages from SMS User X need to be forwarded to SMSC connection X? Any idea when you will support the possibility to put SMPP username/password into the @@USERNAME@@ and @@PASSWORD@@ parameters, so that we can use them in the HTTP SMSC Connection... To make our HTTP delivery reports work with NowSMS we indeed need to adapt some things, but that would not be a problem. Besides "ReceiptDelivered=Yes" (DELIVERED) and "ReceiptFailed=Yes" (NOT DELIVERED) our HTTP system also supplies reports like BUFFERED. How can we forward these to our SMPP clients? I don't fully understand the use of the "Phone" parameter. Isn't the "ReceiptMessageId" parameter already enough to tell NowSMS to what SMPP user he needs to forward the reports? Is the below URL correct for forwarding the reports from our HTTP platform to NowSMS? http://ip:8800?username=&password=&phone=&receiptmessageid=&receiptdelivered=yes does it matter what username/password we use? Should these be the same username/password from the SMS user to which the report belongs? | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5876 Registered: 10-2002 |
Hi Maikel, It gets messy configuring the multiple SMSC connections. To bind a particular user account to a particular SMSC connection, you need to use the AllowedUserOnly settings in the SMSGW.INI file. That's why I'd rather see some @@ parameters. We're still reviewing it, but it doesn't look like it should take very long. Give me a few more days to review it.
We don't have any support for interim/in-transit/buffered statuses in this interface. I know that we do support them in the SMPP side (for SMPP to SMPP), but there is not any support for them in this interface. I can investigate this more, but I'm not optimistic.
Agreed, it doesn't make any sense. But when I tried it before replying to your message, I found that the HTTP interface required this parameter ... even if it was subsequently overridden.
Yes, the URL is correct, just be sure to include non-blank values (and change "username" to just "user"). The user/password field can be any value, I'd suggest defining an account in the "SMS Users" list just for the SMSC. Similar to the "Phone=" issue, the HTTP interface does some parameter validation. -bn | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5879 Registered: 10-2002 |
Maikel, You might want to hold off any testing in this area for a week or so. I've been reviewing this with some of my colleagues and we're going to make some adjustments. Key changes that we're currently planning: 1.) Don't require the "Phone" parameter when "ReceiptMessageId" parameter is present. 2.) Support passing the NowSMS message ID to the HTTP SMSC, and allow this message ID to be used in the "ReceiptMessageID" parameter. (We will continue to also support the current approach where we parse the message ID assigned by the HTTP SMSC from the HTTP response, and allow this ID to be used in the "ReceiptMessageID" parameter.) 3.) Support @@SubmitUser@@ and @@SubmitPassword@@ replacement parameters in the HTTP SMSC URL templates to indentify the username and password of the original submitting user. 4.) Support for a @@ReceiptRequested@@ parameter in the HTTP SMSC URL template. This parameter will be set to Yes if the user requested a receipt, or No if no receipt is requested. 5.) Still under investigation ... support for the "buffered" (in-transit) receipt. -bn | ||||
| Maikel Lambregts New member Username: Silverstreet Post Number: 3 Registered: 05-2006 |
This is very good news :-) My next concern however has to do with capacity (sms/sec). Let's say we install NowSMS on a powerfull W2K3 server (DualXeon, 15.000 SCSI and lots of RAM). With what speed are SMPP clients able to supply sms to NowSMS and even more important with what speed is NowSMS able to forward these sms to our HTTP. This is an optimized php script running on Apache supporting persistent connections. I think that NowSMS should at least support quite some simultaneous HTTP requests to our server to reach interesting capacities. Is NowSMS capable of doing this? What about the speed of receiving the delivery reports from our platform and forwarding these into the SMPP binds? Is this speed limited by licensing btw? Your thoughts please :-) | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5890 Registered: 10-2002 |
Currently, there is not support for persistent connections. We're going to relook at that though, as we've gradually been adding persistent connection support in various other places within the software. Multiple simultaneous HTTP requests is not a problem. But you do need to define your SMSC connection multiple times. There is not a problem doing this, other than the fact that you have to repeat the same configuration information multiple times. We did just remove this multiple definition limitation in the MMS MM7 interface, which has similar issues ... and I suspect we could do the same here very easily. Let me add these issues to the list of items to investigate. The only licensing speed limit here is the speed at which messages are routed to the HTTP SMSC. (And there is an optional speed limit that you can impose on individual SMPP accounts to limit how fast they are allowed to submit messages to you.) | ||||
| Maikel Lambregts New member Username: Silverstreet Post Number: 4 Registered: 05-2006 |
Ok, so the amount of times we define our HTTP SMSC is equal to the amount of simultaneous connections. How do we tell NowSMS that it should load balance the traffic from all SMPP accounts equally over the defined HTTP SMSC's. Is it possible to dedicate one or more HTTP SMSC's to a single SMPP account, etc... | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5905 Registered: 10-2002 |
Yes.
For each of the definitions have the same configuration settings, it will happen automatically.
The AllowedUser/AllowedUserOnly settings in the SMSGW.INI can do this. (You can find information on them here: http://support.nowsms.com/discus/messages/1/5972.html) We've made progress on the changes that I detailed above. The changes have been implemented (the 1-5 list above), but still have to go through testing along with some other additional changes. I should have more news later this week. -bn | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5912 Registered: 10-2002 |
Maikel, I've uploaded an update to better handle your configuration needs. http://www.nowsms.com/download/maikel.zip Changes: 1.) The "Phone" parameter is not required when "ReceiptMessageId" parameter is present. 2.) The NowSMS message ID can be passed to the HTTP SMSC, allowing this message ID to be used in the "ReceiptMessageID" parameter. If TrackHttpReceipts=Yes, and the new @@MessageID@@ replacement parameter is present in the URL template, then it is assumed that this ID will be presented in the "ReceiptMessageID" parameter. 3.) @@SubmitUser@@ and @@SubmitPassword@@ replacement parameters are supported in the HTTP SMSC URL templates to indentify the username and password of the original submitting user. 4.) @@ReceiptRequested@@ parameter is supported in the HTTP SMSC URL template. This parameter will be set to Yes if the user requested a receipt, or No if no receipt is requested. 5.) Support for buffered/in-transit receipt status. When "ReceiptMessageId" parameter is present, valid status values include "ReceiptDelivered=Yes", "ReceiptIntransit=Yes" or "ReceiptFailed=Yes". 6.) A configuration parameter when defining an HTTP SMSC connection allows you to specify the maximum number of concurrent connections allowed. 7.) Experimental: Under the [HTTP - x.x.x.x:xxx] section header, it is possible to add a setting: UseKeepAlive=Yes If this setting is present, NowSMS will attempt to use keep-alive connections to the SMSC. (Test this with your SMSC connection before relying on it. We don't yet support keep-alive sockets on our HTTP server interface for the SMS gateway, so we couldn't put this setting through a heavy stress test.) -bn | ||||
| Maikel Lambregts New member Username: Silverstreet Post Number: 5 Registered: 05-2006 |
Hi Bryce, I installed the new application and I'm testing the sending of messages and I have the following questions/feedback: I noticed you introduced the "ThreadCount" parameter. Is it correct that by giving this a value of e.g. 2 the system behaves exactly the same as when I would specify the same HTTP SMSC twice? So it is not necessary anymore to specify multiple HTTP SMSC's? Not all supported GSMchars are arriving correctly on my phone. I added an attachment to explain this better. It has nothing to do with the communication from SMPP client to NowSMS, but with the communication from NowSMS to our HTTP SMSC. When I send concatenated 7-bit sms the parts are connected allright but we get the text as a HEX string on our phone. Our HTTP SMSC however needs the TEXT as normal 7-bit + concatenated UDH like 050003010201 How will NowSMS forward Unicode sms to our HTTP SMSC? We have a BODYTYPE=4 for this purpose and we then expect the Unicode data as a HEX string. Below are the 2 URL templates we have now: /send.php?USERNAME=@@SubmitUser@@&PASSWORD=@@SubmitPassword@@&DESTINATION=@@PHONENUMBER@@&BODYTYPE=1&BODY=@@TEXT@@&SENDER=@@SENDER@@&REFERENCE=@@MESSAGEID@@&DELIVERY=1 /send.php?USERNAME=@@SubmitUser@@&PASSWORD=@@SubmitPassword@@&DESTINATION=@@PHONENUMBER@@&BODYTYPE=3&BODY=@@DATA@@&SENDER=@@SENDER@@&REFERENCE=@@MESSAGEID@@&DELIVERY=1&UDH=@@UDH@@ *DELIVERY=1 will be changed to DELIVERY=@@RECEIPTREQUESTED@@ when we also accept Yes/No besides 1/0 What's the use of @@SERVICETYPE@@ (I read this in the manual). What values can it have and what are their meaning?
| ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 5923 Registered: 10-2002 |
Hi Maikel,
Correct.
By default, we send in UTF-8 format. Those are the characters you are seeing. If you want to use a different character set (maybe you are expecting iso-8859-1), then you can add Charset=iso-8859-1 under the [HTTP - server:port] section header.
We've had a couple of other people asking us for the same thing. I'll see what we can do about that, but it probably won't be until next week.
It sends it using the binary template. The only clue that it is is Unicode is the @@DCS@@ parameter would be 8. (I've often wondered if we should have a separate Unicode template, but so far this has been sufficient.)
It's an SMPP parameter, and it can take on any text string value assigned by the client. We pass this through because some services use it to convey extra information about the message. -bn | ||||
| Maikel Lambregts New member Username: Silverstreet Post Number: 6 Registered: 05-2006 |
Any updates on this? | ||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6061 Registered: 10-2002 |
Sorry Maikel, I've fallen way behind on the discussion board here. There is an update that has a configuration option to submit long text or EMS messages to an HTTP SMSC using text format with UDH, instead of converting the text to 7-bit GSM binary format. This update is not ready for general release yet, as there are still some other changes pending, but if you send an e-mail to nowsms@now.co.uk with "Attention: Bryce" in the subject line, referencing this issue, then we can send you a ZIP file with the interim update. -bn | ||||
char issues
