VICIdial Agent Error: ‘No One Is In Your Session’ (8600051)

An agent logs in, the screen loads, and then:

NO ONE IS IN YOUR SESSION: 8600051

The agent cannot take calls. Sometimes it affects one agent, sometimes everyone. Here is what the message means and how to work through it methodically instead of restarting things at random.

What the Number Is

8600051 is a conference extension. When an agent logs in, VICIdial places their phone into a dedicated conference — historically MeetMe, more recently ConfBridge — and every call the agent handles gets bridged into that same conference. It is the mechanism that lets calls be transferred and monitored without the agent’s channel dropping.

The error means VICIdial checked the conference and found nobody in it. The agent’s phone never joined, or joined and dropped.

So this is almost never a VICIdial application bug. It is a telephony problem between the agent’s phone and Asterisk.

Step 1: Is the Phone Actually Registered?

asterisk -rx "sip show peers" | grep 8001

Substitute the agent’s phone extension. You want a status of OK with a latency figure. UNKNOWN or UNREACHABLE means the softphone is not registered and nothing else matters until that is fixed.

If the agent uses the webphone, check the WebSocket instead:

asterisk -rx "http show status"

Common causes at this stage:

• Softphone configured with the wrong password or server address
• Agent’s firewall or ISP blocking SIP
• Phone entry disabled in Admin → Phones
• Webphone failing because the page loaded over HTTP rather than HTTPS

Step 2: Watch the Login Live

This is the step that actually finds the answer. Open the CLI and have the agent log in while you watch:

asterisk -rvvvvv

You should see the phone being dialled and joining the conference:

-- Executing [8600051@default:1] MeetMe("SIP/8001-00000012", "8600051,F")

What you see instead tells you where it broke:

asterisk -rx "manager show connected"

Step 3: Conference Ranges

Every VICIdial server has a range of conference numbers assigned to it. If the range is wrong, too small, or overlapping with another server in a cluster, agents get assigned conferences that do not exist or that another server is already using.

Check what the server has:

SELECT server_ip, conf_start, conf_end FROM servers;

And what conferences exist:

SELECT count(*) FROM conferences;
SELECT count(*) FROM vicidial_conferences;

If the counts are low or zero relative to your agent count, regenerate them in Admin → Servers → Modify Server by setting the conference range and saving, then:

/usr/share/astguiclient/ADMIN_keepalive_ALL.pl

On a cluster, ranges must not overlap. Server 1 might hold 8600051–8600250, server 2 8601051–8601250. Two servers handing out the same conference number produces exactly this error, intermittently, which makes it maddening to diagnose.

Step 4: Stale Conference Entries

If an agent’s session ends badly — browser crash, network drop — the conference can be left marked as in use. New logins then get pushed to a different conference while the old one sits reserved.

Look for orphans:

SELECT * FROM vicidial_conferences WHERE extension != '' AND server_ip = 'your.server.ip';

VICIdial’s own cleanup usually handles this. If entries are clearly stale — an agent who logged out hours ago — clear them:

UPDATE vicidial_conferences
SET extension = '', leave_3way = '0'
WHERE conf_exten = '8600051' AND server_ip = 'your.server.ip';

Then have the agent log in again. Only do this for conferences you are certain are not in active use.

Step 5: MeetMe Versus ConfBridge

Asterisk 13 and later dropped app_meetme from the default build in favour of app_confbridge. VICIdial supports both, but the server record has to say which one you are using.

Check what is loaded:

asterisk -rx "module show like meetme"
asterisk -rx "module show like confbridge"

Then confirm Admin → Servers → Modify Server → Conf Engine matches. A server running ConfBridge but configured for MeetMe will originate calls into a conference application that does not exist, and every agent will see 8600051.

For ConfBridge, check /etc/asterisk/confbridge.conf has the VICIdial profiles:

[default_bridge]
type=bridge
max_members=50

[default_user]
type=user
quiet=yes

Step 6: Timing and Load

Under heavy load, the conference join can time out before VICIdial’s check runs. If this error appears only at peak and clears by itself, you are looking at a capacity problem rather than a configuration one.

Check for CPU starvation:

top -bn1 | head -15
asterisk -rx "core show channels count"

High load average with the dialer at full tilt means the server is undersized for the agent count and dial ratio. Lower the ratio, or add capacity.

Also check AGENT_TIME_DIFF and the agent’s own network latency. An agent on a poor connection can genuinely fail to join within the window.

Quick Diagnostic Order

Work through it in this order and you will find most instances quickly:

1. sip show peers — is the phone registered?
2. Watch asterisk -rvvvvv during a login — where does it stop?
3. Check the server’s conference range and count
4. Look for stale vicidial_conferences rows
5. Confirm the conf engine matches the loaded Asterisk module
6. Check load if it is intermittent and peak-correlated

Resist the urge to restart Asterisk first. It clears the symptom often enough to feel like a fix, which means the actual cause stays in place and the error comes back the next day.