[cisco-voip] ParkingLotD and SNR | Leaked Calls on StationD

[Daniel Pagan]

Folks:

Wrapping up on this thread. BU created three new defects for this issue:

CSCut60329
Misconfigured Mobile Connect-SNR causes call leak in StationD

CSCut60376
Misconfigured Mobile Connect-SNR causes call leak in StationD part2

CSCut60641
Race condition at LBM Interface between LBM res and Cc signals

Some more detail on this issue in my previous messages.

- Dan

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Daniel Pagan
Sent: Tuesday, January 13, 2015 12:10 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] ParkingLotD and SNR | Leaked Calls on StationD

I set this up in a lab and it looks like the issue can be recreated in CUCM 10.x as well...


1.       Enable and setup SNR for a user

2.       Configure the Remote Destination to an invalid number - force DA for SNRD to fail.

3.       Configure the Remote Destination for "User Control" voicemail policy

4.       Call the user's DN x number of times, where x equals your busy trigger value.

Can't seem to find a matching, publicly available defect for this so I opened a TAC case. The problem cannot be recreated when the Remote Destination's voicemail policy is "Timer Control" instead of "User Control", and I fail to see ParkingLotD or ParkingLotCdpc when I'm not using "User Control" so it must be related.

The original call sends CcSetup to SNRD which results in a DA request. Although the request fails, we still invoke ParkingLotD/Cdpc and perform another DA request but to the user's DN instead of the Remote Destination. This seems to create another set of CIs and extends another CcSetup to StationD. Run this call flow a few times till the busy trigger is hit and the user-facing symptoms are:


1.       Inbound calls route immediately to VM since the busy trigger is reached

2.       Potentially user sees "Error Pass Limit" if Max Calls are reached - user cannot activate the line or place a call.

Resetting the phone associated to the StationD process leaking the call appears to be a workaround. Permanent solution is correct the Remote Destination so DA is successful or set the voicemail policy to Timer Control.

- Dan


From: Daniel Pagan
Sent: Tuesday, January 13, 2015 11:53 AM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: ParkingLotD and SNR | Leaked Calls on StationD

Folks:

Hoping someone can tell me if and how ParkingLotD and ParkingLotCdpc are related to outbound SNR calls. I'm looking at an SNR call and in SDL traces I'm seeing DA for CellProxy followed by a "InitiateCallWithFeatureReq" from Cc to ParkingLotD. I'm wondering what this event is for because I suspect it's related to a series of stuck/stale CI's. Both processes seem to be related to SNR when "User Control" is enabled at the Remote Destination. I'm familiar with CSCub55072 and it doesn't appear to be related.

There's an issue where calls seem to be leaking in the following call flow:


1.       Inbound call to DN over SIP trunk

2.       DN associated to Remote Destination

3.       CcSetup to the associated SNRD results in a rejection due to the remote destination failing on DA - the remote destination itself was configured incorrectly.

4.       Even though DA failed for SNRD, we have a 2nd successful DA to the called DN which appears to be related to ParkingLotCdpc. StationD receives this 2nd CcSetup while stating it's a VMA call.

The user answers the inbound call and eventually disconnects. Later, another call arrives to his DN, LineControl reports ZERO active calls, but the StationD process reports ONE active call. Later, StationD will report TWO active calls while LineControl accurately reports ZERO. I'm familiar with CSCub55072 and it doesn't appear to be related.
Should we expect to see ParkingLotD and ParkingLotCdpc involved when DA fails to the remote destination? I'm setting this up in a lab environment now and fairly certain the call shouldn't extend this far when SNRD's DA fails, causing a 2nd DA to the called DN for no reason, which might explain the call leakage to StationD since CCM is sending it a 2nd "VMA call" for a failed SNR.

- Dan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150330/6c7a8574/attachment.html>