Well one thing for sure, my jolla one with sailfish 3.4 does not lose any message, so something happened on the road to sf 4 (i noticed i was losing messages in sf 4.5)
I know sf 3.4 is working cause if i request an activation code or an otp, it arrives straight away, while on the xa2 i often have to resend the message multiple times…
X10III, SFOS 5.0.0.68 (current), no VoLTE (incompatible operator )
This morning: I received only the last from a series of SMSs from a sender. No trace of the others.
Past issues, older SFOS versions: some SMSs -or even parts of longer ones- appear like sent by a special, short number- instead of being linked under the message sender.
The sender is abroad if that matters,on Android, and may use some unicode chars.
My hypothesis: something in the message structure (operator related, charset related ) derail the SFOS handling of the message.
Question: is it possible to turn on persistent logging of the raw data of SMS/MMS/alerts/voice message notifications etc - for offline inspection?
@247
A lot about the networks has also changed.
@rtr2001
Rather fantastical hypothesis, but ofono logger should be just that.
1 Like
Today i discovered that my problem just disappeared. I don’t have a clue what happened, i changed nothing.
10ii sfos 5.0.68 : last weeks, a random part of SMS I,ve received was seriously delayed (around 1 week delayed).
I think it was my operator which get the problem.
I have the same problem recently with one contact on XA2 (h4113), Sailfish 5.0.0.68, 2G. I’ve looked into /var/lib/ofono//sms_assembly, but there was no track of the completely missing message (and same for the previous noticed occurence). Later he re-sent the message and it was also interesting, because according to my operator’s metadata, both consisted of 4 parts. But the re-sent message happend to be incorrectly assembled, leaving part 004 inside subdirectory of sms_assembly, showing that part 004 is not the last, as after the omitted part there were 9 more characters the message continued with. Time of the 004 file is 18:51:44, a second after third message and two seconds before fourth by operator’s metadata. Time distance (as recieved by operator? - would need to investigate) between parts was in both cases <=6s. I will try ofono logger, hope I will get some more useful info.
1 Like
I’ve also seen partial SMS many times, or SMS received as “corrupted”, containing parts of some earlier messages in them. There is definitely something wrong with the messages/parts handling.
3 Likes
Sms-mt (mobile terminating) service can come through multiple different routes. Even in plain old 2G there are two practically different services due to different bearers (first cs and later also gprs in 2G ph2+). (In early days that often used to cause problems for device manufacturers in case of reply-to-a-message vs. generate-a-new-message (instead of reply.) Sometimes reply tried to re-use the bearer (typically gprs) which then caused delivery failure on network side, depending on the operator.)
In 4G, routes may use SIP over IMS if VoLTE is available but also signalling gateway, which eventually utilizes old 2G/3G core. However, interworking along those paths may modify some aspects of the message, such as maybe encapsulation, headers, or originating address, all of which the ue must be able to handle correctly. Especially by the time of concatenating messages.
Each sms is independent from the other sms’es that altogether form the original message. Even all parts may end up using different routes, if e.g. a moving terminal looses some connection and network applies alternative fallback route which works.
So, solution is not to quit using 2G because neither ue nor smsc can decide or guarantee a certain delivery route for sms-mt. 4G relays on 2G. Note also that sms-mt uses the originating sender’s smsc. Terminating user’s operator’s smsc is not involved at all. Hence, the ue should adapt to all variations out there in order to support sms-mt service and to be able to receive sms’es from other operators, world wide. To support sms-mo (which is different and independent service from sms-mt) case is different, since sms-mo always uses own operator’s smsc. (And delivery pipeline continues with sms-mt from thereon.)
Sounds like some sailfish sw-version cannot deal with all variations of sms-mt that may in worst case terminate even through a mixture of routes and meet some interworking on the route. That would also explain the messages appearing sent by short numbers and explains also a strange additional message if any. My guess is that IMS iw-point receives a too long message in sip, which is re-segmented (at iw-point) because it does not fit to a single tpdu. Network works as specified but sailfish fails to handle such exception case.
For debugging I’d probably switch 4G off and see what comes through when variant length messages are sent from another VoLTE phone in another operator’s network. (Can’t test myself / don’t have SF.)
2 Likes
I’ve also noticed, that when notified someone sent me an SMS message and I haven’t received it, restarting phone helps clear the condition with the specific users. Lost texts remain lost, but anything in the future comes through (not sure how long, but complaints stop)
I finally have a hit. Interesting parts in the log are 10:20-11:20, when the missing SMS was supposed to arrive (times 10:20:25, 27, 33, 38 according to my operator) and then (14:49:30, 33, 35, 37 according to my operator), when my friend re-sent the message, now arriving succesfully.
As I said previously, 2G only, data switched off. Upon request, I can provide content of the problematic SMS (fortunately no sensitive data inside). Contained Czech diacritical marks.
(I had to change the extension form .tar.gz to .targz in order to be able to upload it here, you may need to reverse this process to view the contents.)
ofono_2026-01-20_193713.targz (4.3 KB)
3 Likes