| Possible SMPP Encoding Issue |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through November 14, 2013 ⬆ |
◄ ► |
| Author | Message | |||
| Tim Williams New member Username: Timw Post Number: 39 Registered: 09-2010 |
Hi, We appear to have come across an issue where the content of some Delivery reports doesnt appear visible when NowSMS receives them. This is what we see in the SMSIN: Text="id:50EEF5C3 sub:001 dlvrd:001 submit date:1307241313 done date:1307241313 stat:ACKED err:003 text: " which does match, but in a captured trace of the Deliver_sm: Optional parameter: 0x1560 (0x1560): 3233343135 Are these passed through to NowSMS at all? Regards Tim | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4605 Registered: 08-2008 |
Hi Tim, I'm sorry, but I don't understand what you are asking. Are you saying that the optional parameter 0x1560 is present when received from the provider, but is not then delivered to the SMPP client? Optional parameters are only routed if they are defined in SMPPOptions. Are you using that functionality? -- Des NowSMS Support | |||
| Tim Williams New member Username: Timw Post Number: 40 Registered: 09-2010 |
Hi Des, I haven't defined any, I will have a look and report back shortly. | |||
| Tim Williams New member Username: Timw Post Number: 41 Registered: 09-2010 |
Hi Des, Sorry, I hadn't used the SMPPOptions before, I received this info: Please note that the value can be found under the optional parameter. If you expand the optional parameters, it will show you the tag 1560, which is for the value. This is where your application should parse and and not in the message text. Would the following be ok for example? [SMPPOptions] mblox_operator=1560,String,6 Is this information passed to the accounting callback for SMSIN (Delivery Report)? Regards Tim | |||
| Tim Williams New member Username: Timw Post Number: 42 Registered: 09-2010 |
Hi Des, Instead of creating a new thread I also have another question - is there anyway to tell how many parts the SMS will be from the accounting callback, or would I have to check the length of the message to calculate this? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4607 Registered: 08-2008 |
Hi Tim, Yes, that would be correct, depending on the parameter encoding. If you can supply a raw SMPP packet, or just a Wireshark decode of that parameter as received, I can explain the appropriate options. The basic format is: [SMPPOptions] parametername=####,Type,Len #### is the parameter tag number in hex. Type specifies the parameter type: Integer, String, CString or HexString. Len is optional, but is usually required for Integer to specify a 1 or 2 byte value. String is not null-terminated, CString is null terminated. HexString treats the value as binary data and converts it to a string of hex characters for HTTP (and back to binary for SMPP). Len can be used for String or HexString to force a length (truncate or pad with nulls). In your case, I'd suggest not using Len ... and looking at the data format of a message received from the provider to determine whether or not the parameter is null terminated to decide String vs. CString. Or, if you are not concerned with readability for HTTP, just use HexString. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4608 Registered: 08-2008 |
Unfortunately, you'd have to parse the UDH to determine. | |||
| Tim Williams New member Username: Timw Post Number: 43 Registered: 09-2010 |
I can email the wireshark deliver SM with the optional parameter? IS there a specific format for the UDH to determine the number of parts (the last digits after the final - for example? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4610 Registered: 08-2008 |
Yes, go ahead and e-mail to nowsms@nowsms.com with Attention: Des in the subject line. I'll explain UDH in a follow-up. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4611 Registered: 08-2008 |
The first byte of UDH is an overall length (that follows ... e.g., not including this byte). Segments follow that are sequences of ID LENGTH DATA (LENGTH is the length of the data that follows) For segmented messages, ID=0 (or in rare instances 8) LENGTH=3 (or 4 if ID=8) DATA is sar_msg_ref_num (1 byte for ID=0, 2 bytes for ID=8) sar_total_segments sar_segment_seqnum So typically, you'd see something like: segment #1 of 2 - 050003EE0201 segment #2 of 2 - 050003EE0202 EE would vary ... it gets more complex if UDH includes other options like port addressing. We could probably add accounting callbacks to do this parsing and add more parameters to the callback ... with relative ease, I'm just hesitant to commit to that right now. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4613 Registered: 08-2008 |
Hi Tim, I looked at the Wireshark trace. I'd suggest using this setting: [SMPPOptions] mblox_mccmnc=1560,String -- Des NowSMS Support | |||
| Tim Williams New member Username: Timw Post Number: 44 Registered: 09-2010 |
Hi Des, I have added this into the config but looking at the accounting callbacks I can't see anything being passed through (this info is passed back to us in the DLR). Also, having looked at the requests coming through on the PreAuth and no UDH info is available but there is a MsgCount flag which appears to supply the info needed? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4615 Registered: 08-2008 |
Hi Tim, MsgCount will only be present for HTTP submissions, and only in the PreAuth. All other cases will see UDH. I'm trying to see if there is an issue specific to delivery reports and TLV parameters. But I need to find a way to simulate this since I don't have any SMPP connections that return extra TLV in delivery reports. Could you send me an SMSDEBUG.LOG and SMPPDEBUG.LOG showing one of these receipts being processed? That might give me a clue while I try to setup a way to recreate. Via email, like before, is fine. Send to nowsms@nowsms.com and put Attention: Des in the subject line. -- Des NowSMS Support | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4616 Registered: 08-2008 |
Hi Tim I did find a way to insert this parameter in some delivery reports, and it is working as expected. The SMSIN callback includes the paramter SMPPOption_mblox_mccmnc with this data. One thing I did notice though, is that changes to the [SMPPOptions] section of SMSGW.INI were not always activated without restarting the service. We are investigating that, but I suspect a service restart will activate the settings for you. -- Des NowSMS Support | |||
| Tim Williams New member Username: Timw Post Number: 45 Registered: 09-2010 |
Hi Des, Thanks for the help, all working as expected now :) | |||
| Tim Williams New member Username: Timw Post Number: 46 Registered: 09-2010 |
Hi Des, Bringing back an old thread - UDH headers.. all was working ok up until recently (well today) when I noticed I was unable to parse some correctly - so I checked and I have the following: Binary=1;DCS=4;UDH=0605043ED10000;Data=5768617473417070204A363638313450756937475 66E5876733031415A41504955545A6A376E35755020576861747341707020696E7465726E616C207 57365202D207361666520746F2064697363617264 This is just one part Request: Type=SMSSend&Binary=1&UDH=0B000304040105043ED10000&DCS=4&ReceiptRequested=Yes&Me ssageID=SAR-+[number]-5138fdb2-4-1&UserData=1197831 I received all the parts and NowSMS has got the message IDs in the format of segment 4-1 (and the others 4-2, 4-3, 4-4) etc but the UDH doesn't appear in the same format as others coming in - is this because it's a binary message? UDH headers: 0B000304040105043ED10000 0B000304040205043ED10000 0B000304040305043ED10000 0B000304040405043ED10000 I can see the bits I believe would be the total/current part (0401, 0402, 0403 etc) but is there a specific format for this and instances when they occur instead of the previous formats? Regards Tim | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4698 Registered: 08-2008 |
Hi Tim, This is because the UDH also includes port information ... specifically the message has a destination port number of 0x3ED1. It's probably easiest to explain by referencing my earlier post and explaining it with these examples ...
Looking at 0B000304040105043ED10000 0B is overall length First ID LENGTH DATA segment is 0003040401 Second ID LENGTH DATA segment is 05043ED10000 (05 ID is for port numbers) Before spending too much time on this ... we did make changes to the accounting callbacks in the most recent version (2013.09.26, which was promoted to the official download version). We factored in your original request with that from another customer that wanted an option to not reassemble 2-way SMS. The accounting callback processing now parses UDH for segmentation and port information. If present, it includes this information in HTTP variables SourcePort, DestPort, SegRef, SegCount and SegNum. So in the case of the first message, you'd now see the following additional parameters in the accounting callback: &DestPort=3ED1&SegRef=4&SegCount=4&SegNum=1 -- Des NowSMS Support | |||
| Tim Williams New member Username: Timw Post Number: 48 Registered: 09-2010 |
Hi Des, That would make life a lot easier I admit! when updating to the latest version what implications would this have on a live environment / ie server reboots any issues that might crop up? (license needing changing)? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4700 Registered: 08-2008 |
Hi Tim, Based upon your recent email (where you asked about the character set override for a particular client), you are currently running one of our interim 2013 releases. So I wouldn't expect any issues with an update. You might want to scan through http://www.nowsms.com/download/changes.txt and read back thru whatever version you are currently running to see if there are any notes that cause concern. The install will stop the services, then copy over the update and restart the services. It generally just shuts things down for a few minutes. -- Des NowSMS Support | |||
| Tim Williams New member Username: Timw Post Number: 50 Registered: 09-2010 |
Hi Des, Thanks - nothing looks like it would cause problems so will aim to update tonight or tomorrow - I do have a query regarding Burst Mode Licensing Support - is this activate automatically - or is a different license required? | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4705 Registered: 08-2008 |
Hi Tim, The burst mode logic will activate automatically. There is nothing to configure and no separate license required. -- Des NowSMS Support | |||
| Tim Williams Frequent Contributor Username: Timw Post Number: 51 Registered: 09-2010 |
Hi Des, Thanks again - all updated with no issues, only query I have at the moment is... can you disable any of the SMSC connections without totally removing them from the config (apart from changing the user/pass/port etc so it can't connect) | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 4711 Registered: 08-2008 |
Hi Tim, That is a frequent request to be able to temporarily disable an SMSC connection. Unfortunately, there is no facility to do so. I usually change username/password temporarily when I have had need to do so. It would be better if there were a setting, so we do need to reconsider. -- Des NowSMS Support | |||
