Handling multi-line USSD responses

[davidjb]

I've been playing around with USSD responses using the GsmModem class and I've found that multi-line USSD responses are handled as individual lines. For instance, an (unsolicited) +CUSD response can look something like this (a live example from Telstra in Australia):

AT+CUSD=1,"#100#",15
OK

+CUSD: 1,"Bal:$100.00 *
Exp 01 Jan 2013
1. Recharge
2. Balance
3. My Offer
4. PlusPacks
5. Tones&Extras
6. History
7. CredMe2U
8. Hlp
00. Home
*charges can take 48hrs",15

gets handled as a set of individual lines rather than as one response together. Each of the lines are seen (at least at the Python later) as being \r\n separated.

In addition, because none of the lines match the prescribed regex for USSD, no response gets returned from the call to sendUssd (despite a USSD session now existing).

Thoughts on being able to support responses like this? The v.250 standard seems to say that any characters may be included in a string and should be represented using a backslash and their character code.

So far, I've worked around the issue by just joining all the lines together in a custom _handleUssd method, and dividing up again based upon some modified regex to get each +CUSD response separately (eg re.findall('\+CUSD:\s*\d,".*?",\d+', joined_lines, re.DOTALL)). Hacky, but it works for now.

This is a fantastic library, by the way - greatly appreciate all the hard work. Works a treat with my ZTE K3571-Z modem.

[faucamp]

Thanks for the detailed report, and my apologies for the long delay in responding - just started a new day job so things have been a bit busy. :) Interesting USSD response - similar responses on the South African networks do not terminate lines with \r\n, opting for simple \n instead; however this could also be ZTE-specific (although I doubt it). I'll add it to the test cases right away and provide a patch.

[faucamp]

Fixed in 6a5cb24361d4fdbd82a5844923e1b746a38c106b.

This is based on your workaround, thanks - other alternatives ended up being too long-winded or required too much invasive change in the serial comms subsystem.

Thanks again for the detailed report, it is much appreciated. Please feel free to re-open this if you feel it is not resolved.

[davidjb]

Super - thanks for getting back to me and adding the fix into the package. I'll test it with my existing code tonight and see what happens.

I think I have another modem (Huawei) that I can test this with as well to confirm whether the response line endings are from my network, or device/manufacturer specific. I'll see what happens - I'm very curious now. Interesting to learn about different cellular networks operating differently - though I suppose it's no different than Mac/Windows/Unix formatted text and line endings.