Will the outgoing "legacy" call answer before you join it to the
incoming call or will it be in some other state (like ringing).
Reason I ask is that I have a couple of macros that do almost what you
want to implement privacy manager on my system... Esentially plays a
please hold message until a se
Some more info in case anyone else hits this.
"Unable , to create channel of type 'Zap' (cause 66 - Channel not
implemented)"
I hit this error again setting up another system. So, not only does it
appear if you have more daughter boards than you have configured in
zaptel.conf; you will also get i
Thanks, Lonnie.
What I need is to initiate a *separate* *outgoing* call (to the legacy
network) that will be joined to the parked call.
My understanding is that a Followme() is joined by a user dialing *into*
Asterisk to meet the parked call in response to a page.
Any ideas ?
Brian
-Or
Michael, many thanks for your sharing your experiences. Interesting stuff.
Mart
Michael Graves wrote:
> After watching this a while I feel that I must weigh in based on my own
> experience. I've taken an embedded system approach to my Asterisk
> installation from a time when this was not at all c
After watching this a while I feel that I must weigh in based on my own
experience. I've taken an embedded system approach to my Asterisk
installation from a time when this was not at all commonplace. My
earliest embedded systems were early in 2004.
AFAIK Astlinux was the very first distro to be c
On Jan 3, 2009, at 11:39 AM, O'Connor, Brian wrote:
>
> I have an unusual call handling requirement, and can use some guidance
> on how to accommodate this.
>
> An incoming call needs to be forwarded to a legacy network with a
> *very
> long* set-up delay (10's of seconds). So while initiating
I have an unusual call handling requirement, and can use some guidance
on how to accommodate this.
An incoming call needs to be forwarded to a legacy network with a *very
long* set-up delay (10's of seconds). So while initiating call set-up on
the outgoing path we want to play a "please hold" mes
Martin Rogers wrote:
> I agree about the versioning, but these are just numbers.
>
> We have just moved a fairly complex dialplan from 1.4 to 1.6 and it
> wasn't that big a deal. More of headache actually were changes to the AMI.
>
As is normally the case, your mileage may vary. I know I'll be
I agree about the versioning, but these are just numbers.
We have just moved a fairly complex dialplan from 1.4 to 1.6 and it
wasn't that big a deal. More of headache actually were changes to the AMI.
Mart
Rob Hillis wrote:
> Martin Rogers wrote:
>> Just curious, but rather than wait for 1.4.23,
Martin Rogers wrote:
> Just curious, but rather than wait for 1.4.23, wouldn't it be better to
> head straight for 1.6 ?
>
1.4 to 1.6 is a big step that can (and almost certainly *will*) lead to
dialplan breakages. After going through the pain of a 1.4 to 1.6
migration, I've come to realise
Just curious, but rather than wait for 1.4.23, wouldn't it be better to
head straight for 1.6 ?
Thanks
Mart
Darrick Hartman wrote:
> David,
>
> Remove the setting of PERSISTLOG. We've updated the init script after
> 0.6.2 was released. Before if PERSISTLOG was set to anything, it would
> log
11 matches
Mail list logo
