RECOVERY_ON_TIMER_EXPIRE On some calls
- Thread starter MTR
- Start date
- Status
this Network has 2 Polycom IP 550 phoness and a very old RV042 linksys router, this router is like 10 years old
that location was connected until now to asterisk and it was working fine as soon as we moved to FS we had 2 issues
1. RECOVERY_ON_TIMER_EXPIRE
2. and incoming calls didn't work sometimes,
the 2nd issues point it to NAT so i went into the POLYCOM phones and set up the keepalive to 15 seconds that seemed to resolve both of the above issues
so @DigitalDaz you are correct this was a NAT issue
just one thing that i cant understand why will we have issues on active call, isn't a active call the same as keep alive??
however now its working will wait another few days
that location was connected until now to asterisk and it was working fine as soon as we moved to FS we had 2 issues
1. RECOVERY_ON_TIMER_EXPIRE
2. and incoming calls didn't work sometimes,
the 2nd issues point it to NAT so i went into the POLYCOM phones and set up the keepalive to 15 seconds that seemed to resolve both of the above issues
so @DigitalDaz you are correct this was a NAT issue
just one thing that i cant understand why will we have issues on active call, isn't a active call the same as keep alive??
however now its working will wait another few days
@MTR The problem with it on active calls would indicate that its definitely a NAT issue but also that session timers are enabled, some carriers set this, you will see it in the invite or 200OK, Session Expires, I think the header is.
Remember, once the session is established, only UDP RTP is flowing and there is no activity on the SIP channels.
The router is probably closing down the SIP NAT tunnel. An easy fix is usually to drop the registration time down to about 120, that's usually good as the phones will typically register at half the time like with DHCP so this works around at about a minute. That will refresh the NAT tunnel and should allow the inbound RE-INVITE through.
A very quick way to check your reg timers are too high is to take a quick print screen of the sip registrations page, this only works with PAT...
Give it a few minutes until the phones have reregistered the go and take a look again at the registrations page. Compare the port numbers.
If you see the port numbers are different this would indicate exactly what has been described and the new register has been established on a different port.
What you want to do is bring down the reg timers until the port remains the same and then you have cracked it.
Remember, once the session is established, only UDP RTP is flowing and there is no activity on the SIP channels.
The router is probably closing down the SIP NAT tunnel. An easy fix is usually to drop the registration time down to about 120, that's usually good as the phones will typically register at half the time like with DHCP so this works around at about a minute. That will refresh the NAT tunnel and should allow the inbound RE-INVITE through.
A very quick way to check your reg timers are too high is to take a quick print screen of the sip registrations page, this only works with PAT...
Give it a few minutes until the phones have reregistered the go and take a look again at the registrations page. Compare the port numbers.
If you see the port numbers are different this would indicate exactly what has been described and the new register has been established on a different port.
What you want to do is bring down the reg timers until the port remains the same and then you have cracked it.
It is what keepalives are for but depending upon the endpoint these keepalives can be one way traffic. In some cases the ports can still become closed. A register, though definitely more 'expensive' will definitely cause a two way traffic flow and makes it almost certain that you will have no problems.
The best way, I believe is using a INFO or OPTIONS packet for keepalive. The INFO is the least expensive.
The reason I stick with the low reg times instead is that I have multiserver capability so I want low reg times in case of failover,
The best way, I believe is using a INFO or OPTIONS packet for keepalive. The INFO is the least expensive.
The reason I stick with the low reg times instead is that I have multiserver capability so I want low reg times in case of failover,
- Status