Jump to content

Receiving SMS with Quest Blue


Recommended Posts

We recently updated to 68.0.12 version, latest. That fixed SMS sending in general. There are two issues that we do not know how to solve:

1. How to configure each tenant for sending with their own ANI?

2. How can each tenant get a response? 

I look through documentation but cannot find anything that will help me on these two topics.. Thanks, Dusan

Link to comment
Share on other sites

There is a setting for each tenant in the domain settings that defines the default ANI for that tenant. That should solve that problem. For inbound routing, you need to assign the SMS DID to an extension or to a queue, so that the system knows where to send the request.

Link to comment
Share on other sites

Ok, jere is what I get from the log:

7] 22:28:54.040

Provisioning without domain context

[9] 22:28:54.040

Tried to match recvsms

 

[8] 22:28:54.040

Receive SMS

{"from":"5404611989","to":["5406003047"],"text":"One more time","media":[],"segments":"1","type":"SMS"}

[8] 22:28:54.040

Using system settings for SMS provider questblue and user xxxxxxxxx

[8] 22:28:54.040

QuestBlue: Receive JSON to 5406003047

[8] 22:28:54.040

Receive SMS from 5404611989 to 5406003047 with text content One more time

[3] 22:28:54.040

SMS from 5404611989 to 5406003047 could not be delivered to an account

So what do I have wrong? 

Link to comment
Share on other sites

The problem is that 5406003047 is not +15406003047. It seems that when we were testing this, QuestBlue was sending this with the +-format, but in your case not. We'll add something that automatically converts it into the global notation (it would be easier if everyone just sends phone numbers in global notation). If you can it would be great if you can check if it is fixed in 68.0.13.beta so that we can include it in the 68.0.14 build.

Link to comment
Share on other sites

  • 2 weeks later...

Hello again, back on this topic. This is still not working correctly, at least what was described in one of the previous answers. Multiple extensions cannot receive inbound messaging if they are in the agent queue. Also, In my attempt to finally resolve these issues I tried updating to 68.0.14 last night. Unfortunately the link on the site downgrades you to .0.04. even though that the release notes talk about .0.14. This getting very frustrating since we wasted a lot of time on this issue. Would you please be so kind to keep announcements current with correct links to the latest version. I think all of your users would appreciate this, thank you.

Link to comment
Share on other sites

The SMS routing is different than the call routing. Right now you can route a SMS either to the extension (through the extensions SMS ANI) or to an agent group. In an agent group, because agents can be logged in or not, things can get confusing when a message is received. The idea is that they work as a team and take over the conversation with a specific number, including the chat history. 

What link did you use for the 68.0.14 version? 

Link to comment
Share on other sites

When we were testing 68.0.13 beta we had agent group created.  Only the extension who had an ANI originally assigned to it would receive the incoming text, the other extension in the agent group would not.  I even sent a log of that change to the support. 

So either I am not understanding the Agent group or it is not working the way it was meant to work.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...