Xuc & Xucmgt (CC & UC embedded)

XUC overview page

XUC overview page available at @XUC_IP:PORT, usually @SERVER_IP:8090. You have to check if the “Internal configuration cache database” contains agents, queues etc.

XUC sample page

XUC sample page available at @XUC_IP:PORT/sample, usually @SERVER_IP:8090/sample. You can use this page to check user login and other API functions. CCManager, agent and assistant web use functions available on the sample page.

XUC Internal Metrics

Internal metrics are also available - see XUC Internal Metrics page.

Agent states after XUC restart

Please see the note in restarting XUC server with active calls.

Queue created

New queue will not appear immediately in CCAgent and CCManager until the agent or the manager is not relogged to these applications accordingly. The Xuc server restart is not required.

Queue deleted

Deleted queue will still appear in CCAgent and CCManager until the Xuc server is restarted.

Audio quality issues

If something goes wrong with the quality of an ongoing call, it will be reflected in live, every 20 seconds, inside the xuc server logs, with the following format:

WARN  s.ClientLogger- [userw] 1590da900aba2a761573c0493c04a0a1@192.168.56.2:5060 Audio quality issues ->  RTT 186ms - Jitter upstream 1ms / downstream 0ms - Packet loss upstream 21% / downstream 6%

At the end of each call, a call quality report will also be sent in the xuc server logs, with the following format:

INFO  s.ClientLogger- [userw] 1590da900aba2a761573c0493c04a0a1@192.168.56.2:5060 Call quality report -> Highest RTT 186ms - Highest Jitter upstream 3ms / downstream 3ms - Highest Packet loss upstream 21% / downstream 12%

Both those format include the user as well as the sip call id, so it can be grepped. It can also be grepped by the type of message, “Audio quality issues” and “Call quality report”.

Audio quality visualisation

When needed, a dedicated module can be setup to allow graphical representation of those data. See the following section for more details.

Activation

On XiVO PBX:

1. In /var/lib/postgresql/17/data/pg_hba.conf add rights for following users on specific tables (replace the <XUC_IP> with the IP of VM where xuc is running):

   host  call_quality_stats    rografana   <XUC_IP>/32    md5
   host  call_quality_stats    rwfluent    <XUC_IP>/32    md5
   

2. Add the service in file /etc/docker/xivo/docker-xivo.grafana.yml to /etc/docker/xivo/docker-xivo.override.yml.

3. And finally run:

   xivo-dcomp reload db
   xivo-dcomp up -d
   

On XiVO CC / UC :

1. Add the service in file /etc/docker/compose/docker-xivocc.fluentd.yml to /etc/docker/xivo/docker-xivocc.override.yml.

2. And then run:

   xivocc-dcomp up -d
   

Usage

When audio quality visualisation activation step is done.

You can access grafana web page via:

https://<XIVO_IP>:3000/

Replace the <XIVO_IP> with the IP of your Xivo PBX.

Dashboard view :

On grafana dashboard you can:

1. Select user that you want to display thank to the users_list parameter

2. Zoom out by pressing CRTL+Z or by clicking on the magnifier

Warning

All the added dashboards will not be saved in case of update.

Xuc CLI

The xuc CLI is a small terminal tool that lets you inspect the state of xuc’s internal call-tracking mechanics. You can compare them with your Asterisk state and clean them up if needed, which can troubleshoot some issues in production without restarting xuc.

The CLI is invoked through:

xivocc-dcomp exec xuc bin/xuc-cli <command>

Run xuc-cli on its own to list the available commands. Run a command with no action (for example xuc-cli siptracker) to list the actions that command accepts. Prefix every command below with xivocc-dcomp exec xuc bin/xuc-cli.

Note

The CLI auto-detects the running xucserver process. If several are running (or detection fails), pass the process id explicitly with --pid <PID> (-p for short), placed right after bin/xuc-cli.

General information

• info — print the xuc start time, version, and the number of users and agents available in the xuc internal repository

MDS

• mds list — list every known mds with its state and AMI connectivity (hostname, port)

• mds <MDS> — print AMI info and connectivity of <MDS> (the technical name of your mds)

SIP tracker

The siptracker command inspects and operates on xuc’s per-line call trackers.

A tracker is selected either by its SIP peer name (as known by Asterisk) or by extension using --exten <number> (-e for short). All actions accept --driver <driver> (-d), which defaults to PJSIP.

Note

<SIP_PEER> is the bare peer id without the driver prefix. Pass 1p7b9k7f, not PJSIP/1p7b9k7f (even though siptracker list prints the interface with the prefix in its INTERFACE column).

• siptracker list — list every currently tracked SIP peer (interface, extension, number of calls) for the selected driver (--driver, PJSIP by default)

• siptracker <SIP_PEER> info — print the tracker details for that peer (extension, interface, calls, current calls and more)

• siptracker <SIP_PEER> clearcalls — clear the calls tracked internally for that peer. Useful to fix ghost calls and stuck transfers

• siptracker <SIP_PEER> hangup <CHANNEL> — hang up a specific call channel and remove it from the tracker

• siptracker <SIP_PEER> stop — stop the tracker for that peer. It is recreated cleanly when the user reconnects (the user must refresh their assistant)

Selecting by extension instead of peer name works the same way, for example:

siptracker --exten 1001 info
siptracker -e 1001 clearcalls

For example, siptracker --driver PJSIP 1p7b9k7f info prints:

[xuc.services.calltracking:type=SipDeviceTracker,name=PJSIP_1p7b9k7f-]
        - Extension: 1600
        - Interface: PJSIP/1p7b9k7f
        - Calls: 0
        - CurrentCalls:
        - ChannelEvent: 0
        - PartyInformations: 0
        - PathsFromChannel: 0

And siptracker -e 1600 hangup PJSIP/1p7b9k7f-00000015 prints:

OK: Command Successful