Co-browse not working with REM SDK and Expert Assist in same app instance for calls number 2 ...

[briwilli@cisco.com]

This error was reported to me by a customer with REM SDK 10.6.3 and Expert Assist SDK 10.6.1 for both Android and iOS apps. I have replicated the customer results with a different iOS app in a different REAS lab.

When I assure previous call and session have ended and obtain a fresh session ID, client with a second call in same application instance does not ever receive the popup prompt to accept CoBrowse/sharing but co-browsing is able to continue (is rejoined). Noted also that to assure a fresh session ID, I had to perform the logout step from the Session Token server. I’ve extended the client to also use a  fresh correlation ID with each call, and that has the related issue of not offering co-browse popups for customer to accept. In this case, previous co-browse session is not rejoined and there is no co-browsing.

[robdoyle]

Hi,

What id the agent console you are using? Finesse? ExpertAssist? Bespoke?

In the second scenario with different session id and correlation ID does the agent side get the call or use the new correlation ID?

If so does the agent request the screen share?

Thanks,

Rob

[briwilli@cisco.com]

Hi Robert,

I should have mentioned that it is the Finesse agent desktop. Agent side gets the call with new correlation ID (I also change the SIP username to match the new correlation ID. ) The call is placed using the REM advanced SDK , and we start Expert Assist in co-browse only mode. Agent click the button in the EA gadget to co-browse and sees notifications that the caller had not accepted the co-browse session. The caller never sees the popups alerts to accept the co-browse after the first call. Only way to see the alert again is to completely restart to iOS app.

Thank you,

Brien

[briwilli@cisco.com]

robdoyle We have another anomaly to report. In number 1 of the scenario, we are receiving 3 alerts prompting to allow sharing. Co-browsing starts immediately on with a yes response to the first alert. The next two alerts appear to be superfluous. I don't know that this is related to the case, but is not a satisfactory experience on the iOS client.

[robdoyle]

Hi Brien,

1. The scenario where the consumer starts a fresh co-browse with the same CorrelationID is expected behaviour...

Once the consumer has granted permission to cobrowse, any agent can join and see the cobrowse without requesting permission. From the Consumer’s point-of-view, they have decided to share their screen to that cobrowse correlationID, irrespective of the connected agents. And will continue to do so whilst they’re connected to the cobrowse or if they leave and rejoin it. Permission has been granted to all agents and not just a particular agent. If you want the consumer to see the allow sharing alert for a fresh co-browse you will need to use a new correlationID.

2. I haven't seen the multiple allow sharing alerts issue. Are you able to share the app or a cut down version of it with the API calls you are making?

3. Regarding the issue where no allow sharing alert is seen on subsequent co-browse with different CorrelationID until the application is restarted. I'll test that and get back to you.

Regards,

Rob

[briwilli@cisco.com]

Hi Robert,

Right, for your question 1, I thought the problem might have been that the customer's client app was just not generating a new correlation ID. So, the real issue that surprised me was the issue as in question 3 where new correlation ID's are generated with each call.

As far as your question 2, app-sharing does work after the client accepts the first popup to allow sharing. That is, the agent can press buttons on the iOS client view that is presented and those do respond as expected in the client app.

Thank you,

Brien

[robdoyle]

Hi Brien,

Testing with the sample app I don't see issues 3.

Subsequent co-browse sessions always prompt the user to accept screen share when the agent requests it.

Also I can't reproduce issue 2.

Only one pop-up is presented to the consumer for each screen share session.

Can you provide access to your app?

[briwilli@cisco.com]

Hi Robert.

Issue 3 occurs in an app that is a combination of using the advanced CSDK for the calling and starting the ExpertAssist SDK in co-browse only mode.

Brien

[robdoyle · Accepted solution]

Hi Brien,

I tested once more just using ExpertAssist SDK in co-browse only mode to isolate the issue and as before subsequent co-browse sessions always prompt the user to accept screen share when the agent requests it.

Please check the console logs via xcode for the value of the RootTopic for subsequent calls to startSupport. you will need to call endSupport on the client side to avoid using the old ID for subsequent calls.

Regards,

Rob

[briwilli@cisco.com]

Hi Robert,

I want to thank you so much for your support. It seems as if the whole train of issues related to using Expert Assist co-browse in conjunction with the CSDK (advanced) has to to with properly cleaning up sessions at the right time in the right way. I got part way there with properly logging-off CSDK sessions and generating new correlation IDs, but I never knew about Expert Assist having its own endSupport method (we probably need to add this to the sample app.) After seeing your message and adding endSupport, it becomes very predictable (in iOS at least) when I get too many or too few prompts to allow a co-browse. The customer has a few more questions around Android (I haven't worked with that specifically, but there appear to be some of the some issues.) One thing they are not seeing in Android is the "Toast" that app sharing is in force. I've contacted an Android developer and we will try to recreate and open a new case if needed.If you happen to already have encountered this issue, please let us know. Thanks again