Why Every Phone in an Alias Needs the Same Login Password

There is one rule that sinks more phone-alias setups than any other: every phone grouped under an alias must use the same login password. It sounds obvious until you remember the agent only ever types one password - and that password has to work on whichever server the load-balancer picks.

One password, many possible servers

When an agent logs in with an alias, they enter a single Phone Password. They cannot know in advance which dialer they will land on, because that is decided live by agent counts. So the password they type must be valid on all of the underlying phones. If even one phone in the list has a different login password, an agent routed to that server will be rejected at login - while the same agent logging in a minute later, when a different server wins, sails through. That intermittent behavior is the classic symptom.

flowchart TD
  A[Agent enters one phone password] --> B{Load balancer picks server}
  B --> C[Dialer A phone password matches]
  B --> D[Dialer B phone password differs]
  C --> E[Login succeeds]
  D --> F[Login rejected]

Registration password vs login password

It helps to keep the two passwords straight. The registration password is what the Softphone uses to maintain its Phone registration with each server's SIP registrar. The login password is what the Agent types on the agent screen to claim the phone. Across an alias, both are usually set identically on every phone - but it is the login password specifically that the alias rule is about.

• Registration password: keeps the SIP line registered to each server
• Login password: what the agent enters to log into the chosen dialer

When you build an alias, copy the password fields verbatim from the first phone to every other phone. Do not retype them by hand on each form; that is how a single transposed character sneaks in.

For how these fields relate to the rest of the phone entry, see the phones and aliases guide, and the login vs registration password.

VICIfast generates matching credentials across the cluster so this mismatch never happens - see pricing.