This document was generated from CDN thread
Created by: Christopher Nagel on 12-07-2010 03:49:34 PM
In the documentation, it says this value on the Agent object will be 0, 1 or 2:
CTIOS_INCOMINGOROUTGOING indicates the direction of the call. The defined values are
0 = the direction of the call is unknown
1 = the call is an incoming call and the agent may enter wrapup data
2 = the call is an outgoing call and the agent may not enter wrapup data
This value may be obtained using the GetValueInt method on the Agent object.
(p4-54, Cisco CTI OS Release 7.0(0), July 2005)
However, I am seeing values like: 21327 in my logs.
Is this a bad cast in the Arguments.toString() method? Are there times when this value should be considered invalid and not tested?
Thanks,
Chris
Subject: RE: IncomingOrOutgoing - garbage values?
Replied by: Shannon McCoy on 15-07-2010 09:08:21 AM
I had similar problems on a 7.2 Monitor mode app. What I did was monitor the call events and if the Dialed Number was the same as the agents extension then it is inbound if the Dialing Number is the agents extension the call is outbound. I found the Incoming and Outgoing values to be useless.
Subject: RE: IncomingOrOutgoing - garbage values?
Replied by: Christopher Nagel on 15-07-2010 06:01:21 PM
I had similar problems on a 7.2 Monitor mode app. What I did was monitor the call events and if the Dialed Number was the same as the agents extension then it is inbound if the Dialing Number is the agents extension the call is outbound. I found the Incoming and Outgoing values to be useless.
Thanks, Shannon.
I've added this method to my event sink object. Turns out that the remote ID changes places, depending on the event (e.g., AnsweringDeviceID, CallingDeviceID, etc.). Wish there was a constant key such as "RemoteDeviceID" but this allows me just to pass in the individual keys as needed.
Also - I hope this works within OnAgentStateChange (e.g., that CTIOS_ANSWERINGDEVICEID survivies the life of the call, not just until OnCallEstablished...)
/**
* Provides a way to see if the value of the passed device key in the args applies to the
* current agent's instrument number, thereby telling the programmer that the agent's side of
* the call segment is the one to which the action applies.
*
* The power of the Cisco CTI stream is that you can see all events, everywhere. It's also
* the curse.
*
* @param curArgs
* @param deviceKey
* @return boolean
*/
private boolean compareDevice( Arguments curArgs, int deviceKey )
{
String specifiedDevice = curArgs.GetValueString( deviceKey );
if( myDeviceConstant == null )
try {
myDeviceConstant = m_appFrame.myCTIData.getConstant("agentExtension") ;
if( myDeviceConstant == null )
throw new IllegalArgumentException( "Can't get agent instrument for event filter." );
} catch( Throwable e ) {
return false;
}
if( (specifiedDevice != null && specifiedDevice.equals(myDeviceConstant) )
|| specifiedDevice == null )
return true;
else
return false;
}
Subject: RE: IncomingOrOutgoing - garbage values?
Replied by: Shannon McCoy on 17-07-2010 12:49:24 AM
There are a bunch of interesting things in there. I have hundreds of call traces that I created on a live system with 100+ agents and isolated out the call traffic to look for patterns. One that was a complete bugger was RONA vs AWR calls. It turns out that if you look at the Not Ready State change message and look at the ReasonCode it is 32767 only on RONA calls when the Agent is made not ready after not answering the call. That only took a month to find.
The answering device does seem to survive the life of the call but its not in every message. I do a dump args trace to a file and it is suprising how many arguments are not documented but in the args collection. The only way to get the real picture is to do full dump to a file on every event for a couple of days and then trace back through it. Some pretty interesting stuff in there. Well maybe not interest But informative. Oh Brother, I need to get a life.........
Created by: Christopher Nagel on 12-07-2010 03:49:34 PM
In the documentation, it says this value on the Agent object will be 0, 1 or 2:
CTIOS_INCOMINGOROUTGOING indicates the direction of the call. The defined values are
0 = the direction of the call is unknown
1 = the call is an incoming call and the agent may enter wrapup data
2 = the call is an outgoing call and the agent may not enter wrapup data
This value may be obtained using the GetValueInt method on the Agent object.
(p4-54, Cisco CTI OS Release 7.0(0), July 2005)
However, I am seeing values like: 21327 in my logs.
Is this a bad cast in the Arguments.toString() method? Are there times when this value should be considered invalid and not tested?
Thanks,
Chris
Subject: RE: IncomingOrOutgoing - garbage values?
Replied by: Shannon McCoy on 15-07-2010 09:08:21 AM
In the documentation, it says this value on the Agent object will be 0, 1 or 2:
CTIOS_INCOMINGOROUTGOING indicates the direction of the call. The defined values are
0 = the direction of the call is unknown
1 = the call is an incoming call and the agent may enter wrapup data
2 = the call is an outgoing call and the agent may not enter wrapup data
This value may be obtained using the GetValueInt method on the Agent object.
(p4-54, Cisco CTI OS Release 7.0(0), July 2005)
However, I am seeing values like: 21327 in my logs.
Is this a bad cast in the Arguments.toString() method? Are there times when this value should be considered invalid and not tested?
Thanks,
Chris
I had similar problems on a 7.2 Monitor mode app. What I did was monitor the call events and if the Dialed Number was the same as the agents extension then it is inbound if the Dialing Number is the agents extension the call is outbound. I found the Incoming and Outgoing values to be useless.
Subject: RE: IncomingOrOutgoing - garbage values?
Replied by: Christopher Nagel on 15-07-2010 06:01:21 PM
I had similar problems on a 7.2 Monitor mode app. What I did was monitor the call events and if the Dialed Number was the same as the agents extension then it is inbound if the Dialing Number is the agents extension the call is outbound. I found the Incoming and Outgoing values to be useless.
Thanks, Shannon.
I've added this method to my event sink object. Turns out that the remote ID changes places, depending on the event (e.g., AnsweringDeviceID, CallingDeviceID, etc.). Wish there was a constant key such as "RemoteDeviceID" but this allows me just to pass in the individual keys as needed.
Also - I hope this works within OnAgentStateChange (e.g., that CTIOS_ANSWERINGDEVICEID survivies the life of the call, not just until OnCallEstablished...)
/**
* Provides a way to see if the value of the passed device key in the args applies to the
* current agent's instrument number, thereby telling the programmer that the agent's side of
* the call segment is the one to which the action applies.
*
* The power of the Cisco CTI stream is that you can see all events, everywhere. It's also
* the curse.
*
* @param curArgs
* @param deviceKey
* @return boolean
*/
private boolean compareDevice( Arguments curArgs, int deviceKey )
{
String specifiedDevice = curArgs.GetValueString( deviceKey );
if( myDeviceConstant == null )
try {
myDeviceConstant = m_appFrame.myCTIData.getConstant("agentExtension") ;
if( myDeviceConstant == null )
throw new IllegalArgumentException( "Can't get agent instrument for event filter." );
} catch( Throwable e ) {
return false;
}
if( (specifiedDevice != null && specifiedDevice.equals(myDeviceConstant) )
|| specifiedDevice == null )
return true;
else
return false;
}
Subject: RE: IncomingOrOutgoing - garbage values?
Replied by: Shannon McCoy on 17-07-2010 12:49:24 AM
I had similar problems on a 7.2 Monitor mode app. What I did was monitor the call events and if the Dialed Number was the same as the agents extension then it is inbound if the Dialing Number is the agents extension the call is outbound. I found the Incoming and Outgoing values to be useless.
Thanks, Shannon.
I've added this method to my event sink object. Turns out that the remote ID changes places, depending on the event (e.g., AnsweringDeviceID, CallingDeviceID, etc.). Wish there was a constant key such as "RemoteDeviceID" but this allows me just to pass in the individual keys as needed.
Also - I hope this works within OnAgentStateChange (e.g., that CTIOS_ANSWERINGDEVICEID survivies the life of the call, not just until OnCallEstablished...)
/**
* Provides a way to see if the value of the passed device key in the args applies to the
* current agent's instrument number, thereby telling the programmer that the agent's side of
* the call segment is the one to which the action applies.
*
* The power of the Cisco CTI stream is that you can see all events, everywhere. It's also
* the curse.
*
* @param curArgs
* @param deviceKey
* @return boolean
*/
private boolean compareDevice( Arguments curArgs, int deviceKey )
{
String specifiedDevice = curArgs.GetValueString( deviceKey );
if( myDeviceConstant == null )
try {
myDeviceConstant = m_appFrame.myCTIData.getConstant("agentExtension") ;
if( myDeviceConstant == null )
throw new IllegalArgumentException( "Can't get agent instrument for event filter." );
} catch( Throwable e ) {
return false;
}
if( (specifiedDevice != null && specifiedDevice.equals(myDeviceConstant) )
|| specifiedDevice == null )
return true;
else
return false;
}
There are a bunch of interesting things in there. I have hundreds of call traces that I created on a live system with 100+ agents and isolated out the call traffic to look for patterns. One that was a complete bugger was RONA vs AWR calls. It turns out that if you look at the Not Ready State change message and look at the ReasonCode it is 32767 only on RONA calls when the Agent is made not ready after not answering the call. That only took a month to find.
The answering device does seem to survive the life of the call but its not in every message. I do a dump args trace to a file and it is suprising how many arguments are not documented but in the args collection. The only way to get the real picture is to do full dump to a file on every event for a couple of days and then trace back through it. Some pretty interesting stuff in there. Well maybe not interest But informative. Oh Brother, I need to get a life.........