The Softphone allows an authorized user to make and receive telephone calls directly through a supported web browser.
The Softphone combines:
AIUNIFY Call Center provides two synchronized Softphone interfaces:
Both use the same underlying browser calling state and Twilio Device connection.
To open the full Softphone page:
The Softphone page is available at:
The page heading is:
Its description explains that the user can make real-time voice calls from the browser.
A floating Softphone button is available throughout the authenticated application.
The widget remains accessible while the user works in sections such as:
The same widget also remains present on the standalone Softphone page.
When minimized, the widget appears near the lower-right corner.
Its appearance changes according to activity:
Select the floating Phone button to open the Softphone panel.
The expanded panel displays:
Select the Minimize icon in the widget header.
Minimizing the widget does not end an active Call.
The minimized button continues displaying active-Call information.
The widget automatically expands when:
The user must be signed in before the browser can obtain a Twilio Voice access token.
Unauthenticated users cannot register a browser calling device.
The standalone Softphone page and assigned-number endpoint can open without a KYC check.
However, the routes that initiate, end, hold, and save a Disposition are protected by the Basic KYC middleware.
Therefore, a Customer may see the Softphone interface but still be unable to place a Call until KYC is Approved.
The effective Customer requirement is:
Administrators and Agents follow the KYC exceptions described in Chapter 2.
Creating a Call requires:
A user can have access to the Softphone page while lacking permission to initiate Calls.
When that occurs, the backend can reject the Call even if the dialer appears ready.
The platform must have an active Twilio configuration containing the credentials needed for browser Voice.
These include:
The browser token is issued for the identity:
and is valid for approximately one hour.
The browser attempts to refresh it before expiration.
The user must have a Phone Number assigned directly to the signed-in account.
For normal Softphone use, the number must generally be:
An Agent’s Softphone checks numbers assigned to the Agent’s own User ID.
Assigning a number only to the parent Customer does not automatically make it available to every Agent.
Each Agent should confirm the intended number appears under:
Phone Numbers already connected to an AI Agent are excluded from the normal human Softphone number list.
This helps prevent one number from being used simultaneously as both:
Use a current desktop browser with:
Google Chrome is the safest starting choice for the current browser calling implementation.
The first time the browser attempts to access audio, it can request permission to use the microphone.
Select Allow only when the address bar shows the correct AIUNIFY Call Center domain.
When microphone access is denied, the Softphone can report:
or:
The current Softphone interface does not provide a visible control for selecting:
It uses the browser or operating system’s selected default devices.
Change those devices through the browser or computer settings before placing production Calls.
A headset reduces:
Test both microphone and speaker before an Agent begins calling.
Normal navigation inside the AIUNIFY application preserves the global Twilio Device and active Softphone state.
However, a full browser refresh, closing the tab, or leaving the website triggers Device disconnection and unregisters the browser.
During an active Call:
The Softphone browser Device can have these states:
Offline means the browser is not currently connected to the Twilio Voice service.
Possible causes include:
While connecting, the interface can display:
or:
Wait before selecting Call.
Registered means the browser has obtained a Voice token and successfully registered the Twilio Device.
The interface displays:
and a green indicator.
Error means Device initialization or the provider connection failed.
The interface displays the returned error where available.
The Softphone translates certain Twilio errors into messages such as:
and:
Attempting to call before registration can produce:
The page’s initial configuration flag checks whether a Twilio configuration record exists.
The actual Device registration process requires an active usable configuration.
Therefore:
does not by itself prove that the service is operational.
The authoritative readiness indicator is:
The left Card contains:
The right Card displays:
Use this Card to verify that the correct Phone Number and Call state are being used.
The selected caller ID appears under:
Select it to open the number menu.
The menu can display:
A source Badge identifies:
The selected number is stored in the browser under:
When the Softphone reloads, it attempts to restore that selection.
When no saved number exists, the first available assigned Phone Number is automatically selected.
When the previously selected number is no longer assigned, the Softphone:
Select:
when a number was recently assigned but does not yet appear.
When no usable number is found, the interface displays:
and disables the Call button.
When the number request fails, the interface displays:
Use the Refresh icon after confirming the session and network are active.
In the reviewed source, the Number Switcher and the main Softphone context each create their own instance of the assigned-number hook.
The visible Number Switcher updates its own selected number and browser storage.
The Call action uses the separate selection stored in the Softphone context.
This means the displayed caller ID can change before the actual Call action has synchronized to it.
After changing Calling From:
Do not assume that the visible menu selection alone proves the Call will use that number.
The Call-creation backend accepts a number source of:
and verifies that the selected number belongs to the signed-in user.
Despite the SIP source designation, the current browser Softphone uses:
for the actual browser Call path.
The selected SIP number is passed primarily as the outbound caller ID in that process.
It is not shown using a separate browser-to-SIP WebRTC transport in this Call path.
A SIP-sourced number can fail as a Twilio caller ID when it is not authorized or verified within the connected Twilio account.
Complete an internal test before using a SIP-labeled number for browser Calls.
The page readiness checks both:
records.
The Softphone’s normal number endpoint retrieves from the phone_numbers table.
A SIP Trunk number stored only in trunk_phone_numbers can therefore satisfy the page’s assignment check but fail to appear in the Number Switcher unless it is also synchronized into the normal Phone Number system.
Enter the person’s number under:
The field includes:
The default country is:
A number entered without + is interpreted using that default unless another country is selected.
Use E.164 format:
Example:
For an international number, select the proper country or enter the complete + country code.
Do not enter an international number as an unqualified local number.
The outbound TwiML path assumes +1 when a destination lacks a leading plus sign.
The Call button requires at least:
after nonnumeric characters are removed.
A ten-digit check does not prove that the destination is real or callable.
The Softphone can display:
The destination field is disabled while the Call state is:
End the current Call before changing the destination.
The Dial Pad contains:
Before a Call connects, selecting a digit appends it to the destination Phone Number.
During a connected Call, Dial Pad digits are sent as DTMF tones.
DTMF can be used for:
The standalone Softphone page keeps the Dial Pad visible during active Calls, allowing DTMF tones.
The global expanded widget hides the Dialer interface during a Call, including its Dial Pad.
Therefore:
Before dialing, the user can select:
The frontend’s default value is enabled when the Softphone context first loads.
The Recording option becomes unavailable after the Call starts.
Choose the correct setting before selecting Call.
When enabled, the outbound TwiML uses:
The provider is instructed to begin recording when the external leg answers.
When the recording is completed, Twilio sends recording information back to the Call record through the configured Webhook.
The recording does not necessarily appear immediately after hangup.
The same outbound browser-Call path also requests transcription when Recording is enabled.
Therefore, enabling Recording can result in:
During a connected outbound Call, the standalone page displays:
with an animated red indicator when Recording was enabled.
Before the Call connects, the Call Information Card can display:
This means recording has been requested for the upcoming Call.
It does not mean audio is already being recorded.
Turning the option off affects the next outbound Softphone Call.
It does not remove historical recordings.
The reviewed inbound Softphone TwiML connects the caller to the browser without adding the outbound record-from-answer recording attributes.
The Softphone Recording checkbox is not applied to an already incoming Call.
Therefore, normal inbound browser Calls are not confirmed as recorded through this current handler.
Before recording, confirm:
The technical checkbox does not establish legal permission.
Calls can be prepared from supported Contact interfaces.
Examples include:
Selecting the Contact’s Call action:
The user must still select Call.
Click-to-call currently normalizes an unqualified Contact number using:
International Contacts should store the complete E.164 number to avoid an incorrect +1 interpretation.
When the Call begins through a Contact-aware action, the Call request can include:
This links the Call to the master Contact and, where applicable, its Campaign participation.
During a Contact-linked Call, the expanded widget can show the active Contact Name in its header.
When the Softphone has an active Contact ID, it displays:
The Quick Edit dialog contains:
After selecting Save:
Quick Edit will not save without a usable Phone Number.
Quick Edit saves directly to the Contact record.
It is not a temporary Softphone-only change.
Review the information carefully before saving.
Before selecting Call, confirm:
When Call is selected, AIUNIFY Call Center first creates a Call record containing:
The browser then asks Twilio Voice SDK to connect using that Call record’s ID.
The backend verifies that the selected From Number belongs to the signed-in account.
When it does not, the system returns:
When no outbound number is available:
The Softphone refuses to start another outbound Call unless the current Call state is:
Internal state:
Visible label:
Internal state:
Visible label:
Internal state:
Visible label:
Internal state:
Visible label:
The local Call timer begins after the Twilio browser Call emits its accepted event.
Internal state:
Visible label:
The interface keeps this state briefly and then returns to Idle.
Internal state:
Visible label:
The interface returns to Idle after a short delay.
The Softphone state reflects the browser SDK.
The stored Call record is updated separately through Twilio Webhooks.
For reporting and billing, the authoritative values are the final:
not only the temporary browser display.
The standalone Softphone displays duration in:
Example:
The timer starts when the browser Call emits its accepted event.
This can represent the browser leg becoming active and should not be treated automatically as the exact billable external conversation duration.
The final Call History duration is populated through provider status data.
Use that stored value for reporting.
The expanded global widget currently passes the raw numeric seconds value into a component designed for a formatted duration string.
It can therefore display:
rather than:
The minimized active-Call button formats its timer correctly as MM:SS.
During a Call, the controls include:
Mute and Hold are enabled only when the state is Connected.
End Call can be available during Ringing or Connected states.
Select the Microphone button to mute the local browser microphone.
The remote participant should no longer hear the Agent.
Select the button again to restore the microphone.
Mute is performed through the Twilio browser SDK.
It does not require a backend request.
The Call Information Card changes:
to:
Select Hold after the Call is Connected.
The interface immediately changes its Hold state while the backend request is processed.
The backend finds the external PSTN Call leg and redirects it to Twilio hold music.
Select Resume to redirect the external Call leg back to the browser identity.
Hold requires:
When the external leg has not connected, the backend can return:
The interface initially changes the Hold indicator.
When the backend request fails, the Softphone reverts the visual Hold state.
The shared Call Controls component expects properties named:
The standalone Softphone page currently supplies:
Therefore, the standalone page’s Mute and Hold buttons are not correctly wired in the reviewed source.
During a connected Call, use the global floating Softphone widget for Mute and Hold.
The widget supplies the correct control properties.
The standalone page remains useful for:
Select the red Phone button.
The browser attempts to:
The backend instructs Twilio to complete the active provider Call, but the local Call record is then updated to:
Therefore, a manually ended Call can appear as Canceled rather than Completed in Call History.
Even when the backend Call-status update fails, the browser still attempts to disconnect the active Call.
Review Call History afterward to verify the final stored state.
The backend can return:
when the stored status is no longer:
When someone calls an assigned Phone Number, the inbound handler:
An Incoming Call can reach the browser only when:
The alert displays:
When the caller number is unavailable, it displays:
The current Incoming Call alert displays the caller’s raw From value.
It does not show a confirmed Contact match or Contact Name.
Select Accept.
The interface displays:
and accepts the incoming Twilio browser Call.
Select Reject.
The browser rejects the incoming Call and clears the alert.
The caller then follows the remaining inbound TwiML behavior.
The inbound routing provides approximately:
for the browser identity to answer.
When no one answers, the caller hears a message stating that the person is unavailable, followed by hangup.
When AIUNIFY cannot determine which User owns the called number, the caller hears:
The Call is then terminated.
A normal inbound browser Call is stored with:
The Twilio browser Device is configured with:
The browser does not provide a traditional multi-line Call Waiting interface.
A second caller may be routed to the Call Queue when the server determines the owner is busy and Queueing is enabled.
The Call Queue can hold an inbound caller while the intended user is busy.
The process is:
The installed migration defines defaults of:
The backend accepts:
The current source contains a Queue Settings API route but no normal visible Customer page for editing these settings.
Changing Queue configuration currently requires an approved administrative or development workflow.
The default greeting states that the caller is being placed in a Queue and that an Agent will be available shortly.
An account-specific greeting can replace it when configured.
While waiting, Twilio can tell the caller:
It then plays hold music.
When the Queue has reached its maximum size, the caller hears:
The Call ends.
When callers are waiting, the expanded Softphone widget displays:
While a user is in a Call, the browser checks Queue status approximately every:
It performs one additional check after the Call ends.
When the current user is not in a Call, the Queue Indicator displays a button to connect the next waiting caller.
The oldest waiting caller is selected first.
When a connected Call changes to Ended and callers are waiting, the Softphone waits approximately two seconds and automatically requests the next caller.
The system calls the browser identity and then joins it to the waiting Twilio Queue.
The Softphone receives this as an Incoming Call that must be accepted.
The current Queue service considers the owner busy only when it finds a recent:
It does not include normal outbound Calls in this busy query.
A second inbound caller may therefore fail to enter the Queue while the user is busy on an outbound Call.
For Queue operations, an Agent is mapped to the parent Customer’s Queue owner ID.
When an Agent requests Connect Next, the current dequeue process calls:
rather than the Agent’s own browser identity.
The dequeued caller can therefore ring the parent Customer’s Softphone instead of the Agent who selected the action.
Normal browser registration uses the global Twilio configuration.
The Queue dequeue service looks for the Queue owner’s active Twilio credential.
A working global Softphone does not guarantee that Queue dequeue has the additional credential it expects.
The browser treats Queue status as noncritical.
Queue-request failures are generally logged in the browser console and may not produce a prominent user-facing error.
When Connect Next does nothing, report:
to the Administrator.
The Post-Call dialog appears only when:
It appears approximately 1.2 seconds after the Call ends.
A number typed directly into the Softphone without selecting a Contact normally has no active Contact ID.
The Post-Call Disposition dialog will not automatically appear for that Call.
The dialog is presented as:
It can include the linked Contact’s Name.
The available results are:
The user can enter up to:
of Call Notes.
Selecting:
reveals a date-and-time field.
The backend stores the selected time in:
The Disposition route stores the callback date.
It does not itself create a confirmed:
Users should maintain the organization’s approved callback process.
To save:
Select Skip to close the dialog without saving a Disposition or Notes.
When a linked Contact exists, saving a Disposition updates:
If Call Notes were entered, the Notes are appended to the Contact record with the date and Disposition.
Selecting the Do Not Call Disposition stores that result on the Call.
The save route does not change the master Contact’s Status to DNC.
To prevent future calling, separately update the Contact’s calling Status according to the organization’s DNC procedure.
When saving a Post-Call Disposition fails, the current dialog logs the error but does not display a clear user-facing error notification.
Confirm the result in Call History or the Contact record before assuming it saved.
Completed Calls with a positive duration can create a Credit deduction based on:
The current status processor attempts the Credit deduction after the Call is marked Completed and a duration is available.
The normal manual Softphone Call-creation action does not perform a confirmed pre-Call affordability check.
A Call can begin before the final Credit charge is calculated.
When the completed Call cost exceeds the available balance, the current billing action logs the insufficient-Credit condition and returns without completing the deduction.
The Call has already occurred.
Administrators should monitor for unbilled Calls and reconcile them through Credit Management.
The Header Credit Balance does not update continuously.
After a Call:
The human Softphone does not provide a visible live button for transferring the current Call to another Agent or external number.
There is no visible live Conference button.
The current controls do not include adding another participant to an active Call.
Audio-device selection must be handled through browser or operating-system settings.
There is no visible Call Park or retrieval control.
The Softphone blocks starting a second Call while the current state is active, and incoming-while-busy is disabled at the Twilio Device level.
Check:
Wait briefly, then:
Possible causes include:
The page checks whether a configuration row exists, while token generation requires an active usable configuration.
Report the Device error rather than relying on the initial configuration status.
Check:
The Phone Number must be assigned directly to the Agent account for the Agent Softphone.
Confirm that the SIP number has been synchronized into the normal Phone Number records used by the Softphone endpoint.
This can result from the current separate Number Switcher and Softphone-context states.
Select the number, reload or navigate, and make an internal test Call.
Confirm:
The Softphone page can load without KYC, but Call initiation requires Basic KYC for Customers.
Complete verification and retry.
Confirm the role has:
The selected From Number does not pass the backend ownership check.
Refresh the number list and confirm assignment.
A TwiML configuration mismatch can produce a spoken or logged message that the Call ID is missing.
The TwiML Application’s Voice URL must point to the correct manual-Call handler.
Confirm the destination was entered and that the browser request completed before the Twilio Call began.
Store and enter the full + country code.
Numbers without a leading plus can be interpreted as U.S. numbers.
The browser Softphone still uses the Twilio Voice transport.
Confirm the number is accepted as a caller ID by the global Twilio account.
Check:
Check:
Use the global floating Softphone widget.
The standalone page currently passes incorrect Mute and Hold property names.
Confirm:
The backend failed to locate or redirect the external Call leg.
Wait until Connected and retry once.
Open the standalone Softphone page before or during the Call.
The global widget hides the Dial Pad while a Call is active.
The browser timer and provider duration are calculated through separate event paths.
Use Call History for the final stored duration.
Confirm:
The destination number could not be matched to an assigned User.
Review Phone Number ownership and inbound routing.
The browser identity did not answer within the inbound Dial timeout.
Confirm the user’s browser was registered and the alert was accepted.
The current inbound Softphone route does not apply the outbound recording option.
This is expected under the reviewed implementation.
The current busy check detects only certain recent inbound Call states.
An outbound active Call may not trigger Queue routing.
The Call must have been started from a linked Contact action.
A manually typed number is not enough.
Confirm:
The current route stores the callback date but does not confirm a reminder or calendar workflow.
The Disposition does not automatically set the master Contact to DNC.
Update the Contact Status separately.
Use this sequence:
Confirm:
Monitor:
Complete:
The reviewed Softphone implementation currently includes these important limitations:
At the end of this chapter, the user should understand how to open the standalone Softphone and global floating widget, recognize the Device states, grant microphone access, verify Dialer readiness, select an assigned caller ID, enter an E.164 destination, configure outbound Recording, and start a browser Call.
The user should understand the Call states:
and know how to use Mute, Hold, Resume, DTMF tones, and End Call.
The user should understand that the standalone and floating interfaces share the same Device and active Call, allowing normal internal page navigation without ending the conversation. A full browser reload or tab closure can disconnect the Device.
The user should understand how inbound Calls are routed to the browser identity, how to Accept or Reject them, why the browser must remain registered, and why an unanswered inbound Call is terminated after the routing timeout.
The user should understand the Call Queue workflow, including waiting callers, Queue size, wait time, Connect Next, and automatic dequeue. The user should also recognize the current limitations involving outbound busy detection, Agent queue ownership, and credential dependencies.
The user should understand how Contact-aware calling links a Call to a Contact, enables Quick Edit, and displays the Post-Call Disposition dialog. The user should know that selecting Do Not Call on the Call does not automatically set the master Contact’s DNC Status.
Most importantly, the user should follow this safe workflow: