SMS encoding type used by Tmobile network?

[smsemailfreak]

1) Sending international characters, such as ñ, from any tmobile phone to another tmobile phone, including ancient bricks, works fine.
2) Sending via phone to another phone on a different provider works fine
3) When emailing such characters via the sms gateway to tmobile phones the characters are NOT displayed.
4) When emailing to other providers, via their sms gateway, the characters ARE displayed.

Since the email gateway works with other providers, but not with tmobile, something is wrong on your side according to a myriad of tests.

Please let us (all of the developers) know the EXACT SMS encoding specification that you are using, or if you're not using SMS encoding specifications, please advise what encoding you are using.
Thanks

[Takeshi]

Hello smsemailfreak and Welcome to the T-Mobile Partner Network,

I see the issue you mention and am able to replicate it. I have some ideas on this but want to do a bit more research.

Thank you,
Takeshi

[smsemailfreak]

I look forward to more support, this is hurting...

In the meantime, please post your encoding information.

Cheers

[Takeshi]

Hello smsemailfreak,

We understand this is frustrating and we are working to get the information you need as quickly as possible. Unfortunately, this is not our primary area of focus and so we must bounce this off a few of our internal contacts to find the information and this takes time.

My best guess from my experience is that the tmomail.net is not a true sms gateway because it is capable of processing MMS and html email. The people that I've spoke to in various departments all agree that the characters are getting lost in translation, we just have to get the exact reason why.

Thank you,
Takeshi

[smsemailfreak]

COMMUNITY... do a and respond and please

Takeshi,

Thank you for keeping us updated, hopefully I can provide some more info to help.

******************** a **********************
compose an email and send to NUMBER@tmomail.net
leave subject blank, no need for it
in the body, make sure you have under X# of chars such as:
í, ú, ñ
a.1) what happens? ....you get ????????, no special chars on the phone
now do the same thing, but put 160 of them
a.2) what happens? ...... you get an MMS received on the phone, which can show all characters in one message

Here is flow
INCOMING MESSAGE
if message { process without using GSM 03.38}
if messsage > X # of bits {send as MMS}

Interesting? Yes, it appears that if the incoming messages to your gateway are never processed using the GSM 03.38 charset. (More than likely, they are being interpreted as UTF data, which would explain the character limitation when using the gateway, but not with phones, as shown below.)

Here is further breakdown:
Using email Compose a message with 160 foreign chars and send...
From above, you should be able to guess what happens, you get an MMS

Using a tmobile networked phone, compose a message with 160 foreign chars, send...
What happens? .... phone receives all 160 chars, as it should,
It's because it's processing as GSM 03.38

I hope this helps.


****************** 1 ***************************
Here is a generic explanation of the GSM 03.38 charset - this is accurate to inform
that the characters as described, should be functioning in your gateway - IF your gateway were GSM 03.38.
http://en.wikipedia.org/wiki/GSM_03.38

The site includes links for:
* GSM 03.38 to Unicode - the GSM 03.38 to Unicode mapping data file from unicode.org.
* Text to GSM 03.38 in C# - Text to GSM 03.38 mapping in the C# programming language.

And:
JCharset - Java Charset package includes GSM 03.38 support - JCharset - Java Charset package includes GSM 03.38 support
http://www.freeutils.net/source/jcharset/

****************** 2 ***************************

Please take note of the different encoding types used when composing an SMS, and when it is received.
Information such as Mime Type, Encoding type, headers, URI, scheme
eg: MIME's base64 encoding
Notice the encoding changes when using SMS vs MMS