Error from ISDN: "Message not compatible with call state"

[6rlopez_2]

I have E1 connected to MGCP gateway. When I send calls through this E1 I receive:

Oct 14 20:33:40.933: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0xA10A

Cause i = 0x82E57D - Message not compatible with call state

[gogasca]

Hi,

Could you please paste the complete debug.

BTW which platform you are using?

Thanks

[6rlopez_2]

I have the same situation with 2811 and 3825.

The debug:

Oct 14 20:33:32.700: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x210A

Bearer Capability i = 0x8090A3

Standard = CCITT

Transer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9839E

Exclusive, Channel 30

Display i = 'Javier Lopez'

Calling Party Number i = 0x0081, '946719637'

Plan:Unknown, Type:Unknown

Called Party Number i = 0x80, '0017192347502'

Plan:Unknown, Type:Unknown

Oct 14 20:33:32.760: ISDN Se0/0/0:15 Q931: RX <- SETUP_ACK pd = 8 callref = 0xA10A

Channel ID i = 0xA9839E

Exclusive, Channel 30

Oct 14 20:33:38.025: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0xA10A

Oct 14 20:33:40.857: ISDN Se0/0/0:15 Q931: RX <- PROGRESS pd = 8 callref = 0xA10A

Cause i = 0x829F - Normal, unspecified

Oct 14 20:33:40.861: ISDN Se0/0/0:15 Q931: TX -> STATUS pd = 8 callref = 0x210A

Cause i = 0x80E0 - Mandatory information element missing

Call State i = 0x03

Oct 14 20:33:40.933: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0xA10A

Cause i = 0x82E57D - Message not compatible with call state

Display i = ' 0 PASOS'

Locking Shift to Codeset 5

Codeset 5 IE 0x1A i = 0xC400

Thanks!

[teodorgeorgiev]

Which ISDN protocol are you using?

As you may see, Cisco complains of a mandatory information element missing in an Q.931 message.

I think it is about the "PROGRESS" message, as it does not contain a "Progress Indicator". And the PI element is mandatory for the the "PROGRESS" message, according to the Q.931 specifications.

[6rlopez_2]

We have ISDN PRI EURO. It does not fail with all the numbers, it just fails with one international number. If we try this call through an H323 gateway there is no problem.

[msolak]

seems to be a timer problem.

check your t302 and t310 timers.

greetings

mehmet

[teodorgeorgiev]

The "incompatible with call state" error message is due to Cisco (in my opinion).

The issue is that Cisco sends a "STATUS" message, which is wrong. The Cisco should send a "STATUS ENQUIRY" message and then the other side shall reply with "STATUS". That is why the other side sends a RLC with "incompatible with call state" message - a "STATUS ENQUIRY" message must appear before "STATUS".

Also, check your timers (as the other guy suggested). The interval between "SETUP" and "CALL PROCEEDING" is 6 seconds. Maybe that is the issue.

But I think it is in the equipment at the other side, which does not send a PI inside the "PROGRESS" message.

[runariversen]

Hi,

this is just a thought...

you mention that it is working with a h323 gw, towards the same int number ?

could this have something to do with " numbering type" ?

Calling Party Number i = 0x0081, '946719637'

Plan:Unknown, Type:Unknown

Called Party Number i = 0x80, '0017192347502'

Plan:Unknown, Type:Unknown

might be something with with your pstn, that the international number is a other numbering type and there is a mismatch ?

br

Runar

[6rlopez_2]

Thanks for the suggestion, but with H323 we are using the same plan and type wothout problem

[level3tech]

I had the same issue. I wasn't using h.323, but inbound isdn calls would die with the same debug error you are receiving. The telco was using a dms-100, but the router would NOT complete a call with that switchtype. I played around with it and found that ni2c switchtype eliminated any errors i was getting.

I would recommmend trying various switchtypes, as i found that the switchtype doesn't necessarilly have to match what is on the other end. Just change it around and give it a shot, let us know what happens.

Thanks!

[john.heyer]

I ran in to a similar problem with a Brooktrout TR1034 PRI fax board being used by Captaris RightFax. The switch type matched on both ends, but it also had an option for "Protocol Variant" which I had never heard of.

After setting this to AT&T Pub 41449 as they suggested, the "Message not compatible with call state" warning went away, and also seemed to make

our faxes more reliable.

http://www.brooktrout.com/support/download/ECC_175Manual.pdf

[m0hammadatifbutt]

Face the same issue where outbound calls were not working, fixed the issue by changing isdn switch-type from primary-ni to primary-net5.

Check with SP what is supported and configure the same on your side.