Summary:	ASTERISK-16494: [patch] No support for Cisco 7906 handset
Reporter:	Jonathan Hunter (jmhunter)	Labels:
Date Opened:	2010-08-03 06:19:34	Date Closed:	2012-05-27 20:06:58
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_skinny
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) backtrace.txt ( 1) skinny_7906.diff
Description:	Cisco 7906 handset is not yet supported by chan_skinny [Aug  3 11:13:33] WARNING[4713]:  Unsupported device type '369 (7906)' found. ****** ADDITIONAL INFORMATION ****** Picking up handset leads to: -- Starting simple switch on 'xxx@yyy' however when digits are dialled on the handset, nothing happens at the Asterisk end (no outbound call is initiated) I also managed to get Asterisk to segfault whilst trying to get the phone working - partial backtrace is attached.
Comments:	By: Damien Wedhorn (wedhorn) 2010-08-03 07:22:28 Small patch to add a single line. Let me know how it goes. There is an embedded bug in that you shouldn't get a simple switch for an unsupported device, but we'll look at that separately. By: Jonathan Hunter (jmhunter) 2010-08-03 09:55:39 OK, the phone registers & displays the line's extension number on the display. I pick up the phone and get a dialtone, I can dial the destination OK, and Asterisk routes the call correctly. However, the audio in the handset remains a dialtone, rather than the actual call.. :-) Thank you for your help with this. I may have to switch a couple of the phones to SIP, but will try and keep one skinny phone around as long as I can for testing. If all else fails, I will have access to my personal server again in a month or two, and will be able to do more detailed testing then.. By: Damien Wedhorn (wedhorn) 2010-08-03 14:43:15 Can you set "skinny set debug on" and provide the console printout of your call attempts. Also, can you try two other situations, after having made the call, try a redial. Also, try calling in to the 7906. By: Damien Wedhorn (wedhorn) 2012-05-27 20:06:58.566-0500 This should already be resolved in trunk with the addition of the v17 protocol handling.