Notes

   Upon installing a few Aastra 6731i phones and a 6755i onto a system that was previously proliferated with Polycom phones of various models, I was pleasantly surprised with the ease of writing provisioning code for the Aastra's and went to town with the roll-out. We discovered, however, that the 6731i's tended to drop calls after approximately 45 minutes and the 6755i, slightly longer. Asterisk somehow didn't see the calls drop and a ghost channel was left "up" in Asterisk until we manually issued a 'channel request hangup'.

Investigation

   To get to the bottom of this issue, we connected a 10/100 hub to a laptop, the phone and the network backbone. We then ran tcpdump to save the SIP traffic to a cap file and dialed into a conference with MOH. After about 50 minutes the phone call disappeared from the Aastra phone, but the leg still existed on Asterisk:

   Upon examining the cap file, we noticed that at exactly 3600 seconds into the capture, we saw:

* -> Aastra   SIP/SDP  Request: INVITE sip:device18_1 @ 192.168.1.103:5060;transport=udp SIP/2.0
Aastra -> *   SIP      Status: SIP/2.0 481 Call Leg/Transaction Does Not Exist

   While performing this test again, we watched closer and stopped the packet capture as soon as the call dropped. When we did this, we did not see the "481 Call Leg/Transaction Does Not Exist" message. This appears to be a timed event when Asterisk checks again to be sure the device is still active, and the Aastra responds with that message. There were no messages in the CLI about the call termination, and the CDR records showed the call was up until I manually terminated the call with "channel request hangup". We still we unsure why the call was dropping, but we knew it was some sort of timeout, apparently on the Aastra side, since Asterisk didn't seem to even know about it.

Further Research & Testing

   Without any further answers, we entered the #asterisk IRC channel on Freenode to present our evidence and ask for some ideas on what to investigate further. WIMPy responded with several suggestions for "session-timers" and "session-expires", further confirming the timeout suspicion. Overall, we ended up adding the following into the sip.conf file:

session-timers=accept
session-expires=600
rtptimeout=60
rtpholdtimeout=300

   Our tests with these settings didn't help the matter. To be fair, WIMPy suggested using "refuse" instead of "accept", but our reading on the subject brought us to attempt that first. We also found some notes on the Aastra phone saying, "You should avoid using 'sip session timer' with any value other than 0." With that suggestion, we added the following to the Aastra config:

sip session timer: 0

   After rebooting the phone, and reloading the Asterisk SIP settings, we tested the phone again. This time,, we left (it was late) and let the phone run overnight, playing MOH in a conference. Upon checking in the morning, the phone was still playing music!

Summary

   We are currently unsure if the Aastra "sip session timer: 0" change did the trick or if "session-timers=refuse" helped, or if *both* are required, but we do know that the issue is resolved. Given the opportunity to work on this again, we'll try just one option next time. For now, this is a production environment that is once again working properly.