Extended parameters for accounting callbacks

Extended parameters for accounting callbacks SearchSearch
Author Message
ashot shahbazian
Frequent Contributor
Username: Animatele

Post Number: 53
Registered: 06-2004
Posted on Friday, October 07, 2005 - 12:00 am:   

Hi Bryce!

We're building a software solution that would help to monitor repeating messages off a single user account, for SPAM control purposes.

It seems that the system could be integrated with NowSMS via its accounting callback mechanism if, in addition to the destination number and username, it would also post the user's IP address, Sender ID, message text/data string and DCS.

Another necessary feature would be to enable different types of pre-determined SMPP errors depending on the system's decision to accept or deny the message. Our SMPP connector handles it differently for each of the 3 scenarios:

1. If the repeating message was previously "whitelisted" it returns an sm_resp to the user normally, just as it does for non-repeating messages.

2. If the repeating message was "blacklisted" previously, the sm_resp would be returned with "invalid service type" or "invalid destination address."

3. If the message was neither white or black listed previously, it appears on the operator's screen, and while the operator's thinking what to do with it returns "throttling error" (alternatively, it does not return anything and lets the message time out.) We're now testing it with different SMPP platforms/providers to see how their systems react in each case.

If NowSMS can be made to handle the responses according to the input it gets from an external app, with support of additional parameters for callbacks it can be easily integrated with any anti-spam or traffic monitoring solution.

Is it feasible to add support for this?

SMS spam is a major problem, as every week it makes dozens of networks block other carriers from sending SMS to their subscribers. As a result, the cost of texting is continuing to rise and in many countries it's just ridiculous to text anyone ourside of home network.


BR
Ashot
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 5095
Registered: 10-2002
Posted on Friday, October 07, 2005 - 10:00 pm:   

Hi Ashot,

What you're saying makes a lot of sense (as usual).

And some of the suggestions fit in with changes that we have made in the accounting callbacks in the MMSC. But there is more that is feasible in this type of callback for SMS because the amount of data is less, so it is feasible to pass the entire message content to the callback.

As I look at it, I don't see any reason that the callback couldn't be extended to include the sender id, recipient id, the text/data, and DCS. And we could parse the HTTP response for an SMPP return code value, so you could have flexibility to return different error codes.

It's probably not that difficult to do this. But those are famous last words. I'll see if we can look into this next week.

-bn
ashot shahbazian
Frequent Contributor
Username: Animatele

Post Number: 54
Registered: 06-2004
Posted on Saturday, October 08, 2005 - 12:47 am:   

Hi Bryce!

I'm really glad that my suggestions fit in! As I look back I realise that my input's triggered some cool features. One of the recent changes, for proper routing of DR-s when connected via parallel binds with the same login is absolutely unique.

One thing I would stress is the importance of passing the user's IP address in the callback. The IP address is harder to manipulate for the abuser than the user ID, as anyone can possibly register a bunch of accounts and send spam using different accounts in sequense. With the IP in callback, the system can be fine-tuned to look for both the IP and the User ID when checking for repeating messages.

BR,
Ashot
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 5109
Registered: 10-2002
Posted on Tuesday, October 11, 2005 - 05:36 pm:   

Hi Ashot,

Here's what we're planning to do:

Update SMS accounting callbacks (including PreAuth) to include additional information about the message. Additional parameters are:

“&SubmitIP=” (IP address of submitting client)
“&Sender=” (sender address of SMS message)
“&Binary=” (set to 1 if message is binary)
“&PID=” (Protocol ID), “&DCS=” (data coding scheme value)
“&UDH=” (user data header)
“&Data=” (hex string with message data for binary messages)
“&Text=” (UTF-8 text of message).

The “PreAuth” can also now return a specific SMPP error code to be returned to a submitting SMPP client (previously, if PreAuth=Deny” was returned in the response, the SMPP error code ESME_RTHROTTLED was always returned). To return an error, the HTTP response to the PreAuth accounting callback should include the text, SMPPErrorCode=#### or SMPPErrorCode=0x####, where #### is the SMPP error code to be returned. (If the “0x” prefix is present, the error code is assumed to be in hex format, otherwise it is assumed to be in decimal.)

I'm not sure yet when we'll be able to make this available. Hopefully this week or next.

-bn
ashot shahbazian
Frequent Contributor
Username: Animatele

Post Number: 55
Registered: 06-2004
Posted on Tuesday, October 11, 2005 - 07:10 pm:   

Hi Bryce!

Sounds just right!

Can each individual message be pre-authorised in this fashion?

BR
Ashot
Anonymous
 
Posted on Thursday, October 13, 2005 - 02:59 pm:   

Hi Bryce!

I think you also should include "&To=" parameter into "PreAuth" callback. It might be helpful in implementing black list and setting up specific routing rules. Sender won't be charged if his message doesn't meet restrictions.

BR
Alex K.
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 5116
Registered: 10-2002
Posted on Thursday, October 13, 2005 - 04:25 pm:   

Hi Alex and Ashot,

Thanks for mentioning the "&To=" parameter. I can confirm that it will also be present.

I forgot to mention it in the list above because currently it is defined for the "PreAuth" callback, but currently in most cases, it is not actually presented. I only listed the new parameters above, but this one has also been "fixed", so that it will be present.

The callback does occur for each individual message. For SMPP client connections, it is pretty straight-forward. For web client connections, it can be a bit more confusing. (It is more confusing because we allow multiple recipient submissions via that interface, and because a web submission might result in a segmented message being sent out. The callback there will have a "&To=" parameter with a comma delimited list of recipients if necessary. If the message is going to be sent segmented, then you will know this by the "&MsgCount=" parameter which will reflect the total number of messages ... recipients*segments ... that are requested.)

-bn
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 5134
Registered: 10-2002
Posted on Friday, October 14, 2005 - 06:37 pm:   

Ok, the update with this enhanced preAuth callback support has been uploaded to http://www.nowsms.com/download/latestpatch.zip.