|Summary:||ASTERISK-11745: [patch] chan_skinny call control problems with 7921|
|Date Opened:||2008-03-28 12:33:47||Date Closed:||2011-07-26 15:02:51|
|Environment:||Attachments:||( 0) skinnytransfver.v7.diff|
|Description:||First Problem: chan_skinny doesn't respect callwaiting=no flag in chan_skinny.conf|
This is for the 7921G phone. 7920 phone works as expected.
Example: (All phones chan_skinny with 1 line)
phone1 -> phone2
phone3 -> phone2
if phone2 answers, then phone2 can hear both phone1 & phone3, but they can't hear each other.
Second Problem: If a 7921G skinny device calls itself, the phone continues to ring until the battery is removed.
|Comments:||By: sbisker (sbisker) 2008-05-20 15:07:29|
This is still an issue with 1.6.0-beta9. In fact it is a little worse.
If A & B call C. And C answers either line, A & B still indicate ringing, but C thinks it's answered the call. Further, if C hangs up both calls, they still indicate that the phone is ringing.
By: Michiel van Baak (mvanbaak) 2008-07-19 06:44:41
Is it possible for you to test with trunk ?
By: Tilghman Lesher (tilghman) 2008-08-01 11:20:53
sbisker: we need a response here.
By: Michiel van Baak (mvanbaak) 2008-08-11 17:39:59
If you cant test with trunk, please tell us.
I'll have to close this issue this weekend if we did not get any feedback.
By: Damien Wedhorn (wedhorn) 2008-08-15 21:55:16
I've been playing around and I seem to be getting similar issues with my old phones. Any additional subs on a line seem to cause headaches. eg, call extn that dials multiple Skinny devices (including originating) and you can't hang up the originating leg from the device. I'll dig around a bit more and see if I can fix up the sub/line handling a bit (including ignoring callwaiting), which my fix this issue as well.
By: dea (dea) 2008-10-06 18:46:30
I cannot 100% prove this, but I think part of the issue stems from the fact
that we always set one of the call instance/reference values to 00.
I found that one of the status packets has the call number set, but we do not
set it and it is always 00. A simple increment/decrement will not work to
1st Call- 01
2nd Call- 02
3rd Call- 03
Hangup 2 and make another call now we have:
1st Call- 01
2nd Call- 02
3rd Call- 02
An array of call instances seems wasteful, and I have not had time to
look into a bitmasked instance tracker.
We do set call instance and line reference values properly, but I am starting
to think the phones may also need the correct call number to track the calls
I will re-run the packet captures to see which response packet needs the tweak.
The first uint32_t labeled as space in the packet call_info_message should
contain the call number.
I also noted that in stop_media_transmission_message and
close_receive_channel_message the conferenceId is repeated in the first
unint32_t labeled space.
It is possible that the phones internal call tracking state depends on one
or both sets of missing information.
By: Leif Madsen (lmadsen) 2009-01-09 13:16:55.000-0600
Reassigned to mvanbaak in the hopes we can move this issue forward again...
By: Michiel van Baak (mvanbaak) 2009-01-23 11:03:11.000-0600
put on hold. wedhorn is working on a massive cleanup/fixup of chan_skinny and we'll see how things work out with that in place.
By: Jason Parker (jparker) 2009-03-16 14:35:42
Is there a bug open for the cleanup by wedhorn? If so, we should probably add a relationship to it here.
By: Leif Madsen (lmadsen) 2009-03-18 08:34:48
Per mvanbaak on IRC, there is no issue open to relate to.
By: Leif Madsen (lmadsen) 2010-07-27 12:18:34
I'm suspending this issue as it does not appear to have any traction. If anyone is willing to move this issue forward again please reopen.
Also if wedhorn is really working on a big chan_skinny clean up, it would be ideal to have that opened as a separate bug to be related to this one.
By: Leif Madsen (lmadsen) 2010-07-27 15:57:19
Reopened at the request of wedhorn.
By: Damien Wedhorn (wedhorn) 2010-07-30 03:00:38
skinnytransfer.v7.diff added. Should fix the second issue where a device calls itself.
By: Damien Wedhorn (wedhorn) 2011-05-16 01:57:14
All of the reported issues should now be fixed in trunk as at r319024.