autoAnswer - sometimes true, sometimes false?

WebRTC SDK
1

Hi guys, sorry to bug you yet again with another question that's probably buried somewhere I haven't dug up yet. :laughing: But here goes: In this super-simple code...

sdk.on('pendingSession', function(e) {
console.log(e.autoAnswer);
});

Sometimes autoAnswer is true, and sometimes it's false. Now from what I've heard, auto-answer is set by user (well, under the hood it's probably by division or queue or something, but the way our org does things it's essentially by user). But it seems that the autoAnswer property doesn't accurately reflect whether a user has auto-answer turned on. When I call into my test program, sometimes auto-answer is true and sometimes it's false... but the call starts immediately as if it were true. So what's happening is my code is still showing users an "answer" button even though I'm already on the call.

Is there another property I should be looking at, something more reliable than autoAnswer? In my digging through the docs I saw something about a disableAutoAnswer or something, but that didn't look like what I'm looking for. I'm trying to detect if an incoming call is auto-answered or not. Any ideas? In the meantime, I'll keep hunting on DuckDuckGo :smiley: Thanks in advance.

EDIT: Just to clarify, I'm talking inbound calls (I know this page says it's always true for outbound calls).

2

So autoanswer is a property that gets communicated to the client (from the backend obviously) with every new session. Autoanswer will be true for all outgoing calls and for incoming acd calls when the value is true for the user setting. Autoanswer will never be true for incoming non-acd calls.

3

Right, that was how I understood it... so then why is it false sometimes and true others? Like I said, I'm not even dealing with outbound calls (I did read that part lol). I'm guessing it's what you called "non-acd"... what does that mean? Sorry, still learning the slanguage of telephony. Don't all calls come from the same place? Probably confusing ACD with IVR lol...

4

Or could it be that autoAnswer should be listened for at another point, i.e. a different event handler? Maybe the system is still calculating it or something during "pendingSession"?

5

At this point, I've discovered something.......... interesting.................

So the call comes in, my program responds by showing the call controls. That's fine. THEN the pendingSession event fires and my code responds to THAT........... so............ yeah, gonna see what I can scrounge up from the docs. Might be time to study the living daylights out of the flippin' Network tab. :laughing:

Also, to layer on another slice of wacky..... it only happens after I have already answered a call. So: Random conjecture #1: Somehow, someday, I'm either causing two pendingSession events. Why? Cuz {REASONS} :laughing:

6

  1. So there is a case where we "fake" a pending session, but that only applies to persistent connections. It also shouldn't apply here because if there's an active persistent connection the backend will autoanswer the call without any say-so from the client.

  2. The distinction between acd and non acd is slight. Generally if the purpose on the user of the conversation is agent it's classified as an acd call. Acd calls are usually placed on behalf of a queue or assigned to a user as part of a queue. I would say this is generally the case for inbound calls from an IVR but its possible the IVR sends it directly to a user without going through a queue which would then make it a non-acd call for that user. Sorry it's so complicated. I'm probably not the most qualified to answer the question of what makes a call an acd call.

  3. Regarding your slice of whacky. After the sdk is fully initialized, will you check the values of sdk.isPersistentConnectionEnabled() and sdk.isConcurrentSoftphoneSessionsEnabled()?

7

Okay, after 2 whole days fighting with this thing I finally found it: it was an ID-10-T error! :rofl: :man_facepalming:

Turns out with so many "e's" floating around, I was referencing the wrong one. Of course there's no "autoAnswer" on a flippin' onclick event! :laughing: But that's JS. Reminds me why I love C. :laughing:

The moral of the story, kids, is remember what a witch nested callbacks can be. :rofl: Hope that helps others racking their brains, pouring over the docs, and nearly crashing search engines looking for info. :laughing: And apologies to those who have had to read this question. I feel like... well, "ID-10-T" says it all, lol

1 Like
8

I know it's been awhile since I posted to this, but unfortunately even with my stupid mistake fixed, there are still times when I see autoAnswer = false. Not sure why that happens, but I have a workaround in place. So in case anyone else runs into this issue, here's what I did:

  1. In my sessionStart event handler, I have an "activeSession" variable that I use to get info like session ID (or "conversationId" in the slanguage of the API). I'm sure most users have similar variables, whether they're Boolean "onCall" or whatever.
  2. Since I was getting pendingSession and sessionStart at basically the same time (might be a few ms difference), in pendingSession, if auto-answer was false but I was already on a call, it returned. That fixed the problem I was having back then where pendingSession would fire with autoAnswer: false. That prevented the "answer call" dialog we had created from appearing while the user was already on a call.

Anyway, just thought this might help somebody else someday. :smiley:

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.