change SMS ID

[e***@hotmail.com]

can i change SMS ID if i use GSM modem ? if yes then how ?

[John Henderson]

Post by e***@hotmail.com
can i change SMS ID if i use GSM modem ? if yes then how ?

What are you trying to do? What do you mean by "SMS ID"?

John

[e***@hotmail.com]

Post by e***@hotmail.com
can i change SMS ID if i use GSM modem ? if yes then how ?

What are you trying to do?  What do you mean by "SMS ID"?
John

hi John
i need to change the SMS sender name

[John Henderson]

Post by e***@hotmail.com
hi John
i need to change the SMS sender name

You can't do that when messages get lodged "over-the-air", as
from a phone or modem. The sender (originator) phone number is
put into the message by the SMSC (message centre) where it's
lodged. There is no mechanism for passing a different
originator address to the SMSC.

However, you can include a "reply-to" address that's different
from the originator address. This is a fairly recent feature,
so not all receiving handsets will handle it correctly.

You put this reply-to address into a UDH (user data header), and
turn the UDHI (indicator) bit on within the PDU-type octet.

If I wanted to send the message text "Please reply" to
[phone], and specify [phone] as the reply-to address,
then I'd try sending a PDU like:

0051000B918967452301F90000AA190A22080B912143658709F180B2CBE17919242FC3D979

See 3GPP 23.040, sections 9.2.3.24 and 9.2.3.24.10.1.17.

John

[h***@gmail.com]

Post by John Henderson

Post by e***@hotmail.com
hi John
i need to change the SMS sender name

You can't do that when messages get lodged "over-the-air", as
from a phone or modem. The sender (originator) phone number is
put into the message by the SMSC (message centre) where it's
lodged. There is no mechanism for passing a different
originator address to the SMSC.
However, you can include a "reply-to" address that's different
from the originator address. This is a fairly recent feature,
so not all receiving handsets will handle it correctly.
You put this reply-to address into a UDH (user data header), and
turn the UDHI (indicator) bit on within the PDU-type octet.
If I wanted to send the message text "Please reply" to
[phone], and specify [phone] as the reply-to address,
0051000B918967452301F90000AA190A22080B912143658709F180B2CBE17919242FC3D979
See 3GPP 23.040, sections 9.2.3.24 and 9.2.3.24.10.1.17.
John

can u show me format of your pdu, i dont understand 190A22080B912143658709F180B2CBE17919242FC3D979

[John Henderson]

Post by h***@gmail.com
can u show me format of your pdu, i dont understand 190A22080B912143658709F180B2CBE17919242FC3D979

Handset manufacturers seem to have ignored the reply address
facility completely to date. But the encoding of a UDH follows
standard procedure.

19 UDL (UD length in septets, 25 decimal)
0A UDHL (UDH length in octets, 10 decimal)
22 IEI (reply address element)
08 length of reply address element
0B address length excluding "F" fill digit (semi-octets,
11decimal)
91 type-of-address (international format)
2143658709F1 address (12345678901)

Note the different units of length in the standards for different
situations - septets, octets, and semi-octets.

Let's talk in decimal now unless we need to do otherwise.
The UDHL value was 10 octets, which is 80 bits. Add the 8
bits for the UDHL octet itself gives us 88 bits total consumed by
using a UDH in our case. The UDH needs to be padded to a septet
boundary, and the next septet boundary is at 13 septets (91
bits) used.

This means that the first 13 septets positions of the UD are
taken. The reason for the requirement to pad to a septet
boundary is for compatability with early handsets which do not
undertand the UDH mechanism. These handsets must display the
text after the UDH correctly, as if the UDH was ordinary text.
So these devices will display the UDH as gibberish in front of
the actual text. If the leading 13 septets were all zero fill
bits, that could be achieved by using 13 leading "@"
characters ("@" is 7 all-zero bits in the 7-bit default
alphabet).

If we enode the standard (no UDH) 25-septet text
message "@@@@@@@@@@@@@Please reply" we get a UDL-UD field of
19000000000000000000000080B2CBE17919242FC3D979.

So I hope you see exactly how the remainder of the UD
(80B2CBE17919242FC3D979) is derived.

[h***@gmail.com]

Post by John Henderson

Post by h***@gmail.com
can u show me format of your pdu, i dont understand 190A22080B912143658709F180B2CBE17919242FC3D979

