Webex Customer Assist join/unjoin status not propagated within XSI

[DevTeamAkixi]

We’ve run into a weird issue with the Webex Calling API: XSI API, which comes from the old BroadWorks setup. As you probably know, the XSI API has two bits:

• XSI-Actions: standard request/response style
• XSI-Events: real-time streaming events

The question is about the Webex features:

• Call Queue
• Customer Assist

Both use BroadWorks' Call Queue tech under the hood, so you'd expect them to work pretty much the same with the XSI API... but that’s not quite happening.

For regular Call Queues, everything works fine:

• You can see join/unjoin status with XSI-Actions

• Those status changes also show up in XSI-Events

But with Customer Assist queues:

• The join/unjoin status is completely missing from both XSI-Actions and XSI-Events

• Everything else works though:
  • Call events and ACD events come through fine
  • Other XSI-Actions requests work as expected
  • Streaming is fine, just missing the join/unjoin part

So yeah its not a total failure, just a partial gap in functionality.

Ideally, Customer Assist queues should behave just like Call Queues:

• We should be able to pull join/unjoin status via XSI-Actions

• And see the same updates streamed via XSI-Events

Here’s the XSI-Actions request that is in question:

GET https://{server}/com.broadsoft.xsi-actions/v2.0/user/<subscriberid>/services/callcenter

And the response is like:

<?xml version="1.0" encoding="ISO-8859-1"?>
<CallCenter xmlns="http://schema.broadsoft.com/xsi">
  <agentACDState>Sign-In</agentACDState>
  <useDefaultGuardTimer>true</useDefaultGuardTimer>
  <enableGuardTimer>false</enableGuardTimer>
  <guardTimerSeconds>5</guardTimerSeconds>
  <useSystemDefaultUnavailableSettings>true</useSystemDefaultUnavailableSettings>
  <forceAgentUnavailableOnDNDActivation>false</forceAgentUnavailableOnDNDActivation>
  <forceUnavailableOnPersonalCalls>false</forceUnavailableOnPersonalCalls>
  <forceAgentUnavailableOnBouncedCallLimit>false</forceAgentUnavailableOnBouncedCallLimit>
  <numberConsecutiveBouncedCallsToForceAgentUnavailable>3</numberConsecutiveBouncedCallsToForceAgentUnavailable>
  <makeOutgoingCallsAsCallCenter>false</makeOutgoingCallsAsCallCenter>
  <callCenterList>
    <callCenterDetails>
      <serviceUserId>g1PremiumCallCenter</serviceUserId>
      <available>true</available>
      <phoneNumber>9728880010</phoneNumber>
      <extension>0010</extension>
      <isLogOffAllowed>true</isLogOffAllowed>
      <skillLevel>9</skillLevel>
    </callCenterDetails>
  </callCenterList>
</CallCenter>

But when you hit the same endpoint where the user is logged into Customer Assist Queue, You don’t see anything in <callCenterList>.

Like wise, on an event subscription, for Call Queues, we get ACDAgentJoinUpdateEvent updates through the “Call Center Agent” event package.

But when an agent is part of Customer Assist, that event doesn’t let us know anything about Customer Assist. So we’re in the dark about join/unjoin updates.

Could you guys take a look and help us understand what’s going on here?

• Is this a known bug and is already registered within your internal system?
• If so, do you know when this is planned to be fixed?

Also, if you’ve got any workarounds, that’d be super helpful to know.

[bigevilbeard]

@DevTeamAkixi I would suggest opening a tax case for this and asking if they believe this is a bug or possible fix/solution.

[alonso845]

Hi @DevTeamAkixi,

This is a known limitation — Customer Assist queues don’t expose join/unjoin state via XSI-Actions or XSI-Events, unlike standard Call Queues. Engineering is aware, but there’s no GA fix date yet. The current workaround is to track agent status indirectly (via call/ACD events or Control Hub APIs if applicable). I’d recommend opening a TAC case so your scenario can be linked to the defect and you can get updates.

[Stefan Mihajlov]

@DevTeamAkixi 

You’ve tested this correctly — what you’re running into isn’t a mis-use of the XSI API, it’s a gap in Webex Calling’s Customer Assist implementation.

Customer Assist is built on BroadWorks call center primitives, but Cisco never wired up the agent join/unjoin state exposure into the XSI layer. That’s why you see normal call queue agents fully represented in both XSI-Actions and XSI-Events, but Customer Assist agents don’t show up in <callCenterList> and don’t generate ACDAgentJoinUpdateEvent.

This isn’t something you can fix from your side — it’s a platform limitation. Cisco has acknowledged it as a defect/feature gap (internal bug record exists) and the fix is being tracked for a future Webex Calling update. There isn’t a public ETA yet.

Workarounds today:

• You can still see sign-in / sign-out state for the agent via XSI, but you won’t see Customer Assist queue membership changes.

• If you absolutely need visibility, the only option is to monitor call events instead of relying on join/unjoin status — not ideal, but at least lets you track activity.

So bottom line: you aren’t missing anything in your implementation, this is a known shortcoming of Customer Assist in Webex Calling. Best step is to raise a TAC case or feature request through your Cisco account team so your requirement is logged against the fix.

–––
Best regards,
Stefan Mihajlov

Mark this post as Helpful if it helped you, and Accept as Solution if it resolved your question.

[DevTeamAkixi]

That is really helpful. Thanks for that.

I have few more questions:

1. Do you have public view of the tracked bug, so we know the status without pestering people in the forum?
2. Also to raise a TAC case or feature request, where do we do this?
3. Is there an alternative Webex API to get the join/unjoin status as we see on admin.webex.com like below screenshot?

[DevTeamAkixi]

Can I get a response to my message please?

[bigevilbeard]

@DevTeamAkixi from what i see in the reply from @Stefan Mihajlov  the bug case is an internal bug, so dont think this can be provided. The link here to raise a tac case or you can do this via your cisco account manager https://www.cisco.com/c/en/us/support/web/tac/technical-services-resource-guide.html 

Hope this helps.