Wrapping up on this one. The resolution was disabling the Cluster-Wide Call Park service parameter. Setting this to FALSE and restarting CUCM resolved the issue. In the "New and Changed Information" section for CUCM 8.6(2), it's mentioned that this feature will disable CTI monitoring of park DNs but further states it will be restored in CUCM 9.0.
Description: Cluster-Wide Call Park Description Cisco Unified Communications Manager 8.6(2) allows you to enable call parking for cluster-wide configurations. The following changes are introduced with this feature: *Park codes for all nodes in a Cisco Unified Communications Manager cluster are now allocated from a single entity, the lowest active node in the cluster. Therefore, Unified CM ignores the Cisco Unified Communications Manager field on the Call Park Configuration web page. *The single entity allocates park codes from a pool of all configured park codes, regardless of which Unified CM is assigned. *Unified CM allocates park codes through strict enforcement of the partition order in the Calling Search Space (CSS) of the parking party. This update provides a predictable behavior that is easy for administrators to understand. *The parked calls limit is no longer 100 calls per cluster. Available park codes and system resources determine the number of parked calls. *CTI monitoring of parked call Directory Numbers (DNs) is unavailable. This function will be restored in Unified CM Release 9.0. Customer is on 9.1(2) SU1 so perhaps it's still unavailable. Thanks for the assistance earlier. - Daniel From: Wes Sisk (wsisk) [mailto:ws...@cisco.com] Sent: Wednesday, April 16, 2014 2:04 PM To: Daniel Pagan Cc: cisco-voip@puck.nether.net Subject: Re: [cisco-voip] CTI & CCM SDL Trace Question "invalid parkDN" happens when ccm fails to resolve the passed partition name back to an associated PKID. Is there an overlap? Overlaps sometimes create interesting situation where they may or may not work based on order of device/feature initialization including device resets/restarts. Is the CTI application running updated version of jtapi or TSP? -Wes On Apr 16, 2014, at 10:31 AM, Daniel Pagan <dpa...@fidelus.com<mailto:dpa...@fidelus.com>> wrote: Wes Digging through traces covering the launch and login of the JTAPI application shows the following events on Node #1: 1. JTAPI sends CTI Manager a ProviderOpenRequest 2. CTI Manager answers this request with a ProviderOpenResponse a. This response contains the provider ID number which seems to be later referenced as a Line Handle 3. Further down the standard operations... JTAPI sends a request to CTI Manager asking to register for call park events with a CtiRegisterParkDNMonitorReq a. This request appears to contain the Line Handle number previously provided by CTI Manager b. This request is passed from CTI Handler to all instances of the CallParkManager process on node #2 4. CallParkManager replies with CtiRegisterParkDNMonitorRes with a Line Handle of "0" 5. CTI Manager prints an error stating "invalid line handle" and steps three and four are repeated over and over between the same instances of CTIHandler and CallParkManager for each call park DN. In short, CallParkManager is not responding with the correct Line Handle number. In a working scenario, I confirmed that CallParkManager responds with the same Line Handle number provided within the monitor request. Do you know if there's a specific situation where CallParkManager is sending a LH=0 in the response for monitoring call park events with CallParkManager? In CCM SDL traces on Node #2, the AppInfo line under the register request prints the following: |SdlSig-I |CtiRegisterParkDNMonitorReq |AppInfo |CallParkManager - CtiRegisterParkDNMonitorReq - invalid parkDN=<number> or Partition name=<name> |SdlSig-O |CtiRegisterParkDNMonitorRes - Daniel From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Daniel Pagan Sent: Tuesday, April 15, 2014 2:15 PM To: Wes Sisk (wsisk) Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> Subject: Re: [cisco-voip] CTI & CCM SDL Trace Question 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:ws...@cisco.com] Sent: Tuesday, April 15, 2014 1:07 PM To: Daniel Pagan Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@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 <dpa...@fidelus.com<mailto:dpa...@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: WORKING SCENARIO - Call is displayed |AppInfo |sendCallParkNotify ctiList.size[2] |AppInfo |CallPark - calledparty = <####> ..... (omitted call info).... |AppInfo |Notification sent to ctiinterface (1,200,22,1) 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:ws...@cisco.com] Sent: Tuesday, April 15, 2014 11:58 AM To: Daniel Pagan Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@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 <dpa...@fidelus.com<mailto:dpa...@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@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
