Sending USSD does not work

[marcogaio]

My operator (Wind, Italy) use extensively USSD, and worked in chan dongle original version, with asterisk 1.6/1.8.

Now (asterisk 11) does not work anymore. Example: eraldo*CLI> dongle ussd dongle0 *123# [dongle0] USSD queued for send with id 0x7f659401b790 [Apr 18 00:07:43] ERROR[3452]: at_response.c:517 at_response_error: [dongle0] Error sending USSD 0x7f659401b790

[wdoekes]

That particular error message gives hardly any info.

Could you get verbose+debug level (>=10) output? Perhaps it provides more clues.

[marcogaio]

I was just on verbose mode:

eraldo*CLI> core set debug 999
Core debug was OFF and is now 999.

eraldo*CLI> core set verbose 999
Console verbose was OFF and is now 999.

eraldo*CLI> dongle ussd dongle0 *123#
[dongle0] USSD queued for send with id 0x7fdcb401b790
    -- [dongle0] Error sending USSD 0x7fdcb401b790
[Apr 23 22:29:52] ERROR[3664]: at_response.c:517 at_response_error: [dongle0] Error sending USSD 0x7fdcb401b790

[wdoekes]

Are you sure you're the getting debug log in your console? I see the verbose logs, but I think there might be debug logs as well.

Check logger.conf please; perhaps the debug log is routed to a file instead.

[marcogaio]

Ahem, sorry... effectively i've disabled debug output. ;-(

