Summary: | ASTERISK-21071: [patch] Open channel for incoming call after RING; +CLIP responses from rfcomm; faster reporting of incoming calls | ||
Reporter: | Heiko Bihr (heiko.bihr) | Labels: | patch |
Date Opened: | 2013-02-13 12:03:20.000-0600 | Date Closed: | |
Priority: | Minor | Regression? | No |
Status: | Open/New | Components: | Addons/chan_mobile |
Versions: | SVN 10.12.0 13.18.4 | Frequency of Occurrence | |
Related Issues: | |||
Environment: | Fedora 17 i386 | Attachments: | ( 0) recognize_clip_after_ring_trunk.patch ( 1) recognize_clip_after_ring_trunk.patch ( 2) recognize_clip_after_ring.patch ( 3) recognize_clip_after_ring.patch |
Description: | My old Nokia 6230i emits the following response sequence for an incoming call
{quote} RING +CLIP: "+49xxxxxxxx",145 +CIEV: 4,1 RING +CLIP: "+49xxxxxxxx",145 {quote} chan_mobile detects an incoming call, if it receives +CIEV: 4,1. It then waits for a +CLIP response to get the caller id and after that opens a channel. On my mobile, there are 4 seconds of waiting time between the two RING answers in the above sequence. These 4 seconds must pass for every incoming call, before it is reported to asterisk. | ||
Comments: | By: Heiko Bihr (heiko.bihr) 2013-02-13 12:04:43.217-0600 [^recognize_clip_after_ring.patch] is a patch to chan_mobile.c, that handles RING just like +CIEV: 4,1 With this patch, a channel is opened directly after the first +CLIP response in the above sample. This reduces the waiting time, before an incoming call is reported to asterisk core. By: Matt Jordan (mjordan) 2013-02-13 12:19:03.536-0600 Since this represents an improvement and a behavioral change, you should: # Write the patch against trunk. Improvements are not committed in release branches. # See if other users of chan_mobile can confirm that your patch does not adversely affect their systems. That will make it easier for the patch to be accepted. Thanks! By: Richard Mudgett (rmudgett) 2013-02-13 18:20:08.802-0600 The patch is also not marked as a contribution. The electronic license may need to be completed and the patch re-uploaded. By: Heiko Bihr (heiko.bihr) 2013-02-15 04:46:31.440-0600 rewrote the patch against trunk By: Matt Jordan (mjordan) 2013-03-07 09:55:36.840-0600 I've marked the patch as a contribution. Please sign a License Contributor agreement so that your patch may be included in Asterisk. Thanks! By: Rusty Newton (rnewton) 2013-03-25 13:07:23.412-0500 Heiko Bihr - this still needs you to sign the contributor agreement and use "More Actions > Attach Files" to attach the patch as a contribution. By: Rusty Newton (rnewton) 2013-03-25 19:16:12.836-0500 It looks like the file is attached and Heiko does have an approved license. I think there is some buggy behavior happening with the attachment not showing. We are looking into it. By: Rusty Newton (rnewton) 2013-03-29 09:54:52.530-0500 Heiko - the original rejected license applies to the upload. You'll need to re-upload the patch for your new approved license to apply. Thanks! By: Heiko Bihr (heiko.bihr) 2013-03-30 05:33:39.711-0500 re-upload of patch as code contribution By: Rusty Newton (rnewton) 2013-04-02 17:06:11.618-0500 Thanks for the contribution! Asterisk components under extended support are supported primarily by the Asterisk developer community. The issue will wait for a community developer to review it and push it through. Getting others to review and test it ahead of time could speed things up. |