Summary:	ASTERISK-24468: Incoming UCS2 encoded SMS truncated if SMS length exceeds 50 (roughly) national symbols
Reporter:	Dmitriy Bubnov (dmitriy.bubnov)	Labels:
Date Opened:	2014-10-29 08:59:52	Date Closed:	2014-11-08 18:28:24.000-0600
Priority:	Critical	Regression?
Status:	Closed/Complete	Components:	Addons/chan_mobile
Versions:		Frequency of Occurrence	Constant
Related Issues:
Environment:	All	Attachments:	( 0) chan_mobile-1_8.diff ( 1) chan_mobile-trunk.diff ( 2) cmgr_hcidump_out.txt
Description:	One symbol in national language expanded to 4 bytes when UCS2 character encoding used. So, size of 256 bytes for receiving buffer {{buf}} in function {{do_monitor_phone}} is not enough for incoming UCS2 encoded SMS, when last is longer than 50 national symbols. I suggest to set size of this buffer to 350 bytes, instead of current 256 bytes. Such modification will make incoming SMS in UCS2 encoding not to be truncated. Provided patch reclaims truncation only for incoming SMS, and not affect outgoing SMS.
Comments:	By: Dmitriy Bubnov (dmitriy.bubnov) 2014-10-29 09:07:28.465-0500 +CMTI / +CMGR transaction between Nokia 6230i phone and Asterisk chan_mobile module By: Dmitriy Bubnov (dmitriy.bubnov) 2014-10-29 09:14:26.871-0500 Patch for chan_mobile.c trunk By: Dmitriy Bubnov (dmitriy.bubnov) 2014-10-29 09:17:21.726-0500 Patch for chan_mobile.c v1.8 By: Matt Jordan (mjordan) 2014-10-30 09:45:48.835-0500 Thanks for the patches! I am curious, however - why 350 bytes? That's something of an odd number (generally, powers of 2 are what are used). Is there any risk that 350 bytes is not sufficient? By: Dmitriy Bubnov (dmitriy.bubnov) 2014-10-30 11:30:24.503-0500 It is simple arithmetics. Lets count: 1) AT+CMGR phone response prefix {{+CMGR: "REC UNREAD","+7**********",,"14/10/29,13:31:39+12"\r\n}} is about 60 bytes; 2) 140 bytes is a maximum SMS body length regarding GSM standart, but in UCS2 encoding it expanded to 280 bytes; 3) AT+CMGR phone response suffix {{\r\n\r\nOK\r\n}} is 8 bytes; 4) plus 1 byte to hold char '\0' for C library string functions. So, 60+280+8+1=349. It's a minimum size for receiving buffer to hold long SMS in UCS2 encoding. Surely, it is possible to make {{buf}} bigger than 349 (but no less!) bytes to make provision for variants in phone response prefix, and to comply various "power of" rules. And, in any case, 256 bytes is not enough to hold whole phone response in case of long SMS in UCS2 encoding. By: Dmitriy Bubnov (dmitriy.bubnov) 2014-11-05 09:12:26.764-0600 What about this issue? By: Richard Mudgett (rmudgett) 2014-11-05 11:13:01.039-0600 You need to hit either the "Send Back" or the "Enter feedback" buttons when you respond with the requested feedback to allow filters to show the issue as needing further attention.  Otherwise someone has to manually watch the issue.  For some reason not many people figure this out and wonder why nothing happens. :( By: Dmitriy Bubnov (dmitriy.bubnov) 2014-11-05 11:38:35.326-0600 Ok, thank you. It is my fault, or, may be, my old Safari browser. By: Matt Jordan (mjordan) 2014-11-05 16:25:36.376-0600 I like to blame the browser myself :-) As {{chan_mobile}} is an extended support module, I don't think you'll find too many objections to the patch. As the final release of 1.8 is currently in RC status, I'll be happy to apply this patch to 11+ in the next few days.