| Regarding Class 0,1,2 issue |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through May 20, 2013 ⬆ |
◄ ► |
| Author | Message | |||
| Johnny New member Username: Johny Post Number: 38 Registered: 02-2009 |
Hi I use NOW SMS v2012.11.16 In the text message tab, when I select a default message type, sms is received But when I select class0,1,2 message length is wrong i attach the log captuer files and SMSGW.INI files please check and answer to me Thanks <SMSGW.INI> [SMSGW] Modem1=SMPP - 203.xxx.xxx.xx:xxxx WebAuth=No WebMenu=Yes WebPort=8800 ReceiveSMS=No ReceiveMMS=No Debug=Yes ReceiveSMSCharset=utf-8 ConfigurationUpdateTriggerRestart=20111107161457 SeparateUserQueues=Yes AlertEMailSender=xxxxxxxx11.com AlertEMailQueueSize=50 AlertEMailSMTPUser=xxxxxx@xxx.com AlertEMailSMTPPass=xxxx PHPEnable=No PHPAllowRemote=No AlertEMailSMTPServer=xxx.xxxx.com AlertEMailSMTPPort=25 AlertEMailRecip=xxx@xxx.com AlertEMailSendInfo=No [Inbound SMS Routing] [SMPP - 203.xxx.xxx.xx:xxxx] GSMPackLongSMSWithMessageClass=Yes SMPPVersion=v3.4 UserName=Nxxxx Password=Exxxx SenderAddressOverride=Yes Receive=No ReceiveMMS=No UseSSL=No LongSMSAlt=Yes KeepAlive=58 SenderAddress=+821029991115    | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4351 Registered: 08-2008 |
Hi Johnny, I don't know enough (or any details whatsoever) about what data you are sending. (standard text, binary data, Unicode text?) I also don't know what length field you are complaining about (194 is long for an SMS, so I'm guessing SMPP packet length rather than message length). It would help to see the message details of what is being submitted, and something like a Wireshark trace of the data comparing a message with no class information to one that includes class information. The only difference between a message with class information and one without is a single byte difference in the data_coding value. That said, I am confused as to your use of the GSMPackLongSMSWithMessageClass=Yes setting which would be an override to use 7-bit encoding for long messages with class information when 8-bit encoding is otherwise enabled for long messages. Are these long messages that you are having problems with? If so, why are you using this setting to encode long messages with class information using 7-bit encoding? If your problems are with long text messages, that setting is suspicious to me. -- Des NowSMS Support | |||
| Johnny New member Username: Johny Post Number: 39 Registered: 02-2009 |
Hi My test method is as follow Long text message is ok. when I 1page message(160 alphabet characters) is sent, problem is occured. I don't set the encode long meesage with 7-bit. Message Class: Default Text: 160 alphabet characters(GSM 7bit) Log Length : 174 (correct length) Receive status: received Message Class: Class0 Text: 160 alphabet characters(GSM 7bit) Log Length : 194 (wrong length) Receive status: received Message Class: Class1 Text: 160 alphabet characters(GSM 7bit) Log Length : 194 (wrong length) Receive status: received Message Class: Class2 Text: 160 alphabet characters(GSM 7bit) Log Length : 194 (wrong length) Receive status: not received Please one more check . Thanks set deafult class  set class 2   | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4360 Registered: 08-2008 |
I'm sorry, but I still have no idea what length you are referring to. Those reports about message length are coming from some other software that I am not familiar with. Please familiarise yourself with a good TCP/IP capture utilty, such as Wireshark (www.wireshark.org). I configured an SMPP connection with settings similar to yours and used Wireshark to capture and decode the SMPP traffic. As you will see in the following screen captures, both length fields (SMPP packet length and message length) are identical whether the message is sent default (no message class) or class 2. I encourage you to confirm this for yourself on your own system.   I do not doubt that you are experiencing a problem. I'm just disagreeing with your assessment that the length parameter is set incorrectly. My suspicion is that your SMSC does not support standard text encoding when a message class is specified. The SMSC might expected 7-bit packed encoding (raw SMS) in this scenario, or it may be hopelessly confused. You can test this by enabling the "Encode text messages with 7-bit packed encoding" setting. My guess is that this might cause problems for no class messages, but allow messages with message class to work. If this is the case, and the SMSC cannot be fixed to work consistently, we can investigate adding an option to force 7-bit encoding only when a message class is specified. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4371 Registered: 08-2008 |
Hi Johnny, A follow-up .... Assuming that my suspicion is correct, and your SMSC expects 7-bit packed encoding (raw SMS) when a message class is specified, we have an update that enables this behaviour. The update is at http://www.nowsms.com/download/nowsms20130401x.zip The new setting is: * SMPP: Work-around for SMPP SMSC behaviour where SMSC expects 8-bit text encoding under normal circumstances, but expects 7-bit packed encoding if text is sent in a message that specifies an SMS message class. To enable the use of 7-bit packed encoding when messages include SMS message class, edit SMSGW.INI, and under the [SMPP - host:port] section of the file, add GSMPackWithMessageClass=Yes. -- Des NowSMS Support | |||
