Morten_Sobyskogen | 2017-03-27 11:16:40 UTC | #1
Hello! Sorry if this is in the wrong category. I wondered if its possible to get some help with this: What are the correct parameters on the CallConversationNotificationParticipants to check on for determining if a call has been answered?
this.notificationHandler = new NotificationHandler(); this.notificationHandler.AddSubscription($"v2.users.{User.Id}.conversations.calls", typeof(CallConversationNotification));
When testing an incoming call, the NotificationHandler_NotificationReceived eventhandler is hit, and I extract the callData which contains the participants:
var callData = notificationData as NotificationData<CallConversationNotification>;
I then extract the caller and reciever into two CallConversationNotificationParticipants objects, and I have to find out when the call has been actually answered and then invoke the OnIncomingCall-method.
The problem is I cant seem to find the correct things to check for if a call has been answered. For example the following does not work, since the Connected StateEnum is connected several times, so this is nothing I can compare on:
if (caller.Direction.Value == CallConversationNotificationParticipants.DirectionEnum.Inbound && caller.State == CallConversationNotificationParticipants.StateEnum.Connected && receiver.State == CallConversationNotificationParticipants.StateEnum.Connected ) { this.OnIncomingCall(this, new CallEventArgs() { CallId = caller.Id, TelephoneNumber = caller.Address }); }
Hope you could help me with some tips on how to get this correct, Ill supply more information if needed.
Thanks, Morten
tim.smith | 2017-03-27 15:02:37 UTC | #2
If you're trying to determine if a participant is connected, check the participant's state property and look for the value connected.
If you're trying to determine the event that indicates when a participant is connected, you'll need to track the state of the participant over time. This could be done by using Dictionary<string, bool> (conversation ID, agent connected) to keep track of conversation IDs and if the agent is connected to that conversation or not.
When you get an event, if the conversation isn't in the list, add it and check the connected state of the agent. If it is in the list, compare the cached connection state with the current state. If it's false->false or true->true, do nothing. If it's false-> true, that's your connected event. If it's true->false, that's your disconnected event.
Morten_Sobyskogen | 2017-03-27 16:19:06 UTC | #3
Thanks for replying. I guess my question is, if the caller (customer) and reciever (agent) has State = connected, can I assume that the incoming call has been answered by the agent and is active?
It seems when the event is raised for an incoming call, not yet being answered by an agent (me), the caller is state is connected and the agent state is Alerting. Connected time is null for agent. When I answer, the event is raised again and the state is connected for both agent and caller, and connectedtime has a value for the agent also.
The strange thing is, while in this state, the event is raised three times more. Is there any reason this should happen once the agent has answered the incoming call?
tim.smith | 2017-03-27 16:26:39 UTC | #4
if the caller (customer) and reciever (agent) has State = connected, can I assume that the incoming call has been answered by the agent and is active?
Definitely not. The state of one participant has no bearing on the state of another. The conversation model in PureCloud is not a 1:1 entity. If a participant is connected, it means that their media is connected to PureCloud; there is no implication that the participant is interacting with anyone or anything. The only implication is that any connected participants in a conversation are interacting (save for muted/held participants).
The strange thing is, while in this state, the event is raised three times more. Is there any reason this should happen once the agent has answered the incoming call?
Events are raised any time any data for any part of the conversation changes. This could be a state change, but it could also be assigning wrap up codes, altering participant attributes, the system updating computed properties (e.g. endTime), etc. This is why it's useful to use the design pattern of caching information that is useful to you and comparing your cache with the incoming data to see if anything you care about has changed.
system | 2017-08-28 19:33:22 UTC | #5
This post was migrated from the old Developer Forum.
ref: 1107