cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
484
Views
0
Helpful
3
Replies

Receiving Q931 Voice traffic on ISDN to AS5400

happykiran
Level 1
Level 1

We are trying to get a switch with Q.931 output to send traffic to us. The switch is an ECT switch that uses NMS voice cards. The switch is sending traffic to PSTN termination and it is working well. However, when it sends traffic to As5300 or AS5400, the called digits seem to be truncated. We have debugged the call using debug isdn q931 and debug voice ccapi inout. It appears that the call cycle is being completed, but the calls are not going through because called digits are not being fully received by the CISCO GW. Eg the number being called is 00442075709976, but the numbers being received at the CISCO GW are 004420757. We are seeking urgent solutions. Can any one help?

1 Accepted Solution

Accepted Solutions

the problem you are having is that the switch doesnt send you the full number en-block but in overlap mode. This means as soon as the switch knows the call is for you without knowing all the following digits, the call is switched to your AS5400. This is a big difference between europe (where number length is usually more or less variable) and USA (where its fixed).

you can fix this problem by doing the following:

isdn overlap-receiving

(without the other parameters)

and make your dial peers not match any destination until you got the full length number. Your dial peers have direct-inward-dial and dial-pattern 00T. This means as soon as the prefix 00 is matched, the call is established further.

As you can see in your debug, you get '004420740', and the information messages with the additional digits. As '004420740', already matches 00T, the call is already progressed to the VoIP cloud. The destination network will then be feeded with the following digits to come which is fine as long as it understands them. Now some older VoIP H323 equipment cant handle overlap digits following so you should not proceed into the VoIP cloud unless you have received all digits. In this case you do:

destination-pattern 004420740.....

(add as many dots as there are digits)

or you add the full number instead to be matched.

if your problem is that the additional digits are simply not forwarded to the remote VoIP peer even it would understand overlap sending, then you can try:

voice service voip

signaling forward unconditional

A few info's from your trace:

a) your sending switch doesnt know how long the number should be. there's no indication about the end of the number. If he would know you would get "SENDING COMPLETE" information with the last digit.

b) your device doesnt know it either as otherwhise it would signal sending complete back on the last digit received to indicate that it wont accept any furtther digits.

there's nothing wrong with that though. Maybe only your remote device how long the number will be. Really depends on the application and networks used.

View solution in original post

3 Replies 3

pacameron
Level 4
Level 4

router configs? debug ISDN q931 logs ?

Can't help without more information.

The config is as follows... The ISDN Q931 log is given below.

Building configuration...

Current configuration : 93751 bytes

!

version 12.1

no service single-slot-reload-enable

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname imass-GW02

!

no boot startup-test

logging rate-limit console 10 except errors

aaa new-model

aaa authentication login default local

aaa authentication ppp default if-needed local

!

!

resource-pool disable

!

!

!

!

voice-fastpath enable

ip subnet-zero

no ip finger

!

isdn switch-type primary-net5

call rsvp-sync

!

voice service pots

!

voice service voip

fax protocol t38 ls-redundancy 0 hs-redundancy 0

h323 call start fast

!

!

!

!

!

fax interface-type modem

mta receive maximum-recipients 0

!

!

!

controller E1 6/0

pri-group timeslots 1-31

!

controller E1 6/1

framing NO-CRC4

ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled ani

!

controller E1 6/2

ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled

!

controller E1 6/3

ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled ani

!

controller E1 6/4

ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled

!

controller E1 6/5

ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled

!

controller E1 6/6

ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled

!

controller E1 6/7

ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled ani

!

controller E1 7/0

ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled ani

!

controller E1 7/1

ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled ani

!

controller E1 7/2

ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled ani

!

controller E1 7/3

ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled ani

!

controller E1 7/4

ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled ani

!

controller E1 7/5

ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled ani

!

controller E1 7/6

ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled ani

!

controller E1 7/7

ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled ani

!

!

interface Loopback0

no ip address

!

interface FastEthernet0/0

ip address 213.232.102.44 255.255.255.0

duplex auto

speed 100

no cdp enable

!

interface FastEthernet0/1

no ip address

shutdown

duplex auto

speed auto

no cdp enable

!

interface Serial0/0

no ip address

shutdown

clockrate 2000000

!

interface Serial0/1

no ip address

shutdown

clockrate 2000000

no cdp enable

!

interface Serial6/0:15

no ip address

encapsulation ppp

