VoIP ISDN PRI connect problem

[mobasshar]

I am having problems connecting some calls through ISDN Switches.

The Setup I have is as follows:

ISDN SWITCH ----> ETSI-----> Cisco 3640 ---- > IP -----> AS5300 ---->

ETSI -----> ISDN PBX

I get some calls from ISDN PBX with Bearer Capability of 0x9090A3

which works ok. However I have calls with Bearer Capability of

0x8090A3. These latter calls fails with cause code 0x829C

These are debugs from the destination AS5300.

>Feb 25 16:39:09: ISDN Se2:15: TX -> SETUP pd = 8 callref = 0x029D

>Feb 25 16:39:09: Bearer Capability i = 0x8090A3

>Feb 25 16:39:09: Channel ID i = 0xA98382

>Feb 25 16:39:09: Calling Party Number i = 0x81, '2078910000', Plan:ISDN, Type:National

>Feb 25 16:39:09: Called Party Number i = 0x80, '265551234', Plan:ISDN, Type:Unknown

>Feb 25 16:39:09: ISDN Se2:15: RX <- SETUP_ACK pd = 8 callref = 0x829D

>Feb 25 16:39:10: ISDN Se2:15: TX -> DISCONNECT pd = 8 callref = 0x029D

>Feb 25 16:39:10: Cause i = 0x829C - Invalid number format (incomplete number)

>Feb 25 16:39:10: ISDN Se2:15: RX <- RELEASE pd = 8 callref = 0x829D

>Feb 25 16:39:10: Cause i = 0x819C - Invalid number format (incomplete number)

>Feb 25 16:39:10: ISDN Se2:15: TX -> RELEASE_COMP pd = 8 callref = 0x029D

However check out below, and it works:

>Feb 25 16:49:04: ISDN Se2:15: TX -> SETUP pd = 8 callref = 0x02AA

>Feb 25 16:49:04: Bearer Capability i = 0x9090A3

>Feb 25 16:49:04: Channel ID i = 0xA98381

>Feb 25 16:49:04: Progress Ind i = 0x8183 - Origination address is non-ISDN

>Feb 25 16:49:04: Calling Party Number i = 0x21, 0x83, '2078910000', Plan:ISDN, Type:National

>Feb 25 16:49:04: Called Party Number i = 0x81, '265551234', Plan:ISDN, Type:Unknown

>Feb 25 16:49:04: ISDN Se2:15: RX <- SETUP_ACK pd = 8 callref = 0x82AA

>Feb 25 16:49:10: ISDN Se2:15: RX <- CALL_PROC pd = 8 callref = 0x82AA

>Feb 25 16:49:10: ISDN Se2:15: RX <- ALERTING pd = 8 callref = 0x82AA

>Feb 25 16:49:10: ISDN Se2:15: RX <- CONNECT pd = 8 callref = 0x82AA

>Feb 25 16:49:10: Progress Ind i = 0x8182 - Destination address is non-ISDN

>Feb 25 16:49:10: Connected Number i = 0x0180

>Feb 25 16:49:10: ISDN Se2:15: TX -> CONNECT_ACK pd = 8 callref = 0x02AA

>Feb 25 16:49:16: %ISDN-6-CONNECT: Interface Serial2:0 is now connected to 265551234

>Feb 25 16:49:16: %ISDN-6-DISCONNECT: Interface Serial2:0 disconnected from 265551234 , call lasted 6 seconds

>Feb 25 16:49:16: ISDN Se2:15: TX -> DISCONNECT pd = 8 callref = 0x02AA

>Feb 25 16:49:16: Cause i = 0x8290 - Normal call clearing

>Feb 25 16:49:17: ISDN Se2:15: RX <- RELEASE pd = 8 callref = 0x82AA

>Feb 25 16:49:17: Cause i = 0x8190 - Normal call clearing

>Feb 25 16:49:17: ISDN Se2:15: TX -> RELEASE_COMP pd = 8 callref = 0x02AA

The ISDN cause code I get 0x82 & 0x81 means that

81 - From the private network near the local user [(possibly a local

private branch exchange (PBX)].

82 - From the public network near the local user (local telco switch).

Since I have configured the AS5300 to be an ETSI switch (emulating

network). Its configured to an Panasonic TD-500 PBX running ISDN ETSI

(user side).

The cause code '9C' means invalid number format. However I have

translated the outputs so that the two match. However the only

remaining difference seems to be the Bearer Capability (which its

picking up from the ISDN switch connected to the 3640 and transmitting

to the AS5300 (and I though the bearer capability came from the local

device, however since the AS5300 is configured as the ISDN network

switch, I fear that its passing the bearer capability learnt at the

remote end).

I know its the ISDN PBX thats being fussy, but I have no control over

the PBX or the ISDN switch (ISDN switch being PTT). As I have no

control over the origination calls, I am using the translate rules to

adapt to plan and type that the PBX accepts.

If the call is made from the ISDN switch by the carrier then I get

bearer capability that works ( 0x9090A3). However if the carrier

receieves calls from outside its PBX then it comes with bearer

capability (0x8090A3) that does not work.

Is there a way that I can nail up the bearer capability in the AS5300

so that the PBX always gets a constant bearer capability from the

AS5300.

On the 3640 I have it configured as follows:

>translation-rule 1

> Rule 1 00 00 international unknown

> Rule 2 00 00 reserved unknown

>!

>translation-rule 10

> Rule 1 null 2078910000 ANY national

>!

>interface Serial3/0:15

> no ip address

> no logging event link-status

> isdn switch-type primary-net5

> isdn overlap-receiving

> isdn incoming-voice voice

> isdn T310 120000

> isdn send-alerting

> no cdp enable

>!

>voice-port 3/0:15

> translate calling 10

> translate called 1

>!

>dial-peer voice 265000 voip

> preference 3

> destination-pattern 65T

> session target ipv4:voip.dubai.net.ae

> codec g729br8

> fax rate 4800

> ip precedence 3

>!

On my AS5300 I have it configured as follows:

>interface Serial2:15

> no ip address

> isdn switch-type primary-net5

> isdn not-end-to-end 64

> isdn protocol-emulate network

> isdn incoming-voice modem

> isdn map address 8* plan isdn type unknown

> isdn map address 9* plan isdn type unknown

> no cdp enable

> !

>dial-peer voice 265000 pots

> destination-pattern 65......

> port 2:D

> prefix 2

> forward-digits all

>!

I hope I have provided enough information here to help decipher my problem.

[dkundu]

You can configure the bearer cap parameter on a Cisco AS5300 by using

#voice-port 2:D

(config-voiceport)#bearer-cap ?

3100hz enable 3100hz

speech enable speech

Debashis

[mimckee]

It looks to me like it would be an ISDN plan and type issue. What should your plan and type be. ISDN and unknown? It looks like when it fails the plan and type are unknown and unknown. I am little confused on your debugs. Does the first call fail and the first work?

Hope this helps,

-Mckee

[scadora]

I am also a little confused by the debug. In the first example (which I assume is the failed call), the 5300 transmits the disconnect. That would suggest to me that the problem lies to the left of the 5300 in your topology--in the voip leg or between the 3600 and the switch. Can you get the isdn debug from the 3600 as well for a failed call? Possibly debug voip ccapi inout would also be helpful.

Shelly

[mobasshar]

Further investigation reveals the following:

On call that succeed the PBX sends a CALL_PROC and on calls that fail the PBX sends SETUP_ACK to which the ISDN switch sends an DISCONNECT! see below:

CALL OK...........

Feb 28 10:52:54: ISDN Se2:15: TX -> SETUP pd = 8 callref = 0x054A

Feb 28 10:52:54: Sending Complete

Feb 28 10:52:54: Bearer Capability i = 0x9090A3

Feb 28 10:52:54: Channel ID i = 0xA98381

Feb 28 10:52:54: Progress Ind i = 0x8483 - Origination address is non-ISDN

Feb 28 10:52:54: Calling Party Number i = 0x01, 0x83, 'xxxxxxxxx', Plan:ISDN, Type:Unknown

Feb 28 10:52:54: Called Party Number i = 0x81, '2100', Plan:ISDN, Type:Unknown

Feb 28 10:52:54: ISDN Se2:15: RX <- CALL_PROC pd = 8 callref = 0x854A

Feb 28 10:52:54: ISDN Se2:15: RX <- ALERTING pd = 8 callref = 0x854A

Feb 28 10:52:58: ISDN Se2:15: TX -> DISCONNECT pd = 8 callref = 0x054A

Feb 28 10:52:58: Cause i = 0x8290 - Normal call clearing

Feb 28 10:52:59: ISDN Se2:15: RX <- RELEASE pd = 8 callref = 0x854A

Feb 28 10:52:59: Cause i = 0x8190 - Normal call clearing

Feb 28 10:52:59: ISDN Se2:15: TX -> RELEASE_COMP pd = 8 callref = 0x054A

CALL FAILS...........

Feb 28 10:09:56: ISDN Se2:15: TX -> SETUP pd = 8 callref = 0x0546

Feb 28 10:09:56: Bearer Capability i = 0x8090A3

Feb 28 10:09:56: Channel ID i = 0xA98381

Feb 28 10:09:56: Calling Party Number i = 0x81, 'xxxx', Plan:ISDN, Type:Unknown

Feb 28 10:09:56: Called Party Number i = 0x81, '29560461', Plan:ISDN, Type:Unknown

Feb 28 10:09:56: ISDN Se2:15: RX <- SETUP_ACK pd = 8 callref = 0x8546

Feb 28 10:09:57: ISDN Se2:15: TX -> DISCONNECT pd = 8 callref = 0x0546

Feb 28 10:09:57: Cause i = 0x829C - Invalid number format (incomplete number)

Feb 28 10:09:57: ISDN Se2:15: RX <- RELEASE pd = 8 callref = 0x8546

Feb 28 10:09:57: Cause i = 0x819C - Invalid number format (incomplete number)

Feb 28 10:09:57: ISDN Se2:15: TX -> RELEASE_COMP pd = 8 callref = 0x0546

[mobasshar]

The first debug fails. The second one works.

In the first one the CLI has been inserted with the translation ule as it originates with a NULL CLI, Plan: unknown and type: International.

The PBX is expecting PLAN: ISDN type: unknown.

I now also have access to the PBX and can make changes (though its limited what the PBX will allow you).

[vimoreno]

A few thoughts on this:

1. Set your gateway (or Call Manager if you have one) to send both type and numbering plan as "unknown".

2. Make sure the number you are using as the calling party is a full E.164 (11 digit) number. Some CO switches won't route the calls if this number is in a different format.

3. It looks like calls are failing when you try to access external numbers. The successful call actually goes to a 4 digit extension.

4. Having said the above, I find it very strange that the gateway is actually the one disconnecting the call after receiving a SETUP_ACK. You may want to verify that you are using the correct PRI protocols on both ends, also now that you have access to the PBX, you may want to change the PRI protocol and try something else, as this looks like a message incompatibility.

[vimoreno]

One thing you want to watch is that your setup messages have a called party value of 265551234, which in the NANP doesn't mean much as it is an 9 digit number, that's why you get the "incomplete numbe" cause codes. If you are going to send numbers to the Telco they need to be either 7, 10 or 11 digit numbers (other than special 3 digit numbers), otherwise the telco doesn't have the necessary info to route the call (hence "incomplete number"