Testing the SMS functionality in 4.2

[Laryn]

I've been trying to get SMS working in a local installation of the 4.2 branch and still having some difficulty (I currently have a support request in with Clickatell to see if it's something on their end).

In the meantime, here are a few notes I've jotted along the way:

• I edited the mobile number of a demo contact and found the SMS was trying to send to the home phone (marked primary) instead of the mobile phone
• The phone numbers will need some cleansing since they need to be in international format (at least for Clickatell) which means country code at the beginning (no + or spaces though), no parentheses or spaces or dashes within the number...otherwise we get an ugly white screen "ERR: 114, Cannot route message" error.
• I was curious (since we are working within such a small amount of characters) how inserting tokens will be calculated towards the character limit -- what happens if the token makes the message go over the limit?
• Is it possible to only show templates that are specific to SMS format? (the email templates are irrelevant to the SMS system)
• Can we make the errors cleaner and avoid the white screen? E.g. display them in a standard theme in a more pleasing way
• Is the plan to add SMS to more menus as well? (e.g. in a contact view > Activities tab, like sending email is currently allowed, and the main Actions button on a contact view)

[SarahG (FountainTribe)]

In regard to "The phone numbers will need some cleansing since they need to be in international format (at least for Clickatell) which means country code at the beginning (no + or spaces though), no parentheses or spaces or dashes within the number...otherwise we get an ugly white screen "ERR: 114, Cannot route message" error. "

Since most end-users of CiviCRM will probably not bother to put in a country code,  then the country code could be determined automatically either based on the home address of of the contact, or there could be a default country code for the whole database.

[totten]

Another question:

When composing a message, there's an option called "Invalid After". After grepping the codebase, I couldn't find what this does -- it appears that we pass it around as the "$smsParams[invalid_after]" and possibly "$header[invalid_after]" variables, but those variables don't seem to be used.

There is some explanation on the blog ( http://civicrm.org/blogs/mneimeyer/proto-civisms ) which describes it as an advanced feature in Clickatell, but I don't see how it can work if the variable isn't read. Has someone tested this? (I don't have a Clickatell account right now.)

[Barnacle]

The international phone number cleansing seems a significant problem.

Our site is UK specific so the solution was easier than it might have been. But I had to post-process the user registration form to strip the leading zero and add the UK country code (44) to the beginning of any number that was typed in that way.

This strikes me as a disparity between CiviSMS and Clickatell. CiviSMS automatically takes out the leading zero and passes it to Clickatell, but by then it's an invalid number. If the leading zero had been kept in then at least it would work locally.

I thought I should raise this as an issue since I don't think what presently happens is the best solution.

[Donald Lobo]

yes, i suspect civi will need to figure out and add code to "format" the numbers before sending them over to the SMS providers. Also we should check what phone format other SMS providers use.

For the short term, we'll need to assume folks use complete phone numbers and/or a DB hook/trigger to clean the phone numbers up.

Would really help if someone can help spearhead this improvement for a future release

lobo

[Deepak Srivastava]

When composing a message, there's an option called "Invalid After". After grepping the codebase, I couldn't find what this does -- it appears that we pass it around as the "$smsParams[invalid_after]" and possibly "$header[invalid_after]" variables, but those variables don't seem to be used.

Yep verified, these fields are not being used. Though they did help in shaping the sms code structure such that any additional api parameters could directly be sent from UI (form) to underlying api (provider->send()).

Filed an issue here to remove these fields - http://issues.civicrm.org/jira/browse/CRM-10584

[Deepak Srivastava]

This strikes me as a disparity between CiviSMS and Clickatell. CiviSMS automatically takes out the leading zero and passes it to Clickatell, but by then it's an invalid number. If the leading zero had been kept in then at least it would work locally.

Looked at the code and can't see it doing any extra stripping. Tried testing with such a number but couldn't reproduce.

Only place the stripping happens is during inbound call i.e when provider reports back. Have you tested this feature ?

[Deepak Srivastava]

Just an update: Issues raised here like - exposing sms to other places and sms being sent to phone type other than mobile, has already been fixed under - http://issues.civicrm.org/jira/browse/CRM-10498.

[Barnacle]

This strikes me as a disparity between CiviSMS and Clickatell. CiviSMS automatically takes out the leading zero and passes it to Clickatell, but by then it's an invalid number. If the leading zero had been kept in then at least it would work locally.

Looked at the code and can't see it doing any extra stripping. Tried testing with such a number but couldn't reproduce.

Only place the stripping happens is during inbound call i.e when provider reports back. Have you tested this feature ?

The reason I thought it was stripping the leading zero was that in the Clickatell report it showed attempts to send a text to '7123456789' instead of '07123456789' and these attempts failed due to malformed number. I assumed CiviCRM was giving the wrong number to Clickatell, but I guess it's also possible that Clickatell strips the leading zero. That would mean Clickatell expects the country code always to be there.

My needs are location-specific, but since I registered for a UK Clickatell account and sent to a UK number I expected this to work without issue. Is this supposed to work? Should I re-test?

I'm still on version 4.2-alpha3 if that makes a difference.

[Donald Lobo]

You should first upgrade before you do a retest

You should also play around and see what phone numbers clickatell accepts and rejects.

* with/without country code
* with/without non-numeric characters
etc

lobo

[petermcandrew]

We're running 4.2.4 on one of our sites and I'm finding that I'm able to send messages using the following pattern:
447123456789
+447123456789

but not:
+4407123456789 (ERR: 114, Cannot route message)
00447123456789 (ERR: 105, Invalid Destination Address)
07123456789 (ERR: 114, Cannot route message)

One of our clients would like to send SMS's to various numbers in different countries, so having a country attached to a phone field might be useful, in a similar way that you can specify the phone type you could also choose the phone country. 
Using the country from the address as Sarah suggests seems like a sensible default but there are a few cases where it doesn't hold up, such as someone having addresses in different countries, someone not having a country in their address.  Also when adding a phone number it wouldn't make much sense from the API and UI point of view to then have to go an add an address.  The country could also be defaulted to some value, so that its not an extra click for someone 'just adding' a phone number.

This might well deserve it's own thread but I thought I'd see if anyone has anything else to share.

Peter