That message is created by the Voicemail application. Check your
extensions.conf and see what your action is for when the call can not
be connected.
For example, a correct dialplan for a SIP extension would read:
exten => _200Z,1,Dial(SIP/${EXTEN},20)
exten => _200Z,2,Voicemail(u${EXTEN})
exten
> For example, a correct dialplan for a SIP extension would read:
>
> exten => _200Z,1,Dial(SIP/${EXTEN},20)
> exten => _200Z,2,Voicemail(u${EXTEN})
> exten => _200Z,102,Voicemail(b${EXTEN})
> exten => _200Z,103,Hangup
Hi All... I'm a newbie, just busy getting to grips with asterisk.
I've set up
Hi Keith,
Hi All... I'm a newbie, just busy getting to grips with asterisk.
I've set up the following, but it causes a segfault when I call somebody who
is offline:
exten => _[123456789],1,NoOp(.call for .${EXTEN})
exten => _[123456789],2,Dial(SIP/${EXTEN},60,tr)
exten => _[123456789],
> Are you running Redhat or Fedora? If so, read this thread for a solution:
>
> http://lists.digium.com/pipermail/asterisk-users/2004-January/031953.html
Nope, SUSE SLES 8
regards,
Keith
___
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lis
Keith Waters wrote:
Are you running Redhat or Fedora? If so, read this thread for a solution:
http://lists.digium.com/pipermail/asterisk-users/2004-January/031953.html
Nope, SUSE SLES 8
There are other users running the latest CVS-HEAD reporting that problem
(asterisk segfaults when unable to
On Mon, 2004-06-21 at 23:26, Simon Brown wrote:
> When I dial a SIP phone which is specified in the sip.conf, but the phone is
> not connected, Asterisk gives the message "The user at Extension XXX is on
> the phone "
> Shouldn't the message be the unavailable message?
> Is there something wron
June 2004 0:47
To: [EMAIL PROTECTED]
Subject: Re: [Asterisk-Users] Busy message
On Mon, 2004-06-21 at 23:26, Simon Brown wrote:
> When I dial a SIP phone which is specified in the sip.conf, but the
> phone is not connected, Asterisk gives the message "The user at
> Extension XX
> Simon Brown
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Eric Wieling
> Sent: Wednesday, 23 June 2004 0:47
> To: [EMAIL PROTECTED]
> Subject: Re: [Asterisk-Users] Busy message
>
> On Mon, 2004-06-21 at 23:26, Simo
ay of working.
>
> Simon Brown
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Eric
> Wieling
> Sent: Wednesday, 23 June 2004 0:47
> To: [EMAIL PROTECTED]
> Subject: Re: [Asterisk-Users] Busy message
>
> On
hable. Dial will continue with the next priority
on time-out (which generally happens when the device isn't answered).
> -Original Message-
> From: Simon Brown [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 22, 2004 6:44 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [Ast
On Tue, 2004-06-22 at 18:43, Simon Brown wrote:
> This should be listed as a bug - it is not logical to go to busy, when in
> fact the extension is unavailable.
I think the whole idea of "busy" or "unavailable" is flawed. Asterisk
sets ${CAUSECODE} with the cause of the call being cleared. You c
Eric Wieling [EMAIL PROTECTED] wrote:
> On Tue, 2004-06-22 at 18:43, Simon Brown wrote:
>> This should be listed as a bug - it is not logical to go to busy,
>> when in fact the extension is unavailable.
>
> I think the whole idea of "busy" or "unavailable" is flawed.
> Asterisk sets ${CAUSECODE} w
Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Eric Wieling
> Sent: Wednesday, 23 June 2004 8:43
> To: [EMAIL PROTECTED]
> Subject: RE: [Asterisk-Users] Busy message
>
> *I* think it should go to unavailable, but it has always gone to bu
7;t answered).
>
> > -Original Message-
> > From: Simon Brown [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 22, 2004 6:44 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [Asterisk-Users] Busy message
> >
> >
> > This should be lis
On Tue, 2004-06-22 at 19:31, Aaron J. Angel wrote:
> What would the contents of CAUSECODE be when set? I can't find
> documentation of this anywhere.
Sorry, it's "${HANGUPCAUSE} Asterisk hangup cause" as documented in
docs/README.variables. The cause code listing can be found in
include/asterisk
Logged in bugtracker as Bug #1893
Simon Brown
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rich Adamson
Sent: Wednesday, 23 June 2004 11:37
To: [EMAIL PROTECTED]
Subject: RE: [Asterisk-Users] Busy message
The issue has been suggested several times
Eric Wieling [EMAIL PROTECTED] wrote:
> On Tue, 2004-06-22 at 19:31, Aaron J. Angel wrote:
>> What would the contents of CAUSECODE be when set? I can't find
>> documentation of this anywhere.
>
> Sorry, it's "${HANGUPCAUSE} Asterisk hangup cause" as
> documented in docs/README.variables. The cau
Bug #1893 has now been acknowledged
Simon Brown
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rich Adamson
Sent: Wednesday, 23 June 2004 11:37
To: [EMAIL PROTECTED]
Subject: RE: [Asterisk-Users] Busy message
The issue has been suggested several times
[EMAIL PROTECTED] wrote:
> Sorry, it's "${HANGUPCAUSE} Asterisk hangup cause" as
> documented in docs/README.variables. The cause code listing
> can be found in include/asterisk/cause.h
As twisted points out: "Hangup cause is different than why it couldn't
create the channel." If that's the case
> There are other users running the latest CVS-HEAD reporting that problem
> (asterisk segfaults when unable to create channel). Maybe you have to
> revert to a previous version till the bug is fixed. ( cvs -D )
OK, thanks, will try that (btw, cvs -D is an invalid command)
Have you any idea wh
Hi!
> > I think the whole idea of "busy" or "unavailable" is flawed.
> > Asterisk sets ${CAUSECODE} with the cause of the call being
> > cleared. You can use this to determine what you want to do.
> > For exmaple if the cause code indicates "unallocated" then
> > you should give the caller some i
Hi Keith
Keith Waters wrote:
There are other users running the latest CVS-HEAD reporting that problem
(asterisk segfaults when unable to create channel). Maybe you have to
revert to a previous version till the bug is fixed. ( cvs -D )
OK, thanks, will try that (btw, cvs -D is an invalid command)
On Tue, 2004-06-22 at 21:44, Aaron J. Angel wrote:
> After doing some quick research, it appears HANGUPCAUSE is only implemented
> in chan_zap and chan_sip. What about the other channels?
They are out of luck until someone creates a patch to add that feature
to the other channels. I belive chan_
There's not really a way to do that that right now, although we could add
something like AST_CONTROL_INUSE which could represent that the channel is
in use actually. Wouldn't be extremely difficult to do, but would "INUSE"
and "BUSY" be the same? If not, where do we jump to?
Mark
On Wed, 11 Jun
Hmm... this gets quickly back to my long-standing desire to have more
comprehensive call completion codes being handed back by the channels
to the dialplan.
The current method of throwing certain replies into a big bucket
called "Busy" and others into a big bucket called "Error" and
auto-jumpi
On Fri, 2003-06-13 at 16:07, John Todd wrote:
> Hmm... this gets quickly back to my long-standing desire to have more
> comprehensive call completion codes being handed back by the channels
> to the dialplan.
>
Just a couple of comments.
I agree with jtodd about the call completion codes, but
At 4:46 PM -0600 6/13/03, Karl Putland wrote:
On Fri, 2003-06-13 at 16:07, John Todd wrote:
Hmm... this gets quickly back to my long-standing desire to have more
comprehensive call completion codes being handed back by the channels
to the dialplan.
Just a couple of comments.
I agree with jtodd
> >Why not have dial just dial, then have applications like WaitForAnswer,
> >WaitForDisconnect etc...?
> >
> >This would give more granularity to the call flow control and allow
> >someone to get brave and write a WaitForHuman or whatever.
>
>
> Hmm... I can't think of too many instances where
> >Why not have dial just dial, then have applications like WaitForAnswer,
>WaitForDisconnect etc...?
>
>This would give more granularity to the call flow control and allow
>someone to get brave and write a WaitForHuman or whatever.
Hmm... I can't think of too many instances where the functio
I had the same problem even though it was with capi, this may help. Have
you set your msn as Andrew or your line number??
Try this
exten => 2468,1,Dial(${TRUNK}/91234567:0412345678:1)
Regards
Michael Hatzis
0421 476 211
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PR
m.
B.R.
Eduardo.
-Mensaje original-
De: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] En nombre de Hatzis,
Michael
Enviado el: martes, 14 de diciembre de 2004 23:21
Para: Andrew Furey; Asterisk Users Mailing List - Non-Commercial Discussion
Asunto: RE: [Asterisk-Users] Busy message on ISDN card
Hi,
I had the same problem when i tried i4l, and as far as I remember the
solution was to set
the outgoing msn to the msn of the isdn-line.
From my old modem.conf:
incomingmsn=*
outgoingmsn=123456,123457
device => /dev/ttyI0
device => /dev/ttyI1
best regards,
Nils
On Sat,
32 matches
Mail list logo
