Conference number '8600051' not found!

[aur]

[Apr 23 08:55:55] -- Executing [55558600051@default:1] MeetMeAdmin("Local/55558600051@default-00000000;2", "8600051,K") in new stack
[Apr 23 08:55:55] WARNING[2806][C-00000001]: app_meetme.c:5342 admin_exec: Conference number '8600051' not found!
[Apr 23 08:55:55] -- Executing [55558600051@default:2] Hangup("Local/55558600051@default-00000000;2", "") in new stack
[Apr 23 08:55:55] == Spawn extension (default, 55558600051, 2) exited non-zero on 'Local/55558600051@default-00000000;2'
[Apr 23 08:55:55] WARNING[2806][C-00000001]: func_hangupcause.c:138 hangupcause_read: Unable to find information for channel
[Apr 23 08:55:55] -- Executing [h@default:1] AGI("Local/55558600051@default-00000000;2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16--------------------)") in new stack
[Apr 23 08:55:55] -- <Local/55558600051@default-00000000;2>AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ----------) completed, returning 0
[Apr 23 08:56:00] == Manager 'sendcron' logged on from 127.0.0.1
[Apr 23 08:56:00] == Using SIP RTP CoS mark 5
[Apr 23 08:56:00] -- Called 4004
[Apr 23 08:56:00] -- SIP/4004-00000003 is ringing
[Apr 23 08:56:00] -- SIP/4004-00000003 is busy


I am getting this error when I click on call agent again. My user is registered on Webphone and it is showing busy. Can anyone help me to resolve this issue. Thanks

[jamiemurray]

If you are using ViciPhone v3, there is a bug with server side BYEs that causes the phone to effectively crash preventing any new calls reaching it (it returns busy). Logout/in will get around it. I actually ended up switching a few clients back to an earlier version of viciphone because of this issue until it's fixed or I get the time to look at it myself and find the bug.

The conference number not found is normal if the conference is empty, a kick command is issued at the start to ensure it's empty before an agent session begins using it.

[carpenox]

are you hearing the "only_person" sound when you login? Check if dahdi is running with this command: dahdi_cfg -v

[mcargile]

@jamiemurray
I was able to get Viciphone 3 to get stuck in Incall when the server side Bye comes in. That was just a display bug though. I was not updating the display to go back to Registered. I actually had code for doing so but it was commented out for some reason that I have long sense forgotten. This makes me think that that code caused some other issue.

That said I could not get it to return Busy to Asterisk after that. It always accepted the invite. Please test with my dev version:

https://dev.viciphone.com/viciphone.php

and see if you can replicate it. If you can please send an email to support@vicidial.com and put it to my attention and reference this forum post. Also send the webphone debug output, a description of the steps you are taking to replicate this, along with your browsers debug console output.

[jamiemurray]

Hi Mike,

Yeah, it appears the In Call thing is indeed cosmetic but this actually just masked the cause of the issue one of my clients was facing in one of their offices.
Agents in one site were randomly reporting a loss of audio. Sometimes one agent at a time, sometimes more than one agent at a time. One agent particularly had this issue with it happening at least once an hour resulting in no audio, and no "No one is in your session" error appearing.

Since this cosmetic issue has been cleared up, I had a quick look and found it to be an ICE error that occurs when an agent workstation loses network for a second that's not handled and locks the phone up with all javascript disabled on it after the ICE error.
The agent's workstation reported intermittent "Network Cable Unplugged", despite telling them this and their promises to remedy it, it continues to be an issue, to say I'm frustrated with the amount of support requests this one user causes is an understatement. In the meantime I have a script that runs when the network disconnection occurs and throws a message up on their screen telling them it's happened and to log out/back in to reset their audio.

The phone seems to recover from this on V1, but not on V3 although that could be a false perception. I'll do a bit more digging and share my findings as soon as I can.