retain original caller id on Call transfer on asterisk - asterisk

I am running a B2C outbound Campaign on VicidialNow C.E 1.1 as Asterisk Server / SIP Server.
The call is made from server to customer and connected to agents waiting for calls. The agents transfers the call to third party (not a blind transfer). The 3rd party sees the Caller ID of agent.
Now, what I want is to display the caller id or the phone number of the customer to the 3rd party.
I Googled and searched over SO, found this sendrpid=pai to add on sip.conf file. but this functionality only supports on 1.4 or upgraded version.
scenario:
Agent calls the Customer's phone ex 12123344 and call is received. Agent puts Customer on hold and dials Mr XX, another phone number (not the extension of sip server) ex 21214433. The conference call is made(customer, agent and Mr. XX are in conference). I want Mr. XX to see the Customers Number asap the Customer is Connected to the conference.

Capture the incoming CID information into a channel variable when the call first comes in:
exten => foo,1,Set(ORIG_CID=${CALLERID(all)})
... then set the CID just before you dial to be the contents of the channel variable.

Related

How can I start a conference call on GSM network?

I need to make a conference voice call on GSM network.
The maximum I have seen in the datasheet is that the command AT+CLCC can report a list of current calls of ME automatically when the current call status changes.
How can I make conference calls with a SIM800L? I have 2 phone numbers for call.
The key command for the feature you are asking for is AT+CHLD (Call Holding Services). It is important to say that this is well known GSM Supplementary Service, and since AT+CHLD is a standard command it is a feature that is likely to be supported by all cellular modems, not only SIM800.
The main constraints that any user must know are:
It is a service strictly related to VOICE calls
The network operator must support this service as well
ETSI Specifications about multi-party calls
Though it may appear as a boring introduction, we need to build our procedure on solid basis. Feel free to skip this paragraph if you are just interested in the AT commands sequence.
ETSI specification TS 127.007 v15.3.0 describes its behaviour at chapter 7.13: "Call related supplementary services +CHLD":
This command allows the control of the following call related
services:
a call can be temporarily disconnected from the MT but the connection is retained by the network;
multiparty conversation
(conference calls);
the served subscriber who has two calls (one
held and the other either active or alerting) can connect the other
parties and release the served subscriber's own connection.
A further document related to MPTY calls is then referenced : 3GPP TS 22.084 (that can be found here. Another interesting source is ETSI 300 954 which states
The served mobile subscriber A may initiate an active MultiParty call
from an active call C and a held call B.
This means that we can obtain a conference call just by adding held calls to active calls.
AT Commands procedure
From the previous documents we can deduce that the following steps will setup a multi-party call:
Start a voice call with one of the parties by issuing ATD<number>;, or answer to an incoming call with ATA
Put on hold the first call by issuing AT+CHLD=2 (well supported by your SIM800, that for +CHLD=2 states "Place all active calls on hold (if any) and accept the other (held or waiting) call.").
Start a call with the third party
Start the multiparty by issuing AT+CHLD=3 (well supported by your SIM800, that for +CHLD=3 states "adds an held call to the conversation.").
About AT+CLCC
The command you mentioned in the question is not directly responsible for starting a multiparty conversation, but it is someway related to it. In fact, it is able to list the status of all the active calls.
Execution command AT+CLCC provides the following answer:
[+CLCC: <id1>,<dir>,<stat>,<mode>,<mpty>[,<number>,<type >,<alphaID>]
[<CR><LF>+CLCC: <id2>,<dir>,<stat>,<mode>,<mpty>[,<number>,<type>,<alphaID>]
[...]]]
OK
We will linger on just two relevant parameters:
<id N> is the ID of the Nth call. It is relevant because many options of +CHLD command allow to selective hold/release an X call, and this ID it is required in order to specify X in the command. All these options, not mentioned in the this answer, can be useful in order to select correctly the call to be added in the multiparty conversation.
<mpty> is the multiparty call flag, and if it is set to 1 it means that the call is one of multiparty (conference) call parties.

asterisk queue_log late COMPLETEAGENT

I am trying to write a wallboard for my asterisk server. This wallboard will process the queue_log file in /var/log/asterisk.
Here is a scenario in question:
1) A customer calls out call center. Let his number be 44556677889900 and our number 8881234567890.
2) The customer enters the queue 210.
3) Agent 1 takes the call.
4) Agent 1 decides that the call should go to another queue. And transfers it to queue 209
5) Agent 2 takes the call.
6) Agent 2 terminates the call after talking with the customer. (When Agent 2 is talking on the phone Agent 1 is idle and available for a new call.
7) Normally Agent 1 ended his call at 4th step, but the log with COMPLETEAGENT appears just now, even the agent is available since 4th step
Here is the output in the queue_log:
1550582529|1550582516.26480|210|NONE|DID|8881234567890 * 1. step*
1550582529|1550582516.26480|210|NONE|ENTERQUEUE||44556677889900|1 * 2. step*
1550582531|1550582516.26480|210|Test Agent 1|CONNECT|2|1550582529.26493|2 3. step
1550582536|1550582536.26498|209|NONE|DID| ** 4. step**
1550582536|1550582536.26498|209|NONE|ENTERQUEUE||9991|1 4. step
1550582539|1550582536.26498|209|Test Agent 2|CONNECT|3|1550582536.26499|2 5. step
1550582543|1550582536.26498|209|Test Agent 2|COMPLETECALLER|3|4|1 6. step
1550582549|1550582516.26480|210|Test 1|COMPLETEAGENT|2|18|1 7. step
As mentioned in the 7th step, Agent 1 if available for new calls after he transfers the call to queue 209. (In fact if a new call comes, the system send the call to Agent 1). However the log "COMPTELEAGENT" appears only when the customer disconnects.
This makes my wallboard think that Agent 1 is busy even he is not. And worse if he received a new call before Agent 2 finishes, everything gets more complicated.
Questions:
1) How it is possible to make the system send the COMPLETEAGENT at step 4 ?
2) Why is ATTENDEDTRANSFER log missing ? (Not related to this problem directly but can also be connected)
Asterisk Version: 13.22.0
Freepbx 14.0.5.25
Thank you in advance.
1) System should not send COMPLEATEAGENT at 4, becuase thoose event should be sent AFTER END of call.
That event is created by QUEUE, not by AGENT. From queue's point of view call not yet finished.
If you want it be finished, do transfer of LEGA, not queue's LEG.
2)Transfer subsystem not related to queue subsystem and SHOULD NOT be related in any realible PBX. You can write your own if you want.
Side notes
no point parse queue_log, much simpler setup queue_log in mysql or other db and read it.
you can write your own queue system using Async AGI.
you can add as many logs as you want by using dialplan CEL or UserEvents.

Asterisk 13.22.0 - No channel type registered for 'Agent' when queue rings

With the below config, I just keep gettings this in the Asterisk 13.22.0 CLI:
WARNING[15872][C-00000051]: channel.c:6343 ast_request: No channel type registered for 'Agent'
whenever a caller gets sent to that agent queue with logged in agents waiting for calls on Asterisk 13.
3997 and 3998 are my two agents. They can call each other and receive calls from other extensions. They can phone out of my PBX, no problems.
My agents.conf:
[agents](!)
autologoff=15
wrapuptime=5000
custom_beep=beep
[3997](agents)
fullname=>AGENT 1
[3998](agents)
fullname=>AGENT 2
My queues.conf:
[testq]
musicclass = default
strategy = leastrecent
timeout = 10
retry = 5
autofill = yes
member => Agent/3997,0,3997,hint:3997#default,no
member => Agent/3998,0,3998,hint:3998#default,no
Also, setting ringinuse on (change member line above to have "yes" at the end) has no effect except to make the error "No channel type..." appear twice in the 13.22.0 CLI per external ring heard by caller, instead of once per external ring if ringinuse is set to "no" in the two lines above.
Logging in an agent in extensions.conf is done by:
exten=>1007,1,NoOp(Login agent from ${CALLERID(num)})
same=>n,Set(MONITOR_OPTIONS=b)
same=>n,UnpauseQueueMember(,Agent/${CALLERID(num)})
same=>n,AgentLogin(${CALLERID(num)},s)
Queue show with agents logged in:
localhost*CLI> queue show
testq has 0 calls (max unlimited) in 'leastrecent' strategy (0s holdtime, 0s talktime), W:0, C:0, A:16, SL:0.0% within 0s
Members:
3997 (Agent/3997 from hint:3997#default) (ringinuse disabled) (In use) has taken no calls yet
3998 (Agent/3998 from hint:3998#default) (ringinuse disabled) (In use) has taken no calls yet
No Callers
localhost*CLI>
Then, if the queue is called from outside:
localhost*CLI> queue show
testq has 1 calls (max unlimited) in 'leastrecent' strategy (0s holdtime, 0s talktime), W:0, C:0, A:16, SL:0.0% within 0s
Members:
3997 (Agent/3997 from hint:3997#default) (ringinuse disabled) (In use) has taken no calls yet
3998 (Agent/3998 from hint:3998#default) (ringinuse disabled) (In use) has taken no calls yet
Callers:
1. SIP/3916-00000055 (wait: 0:08, prio: 0)
3916 is never answered, and neither 3997 or 3998 receive the call, both continuing with MOH indefinitely.
Constantly on the CLI this comes up, timed with each ring of 3916 (the "outside" phone):
taken no calls yet
Callers:
1. SIP/3916-00000055 (wait: 0:08, prio: 0)
localhost*CLI>
[Aug 2 10:37:39] WARNING[16925][C-00000056]: channel.c:6343 ast_request: No channel type registered for 'Agent'
[Aug 2 10:37:44] WARNING[16925][C-00000056]: channel.c:6343 ast_request: No channel type registered for 'Agent'
[Aug 2 10:37:49] WARNING[16925][C-00000056]: channel.c:6343 ast_request: No channel type registered for 'Agent'
What am I doing wrong?
The expectation is that either 3997 or 3998 will receive the incoming call placed by SIP/3916. As of now, 3916 rings forever, and 3997 and 3998 just play MOH forever, with the above error emitted with each ring heard on 3916 / externally.
Thanks!
Stefan
Found the solution for this...!
https://wiki.asterisk.org/wiki/display/AST/New+in+12#Newin12-channels_chan_agent
and
https://reviewboard.asterisk.org/r/2657/diff/1/
and
https://blogs.asterisk.org/2016/02/10/converting-from-chan_agent-to-app_agent_pool/
clarifies the situation. After Asterisk 12, chan_agent was removed from Asterisk.
It has been replaced with the AgentRequest application.
So I had to adapt my previously posted configs as follows to get queued agents working and answering incoming calls to the queue.
My agents.conf stayed unchanged from my original post.
My queues.conf had to change from my original post to:
member=>Local/3997#internal,,3997,Agent:3997
member=>Local/3998#internal,,3998,Agent:3998
with the rest of the queue settings remaining the same.
The agent login extension had to change to:
exten=>1007,1,NoOp(Login agent from ${CALLERID(num)})
same=>n,Set(MONITOR_OPTIONS=b)
same=>n,UnpauseQueueMember(,Local/${CALLERID(num)}#internal)
same=>n,AgentLogin(${CALLERID(num)},s)
In my [internal] context (where my phones live - including my test phones 3997 and 3998) I had to add extensions that would call the AgentRequest() dialplan application on each of them if that extension was dialled. This is effectively how the queue is answered:
[internal]
.
.
.
exten=>3997,1,AgentRequest(3997)
same=>n,Hangup()
exten=>3998,1,AgentRequest(3998)
same=>n,Hangup()
.
.
.
Then I set up a testing extension in [internal] called '48' that would trigger the queue and let me test:
[internal]
.
.
.
exten=>48,1,NoOp(Sending test call to testq)
same=>n,Queue(testq,trhc)
.
.
.
So, my test procedure was:
Phone 1007 on phone 3997 (1007 - see my original post - is my agent login extension that calls AgentLogin on the dialing extension.) This logs me into the queue 'testq' as Agent 3997.
Phone 1007 on phone 3998. This logs me into the queue 'testq' as Agent 3998.
Phone 48 from any other phone, which calls the Queue application on the testq, which is defined in queues.conf as consisting of agents / phones 3997 and 3998.
Due to my queue being set to " strategy = leastrecent" on repeated calls to extension 48, either 3997 or 3998 would pick up calls made.
This is exactly the functionality desired and I now have a working model of Agent queues in Asterisk 13 using the new (to me) app_agent_pool interface via AgentRequest instead of trying to use "chan_agent" which no longer exists post Asterisk 12.
All that is now needed is to GOTO from my incoming extension to local,48,1 or simply do Queue(testq,trhc) from my incoming extension directly. If I have logged in agents in the testq queue, the most least recently dialled agent will get connected to the caller.
Maybe this helps someone transition from a pre Asterisk 12 to Asterisk 12 or higher.
Kind regards,
Stefan

RingOut and call log results are not useful (when the call is not answered by a human)

When making a RingOut call between two PSTN phone numbers, RingCentral does not report the call outcome when the callee's phone goes to voicemail or to the "subscriber is unavailable" message or the callee hangs up.
In the cases I have tested the call outcome is always "Success" when doing a get request to the RingOut API endoint /restapi/v1.0/account/~/extension/~/ringout/###.
When querying the call-log or the active-calls endpoint, with the ?view=Detailed parameter the results is always "Call connected" for the whole call and the callee's leg of the call.
My question is how do I determine if the callee's phone:
Went to Voicemail.
They hang up.
They weren't able to answer because of a network issue.
Basically how do I know if a human answered the phone or not?
In order to determine if a call goes to Voicemail, this requires ADM (Answering Machine Detection) which is a functionality of call-center softphone which handles auto-dialing.
RingCentral offers this functionality through the Contact Center product (https://www.ringcentral.com/contact-center/contact-center-features.html). If you need this type of functionality, please contact your RingCentral Account Executive to discuss your needs.
Here is a set of documents which provide greater detail on these deterministic values for RingOut using the API: http://developing-with-ringcentral.readthedocs.io/en/latest/making_calls/#making-a-call

How to send a text from the user's cell phone number using Twilio?

I want to programatically send SMS / text messages from my Meteor app; many people recommend twilio for this, and there are several Meteor Twilio packages (findable via atmosphere and/or googling/binging). I don't know if one of these packages is decidedly better than the other, but for now, at least, I'm using the abhiaayer:meteor-twilio package.
My concern is that, when you create a Twilio account, they assign you a "from" phone number (you can't, apparently, just use your own). Maybe I'm misunderstanding how this works, but before I go too far down this path, I want to know if the sender of the SMS -- IOW the user of my app -- will be able to use their phone number as the "from"/sender phone number.
After all, the whole point of my app is to allow the user to send out multiple identical texts (such as "where are you?" or "are you okay?") to friends/family, and then get a response back from them (to his phone, not to a Twilio-supplied number).
If it's possible to use Twilio with your own phone number as the "from"/sending number, has anyone got suggestions on Meteor package preferences (abhiaayer, andreioprisan, DispatchMe) and how that can be accomplished from Meteor?
I imagine the basic code would be pretty much the same, regardless of package used; e.g., here's an example from the andreioprisan package
twilio = Twilio(ACCOUNT_SID, AUTH_TOKEN);
twilio.sendSms({
to:'+16515556677', // Any number Twilio can deliver to
from: '+14506667788', // A number you bought from Twilio and can use for outbound communication
body: 'word to your mother.' // body of the SMS message
}, function(err, responseData) { //this function is executed when a response is received from Twilio
if (!err) { // "err" is an error received during the request, if any
// "responseData" is a JavaScript object containing data received from Twilio.
// A sample response from sending an SMS message is here (click "JSON" to see how the data appears in JavaScript):
// http://www.twilio.com/docs/api/rest/sending-sms#example-1
console.log(responseData.from); // outputs "+14506667788"
console.log(responseData.body); // outputs "word to your mother."
}
});
I did create a Twilio account, and have the "from" number (not my actual cell phone number) they assigned my account, and the SID, but I don't kow what the AUTH_TOKEN should be.
If what I intend is not possible from Twilio, what I may do is just write the app so that all the selected "to" numbers can be copied to the clipboard, so that the user can paste them into his SMS screen's "recipients" textbox; but I was hoping to afford the user the luxury of simply tapping a button.
I don't think you can do this (send from the user's own cell number using Twilio). If your app is an actual mobile app as opposed to a web app you can use the Android or iOS APIs for sending SMS from the user's phone. I'm not sure of the details of this and certainly with iOS it looks like you can't do so fully automatically for obvious reasons (you could just spam all the user's contacts for instance, and this would incur a monetary cost to the user).
There's a Cordova plugin here which can do what you want: https://github.com/cordova-sms/cordova-sms-plugin (I haven't used it so can't vouch for it but it seems to be actively maintained).
If it is a web app, your suggesting of copying the numbers to clipboard is by far the most straightforward solution and I would recommend that in the first instance. For completeness I've included some details and considerations below of how you can do 2-way communication with Twilio (or alternatives such as Nexmo) in a couple of ways, in case someone finds it helpful. It's not exactly trivial though. 1-way communication is a lot easier!
Send via API
From your app the user types a message and selects who to send it to. You app then connects to your server which uses the Twilio API to send N messages to the N recipients. These messages will appear to come from the Twilio-provided number.
Send via SMS
The user manually sends an SMS to your Twilio number and then you receive a webhook to your server from Twilio with the message details. You have to do the processing to work out who to forward the message to and then use the Twilio API to do so. Again the recipients will see a message from the Twilio-provided number.
Replies
When a recipient replies to the message, Twilio sends you a webhook with the details and you can determine who sent the original message and forward the reply back to the original sender.
Number Pooling
One of the obvious flaws here is that if multiple users send a message to the same person then there's no way of telling which message they are replying to. There's no message IDs passed with SMS so you have to use multiple sending numbers (one per unique sender to a particular recipient). The amount of numbers required is basically the most number of different senders one user would have to reply to (this is not generally possible to work out beforehand, so you would have to call the API to provision a new number on the fly).
To give a more concrete example say you have 2 users (S1 & S2) and 3 recipients (R1, R2 & R3). You have 1 Twilio-provided number (N1).
S1 sends a message to R1 via your app, you use N1 to send the message via the Twilio API. R1 receives the message from N1. If they reply, you receive a message to N1 from R1 so you know you need to forward it to S1.
S1 sends a message to R2 via your app, R2 has not yet received any messages so you can reuse N1 to send the message. R2 replies to N1 and again you can forward it to S1. If this is delivered in-app, no further problems, if the reply is forwarded via SMS then we'd need to provision a new number (N2) to enable S1 to reply to R2's reply.
S2 sends a message to R3 via your app, as before you can reuse N1 and still route the reply correctly.
Now if S2 sends a message to R1, we realise that R1 has already received messages from S1 using number N1. In this case we can't use N1 because we cannot identify who the reply was intended for. If we haven't already, we need to provision a new number (N2) and now we can send the message so R1. When R1 replies to N2 we know the reply needs to be forwarded to S2.
The more users sending to one recipient, the bigger (and more expensive) your number pool gets. It's probably worth implementing some kind of timeout (say 72 hours) in which the recipient can reply. So in this case if the timeout had expired after S1 sent the message to R1 via N1, we could reuse N1 for the communication between S2 and R1. Obviously this isn't entirely foolproof but it could reduce costs.
Identity
The other issue with sending from a pooled number. I send a message to Dan via an app, and he receives that message from a random number:
Hi Dan, how are you?
How does Dan know who sent the message? You'd have to add some identifier to every message (or at least the first in each conversation thread).

Resources