IEC errcode 23 Incompatible protocols???

[ivan.marakovic]

HI,

Can someone help me with the following problem?

On our VOIP gateway (3640 + NM-HDV + VWIC-1MFT-E1 + IOS 13.3.11T) we are getting the following IEC errors:

Syd-vgw-r1# sh voice statistics iec since-reset

Internal Error Code counters

----------------------------

Counters since last reset (2002-03-01T00:00:15Z):

SUBSYSTEM Application Framework [subsystem code 3]

[errcode 23] Incompatible protocols 4

The only "explanation" I have found was this:

Code 23

Incompatible protocols

A matched dial peer could not be used for the outbound leg because the gateway cannot translate between the inbound and outbound protocols.

Category 47

Would anyone be able to explain the real meaning of the above?

Any help will be much appreciated.

Regards

Ivan

[teodorgeorgiev]

Show your config and espedially the dialpeers + routing logic.

[ivan.marakovic]

Hi Teodor,

the part of the conf is below:

voice-card 1

!

ip cef

!

!

isdn switch-type primary-net5

controller E1 1/0

pri-group timeslots 1-31

!

interface Loopback0

ip address 10.1.2.8 255.255.255.0

h323-gateway voip interface

h323-gateway voip bind srcaddr 10.1.2.8

!

interface FastEthernet0/0

description Connection to Syd-dst-r1

ip address 10.5.2.5 255.255.255.252

speed 100

full-duplex

!

interface FastEthernet0/1

description Connection to Syd-dst-r2

ip address 10.5.2.13 255.255.255.252

speed 100

full-duplex

!

interface Serial1/0:15

no ip address

no logging event link-status

isdn switch-type primary-net5

isdn protocol-emulate network

isdn incoming-voice voice

isdn T310 12000

no cdp enable

!

router ospf 1

log-adjacency-changes

network 10.1.2.0 0.0.0.255 area 0

network 10.5.2.4 0.0.0.3 area 0

network 10.5.2.12 0.0.0.3 area 0

!

no ip http server

!

ip classless

control-plane

!

!

!

voice-port 1/0:15

input gain 3

cptone AU

timeouts interdigit 4

!

dial-peer cor custom

!

dial-peer voice 1 pots

destination-pattern 555.

port 1/0:15

dial-peer voice 4410 pots

preference 1

destination-pattern 410T

port 1/0:15

!

dial-peer voice 4412 voip

preference 2

destination-pattern 410T

session target ipv4:10.1.2.9

ip qos dscp cs5 media

!

dial-peer voice 4420 pots

preference 1

destination-pattern 420....

direct-inward-dial

port 1/0:15

!

dial-peer voice 4422 voip

preference 2

destination-pattern 420....

session target ipv4:10.1.2.9

ip qos dscp cs5 media

!

dial-peer voice 4430 pots

preference 1

destination-pattern 430....

direct-inward-dial

port 1/0:15

!

dial-peer voice 4432 voip

preference 2

destination-pattern 430....

session target ipv4:10.1.2.9

ip qos dscp cs5 media

!

dial-peer voice 4440 pots

preference 1

destination-pattern 440T

port 1/0:15

!

dial-peer voice 4442 voip

preference 2

destination-pattern 440T

session target ipv4:10.1.2.9

ip qos dscp cs5 media

!

dial-peer voice 5101 pots

incoming called-number [1-9]10T

no digit-strip

port 1/0:15

!

dial-peer voice 5201 pots

incoming called-number [1-9]20....

no digit-strip

direct-inward-dial

port 1/0:15

!

dial-peer voice 5301 pots

incoming called-number [1-9]30....

no digit-strip

direct-inward-dial

port 1/0:15

!

dial-peer voice 5401 pots

incoming called-number [1-9]40T

no digit-strip

port 1/0:15

!

dial-peer voice 210 voip

destination-pattern 210T

session target ipv4:10.1.3.8

incoming called-number 410T

codec g726r24

ip qos dscp cs5 media

ip qos dscp cs5 signaling

no vad

!

