Caller ID issue

[snootalope]

This probably isn't a CallManager issue, but I figured this would be a good place to post beings anyone who manages CCM probably knows a thing or two about the gateways.

Here's my dilema. For the past five months (yes, five months) I've been fighting with the phone company to get caller id enabled for a PRI we have coming into our office.

We actually have two PRI's. One for local calls, and one for long distance. The PRI we have for our local calls currently has Caller ID enabled and it works just fine. The long distance is the one we're fighting with.

Our company has a couple 800#'s that the phone company routes down our long distance T to get to our building. We are wanting caller ID enabled on this T.

Here's the problem. Whenever the telco enables caller ID on their end and makes a test call to our 800#'s, they get a fast busy. They are aware that our equipment only handles digits for CallerID rather than both digits and name. Beings this has been going on for five months, I'm starting to think it may be something on our VG200 gateway.

I've got the VG200 setup and currently terminating both PRI's. One uses pri-groups and the other (the long distance T) uses ds0-groups. Not sure if makes a difference to caller id or not, just thought I'd put that on there. So, the one with the pri-groups configured is our local T and caller ID works just fine to the inside and out (digits). The long distance gives a fast busy signal when the telco enables caller ID.

In five months I think I've covered everything I can on cisco.com and goole. I'm out of ideas.

Anyone real knowledgeable in the is area able to maybe give me some advice?

Thanks!

 

[jeter]

They both PRI's need to be setup with pri-group, example!

!
controller T1 0/1/0
framing esf
linecode b8zs
pri-group timeslots 1-24 service mgcp
!
controller T1 0/1/1
framing esf
linecode b8zs
pri-group timeslots 1-24 service mgcp

Your serial interfaces should look similier
!
interface Serial0/1/0:23
no ip address
isdn switch-type primary-ni
isdn incoming-voice voice
isdn bind-l3 ccm-manager
no cdp enable
!
interface Serial0/1/1:23
no ip address
isdn switch-type primary-ni
isdn incoming-voice voice
isdn bind-l3 ccm-manager
no cdp enable
!!
voice-port 0/1/0:23
!
voice-port 0/1/1:23
!

Now with that said you need to make sure that your translations are setup correclty. Test by debugging your gatewat (debug isdn q931) call into your 800# just to verify its getting to your router. Then troubleshoot further into call manager!!!



Some people are like slinkies.
Not really good for anything but they bring a smile to your face when pushed down the stairs.


Tek-TIP Member 19,650

 

[snootalope]

So, the ds0-group doesn't support the caller id feature?

I was starting to think it might of had something to do with that one single difference...

 

[jeter]

from your gatway type show isdn status. Verify that both PRI's show an established link. Verify Call Manager gateway programming as well.

Some people are like slinkies.
Not really good for anything but they bring a smile to your face when pushed down the stairs.


Tek-TIP Member 19,650

 

[snootalope]

both pri's are established, they're both making and getting calls already.

Does a ds0-group not support the caller ID feature? That's what I'm trying to find out now..

 

[soleman52]

Have you tried swapping the pri's to see if the trouble follows off hours of course.....

 

[snootalope]

No, soleman, haven't tried that. I'd rather not mess with the T that's already working correctly though..

I just tried changing the ds0-group to a pri-group and it didn't work. Just got a busy from the outside calling in, and busy from the inside calling out.

I think I'm going to have to have the telco switch something on their end so we can configure the trunk as a pri-group.

 

[dyankee]

You might be confusing a PRI and a older digital trunk type. Your local service is a PRI where the caller id is sent over a D-channel (typically channel 24) Typically direct connect T1 from a LD service are DS0 channels of 56k each, control signaling (line seizures, inbound and outbound, outpulsing signals) can occupy part of that channel or all be placed in a single channel. There are several different methods. Most likely the caller id information is coming through the seized channel as a series of pulses similiar to the way caller id works on an analog CO line. These digits may be causing the inbound 800 failures.
Best bet is to upgrade to a PRI Probably won't be cheap

 

[snootalope]

Well, we've determined what needs to be done. The T1 that I thought was a PRI, is not a PRI. It's a T1 CAS. So, we've got to switch the signaling type to e&m-fgd (from wink start) and apparently that'll do the trick.