ISDN Configuration issue

Unanswered Question
Apr 30th, 2007

Hi,

We are having an issue with a voice over ip architecture where basically we have one pbx on one end connected to a 3825 through a qsig E1 and same thing on the other end. Both routers are connected through the LAN since this is a lab environment before putting it into production.

The call goes through from one end but not from the other. It does go through if we initiate the call from the router instead of the PBX on the not working side.

While troubleshooting, we found the isdn error "invalid call reference value" and the L3 BadPeerMsg.

Apart from this, the configuration is straight forward with session targets and the call does get routed to the pbxs.

Please if you have seen this kind of error before, let us know how you dealt with it.

Regards.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
Loading.
Paolo Bevilacqua Mon, 04/30/2007 - 07:02

Hi,

can you collect output of "debug isdn q931"for the failed and successful call (initiated by the router) ?

The "invalid call reference" error may be due to some IOS bug, suggest you upgrade to latest maintenance release of the chosen IOS train.

l.mourits Tue, 05/01/2007 - 13:58

There are quite some ugly bugs regarding ISDN signalling and QSIG trunks, I would first upgrade to the latest release before testing any.

HTH,

Leo

jskalli Thu, 05/03/2007 - 08:57

I have upgraded to the latest IOS with no success. Here are the two debugs. First the working one:

routeur 3825 cote maquette

sens reussi

le numero 5715 du site maquette appelle vers le site centrale 1851

***************************************************************************

g isdn q931

debug isdn q931 is ON.

BeniMellal#

ISDN Se1/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x0001

Bearer Capability i = 0x9090A3

Standard = CCITT

Transfer Capability = 3.1kHz Audio

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA1839F

Preferred, Channel 31

Facility i = 0x91AA068001008201008B0100A10B02010306042B0C09008400

Progress Ind i = 0x8183 - Origination address is non-ISDN

Calling Party Number i = 0x0183, '5715'

Plan:ISDN, Type:Unknown

Called Party Number i = 0x81, '1851'

Plan:ISDN, Type:Unknown

Locking Shift to Codeset 5

Codeset 5 IE 0x32 i = 0x81

ISDN Se1/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8001

Channel ID i = 0xA9839F

Exclusive, Channel 31

ISDN Se1/0/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x8001

Facility i = 0x91AA068001008201008B0100A1150202295006082B0C02885302010603050001000000

Facility i = 0x91AA068001008201008B0100A10C0202296006042B0C09018400

Facility i = 0x91AA068001018201018B0100A1130202297006082B0C0288530201023003800164

Facility i = 0x91AA068001008201018B0100A1410202298006082B0C0288530201003031810C0C06118031383531740200C08221031902000400000000600000000400C00E38008104800500008F806301C37C01C3

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

ISDN Se1/0/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x0001

Cause i = 0x8090 - Normal call clearing

ISDN Se1/0/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x8001

ISDN Se1/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x0001

jskalli Thu, 05/03/2007 - 08:59

And here is the Debug of the call Not working:

ISDN Se1/0/0:15 Q931: Applying typeplan for sw-type 0x16 is 0x0 0x0, Calling num 1851

ISDN Se1/0/0:15 Q931: Applying typeplan for sw-type 0x16 is 0x0 0x0, Called num 5715

ISDN Se1/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0080 (re-assembled)

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98381

Exclusive, Channel 1

Facility i = 0x91AA068001008201008B0100A11502022E9006082B0C02885302010603050001000000

Facility i = 0x91AA068001018201018B0100A15202022EA006082B0C0288530201073042A240303E810100820101A310A0098004313835310A01003003800164A40A8003323530300380010AA50B8004313835313003800164A60B8004353731353003800139

Facility i = 0x91AA068001008201008B0100A11502022EB006082B0C02885302014C30058003323530

Facility i = 0x91AA068001018201018B0100A12C02022EC006082B0C028853020104301C80033235300202141F800332353002021420A00380010AA10380010A

Facility i = 0x91AA068001008201008B0102A11402022ED002013B300B30090A01050A01030A0104

Facility i = 0x91AA068001008201008B0100A10C02022EE006042B0C09008400

Facility i = 0x91AA068001018201018B0100A11302022EF006082B0C0288530201013003800164

Facility i = 0x91AA068001018201018B0100A11302022F0006082B0C0288530201113003800139

Facility i = 0x91AA068001008201018B0100A13402022F1006082B0C02885302010030248222031C0200040D000000200000000400C00E3800810480E500000F040088804F021F00

Calling Party Number i = 0x80, '1851'

Plan:Unknown, Type:Unknown

Called Party Number i = 0x80, '5715'

Plan:Unknown, Type:Unknown

High Layer Compat i = 0x9181

ISDN Se1/0/0:15 Q931: TX -> SEGMENT pd = 8 callref = 0x0080

Segmented Message i = 0x8105

1st segment. Segments remaining : 1

ISDN Se1/0/0:15 Q931: TX -> SEGMENT pd = 8 callref = 0x0080

Segmented Message i = 0x0005

Segments remaining : 0

ISDN Se1/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8080

Cause i = 0x85D1 - Invalid call reference value

ISDN Se1/0/0:15 Q931: Applying typeplan for sw-type 0x16 is 0x0 0x0, Calling num 1851

ISDN Se1/0/0:15 Q931: Applying typeplan for sw-type 0x16 is 0x0 0x0, Called num 5715

ISDN Se1/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0081 (re-assembled)

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98381

Exclusive, Channel 1

Facility i = 0x91AA068001008201008B0100A11502022E9006082B0C02885302010603050001000000

Plan:Unknown, Type:Unknown

Called Party Number i = 0x80, '5715'

Plan:Unknown, Type:Unknown

High Layer Compat i = 0x9181

ISDN Se1/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8080

Cause i = 0x85D1 - Invalid call reference value

ISDN Se1/0/0:15 Q931: TX -> SEGMENT pd = 8 callref = 0x0081

Segmented Message i = 0x8105

1st segment. Segments remaining : 1

ISDN Se1/0/0:15 Q931: TX -> SEGMENT pd = 8 callref = 0x0081

Segmented Message i = 0x0005

Segments remaining : 0

ISDN Se1/0/0:15 **ERROR**: L3_BadPeerMsg: event 0x5A cr 0x80 callid 0x0

ISDN Se1/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8081

Cause i = 0x85D1 - Invalid call reference value

ISDN Se1/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8081

Cause i = 0x85D1 - Invalid call reference value

ISDN Se1/0/0:15 **ERROR**: L3_BadPeerMsg: event 0x5A cr 0x81 callid 0x0

BeniMellal#

mchandak Thu, 05/03/2007 - 09:48

can u attach show run from the router where the 2nd debug was collected from ?? One possible reason is the "segment" msg being sent by the Router and the other end is unable to interpret it. Also, ensure that the isdn switch-type is set is the same configured on both ends

jskalli Thu, 05/03/2007 - 10:54

Here is the show run with IP hidden.

Thanks.

Building configuration...

Current configuration : 2413 bytes

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname BeniMellal

!

boot-start-marker

boot system flash:c3825-entservicesk9-mz.124-13a.bin

boot system flash:c3825-entservicesk9-mz.124-13b.bin

boot-end-marker

!

no logging on

enable secret 5

!

no aaa new-model

network-clock-participate slot 1

voice-card 0

dspfarm

!

voice-card 1

dspfarm

!

ip cef

!

!

!

!

no ip domain lookup

isdn switch-type primary-qsig

!

!

!

!

!

!

!

!

!

!

voice iec syslog

!

!

!

!

!

!

controller E1 1/0/0

pri-group timeslots 1-31

!

!

!

!

interface GigabitEthernet0/0

ip address x.x.x.x 255.255.255.0

duplex auto

speed auto

media-type rj45

!

