Problema de envio de SMS para información transacciones a usuarios

Problema de envió de SMS para información transacciones a usuarios.

En los los último tiempos me he dedicado a crear programas que permitan la captura de información desde dispositivos móviles desde datos muy simples como un simple ID de identidad y un valor  hasta planillas completas de información ingreso de personal y manejos de ventas y controles automáticos  , hechos desde Galaxy, pasando por Blackberry y los mas sencillos celulares tipo Nokia CE-01, desde luego la captura de la información reviste sus problemas propios, como son el de acomodar tanta información en pantallas tan pequeñas, usar o no medios de comunicación directa o web-service, usar la interface correcta dependiendo del móvil y detectar este, y un largo etc, pero en este documento quiero tocar algunos temas que me traían de cabeza relacionados no con los programas en si, ni como capturar al información , sino al enviar la información necesaria de confirmación por ejemplo al cliente,y que encontré la solución de carambola , pues por lo menos los asesores de las compañías de celular no sabían darme respuesta a los interrogantes.

Tenía como premisa en el envió de los mensajes básicamente 2 cosas:

1. La longitud máxima de un mensaje SMS es de 160 caracteres
2. Los caracteres que se pueden enviar sin problema son los caracteres ASCII.

Estas premisas firmadas y re-confirmadas por las compañías de celular de mi país (Colombia), y por las compañías que prestan los servicios de envió de mensajes SMS masivos.

Craso error que me costo no solo dinero, sino tiempo y trasnochadas.

Se generaban lo siguientes problemas:

1. Perdida de mensajes, simplemente no llegan al usuario
2. Se truncaban los mensajes
3. Llega de mensajes repetidos o incompletos
4. Llega de mensajes con información distorsionada (aveces solo lo caracteres iniciales, algunos del centro o solo los finales)
5.Liquidación errática del costo  envió de SMS a los celulares del doble o triple de lo esperado según los mensajes contabilizados y revisados una y otra vez.
6. Unos llegan casi instantáneamente y otros los de Comcel (ahora Claro) te puedes ir a tomar un tinto y fumarte un cigarrillo y llegan cuando ya no se usa.
7. Los celulares de alta gama son los que menos mensajes reciben (los que mas fallan en la recepción)

Y lo mas desesperante es que el comportamiento es errático ,  unos celular nunca ponen problema. a otros nunca les llega , los de una Claro (Comcel) ponen mil problemas los de Movistar casi nunca fallan , los de Tigo unos si y otros no, es en verdad desesperante y nadie te sabe dar razón, de un un miserable mensaje  de 160 caracteres si por Internet mandas una pastoral de varios gigas y no pasa nada , no se pierde ni una coma.

Pues bien como dije encontré la respuesta buscando otra cosa relacionado con lo caracteres permitidos en las bases de datos postgresql  con campos para almacenar imágenes, allí el autor, que Dios lo bendiga, decía muy de paso que  había que configurar la base datos para que permitiera carateres UTF-8/UNICODE y que si las imágenes venían de un celular este también tenia que estar configurado de esta forma si el celular lo permitía pues mucho fabricante americano usa el set por default GSM 03.38 y los Europeos el UNICODE.

No decía mas pero esto prendió un bombillo en mi cabeza, que a estas alturas estaba mas oscura que una noche sin luna y me fui a ver que era el famoso estándar por defecto GSM 03.38 de caracteres para celular.

Y,  ohhh sorpresa.

Resulta que no todos los celulares  manejan el famoso ASCII, con 256 caracteres , sino un set de 138 caracteres básicamente los caracteres que se pueden presentar con 7 bit y algunos especiales que se pueden conformar con caracteres de escape <ESC>, estos son en mayoría Americanos, los Europeos (de tecnología no de fabricación que no es lo mismo) maneja el UNICODE.
Algunos tiene forma de ajustarlos para que reciban y envíen UNICODE, y reciben los mensajes bien, pero el problema es que incluso celulares de la misma referencia unos lo traen, otros permiten configurarlo y oros simplemente no lo traen.

Esta bobadita implica:

1. Que si envías un carácter que no esta en el Set GSM 03.38 reconocido por el celular , este simplemente no lo ve, humm. o ve lo que cree y muestra pedazos del mensaje.

Por ejemplo: [Hola Mundo] es probable que no sea visto mientras que (Hola Mundo) si,
porque [ ]  son caracteres especiales UNICODE, mientras que () son estándar.
Ver tablas al final del documento.

2. Las plataformas de celular tratan de ajustar el cuento de la forma mas simpática,  simplemente
convierten el GSM 03.38 a UNICODE,  y los 160 caracteres se vuelven 70, ya que la representación UNICODE  necesita 3 caracteres para desplegarse, pero como la plataforma corta a  70, el mensaje llega totalmente distorsionado si llega, pues al truncarlo en algunos casos el celular ni sabe que fue lo que llego, pero eso no es todo, la compañía  toma el mensaje de 160 y los divide en (70+70+20) y te cobra 3 mensajes de SMS , lindos no, como para enmarcar. Claro no, ejem , COMC EL.

Bueno es obvio que la mayoría de los problemas se respondieron solos sabiendo el cuento, pero que pasa con la demora, eso si me lo dijeron en CLARO (COMCEL), me toca creer hasta que se demuestre lo contrario como me paso con los caracteres , pues  TIGO y MOVIESTAR usan un CARRIE local , mientras CLARO usa el CARRIE internacional, en palabras  del funcionario que me dio la explicación,"Si le envías un mensaje a la esposa que esta tu lado, el mensaje se despacha hacia Inglaterra donde esta el CARRIE internacional y regresa , mientras que el de MOVIESTAR, va  la repetidora mas cercana y regresa".

Porque hace ese recorrido el de CLARO, no se, "Doctores tiene la santa madre iglesia, que son los que saben"

Gracias infinitas a este link 

http://www.csoft.co.uk/sms/character_sets/gsm.htm
http://www.csoft.co.uk/sms/character_sets/encoding.htm

The GSM 03.38 Default Character Set

Dec		0	16	32	48	64	80	96	112
	Hex	0	10	20	30	40	50	60	70
0	0	@	Δ	SP	0	¡	P		p
1	1	£	_	!	1	A	Q	a	q
2	2	$	Φ	"	2	B	R	b	r
3	3	¥	Γ	#	3	C	S	c	s
4	4	è	Λ	¤	4	D	T	d	t
5	5	é	Ω	%	5	E	U	e	u
6	6	ù	Π	&	6	F	V	f	v
7	7	ì	Ψ	'	7	G	W	g	w
8	8	ò	Σ	(	8	H	X	h	x
9	9	Ç	Θ	)	9	I	Y	i	y
10	A	LF	Ξ	*	:	J	Z	j	z
11	B	Ø	<ESC>	+	;	K	Ä	k	ä
12	C	ø	Æ	,	<	L	Ö	l	ö
13	D	CR	æ	-	=	M	Ñ	m	ñ
14	E	Å		.	>	N	Ü	n	ü
15	F	å	É	/	?	O	§	o	à

Some additional characters can be sent using the <ESC> code in the above table plus an additonal character

Sending additional characters on GSM phones

You want to send ASCII				Send the following
Character	Decimal	Hex		Characters	Hex	Decimal
€				<ESC> e	1B 65	27 101
<FF>	10	0C		<ESC> <LF>	1B 0A	27 10
[	91	5B		<ESC> <	1B 3C	27 60
\	92	5C		<ESC> /	1B 2F	27 47
]	93	5D		<ESC> >	1B 3E	27 62
^	94	5E		<ESC> ^	1B 14	27 20
{	123	7B		<ESC> (	1B 28	27 40
|	124	7C		<ESC> @	1B 40	27 64
}	125	7D		<ESC> )	1B 29	27 41
~	126	7E		<ESC> =	1B 3D	27 61

This table shows the default GSM character set, but does not indicate how to encode the characters when you wish to send them in an HTTP POST message. See Character Encoding for that information.

haracter Description Encode as CR Carriage Return %0D LF Line Feed %0A SP Space %20 " quotation mark %22 # hash %23 % percent %25 & ampersand %26 , comma %2C . period %2E / forward slash %2F : colon %3A ; semi-colon %3B < less than %3C = equal %3D > greater than %3E ? question mark %3F ¡ inverted exclamation mark %A1 £ Pound %A3 # currency sign %A4 ¥ Yen %A5 § paragraph sign %A7

Character Description Encode as Ä capital A with diaeresis %C4 Å capital A with ring %C5 à small a grave %E0 ä small a with diaeresis %E4 å small a with ring %E5 Æ capital diphthong AE %C6 Ç capital C cedilla %C7 É capital E acute %C9 è small e grave %E8 é small e acute %E9 ì small i grave %EC Ñ capital N with tilde %D1 ñ small n with tilde %F1 ò small o grave %F2 ö small o with diaeresis %F6 Ø capital O with storke %D8 Ö capital O with diaeresis %D6 Ü capital U with diaeresis %DC ù small u grave %F9 ü small u with diaeresis %FC ß small s sharp %DF

The characters shown below cannot be sent to mobile/cell phones unless those phones support Unicode. Most European and American phones don't support Unicode. Character Description [ left square bracket \ back slash ] right square bracket ^ caret ` grave accent { left curly brace | pipe or vertical bar } right curly brace ~ tilde DEL Delete