Hi,
When we transfer a call to a number using a Data Action and eventually the PostConversationsCallParticipantReplaceRequest , it seems that the UUIData defined in the flow for transfers do not get transferred.
If we transfer the call to a number explicitly from within the flow, the UUIData are transferred as expected.
Shouldn't we expect the same behaviour in these two scenarios? Any thoughts?
Regards,
Nikos
Can you please provide us with some feedback regarding this case? Thank you.
Hi Nikos,
This isn't a formal support channel for Genesys Cloud. I recommend that you open a case with Customer Care to investigate this issue.
--Jason
Hello,
I don't know and I don't have details on how Architect works underneath.
But I can confirm that when you use a "Set UUI Data" block in your Architect flow, it doesn't translate into an immediate API request to get UUI data updated/attached to the call.
The UUI data defined in the "Set UUI Data" block is in fact buffered by Architect and managed at the end of the flow (when processing the Architect Transfer or Disconnect blocks).
This explains why you don't see it when you transfer the call via your own API call (through Data Action or else).
I think you could:
Either have your Data Action provide an answer back to the Architect flow, indicating transfer type (queue, user, number) and transfer address/number, and use the regular Transfer blocks in Architect.
Or possibly do the update of UUI Data yourself (in your DataAction) before triggering the transfer.
A PUT on /api/v2/conversations/calls/{conversationId}/participants/{participantId}/communications/{communicationId}/uuidata (Set uuiData to be sent on future commands) might work while the call is under the control of Architect IVR (UUI Data for Transfer case).
But I can't say for sure (as I haven't tried it from there).
Regards,
Very interesting suggestions! Thank you! Will give it a try!
FYI for future reference, @Jerome.Saint-Marc , unfortunately the PUT update attempt failed.
The first suggested approach (return to the flow and then transfer) would defeat the purpose of our scenarios since we want to explicitly create the transfer using the API on our side.
If you have any other suggestions please feel free to comment.
Thank you.
Hello,
Yes, I just tried and the request is rejected when using client credentials grant. It requires a user context (i.e. Implicit Grant or Authorization Grant).
I have tried with another conversation method to update the participant directly, but it is also rejected - it requires to be an active participant in the conversation.
This appears to be done "by design" (on purpose).
So unfortunately, I don't have other suggestions/ideas.
I mean that if it is to carry uuiData up to agents/scripts, then I would say to extract the uuiData in the Architect Flow and attach them as Participant Data (participant's attributes).
If it is to set UUI Data because you are transferring the call to an external number and you want that data to be carried to an external system (gateway, SBC, media server) via SIP, then, I don't see a way.
Still one question if this is what you are doing: is it to provide some data to that external system? or to allow you to correlate a SIP call (SIP CallID) with a Conversation (ConversationId)?
First of all thank you for your time and effort @Jerome.Saint-Marc.
Allow me to explain our case.
Initially, the requirement was to transfer to an external IVR and once the call was completed there to return to the same flow on Genesys at the point we did the transfer ideally retrieving some data from the external system. We were informed that this is not possible and that the returned call from the external IVR back to Genesys would be a new call (new conversationId etc.) starting from the beginning of the flow.
Having that in mind, what we are attempting now to accomplish is a combination of both cases you mentioned :
Any suggestion would be greatly appreciated.
Do you have access to the SIP CallId of the "inbound call" to this external system (assuming it is transferred via SIP trunk and not going through the PSTN/PLMN)?
I mean for the call arriving from PureCloud (and the call initiated back to PureCloud), can your system retrieve the SIP CallID of the call that gets connected to it?
If yes, I may have an idea on how your system could find/identify the conversation on PureCloud side (not using UUI).
Sorry - another question - what is the reason to trigger the transfer to your external IVR using the Data Action then? I mean why can't you give control back to the Architect Flow to trigger the transfer to this external number (to preserve UUI)?
I will have to verify it, but I believe it is possible to retrieve the SIP CallId on the external system so yes please do elaborate on your suggestion.
The reason of triggering the transfer through Data Action was to be able to control the call flow on our side and perform any additional custom business logic on our end. In addition, to evaluate all possible options of call control.
I would strongly suggest to give the control back to the Architect flow, to trigger the transfer, so UUI Data works.
Having said that, regarding SIP CallID.
I have tested the following with BYOC Cloud (virtual edges). I would assume this also works with BYOC Premise (and local/on-premise Edges) - but this would have to be tested/tried (if this is a type of environment you target as well).
The information is available as part of Analytics Conversation Details.
There is a "protocolCallId" attribute, in the conversation -> participant -> session.
If you take the first participant on an inbound call (customer/external), the "protocolCallId" will contain the SIP CallID of the incoming call (coming from the SIP Trunk Provider/gateway/...).
In your case, if you take the last participant (which should correspond to your external number), the "protocolCallId" should contain the SIP CallID that PureCloud will set on the outgoing SIP INVITE to your system (the SIP CallID you should receive on your side).
If you know the ConversationId, you can just use a GET on /api/v2/analytics/conversations/{conversationId}/details and retrieve the SIP CallID.
If you know the SIP CallID, you can perform a query on conversation details (POST on /api/v2/analytics/conversations/details/query) using a segment filter on protocolCallId
The Analytics Query Builder (Dev Tools) doesn't expose it - but it is listed (and of course working) in the available dimensions (search) for Conversation Details: https://developer.mypurecloud.com/api/rest/v2/analytics/dimensions.html
The drawback of that approach is that you need to rely on the Analytics. Conversation Details are to be pushed in realtime (or close to), even when conversation is still active. But if there is a problem with that service (I mean if ever there are some issues going on with that Analytics service in a region, in a degraded situation), you may not get the result through these 2 requests.
So you'd have to plan on how to handle this if ever this happens (just in case).
That's why I was strongly suggesting to provide the control back to Architect flow to perform the transfer, and leverage UUI Data - as this one doesn't not rely on upper service.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.