[cisco-voip] CTI & CCM SDL Trace Question
Brian Meade
bmeade90 at vt.edu
Wed Apr 16 13:50:44 EDT 2014
Does that park DN exist on that particular node?
I wonder if it is having problems with the ranges and the code checking if
the DN exists isn't checking the ranges.
Have you tried with just an individual park DN?
On Wed, Apr 16, 2014 at 1:27 PM, Daniel Pagan <dpagan at fidelus.com> wrote:
> The parkDN listed is an actual park range on their cluster. Then I’m
> seeing the park monitor requests listing each individual pattern within the
> provided ranges. There are overlaps in the park ranges, each assigned to
> its own partition, but they don’t cross/overlap on other nodes so that
> shouldn’t be an issue.
>
>
> *Example*:
>
>
>
> *Requesting park information*
>
>
>
> |AppInfo
> |ProcessCTIDatabase::initializing_CtiCallParkRetrieveParkDNReq(): *NodeId
> = 2*, *parkDN = 89[1-9]* partition=*SF-PT*
>
> |AppInfo
> |ProcessCTIDatabase::initializing_CtiCallParkRetrieveParkDNReq(): *NodeId
> = 2,* *parkDN = 89[1-9]* partition=*MP-PT*
>
>
>
> *Request & response for park monitoring*
>
>
>
> |SdlSig-I |CtiRegisterParkDNMonitorReq |wait
> |CallParkManager(2,100,215,1)
> |CTIHandler(1,200,22,43404) |1,200,13,43426.10^10.10.42.12^*
> |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] AsyncResponse=8 *mParkDNToMonitor=892
> Partition=SF-PT* *LH=16820620*|3440
>
>
>
> |AppInfo |CallParkManager - CtiRegisterParkDNMonitorReq - *invalid
> parkDN=892* or *Partition name=SF-PT*
>
>
>
> *Returning LH=0*
>
>
>
> |SdlSig-O |CtiRegisterParkDNMonitorRes |NA
> RemoteSignal |CTIHandler(1,200,22,43404)
> |CallParkManager(2,100,215,1) |1,200,13,43426.10^10.10.42.12^*
> |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] AsyncResponse=8 mResult=0x8ccc0082 *LH=0*|0
>
>
>
> |SdlSig-I |CtiRegisterParkDNMonitorRes
> |ready |CTIHandler(1,200,22,43404)
> |CallParkManager(2,100,215,1) |1,200,13,43426.9^10.10.42.12^*
> |[R:N-H:0,N:0,L:0,V:0,Z:0,D:0] AsyncResponse=7 mResult=0x8ccc0082 *LH=0*|0
>
>
>
> *|AppError |invalid line handle*
>
>
>
> I created this same overlap on my lab environment running the exact same
> version of CUCM and park monitoring requests and responses for the new
> range completed with no problems. As a test, I advised the integrator and
> their customer to create a new park range *without* an overlap and assign
> it to another node – one without a park DN or range. This was done but they
> said the issue still exists. I’m interested to hear if their TAC CE finds
> anything informative when searching for “CtiRegisterParkDNMonitorReq -
> invalid parkDN*” *or can pin point why CallParkManager determines it’s
> invalid. I’m also hoping it’s nothing simple J
>
>
>
> - Dan
>
>
>
> *From:* bmeade90 at gmail.com [mailto:bmeade90 at gmail.com] *On Behalf Of *Brian
> Meade
> *Sent:* Wednesday, April 16, 2014 12:50 PM
>
> *To:* Daniel Pagan
> *Cc:* Wes Sisk (wsisk); cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] CTI & CCM SDL Trace Question
>
>
>
> Daniel,
>
>
>
> Is the parkDN listed an actual park number or is it the directory number
> of the line doing the parking?
>
>
>
> I'm guessing you're running the same version on your lab cluster?
>
>
>
> Brian
>
>
>
> On Wed, Apr 16, 2014 at 12:42 PM, Daniel Pagan <dpagan at fidelus.com> wrote:
>
> Brian
>
>
>
> Unfortunately the customer and their integrator can’t seem to get park
> monitoring to work successfully on this cluster. The working scenario I
> described was done in my lab and production environment here. Comparing the
> two requests across their environment and mine shows no significant
> difference.
>
>
>
> In their environment, the park DN ranges provided back to JTAPI lines up
> with the park monitor requests that arrive later in the trace file. Looking
> at CCM SDL traces shows that every CtiRegisterParkDNMonitorReq containing a
> DN and partition is met with an “invalid parkDN=*xxxxx*” error by
> CallParkManager.
>
>
>
> The customer’s integrator has a TAC case open and I provided them with my
> findings. Hopefully this allows the CE to pick up speed and target a
> specific area of the issue.
>
>
>
> - Daniel
>
>
>
>
>
> *From:* bmeade90 at gmail.com [mailto:bmeade90 at gmail.com] *On Behalf Of *Brian
> Meade
> *Sent:* Wednesday, April 16, 2014 12:12 PM
> *To:* Daniel Pagan
> *Cc:* Wes Sisk (wsisk); cisco-voip at puck.nether.net
>
>
> *Subject:* Re: [cisco-voip] CTI & CCM SDL Trace Question
>
>
>
> Daniel,
>
>
>
> Do you see anything different between the working and nonworking
> CtiRegisterParkDNMonitorReq? Is there a difference in partitions or
> anything between a working and nonworking number?
>
>
>
> Is that AppInfo CallParkManager line printing the correct number/partition?
>
>
>
> Brian
>
>
>
> On Wed, Apr 16, 2014 at 11:31 AM, Daniel Pagan <dpagan at 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-bounces at puck.nether.net] *On Behalf
> Of *Daniel Pagan
> *Sent:* Tuesday, April 15, 2014 2:15 PM
> *To:* Wes Sisk (wsisk)
>
>
> *Cc:* cisco-voip at 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:wsisk at cisco.com <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> 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:wsisk at cisco.com <wsisk at cisco.com>]
> *Sent:* Tuesday, April 15, 2014 11:58 AM
> *To:* Daniel Pagan
> *Cc:* 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> 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
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> 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/20140416/b71ecea6/attachment.html>
More information about the cisco-voip
mailing list