| Multipart messages problem |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Lite Support ⬆ Archive through September 20, 2012 ⬆ |
◄ ► |
| Author | Message | |||
| Neil Stamps New member Username: Neil Post Number: 36 Registered: 12-2009 |
I am trying to test multipart incoming messages, which will be received by a JSMS library via SMPP. It seems that the UDH data is getting manipulated - the incomming from the modem indicates 5 octets of data - but the data received by our application shows an indicator of zero - but there are still 5 octets in place. I enclose the receipt logs here are the logs of the received data... 2010-01-26 15:38:53,+447989417659,GlobeTrotter GI515m - Modem Interface,UDH=050003130401;Text="The licenses for most software are designed to take away yourfreedom to share and change it. By contrast, the GNU General PublicLicenses are intended to";Recip=+07527429359 2010-01-26 15:38:53,+447989417659,GlobeTrotter GI515m - Modem Interface,UDH=050003130402;Text=" guarantee your freedom to share and changefree software--to make sure the software is free for all its users.for this service if you wish); that you rec";Recip=+07527429359 2010-01-26 15:39:00,+447989417659,GlobeTrotter GI515m - Modem Interface,UDH=050003130403;Text="eive source code or can getit if you want it; that you can change the software and use pieces ofit in new free programs; and that you are informed that y";Recip=+07527429359 2010-01-26 15:39:00,+447989417659,GlobeTrotter GI515m - Modem Interface,UDH=050003130404;Text="ou can dothese things.END OF MESSAGE";Recip=+07527429359 This is the diagnostics from the receipt library - showing the UDH as received (just the first - the other parts show a similar problem). ---Message--- id : 1 sender : Number: 447989417659, Type of Nr: (0x01) International, NPI: (0x01) ISDN/Telephone (E.164/E.163) recipient : Number: 07527429359, Type of Nr: (0x01) International, NPI: (0x01) ISDN/Telephone (E.164/E.163) type : text DCS : 0xF0 [DATA_CODING][DEFAULT_ALPHABET][CLASS_0] timestamp : Tue Jan 26 15:38:53 GMT 2010 message : "The licenses for most software are designed to take away yourfreedom to share and change it. By contrast, the GNU General PublicLicenses are intended to" statusReport : false validityPeriod : null deferredDelivery : null UDH present : true --- UDH --- 000000000 00 03 13 04 01 |.....| rejectDuplicates : false replyPath : false mms : false protocolIdentifier: 0x00 SME-to-SME protocol isCompressed : false priorityFlag: 0 scheduleDeliveryTime: UNSET replaceIfPresent: false serviceType: ---Source--- | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1722 Registered: 08-2008 |
Hi Neil, Are you sure that there is actually a problem? It may just be the way that the software library you are using works. Different software implementations seem to differ in their interpretation of whether or not the UDHL (length) is included as part of the UDH. In the physical SMS, UDHL is always the first byte of the UDH. But when the physical message is abstracted by software, the software designer might decide not to include the UDHL in the UDH. So, if it's truly missing, I would need to see an SMPP trace ... or SMPPDEBUG.LOG. I'd be shocked if NowSMS was losing this byte. I think instead it's just the way the library you are using handles UDH by not including the UDHL. As a side note, you might prefer not to work with UDH for segmentation, and instead use SMPP TLV parameters ... which are easier to understand and decode. By default, NowSMS uses UDH, but there is a configuration option to use TLV parameters instead (sar_msg_ref_num, sar_total_segments, sar_segment_seqnum). This configuration screen is not present in NowSMS Lite, but you can manually edit SMSGW.INI, and under an [SMPP] header, add UseTLV=Yes. -- Des NowSMS Support | |||
| Neil Stamps New member Username: Neil Post Number: 37 Registered: 12-2009 |
the logs I have enclosed are from the software library - it shows the raw UDH as received. It looks like the length indicator has indeed been dropped. Unfortunately the TLV strategy does now work with the JSMS library as it sees them as individual messages rather than a multipart. | |||
| Des - NowSMS Support Board Administrator Username: Desosms Post Number: 1736 Registered: 08-2008 |
Neil, It doesn't matter what the logs from the software library show. (Well, it matters a little, but it is not the definitive word on this matter.) As I stated above, different software implementations seem to differ in their interpretation of whether or not the UDHL (length) is actually part of the UDH. This has nothing to do with the physical message, where the UDHL is required to precede the UDH data. In the example above, your software library says that the UDH is 00 03 13 04 01. If the UDHL byte were actually missing, the software would have no way of knowing that the UDH is 5 bytes long! That said, I'm probably being too academic in this discussion. I would suggest that you use Wireshark to intercept and interpret the SMPP data going to your client. You should see that the UDH length field is indeed present. This length byte is always the first byte of UDH. The fact that this software library does not consider the length byte to actually be part of the UDH is irrelevant. -- Des NowSMS Support | |||
| Neil Stamps New member Username: Neil Post Number: 39 Registered: 12-2009 |
Thanks - I've had confirmation of a problem in the libraries we are using. This is now resolved. | |||