dial-peer voice 211 voip

destination-pattern 210T

session target ipv4:10.1.3.9

incoming called-number 410T

ip qos dscp cs5 media

ip qos dscp cs5 signaling

no vad

!

dial-peer voice 220 voip

destination-pattern 220....

session target ipv4:10.1.3.8

incoming called-number 420....

ip qos dscp cs5 media

ip qos dscp cs5 signaling

no vad

!

dial-peer voice 221 voip

destination-pattern 220....

session target ipv4:10.1.3.9

incoming called-number 420....

ip qos dscp cs5 media

ip qos dscp cs5 signaling

no vad

!

dial-peer voice 230 voip

destination-pattern 230....

session target ipv4:10.1.3.8

incoming called-number 430....

ip qos dscp cs5 media

ip qos dscp cs5 signaling

no vad

!

dial-peer voice 231 voip

destination-pattern 230....

session target ipv4:10.1.3.9

incoming called-number 430....

ip qos dscp cs5 media

ip qos dscp cs5 signaling

no vad

!

dial-peer voice 240 voip

destination-pattern 2240T

session target ipv4:10.1.3.8

incoming called-number 440T

ip qos dscp cs5 media

ip qos dscp cs5 signaling

!

dial-peer voice 241 voip

destination-pattern 240T

session target ipv4:10.1.3.9

incoming called-number 440T

ip qos dscp cs5 media

ip qos dscp cs5 signaling

See if you can spot anything.

Regards

Ivan

[teodorgeorgiev]

Hi Ivan,

honestly said I can't be sure of the core of the problem.

What I suspect is:

Some of your calls try to come on VoIP dial-peer and to leave via VoIP dial-peer, but this is almost not possible, because Cisco usually gives another error. If your IOS is not IP-IP, you can't have calls where both the inbound and the outbound legs are IP.

The other thing is (but also very strange to believe) someone is sending you SIP calls. You could check if your SIP service is stopped. The simpliest thing to do: run a portscan against your voice gateway and see if you have the SIP port 5060 opened.

The last thing is the G726 hard-coded codec at dial-peer 210.

That is what I may suggest you, even if it sounds a bit funny..

If you can provide more information (like debug), or on which dialpeers the error has occured, it will bring some light.

[ivan.marakovic]

Thank you Teodor.

Your help is much appreciated.

It is possible that the call comes via VOIP and tries to leave via VOIP. At that time I had an E1 interface shutdown (because some of DSP were faulty)

Other gateways were still sending calls to it which were than sent to the other gateway in the same site.

I do not think these calls were failing.

I did some debugging and it appeared that the error was coming when the voip call comes in and tries to come out via voip again.

The IOS we have here is IP PLUS 12.3.11T.

Just to explain the scenario I have here.

We have multiple sites with two voip gateways at each.

Each gateway from one site will send voip to any of the two gw from the other site (same preference)

Then when the call arrives to the gateway, it will try to send it via E1 , but if not successful then it will send it via VIOP to the other gw on the same site.

As you said, perhaps this is not supported with the IOS used.

Would IP PLUS IOS for 3640 support that?

Can I jump to something else here?

Every 10 - 15 minutes, I am getting calls that are disconnected with the following cause:

DisconnectCause 7F , DisconnectText interworking (127),

syslog messages are below:

20050607 083828 10.1.3.8 - <189>8248: Jun 7 08:38:02.733: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 2, ConnectionId 47D6D241 D66611D9 84440007 85111F61, SetupTime 08:37:56.473 UTC Tue Jun 7 2005, PeerAddress , PeerSubAddress , DisconnectCause 7F , DisconnectText interworking (127), ConnectTime 08:37:56.633 UTC Tue Jun 7 2005, DisconnectTime 08:38:02.733 UTC Tue Jun 7 2005, CallOrigin 2, ChargedUnits 0, InfoType 2, TransmitPackets 304, TransmitBytes 6080, ReceivePackets 302, ReceiveBytes 6040

