ISDN: Recovery on timer expiry

Unanswered Question
Jun 3rd, 2008

Hi,

We have a remote site using H323 on a 1861. The IOS is 12.4(15)XY2. We have the following problem, when we receive a call from a cell network we get the Recovery on Timer Expiry error message. This has only started to happen since we told our Telco to enable Caller ID on the BRI.

Failed Call:

000351: Jun 4 01:24:36.291: ISDN BR0/1/0 Q931: RX <- SETUP pd = 8 callref = 0x18

Sending Complete

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0x89

Exclusive, B1

Date/Time i = 0x0806040D18

Date (yr-mm-dd) = 08-06-04

Time (hr:mnt:sec) = 13:24:52

Signal i = 0x40 - Alerting on - pattern 0

Calling Party Number i = 0x2183, '212484869'

Plan:ISDN, Type:National

Called Party Number i = 0xC1, '4070760'

Plan:ISDN, Type:Subscriber(local)

High Layer Compat i = 0x9181

000352: Jun 4 01:24:36.303: ISDN BR0/1/0 Q931: TX -> CALL_PROC pd = 8 callref = 0x98

Channel ID i = 0x89

Exclusive, B1

000353: Jun 4 01:24:46.655: ISDN BR0/1/0 Q931: RX <- RELEASE pd = 8 callref = 0x18

Cause i = 0x82E6333130 - Recovery on timer expiry

000354: Jun 4 01:24:46.659: ISDN BR0/1/0 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x98

Good Call:

000355: Jun 4 01:25:17.700: ISDN BR0/1/0 Q931: RX <- SETUP pd = 8 callref = 0x19

Sending Complete

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0x89

Exclusive, B1

Date/Time i = 0x0806040D19

Date (yr-mm-dd) = 08-06-04

Time (hr:mnt:sec) = 13:25:52

Signal i = 0x40 - Alerting on - pattern 0

Calling Party Number i = 0x2181, '93631830'

Plan:ISDN, Type:National

Called Party Number i = 0xC1, '4070760'

Plan:ISDN, Type:Subscriber(local)

000356: Jun 4 01:25:17.712: ISDN BR0/1/0 Q931: TX -> CALL_PROC pd = 8 callref = 0x99

Channel ID i = 0x89

Exclusive, B1

000357: Jun 4 01:25:17.792: ISDN BR0/1/0 Q931: TX -> ALERTING pd = 8 callref = 0x99

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

000358: Jun 4 01:25:18.576: ISDN BR0/1/0 Q931: TX -> CONNECT pd = 8 callref = 0x99

Channel ID i = 0x89

Exclusive, B1

000359: Jun 4 01:25:18.664: ISDN BR0/1/0 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x19

000360: Jun 4 01:25:21.136: ISDN BR0/1/0 Q931: RX <- DISCONNECT pd = 8 callref = 0x19

Cause i = 0x8090 - Normal call clearing

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

000361: Jun 4 01:25:21.152: ISDN BR0/1/0 Q931: TX -> RELEASE pd = 8 callref = 0x99

000362: Jun 4 01:25:21.428: ISDN BR0/1/0 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x19

Can anyone explain what could be happening?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
bwilmoth Mon, 06/09/2008 - 07:55

This situation can be resolved by increasing the value of timer T310. This can be done on the Cisco IOS gateway.

IOS configuration is achieved through the following interface command

Router(config-if)#isdn t310

webstd.design Tue, 09/16/2008 - 23:16

By default what is this value? And what is the best practice for this value? Should I increse\decrease it?

Paolo Bevilacqua Mon, 06/09/2008 - 08:02

This happens when the outgoing voip leg gets no response. See 10 seconda have passed without further acknowledgment after CALL_PROC, so rightly the nextowkr disconnects.

Check you DP config, why is the first call treated differently than the second? Apparently, only the calling number is different.

appserv Mon, 06/09/2008 - 12:03

Thanks for the responses.

This is a copy of how my dial peers are setup. This config has worked for us in the past using 2801 routers.

dial-peer voice 1 pots

tone ringback alert-no-PI

preference 1

destination-pattern 1T

progress_ind alert enable 8

direct-inward-dial

port 0/1/0

!

dial-peer voice 100 voip

tone ringback alert-no-PI

preference 1

destination-pattern 5510.

progress_ind setup enable 0

voice-class codec 10

voice-class h323 1

