CTI Route Point: ISDN Issues

chmorin

I have been given a smörgåsbord of ISDN issues with PRI's recently. I have not gotten my CVOICE exam passed yet, but I think all of this gateway nonsense is going to be giving me a hand.

Anyway, I think I have finally figured out the call process I should see when I debug q931. This is a CTI Route Point, however, that is forwarding the calls to an external number. Now it is very obvious where this goes wrong, but I'm still new to the CTI thing:

ISDN Se0/0/0:23 Q931: RX <- SETUP pd = 8  callref = 0x00B3
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98381
                Exclusive, Channel 1
        Facility i = 0x9F8B0100A10F02010106072A8648CE1500040A0100
                Protocol Profile =  Networking Extensions
                0xA10F02010106072A8648CE1500040A0100
                Component = Invoke component
                        Invoke Id = 1
                        Operation = InformationFollowing (calling_name)
                                Name information in subsequent FACILITY message
        Calling Party Number i = 0x2083, '281754XXXX'
                Plan:Unknown, Type:National
        Called Party Number i = 0x80, 'XXXX'
                Plan:Unknown, Type:Unknown
ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd = 8  callref = 0x80B3
        Channel ID i = 0xA98381
                Exclusive, Channel 1
ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x140E
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98397
                Exclusive, Channel 23
        Calling Party Number i = 0x2183, '9281754XXXX'
                Plan:ISDN, Type:National
        Called Party Number i = 0x80, '1800810XXXX'
                Plan:Unknown, Type:Unknown
ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x940E
        Channel ID i = 0xA98397
                Exclusive, Channel 23
ISDN Se0/0/0:23 Q931: RX <- FACILITY pd = 8  callref = 0x00B3
        Facility i = 0x9F8B0100A117020101020100800F4E45575041524B204452494C4C494E
                Protocol Profile =  Networking Extensions
                0xA117020101020100800F4E45575041524B204452494C4C494E
                Component = Invoke component
                        Invoke Id = 1
                        Operation = CallingName
                                Name Presentation Allowed Extended
                                Name = NXXXX
[COLOR="Red"]ISDN Se0/0/0:23 Q931: RX <- PROGRESS pd = 8  callref = 0x940E
        Cause i = 0x8AA9 - Temporary failure
        Progress Ind i = 0x8488 - In-band info or appropriate now available
ISDN Se0/0/0:23 Q931: TX -> PROGRESS pd = 8  callref = 0x80B3
        Cause i = 0x80A9 - Temporary failure[/COLOR]
        Progress Ind i = 0x8488 - In-band info or appropriate now available
ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8  callref = 0x00B3
        Cause i = 0x8090 - Normal call clearing
ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8  callref = 0x140E
        Cause i = 0x8090 - Normal call clearing
ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8  callref = 0x940E
ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8  callref = 0x80B3
ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8  callref = 0x140E
ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x00B3un all
All possible debugging has been turned off

So, hopefully I am correct in analyzing it this far:

The call comes into the gateway, it gets setup normally and then setup again as the new call it should be forwarded as. So far so good... It receives facility, then where I would normally hope to see 'connect' (I think) it receives 'progress' with Temporary Failure. From what I have researched, this could mean a million things. I then hang up and the usual disconnect occurs.

My question is since this is a received message, should I contact the ISP to troubleshoot or is it on my end? This only happens on this particular route point. If I was to call the route point internally, it gets routed correctly out the PRI. If I call the direct number the CTI point forwards to, the number is routed correctly. This problem only happens when calling EXTERNALLY to the CTI route point.

shodown

when the inbound call in coming in do you use a translation pattern?

chmorin

shodown wrote: »

when the inbound call in coming in do you use a translation pattern?

Negative.

shodown

so how are you sending it to the CTI route point? IF you are using H323 or MGCP?

chmorin

shodown wrote: »

so how are you sending it to the CTI route point? IF you are using H323 or MGCP?

MGCP

The call comes into the gateway and gets sent to call manager. The call manager sees the extension as one that is attached to a CTI route point. The CTI route point is set to forward all calls to an external number.

Probably not a traditional use of the route point.

shodown

Yeah thats not the way I do it. I will take the 10 digit number in and translate it to a 4 digit which is the CTI route point, then a foward all on the CTI route point. Thats usually how I do it. If you don't have 10 digit coming it you can use a 4 digit.

chmorin

shodown wrote: »

Yeah thats not the way I do it. I will take the 10 digit number in and translate it to a 4 digit which is the CTI route point, then a foward all on the CTI route point. Thats usually how I do it. If you don't have 10 digit coming it you can use a 4 digit.

I don't see the need to translate the number to anything. I have 4 digits coming in from the PRI, and those hit the CTI route point. The route point forwards all to the external address that they are going to be sent to.

We did this in situations where we implemented eFax. We get an outside number for their new fax line, and took the previous number that it used to be and had it (in a CTI route point)forward to the new number. This way they could keep their old fax number, seemingly.

Is there a better way to go about this? And we seem to be getting off the track of my question but I'm all for better solutions.

shodown

chmorin wrote: »

I don't see the need to translate the number to anything. I have 4 digits coming in from the PRI, and those hit the CTI route point. The route point forwards all to the external address that they are going to be sent to.

We did this in situations where we implemented eFax. We get an outside number for their new fax line, and took the previous number that it used to be and had it (in a CTI route point)forward to the new number. This way they could keep their old fax number, seemingly.

Is there a better way to go about this? And we seem to be getting off the track of my question but I'm all for better solutions.

I was just trying to break down your call flow. You can have anything go to a CTI route point. Is your point Registered?

chmorin

-sigh- nothing like discovering database replication issues to make your day turn. Yes, it is registered and functional. Only calls from external will not function.

shodown

Route that call to a internal phone and see if it will still ring

chmorin

shodown wrote: »

Route that call to a internal phone and see if it will still ring

What a fantastic idea. LOL I feel dumb for not doing that.

I sent it to my cell phone, and it just rang for me.

I really hate that I didn't think of that

chmorin

We are changing our provider in the next few weeks so I'll wait for that change before I open a ticket with the provider. At this point, I need to see how they receive the call. The way it looks on my end, is that it is sent as a perfectly fine looking number but gets disconnected from their end. I'll need to find out why.

Who knows, maybe it won't happen when we change providers.