We are developing a CTI bridge between a Cisco CTI server and our software, using GED-188 version 16.
We appear to receive four GED-188 BEGIN_CALL_EVENT messages when 'agent4' dials '4000', using our test system. The telephone system processes the phone call and then passes it onto the "ready" 'agent1'.
Agent: agent4 agent1 (ready)
Extension: 4004 -->> 4001
Peripheral: 5004 5000
Using Wireshark, I see the four network messages - which appear below:
|BEGIN_CALL_EVENT||event 1||event 2||event 3||event 4|
|Peripheral Type:||PT_ENTERPRISE_AGENT (17)||PT_VRU (8)||PT_VRU (8)||PT_ENTERPRISE_AGENT (17)|
|Number CTI Clients:||0||0||0||0|
|Number Named Variables:||3||0||0||3|
|Number Named Arrays:||0||0||0||0|
|Call Type:||CALLTYPE_ACD_IN (1)||CALLTYPE_ACD_IN (1)||CALLTYPE_ACD_IN (1)||CALLTYPE_PREROUTE_ACD_IN (2)|
|Connection DeviceID Type:||CONNECTION_ID_STATIC (0)||CONNECTION_ID_STATIC (0)||CONNECTION_ID_STATIC (0)||CONNECTION_ID_DYNAMIC (1)|
|Called Party Disposition:||0||0||0||0|
|DNIS:||4000||<not supplied>||<not supplied>||4001|
|Dialled Number:||<not supplied>||<not supplied>||<not supplied>||4000|
|Router Call Key Day:||150987||<not supplied>||<not supplied>||150987|
|Router Call Key CallID:||206||<not supplied>||<not supplied>||206|
|Router Call Key Sequence|
|1||<not supplied>||<not supplied>||4|
|Call Variable 1:||<not supplied>||<not supplied>||<not supplied>||Test1|
|Call Variable 10:||<not supplied>||<not supplied>||<not supplied>||Test10|
|Named Variable:||user.microapp.media_server||<not supplied>||<not supplied>||user.microapp.media_server|
|Named Variable:||user.microapp.UseVXMLParams||<not supplied>||<not supplied>||user.microapp.UseVXMLParams|
|Named Variable:||user.microapp.locale||<not supplied>||<not supplied>||user.microapp.locale|
I am only interested in the last BEGIN_CALL_EVENT message of the four, so we can do some work in our application to match the phone call arriving with the agent.
I reason we get issued four messages, as the phone call is "transferred" through a workflow before ringing the device for agent1.
My questions are:
1. is it "normal" to receive BEGIN_CALL_EVENT messages as a call is passed through the workflow (is my reasoning correct)?
2. what is the best [Cisco-friendly] approach to filter the "noisy" messages, to allow for [unknown and uncontrollable] on-site configuration?
3. what fields can reliably be used to select the last message (currently using the presence of Dialled Number!), so the code will work against other installations?
4. should we maintain state between messages as the order is not guaranteed (how can they be reliably associated?)?
it looks like you have multiple peripherals set up in a single PG. So the CTI Server connected to that PG will receive all of the events for each of the peripherals, and since each Peripheral is reporting the Begin_call for that particular Peripheral it will have the Call ID of the call as known by that peripheral. Also, the call is being transfer via the IVR. So there is a call leg from agent 4004 to the VRU, which is reported by each of the peripherals with its own Call ID. Then there is a call leg set up from the VRU back to Agent 4001, again report by each Peripheral with its own CallID.
You have to look at the Peripheral ID to know which call events to filter out. If you only care about the events corresponding to the Agents devices then you would only look at the events coming from Peripheral ID 5000.
Also, I’m thinking that the VRU in this case is CVP, and you have it set up as a Type 10, so that the VRU will remain in the call the whole time the call is up, you have to realize that there are two call legs set up for every call between two agents.
Thanks for your response,
Using the peripheral ids allows us to ignore the second and third message, but it doesn't allow us to disambiguate between the first and fourth messages since they have the same id. Is there any other information we can use to identify a single call when receiving multiple begin call event messages? Looking at the messages, they have different call types and connection device id types, but can we always rely on this behaviour? Or do we have to aggregate multiple messages to the same peripheral to identify a single call?