Now SMS , SMPP router

Now SMS , SMPP router SearchSearch
Author Message
Rufat Sadiyev
New member
Username: Rufat

Post Number: 1
Registered: 05-2014
Posted on Thursday, May 29, 2014 - 05:52 am:   

Hello, i've faced with the problem during configuration of NOWSMS as SMPP router. The situation is following: I have 2 SMSC and to each i have successfully established connection. NowSMS is connected to both of them as SMPP client. I need to configure routing sms received from one of them to another one.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4913
Registered: 08-2008
Posted on Thursday, May 29, 2014 - 02:38 pm:   

Hi Rufat,

Are there only ever going to be these 2 SMSC connections, or is there potential for more?

Is the only message routing rule that any message received from one of the connections should be routed to the other connection?

If the answer to both of those questions is yes, then a simple edit to the SMSGW.INI will achieve the configuration.

In that file, there will be a configuration section for each SMSC connection, with a header like this [SMPP - server:port]. Each section should have a RouteName= attribute .... let's assume these route names are SMPP1 and SMPP2.

Under the section header for the section that contains RouteName=SMPP1, add ReRouteReceived=SMPP2.

Under the section header for the section that contains RouteName=SMPP2, add ReRouteReceived=SMPP1.

Any messages received from one will be routed to the other.

In this configuration, be aware that delivery reports will not work properly. The reason for this is not specific to NowSMS, but a limitation of SMPP when messages are transmitted in a direction of SMSC -> ESME.

There is a lengthy explanation of this issue here:

http://www.nowsms.com/sms-hubbing-considerations

To properly handle delivery receipts, the other SMSCs need to use data_sm instead of deliver_sm, or add an additional connection to your system, so that messages they submit to you follow an ESMME -> SMSC path to preserve SMPP message_id tracking.

If the answer to one of your questions above is No, then it gets more complicated. Instead of ReRouteReceived=SMPP2, it becomes a generic ReRouteReceived=Yes (or "Re-Route Received Messages for Outbound Delivery" in the Advanced settings). Rules must then be established for how which messages are routed to which connection...either based on recipient prefix routing, or accounting callbacks.

--
Des
NowSMS Support
Rufus
New member
Username: Rufat

Post Number: 2
Registered: 05-2014
Posted on Tuesday, June 03, 2014 - 01:31 pm:   

Hi Des. Thanks for provided information and promt support. I could successfully configure routing.
Rufus
New member
Username: Rufat

Post Number: 3
Registered: 05-2014
Posted on Monday, July 14, 2014 - 07:43 am:   

Hi Des, in order to properly handle delivery receipts i have used data_sm. But Now SMS doesn't pass this package to previous SMSC. Can you provide more detailed information regarding it.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4950
Registered: 08-2008
Posted on Thursday, July 17, 2014 - 07:23 pm:   

Hi Rufus,

Sorry for the delay in response.

This can be very difficult to troubleshoot, because it is difficult to determine where the message-id chain breaks down, or if the delivery receipts are even arriving properly from the SMSC connection.

To fully understand this, it is probably necessary to capture an SMPP packet trace to follow the message flow. (The NowSMS SMPPDEBUG.LOG can also be used, but it is harder to interpret because it just logs a hex dump of the packets. We can use this if you are unable to use Wireshark. SMPPDEBUG.LOG is enabled when SMSDEBUG.LOG is enabled.)

We'd want to see a trace that shows a message being sent (with delivery report requested), and any delivery report coming back.

If you do not wish to post the traces here, you can send them via email to nowsms@nowsms.com with Attention: Des in the subject line of the message. Please post a reply here if you send the trace via email, so that I can look for it if it is not immediately posted too my attention.

--
Des
NowSMS Support
Rufus
New member
Username: Rufat

Post Number: 4
Registered: 05-2014
Posted on Thursday, July 24, 2014 - 07:09 am:   

Hi Des, I have replied you via email. Waiting for your comments.
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4957
Registered: 08-2008
Posted on Thursday, July 24, 2014 - 07:31 pm:   

Hi Rufat,

It looks like the problem is that no message ID is returned in the data_sm_resp.

If you look at the response, it is a 17 byte response, 16 bytes header, then a single null byte (empty string) for the message ID.

A lack of knowledge of the upstream message ID prevents the ability to track delivery receipts.

