[cisco-voip] CTI & CCM SDL Trace Question

Brian Meade bmeade90 at vt.edu
Wed Apr 16 12:12:23 EDT 2014 

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/012fa0b5/attachment.html>

More information about the cisco-voip mailing list