<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
"occur as things are starting to get busy on the trunks"<br>
<br>
This raises concern about glare conditions. Not sure if your CO will
continue hunting when a glare condition occurs. This gets into very
specific implementation details of the ISDN stack in both the CO and
CPE equipment. I've also seen ISDN protocol mismatches exacerbate
this. At the simplest, verify b-channels remain in service. After that
we need to carefully review d-channel signaling.<br>
<br>
To look for further information I would start with review of CDR's on
CM. If inbound call fails for any abnormal reason it should be logged
in CDR.<br>
<br>
After that it may be useful to review CDR's from the IOS gateway
itself. These come out in a slightly different format. "Show call
history voice" may also be useful.<br>
<br>
If all of those fail then setup CM trace archive and archive CM SDI and
SDL traces through your busy hours. It is possible to parse those and
identify all calls.<br>
<br>
Of couse, if the call is being dropped in the CO before any signaling
to the CPE then we will not see any mention in our gear.<br>
<br>
/Wes<br>
<br>
On Thursday, August 05, 2010 9:14:26 AM, Dave Wolgast
<a class="moz-txt-link-rfc2396E" href="mailto:dwolgas1@rochester.rr.com"><dwolgas1@rochester.rr.com></a> wrote:<br>
<blockquote
cite="mid:AANLkTi=vrTRUEFNaygi29QkgmXiY0TDsr=jBmoo_V_fi@mail.gmail.com"
type="cite">I am pretty confident that this does not have to do with
CallManager (6.1.4, MGCP PRI GWs with lots o' DIDs), but I am wondering
if someone might help me put together a method for approaching the
issue...<br>
<br>
Sporadically, for what seems like about a minute at a time, some
callers to our DIDs (mostly cellular callers) report getting a network
message that the call cannot be completed, or for Verizon Wireless
callers, "the Verizon Wireless customer you called is not available at
this time." My personal experience is that I retry 2-4 times, and end
up getting through. It doesn't happen often, but does seem to occur as
things are starting to get busy on the trunks. That said, I never see
blocking on the trunks when I monitor using RTMT, even though
utilization is fairly high.<br>
<br>
The DIDs are on a trunk group of 5 Verizon PRIs, and in 2008, were
ported by Verizon to a different CO when headquarters moved a few miles
down the road.<br>
<br>
Any ideas for things I should look at/for? Should I be calling
Verizon, or any of the cell carriers on which the issue was reported?<br>
<br>
Thanks for any suggestions you might offer!<br clear="all">
<br>
-- <br>
Dave Wolgast<br>
Livonia, NY<br>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
cisco-voip mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/cisco-voip">https://puck.nether.net/mailman/listinfo/cisco-voip</a>
</pre>
</blockquote>
<br>
</body>
</html>