IPO500V1 One-Way Audio on Inbound; "Number Busy Disc" on outbound

[sceaton]

Hello,

We have an IPO500V1 running 5.0(24) here in the US.

Service is via Bandwidth.com (T1 -> Adtran 904 -> PRI)

Today started an issue where inbound calls experience one-way audio (caller can hear the store, but the store cannot hear the caller).

SOME calls get through just fine, others fail. You can tell if the call will fail because you can't navigate the auto-attendant. If you stay on the line, VMPro sends the call to a default hunt group, which when answered, cannot hear the caller.

Also, outbound calls display "Number Busy Disc" on the 5600IP phone display and the calls will not go through. As far as I know, no outbound calls have been successful.

Bandwidth.com insists the Adtran is fine and that we need to look at the IPOffice.

Where to start? This has been in service for ~2 years.

 

[Westi]

if it doesn't work again after a reboot (and nothing has been changed in the programming) then the line provider is just trying to get out of THEIR issue the easy way.
But we all know that line providers never do that LOL.
I would say that 9 out of 10 issues that come along are with the line providers equipment if a reboot will not fix it. The 1 time it might be someone on site having changed something inadvertently.

Joe W.

FHandw, ACSS

Google it you damn kids

 

[sceaton]

Hi Joe!

I dug through the monitor logs and found details of one of the failed outbound calls (this is just the end):
###
4930731mS ISDNL1Rx: v=1 peb=1
0000 02 01 56 44 08 02 80 0f 45 08 02 82 a9 ..VD....E....
4930731mS ISDNL2Rx: v=1 peb=1
0000 02 01 56 44 08 02 80 0f 45 08 02 82 a9 ..VD....E....
4930731mS ISDNL3Rx: v=1 peb=1
ISDN Layer3 Pcol=08(Q931) Reflen=2 ref=000F(Local)
Message Type = Disconnect
InformationElement = CAUSE
0000 08 02 82 a9 ....
4930731mS ISDNL3Evt: v=1 stacknum=1 State, new=ReleaseReq, old=Proceeding id=1304
4930732mS ISDNL3Tx: v=1 peb=1
ISDN Layer3 Pcol=08(Q931) Reflen=2 ref=000F(Remote)
Message Type = Release
4930732mS ISDNL2Tx: v=1 peb=1
0000 00 01 44 58 08 02 00 0f 4d ..DX....M
4930733mS ISDNL1Tx: v=1 peb=1
0000 00 01 44 58 08 02 00 0f 4d ..DX....M
4930738mS ISDNL1Rx: v=1 peb=1
0000 00 01 01 46 ...F
4930738mS ISDNL2Rx: v=1 peb=1
0000 00 01 01 46 ...F
4930750mS ISDNL1Rx: v=1 peb=1
0000 02 01 58 46 08 02 80 0f 5a ..XF....Z
4930750mS ISDNL2Rx: v=1 peb=1
0000 02 01 58 46 08 02 80 0f 5a ..XF....Z
4930750mS ISDNL3Rx: v=1 peb=1
ISDN Layer3 Pcol=08(Q931) Reflen=2 ref=000F(Local)
Message Type = ReleaseComplete
4930751mS ISDNL3Evt: v=1 stacknum=1 State, new=NullState, old=ReleaseReq id=1304
4930751mS ISDNL2Tx: v=1 peb=1
0000 02 01 01 5a ...Z
4930751mS ISDNL1Tx: v=1 peb=1
0000 02 01 01 5a ...Z
4930752mS CMLineRx: v=1
CMReleaseComp
Line: type=Q931Line 1 Call: lid=0 id=1304 in=0
BChan: slot=0 chan=1
Cause=41, Temporary failure
4930752mS CMCallEvt: 0.1304.0 65 Q931 Trunk:1 CHAN=1: StateChange: END=B CMCSAccept->CMCSCompleted
4930753mS CMExtnTx: v=172, p1=0
CMFacility
Line: type=IPLine 250 Call: lid=274 id=1301 in=0
IE CMIEFastStartInfoData (6)
Timed: 18/07/11 19:16
4930753mS CMExtnTx: v=172, p1=8023
CMFacility
Line: type=IPLine 250 Call: lid=274 id=21 in=1
IE CMIEFastStartInfoData (6)
4930756mS CMLOGGING: CALL:2011/07/1819:16,00:00:00,000,172,O,19194145957,919194145957,NormanGlasser2,,,0,,""n/a,0
4930756mS CD: CALL: 274.1301.0 BState=Disconnecting Cut=1 Music=0.0 Aend="Norman Glasser2(172)" (0.0) Bend="Line 1" [Line 1] (1.2) CalledNum=19194145957 () CallingNum=172 (Norman Glasser2) Internal=0 Time=10074 AState=Dialled
4930756mS CD: CALL: 274.1301.0 Deleted
4930758mS CMExtnEvt: Norman Glasser2: CALL LOST (CMCauseTemporaryFailure)
#####

This means the PRI (adtran) is responding with: "Cause=41, Temporary failure" right? Which points the issue back at them? Just want to be sure my guns are loaded when I insist the problem is theirs.

Thanks!

 

[sceaton]

So after troubleshooting the outbound dialing issue with bandwidth.com, they determined that a call got "stuck" on their end. They "doubled our trunks" overnight, since all calls get flushed each night and that should take care of the real problem.

We tested inbound and outbound calls, and so far, so good.

There went 5 hours of my life that I'll never get back.

 

[amriddle01]

As Westi said, 9 times out of 10 it's the lying providers

http://www.ipoffice.tel

 

[muckermucker]

You want to have a read of one way audio. I found it when I had the same problem as you. It explains exactly why you experience one way audio and how to fix it.

 

[mattKnight]

>It explains exactly why you experience one way audio and how to fix it.

Not really. It explains 1 potential cause of one way voice.

It doesn't add anything to this thread though

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[muckermucker]

It still added more than your scolding comment Matt.