cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1993
Views
0
Helpful
10
Replies

Call forward drop after first ring.

ayalawalter
Level 1
Level 1

Hi, When I call from PSTN to an phone that is forwarded to other, call is droped.

I can see in traces the following message:

Jun 9 13:28:33.407: ISDN Se1/0:15 Q931: RX <- STATUS pd = 8 callref = 0x18A1

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

Call State i = 0x03

Jun 9 13:28:33.411: ISDN Se1/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x98A1

Cause i = 0x80E2 - Message not compatible with call state or not implemented

Somebody can tell me what's wrong.

Regards

10 Replies 10

Michael Owuor
Cisco Employee
Cisco Employee

Hi Walter,

The first line in the debug output that you posted is one where the router is receiving a STATUS isdn Q.931 message from the PSTN indicating that the message that the router just sent to the PSTN was not the expected one. So the interesting lines would be the ones just before the one you posted. Do you mind posting the debugs starting from the SETUP and ending with the DISCONNECT?

Also t oconfirm, is the call being forwarded to another internal IP Phone?

Thanks,

Michael.

Thanks Michael.

Here you have the complete trace.

The call path is the following:

PSTN--->8028 and this is forwarded to 8000

Jun 9 13:28:33.319: ISDN Se1/0:15 Q931: RX <- SETUP pd = 8 callref = 0x18A1

Bearer Capability i = 0x8090A3

Standard = CCITT

Transer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA18398

Preferred, Channel 24

Progress Ind i = 0x8103 - Reserved value

Calling Party Number i = 0x0181, '913125316'

Plan:ISDN, Type:Unknown

Called Party Number i = 0xC9, '8028'

Plan:Private, Type:Subscriber(local)

Locking Shift to Codeset 5

Codeset 5 IE 0x31 i = 0x81

Codeset 5 IE 0x32 i = 0x80

Jun 9 13:28:33.335: ISDN Se1/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x98A1

Channel ID i = 0xA98398

Exclusive, Channel 24

Jun 9 13:28:33.335: ISDN Se1/0:15 Q931: TX -> FACILITY pd = 8 callref = 0x98A1

Facility i = 0x9FAA068001008201008B0100A118020101060528EC310014300C0A01010A0102800438303138

Jun 9 13:28:33.335: ISDN Se1/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x98A1

Facility i = 0x9FAA06800100820100A12A020101060528EC2C0001801E5365632E205669632E2052656C6163696F6E657320496E7465726E616369

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

Jun 9 13:28:33.407: ISDN Se1/0:15 Q931: RX <- STATUS pd = 8 callref = 0x18A1

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

Call State i = 0x03

Jun 9 13:28:33.411: ISDN Se1/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x98A1

Cause i = 0x80E2 - Message not compatible with call state or not implemented

paolo bevilacqua
Hall of Fame
Hall of Fame

Please specify which exact IOS are you running, as this seems to be CSCsi94745.

Please send the complete q931 trace to indefiy a possible workaround if you cannot upgrade IOS yet (recommended).

Team,

After reviewing the complete debug, I suspect we are running into CSCdy26520 (Progress Indicator isn't a valid IE in ALERTING per DSM-100 spec.)

Q.931 sequence of events in the failed call:

RX - SETUP

TX - CALL_PROC

TX - FACILITY

TX - ALERTING (Contains Facility IE and Progress Indicator)

RX - STATUS (Telco complaining about receiving a progress ind)

TX - DISCONNECT (CCM dropping the call because it didn't expect to receive the STATUS message above)

Potential workaround, configure CCM to not send the PI.

Change the CCM Service Parameter 'Disable Alerting Progress Indicator' to TRUE.

Disable Alerting Progress Indicator : This parameter determines whether the alerting progress indicator to Inband Information is reported to digital PRI gateways. Valid values specify True (disable the alerting progress indicator) or False (send the alerting progress indicator). To receive ring back in certain configurations, you may have to set this field to False to force media cut-through. This is a required field.

Default: false.

Hope this helps.

Regards,

Michael.

Another workaround at GW-level would be:

no isdn outgoing ie progress-indicator

CSCdy26520 is a fix for CM and specially applies to MGCP. The bug I've mentioned before is the proper IOS GW fix.

Michael, I changed this parameter to TRUE.

I restarted CCM service and nothing. I still have the problem.

Do you think that I need to restat completely the server?

Hi Walter,

You shouldn't need to restart the server.

Is the gateway MGCP or H.323 controlled? If you have an MGCP gateway, a reset of the MGCP process may be required for it to pick up the configuration change.

The issue is documented in the following two documents.

* http://supportwiki.cisco.com/ViewWiki/index.php/Incoming_PRI_calls_are_disconnected_after_a_two_to_three_second_connection_by_Cisco_CallManager._debug_isdn_q931_shows_the_Message_not_compatible_with_call_state_error_message_as_the_disconnect_reason

* http://www.ciscotaccc.com/kaidara-advisor/voice/showcase?case=K68327890

Try the gateway-level workaround that Paolo suggested. On the d-channel interface in the router, add the command 'no isdn outgoing ie progress-indicator'.

Another workaround that has worked for some is to change the switch-type both in CCM and on the gateway from DMS100 to Primary-n1 (The NI-2 specification does not send the NOTIFY message)

Hope this helps.

Michael.

I just reset mgcp on both gateways and nothing.

Regarding to change switch-type, we are using pri-euro.

About Paolo says, I have not this command in the gateway.

I'm thinking in a IOS upgrade to another more stable, like 12.3.14T.

I'm using an c3725-IS-MZ.123.1a

Hi all,

I had exactly the same problem on an H.323 PRI gateway to an Alcatel PBX and it was solved by the "no isdn outgoing ie progress-indicator" command on the serial interface of the E1 as was recommended in the post.

Thanks a lot, guys!

Cheers,

Markus

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: