Special chars issue for outgoing SMS

[herihaja]

The phone receives special characters incorrectly. eg:

• é is received as AC.
• à is received as A?A

It seems to be similar to the issue 332 but, I don't have any idea on where about the config can I specify data_coding.

[smn]

Can you possibly provide the output log of the SMPP transport?

[smn]

The reason for asking is that the source of this problem can be at 3 different places:

1. Vumi sending it incorrectly to the SMSC
2. The SMSC not handling the characters correctly after Vumi has handed them over.
3. The phone having trouble displaying the characters.

[herihaja]

This is a part of the log of the SMPP transport. I changed the phone number to xxxxxx to hide it:

2013-07-02 01:45:15+0000 [TopicSmppTransport,client] Sending SMPP, to: 26133xxxxxxx, message: u'y\xe9s' 2013-07-02 01:45:15+0000 [TopicSmppTransport,client] OUTGOING >>>> {'body': {'mandatory_parameters': {'priority_flag': 0, 'source_addr': '26133xxxxxxx', 'protocol_id': 0, 'replace_if_present_flag': 0, 'registered_delivery': 0, 'dest_addr_ton': 'unknown', 'source_addr_npi': 'unknown', 'schedule_delivery_time': '', 'dest_addr_npi': 'unknown', 'sm_length': 17, 'esm_class': 0, 'data_coding': 0, 'service_type': '', 'source_addr_ton': 'unknown', 'sm_default_msg_id': 0, 'validity_period': '', 'destination_addr': '26133xxxxxxx', 'short_message': 'y\xc3\xa9s'}}, 'header': {'command_status': 'ESME_ROK', 'command_length': 74, 'sequence_number': 4318471, 'command_id': 'submit_sm'}} 2013-07-02 01:45:15+0000 [TopicSmppTransport,client] SMPPLinkForm {'sent_sms': 163073, 'sequence_number': 4318471}

[smn]

So what I'm seeing is the following:

>>> print u'y\xe9s'
yés
>>> u'y\xe9s'.encode('utf-8')
'y\xc3\xa9s'

Your app is sending Unicode strings (good!) the SMPP transport is converting these to UTF-8 bytestrings when putting them on the wire to the SMSC (safe assumption).

What I'd recommend you do is check with your SMSC what character set they are expecting you to encode your SMPP submit_sm commands with. If that's not UTF-8 then that could be the problem. If it is UTF-8 then it's most likely a problem with the SMSC.

[jerith]

latin1 is another encoding commonly used by SMS providers. I'm not sure if we have a way to configure that in the transport, but it would probably be a good thing to add if we don't.

[smn]

With #332 and #619 landing my guess is this is resolved as well? Please confirm.

[smn]

@herihaja I'm closing this ticket due to lack of response. Please feel free to open this ticket again if this is still an issue.