Handset manufacturers seem to have ignored the reply address
facility completely to date. But the encoding of a UDH follows
standard procedure.
19 UDL (UD length in septets, 25 decimal)
0A UDHL (UDH length in octets, 10 decimal)
22 IEI (reply address element)
08 length of reply address element
0B address length excluding "F" fill digit (semi-octets,
11decimal)
91 type-of-address (international format)
2143658709F1 address (12345678901)
Note the different units of length in the standards for different
situations - septets, octets, and semi-octets.
Let's talk in decimal now unless we need to do otherwise.
The UDHL value was 10 octets, which is 80 bits. Add the 8
bits for the UDHL octet itself gives us 88 bits total consumed by
using a UDH in our case. The UDH needs to be padded to a septet
boundary, and the next septet boundary is at 13 septets (91
bits) used.
This means that the first 13 septets positions of the UD are
taken. The reason for the requirement to pad to a septet
boundary is for compatability with early handsets which do not
undertand the UDH mechanism. These handsets must display the
text after the UDH correctly, as if the UDH was ordinary text.
So these devices will display the UDH as gibberish in front of
the actual text. If the leading 13 septets were all zero fill
alphabet).
If we enode the standard (no UDH) 25-septet text
19000000000000000000000080B2CBE17919242FC3D979.
So I hope you see exactly how the remainder of the UD
(80B2CBE17919242FC3D979) is derived.

thank you for your help, but i still understand standard of "80B2CBE17919242FC3D979" (septet, octet or decimal semi-octet), i used "E8 32 9B FD 46 97 D9 EC 37" (hellohello), but when message is built content not correct "hellohello"

[John Henderson]

Post by h***@gmail.com
thank you for your help, but i still understand standard of "80B2CBE17919242FC3D979" (septet, octet or decimal semi-octet), i used "E8 32 9B FD 46 97 D9 EC 37" (hellohello), but when message is built content not correct "hellohello"

"hellohello" encodes as 0AE8329BFD4697D9EC37, where the leading
"0A" being the UDL (10 decimal). The UD itself is
E8329BFD4697D9EC37 as you say.

This is for a standard SMS without a UDH in the UD field. This
means the UDHI bit isn't set in the PDU-type octet.

If you set the UDHI bit, this means that the octet following the
UDL is the length (in octets) of the UDH. In that case, the
encoding of the text "hellohello" gets complicated, because it
must be padded to the septet boundary following the UDH, but
nevertheless encoded as if the UDH was leading 7-bit characters.

Are you trying to encode "hellohello" in an SMS with a UDH at the
beginning of the UD field? If so, what's your UDH?

John

[h***@gmail.com]

Post by John Henderson

Post by h***@gmail.com
thank you for your help, but i still understand standard of "80B2CBE17919242FC3D979" (septet, octet or decimal semi-octet), i used "E8 32 9B FD 46 97 D9 EC 37" (hellohello), but when message is built content not correct "hellohello"

"hellohello" encodes as 0AE8329BFD4697D9EC37, where the leading
"0A" being the UDL (10 decimal). The UD itself is
E8329BFD4697D9EC37 as you say.
This is for a standard SMS without a UDH in the UD field. This
means the UDHI bit isn't set in the PDU-type octet.
If you set the UDHI bit, this means that the octet following the
UDL is the length (in octets) of the UDH. In that case, the
encoding of the text "hellohello" gets complicated, because it
must be padded to the septet boundary following the UDH, but
nevertheless encoded as if the UDH was leading 7-bit characters.
Are you trying to encode "hellohello" in an SMS with a UDH at the
beginning of the UD field? If so, what's your UDH?
John

