Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

recovery on timer expiry for R2

Hi

Can anyone tell me how to increase the value of the timer for R2 connection that my calls wouldn't get dropped after 6 seconds of inactivity.

Thanks in Advance.

4 REPLIES
Hall of Fame Super Gold

Re: recovery on timer expiry for R2

Does the call connects then drops after 6 secs ?

Or which kind of inactivity are your referring to?

It is happening for incoming or outgoing calls ?

It is possible that something is not correct with the E1 R2 "handshake" as applicable to your country/telco, hence the call drop.

New Member

Re: recovery on timer expiry for R2

The log in gatekeeper shows a duration of 6 seconds but a call doesn't get established. This doesn't happen to all calls only to some of them and each of those unsucessful calls show 6 sec duration and 102 disconnect cause code.

This is happening for incoming calls

Here's the config in my Cisco 3640

controller E1 0/0

framing NO-CRC4

ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled

cas-custom 0

alert-wait-time 20

the last line alert-wait-time was added not long ago but it doesn't help either.

I think I need some solution like this http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a0080094487.shtml which advices to increase the value of timer T310 but in my case when I connect via R2 it seems that there's no option to increase the timer value.

Thanks in Advance

Hall of Fame Super Gold

Re: recovery on timer expiry for R2

Hi,

you would need a trace of "debug vtsp signal" to understand why the call fails on the R2 side.

Notably your config does not specify a custom contry/telco, so it's possible that in its genericness does not meet in some case what the switch expects.

New Member

Re: recovery on timer expiry for R2

I fixed this issue with a simple reboot of the customer's voice gateway (MGCP).

378
Views
0
Helpful
4
Replies
CreatePlease login to create content