tracker issue : CF-3038839

Problem:

UDH (user defined headers) are smegs of binary data prepended to incoming SMS text to indicate the SMS contains logos/ringtones or, probably more frequently, is part of a multiple message SMS (ie the original text was too long so the provider chopped up the message into 160 char chunks & re-sent). the esmClass for these types of SMS is 64. the UDH provides info for the SMS client to reassemble the message parts back into one message. the UDH bytes consist of:

byte[1]=length of data header-1 or length of next bits
byte[2]=message type
byte[3]=length of next bits
byte[4]=message ID
byte[5]=total message parts
byte[6]=this is message part #

the problem lies in the 2nd byte (message type), which for multiple SMS is \u0000. cf strips out/throws away this "NULL" byte so the byte sequence then becomes 1-3-4-5-6 with a length of 5 bytes instead of the 6 that were really sent.

it would be ideal if the SMS gateway handled/parsed the UDH or failing that if cf didn't toss out the "NULL" 2nd byte to allow the client to more easily parse the incoming SMS.

thanks.
Method:

<cfscript>
// udh
// byte[1]=length of data header-1 or length of next bits
// byte[2]=message type
// byte[3]=length of next bits
// byte[4]=message ID
// byte[5]=total message parts if message type=0
// byte[6]=this part #

// fake a UDH for testing
// 5 bytes coming, multi message type, 3 bytes coming, messageID, two parts, this is part #1
udh=toBinary(toBase64(chr(5)&chr(0)&chr(3)&chr(21)&chr(2)&chr(1)));
// length as told by UDH
l=udh[1]+1;
// length of byte array
realL=arrayLen(udh);
system.dump(udh);
writeoutput("real length:=#realL#<br>header stated length:=#l#<br>");
</cfscript>

Result:

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3038839

External Customer Info:
External Company:  
External Customer Name: PaulH
External Customer Email: 00EE238442D680B29920157F
External Test Config: 06/08/2009

Attachments:

Comments: