call doesnt get to PSTN

[andres.pasten]

Hi,

I´ve a rare issue. I've a Cisco 2821 as gateway with 3 E1, two connected to PSTN and the last one connected to an IVR.

a) E1-PSTN

interface Serial1/0/0:15

no ip address

isdn switch-type primary-net5

isdn incoming-voice voice

no cdp enable

b) E1-IVR

interface Serial0/0/0:15

description E1 IVR MKD

no ip address

isdn switch-type primary-net5

isdn protocol-emulate network

isdn incoming-voice voice

isdn bchan-number-order descending

no cdp enable

I can make calls from the PSTN to a number assigned to the E1-IVR, but when a call to E1-PSTN comes from the E1-IVR, it receives ringback tone but the call is not sended to the PSTN. These are the dial-peers:

1.- E1-PSTN

dial-peer voice 900 pots

preference 1

destination-pattern 9.......

incoming called-number .

fax rate disable

direct-inward-dial

port 1/0/0:15

forward-digits 7

2.- E1-IVR

dial-peer voice 6432 pots

destination-pattern 6432

incoming called-number .

fax rate disable

direct-inward-dial

port 0/0/0:15

forward-digits all

Here is a debug for a call from PSTN to IVR:

*Aug  3 17:05:50.997: ISDN Se1/0/1:15 Q931: RX <- SETUP pd = 8  callref = 0x020E

        Sending Complete

        Bearer Capability i = 0x8090A3

                Standard = CCITT

                Transfer Capability = Speech 

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0xA1838B

                Preferred, Channel 11

        Calling Party Number i = 0x2183, '28385500'

                Plan:ISDN, Type:National

        Called Party Number i = 0xC1, '5826432'

                Plan:ISDN, Type:Subscriber(local)

*Aug  3 17:05:51.009: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x2 0x1, Calling num 28385500

*Aug  3 17:05:51.009: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x4 0x1, Called num 6432

*Aug  3 17:05:51.009: ISDN Se1/0/1:15 Q931: TX -> CALL_PROC pd = 8  callref = 0x820E

        Channel ID i = 0xA9838B

                Exclusive, Channel 11

*Aug  3 17:05:51.009: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8  callref = 0x6052

        Sending Complete

        Bearer Capability i = 0x8090A3

                Standard = CCITT

                Transfer Capability = Speech 

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0xA9839F

                Exclusive, Channel 31

        Calling Party Number i = 0x2183, '28385500'

                Plan:ISDN, Type:National

        Called Party Number i = 0xC1, '6432'

                Plan:ISDN, Type:Subscriber(local)

*Aug  3 17:05:51.033: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8  callref = 0xE052

        Channel ID i = 0xA9839F

                Exclusive, Channel 31

*Aug  3 17:05:51.033: ISDN Se0/0/0:15 Q931: RX <- CONNECT pd = 8  callref = 0xE052

        Channel ID i = 0xA9839F

                Exclusive, Channel 31

        Progress Ind i = 0x8182 - Destination address is non-ISDN

*Aug  3 17:05:51.037: %ISDN-6-CONNECT: Interface Serial0/0/0:30 is now connected to 6432 N/A

*Aug  3 17:05:51.037: ISDN Se0/0/0:15 Q931: TX -> CONNECT_ACK pd = 8  callref = 0x6052

*Aug  3 17:05:51.041: ISDN Se1/0/1:15 Q931: TX -> CONNECT pd = 8  callref = 0x820E

        Progress Ind i = 0x8182 - Destination address is non-ISDN

*Aug  3 17:05:51.093: ISDN Se1/0/1:15 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x020E

*Aug  3 17:05:51.093: %ISDN-6-CONNECT: Interface Serial1/0/1:10 is now connected to 28385500 N/A

and here is a debug for a call from IVR to PSTN:

*Aug  3 17:01:14.317: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8  callref = 0x0013

        Bearer Capability i = 0x8090A3

                Standard = CCITT

                Transfer Capability = Speech 

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0xA18381

                Preferred, Channel 1

        Calling Party Number i = 0x4180, '6432'

                Plan:ISDN, Type:Subscriber(local)

        Called Party Number i = 0xC1, '95853444'

                Plan:ISDN, Type:Subscriber(local)

        Sending Complete

*Aug  3 17:01:14.329: ISDN Se1/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x4 0x1, Calling num 6432

*Aug  3 17:01:14.333: ISDN Se1/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x4 0x1, Called num 5853444

GW-LCOCHRANE#

GW-LCOCHRANE#

GW-LCOCHRANE#

*Aug  3 17:01:14.333: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8  callref = 0x8013

        Channel ID i = 0xA98381

                Exclusive, Channel 1

*Aug  3 17:01:14.333: ISDN Se1/0/0:15 Q931: TX -> SETUP pd = 8  callref = 0x6049

        Sending Complete

        Bearer Capability i = 0x8090A3

                Standard = CCITT

                Transfer Capability = Speech 

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0xA9839E

                Exclusive, Channel 30

        Calling Party Number i = 0x4180, '6432'

                Plan:ISDN, Type:Subscriber(local)

        Called Party Number i = 0xC1, '5853444'

                Plan:ISDN, Type:Subscriber(local)

*Aug  3 17:01:14.377: ISDN Se1/0/0:15 Q931: RX <- CALL_PROC pd = 8  callref = 0xE049

        Channel ID i = 0xA9839E

                Exclusive, Channel 30