i use PDU that you posted "0051000B918967452301F90000AA190A22080B912143658709F180B2CBE17919242FC3D979" but i modified this pdu, ignore "0051000B918967452301F90000AA", i want to edit "190A22080B912143658709F180B2CBE17919242FC3D979", as you said:
19 UDL (UD length in septets, 25 decimal)
0A UDHL (UDH length in octets, 10 decimal)
22 IEI (reply address element)
08 length of reply address element
0B address length excluding "F" fill digit (semi-octets,
11decimal)
91 type-of-address (international format)
2143658709F1 address (12345678901)
i try to change UDL (19), 0A, 08, 0B, 91, address 12345678901 to another, but i cant encode a new text such as "hellohello" as i want, i want to know how to encode it and insert it into pdu. May you show me how to encode any text in PDU with UDHI was set.
Note: i set UDHI too (51).
P/s: Sorry about my english :(

[John Henderson]

Post by John Henderson
19 UDL (UD length in septets, 25 decimal)
0A UDHL (UDH length in octets, 10 decimal)
22 IEI (reply address element)
08 length of reply address element
0B address length excluding "F" fill digit (semi-octets,
11decimal)
91 type-of-address (international format)
2143658709F1 address (12345678901)
i try to change UDL (19), 0A, 08, 0B, 91, address 12345678901 to another, but i cant encode a new text such as "hellohello" as i want, i want to know how to encode it and insert it into pdu. May you show me how to encode any text in PDU with UDHI was set.
Note: i set UDHI too (51).
P/s: Sorry about my english :(

OK, let's assume your UDHL is unchanged at 0A hex (10 decimal),
and you're using the same 11-digit international-format reply
address ([phone]) as I used in my example. That makes
things simpler.

The UDH length, including the UDHL octet, remains 11 octets
(decimal), or 88 bits. The next septet boundary is at 13 septets
(91 bits) used.

What would "hellohello" encode as if it occurred after 13 other
7-bit characters? In general, you can't say how it would begin
because the packing algorithm would have bits of the 13th
character mixed up with bits of the 14th character (3GPP 23.038,
section 6.1.2.1.1).

But the packing to accommodate a UDH is a special case, where we
know that the fill bits are all zeros. So we can encode
"hellohello" with absolute certainty. And an easy way to do that
is to encode the 23-bit (13 + 10) text "@@@@@@@@@@@@@hellohello",
and simply replace the required number of leading octets with the
UDH.

Encoding this text gives us a UDL of 17 hex, and a UD of:
00000000000000000000004097D9EC37BACC66BF01

Now replace the first 11 octets 0000000000000000000000 with
0A22080B912143658709F1 and you have your UD of
0A22080B912143658709F14097D9EC37BACC66BF01 (saying "hellohello").

John

[h***@gmail.com]

Post by John Henderson

Post by John Henderson
19 UDL (UD length in septets, 25 decimal)
0A UDHL (UDH length in octets, 10 decimal)
22 IEI (reply address element)
08 length of reply address element
0B address length excluding "F" fill digit (semi-octets,
11decimal)
91 type-of-address (international format)
2143658709F1 address (12345678901)
i try to change UDL (19), 0A, 08, 0B, 91, address 12345678901 to another, but i cant encode a new text such as "hellohello" as i want, i want to know how to encode it and insert it into pdu. May you show me how to encode any text in PDU with UDHI was set.
Note: i set UDHI too (51).
P/s: Sorry about my english :(

OK, let's assume your UDHL is unchanged at 0A hex (10 decimal),
and you're using the same 11-digit international-format reply
address ([phone]) as I used in my example. That makes
things simpler.
The UDH length, including the UDHL octet, remains 11 octets
(decimal), or 88 bits. The next septet boundary is at 13 septets
(91 bits) used.
What would "hellohello" encode as if it occurred after 13 other
7-bit characters? In general, you can't say how it would begin
because the packing algorithm would have bits of the 13th
character mixed up with bits of the 14th character (3GPP 23.038,
section 6.1.2.1.1).
But the packing to accommodate a UDH is a special case, where we
know that the fill bits are all zeros. So we can encode
"hellohello" with absolute certainty. And an easy way to do that
and simply replace the required number of leading octets with the
UDH.
00000000000000000000004097D9EC37BACC66BF01
Now replace the first 11 octets 0000000000000000000000 with
0A22080B912143658709F1 and you have your UD of
0A22080B912143658709F14097D9EC37BACC66BF01 (saying "hellohello").
John

oke, i'll try it, thank you very much :)

[John Henderson]

And an easy way to do that is to encode the 23-bit (13 + 10) text

Oops. I meant to say 23-character, of course.

John

[h***@gmail.com]

Post by John Henderson

And an easy way to do that is to encode the 23-bit (13 + 10) text

Oops. I meant to say 23-character, of course.
John

so, if i have any text, i will add 13 chars "@" at the top of text, then encode, right?

[John Henderson]

That works for a UDHL value of 0A (10 decimal). If your UDHL was
09, the next septet boundary would be at 12 septets (84 bits)
used. So 12 "@" characters in that case.

If UDHL is 0B hex (11 decimal), then (11 + 1) x 8 = 96 bits are
required for the UDHL + UDH, and the next septet boundary is at
14 septets (98 bits) used. And so on.

Note that some values don't require any padding. 16 septets = 14
octets exactly, for example.

John

[h***@gmail.com]

Post by John Henderson
That works for a UDHL value of 0A (10 decimal). If your UDHL was
09, the next septet boundary would be at 12 septets (84 bits)
If UDHL is 0B hex (11 decimal), then (11 + 1) x 8 = 96 bits are
required for the UDHL + UDH, and the next septet boundary is at
14 septets (98 bits) used. And so on.
Note that some values don't require any padding. 16 septets = 14
octets exactly, for example.
John

hi, its worked, i mofified UDHL and UDL too, just take length of message and some action then, so thank you so much, thank you for help me, this is my final exam :), thank you again :D

[h***@gmail.com]

Post by John Henderson

And an easy way to do that is to encode the 23-bit (13 + 10) text

Oops. I meant to say 23-character, of course.
John

so, i have any text, and i will add 13 char "@" on the top of text then encode it, right ?

[John Weidow]

Post by e***@hotmail.com
can i change SMS ID if i use GSM modem ? if yes then how ?

Solavei is the way
http://www.purplefuture.tk
Love the idea of making money with your mobile device ? Try Solavei
You will never have to buy anything with Solavei... all you are doing is paying for a phone service... what Solavei offers as a mobile service provider is a reward to you for sharing Solavei with those you like, love and trust. So many companies online ask you to pay to be a part of the their company and then you will make all this money... Solavei doesn't and will not ever do that! To learn more how you can get your unlimited 4G nationwide Data, Text and Voice Smartphone for only $49 per month with no contract - or free - simple visit my site. BTW - we are looking for those interested in assisting with our final phase of beta-testing prior to our commercial launch on Sept. 21, 2012.