SMPP Now SMS 2-WAY

SMPP Now SMS 2-WAY SearchSearch
Author Message
Anonymous
 
Posted on Wednesday, June 02, 2004 - 02:44 am:   

I have 1 GSM Modem, 2-WAY working as * and open url from my site. But 2-WAY working only reciving SMS from GSM modem aka SMSC. When I connect to Now SMS as SMPP client 2-WAY rules not working, all SMPP client query redirect to my GSM modem. How make next process: SMPP client connecting to Now SMS and transmit data, Now SMS checking 2-WAY rules and transmit result executing comand to SMSC?
Bryce Norwood - NowSMS Support
Board Administrator
Username: Bryce

Post Number: 2693
Registered: 10-2002
Posted on Friday, June 04, 2004 - 08:12 pm:   

Let me make sure that I understand your configuration, and your problem correctly.

You have 2 SMSC connections defined to NowSMS, a GSM modem and an SMPP connection.

When a message is received over either connection, it calls a 2-way command that you have configured.

The problem is that the reply to the 2-way command gets routed out the GSM modem, and you would like the reply to be routed via the SMSC from which the original message was received.

Is that an accurate description of your configuration, and the problem?

If so, then I have to ask, are your 2-way commands using the "redirect" technique to return responses, or are they just returning text responses?

Let me explain how NowSMS decides which SMSC connection to use for routing a message, and then I will explain some issues related to this that are specific to 2-way command handling.

When NowSMS routes a message, it first looks to see if a sender address has been specified for the message submission (normally there is not a sender address specified, unless you submitted the message via HTTP and specified a "Sender=" parameter). If a sender address was specified, then NowSMS checks to see if the sender address matches the "Default Sender Address" that is configured for any of the SMSC links (or the "Phone Number" associated with a GSM modem). If NowSMS finds a match, then it will route the message only via an SMSC connection with a matching sender address.

If NowSMS did not find a match on the sender address, then it evaluates the recipient address, and it will look to see if it finds a match in the "Preferred SMSC Connection for" recipient address masks associated with any of the SMSC connections. (These recipient address masks can be wildcards such as "+44*" to match any phone number that starts with "+44".) If NowSMS finds a match, then it looks for the longest mask that provides a match, and routes the message via the connection with the longest matching mask. (For example, if you were sending to +441624999999, and you had one connection with a mask of "+44*", and another with "+441624*", then the connection with the mask of "+441624*" would be used as it is a longer match than "+44*".)

If there is no match on the recipient address mask, then the message will be routed via any connection that has "Support any outbound message traffic" checked.

So how does all of this relate to your 2-way command responses?

In a standard 2-way command response, where the command returns response text, when NowSMS submits the reply, it puts the recipient of the message that NowSMS received in as the sender of the reply.

So if "9999" is the phone number of your GSM modem, and a message is received on the GSM modem, the 2-way command response is going to be submitted back into the NowSMS queue with "9999" as the sender. Assuming you have told NowSMS that the "Phone Number" of the modem is "9999", then the message reply will get routed back out through the same modem in which the original message was received.

The same approach applies to SMPP connections. NowSMS applies the original recipient address for the message that was received by NowSMS as the sender in the reply. In order for things to get routed properly, that address must be configured as the "Default Sender Address" in the configuration of the SMPP connection within NowSMS.

It does get trickier if you are using the "redirect" technique to return your responses. But in that case, the @@RECIP@@ parameter can be passed as a variable to your 2-way command. And the URL redirect that your 2-way command returns should include this value as the "Sender=" parameter in the message submission that is returned.

Sorry if this is a bit complex, but if I understood your question correctly, hopefully this will explain what you need to configure.

-bn