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’ comand.
Investigation
To get to the bottom of this issue, we connected a 10/100 hub between the phone and the network backbone, to allow a laptop to listen to the communications. 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:
CLI> core show channels concise
SIP/device18_1-cc05c788!user-502!555!15!Up!MeetMe!555,wqMs,!502!!3!3180!(None)!1288840034.136
DAHDI/pseudo-34872383!default!s!1!Rsrvd!(None)!!!!3!12196!(None)!1288831018.131
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 were 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 had better keywords to search for and found some notes about 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 now 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.