[cisco-voip] Child Process & Clarification

[Daniel Pagan]

Thanks a lot for the clarification. What's throwing me off is this...

phnA: MC=5  BT=5
phnB: MC=1  BT=1
Scenario: Inbound call to phnA & phnB shared line appearance.

LineControl(9042) - 1 calls, 0 CiReq, busyTrigger=5, maxCall=5
Created  |                                       |                               |LineCdpc(1,100,168,97444)        |LineControl(1,100,167,9042
LineCdpc(97444): -dispatchToAllDevices-, sigName=CcSetupReq, device=CIPCDPAGAN
LineCdpc(97444): -dispatchToAllDevices-, sigName=CcSetupReq, device=SEP001D45B5E6C9

CcSetupReq                             |restart0                       |StationD(1,100,58,8701)          |LineCdpc(1,100,168,97444
CcSetupReq                             |restart0                       |StationD(1,100,58,8702)          |LineCdpc(1,100,168,97444
StationD:    (0008701) DEBUG whatToDo: line=1 calls=1 limit=5, busy=5
StationD:    (0008702) DEBUG whatToDo: line=1 calls=1 limit=1, busy=1.

LineControl reports busy trigger and max call values that don't align with all associated appearances. I guess this is why I was expecting one LineControl process per line instance - for MC/BT management across each appearance. Since (if I recall correctly) LineControl runs on the node where the DN first registers, do the LineControl bT/mC values reflect those assigned to the DN that first registers with CUCM?

Thanks again.

- Dan

From: Wes Sisk (wsisk) [mailto:wsisk at cisco.com]
Sent: Thursday, October 24, 2013 2:42 PM
To: Daniel Pagan
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Child Process & Clarification

Cdpc ~ "call dependent process control"

basically maintains all information for that call relevant to that line.

they are essentially "per call" containers for attributes related to the call. And they interact with their parent process (line control, stationD, etc.) to get "higher level information".

there is only one line control per DN. And only 1 line control for all shared lines. In a clustered environment you can have StationD on Node1 passing all info back and forth to LineControl on Node2.

Trace entries, observed behavior, and configuration should align. Notable reasons for deviation: split cluster, other overriding parameter (Max calls per device), broken change notification, and leaks (previous Cdcc, StationCdpc, or LineCdpc started and not correctly stopped).

You can see most of the generations of processes by looking at traces during ccm startup and then watching the started/stopped events during device (un)registration, call (dis)connect.

HTH
Wes

On Oct 24, 2013, at 2:23 PM, Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>> wrote:

Folks:

I'm curious if someone can tell me the purpose of creating child processes, specifically LineCdpc and StationCdpc?

I ask about LineControl because my understanding was that it handled both Max Call & Busy Trigger management AND call dispatch to associated phone devices, but now I see it's actually LineCdpc and I'm curious if there's logical reasoning behind this. I ask about StationCdpc because I see (for calls sourced from a JTAPI client) that both StationD and StationCdpc process are talking to CTIDeviceLineMgr. What I can't figure out is the need for creating these Cdpc's and how their responsibilities differ from their parent process.

Does StationCdpc handle application-level updates that result from transmitted StationD and received StationINIT events? Kind of like acting as an intermediary between actual SCCP events and internal SDI/SDL communication to other processes involved?

Also, am I correct in saying LineControl handles management over busy trigger and max calls per line instance whereas LineCdpc handles the dispatch of calls to the StationD process? Or should there be only one LineControl process per DN while another process handles max calls & busy trigger management on a per line instance basis? Tests in a 9.1.1 lab shows the latter - one LineControl instance while StationD handles the active calls/max calls/bt values... but tests also show issues where shared line appearances with varying MaxCalls/BT values cause voicemail forwarding due to these values being prematurely reached. Trace entries and behavior don't line up with actual configurations so I'm hoping for some clarification. All devices are registered to a single node in this lab environment.

Sorry for the long winded e-mail and I hope you don't mind the brain picking.

- 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/20131024/26d811b7/attachment.html>