20050607 083829 10.1.3.8 - <189>8249: Jun 7 08:38:02.745: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 1, ConnectionId 47D6D241 D66611D9 84440007 85111F61, SetupTime 08:37:56.545 UTC Tue Jun 7 2005, PeerAddress 2305206, PeerSubAddress , DisconnectCause 7F , DisconnectText interworking (127), ConnectTime 08:37:56.635 UTC Tue Jun 7 2005, DisconnectTime 08:38:02.745 UTC Tue Jun 7 2005, CallOrigin 1, ChargedUnits 0, InfoType 2, TransmitPackets 302, TransmitBytes 6040, ReceivePackets 304, ReceiveBytes 6080

20050607 084148 10.1.1.8 - <189>2430: Jun 7 08:41:22.578: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 1, ConnectionId BB5D0FD9 D66611D9 A3760050 7367FC01, SetupTime 08:41:10.268 UTC Tue Jun 7 2005, PeerAddress , PeerSubAddress , DisconnectCause 7F , DisconnectText interworking (127), ConnectTime 08:41:10.478 UTC Tue Jun 7 2005, DisconnectTime 08:41:22.558 UTC Tue Jun 7 2005, CallOrigin 2, ChargedUnits 0, InfoType 2, TransmitPackets 604, TransmitBytes 12080, ReceivePackets 603, ReceiveBytes 12060

20050607 084149 10.1.1.8 - <189>2431: Jun 7 08:41:22.598: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 2, ConnectionId BB5D0FD9 D66611D9 A3760050 7367FC01, SetupTime 08:41:10.278 UTC Tue Jun 7 2005, PeerAddress 2305229, PeerSubAddress , DisconnectCause 7F , DisconnectText interworking (127), ConnectTime 08:41:10.478 UTC Tue Jun 7 2005, DisconnectTime 08:41:22.598 UTC Tue Jun 7 2005, CallOrigin 1, ChargedUnits 0, InfoType 2, TransmitPackets 603, TransmitBytes 12060, ReceivePackets 606, ReceiveBytes 12120

What could be the reason for this?

The IP network between gateways is Ethernet LAN, whit no apparent problems.

Could the disconnect come from some remote network perhaps?

(all calls are external inbound calls that are being routed to our call centre)

Thank for your help again.

Regards

Ivan

[teodorgeorgiev · Accepted solution]

Dear Ivan,

those ye who ask for help, should value it first.

Till you learn the forum rules - farewell.

[ivan.marakovic]

Dear Teodor,

I do value your help very much. I should have reted your input before jumping to a different topic.

I am terribly sorry for that.

Best Regards

Ivan

[teodorgeorgiev]

Hi Ivan,

I am not really deep into the Cisco's "Find the right IOS" game, but as far as I know, 3640 can play an IP-IP gateway.

H323-to-H323 VoIP connections are enabled by default into the IP-IP gateway, so it looks like your IOS is not IP-IP. But to double-check, do the following:

conf t

voice service voip

allow connections

if you have the last command, it means your IOS is IP-IP.

Let me note just an opinion of mine.

1. Your routing scheme is a kind of wrong. It works now like this:

the originating voice gateway sends a call to gateway GWX-1 at location X. This is via IP.

The GWX-1 tries to route the call via PSTN. If it can, it will try to route the call (via IP) to GWX-2 (the second gateway in that location). Here is where you get an IP-IP call leg.

You could avoid it by doing the following:

the originating voice gateway sends a call to gateway GWX-1 at location X. If the call fails, then ***the originating gateway*** will try to send the call to GWX-2 (the second gateway of location X).

The best is to use some kind of gatekeeper/softswitch as a centralised routing manager. If you keep on Cisco, do not use their so-called "Gatekeeper", but configure some router as an IP-IP gateway. All the calls should go through it and it will decide where and how to route them.

[ivan.marakovic]

Hi Teodor,

I was out of action for a few days.

Thank you for a reply.

The command is supported so my IOS supports the IP-IP, (IOS 12.3.11T IP PLUS) but I have removed VOIP dial pears in question now. The conf was incorect, as you said. It was not causeing any calls to fail but it was incorect. The IEC error is not happening that often anymore.

