Possible SMPP Encoding Issue

Possible SMPP Encoding Issue SearchSearch

SMS & MMS Technical Forum » NowSMS Support - SMS Issues (Product Support Only) » Archive through November 14, 2013 » Possible SMPP Encoding Issue « Previous || Next »
Author Message
Tim Williams
New member
Username: Timw

Post Number: 39
Registered: 09-2010
Posted on Thursday, August 22, 2013 - 05:57 pm:   

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
Posted on Thursday, August 22, 2013 - 06:10 pm:   

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
Posted on Friday, August 23, 2013 - 03:05 am:   

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
Posted on Friday, August 23, 2013 - 12:28 pm:   

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
Posted on Friday, August 23, 2013 - 01:27 pm:   

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
Posted on Friday, August 23, 2013 - 01:55 pm:   

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
Posted on Friday, August 23, 2013 - 01:58 pm:   


quote:

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?




Unfortunately, you'd have to parse the UDH to determine.
Tim Williams
New member
Username: Timw

Post Number: 43
Registered: 09-2010
Posted on Friday, August 23, 2013 - 02:08 pm:   

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
Posted on Friday, August 23, 2013 - 02:42 pm:   

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
Posted on Friday, August 23, 2013 - 02:55 pm:   

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
Posted on Monday, August 26, 2013 - 07:23 pm:   

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
Posted on Tuesday, August 27, 2013 - 04:06 pm:   

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
Posted on Tuesday, August 27, 2013 - 04:41 pm:   

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
Posted on Tuesday, August 27, 2013 - 06:07 pm:   

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
Posted on Thursday, August 29, 2013 - 01:51 pm:   

Hi Des,

Thanks for the help, all working as expected now :)
Tim Williams
New member
Username: Timw

Post Number: 46
Registered: 09-2010
Posted on Tuesday, October 22, 2013 - 12:56 pm:   

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
Posted on Wednesday, October 23, 2013 - 03:49 pm:   

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 ...


quote:

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




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
Posted on Wednesday, October 23, 2013 - 03:56 pm:   

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
Posted on Wednesday, October 23, 2013 - 04:17 pm:   

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
Posted on Monday, October 28, 2013 - 12:38 pm:   

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
Posted on Monday, October 28, 2013 - 03:04 pm:   

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
Posted on Tuesday, October 29, 2013 - 10:27 am:   

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
Posted on Wednesday, October 30, 2013 - 05:07 pm:   

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

Login Login / Register Logout Logout Search Last 30 Days Topics Topics