| WDP Adaptation and RerouteReceived |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through September 26, 2009 ⬆ |
◄ ► |
| Author | Message | |||
| ashot shahbazian New member Username: Animatele Post Number: 3 Registered: 06-2004 |
Hi Des, There seems to be an issue preventing a proper message reassembly when submitting it to a CDMA-like SMSC which expects to receive a long message unsegmented: A segmented message is originally received as deliver_sm off an outbind (reverse) connection, i.e. that from our ESME to the source operator SME and the RerouteReceived=DestOpLinkName is used to reverse the message flow. The SMSC definition for the DestOp has "Use WDP Adaptation" checked, which under normal circumstances (that is without reversing the message flow) makes NowSMS to reassemble the segmented message and send it upstream in one piece. In our case however the message gets submitted in segments, as if the RerouteReceived command applies individually to segments before NowSMS had a chance to reassemble it. Could you recreate the scenario and patch it? Would it be a temporary workaround if we tried to loop the message once in NowSMS before trying to reassemble and submit it, e.g. make the first outbind connection to a user account created on NowSMS server itself and only then route it to the DestOp uplink configured to perform reassembly, by means of an AllowedUser=xx command? Many thanks, Ashot Shahbazian Animatele Inc. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 787 Registered: 08-2008 |
Hi Ashot, This is a bit of a difficult scenario for me to recreate ... however I think I understand. I *think* the problem is that when the message is rerouted, the queue filename is a normal hexid.REQ instead of SAR-blah-blah.REQ. I believe this is what prevents the message from being reassembled. Does this match your observation? If so, then I think the loop that you describe would work. If a client submits the message into NowSMS, it is going to queue it in the SAR-blahblah.REQ format. That could be enough to allow you to temporarily work around this. Resolving it in NowSMS may be a little more involved. Before I pursue this matter with engineering, let me know if what you observe matches my expectation, and whether or not the loop works as a temporary work-around. -- Des NowSMS Support | |||
| ashot shahbazian New member Username: Animatele Post Number: 5 Registered: 06-2004 |
Hi Des, Thanks for a quick reply! You are right about the ID-s, but something else is wrong, here's the message: 2009-05-13 16:02:48,4A0C2649.req,,+14042293930,OK -- SMPP - dsahm:7777,Sender=+91916100570;SMSCMsgId=SAR-+14042293930-d4-2-1;Binary=1;UDH=05 00034C0201;Data=A8E5F35B4DBFB7CF6D90BA7DA783D46DBA1AA46EC3E9E1731B446FABC36E7A9B 7E87ABCFE1F619D40ED3EF6A103DDC3ED3C3207A5BDD06D1DBE7F019446F9FE96710BDAD3E83E8ED 301D446F9FD5207A3B0CA2B7C367FA19446F8BE967509BAE0E9FEF70BA1A446FABCF207AFBAC06D1 DB74751B446F9F41F4F6594D07D1DB6A10BD0DA2B7D5 2009-05-13 16:02:48,4A0C264C.req,,+14042293930,OK -- SMPP - dsahm:7777,Sender=+91916100570;SMSCMsgId=7226BA39;Binary=1;UDH=0500034C0202;Data =C2207AFB0C5283E86D7518446FABC371 The SME upstream is in fact another NowSMS server. As you can see: 1. The queue .req-s (those that go after the timestamp) are indeed in hex ID format. 2. What makes it look bad is the fact that the NowSMS server upstream assigns the first segment a proper SAR ID, but the second segment gets a conventional ID, SMSCMsgId=7226BA39. Despite the fact that the UDH seems to indicate it's the second segment of the same 2-part message. Could this also have to do with the "wrong" format of ID-s in the originally received message? If so, the fix with the loop won't work, since after the first loop we'd get a proper "SAR" .req filename for the first segment only. Any ideas? The reason we reassemble the message is that we need to modify the text (and then break it apart again) before sending it on. Don't ask me why, it's a whole other subject. Kind regards, Ashot | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 790 Registered: 08-2008 |
Hi Ashot, Unfortunately, this has me very confused. I can see how the ReRouteReceived= setting is not properly flagging the message as a segmented message. I think it does not matter whether or not the message is originally received unsegmented, or received already segmented. NowSMS does not seem to be applying the SAR- message IDs. That can be fixed. (Probably not until the end of next week.) But I'm not clear on how the other scenario could happen. It is particularly strange that one segment would be flagged, but not another. If you have any further observations on this, it would be helpful. In the meantime, I'm going to discuss the issue with the ReRouteReceived not flagging these segments correctly with engineering and see about getting that part fixed. -- Des NowSMS Support | |||
| ashot shahbazian New member Username: Animatele Post Number: 7 Registered: 06-2004 |
Indeed strange. Further investigation reveals that in flow reverse scenario segments would only flag differently if "WDP Adaptation" is checked on the uplink. If unchecked, they are properly identified as separate segments. So the temporary workaround is to create a loop through the server itself, first uplink in the loop without WDP Adaptation and the second with it. The situation is particular to a Hubbing scenario. Since there are also messages flowing in the opposite direction we're trying to check if those would loop, what if they're segmented etc. etc. Better to have this patched of course, please let me know when done. Note that this is easy to re-create. If you're outside of the U.S. you may use a modem and text a segmented message to it - in the modem def section of the ini file insert reroutereceived=xxx. If you are in the U.S. the messages typically get screwed by Verisign who do the hubbing for U.S. networks - such as they may truncate or corrupt the UDH, or change the encoding for no reason. With AT&T the chances it'd work are better, if you use an AT&T handset to text to an AT&T modem. Kind regards, Ashot | |||
| ashot shahbazian New member Username: Animatele Post Number: 8 Registered: 06-2004 |
Hi Des, We've updated the server where we've observed the problem to v.2009.05.21 (that has fixed spurous problems with some DLR.) The issue with reassembling the message with WDP Adaptation checked still remains, we've now tested it reversing concatenated messages sent to a modem: 2009-05-23 22:01:23,4A1CB4EC.req,,+420723721781,OK -- SMPP - dsahm:7777,Sender=+79037222222;SMSCMsgId=72AEF3FB;UDH=050003280202;Text="t test 123" 2009-05-23 22:01:28,4A1CB4F6.req,,+420723721781,OK -- SMPP - dsahm:7777,Sender=+79037222222;SMSCMsgId=SAR-+420723721781-9c-2-1;UDH=0500032802 01;Text="test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test tes" As you can see the second segment was assigned a non-"SAR" message ID by the NowSMS server upstream. The same text submitted over the same uplink but without reversing the flow (from an "SMS User" account) was assigned proper "SAR"-type ID-s and reassembled (seen as being assigned by just one ID by the server upstream  2009-05-23 22:24:15,SAR-+420723721781-4a1cb9ca-2-1.req,127.0.0.1,+420723721781,OK -- SMPP - dsahm:7777,SubmitUser=ashot;Sender=7777777777;SMSCMsgId=SAR-+420723721781-b5-2-1 ;Text="test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test test 123" 2009-05-23 22:24:15,SAR-+420723721781-4A1CB9CA-2-2.req,127.0.0.1,+420723721781,OK -- SMPP - dsahm:7777,SubmitUser=ashot;Sender=7777777777;Text="test test test t" It'd be great if you could patch it, as this is delaying a launch of an interesting project. We couldn't manage it by trying to loop the messages, as we've run into difficulties routing messages flowing in the opposite direction (replies) through the loop. When do you think this might be fixed? Kind regards, Ashot | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 849 Registered: 08-2008 |
Hi Ashot, We're a bit puzzled by the above situation where the first segment gets the "SAR" ID assigned, but the second segment does not. In our testing, it should be all or nothing. If "ReRouteReceived=xxxxx" is set, then we can see that this id is definitely not getting assigned. However, we haven't had any luck finding any other scenarios in which it doesn't get assigned. We've patched this situation, but I'm concerned that there still may be something that we're missing. The update can be downloaded from http://www.nowsms.com/download/ashot.zip. -- Des NowSMS Support | |||
| ashot shahbazian New member Username: Animatele Post Number: 9 Registered: 06-2004 |
Hi Des, We've not seen this with any other scenario either, so if the patch works it should be fine to include it in the next release. After all, you don't retrieve reversed concats and flip/reassemble them that often. We could be the only ones ever noticing it.. I'll advise how it worked when we'd have tested it. There is an important feature that seems to be either missing or we couldn't figure how to activate, I'll post details in a separate thread. Kind regards, Ashot | |||
| ashot shahbazian New member Username: Animatele Post Number: 11 Registered: 06-2004 |
Tested extensively, works great! Kind regards, Ashot | |||
| Peter Yeh New member Username: No_animatele Post Number: 1 Registered: 09-2009 |
Hi Des, I strongly suggest you not to use Animatele as your SMS provider. I had bad experience them. Before I paid the money, they go their way to help. Once I started the live traffic and followed their policy to send traffic, then they blamed me for loosing a connection to an operator. It makes Animatele pretty much useless. The worst part is that it won't refund the money as it promised before I paid. So, go find another provider, don't bother with Animatele. | |||
| ashot shahbazian New member Username: Animatele Post Number: 46 Registered: 06-2004 |
Peter, This is out of context, but I'd still reply. The refund policy was clearly stated in the T&C. The T&C also states that spamming would lead to a fine of 500 credits per message. We've not enforced it despite your traffic caused 2 blockings and a complaint from Chunghwa Telecom. Moreover, we've let you use up rhe remaining credits for traffic to other destinations. Insisting on a refund after causing loss of connectivity and revenue is not fair by any means, especially in view of clearly stated policy. Given that you've taken this to a public forum I'll initiate an internal discussion to have your service terminated. We would also pursue legal action in Taiwan to recover the fine. The trouble caused to CHT is well documented. Ashot | |||
