Changed how return value of WaitForDigit is built

[webfrank]

WaitForDigit should return the pressed digit as result. Asterisk result value should be parsed as ASCII char.

[Ulexus]

Good find, thanks! I didn't realize "WAIT FOR DIGIT" used the return value as the DTMF value... that's particularly perplexing since DTMF can contain non-numeric characters. Never-the-less, the official documentation appears to agree with you.

Do you happen to know how non-numeric DTMF digits are presented in this case? Regardless, we do have the ResultString parameter (result as a string) stored to the Response structure, so we should use that rather than re-casting the integer Result.

[webfrank]

Hi, I'm not recasting Result, I'm returning, as per interface, a string. WAIT FOR DIGIT will encode as ASCII code the digits (* and # included) into result. I'm using this modified version with our software and is working flawlessly.

[Ulexus]

resp.Result is an int, parsed from the original string via strconv.Atoi(). resp.ResultString is the originally-received string. Thus, by calling string(resp.Result), you are re-casting the int as a string, rather than simply returning the already-stored string version.

[webfrank]

Hi, it's not the same, this is what is returned when pressing 1 (ASCII 49) and * (ASCII 42)
Result: %!s(int=49) - ResultString 49
Result: %!s(int=42) - ResultString 42

ResultString is the string representation of the number (49 for example) and Result is the int parsed from the string. Doing string(int) I'm not getting the string representation of int but the corresponding ASCII char.

If I press "" ResultString is "42", Result is 42 and string(Result) is "" which is the one I want returned.

Hope this is more clear

[Ulexus]

Oh, I see. It's returning the ASCII integer value of the received digit? How bizarre! Well, so be it, then. Thanks for the patch!