At this stage we do not have any gatekeepers.

We have only 10 VOIP gateways on our network and we still manage routing on each of them. At some stage we wil have to look at the gatekeeper or IP-IP gateway.

Thank you very much Teodor.

Regards

Ivan

[teodorgeorgiev]

As for the second issue, nothing I can tell before a debug. Looks like some traffic is transmitted, so the calls were placed and "spoken" :)

Why don't you monitor your CPU usage ?

[ivan.marakovic]

Hi Teodor,

Some calls are still getting disconnected with the code 7F.

This is what I found on the WEB:

127

7F

Interworking, Unspecified.

Indicates that there has been interworking with a network which does not provide causes for actions it takes. Thus, the precise cause for a message which is being sent cannot be ascertained.

Perhaps the call gets disconnected by a remote network which does not send me a cause for a disconnection?? What do you think?

I am not getting any IEC errors with the disconnection, so I think it is probably not the VOIP.

CPU usage does not seam to be the problem. It ranges between 20 and 30%.

They get placed and spoken and then at some point I get the following ISDN q931 debug:

Bearer Capability i = 0x9090A3

Standard = CCITT

Transer Capability = 3.1kHz Audio

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98386

Exclusive, Channel 6

Called Party Number i = 0xA1, '5204'

Plan:ISDN, Type:National

User-User i = 0x04, '0414851254'

4w5d: ISDN Se1/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0xAB9B

Channel ID i = 0xA98386

Exclusive, Channel 6

4w5d: ISDN Se1/0:15 Q931: RX <- ALERTING pd = 8 callref = 0xAB9B

4w5d: ISDN Se1/0:15 Q931: RX <- CONNECT pd = 8 callref = 0xAB9B

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

Locking Shift to Codeset 6

Codeset 6 IE 0x28 i = 'Genesys'

4w5d: ISDN Se1/0:15 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x2B9B

4w5d: ISDN Se1/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x2C93

Cause i = 0x81FF - Interworking error; unspecified

4w5d: ISDN Se1/0:15 Q931: TX -> RELEASE pd = 8 callref = 0xAC93

It looks like to me that a disconnect comes from the PABX (RX <- DISCONNECT).

What do you think is happening?

The thing is that we get quite a number of these disconnect but no complaints from customers nor call centre agents about calls being cut off.

Would it be possible that these calls are ending "normaly" from user's perspective, but I get the 7F from the remote network??

VIOP accounting:

Jun 8 09:51:56.925: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 1, ConnectionId B23CB8DF D73911D9 A7600050 7330EC41, SetupTime 09:51:

18.775 UTC Wed Jun 8 2005, PeerAddress , PeerSubAddress , DisconnectCause 7F , DisconnectText interworking (127), ConnectTime 09:51

:18.995 UTC Wed Jun 8 2005, DisconnectTime 09:51:56.915 UTC Wed Jun 8 2005, CallOrigin 2, ChargedUnits 0, InfoType 2, TransmitPacket

s 1900, TransmitBytes 38000, ReceivePackets 1899, ReceiveBytes 37980

4w5d: ISDN Se1/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x2C93

Jun 8 09:51:56.953: %VOIPAAA-5-VOIP_CALL_HISTORY: CallLegType 2, ConnectionId B23CB8DF D73911D9 A7600050 7330EC41, SetupTime 09:51:

18.783 UTC Wed Jun 8 2005, PeerAddress 1305125, PeerSubAddress , DisconnectCause 7F , DisconnectText interworking (127), ConnectTim

e 09:51:18.983 UTC Wed Jun 8 2005, DisconnectTime 09:51:56.943 UTC Wed Jun 8 2005, CallOrigin 1, ChargedUnits 0, InfoType 2, Transmi

tPackets 1897, TransmitBytes 37940, ReceivePackets 1901, ReceiveBytes 38020

4w5d: ISDN Se1/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x2 0x1, Called num 5209

4w5d: ISDN Se1/0:15 Q931: TX -> SETUP pd = 8 callref = 0x2B9C