In situations like this, when the partner cannot return message ID in data_sm_resp, the only alternative is to configure two connections to each partner SMSC. One connection is initiated by you, where you are in the ESME role, and the partner is the SMSC. The other connection is initiated by the partner, where you are in the SMSC role, and the partner is the ESME. This way submit_sm is always used to send messages, where there is a better chance that message IDs will be reported correctly.

--
Des
NowSMS Support
Rufus
New member
Username: Rufat

Post Number: 5
Registered: 05-2014
Posted on Friday, August 01, 2014 - 10:57 am:   

Hi Des,

As i understood null byte for the message ID issue must be fixed on NowSMS side? Isn't it?


Regarding your suggest (only alternative is to configure two connections to each partner SMSC) - both our SMSC act as server, they have no way to establish connection as client.

Is there any other to fix report problem?
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 4966
Registered: 08-2008
Posted on Friday, August 01, 2014 - 02:24 pm:   

Hi Rufat,


quote:

As i understood null byte for the message ID issue must be fixed on NowSMS side? Isn't it?




No. (Unless there is a very old version of NowSMS being used by the partner.)

If you look at the traces, data_sm is being used to transfer a message to the SMSC. The SMSC returns a data_sm_resp, acknowledging that it has accepted the message. However, the message_id field in this response is blank (null). This means that NowSMS has no idea what message id has been assigned by the upstream SMSC. (Unfortunately, with SMPP, a new message ID is assigned on each hop.) Any eventual delivery report will reference a message id. But NowSMS will not be able to match this delivery report to the message because it has no knowledge of the message ID.

The delivery report can be forwarded back to the other SMSC, but the other SMSC will not understand this message ID either, so it will not know how to process it.

In the direction of ESME -> SMSC, submit_sm is used to transfer a message, and submit_sm_resp should always contain a message ID.

In the direction, SMSC -> ESME, deliver_sm is used to transfer a message. The deliver_sm_resp format does not allow a message ID to be returned. For situations like yours, this is why you would configure NowSMS to use data_sm instead...because data_sm_resp includes a message ID parameter. Your traces show data_sm being used, and the data_sm_resp returning a null/blank message ID.

NowSMS is not generating that data_sm_resp, that is coming from your partners system. There is nothing we can fix on the NowSMS side. If the partner does not tell us what message ID they have assigned to the message, then we will not be able to understand the message ID values in the delivery report and we cannot route them properly or convert the message ID back to the original value.

In situations like this, when the partner cannot return message ID in data_sm_resp, the only alternative is to configure two connections to each partner SMSC. One connection is initiated by you, where you are in the ESME role, and the partner is the SMSC. The other connection is initiated by the partner, where you are in the SMSC role, and the partner is the ESME. This way submit_sm is always used to send messages, where there is a better chance that message IDs will be reported correctly.


quote:

Regarding your suggest (only alternative is to configure two connections to each partner SMSC) - both our SMSC act as server, they have no way to establish connection as client.

Is there any other to fix report problem?




Unfortunately, if their system cannot provide the message ID, the only solution is to disable delivery reports.

However, I need to understand your configuration better.

NowSMS is the client for both SMSC connections, correct? In other words, in NowSMS, there are two connections in the SMSC list, correct? You are not using "SMS Users" at all for the SMSC connections, correct?

To disable delivery reports, edit SMSGW.INI, and under each [SMPP - server:port] header, add DisableDeliveryReceipt+Yes

This setting clears the flag that requests delivery reports, so the upstream SMSC will not generate them.

Alternatively, I have one idea. What if NowSMS does not use data_sm? NowSMS would use submit_sm, and submit_sm_resp from the partner should contain a valid message ID. The partner system would need to use data_sm to talk to NowSMS, and understand the message ID in the data_sm_resp...and I am not confident that it would.

Unfortunately, when dealing with some systems, sometimes the only alternative is to turn off delivery reports.

--
Des
NowSMS Support
Rufus
New member
Username: Rufat

Post Number: 6
Registered: 05-2014
Posted on Monday, August 25, 2014 - 11:13 am:   

Hi Des, is there any standard for Data_SM packet which should be sent to SME from SMSC? Should SMSID be sent to SME in Text Body?
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 5009
Registered: 08-2008
Posted on Monday, August 25, 2014 - 05:24 pm:   

Hi Rufat,

The SMS message ID is returned in the data_sm_resp. The entity that posts the message uses, data_sm, and the entity that accepts the message acknowledges acceptance with data_sm_resp.


For more details, see http://www.nowsms.com/smpp-3-4-protocol-specification-archive ... SMPP 3.4 Spec, section 4.7.2.

--
Des
NowSMS Support