session target ipv4:172.29.2.97

incoming called-number 1T

dtmf-relay h245-alphanumeric

no vad

!

dial-peer voice 101 voip

tone ringback alert-no-PI

preference 2

destination-pattern 5510.

progress_ind setup enable 0

voice-class codec 10

voice-class h323 1

session target ipv4:172.29.2.96

incoming called-number 1T

dtmf-relay h245-alphanumeric

no vad

Paolo Bevilacqua Mon, 06/09/2008 - 13:38

Hi, are you doing some translation somewhere ? Because the called number from you trace does not match "destination-pattern" in the voip DP.

You can also enable "debug cch323" and see what happens, if anything, with the voip call when it fails.

appserv Mon, 06/09/2008 - 14:35

Hi Paolo,

Yes we are doing translations - I cannot test right now as I needed to get the site working ASAP and have told the telco to remove caller id. Waiting on a spare 1861 to be delivered.

thanks.

Paolo Bevilacqua Mon, 06/09/2008 - 14:37

Hi,

Replacing hardware will not change anything.

You have either a subtle configuration issue, or a bug in the new XY IOS.

appserv Mon, 06/09/2008 - 15:51

Aware of that- new hardware is to setup a test lab to troubleshoot this further.

Any other thoughts much appreciated.

pijssel@digacom.nl Thu, 07/03/2008 - 07:03

Hi guys,

Currently I'm having the same issue. As a customer is calling from an Amsterdam site over an ISDN PRI line to a destination in London. Sometimes the call gets connected, and sometimes the get the "Cause i = 0x82E6 - Recovery on timer expiry" error.

I guess this has something to do with the called party being busy, and the busy signal not being forwarded correctly to the Voice Gateway in Amsterdam. I allready tried adjusting the T310 timer, but without any result.

Is there an other way to force this signal, maybe by setting a Progress Indicator?

Thanks in advance.

Paul van den IJssel

Digacom

The Netherlands

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

debug isdn q931 output:

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

Jul 3 15:39:54: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x5590

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9838E

Exclusive, Channel 14

Calling Party Number i = 0x00A1, '301'

Plan:Unknown, Type:Unknown

Called Party Number i = 0x80, '004420796XXXXX'

Plan:Unknown, Type:Unknown

Jul 3 15:39:54: ISDN Se0/0/0:15 Q931: RX <- STATUS pd = 8 callref = 0xD590

Cause i = 0x82E46C - Invalid information element contents

Call State i = 0x01

Jul 3 15:39:54: ISDN Se0/0/0:15 Q931: RX <- SETUP_ACK pd = 8 callref = 0xD590

Channel ID i = 0xA9838E

Exclusive, Channel 14

Jul 3 15:40:01: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0xD590

Jul 3 15:40:19: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0xD590

Cause i = 0x82E6 - Recovery on timer expiry

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

Jul 3 15:40:19: ISDN Se0/0/0:15 Q931: call_disc: PI received in disconnect; Pos

tpone sending RELEASE for callid 0xD511

Jul 3 15:40:22: ISDN Se0/0/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x5590

Jul 3 15:40:22: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0xD5

90

Paolo Bevilacqua Thu, 07/03/2008 - 07:12

Hi, I would begin eliminating the first error and going from there:

Jul 3 15:39:54: ISDN Se0/0/0:15 Q931: RX <- STATUS pd = 8 callref = 0xD590

Cause i = 0x82E46C - Invalid information element contents

Which switch-type is configured? Have you configured a channel selection "exclusive" ? Can you sent the correct main number or nothing at all, as calling ?

For some reason the CO is complaining.

pijssel@digacom.nl Fri, 07/04/2008 - 00:26

Hi,

The switch type is Primary net 5, you can also look this up in the config which I attached. I'm not quite sure what you mean with the channel selection "exclusive".

I am unable to send the correct main number, that is why I've set the CLID to restricted on the CM.

Do you have any suggestions?

Thanks in advance.

Best regards,

Paul van den IJssel

Paolo Bevilacqua Fri, 07/04/2008 - 01:21

Hi, the first STATUS message "may" still be related to the calling number, however is not the cause of the problem.

I think that there is nothing that you can do. Telco sends CALL_PROC, after that telco sends disconnect. The timer expirya is occurring on the called party, not your. Try asking them if they have a cisco with configuration problem :)

Actions

This Discussion