Incoming caller ID not working in 3.0 or 2.27 on T-1

[icmpman]

Experts,
The monitor log shows nothing in the calling number field & consequently no caller ID on phone. Doesn't appear to be rev problem since I downgraded from 3.0 to 2.27 just to see if callerId would work on an analog phone (I have 5420 phones, so have to use 3.0, really. I was just testing to elminate a rev prob).

Are there any suggestions/guidance on this issue? The provider came out and connected a breakout-to-analog (instead of T-1)converter device and showed where they are sending caller ID. My system just doesn't recognize it. Below is trace on 2.27. Caller from outside to internal number. Shows 1 incoming call routed ot analog extension capable of displaying callerid.

57701mS PRN: T1 Channel: GS 5.4: EventRx TipGNotRinging state=Idle
59431mS PRN: T1 Channel: GS 5.4: EventRx TipGRinging state=Idle
59431mS PRN: T1 Channel: GS 5.4: StateChange Idle->IncomingHandshake
59433mS CM: CMInformation
Line: type=Q931Line 5 Call: lid=0 id=-1 in=0
Tag type=Binary [......s....4.\.....<.T.J..sX..s(.T.4.S.r... ...0..=..] [0x03 0x06 0x00 0x02 0x01 0xe9 0x73 0x04 0x01 0xef 0xc6 0x34 0x01 0x5c 0xc8 0xc8 0x01 0xe9 0x89 0x3c 0x01 0x54 0x05 0x4a 0x01 0xe9 0x73 0x58 0x01 0x]
59434mS PRN: T1 Line: 5.4: RxMessage state=Idle msg=Alert_PreIndication
59434mS PRN: T1 Line: 5.4: State Change Idle->IncomingGuard
59651mS PRN: T1 Channel: GS 5.4: StateChange IncomingHandshake->IncomingAlerting
59653mS CM: CMInformation
Line: type=Q931Line 5 Call: lid=0 id=-1 in=0
Tag type=Binary [...w.S..... ...0...,...,.....S.D......s....D.S...S...] [0x03 0x07 0x00 0x77 0x01 0x53 0xe7 0x97 0x00 0x00 0x00 0x20 0x00 0x00 0x00 0x30 0x06 0x00 0x9d 0x2c 0x01 0xef 0xc6 0x2c 0x01 0xef 0xc5 0xec 0x01 0x]
59653mS PRN: T1 Line: 5.4: RxMessage state=IncomingGuard msg=Ringing
59653mS PRN: T1 Line: 5.4: State Change IncomingGuard->Present
59654mS PRN: T1 Line: 5.4: Incoming Call from to
59654mS CD: CALL: 5.4.1 BState=Idle Cut=1 Music=0.0 Aend="Line 5" (0.5) Bend="" [] (0.0) CalledNum= () CallingNum= () Internal=0 Time=0 AState=Idle
59655mS CMCallPkt: v=4
CMSetup
Line: type=Q931Line 5 Call: lid=5 id=4 in=1
SndComp Calling[] Type=Unknown (0) Pres=NAInterworking (2)
BC: CMTC=Speech CMTM=Circuit CMTR=64 CMST=Default CMU1=ULaw
BChan: slot=0 chan=5
59655mS CMTARGET: LOOKUP CALL ROUTE:1 type=100 called_party= sub= calling= in=1 complete=1
59655mS CMTARGET: SET BESTMATCH:1 length 0 vs 0 match= dest=1134
59655mS CMTARGET: LOOKUP INCOMING CALL ROUTE:1, calling party is . Using destination 1134
59656mS CMTARGET: ADD TARGET:1 number=1134 type=100 depth=1 nobar=1 setorig=1
59656mS CMTARGET: SET USER:1 analog orig=1
59656mS CMTARGET: ADD USER:1 analog(1134, state=Idle) (depth=2 B=0) cw=0
59657mS CMTARGET: LOOKUP CALL ROUTE:1 returned 1
59657mS CMCallEvt: v=4 State, new=Idle old=Idle,0,0,Astate
59657mS CMCallEvt: v=4 State, new=Dialling old=Idle,0,0,Astate
59657mS CD: CALL: 5.4.1 BState=Idle Cut=1 Music=0.0 Aend="Line 5" (0.5) Bend="analog(1134)" [analog] (0.0) CalledNum=1134 () CallingNum= () Internal=0 Time=3 AState=Dialling
59658mS CMExtnEvt: v=2 State, new=Presenting old=Idle,0,0,
59658mS CMExtnTx: v=1134, p1=2
CMSetup
Line: type=AnalogueExtn 3 Call: lid=0 id=2 in=0
Called[1134] Type=Default (100) SndComp Calling[] Type=Unknown (0) Pres=NAInterworking (2)

 

[NewNic]

True statement. CLID is not supported on T1.

It is supported on loop trunks and PRI

 

[icmpman]

Ah! So to be clear, are you saying that the IP Office does not support CLID on T1? Because I'm pretty sure that other products using T1s can pull CALLID out of the bitstream...

If that's the case, does anyone know if CLID will be supported by Avaya in the next patch? Or is there a reason why they can't or won't? The other IP Offices I have worked on all have PRI, so I haven't run into this problem until now.

 

[Morrack]

What is your "type" setting when you edit the channels in the line form?

If it's not loop, try that.


Man am I ever behind on this forum


Peter Sherwood

Morrack Consulting

http://www.morrack.com

 

[browmaster]

I saw this working on one T1 with wink start. they tried to duplicate this on another IPO with the same provider. they couldn't do it. I am not sure how it worked. I didn't get the chance to see what the provider was sending and how they were sending DNIS and ANI.

this is why I rarely put the IP Office behind a T1. PRI's just don't have this issue.

 

[icmpman]

Morrack - We actually had this set up as a loop start configuration, but the system would never recognize when a far-end caller hung up (ie, we would get 2 minutes of dial-tone recorded on voice mail, or just hear dial-tone forever if on a call...). To fix this, we had the provider change the configuration to ground-start & this resolved the disconnect problems. CLID hasn't ever worked under either configuration.

Brownmaster - I agree that PRI's are better! The reason we have this is because we have a data & voice product from a provider terminated into an Adtran 600R. This breaks out voice and data. The voice feeds into the IPO as a T-1, now configured as ground-start. When voice channels are not in use, that extra bandwidth can be used for data. It's a pretty cool product - except for my CLID issue.

I was sure hoping there was a way to make this work!! The technician came onsite and connected another device that broke the voice out to 66-block and put a caller-id device on it to show they were sending Caller ID information. It worked.

 

[row1030]

I've had a similar issue. After some time on the phone with Avaya, it has been determined that caller ID via a T1 is only supported with wink start trunks. Though I've not seen it actually work yet. We've not converted to wink start at this point.

 

[dontworx]

To get caller ID on a T-1 for any switch that I know of you have to have the phone company set up Feature group D.