interface GigabitEthernet0/1

ip address 192.168.1.1 255.255.255.0

duplex auto

speed auto

media-type rj45

!

interface Serial1/0/0:15

no ip address

encapsulation hdlc

isdn switch-type primary-qsig

isdn protocol-emulate network

isdn incoming-voice voice

no isdn T309-enable

no cdp enable

!

interface Serial2/0

ip address x.x.x.x 255.255.255.0

encapsulation ppp

serial restart-delay 0

!

interface Serial2/1

no ip address

shutdown

serial restart-delay 0

!

interface Serial2/2

no ip address

shutdown

serial restart-delay 0

!

interface Serial2/3

no ip address

shutdown

serial restart-delay 0

!

ip route 0.0.0.0 0.0.0.0 x.x.x.x

!

!

ip http server

no ip http secure-server

!

!

!

!

control-plane

!

!

!

voice-port 1/0/0:15

!

!

!

!

!

dial-peer voice 57 pots

destination-pattern 57..

direct-inward-dial

port 1/0/0:15

forward-digits all

!

dial-peer voice 1000 voip

destination-pattern 1...

session target ipv4:x.x.x.x

ip qos dscp cs5 media

!

dial-peer voice 56 pots

destination-pattern 56

direct-inward-dial

port 1/0/0:15

forward-digits all

!

dial-peer voice 4000 voip

destination-pattern 4...

session target ipv4:x.x.x.x

ip qos dscp cs5 media

!

dial-peer voice 23 pots

destination-pattern 2300

direct-inward-dial

port 1/0/0:15

forward-digits all

!

dial-peer voice 7000 voip

destination-pattern 7...

session target ipv4:x.x.x.x

ip qos dscp cs5 media

!

dial-peer voice 5715 pots

destination-pattern 5715

direct-inward-dial

port 1/0/0:15

forward-digits all

!

!

!

line con 0

exec-timeout 0 0

logging synchronous

stopbits 1

line aux 0

stopbits 1

line vty 0 4

exec-timeout 0 0

password

login

!

scheduler allocate 20000 1000

!

end

mchandak Thu, 05/03/2007 - 11:36

looks like the issue is with the Facility IE message. Looks like we are sending a lot of information, which is not supported on the other end. Can you check the PBX configuration to see what all is the PBX typing to send within the Facility IE messages ?

jskalli Thu, 05/03/2007 - 22:30

Hi,

Unfortunately, we do not have access to any traces on the pbx side (Siemens Hicom 150). So, I cannot get the info you are asking for.

Regards.

Paolo Bevilacqua Fri, 05/04/2007 - 00:33

Hello,

What IOS are you running now ? Can you send the configuration ?

Apparentely the problem is due to segmentation. Either the cisco does not segment correctly, or the PBX does not understand how the cisco does that. You need to get some support from the PBX people in order to see whay so many facilities are being passed.

jskalli Sat, 05/05/2007 - 11:56

Can you please explain the purpose of facilities .

Thanks.

Paolo Bevilacqua Sat, 05/05/2007 - 12:10

Hard to tell, one would need to decode them. For sure it is a lot of them. I think you have two choice:

1. find a way to not pass that many facilities, perhaps if you was to use SIP, it would not pass that many facilities Also, there is aparamente "qsig decode" under voice service, that you can try tpo see if it changes something.

2. use transparent tccs to trunk the two pbx's. Look for TCCS on CCO, there are configuration guides. In this way, the signaling is passed unchanged, and the voice channels are trunked permanently with a compression of your choice, and VAD optionally.

phershaw Thu, 08/02/2007 - 06:38

Hi,

Did you resolve this issue ?

I am having similar problems where the router is sending segmented ISDN messages to the PBX, which fails the call.

Phil

jskalli Tue, 08/07/2007 - 02:55

Hi,

An upgrade of the IOS plus the following command fixed the problem:

voice service voip

qsig decode

isdn incoming-voice modem

Regards.

Actions

This Discussion