@ appended to long message text | Search |
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through June 21, 2007 ⬆ |
◄ ► |
Author | Message | |||
Dynmark New member Username: Dynmark Post Number: 1 Registered: 03-2007 |
We have been experiencing problems sending long sms messages whereby the @ symbol is added to the end of the message. Trying this through your web interface is fine with the 'Message Class' set to 'Default', however setting this to 'Class 1' that we are using in our software replicates the issue. The message is as follows (386 characters): cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccX Also what is the 'Message Class' setting 'Default' equal to when set from your interface? Cheers. | |||
Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7014 Registered: 10-2002 |
Hmm... As I recall, this type of issue is caused by an ambiguous length field when an SMPP SMSC uses 7-bit encoding. The ambiguity causes a problem for some SMSCs with messages of particular lengths ending with some characters. We have some logic that actually appends a space in such situations to resolve the ambiguity. However, it appears that logic is only triggered when the data_coding value is 0 ... not for other values (such as when message class is 1) which would also use 7-bit encoding based upon the SMSC configuration setting. We've updated the SMPP driver to apply this same logic for any data_coding values that would use 7-bit. I've uploaded a ZIP with an updated SMSSMPP.DLL to http://www.nowsms.com/download/smpp20070328.zip. If you're running a 2007 release of NowSMS, you should only need this updated DLL. If you're running a 2006 release, or you want to update to the latest version first ... the latest patch for NowSMS 2006/2007 can be downloaded from http://www.nowsms.com/download/20070316.zip. If you apply that patch, update the SMSSMPP.DLL file after applying that patch, as the patch will install an older version. -bn | |||
Dynmark New member Username: Dynmark Post Number: 2 Registered: 03-2007 |
Thanks for your quick response. We have installed the above dll onto a test machine that had version v2007.02.14 of NowSMS and ran some tests. Sending short messages appears fine, however sending the long message (above) leaves 2 .req files in the Q that are not being sent. Heres the contents of one of them. [SMS] SubmitUser=XXX SubmittedBy=10.0.2.11 Sender=www ReceiptRequested=Yes Validity=1D0H0M Data=6639DA783C1E8FC7E3F1783C1E8FC7E3F1783C1E8FC7E3F1783C1E8FC7E3F1783C1E8FC7E3F 1783C1E8FC7E3F1783C1E8FC7E3F1783C1E8FC7E3F1783C1E8FC7E3F1783C1E8FC7E3F1783C1E8FC 7E3F1783C1E8FC7E3F1783C1E8FC7E3F1783C1E8FC7E3F1783C1E8FC7E3F1783C1E8FC7E3F1783C1 E8FC7E3F1783C1E8FC7E3F1783C1E8FC7 UDH=050003C80301 pid=00 dcs=11 Binary=1 PhoneNumber=447968XXXXXX [ErrorDetail] RetryCount=3 LastRetryTime=20070328140010 LOG: 13:59:36:593 [41] ThreadProcessConnection: Processing request /?User=XXX&Password=XXX&ReceiptRequested=Yes&Sender=www&PhoneNumber=447968XXXXXX &DCS=11&Text=394cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccX& Validity=1D0H0M 13:59:36:609 [41] Debug: 1 recipient entries 13:59:36:656 [41] ThreadProcessConnection: Request processing complete 13:59:37:156 [4] ThreadProcessModem: Processing SAR-447968XXXXXX-c8-3-2.req... 13:59:37:171 [4] SMPPSubmitAsyncQ: Depth 1 13:59:37:171 [4] ThreadProcessModem: Processing SAR-447968XXXXXX-c8-3-3.req... 13:59:37:171 [4] SMPPSubmitAsyncQ: Depth 2 13:59:37:265 [33] CheckSmppSubmitAsyncQ: SAR-447968XXXXXX-c8-3-2 13:59:37:265 [33] SMPPSubmitAsyncQ: Depth 1 13:59:37:265 [33] ThreadProcessModem: Error: ERROR: Invalid Optional Parameter Value 13:59:37:296 [33] CheckSmppSubmitAsyncQ: SAR-447968XXXXXX-c8-3-3 13:59:37:296 [33] SMPPSubmitAsyncQ: Depth 0 13:59:38:296 [4] ThreadProcessModem: Processing SAR-447968XXXXXX-c8-3-1.req... 13:59:38:296 [4] SMPPSubmitAsyncQ: Depth 1 13:59:38:296 [4] ThreadProcessModem: Processing SAR-447968XXXXXX-c8-3-2.req... 13:59:38:312 [4] SMPPSubmitAsyncQ: Depth 2 13:59:38:390 [33] CheckSmppSubmitAsyncQ: SAR-447968XXXXXX-c8-3-1 13:59:38:390 [33] SMPPSubmitAsyncQ: Depth 1 13:59:38:390 [33] ThreadProcessModem: Error: ERROR: Invalid Optional Parameter Value 13:59:38:406 [33] CheckSmppSubmitAsyncQ: SAR-447968XXXXXX-c8-3-2 13:59:38:406 [33] SMPPSubmitAsyncQ: Depth 0 13:59:38:406 [33] ThreadProcessModem: Error: ERROR: Invalid Optional Parameter Value 13:59:39:406 [4] ThreadProcessModem: Processing SAR-447968XXXXXX-c8-3-1.req... 13:59:39:406 [4] SMPPSubmitAsyncQ: Depth 1 13:59:39:500 [33] CheckSmppSubmitAsyncQ: SAR-447968XXXXXX-c8-3-1 13:59:39:500 [33] SMPPSubmitAsyncQ: Depth 0 13:59:39:500 [33] ThreadProcessModem: Error: ERROR: Invalid Optional Parameter Value 13:59:42:156 [5] SMPPReceiveMessageCallback: inbound message: sender=447968XXXXXX, recip=www, pid=0, dcs=0, msgFlags=C, udh=, msg=id:SAR-447968XXXXXX-c8-3-3 sub:001 dlvrd:001 submit date:0703281359 done date:0703281359 stat:DELIVRD err:000, extraParms=RouteToLocalUser=XXX 13:59:42:625 [14] ThreadProcessInboundSMS: Processing 000227C2.in... 13:59:42:625 [14] GetProgramToExecute: http://Web01.test/somewhere/Inbound/Receive.ashx?sender=@@SENDER@@&smsprefix=@@SMSPREFIX@@&fullsms=@@FULLSMS@@&recip=@@RECIP@@&messageid =@@MESSAGEID@@&receiptmessageid=@@RECEIPTMESSAGEID@@&servicetype=@@SERVICETYPE@@ &smscroute=@@SMSCROUTE@@&msgdate=@@MSGDATE@@&msgtime=@@MSGTIME@@&binary=@@BINARY @@&udh=@@UDH@@&pid=@@PID@@&dcs=@@DCS@@ 13:59:42:625 [14] GetProgramToExecute: http://Web01.test/somewhere/Inbound/Receive.ashx?sender=447968XXXXXX&smsprefix=i d:SAR-447968XXXXXX-c8-3-3&fullsms=id:SAR-447968XXXXXX-c8-3-3%20sub:001%20dlvrd:0 01%20submit%20date:0703281359%20done%20date:0703281359%20stat:DELIVRD%20err:000& recip=www&messageid=000227C2.in&receiptmessageid=SAR-447968XXXXXX-c8-3-3.req&ser vicetype=&smscroute=SMPP-Vodafone&msgdate=20070328&msgtime=135942&binary=0&udh=& pid=00&dcs=00 13:59:42:625 [14] ThreadProcessInboundSMS: Executing http://Web01.test/somewhere/Inbound/Receive.ashx?sender=447968XXXXXX&smsprefix=i d:SAR-447968XXXXXX-c8-3-3&fullsms=id:SAR-447968XXXXXX-c8-3-3%20sub:001%20dlvrd:0 01%20submit%20date:0703281359%20done%20date:0703281359%20stat:DELIVRD%20err:000& recip=www&messageid=000227C2.in&receiptmessageid=SAR-447968XXXXXX-c8-3-3.req&ser vicetype=&smscroute=SMPP-Vodafone&msgdate=20070328&msgtime=135942&binary=0&udh=& pid=00&dcs=00 13:59:42:625 [14] RetrieveURL: Retrieving http://Web01.test/somewhere/Inbound/Receive.ashx?sender=447968XXXXXX&smsprefix=i d:SAR-447968XXXXXX-c8-3-3&fullsms=id:SAR-447968XXXXXX-c8-3-3%20sub:001%20dlvrd:0 01%20submit%20date:0703281359%20done%20date:0703281359%20stat:DELIVRD%20err:000& recip=www&messageid=000227C2.in&receiptmessageid=SAR-447968XXXXXX-c8-3-3.req&ser vicetype=&smscroute=SMPP-Vodafone&msgdate=20070328&msgtime=135942&binary=0&udh=& pid=00&dcs=00 13:59:42:625 [14] RetrieveURL: Looking up Web01.test 13:59:42:640 [14] RetrieveURL: Retrieving somewhere/Inbound/Receive.ashx?sender=447968XXXXXX&smsprefix=id:SAR-447968XXXXXX -c8-3-3&fullsms=id:SAR-447968XXXXXX-c8-3-3%20sub:001%20dlvrd:001%20submit%20date :0703281359%20done%20date:0703281359%20stat:DELIVRD%20err:000&recip=www&messagei d=000227C2.in&receiptmessageid=SAR-447968XXXXXX-c8-3-3.req&servicetype=&smscrout e=SMPP-Vodafone&msgdate=20070328&msgtime=135942&binary=0&udh=&pid=00&dcs=00 13:59:42:640 [14] RetrieveURL: GET /somewhere/Inbound/Receive.ashx?sender=447968XXXXXX&smsprefix=id:SAR-447968XXXXX X-c8-3-3&fullsms=id:SAR-447968XXXXXX-c8-3-3%20sub:001%20dlvrd:001%20submit%20dat e:0703281359%20done%20date:0703281359%20stat:DELIVRD%20err:000&recip=www&message id=000227C2.in&receiptmessageid=SAR-447968XXXXXX-c8-3-3.req&servicetype=&smscrou te=SMPP-Vodafone&msgdate=20070328&msgtime=135942&binary=0&udh=&pid=00&dcs=00 HTTP/1.1 User-Agent: Now SMS/MMS Gateway v2007.02.14 Accept: */* Host: Web01.test Cheers. | |||
Dynmark New member Username: Dynmark Post Number: 3 Registered: 03-2007 |
Update to above, we didn't have the option 'Encode long messages with 7-bit' set. We now get the message to the phone, but it still has the @. Cheers. | |||
Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7018 Registered: 10-2002 |
Enable the SMPPDEBUG.log (enable the SMSDEBUG.LOG and it will enable this log). Send the message twice ... once normal, and once with message class = 1 ... then post back the SMPPDEBUG.LOG so that I can see the differences. | |||
Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7019 Registered: 10-2002 |
Wait. I think we found an issue. The URL from before has been refreshed with a new version: http://www.nowsms.com/download/smpp20070328.zip | |||
Dynmark New member Username: Dynmark Post Number: 4 Registered: 03-2007 |
I've given the new version a try and it no longer shows the @ symbol. It does appear to be putting a space before the last character though? e.g. ccccc X Cheers. | |||
Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7020 Registered: 10-2002 |
This has me puzzled. We are definitely appending a space when this encoding option is used, because the length is ambiguous in certain situations. (The space only gets appended in ambiguous situations where it does not increase the byte count of the encoded message.) But it is appended to the end. I can't see any scenario that would insert it one character before the end. What if you add a space to the end of your test message. Does this get received properly? If it does, then I would like to see an SMPPDEBUG.LOG that shows the 2 test messages being submitted ... maybe there is some other encoding option that I am not thinking of that would be causing a conflict. -bn |