| Sending SMS - Invalid Optional Parameter Value |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through October 19, 2007 ⬆ |
◄ ► |
| Author | Message | |||||
| Umesh Singh New member Username: S_umesh00 Post Number: 4 Registered: 01-2006 |
My SMPP provider requires me to use some TLV parameters (source_port, source_subaddress, dest_subaddress) and I have gone through various NowSMS posts to configure those parameters but now when I send the message I am getting the error "Invalid Optional Parameter Value" } Here is the smpp section of smsgw.ini} file. [SMPP - 196.46.224.133:2008] DefaultSMPPOptions=source_port=49;source_subaddress=15;dest_subaddress=1 SMPPVersion=v3.4 UserName=xxx Password=xxx SenderAddressOverride=Yes Receive=No ReceiveMMS=No UseSSL=No LongSMSAlt=Yes [SMPPOptions] source_port=20A,Integer,2 source_subaddress=202,CString dest_subaddress=203,CString Here the TLV property values are source_port=49 source_subaddress=15 dest_subaddress=1 Error received: 16:50:33:062 [3] ThreadProcessModem: Error: ERROR: Invalid Optional Parameter Value My SMPP Provider says that for the source port parameter (channel id on their side), the length field is 2 octets (which is correct in the sms being sent) however, the value field must be 2 octets which is not correct as the NowSMS is sending 1 octet only. What could be wrong here? Please help me. I am running nowsms 2007 patched based on the thread http://support.nowsms.com/discus/messages/1/20328.html Here is the log from my SMPP provider: 05/04/07 12:27:15.81 2008 01 [Bind 0] Received 00000047,00000004,00000000,00000071, payload length 55 from bind (window -1) 05/04/07 12:27:15.81 2008 02 [Bind 0] 00000000:01013434:37393034:37303433:39350000:00000000:00000000:08746573 05/04/07 12:27:15.81 2008 02 [Bind 0] 74206D73:67020A00:01310202:00033135:00020300:023100 05/04/07 12:27:15.81 2008 00 [Bind 0] Submit SM received 05/04/07 12:27:15.81 2008 00 [Bind 0] Received Submit SM with ESM 0, GSM PID 0, Data Coding 0, length 8 05/04/07 12:27:15.81 2008 00 [Bind 0] Received 18 bytes of optional data 05/04/07 12:27:15.81 2008 00 [Bind 0] Remote Source Channel : '12546' 05/04/07 12:27:15.81 2008 00 [Bind 0] Warning : Couldn't map remote channel '12546' to local channel entry .
| |||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7040 Registered: 10-2002 |
Hi Umesh, I'm confused, because what I see in the log from the SMPP provider is different from what I see in our debug log. In our SMPPDEBUG.LOG, in the TLV section, I always see it start like this: 02 0A 00 02 00 31 02 0A is the tag for soure_port 00 02 is the length (2) 00 31 is the value (31 hex = 49 decimal) Yet, the log that they sent you includes this instead: 020A00:0131 This shows me a length of 1 instead of 2 ... and the same value, 31 (49 decimal) encoded in 1 byte instead of 2. I don't understand why this discrepancy exists. According to our logs, we are sending 2 octets, just like you think we should. I do not understand why the provider would see this differently. Unless maybe you originally did not have the ",2" after the source_port definition ... and the provider's logs are from an earlier period. My guess is that this is the case, and now they are having a problem with one of the subaddress parameters. As I read the SMPP specification, it seems there is a strange encoding for the source_subaddress and dest_subaddress parameter values. It seems to me that neither "15" or "1" would be a valid value ... but I don't understand how this parameter would be used, so it is not clear to me. Can you find confirm with your provider that the source_port value is now being encoded the way that they want ... and assuming this is the case, get them to explain exactly what they expect for the subaddress parameter values. I expect that we're going to have to add a new parameter type ... something like HexOctet, in order to signify a string of binary octets. But let's find out from your provider first, exactly what it is that they are expecting. -bn | |||||
| Umesh Singh New member Username: S_umesh00 Post Number: 5 Registered: 01-2006 |
Hi Bryce, Thanks for the quick reply. I really apologies for the incorrect logs as I changed it while testing. Now as per my provider the source_port parameter is sent correctly which is obvious from the log: == 05/04/07 19:01:28.62 2008 01 [Bind 0] Received 00000047,00000004,00000000,000000D7, payload length 55 from bind (window -1) 05/04/07 19:01:28.62 2008 02 [Bind 0] 00000000:01013434:37393034:37303433:39350000:00000000:00000000:07544553 05/04/07 19:01:28.62 2008 02 [Bind 0] 544D5347:020A0002:00310202:00033135:00020300:023100 05/04/07 19:01:28.62 2008 00 [Bind 0] Submit SM received 05/04/07 19:01:28.62 2008 00 [Bind 0] Received Submit SM with ESM 0, GSM PID 0, Data Coding 0, length 7 05/04/07 19:01:28.62 2008 00 [Bind 0] Received 19 bytes of optional data 05/04/07 19:01:28.62 2008 00 [Bind 0] Remote Source Channel : '49' 05/04/07 19:01:28.62 2008 00 [Bind 0] source_subaddress optional parameter doesn't start with 0xA0; rejecting message == It is also obvious from the log that the problem is now with source_subaddress field and you are very much correct that the strange encoding used for the source_subaddress and dest_subaddress is making it unusable. The SMPP 3.4 spec section 5.3.2.15 for the format of this field says that the first octet of the parameter value is a "Type of Subaddress", and needs to be set to 0xA0, as this is a "user specified" value. So somehow we need to pass this value starting with 0xA0. Again as per your thinking this will require an upgrade of NowSMS but my thinking is that instead of providing it as HexOctet NowSMS should take it as UserDefined and similar to source_port it should convert it to Hex form and prefix with 0xA0, What do you suggest? Regards | |||||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 7076 Registered: 10-2002 |
I'm hesitant to use an approach that is too specific to that particular parameter. That's why I was leaning toward this "HexString" option type, because I think it will offer flexibility that might be useful for other parameters. What you would do here is define the following: [SMPPOptions] source_port=20A,Integer,2 source_subaddress=202,HexString dest_subaddress=203,HexString [SMPP - 196.46.224.133:2008] DefaultSMPPOptions=source_port=49;source_subaddress=A03135;dest_subaddress=A031 For source_address, the HexString type means that the bytes A0 31 35 will be inserted for the value. (31 35 being the binary representation for the character string "15") Added support for this "HexString" option value type can be found in the patch that can be downloaded at http://www.nowsms.com/download/20070411.zip. -bn | |||||
SMSDEBUG.LOG