dialer map ip 195.54.247.126 imbttest

dialer-group 1

autodetect encapsulation ppp

isdn switch-type primary-net5

isdn overlap-receiving T302 3000

isdn incoming-voice modem

isdn send-alerting

peer default ip address pool setup_pool

no cdp enable

ppp authentication chap pap

ppp multilink

!

interface Async1/00

ip unnumbered FastEthernet0/0

encapsulation ppp

ip tcp header-compression passive

async mode interactive

peer default ip address pool setup_pool

ppp authentication chap pap

!

interface Async1/01

ip unnumbered FastEthernet0/0

encapsulation ppp

ip tcp header-compression passive

async mode interactive

peer default ip address pool setup_pool

ppp authentication chap pap

!

interface Async1/02

ip unnumbered FastEthernet0/0

encapsulation ppp

ip tcp header-compression passive

async mode interactive

peer default ip address pool setup_pool

ppp authentication chap pap

!

interface Async1/03

ip unnumbered FastEthernet0/0

encapsulation ppp

ip tcp header-compression passive

async mode interactive

peer default ip address pool setup_pool

ppp authentication chap pap

!

interface Async1/04

ip unnumbered FastEthernet0/0

encapsulation ppp

ip tcp header-compression passive

async mode interactive

peer default ip address pool setup_pool

ppp authentication chap pap

!

interface Async1/05

ip unnumbered FastEthernet0/0

encapsulation ppp

ip tcp header-compression passive

async mode interactive

peer default ip address pool setup_pool

ppp authentication chap pap

!

interface Async1/06

ip unnumbered FastEthernet0/0

encapsulation ppp

ip tcp header-compression passive

async mode interactive

peer default ip address pool setup_pool

ppp authentication chap pap

!

interface Async1/07

ip unnumbered FastEthernet0/0

encapsulation ppp

ip tcp header-compression passive

async mode interactive

peer default ip address pool setup_pool

ppp authentication chap pap

!

interface Async1/08

!

interface Async5/59

ip unnumbered FastEthernet0/0

encapsulation ppp

ip tcp header-compression passive

async mode interactive

peer default ip address pool setup_pool

ppp authentication chap pap

!

interface Group-Async0

no ip address

no group-range

!

interface Group-Async1

ip unnumbered FastEthernet0/0

encapsulation ppp

ip tcp header-compression passive

async mode interactive

peer default ip address pool setup_pool

ppp authentication chap pap

group-range 5/60 5/107

!

ip local pool setup_pool 195.54.247.97 195.54.247.127

ip classless

ip route 0.0.0.0 0.0.0.0 213.232.102.1

no ip http server

!

access-list 101 permit ip any any

dialer-list 1 protocol ip permit

dialer-list 1 protocol ipx permit

snmp-server community public RO

!

!

voice-port 6/0:D

translate calling 1

cptone GB

timeouts interdigit 2

bearer-cap Speech

!

voice-port 6/1:0

!

voice-port 6/2:0

!

voice-port 6/3:0

!

voice-port 6/4:0

!

voice-port 6/5:0

!

voice-port 6/6:0

!

voice-port 6/7:0

!

voice-port 7/0:0

!

voice-port 7/1:0

!

voice-port 7/2:0

!

voice-port 7/3:0

!

voice-port 7/4:0

!

voice-port 7/5:0

!

dial-peer voice 1 voip

incoming called-number .

destination-pattern 00T

progress_ind setup enable 0

session target ipv4:195.54.247.126

dtmf-relay h245-alphanumeric

codec g711alaw

!

dial-peer voice 2 pots

incoming called-number .

destination-pattern 00T

direct-inward-dial

port 6/0:D

!

!

line con 0

exec-timeout 0 0

logging synchronous

transport input none

line aux 0

line 1/00 1/59

no flush-at-activation

autoselect during-login

autoselect ppp

modem Dialin

line 2/00 5/107

no flush-at-activation

autoselect during-login

autoselect ppp

modem Dialin

!

scheduler allocate 10000 400

end

imass-GW02#

debug ISDN q931 Log

Looking at the following log, It is evident that the Telco switch is sending all the digits. But the Setup_ack is sent by as5400 even before all the digits are completely received. Please help me out.

imass-GW02#

*Jan 6 17:47:34.061: %SYS-5-CONFIG_I: Configured from console by kiran on conso

le

imass-GW02#

