06-09-2008 06:47 AM - edited 03-15-2019 11:09 AM
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
06-09-2008 06:55 AM
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.
06-09-2008 07:00 AM
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
06-09-2008 07:02 AM
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).
06-09-2008 07:29 AM
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.
06-09-2008 07:35 AM
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.
06-10-2008 08:00 AM
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?
06-10-2008 08:28 AM
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://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.
06-10-2008 09:08 AM
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.
06-10-2008 07:57 AM
I'm using an c3725-IS-MZ.123.1a
06-12-2008 05:04 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide