Missed Call to email notification?

[Tuly]

Is there a way we can have missed call to email notification? When someone has a missed call on their extension, the system should send an email notifying the user of the missed call.

i may have asked this ones, it was dismissed as a none important feature, but we keep getting this request

Anyone knows if this will be possible with the new WebSocket manager?

[Darren Schreiber]

How about hooking up WebHooks to a small script that emails the customer each time a call is missed? You can inspect the hangup cause to see if it was LOSE_RACE (means someone else answered) or ORIGINATOR_CANCEL meaning nobody answered.

[Tuly]

yeah that should help, i will look in to this  (if i know how to do it...)

[FASTDEVICE]

We use ORIGINATOR_CANCEL and billing seconds zero to show missed calls. We don't use LOSE_RACE as it's implied the call was answered elsewhere. For a close to real-time notification, I'm thinking the trigger event is channel_destroy. 

[Karl Stallknecht]

Are you sure that would work? I just tested this (called to our office from my cell) and it showed "normal clearing" even though I hung up on my cell.

[FASTDEVICE]

@Karl, the answer is simple. You are going to get NORMAL_CLEARING in the event that any callflow element answers the call. You probably have a menu/ auto attendant or some media playing prior to ringing through to the destination.  

[Karl Stallknecht]

Ah okay, thanks.

[Tuly]

@FASTDEVICE would you mind posting a complete example of how you would do a missed call webhook? Even if it was answered by a menu if no one actually picked up the call it should still be considered missed call,

Thanks,

[FASTDEVICE]

Here is what you probably want to look for:

"billing_seconds": "0", "call_direction": "inbound",

[FASTDEVICE]

We show missed calls in our call analytics, not as a real-time notification. I'm thinking for real-time here is what I would do:

Create a webhook using the trigger, "channel_destroy"
the hook fires off code on your server that first delays enough for the CDR to appear in the database (sometimes this could take a few seconds or longer) and then the code queries the CDRs looking for any <in the last say, minute> that are

"hangup_cause": "ORIGINATOR_CANCEL",

or

"billing_seconds": "0", "call_direction": "inbound",

Then, email or sms a notification to the user.

[FASTDEVICE]

One other note, you'll need to play with the timing or save the call_id in a database to prevent sending duplicates.

[Tuly]

i see thanks FASTDEVICE, 1 issue i have, if the voicemail picks up and the caller hangs up, the billing seconds will not be 0, and when ever there is a menu, the billing seconds is also not 0,  

So practically you can only Implement missed call to email notification, on Direct DIDs,  that goes straight to a phone and the voicemail does not even pick up, am I right?

[FASTDEVICE]

There appears to be five missed call scenarios:

1. Extension Ringing
2. Ext. to VM answers
3. Menu/ Media answers
4. Menu to Extension Ringing
5. Menu to Extension to VM answers

Test each scenario and look for how many call legs are identified and the disposition value of the inbound call leg.  

"disposition": "NO_ANSWER",

[Tuly]

1. Extension Ringing                                 ORIGINATOR_CANCEL
2. Ext. to VM answers                               NO_ANSWER   
3. Menu/ Media answers                           ANSWER
4. Menu to Extension Ringing                   ORIGINATOR_CANCEL
5. Menu to Extension to VM answers       NO_ANSWER

thats very good, but how can we add the disposition value to the webhook? possible?

[FASTDEVICE]

Thanks for doing the testing! The purpose of the webhook is to trigger your code when the channel is destroyed. I'm more acquainted with channel_answer, but I'm guessing channel_destroy will trigger when a call leg is hung-up. This will be your semi real-time hook to query the CDRs for the disposition value. Again, the code should delay enough for the CDR to be present, query for the disposition value, do some check to see if the call_id has already been used (if not, store it), and then notify your client(s).

I don't think the disposition value is contained in the webhook, but here is a very good site to capture that kind of data: http://requestb.in/ and investigate.

[Tuly]

Thanks for the link fastdevice... i have an idea how to do missed call now,

One thing concerns me, it does look that webhooks are not so reliably sent,  as a lot of times I'm doing the same thing,  webhooks will send both legs of the call,  and at other times it will send only 1 side of the call, 
should I rather wait for websocket? when websocket comes out will webhooks still be supportive?

[FASTDEVICE]

I find webhooks to be highly reliable, but as mentioned, my experience is with answer. Webhooks is known to fire twice for each trigger, but @Darren states that's by design. However, you mention they sometimes fire with each leg of a call. In which case(s) of the five are you getting a trigger for both legs of a call being destroyed?

as I mentioned before, test each scenario and look for how many call legs are identified and the disposition value of the inbound call leg.

[FASTDEVICE]

Webhooks and websockets are intended for different purposes. Hooks are intended for server-to-server communication, and sockets are server-to-client (browser) communication. I'd expect both will be fully supported. 

[Tuly]

I was testing on channel_destroy, most incoming calls were getting both legs of the call,
But interesting I can do the same incoming call to a menu and pressing an extension after letting the extension Ring 2 times I hang up the call, I would say it's 50-50, 50% of the time we're getting both legs of the call, for the outside number getting a ' normal clearing' ( the menu picked up) and for the extension were getting originator cancelled, and the other 50% of the time we're doing the same same thing and we're only getting the incoming normal clearing,

I'll play around some more tomorrow, will see

[Darren Schreiber]

I was talking to Tuly offline here. Is it acceptable to just get a notice if someone hangs up if they've reached voicemail but don't leave a message?