[dongle0] USSD queued for send with id 0x7f75100157d0
[Apr 26 10:51:53] DEBUG[8352]: at_queue.c:126 at_queue_add: [dongle0] insert task with 1 commands begin with 'AT+CUSD' expected response 'OK' at tail of queue
[Apr 26 10:51:53] DEBUG[8352]: at_queue.c:246 at_queue_run: [dongle0] write command 'AT+CUSD' expected response 'OK' length 26
]Apr 26 10:51:53] DEBUG[8352]: at_queue.c:191 at_write: [dongle0] [AT+CUSD=1,"AA986C3602",15
[Apr 26 10:51:53] DEBUG[8340]: at_read.c:80 at_read: [dongle0] receive 9 byte, used 9, free 2039, read 0, write 9
[Apr 26 10:51:53] DEBUG[8340]: at_read.c:95 at_read: [dongle0] [
ERROR
]
    -- [dongle0] Error sending USSD 0x7f75100157d0
[Apr 26 10:51:53] ERROR[8340]: at_response.c:517 at_response_error: [dongle0] Error sending USSD 0x7f75100157d0
[Apr 26 10:51:53] DEBUG[8340]: at_queue.c:221 at_queue_remove_cmd: [dongle0] remove command 'AT+CUSD' expected response 'OK' real 'ERROR' cmd 1/1 flags 0x00 from queue
[Apr 26 10:51:53] DEBUG[8340]: at_queue.c:69 at_queue_remove: [dongle0] remove task with 1 command(s) begin with 'AT+CUSD' expected response 'OK' from queue

Thanks.

[marcogaio]

Some news on that? Still i cannot send USSD...

eraldo*CLI> dongle ussd dongle0 *123#
[dongle0] USSD queued for send with id 0x7ff084068400
[Jul 23 14:46:14] DEBUG[25977]: at_queue.c:126 at_queue_add:
    [dongle0] insert task with 1 commands begin with 'AT+CUSD' expected response
    'OK' at tail of queue
[Jul 23 14:46:14] DEBUG[25977]: at_queue.c:246 at_queue_run:
    [dongle0] write command 'AT+CUSD' expected response 'OK' length 26
]Jul 23 14:46:14] DEBUG[25977]: at_queue.c:191 at_write:
    [dongle0] [AT+CUSD=1,"AA986C3602",15
[Jul 23 14:46:14] DEBUG[4505]: at_read.c:80 at_read:
    [dongle0] receive 9 byte, used 9, free 2039, read 0, write 9
[Jul 23 14:46:14] DEBUG[4505]: at_read.c:95 at_read: [dongle0] [
ERROR
]
    -- [dongle0] Error sending USSD 0x7ff084068400
[Jul 23 14:46:14] ERROR[4505]: at_response.c:517 at_response_error:
    [dongle0] Error sending USSD 0x7ff084068400
[Jul 23 14:46:14] DEBUG[4505]: at_queue.c:221 at_queue_remove_cmd:
    [dongle0] remove command 'AT+CUSD' expected response 'OK' real 'ERROR' cmd 1/1 flags 0x00 from queue
[Jul 23 14:46:14] DEBUG[4505]: at_queue.c:69 at_queue_remove:
    [dongle0] remove task with 1 command(s) begin with 'AT+CUSD' expected response
    'OK' from queue

Thanks.

[wdoekes]

Well. I don't see anything wrong with the command there.

Like you may know, I don't own any GSM devices, so I cannot test any of this. But you can.

See this thread: https://stackoverflow.com/questions/30125721/how-to-write-a-atcusd-ussd-command-to-support-maximum-handsets

If AT+CUSD=1,"AA986C3602",15 doesn't work, then perhaps:

AT+CUSD=1,"*123#",15
AT+CUSD=1,"*123#",0
AT+CUSD=1,"*123#"
AT+CUSD=0,"*123#"

Or one of the other possibilities featured in the SO post. Possibly in combination with: https://stackoverflow.com/questions/29730142/error-on-checking-balance-via-ussd/29731461#29731461

Step one would be to find something that does work. When you do, we can look into whether it's feasible to implement.

[wdoekes]

I suspect that the problematic code is around here: https://github.com/wdoekes/asterisk-chan-dongle/blob/217daf4f5127e6892b6a62c2acf1aee17f554937/at_command.c#L417

[marcogaio]

No, i was not aware that you don't own a GSM dongle. ;-)

It is a bit strange. 'dongle cmd' seems to work:

eraldo*CLI> dongle cmd dongle0 ATI
[dongle0] 'ATI' Command queued for execute
 [dongle0] Got Response for user's command:'Manufacturer: huawei'
[Jul 24 22:28:37] NOTICE[4505]: at_response.c:1737 at_response: [dongle0] Got Response for user's command:'Manufacturer: huawei'
 [dongle0] Got Response for user's command:'OK'
[Jul 24 22:28:37] NOTICE[4505]: at_response.c:1737 at_response: [dongle0] Got Response for user's command:'OK'

But the command (every command in link you suggest) return strange things:

eraldo*CLI> dongle cmd dongle0 AT+CUSD=1,"*123#"
[dongle0] 'AT+CUSD=1,*123#' Command queued for execute
 [dongle0] Got Response for user's command:'ERROR'
[Jul 24 22:28:39] NOTICE[4505]: at_response.c:1737 at_response: [dongle0] Got Response for user's command:'ERROR'
[Jul 24 22:28:39] ERROR[4505]: at_response.c:521 at_response_error: [dongle0] Received 'ERROR' for unhandled command 'USER'S'

So, i've fired up minicom (a serial terminal emulation program) and tried to send command by hand, discovering that:

AT+CSCS="GSM"
AT+CUSD=1,"*123#",15

works as expected.

But still if i try to send command in dongle:

eraldo*CLI> dongle cmd dongle0 AT+CSCS=GSM
[dongle0] 'AT+CSCS=GSM' Command queued for execute
 [dongle0] Got Response for user's command:'ERROR'
[Jul 24 22:41:32] NOTICE[13743]: at_response.c:1737 at_response: [dongle0] Got Response for user's command:'ERROR'
[Jul 24 22:41:32] ERROR[13743]: at_response.c:521 at_response_error: [dongle0] Received 'ERROR' for unhandled command 'USER'S'

I hope i was useful...

[marcogaio]

Ahem, wrong cut&paste. Clearly, also with quotes:

eraldo*CLI> dongle cmd dongle0 AT+CSCS="GSM"
[dongle0] 'AT+CSCS=GSM' Command queued for execute
 [dongle0] Got Response for user's command:'ERROR'
[Jul 24 22:41:12] NOTICE[13743]: at_response.c:1737 at_response: [dongle0] Got Response for user's command:'ERROR'
[Jul 24 22:41:12] ERROR[13743]: at_response.c:521 at_response_error: [dongle0] Received 'ERROR' for unhandled command 'USER'S'

[wdoekes]

And what about:

AT+CUSD=1,"*123#",15

without first the AT+CSCS="GSM".

And what make is your dongle? Perhaps it needs to get dropped from list of devices where 7bit is selected:

                                                case CMD_AT_CGMM:
                                                        ast_debug (1, "[%s] Got AT_CGMM data (model info)\n", PVT_ID(pvt));
                                                        return at_response_cgmm (pvt, str);

Does it pass this?

And then here?

        static const char * const seven_bit_modems[] = {
                "E1550",
                "E1750",
                "E160X",
                "E150",
                "E173",
                "E1552",
                "E171",
                "E153",
                "E156B",
                "E1752",
                "E261"
        };

        ast_copy_string (pvt->model, str, sizeof (pvt->model));

        pvt->cusd_use_7bit_encoding = 0;
        pvt->cusd_use_ucs2_decoding = 1;
        for(i = 0; i < ITEMS_OF(seven_bit_modems); ++i)
        {
                if(!strcmp (pvt->model, seven_bit_modems[i]))
                {
                        pvt->cusd_use_7bit_encoding = 1;
                        pvt->cusd_use_ucs2_decoding = 0;

By default 7bit_encoding = 0 (and ucs2_decoding=1), but according to your encoded message it is set to 1.

So, unless it's one of those in the list, the encoding should be set to 7bit (no-hex).

        if (pvt->cusd_use_7bit_encoding)
                cusd_encoding = STR_ENCODING_7BIT_HEX_PAD_0;
        else if (pvt->use_ucs2_encoding)
                cusd_encoding = STR_ENCODING_UCS2_HEX;
        else
                cusd_encoding = STR_ENCODING_7BIT;

Please confirm by providing the relevant debug logs of the dongle initialization.

[marcogaio]

Yes, i've tried AT+CUSD=1,"*123#",15 without AT+CSCS="GSM" and does not work.

But you address me in the right way... i've had in the past trouble with SMS encodings, and someone (still you? i don't remember...) suggest to add my modem (a K3765) to seven_bit_modems[], and was still here.

I've removed my modem from 7bit ones, and now USSD works as expected!

Thanks and sorry!!!

[magcks]

According to 3GPP 27.007 and 3GPP 23.038, the DCS (always "15", "00001111" in binary in our case) means: bit 7..4 = 0000: "Language using the GSM 7 bit default alphabet" bit 3..0 = 1111: "Language unspecified"

(also see https://stackoverflow.com/a/30134921)

Thus, if I understood correctly, every Modem is a "USSD 7 bit modem" (if we set DCS to 15...). UCS-2 takes value 01001000 = 72. This should also fix #38 and bg111#231.

I assumed this in my not yet published upcoming PR, as I had to rewrite the CUSD parts because the character encoding code changed. Can somebody confirm this assumption?

[standardgbg]

Hi,

Are there any solution to this? I've tried a lot of USSD commands but still get "at_response.c:1386 at_response_cusd: [dongle0] Error decode CUSD: " followed bu the correct that I can decode with a online PDU decoder. My next move is to remove the E1750 from seven_bit_modems[]. The modem is reporting support for 7 bit encoding: USSD use 7 bit encoding : Yes USSD use UCS-2 decoding : No

I cant find the modem list in "at_command.c". Has it been moved to some other file?