[cisco-voip] CTI & CCM SDL Trace Question

Tue Apr 15 14:15:22 EDT 2014

Excellent - I'll check out CTI Manager traces covering the registration of the JTAPI client. I'm guessing I'll see new instances of CTIHandler created for each registration.

Thanks again

- Daniel

From: Wes Sisk (wsisk) [mailto:wsisk at cisco.com]
Sent: Tuesday, April 15, 2014 1:07 PM
To: Daniel Pagan
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] CTI & CCM SDL Trace Question

ctiList.size reflects the number of CTIHandlers that have registered to receive updates. Registering to receive updates usually happens at app initialization time. Does the user for the app have correct roles and permissions for CTI control, park monitoring, etc.

when the CTI application restarts, re-initializes, or gets de-associated/re-associated with the device then the traces show the ProviderOpen, DevliceList retrieval, filter settings for interested events, and device/line opens.

-Wes

On Apr 15, 2014, at 11:23 AM, Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>> wrote:

Wes

Thanks for the response - I figured the third section described some type of state but didn't know it was for the destination process. That's really helpful.

As for the issue at hand...

I'm comparing a working and non-working scenario, specifically destination process state where the destination is our new instance of CallPark. The process state remains the same across both sets of traces between the park request to StationD and park response from StationD. However, immediately after CallPark receives SsSplitRes with a state of splitting_primary_call, one thing that stands out is this:

NOTE:   1,200,22,1 is referring to CTIHandler
                CallPark sends two CtiCallParkNotify SDL signals to CTIHandler

NON-WORKING SCENARIO - Call is not displayed
|AppInfo  |sendCallParkNotify ctiList.size[0]

NOTE:   CallPark sends zero SDL signals to CTIHandler

Do you know what controls the value of ctiList.size?
CUCM version is 9.1.2.11900-12

- Daniel

From: Wes Sisk (wsisk) [mailto:wsisk at cisco.com]
Sent: Tuesday, April 15, 2014 11:58 AM
To: Daniel Pagan
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] CTI & CCM SDL Trace Question

Daniel,

Nice analysis. In SDL a signal is sent out in response to timer pop or inbound event (a timer pop is actually just another inbound event).
What message goes to CallPark just before CtiCallParkNotify is correctly generated? What state is CallPark in when the message is received?

When CtiCallParkNotify is not sent what is the last message sent to CallPark and what state is CallPark in?

|SignalType    |Signal                             |destination_process_state                           |destination_process       |source_process

"Notify there is a new call to CTI if Park DN is monitored"

What version?
CSCsy69043    No Partition reported to CTI Application when call is parked
CSCtc38841    ParkDN is not OnHold while the call is parked

-Wes

On Apr 15, 2014, at 10:11 AM, Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>> wrote:

Folks:

I'm hoping someone can tell me the purpose of the SDL event "CtiCallParkNotify" sent from CallPark to CTIHandler. During a call park event from a JTAPI client, I'm seeing the standard SDL event "CtiLineCallParkReq" from CTIDeviceLineMgr to StationD and the proper response "CtiLineCallParkRes" from StationD back to CTIDeviceLineMgr. However, I'm looking at a situation where a JTAPI application fails to actually display the parked call and the only different between a working and non-working scenario is the CtiCallParkNotify event that's sent directly from the new process instance of CallPark. When this SDL event is missing, the application does not display the parked call. When it's present in SDL traces, information about the parked call is displayed by the application.

So my question is, what exactly is this specific SDL event (CtiCallParkNotify) used for? Any information on this event would be appreciated.

Thanks ahead of time.

- Daniel
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140415/14b339d1/attachment.html>