similar to: Problem with Caller ID when receiving hidden number in via DAHDI and redirecting out via SIP

Hi, I am running Asterisk 11.3 with both SIP and ISDN. When dialing out (always over SIP) I want to keep track of who answered and of the length of the call. [outgoing-dev2] exten => h,1,Agi(agi://localhost/ajpbxtest.agi?status=finished) exten => _X.,1,NoOp(Will send call to ${CC_DIALSTRING}) exten => _X.,n,Dial(${CC_DIALSTRING}, 60, M(uploadpeer-dev2^${CC_CALLID})em) exten =>

Hi, Odd problem have just noticed in that when I call into the PBX DAHDI detects the call and hands it off to the extension, if I then hang up it still continues to process through the dialplan. This is what I have in chan_dahdi.conf: [channels] language=en echocancel=yes usecallerid=yes cidsignalling=v23 sendcalleridafter = 2 hanguponpolarityswitch=yes rxgain=2.0 txgain=3.0 progzone=uk

2012/1/10, Olivier <oza_4h07 at yahoo.fr>: > Hi, > > 1. This patch didn't correct the issue but I'm far from certain that I > correctly applied the patch. I was right to suspect I was wrong : now, after correctly applying the DAHLIN-275 patch, it's working OK (with the EchoCan module plugged-in). Thanks for your lighting fast correction !! > 2. I took the

The setup is this: 2 sip handsets (a Cisco 7960 and a 7961) exten 401/402 1 fxs/dahdi cordless phone, exten 201 rhino fxo/fxs analog card asterisk 1.4.31 This is running on a Soekris 5501 with Astlinux 0.7.2 While I do have FXO capabilities, no POTS lines are connected. When a call comes in (VoIP, either SIP or IAX) it is usually answered on one of the SIP Cisco phones(x 401 or 402). If it is

On Wed, Nov 20, 2019 at 04:37:14PM +0100, Karol Herbst wrote: > On Wed, Nov 20, 2019 at 4:15 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote: > > > On Wed, Nov 20, 2019 at 1:09 PM Mika Westerberg > > > <mika.westerberg at intel.com> wrote: > > > > > >

Aloha, I'm finishing up the final touches on this install, and have run into an odd problem. I can't seem to get Caller ID on the analog phone lines working. It's a Digium AEX 410 card. I have Verbose set and a line to print the CID: I have usecallerid=yes and callerid=asreceived set in both chan_dahdi.conf and users.conf [analog] include=>default exten =>

On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote: > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Wed, Nov 20, 2019 at 11:29:33PM +0100, Rafael J. Wysocki wrote: > > > > last week or so I found systems where the GPU was under the "PCI > > > > Express Root Port" (name

On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki <rafael at kernel.org> wrote: > > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Wed, Nov 20, 2019 at 11:52:22AM +0100, Rafael J. Wysocki wrote: > > > On Wed, Nov 20, 2019 at 11:18 AM Mika Westerberg > > > <mika.westerberg at intel.com>

On Wed, Nov 20, 2019 at 1:06 PM Rafael J. Wysocki <rafael at kernel.org> wrote: > > On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst <kherbst at redhat.com> wrote: > > > > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki <rafael at kernel.org> wrote: > > > > > > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg > > > <mika.westerberg

On Wed, Jul 22, 2020 at 11:25 AM Mika Westerberg <mika.westerberg at linux.intel.com> wrote: > > On Tue, Jul 21, 2020 at 01:37:12PM -0500, Patrick Volkerding wrote: > > On 7/21/20 10:27 AM, Mika Westerberg wrote: > > > On Tue, Jul 21, 2020 at 11:01:55AM -0400, Lyude Paul wrote: > > >> Sure thing. Also, feel free to let me know if you'd like access to one

On Mon, Oct 21, 2019 at 02:00:46PM +0200, Karol Herbst wrote: > On Mon, Oct 21, 2019 at 1:40 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > Hi Karol, > > > > Sorry for commenting late, I just came back from vacation. > > > > On Wed, Oct 16, 2019 at 04:44:49PM +0200, Karol Herbst wrote: > > > Fixes state transitions of

On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote: > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Thu, Nov 21, 2019 at 01:46:14PM +0200, Mika Westerberg wrote: > > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote: > > > > On Thu, Nov 21, 2019 at 12:28 PM Mika

On Mon, Oct 21, 2019 at 04:49:09PM +0200, Karol Herbst wrote: > On Mon, Oct 21, 2019 at 4:09 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Mon, Oct 21, 2019 at 03:54:09PM +0200, Karol Herbst wrote: > > > > I really would like to provide you more information about such > > > > workaround but I'm not aware of any ;-) I have

On Tue, Oct 1, 2019 at 10:47 AM Mika Westerberg <mika.westerberg at linux.intel.com> wrote: > > On Mon, Sep 30, 2019 at 06:36:12PM +0200, Karol Herbst wrote: > > On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg > > <mika.westerberg at linux.intel.com> wrote: > > > > > > On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote: > > > >

On Thu, Nov 21, 2019 at 11:39:23PM +0100, Rafael J. Wysocki wrote: > On Thu, Nov 21, 2019 at 8:49 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Thu, Nov 21, 2019 at 04:43:24PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Nov 21, 2019 at 1:52 PM Mika Westerberg > > > <mika.westerberg at intel.com> wrote: > > > >

On Wed, Nov 20, 2019 at 10:36:31PM +0100, Karol Herbst wrote: > with the branch and patch applied: > https://gist.githubusercontent.com/karolherbst/03c4c8141b0fa292d781badfa186479e/raw/5c62640afbc57d6e69ea924c338bd2836e770d02/gistfile1.txt Thanks for testing. Too bad it did not help :( I suppose there is no change if you increase the delay to say 1s?

On Thu, Nov 21, 2019 at 1:53 PM Karol Herbst <kherbst at redhat.com> wrote: > > On Thu, Nov 21, 2019 at 12:46 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Thu, Nov 21, 2019 at 12:34:22PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Nov 21, 2019 at 12:28 PM Mika Westerberg > > > <mika.westerberg at intel.com> wrote:

On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg <mika.westerberg at linux.intel.com> wrote: > > On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote: > > still happens with your patch applied. The machine simply gets shut down. > > > > dmesg can be found here: > >

On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote: > On Wed, Nov 20, 2019 at 1:09 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Wed, Nov 20, 2019 at 12:58:00PM +0100, Karol Herbst wrote: > > > overall, what I really want to know is, _why_ does it work on windows? > > > > So do I ;-) > > > > > Or what are

Even if PR3 support is available on the bridge, it will not be used if the PCI layer considers it unavailable (i.e. on all laptops from 2013 and 2014). Ensure that this condition is checked to allow a fallback to the Optimus DSM for device poweroff. Initially I wanted to call pci_d3cold_enable before checking bridge_d3 (in case the user changed d3cold_allowed), but that is such an unlikely case