empty ussd response although dongle received data about asterisk-chan-dongle HOT 3 OPEN

Can provide +CUSD: string for both cases (ok decoding and failure) ?
differs in Data Coding Scheme ?



Bug may be here:
1) K3765  is not listed in at_response_cgmm() as seven_bit_modems
this mean cusd_use_ucs2_decoding and cusd_use_7bit_encoding unaffected by 
at_response_cgmm() for K3765

2) pvt_create() initialize cusd_use_ucs2_decoding = 1 and 
cusd_use_7bit_encoding = 0 (as ast_calloc do)

3) disconnect_dongle() reset cusd_use_ucs2_decoding to 0 instead of 1 

solution: 
1) reset cusd_use_ucs2_decoding and cusd_use_7bit_encoding to default before
look by seven_bit_modems in at_response_cgmm()

2) fix disconnect_dongle() for reset cusd_use_ucs2_decoding  to 1 and 
cusd_use_7bit_encoding to 0

please check r19 and report bug exist or resolved,
i has't K3765 

Applied r19 patch to at_response.c, but not to chan_dongle.c.
Stop, start, ussd now works as expected.

I'd suggest to revert the chan_dongle.c patch, it does not really make sense to 
set cusd_use_ucs2_decoding to 1 there, while setting all other values to 'sane 
uninitialized' values.
One might even argue that the
                pvt->cusd_use_ucs2_decoding     =  1;
line (1385) in chan_dongle.c, function pvt_create could better be set to 0 as 
well.
(Tried that and it works!)

Extra question: at+cscs is used to try setting overall/sms charset to ucs2, and 
response to at+cscs is used to set/not set pvt->use_ucs2_decoding. Does this 
have any relation to the ussd charset capabilities?