[cisco-voip] Errors 18 and 19 on incoming call only through subscriber

Thu Mar 5 22:51:38 EST 2015

Final thing to mention is that while I've come across that defect numerous times, I've never seen it impact Hunt Lists so I'd be more inclined to suspect CSCtr83193 but CCM SDI/SDL traces should help regardless. Place a test call and search your traces for dd="<dialed-digits>"... Further down digit analysis results (assuming the HL is registered to the same node as your calling phone) find RouteListControl followed by HuntListCdrc for more detail on the issue from the perspective of your line group members and hunt list.

Hope this helps.

- Dan

Sent from my mobile device.

On Mar 5, 2015, at 10:18 PM, Daniel Pagan <dpagan at fidelus.com<mailto:dpagan at fidelus.com>> wrote:

I’d also say a similar defect would be CSCul71689 – a defect I came across quite often on 8.6(2). Like Brian said, hunt lists use RouteListControl which creates HuntListCdrc for call distribution to your line group members. With either defect, I’d say another possible workaround would be to register the hunt list to another call processing server so that this particular instance of RouteListControl runs on a different node. Aside from a reset of the HL and registering it to another server, my last option would be to reset the CCM service if one of these is indeed a defect you’re hitting.

Also, as Robert mentioned, detailed CCM SDI & SDL traces would confirm which one you’re hitting (if any of them of course).

The one you found appears to be an issue where RouteListControl itself rejects the call since (I’m assuming) it cannot locate the process instance for your LG/RG member, whereas the defect I listed above results in RouteListControl and RouteListCdrc locating the the LG/RG member but will detect and print them as “DOWN” despite their availability.

- Dan

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of ROZA, Ariel
Sent: Thursday, March 05, 2015 5:36 PM
To: Brian Meade
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] Errors 18 and 19 on incoming call only through subscriber

Thanks. So, the short term workaround would be to restart the CCM Service, until I can apply the latest service release. Right?

From: bmeade90 at gmail.com<mailto:bmeade90 at gmail.com> [mailto:bmeade90 at gmail.com] On Behalf Of Brian Meade
Sent: jueves, 05 de marzo de 2015 07:15 p.m.
To: ROZA, Ariel
Cc: Ryan Ratliff (rratliff); cisco-voip voyp list
Subject: Re: [cisco-voip] Errors 18 and 19 on incoming call only through subscriber

Hunt Lists use the RouteListControl process as well so definitely could be the issue.

On Thu, Mar 5, 2015 at 5:13 PM, ROZA, Ariel <Ariel.ROZA at la.logicalis.com<mailto:Ariel.ROZA at la.logicalis.com>> wrote:
I think I may be hitting this bug:

https://tools.cisco.com/bugsearch/bug/CSCtr83193

It applies to Route Lists instead of Hunt Lists, but the symptoms look similar, and the CUCM version matches..

What do you think?

Regards,
Ariel Roza
Service Delivery Consultant  / Argentina
Logicalis
Tel: +54 11 5282 - 0458<tel:%2B54%2011%205282%20-%200458>
ariel.roza at la.logicalis.com<mailto:ariel.roza at la.logicalis.com>
Peru 327 – CABA – Argentina – C1067AAG
www.la.logicalis.com<http://www.la.logicalis.com/>
_________________________________________________
Business and technology working as one

Síguenos en: <image001.png><http://twitter.com/LogicalisLatam> <image002.png><http://es-es.facebook.com/pages/Logicalis-Latam/234648439078> <image003.png><http://www.youtube.com/logicalislatam> <image004.jpg><http://www.slideshare.net/logicalis> <image005.jpg><http://www.cxounplugged.com/>
<image006.jpg>

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>] On Behalf Of ROZA, Ariel
Sent: jueves, 05 de marzo de 2015 06:56 p.m.
To: Ryan Ratliff (rratliff); Brian Meade
Cc: cisco-voip voyp list

Subject: Re: [cisco-voip] Errors 18 and 19 on incoming call only through subscriber

Hi, Guys…

I restarted RIS on both nodes and did not do a thing, so I guess Ryan might be right. What´s the alternative? Restarting the Callmanager Service? Rebooting the whole sub? Both Sub and Pub?

I have h225, h245 and full ccm traces if there´s any use for them.

Regards,

Ariel.

From: Ryan Ratliff (rratliff) [mailto:rratliff at cisco.com]
Sent: miércoles, 11 de febrero de 2015 11:23 a.m.
To: Brian Meade
Cc: ROZA, Ariel; cisco-voip voyp list
Subject: Re: [cisco-voip] Errors 18 and 19 on incoming call only through subscriber

RIS shouldn’t be involved in that flow, though it does read from the same shared memory segment that the ccm process does so unless RIS itself is screwed I’d expect if ccm doesn’t know a remote phone’s registration status RIS on that node won’t either.

-Ryan

On Feb 10, 2015, at 5:19 PM, Brian Meade <bmeade90 at vt.edu<mailto:bmeade90 at vt.edu>> wrote:

Right, could be an SDL link down.  I've seen this caused by RIS issues where the node receiving the call doesn't think the phone is registered (can't find the LineControl process).  Restarting RISDC usually fixes it.

On Tue, Feb 10, 2015 at 4:26 PM, Ryan Ratliff (rratliff) <rratliff at cisco.com<mailto:rratliff at cisco.com>> wrote:
How would this be RIS?

More like an SDL connection that’s down, or leaked a call on the sub.  Register a phone to the sub and see if you can call to/from another phone registered to the pub.

-Ryan

On Feb 10, 2015, at 10:32 AM, Brian Meade <bmeade90 at vt.edu<mailto:bmeade90 at vt.edu>> wrote:

Usually this is a RISDC problem.  Check database replication is working okay and then restart RISDC on all nodes.

On Tue, Feb 10, 2015 at 9:06 AM, ROZA, Ariel <Ariel.ROZA at la.logicalis.com<mailto:Ariel.ROZA at la.logicalis.com>> wrote:
 Guys,

I am having and odd situation:

I have a CUCM cluster ( Pub & 1 Sub) where i have set up a new branch office with an H323 Gateway and several phones. The config template is similar to other already working branches, but in this particular branch incoming calls are behaving strangely.
PSTN calls come through a FXO port, pass an autoattendant TCL script  on the GW and get routed to CUCM via two identical dialpeers ¡, one for the Sub and one for the Pub.
Debugs show that if calls use the Dialpeer to the Pub, the call goes fine, and the receiver phone answers the call. But if the call uses the Subs dialpeer, it fails with a Disconnect Cause code 18 (user busy) or 19 (user busy - user alerted).

The destination in both cases is the same: a Hunt List that is reachable via any internal phone.

DNA shows the logic is ok, and debugs on both, the gateway and CUCM show the same results, so conectivity should not be an issue.

 Does anyone have any suggestion, besides rebooting the Subs?

CUCM version is 8.6.2
The Pub and the Subs are in different subnets.

Regards,

Ariel.

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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 --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1467 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150306/53e7ec76/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1384 bytes
Desc: image002.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150306/53e7ec76/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 1469 bytes
Desc: image003.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150306/53e7ec76/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 849 bytes
Desc: image004.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150306/53e7ec76/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 863 bytes
Desc: image005.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150306/53e7ec76/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.jpg
Type: image/jpeg
Size: 3975 bytes
Desc: image006.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150306/53e7ec76/attachment-0002.jpg>