16bit ref in SmsSubmit

[SteveAyre]

It would be nice to support encoding 16bit concatenated sms references in SmsSubmit.

[andrewbird]

Hi Steve,
Do you have an example of what you require?

Andrew

[SteveAyre]

As described on http://en.wikipedia.org/wiki/Concatenated_SMS...

A UDL starting 05 00 03 has a 8bit CSMS reference number (1 octets)
A UDL starting 06 08 04 has an 16bit CSMS reference number (2 octets)

This reduces the chance of collisions between references used.

A quick glance of the code indicates that receiving this header is supported (UserDataHeader.from_bytes udh.py line 61) but not when sending (SmsSubmit._split_sms_message submit.py line 302)

[andrewbird]

Hi Steve,
Yes I see no reason why we should not support 16 bit references. I'm not sure if we should change the default or just leave it as an option for the caller. I might get to play with this in the coming days as I have holiday. Do you have a complete PDU from another system that uses these that I might replicate in the unit tests?

Andrew

[SteveAyre]

Another option is to automatically use 8bit for 0-255 and 16bit for 256-65535.

Which is used is then up to the reference generated by the rand_id or id_list properties (since they appear to set the reference).

[andrewbird]

Well I just did some rudimentary check with pduspy and it looks like that
1/ the ref number is not random, it increments 1 .. 254, then rolls over to 0
2/ the ref number increments every time .to_pdu() is called
3/ unless the message object is reused each message sent will have ref number 01 i.e.
d=sms.SmsSubmit("234565432",("h"_161))
print d.to_pdu()[0].pdu # ref is 01
e=sms.SmsSubmit("234565432",("m"_161))
print e.to_pdu()[0].pdu # ref is 01
So two concatenated messages using different objects sent to the same number potentially could have their parts mixed on reassembly.

@pmarti Pablo. what do you think about replacing this logic with the following:
1/ use random 16 bit ref id by default
2/ if ref id is explicitly set via property, if <= 255 use 8 bit method, if > 255 use 16bit method
I figure that should keep things working for people whom have set the value for some reason.

[SteveAyre]

16 bit message ID only refers to the Concatenated SMS UDH reference, which is a different reference the Message Reference, which is always 8bit.

[andrewbird]

Yep I used the wrong terminology(corrected now). I should have said
1/ use random 16 bit ref id by default
2/ if ref id is explicitly set via property, if <= 255 use 8 bit method, if > 255 use 16bit method

[SteveAyre]

Ok. :o)

The same argument goes for the Message Reference too by the way, it's also not random (loops 0-254). It pops 0 before the CSMS pops 1. If you set the ref property it'll loop 0-254 for the CSMS instead.

Since the ref is cached by _get_tpmessref_pdu, it (possibly) prevents reuse of the SmsSubmit object unless you modify the ref each time.

[andrewbird]

A side effect of using 16bit reference numbers is that the individual message payload is reduced. So 7 bit GSM multipart messages become 152 chars instead of 153, and UCS2 ones become 66 chars instead of 67. I'm not sure if we should have the message length vary based purely on which random id got chosen?