There seems to be an issue with the tropo module due to the fact that although the number will be parsed and saved cleanly in the smsframework, the number does not get properly formatted when pushed to the gateway.

While an input of XXXXXXXXXX will work, (XXX) XXX-XXXX will not.

"Sending SMS to (XXX) XXX-XXXX failed. The gateway said An error occured during the HTTP request:"

I've removed my token, and phone number.

DRUPAL_HTTP_REQUEST RESULT: stdClass Object
(
    [request] => GET /1.0/sessions?action=create&token=<token>&to=(XXX) XXX-XXXX&network=SMS&channel=text&message=Input%20confirmation%20code%3A%204108 HTTP/1.0
Host: api.tropo.com
User-Agent: Drupal (+http://drupal.org/)


    [data] => 
    [protocol] => HTTP/1.1
    [status_message] => HTTP Version Not Supported
    [headers] => Array
        (
            [Server] => Apache-Coyote/1.1
            [Date] => Fri, 15 Apr 2011 16:58:29 GMT
            [Connection] => close
        )

    [error] => HTTP Version Not Supported
    [code] => 505
)

It's odd, because the number shows up in the database properly (XXXXXXXXXX as opposed to (XXX) XXX-XXXX). Nevertheless, a workaround (and by no means a good one) Change lines 141-145:

function sms_tropo_send($number, $message, $options) {
	watchdog('sms_tropo','sms_tropo_send options:  <br />' . print_r($options,TRUE));
	$network = $options['network'];
  return sms_tropo_command('create', array('number' => $number, 'message' => $message, 'network' => $network));
}

to

function sms_tropo_send($number, $message, $options) {
	watchdog('sms_tropo','sms_tropo_send options:  <br />' . print_r($options,TRUE));
	$network = $options['network'];
	$number = preg_replace('~[^0-9]~','',$number);
  return sms_tropo_command('create', array('number' => $number, 'message' => $message, 'network' => $network));
}

In the end, it would be nice to have some validation on the number, but unfortunately my drupal api knowledge of the smsframework is not extensive enough nor is my understanding on US phone number lengths.

I would like to thank the maintainer on being so responsive. I sent him an email a few days back, and he fixed and commited the bugs I reported pretty much a few hours later.

Comments

akalsey’s picture

akalsey commented
Category: bug » feature

This is more of a feature request.

We can't strip all non-digits from numbers for a number of reasons. First, the module allows you to send to IM addresses and make voice calls.

Second, these are all valid numbers for SMS, and are equivalent to each other:

* 14155551212
* +14155551212
* tel:+14155551212

Third, since this module allows you to make voice calls, too, and to SIP addresses OR phone numbers, the following are valid "numbers".

* sip:alice@example.com (calls alice@example.com via SIP)
* tel:+14155551212;postd=1234pp56;pause=1000ms (This will dial 1234 one second after connecting to the phone number, pause for an additional 2 seconds (pp) and then dial 56)

So we actually need to strip non-digits only from SMS and voice calls that aren't sip. leading tel:+ and + should not be stripped, and anything following a ; should not be stripped.

I've added some experimental support for this in the dev branch. Test it out and see if it does what you need.

On the other question of validation, what did you have in mind? Figuring out if what someone entered could possibly be a phone number? Short of calling the number I'm afraid it's not quite possible to do reliably. Phone numbers worldwide range from 5 to 15 digits. And the number of digits and format doesn't provide any clues about where the number is located. You can make a guess that if someone enters a 10 digit number into a US-based applciation it's probably a US number, but unfortunately there are numbers from locations around the world that might also match that format when the country code is included.

Norway, for example uses 8 digit phone numbers and their country code is 47. So someone entering 4751234567 could mean a phone number in southern Norway or southwestern Connecticut.

john.karahalis’s picture

john.karahalis commented

Based on my understanding of this problem (please correct me if I'm wrong), I would consider this a bug and not a feature request.

The Phone number: form allows the user to submit his phone number in any format, but only the format 123456789 actually works. If he enters his phone number in any other format, the confirmation code is never sent and the error "Sending SMS to (XXX) XXX-XXXX failed" appears in the log.

I think this is what josefnpat is getting at when he talks about validation. If the system only works when a user enters a number in the form 123456789, the module should require that the user enter his number in this format.

By the way, I appreciate your being so responsive -- I rarely see Drupal maintainers follow up on issues so quickly. Thanks!

josefnpat’s picture

josefnpat commented

Coming from a European country, and living in america, I can totally understand how complicated phone numbers can be. But as you noted, there are some syntaxes that are acceptable and some that are unacceptable.

Since there is extra functionality in the system (i.e. the voice calling as such) perhaps it would make sense to have a separate field for each type of input, as opposed to one input and a select input that allows you to identify what kind of data it is. If it makes more sense to only allow one type of number/aim address/etc to be tethered to an account, have a validation form that is dependent on what the user selects as an input type.

For numbers, there could be regular expressions that could validate the phone numbers (perhaps something like /(tel\:|)[0-9]{5,15}/) and for aim addresses /[0-9a-zA-Z]{3,}/. I'm sure you know what I'm getting at here.

I'm not entirely sure of all the specifications of all the formats that you have, but you are right: We may be able to validate the syntax, but it's going to be rather difficult to determine if it is a functional number/aim address/etc, but I feel we should have at least some validation or at least parsing for users. sms-framework does it, perhaps (at minimum) we can do it for phone numbers?

akalsey’s picture

akalsey commented

I'm labeling it a feature request because a bug implies that something isn't working as intended. The fact that entering characters that don't actually exist in a phone number (and that SMS Framework somehow has no problem with this) results in an error doesn't qualify. Wanting the module to figure out what you probably meant is a feature request.

Regardless, the code to do this is now in the 2.x branch. To get it with git, you can do

git clone --branch 6.x-2.x http://git.drupal.org/project/sms_tropo.git

Or download a tarball from Github. https://github.com/tropo/sms_tropo/tarball/6.x-2.x

john.karahalis’s picture

john.karahalis commented

I still respectfully disagree. I am (mostly) fine with the module not accepting certain characters, but the module does not make the user aware of this and instead fails silently. Perhaps this is only an interface bug, but I do still think it's a bug.

edit: Maybe I'm confused. Is it the SMS Framework module that is allowing the user to enter invalid characters on the user registration page without warning?

Anyway, I certainly don't mean to bicker over little details. I really do appreciate that you have worked a fix into the 2.x branch.

We will be shipping an installation profile with 1.x included, so we will need to find a way to work this fix into that version. Do you have any suggestions that do not involve patching? (Drupal.org makes it difficult to patch modules in installation profiles.)

Thanks again.