I toyed with the idea of rebasing our commits on top of raykrueger/master but decided against it in the end. Not necessarily for any good reason other than that I didn't want to have to force push our master. We'll want to refactor the transmitter to remove some of the duplication between that and smpp/base.rb (that was refactored in 7f6c01e).
…he message_id in the case of the 6-octet UDH. In this way the @udh array always has the same number of elements whether the UDH is in the 5 or 6 octet form. We changed the expected values in the assertions checking the decoded UDH values to use hex values so they can be related to the raw hex values above.
The test we've deleted didn't have any assertions, was called "not a real test", and seemed almost identical to the test below it.
…o it doesn't clutter up the test output.
…s to be either 5 or 6.
…sage ID instead of the usual 1-octet. The tests I've added are based on real messages, but with anonymized MSISDNs and content - hopefully the raw data is still in a consistent form. It looks like there may be similar shortcomings in the SubmitSm PDU code, but I haven't addressed these.
Due to significant divergence from the SMPP spec, the encoding logic was becoming complex and SMSC specific. We've therefore moved this logic into our own application, where it seems to more naturally fit.
…_mt was the same as the PDU sequence number.
…data coding bits are not set.
Some messages were found with data_coding of 1. Although some specs state that this means they are encoded as ASCII, when dealing with O2 SMSCs, bits 2 and 3 of the data_coding are used to indicate encoding. If they are both set to 0 then this indicates default character set, in our case HP-ROMAN8
I got the code for the circumflex character wrong.
These messages come in with data coding '8'.
Because these come with an escape character and then an ASCII character, we substitute it for the appropriate ROMAN-8 coding. The euro character is a special case, since there is no ROMAN-8 encoding for this character. In this case we simply insert a very unlikely token string, and then replace it after the UTF-8 conversion has occurred.
We want UTF-8 in our application, so let's convert it using Iconv. We should remember that we've hard-coded the character set that is in use on SMSCs for historical reasons, but this may not be the case on all SMSCs.
… raises an exception.
Can now handle 5 bit header information being sent in the body of the message. To fully support all types of mobile concatenated messages, the ability to handle 8 bit body headers will need to be implemented. At the moment this difficult as we require an example message with a 8 bit header.