Thanks Teodor

Regards

Ivan

[teodorgeorgiev]

Definitely the PBX is sending the disconnect. The issue is - WHY. The disconnect reason says nothing.

What kind the PBX is?

Are you using ISDN ETSI or QSIG ?

What i see is how Cisco sends "CONNECT ACK" to the PBX, which imho is not needed and unusual. Maybe that is the reason why the the PBX disconnects the call.

[ivan.marakovic]

Hi Teodor,

Thanks for the reply.

We use ISDN ETSI

the conf is below:

controller E1 1/0

pri-group timeslots 1-31

interface Serial1/0:15

no ip address

no logging event link-status

isdn switch-type primary-net5

isdn protocol-emulate network

isdn incoming-voice voice

isdn T310 12000

no cdp enable

voice-port 1/0:15

input gain 3

cptone AU

timeouts interdigit 4

The PABX is Avaya (interface used is DS1)

This is what normally happens between cisco and avaya: (isdn q931 debug)

They are both sending connect_ack to each other and this is not causing a 7F.

What other debug would be usefull here?

Sending Complete

Bearer Capability i = 0x9090A3

Standard = CCITT

Transer Capability = 3.1kHz Audio

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA1839E

Preferred, Channel 30

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

Called Party Number i = 0xA1, '7305722'

Plan:ISDN, Type:National

User-User i = 0x04, '0096253205'

Locking Shift to Codeset 6

Codeset 6 IE 0x7B i = 0x828ABAAE, 'DNIS Insertion'

Jun 16 10:58:14: ISDN Se3/0:15 Q931: RX <- CONNECT pd = 8 callref = 0x94F0

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

Locking Shift to Codeset 6

Codeset 6 IE 0x28 i = 'Genesys'

Jun 16 10:58:14: ISDN Se3/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0xC34C

Channel ID i = 0xA9839E

Exclusive, Channel 30

Jun 16 10:58:14: ISDN Se3/0:15 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x14F0

Jun 16 10:58:15: ISDN Se3/0:15 Q931: TX -> ALERTING pd = 8 callref = 0xC34C

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

Jun 16 10:58:15: ISDN Se3/0:15 Q931: TX -> CONNECT pd = 8 callref = 0xC34C

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

Display i = 'Genesys'

Jun 16 10:58:15: ISDN Se3/0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x434C

Jun 16 10:58:22: ISDN Se3/0:15 Q931: RX <- SETUP pd = 8 callref = 0x4641

Sending Complete

Bearer Capability i = 0x8090A3

Standard = CCITT

Transer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA1839F

Preferred, Channel 31

Called Party Number i = 0xA1, '6305622'

Plan:ISDN, Type:National

User-User i = 0x04, '0096250666'

Locking Shift to Codeset 6

Codeset 6 IE 0x7B i = 0x828ABAB8, 'DNIS Insertion'

Jun 16 10:58:22: ISDN Se3/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0xC641

Channel ID i = 0xA9839F

Exclusive, Channel 31

Jun 16 10:58:22: ISDN Se3/0:15 Q931: TX -> ALERTING pd = 8 callref = 0xC641

Jun 16 10:58:23: ISDN Se3/0:15 Q931: TX -> CONNECT pd = 8 callref = 0xC641

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

Locking Shift to Codeset 6

Codeset 6 IE 0x28 i = 'Genesys'

Jun 16 10:58:23: ISDN Se3/0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x4641

Jun 16 10:58:23: ISDN Se3/0:15 Q931: RX <- SETUP pd = 8 callref = 0x47BE

Sending Complete

Bearer Capability i = 0x9090A3

Standard = CCITT

Transer Capability = 3.1kHz Audio

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA18383

Preferred, Channel 3

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

Thanks a lot Teodor.

Regards

Ivan

[teodorgeorgiev]

Well, in my opinion the right thing to do is to run a debug at the Avaya. There you will see the exact reason for dropping the call.

I have no experience with Avaya (I have with Lucent Definity, but it is quite different) and can't give you any hints :(