[cisco-voip] Child Process & Clarification

Fri Oct 25 09:26:29 EDT 2013

Just ran a quick test.

phnA: BT=2  MC=8
phnB: BT=4  MC=6
Inbound call to shared line appearance...

LineControl reports a BT of 4 and a MC of 8, essentially taking the higher value of each device-level BT/MC parameter, whereas the StationD process accurately represent the BT/MC at each line appearance, BT2/MC8 and BT4/MC6 in this case. Definitely makes sense and I understand your previous explanation much better now.

Thanks again for the clarification!

- Dan

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Daniel Pagan
Sent: Thursday, October 24, 2013 5:09 PM
To: Wes Sisk (wsisk)
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Child Process & Clarification

I should have mentioned this, yes. I assigned different BT/MC values to each line appearance for the purpose of viewing the BT/MC values reported by LineControl. I guess what I should have said was that LineControl is reporting a BT/MC of 5/5 regardless of what device-specific BT/MC values are configured elsewhere, which in this example is 1/1 on phnB.

What threw me off was that LineControl is accurately describing these values for phnA (5/5) with no mention of the line appearance BT/MC values on phnB (1/1)..  which I guess is where my earlier (incorrect) theory of 'one LineControl per line instance' came from -- different MC/BT values at the line level represented by different instances of LineControl -- but that appears to be wrong.

- Dan

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

This debug shows the values for 2 different station d's. The busy trigger is configured per line and per device. 2 devices with the same line can have different busy triggers. this is what you are seeing in these traces.

device 0008701 has busy=5
device 0008702 has busy=1

0008701 is phnA
0008702 is phnB

These look like they align to me?

I think what you're seeing is MC/BT enforced at the device level. They reflect the configuration for the device.

LineControl does generally run on the node where the first device registers the line.

-Wes

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

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

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<http://cisco.com>]
Sent: Thursday, October 24, 2013 2:42 PM
To: Daniel Pagan
Cc: cisco-voip at puck.nether.net<mailto: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/20131025/9d16e87a/attachment.html>