Subject: (usr-tc) Problem with new PRI

From: Scot Desort <[email-masked]>
Date: Thu, 27 Jan 2000 09:39:19 +0000

We added another PRI to our hunt group today. Telco says all trunks in group
are set to UCD hunt method.

New PRI is only taking 1 call on channel 1. It has taken both analog and
digital calls on that channel. I have checked the card in TCM and all
channels are enabled. I have done a hardware reset on the card, with no
effect. Have not had the opporunity to switch the PRI to see if the problem
follows the card or the trunk.

Any ideas on what I might be missing?

--
Scot

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: Brian <[email-masked]>
Date: Thu, 27 Jan 2000 16:58:33 +0000

channel/slot mappings, check them.

ds0 service states, check those.

Go into session monitor, and look at ds0 statistics, it may also show
something.

> Any ideas on what I might be missing?

-----------------------------------------------------
Brian Feeny (BF304)     [email-masked]   
318-222-2638 x 109	http://www.shreve.net/~signal      
Network Administrator   ShreveNet Inc. (ASN 11881) 	      

-

---

From: Scot Desort <[email-masked]>
Date: Thu, 27 Jan 2000 18:44:05 +0000

OK. Duh on me.

Where can one tell if modems are soft-busied. That is what was wrong. I have
since restored to service all of those channels. But before I figured it
out, there didn't seem to be anywhere in TCM that told me the channels were
busied out. Did I miss something???

----- Original Message -----
From: Brian <[email-masked]>
To: usr list <[email-masked]>
Sent: Thursday, January 27, 2000 9:55 AM
Subject: Re: (usr-tc) Problem with new PRI

-

---

From: Brian <[email-masked]>
Date: Thu, 27 Jan 2000 18:50:48 +0000

check the ds0 service states in tcm, or from the dsp command line:

chdev span
dis atstat

brian

-

---

From: "Lon R. Stockton, Jr." <[email-masked]>
Date: Wed, 02 Feb 2000 10:00:58 +0000

> busied out. Did I miss something???

Didn't see an answer for this one, although it's very possible I just
missed it. Whichever, here's an answer for ya...

 1) bring up TCM & open your chassis
 2) click on the span leds of the DSP card(s) you want to check
 3) click 'Performance'
 4) select 'Timeslot' and then 'Select All'; click 'OK'
 5) Under 'Parameters', select 'DS0 Service State' and
    'Queued Action for DS0'. Click 'Add' and then 'OK'.
 6) Voila. Timeslots which are busied-out are listed as
    'localOutOfService' under 'DS0 Service State'.

If the timeslot was hard-busied (or soft-busied with no call currently
active on the timeslot), you'll see the 'localOutOfService' indication
under 'DS0 Service State'.

If the timeslot was soft-busied and there's a call currently active on
that timeslot, you'll see that the 'DS0 Service State' is 'inService'
and the 'Queued Action...' is 'localOutOfService'. As soon as the
current call terminates, you'll see the service state go to
localOutOfService.

That, of course, being the difference between hard-busy and soft-busy.
Hard-busy does it NOW. Soft-busy waits for the current call to complete.

Hope this helps!

-

---

From: Scot Desort <[email-masked]>
Date: Wed, 02 Feb 2000 16:59:08 +0000

Thanks for the specifics, Lon.

What was happening is that if a call hit a channel that was soft busied, the
call wasn't rolling over to the next channel. The telco switch was either
presenting a reorder tone to the end user, or an intercept stating "Your
call cannot be completed as dialed" -- NOT a good thing. The reorder isn't
too bad, but the intercept was ugly. If the user re-dialed and landed on a
channel that was not soft-busied, the call would go through.

What is distressing is that the DSP did not communicate correctly with the
switch. The call should have never landed on that channel - it should have
rolled to the next channel in the rotary. If there were no other available
non-busied channels, user should get regular busy signal.

Any thoughts as to why this would not work properly? Switch is a 5ESS
through a CLEC.

--
Scot

----- Original Message -----
From: Lon R. Stockton, Jr. <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 02, 2000 2:27 AM
Subject: Re: (usr-tc) Problem with new PRI

-

---

From: Jeff Mcadams <[email-masked]>
Date: Wed, 02 Feb 2000 17:22:25 +0000

Thus spake Scot Desort

>What was happening is that if a call hit a channel that was soft
>busied, the call wasn't rolling over to the next channel. The telco
>switch was either presenting a reorder tone to the end user, or an
>intercept stating "Your call cannot be completed as dialed" -- NOT a
>good thing. The reorder isn't too bad, but the intercept was ugly. If
>the user re-dialed and landed on a channel that was not soft-busied,
>the call would go through.

>What is distressing is that the DSP did not communicate correctly with
>the switch. The call should have never landed on that channel - it
>should have rolled to the next channel in the rotary. If there were no
>other available non-busied channels, user should get regular busy
>signal.

>Any thoughts as to why this would not work properly? Switch is a 5ESS

Sounds like an NI-2 translation.  Due to the lack of service messages in
NI-2, there is no way for the chassis to indicate to the switch that the
channels are busied out.  So the switch still sends calls down those
channels and the chassis responds with whatever cause code is defined
(by default 58, bearer capability not presently available).  If you
switch the cause code to 17, that's a user busy which should result in a
normal busy signal to the user...that's a bit better anyway.  You real
solution is to switch to custom 5ESS translation so you can use service
messages and then things will work as you want (soft-busy...calls hunt
past).
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Scot Desort <[email-masked]>
Date: Fri, 04 Feb 2000 08:04:45 +0000

Jeff-

Thanks for the input. As it turns out, the switch was set to 5ESS Standard.
Switch tech changed the trunk group to 5ESSCustom, and all works as
expected. I can now busy out channels and call will not land on them until
restored to service.

--
Scot

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Jeff Mcadams
>Sent: Wednesday, February 02, 2000 10:20 AM
>To: [email-masked]

-

---

From: Kevin Benton <[email-masked]>
Date: Fri, 04 Feb 2000 16:44:06 +0000

> expected. I can now busy out channels and call will not land on them until

Just make sure you're doing answer supervision correctly with the switch.
We had a problem that bit us hard for a month because the telco changed a
switch option that required us to do it properly if we wanted our
customers to be able to stay on-line for more than 30 seconds after the
call started.  Man that one hurt us a bunch...

Kevin

E-Mail:  [email-masked]
Web:     http://users.sota-oh.com/~s1kevin/
Unsolicited advertisements processing fee: $50 subject to change without notice

-