| Re routing SMS to a mobile using 2-way |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through December 14, 2010 ⬆ |
◄ ► |
| Author | Message | |||
| Support New member Username: Zynetix Post Number: 1 Registered: 11-2010 |
I have SMPP connection from our SMSC to NowSMS and I can recieve the SMS on NowSMS. I want to route this SMS back to another mobile within the same SMSC. I believe this is possible through 2-Way. I am using the settings as below: SMS Command Prefix ='*' Recieve Phone Number = 15224466 Command to Execute = ? (My requirement is to further send the recieved full SMS automatically to 77889900 number within the same SMSC.) kindly share the 'Command to Execute' syntax to make it work? Kindly note that this is only a test setup. Moreover, what will be the option for Character Set? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2647 Registered: 08-2008 |
Hi, The solution is probably more complex than it should be ... but as you note, this is a somewhat unusual test configuration. What you need to do is configure a 2-way command that submits the message back into NowSMS. Because it is going to resubmit a message, an account needs to be defined under "SMS Users" to allow the submission. Substitute that user account name and password in the command to execute URL below: http://127.0.0.1:8800/?user=username&password=password&sender=@@SENDER@@&phonenu mber=@@RECIP@@&text=@@FULLSMS@@ Use UTF-8 as the 2-way character set. Make sure that: SMS Command Prefix =* (no quotes, just the * character) If you want to copy the message to 77889900, change phonenumber=@@RECIP@@ to phonenumber=@@RECIP@@,77889900 ... so that the message goes to both numbers. -- Des NowSMS Support | |||
| Support New member Username: Zynetix Post Number: 2 Registered: 11-2010 |
Thanks for this reply. Actually i could route small SMS(less than 160 characters) using these settings. I have a question for Long SMS, will there be any different handling by NowSMS for the Long SMS routing(SMS more than 160 characters)? In case of Long SMS, what is the format of the 'User Data' and 'User Data Header' that is expected by nowSMS when it receives them from the SMSC? Also if text is GSM 7-bit encoded, how does nowSMS find the length of the encoded text? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2651 Registered: 08-2008 |
NowSMS reassembles a long message before it routes it to a 2-way command, so the long message will be reassembled, and then split back up by NowSMS after it is resubmitted. If you want to support binary messages, add the following to the URL string above: &UDH=@@UDH@@&DCS=@@DCS@@&PID=@@PID@@&binary=@@BINARY@@ (Note: NowSMS will ignore the binary= parameter, and will auto-detect the format based upon the text and udh parameters. However, you need to have @@BINARY@@ in the URL in order to get the 2-way command to route binary messages to the command.) -- Des NowSMS Support | |||
| Support New member Username: Zynetix Post Number: 3 Registered: 11-2010 |
We are sending a long message from our test SMSC to nowSMS. In turn the nowSMS has been set-up to relay that message back to the test SMSC. There are 2 parts of a long message and we expect that the byte-streams(GSM 7-bit encoded by SMSC) going into nowSMS should be the same as the ones coming out of it. But nowSMS is sending a completely different encoded stream instead. FYI, we are using wireshark/tcpdump to monitor the bytestreams. Byte-streams of the User Data (part 1 of SMS) as shown below. SMSC to nowSMS [a8 e8 f4 1c 94 9e 83 e8 e8 32 88 5e 9e d3 41 f4] .........2.^..A. [37 c8 5e 96 a7 cd 79 10 1d 1d a6 83 d8 6f f7 19 7] .^...y......o.. [34 6f cf 41 e1 31 bd 1e 66 b3 f3 20 f2 bb 3c 07 4] o.A.1..f.. ..<. [dd df f2 b5 0b 44 45 a7 e7 a0 7b 9a cd 06 85 d9] .....DE...{..... [f3 37 88 5e 9e d3 41 74 74 98 0e a2 a3 cb a0 79] .7.^..Att......y [7e 4e 2f b7 41 e9 39 c8 fd a6 83 c4 f2 f7 ba ec] ~N/.A.9......... [06 85 cd f4 b2 1c 94 6e c3 d9 e5 76 d9 4d 4f bb] .......n...v.MO. [cf 20 3a ba 0c 62 bf dd 67 d0 bc 3d 07 99 cb 61] . :..b..g..=...a [7a 5d 5e 06 a5 dd] z]^... nowSMS to SMSC [54 68 69 73 20 69 73 20 74 68 65 20 74 65 73 74] This is the test [20 74 6f 20 76 65 72 69 66 79 20 74 68 61 74 20] to verify that [6c 6f 6e 67 20 73 6d 73 20 61 63 74 75 61 6c 6c] long sms actuall [79 20 64 6f 65 73 20 77 6f 72 6b 2e 20 54 68 69 ] y does work. Thi [73 20 77 69 6c 6c 20 61 6c 73 6f 20 74 65 73 74 ] s will also test [20 74 68 61 74 20 74 68 65 20 73 79 73 74 65 6d] that the system [20 69 73 20 6e 6f 74 20 62 72 6f 6b 65 6e 20 61] is not broken a [66 74 65 72 20 69 6d 70 6c 65 6d 65 6e 74 69 6e ] fter implementin [67 20 74 68 65 20 6c 6f 6e 67 20 73 6d 73 20 66 ] g the long sms f [65 61 74 75 72 65 20 69 6e] eature in Also please see the nowSMS logs below that give the impression that the message has been encoded correctly by our test SMSC as it appears correctly. SMS-IN log >>>> 2010-11-18 11:49:54,2204,SMPP - 10.128.225.164:2775,UDH=050003350201;Text="This is the test to verify that long sms actually does work. This will also test that the system is not broken after implementing the long sms feature in";Recip=152255 2010-11-18 11:49:57,2204,SMPP - 10.128.225.164:2775,UDH=050003350202;Text=" new sw. Hope this works now. This is taking to long to fix. If you dont fix it now...then you will be fired.";Recip=152255 SMS-OUT log >>>> 2010-11-18 11:50:03,SAR-152255-4cd4ffe4-2-1.req,127.0.0.1,152255,OK -- SMPP - 10.128.225.164:2775,Sender=2204;SMSCMsgId=15;UDH=050003EA0201;Text="This is the test to verify that long sms actually does work. This will also test that the system is not broken after implementing the long sms feature in" 2010-11-18 11:50:04,SAR-152255-4cd4ffe4-2-2.req,127.0.0.1,152255,OK -- SMPP - 10.128.225.164:2775,Sender=2204;SMSCMsgId=16;UDH=050003EA0202;Text=" new sw. Hope this works now. This is taking to long to fix. If you dont fix it now...then you will be fired." | |||
| Support New member Username: Zynetix Post Number: 4 Registered: 11-2010 |
Sorry for not asking the question clearly above. I would like to know why the bytestream that is sent out of nowSMS is different from the one it received though they represent the same text and possibly the same 7-bit data encoding scheme. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 2655 Registered: 08-2008 |
Keep in mind that the technique that you are using involves SMPP being converted back to HTTP, then back to SMPP. It is not going to be encoded exactly the same way. That said ... different SMPP systems have different encoding idiosyncrasies, because the SMPP specification was not detailed enough, so different vendors made different choices on how to interpret things. This is particularly true with regard to long message encoding. The encoding differences that I believe you are referring to are configured under "Advanced Settings" for the SMPP connection in the SMSC list. Specifically, the setting titled "Encode long text messages with 7-bit packed encoding". Some SMSCs expect text to be packed into 7-bit packed encoding when UDH (such as segmentation or port addressing) is present in a message. Most SMSCs expect standard 8-bit encoding for text whether or not UDH is present. Which setting you choose depends on which one works with your SMSC. The most common setting is the default, but if your SMSC expects 7-bit encoding, configure that here. There is also an option to use SMPP TLV parameters instead of UDH, as that is what some other SMSC expect. | |||