*Jan 6 17:48:03.481: ISDN Se6/0:15: RX <- SETUP pd = 8 callref = 0x0C01

*Jan 6 17:48:03.481: Bearer Capability i = 0x8090A3

*Jan 6 17:48:03.481: Channel ID i = 0xA18381

*Jan 6 17:48:03.481: Calling Party Number i = 0x21A3, '2074014200', Pla

n:ISDN, Type:National

*Jan 6 17:48:03.485: Called Party Number i = 0x81, '004420740', Plan:IS

DN, Type:Unknown

*Jan 6 17:48:03.485: High Layer Compat i = 0x9181

*Jan 6 17:48:03.485: ISDN Se6/0:15: TX -> SETUP_ACK pd = 8 callref = 0x8C01

*Jan 6 17:48:03.485: Channel ID i = 0xA98381

*Jan 6 17:48:03.861: ISDN Se6/0:15: RX <- INFORMATION pd = 8 callref = 0x0C01

*Jan 6 17:48:03.861: Called Party Number i = 0x80, '1', Plan:Unknown, T

ype:Unknown

imass-GW02#

*Jan 6 17:48:05.433: ISDN Se6/0:15: RX <- INFORMATION pd = 8 callref = 0x0C01

*Jan 6 17:48:05.433: Called Party Number i = 0x80, '4', Plan:Unknown, T

ype:Unknown

*Jan 6 17:48:05.893: ISDN Se6/0:15: RX <- INFORMATION pd = 8 callref = 0x0C01

*Jan 6 17:48:05.893: Called Party Number i = 0x80, '2', Plan:Unknown, T

ype:Unknown

*Jan 6 17:48:06.073: ISDN Se6/0:15: RX <- INFORMATION pd = 8 callref = 0x0C01

*Jan 6 17:48:06.073: Called Party Number i = 0x80, '2', Plan:Unknown, T

ype:Unknown

*Jan 6 17:48:06.261: ISDN Se6/0:15: RX <- INFORMATION pd = 8 callref = 0x0C01

*Jan 6 17:48:06.261: Called Party Number i = 0x80, '2', Plan:Unknown, T

ype:Unknown

imass-GW02#

*Jan 6 17:48:09.265: ISDN Se6/0:15: TX -> CALL_PROC pd = 8 callref = 0x8C01

*Jan 6 17:48:09.265: ISDN Se6/0:15: TX -> DISCONNECT pd = 8 callref = 0x8C01

*Jan 6 17:48:09.265: Cause i = 0x8081 - Unallocated/unassigned number

*Jan 6 17:48:09.289: ISDN Se6/0:15: RX <- RELEASE pd = 8 callref = 0x0C01

*Jan 6 17:48:09.289: ISDN Se6/0:15: TX -> RELEASE_COMP pd = 8 callref = 0x8C0

1

the problem you are having is that the switch doesnt send you the full number en-block but in overlap mode. This means as soon as the switch knows the call is for you without knowing all the following digits, the call is switched to your AS5400. This is a big difference between europe (where number length is usually more or less variable) and USA (where its fixed).

you can fix this problem by doing the following:

isdn overlap-receiving

(without the other parameters)

and make your dial peers not match any destination until you got the full length number. Your dial peers have direct-inward-dial and dial-pattern 00T. This means as soon as the prefix 00 is matched, the call is established further.

As you can see in your debug, you get '004420740', and the information messages with the additional digits. As '004420740', already matches 00T, the call is already progressed to the VoIP cloud. The destination network will then be feeded with the following digits to come which is fine as long as it understands them. Now some older VoIP H323 equipment cant handle overlap digits following so you should not proceed into the VoIP cloud unless you have received all digits. In this case you do:

destination-pattern 004420740.....

(add as many dots as there are digits)

or you add the full number instead to be matched.

if your problem is that the additional digits are simply not forwarded to the remote VoIP peer even it would understand overlap sending, then you can try:

voice service voip

signaling forward unconditional

A few info's from your trace:

a) your sending switch doesnt know how long the number should be. there's no indication about the end of the number. If he would know you would get "SENDING COMPLETE" information with the last digit.

b) your device doesnt know it either as otherwhise it would signal sending complete back on the last digit received to indicate that it wont accept any furtther digits.

there's nothing wrong with that though. Maybe only your remote device how long the number will be. Really depends on the application and networks used.