Call Disconnects with Cause i = 0x82E6 - Recovery on timer expiry

Unanswered Question
Feb 19th, 2008

Hi,

I have a cisco as5300. I am having issues with the above quoted error only when the call is picked up, which then immediately disconnects giving the listed error.

show call history vo br

AEA : 176923920ms.90072 +60 +19560 pid:101 Answer 254712202461

dur 00:00:19 tx:966/19320 rx:0/0 66 (recovery on timer expiry (102))

IP xxx.xxx.xxx.xxx:18968 rtt:0ms pl:0/0ms lost:0/0/0 delay:70/260/10ms g729r8

The following dial peers handle the calls

dial-peer voice 101 voip

description voip calls to CTIServer

incoming called-number .T

voice-class codec 1

dial-peer voice 99 pots

description calls from provider

destination-pattern 00400

no digit-strip

port 1:D

I have attached the sample logs of the same.

Thanks in advance for any helpful insight

Attachment: 
I have this problem too.
1 vote
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
teodorgeorgiev Thu, 02/21/2008 - 06:46

Read more about the ISDN (Q.931) timers.

After sending to you the CALL PROCEEDING or CONNECT message, the other side waits for some event from your side for a configured timeout and after this timeout expires, the call is dropped.

Do both sides hear each other in such a situation?

davidmuriuki Fri, 02/22/2008 - 01:46

I had read on the Q.931 timers, but whats puzzling is that since the calls are managed by an IVR, the calls are queued and are only transferred to an attendant when one is available. In this scenario, the calls are only disconnected if the caller decides to drop off. Otherwise they are queued till an attendant is available.

If the timer was set from the provider's server, then i would see calls dropping off from the queue after roughly;the same duration.

In my case, the call immediately drops when the attendant immediately picks up. Thus no conversation can commence.

canowlin Sat, 02/23/2008 - 15:00

usually when a call disconnects after one ring you would look at the codecs...it looks like g729 is being used? did you try forcing g711 to see if issue goes away?

davidmuriuki Mon, 02/25/2008 - 06:49

I totally agree, most times its a codec issue. Problem is the calls' provider was very stubborn and did not aid in the troubleshooting. Fortunately I had asked him to re-route these calls to our IP-Pbx which still did not work.

On escalating this to the IP-Pbx vendor,they indicated that the sip headers being sent from the provider's cisco were incorrect and thats why it couldnt work.

Long story short,I requsted the provider to re-send the call traffic to my Cisco AS5300 and he seems to have done something different in his configs.

I am now able to recieve the calls and converse as should be. Problem is, technically, this post is still unresolved. The provider has not owned up to what he did right this time round.

Thanks for all the technicians who provided some insight.

Actions

This Discussion