*Aug  3 17:01:14.409: ISDN Se1/0/0:15 Q931: RX <- ALERTING pd = 8  callref = 0xE049

        Progress Ind i = 0x8282 - Destination address is non-ISDN 

        Progress Ind i = 0x8288 - In-band info or appropriate now available

On both cases, the calls move from one E1 to the other, but on the second case the call remain on the E1.

The only difference that I've find is on the called party number type. Any hint would be helpfull

TIA

Andres Pasten

Adexus S.A.

[hzaben]

Andres

few questions :

- what's the call flow in both ? smthing like ip-phone --> CUCM --> h323 --> GW --> e1 0/0/0 --> isdn --> back to e1 1/0/0 --> h323 --> CUCM

- can you share :

*show run / show version

* for two test calls (working and non-working)

debug voice ccapi inout

debug h225 asn1

debug isdn q931

debug h245 asn1

please specify the call info for the above

regards,

haitham

[andres.pasten]

Haitham,

Thanks for your reply, I´ll have tomorrow the requested debugs.

1.- But for now I can tell you that the flow for the working call is:

PSTN -> E1 1/0/0 -> GW -> E1 0/0/0 -> IVR

that´s when you call the DN 6432 that is defined on IVR

2.- The inverse flow, that´s when DN 6432 wants to call any PSTN number, is not working.

See you.

Andres

[linuxchild]

I'm not sure this will help , but give it a try , under your dialpeer add

Router(config-dial-peer)#numbering-type unknown

Regards

[andres.pasten]

Hi,

I've tried, but this command operates as a filter rule. For example, if I set numebring-type to unknown, it only permit unknown calls to pass. And the calls arrives marked as Subscriber, so it only pass when I set numbering-type to subscriber.

However, anyone know why this set can prevent a call to be sended to PSTN?

Thanks anyway.

Andres Pasten

[andres.pasten]

Haitham,

I´ve uploaded the requested files.

Please let me know if you find something.

TIA

Andres Pasten

[hzaben]

Andres

Why I’m seeing h225 if the call flow like u mentioned above ? can you clarify the exact call flow pls ?

Also you entered the debugs separately , I need to debug all the requested then to make the call if you can .

Thanks

Haitham

[andres.pasten]

Haitham,

I'll get the debugs later, because there is a lot of traffic to isolate the calls. I understood that you need the debugs one per time, sorry.

And about the traffic, this are calls that goes from one E1 to another E1:

a) Incoming call:

1) Someone on PSTN calls to 5826432

2) The call arrives to E1 1/0/0 or 1/0/1 (that are connected to PSTN)

3) Then traslation rule applies, dropping the first 3 digits, remaining the call to 6432

4) Then dial-peer voice 6432 pots applies, sending the call to E1 0/0/0 connected to IVR

5) Call is received ok on IVR, establishing conversation

b) Outgoing call:

1) Someone on IVR dials to PSTN using 9 as prefix, on example 96861315 is dialed

2) The call arrives to E1 0/0/0 (that is connected to IVR)

3) Then dial-peer voice 900 pots applies, sending the call to E1 1/0/0 connected to PSTN, and dropping the prefix 9.

4) Caller receives ringback tone, but the call is not sended to PSTN.

I hope that clarifies the call flow

TIA

Andres

El mensaje fue editado por: Andres Pasten august 09

[andres.pasten]

Haitham,

I´ve uploaded both full debugs:

- debug_incoming_090811_2.txt has the debug for the incoming call explained on my last post, which is working fine.

- debug_outgoing_090811_2.txt has the debug for the outgoing call explianed on my last post, which is not arriving to PSTN.

However there was less traffic on E1, some calls has appeared on the debugs.

Please let me know if you need something else.

TIA

Andres Pasten.

[hzaben · Accepted solution]

Andres

Thanks for the logs and clarification , the call is disconnected since the IVR user drop the line :

*Aug 9 14:51:02.237: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x000A

Cause i = 0x8190 - Normal call clearing

That’s because there was no progress in the call from the pstn side , even the pstn user didn’t answer the call but the but the ivr user didn’t wait till they send disconnect msg , or the user answer but they are not able to send the appropriate msg , see below :

We sent setup :

We sent setup with sending completet flag for them to start routing the call :

*Aug 9 14:50:45.637: ISDN Se1/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x06A9

Sending Complete

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9839F

Exclusive, Channel 31

Calling Party Number i = 0x4180, '6722'

Plan:ISDN, Type:Subscriber(local)

Called Party Number i = 0xC1, '6861309'

Plan:ISDN, Type:Subscriber(local)

Then they sent proceed :

Aug 9 14:50:45.685: ISDN Se1/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x86A9

Channel ID i = 0xA9839F

Exclusive, Channel 31

Now we received alerting with inband info (ringback )

*Aug 9 14:50:45.717: ISDN Se1/0/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x86A9

Progress Ind i = 0x8282 - Destination address is non-ISDN

Progress Ind i = 0x8288 - In-band info or appropriate now available

*Aug 9 14:50:45.717: //7220/CC0200F787ED/CCAPI/cc_api_call_alert:

Interface=0x46AC2220, Progress Indication=DESTINATION IS NON ISDN(2), Signal Indication=SIGNAL RINGBACK(1)

Then the call now is pending on the isdn to send connect message which is not done , please refer to your isdn provider for investigation .

Let me know if any clarification .

-- haitham

[andres.pasten]

Haitham,

Thanks for your support. I schedule test with telephony provider and it detected that rejects the call because of the ANI was in no isdn format. The E1 was sending just 4 digits, when I added the zone prefix + header, the call proceeds.

Once again thanks.

Bye,

Andres