Incorrect 7-bit encoding in 'char_to_hexstr_7bit' and incorrect responces decoding

[GoogleCodeExporter]

chan_dongle can never successfully send any USSD 7 bytes length due to improper 
encode in function 'char_to_hexstr_7bit'.

What steps will reproduce the problem?
1.
Send any USSD 7 bytes length, for example: *101*4# 
2.
Network reply always will be +CUSD: 2 (terminated by network)

Next part difficult to reproduce. Sometime I receive USSD replies from my 
operator (MTS UKR) in following format: +CUSD: 0,"<7-bit encoded data>",1. In 
this case, chan_dongle fails with error decode message. This happens because in 
at_response_cusd message can only decoded as 7-bit-encoded if dcs=0 or 15. In 
my case dcs=1, and at_response tries decode message as UCS2 and fails.

I using chan_dongle-1.1.r14

I changed code of corresponding functions for solve these problems.
See attachment below.

Best regards, Alexey Prokopchuk.

Original issue reported on code.google.com by alexpro....@gmail.com on 4 Nov 2012 at 12:45

Attachments:

• chan_dongle-7bit-fix.patch

[GoogleCodeExporter]

Operator can send and  DCS for USSD response, i think include 'dcs == 1' for 
STR_ENCODING_7BIT_HEX can solve problems only locally.

7bit padding  in char_to_hexstr_7bit on road 

Original comment by bg_...@mail.ru on 21 Nov 2012 at 8:33

• Changed state: Accepted

[GoogleCodeExporter]

I Have the same problem - ussd request *101*4# (MTS UKR) returns an error
Include dcs == 1 not solve the problem
But patch helps me. I confirm that the patch works. Thank you so much, 
Alexander. Tell how to thank you.

Original comment by joeman.6...@gmail.com on 30 May 2013 at 10:44

[GoogleCodeExporter]

I Have the same problem
this patch is also working for me .thank you so much    for patch

Original comment by shabbira...@gmail.com on 14 Sep 2013 at 5:27

[GoogleCodeExporter]

Issue 140 has been merged into this issue.

Original comment by bg_...@mail.ru on 20 Oct 2013 at 11:37