Re: [asterisk-users] DAHDI help please

2012-10-02 Thread Shaun Ruffell 
On Tue, Oct 02, 2012 at 11:22:31PM -0400, Pat Collins wrote:
> Shaun,
> To make more sense of the code, I changed 
> #define DAHDI_XBIT(3 >> 2) to 
> #define DAHDI_XBIT(0)
> 
> Sadly, incoming calls do not work.  Not sure exactly how to START or RING
> when the RX AB bits are 00
> Any ideas?
> Thanks again for your help!

The board drivers call dahdi_rbsbits() when they want to report a change
in the state of the RBS bits for a channel. If you look in the code
there you will see where events are generated depending on the
signalling type.

I should have pointed out that function in my previous email.

Cheers,
Shaun

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Case-sensitivity of Dialplan variables.

2012-10-02 Thread Olivier 
2012/10/1 Mark Michelson 

> Hi!
>
> I've been confronted with an interesting issue to resolve. The
> issue is located here:
>
> https://issues.asterisk.org/**jira/browse/ASTERISK-20163
>
> The issue involves case-sensitivity of channel and global variables
> in the dialplan. Current behavior is as follows:
>
> 1) Variables created in the dialplan by users are case-insensitive.
> Thus if the variable MARK were set, then ${MARK} and ${mark} would
> both evaluate to the set value.
>
> 2) Variables used internally by Asterisk are case sensitive. So if
> some application set a variable called MARK, it would be different
> from a variable set by some application called mark.
>
> First off, this inconsistency is just weird. It would be much easier
> to just have things work one way or the other, not to have this mix.
>
> In addition, this can lead to some awkward situations. Consider that
> someone wants to use a specific SIP codec and so they set the
> variable SIP_CODEc to be "g722". Notice that the final 'c' is
> lowercase, presumably due to a typing error. The option would not
> take effect because chan_sip specifically checks the value of the
> case-sensitive ${SIP_CODEC}. What makes this weirder is that if
> the dialplan writer were to check ${SIP_CODEC} in the dialplan
> using a NoOp or Verbose call, then he would see the variable set
> to the value he set it to when he set ${SIP_CODEc} because the
> variable substitution is case-insensitive in the dialplan. This
> makes debugging the problem difficult.
>
> I propose that dialplan variables need to be made consistent in their
> evaluation. We need to choose either to be always case-sensitive or
> always case-insensitive. The problem is, I don't know which of these
> changes would have a larger effect on people. This is where I would
> like your feedback. Which way should it go?
>
> Some of you might be eager to propose a configuration option to
> decide which it should be. I'm sick of having hundreds of options
> in Asterisk to slightly tweak the behavior one way or another. This
> needs to go one way or the other, not be configurable.
>
> What I plan to do, no matter which way the vote goes, is to document
> on the wiki how things currently behave in Asterisk, to include the
> example I gave above (or something similar anyway). Depending how
> the vote goes, I will make the necessary code changes in Asterisk
> trunk. I will document the behavior change both in UPGRADE.txt and
> on the wiki.
>
> When considering which way you lean, consider that we really don't
> have much of a precedent to go on. For instance, dialplan applications
> are case-insensitive ("answer" and "Answer" and "ANSWER" are all the
> same). Dialplan functions, on the other hand, are case sensitive
> ("HASH" would be evaluated properly but "hash" would not). My personal
> opinion is that all variable evaluations should be case-sensitive.
> I don't feel all that strongly about it though and could easily be
> swayed the other way if people respond overwhelmingly in opposition.
>
> So respond here and let me know what you think. I got a couple of replies
> on the -dev list and they said that this would be good to put out on the
> -users list too.
>
> Mark Michelson
>
> --
> __**__**_
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   
> http://lists.digium.com/**mailman/listinfo/asterisk-dev
>
>
+1 for case-sensitivity

> --
> __**__**_
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>   http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   
> http://lists.digium.com/**mailman/listinfo/asterisk-**users
>
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Case-sensitivity of Dialplan variables.

2012-10-02 Thread Vladimir Mikhelson 

On 10/2/2012 9:12 PM, Warren Selby wrote:
> On Mon, Oct 1, 2012 at 4:15 PM, Mark Michelson  > wrote:
>
> Hi!
>
> I've been confronted with an interesting issue to resolve. The
> issue is located here:
>
> 
>  
>
> So respond here and let me know what you think. I got a couple of
> replies on the -dev list and they said that this would be good to
> put out on the -users list too.
>
> Mark Michelson
>
>
> My vote is to maintain the case sensitivity as the way it is now -
> user generated variables are case-insensitive, and asterisk-generated
> variables are case sensitive.  I think breaking the existing behavior
> would be causing more problems than it solves.
>
> -- 
> Thanks,
> --Warren Selby, dCAP
> http://www.SelbyTech.com 
>
I would concur with Warren.  The best solution is to leave as is.

-Vladimir


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] DAHDI help please

2012-10-02 Thread Pat Collins 
Shaun,
To make more sense of the code, I changed 
#define DAHDI_XBIT  (3 >> 2) to 
#define DAHDI_XBIT  (0)

Sadly, incoming calls do not work.  Not sure exactly how to START or RING
when the RX AB bits are 00
Any ideas?
Thanks again for your help!

-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Pat Collins
Sent: Tuesday, October 02, 2012 2:48 PM
To: 'Asterisk Users Mailing List - Non-Commercial Discussion'
Subject: Re: [asterisk-users] DAHDI help please

Thank you for the reply!
So far, I've managed to get the on off hook to work properly!
My next problem is the incoming ring. I've changed the /include/dahdi/user.h
file:
#define DAHDI_ABIT  (1 << 3)
#define DAHDI_BBIT  (1 << 2)
#define DAHDI_CBIT  (1 << 1)
#define DAHDI_DBIT  (1 << 0)
#define DAHDI_XBIT  (3 >> 2)  ADDED THIS!!

#define DAHDI_BITS_ABCD (DAHDI_ABIT | DAHDI_BBIT | DAHDI_CBIT | DAHDI_DBIT)
#define DAHDI_BITS_ABD (DAHDI_ABIT | DAHDI_BBIT | DAHDI_DBIT) #define
DAHDI_BITS_ACD (DAHDI_ABIT | DAHDI_CBIT | DAHDI_DBIT) #define DAHDI_BITS_BCD
(DAHDI_BBIT | DAHDI_CBIT | DAHDI_DBIT) #define DAHDI_BITS_AC (DAHDI_ABIT |
DAHDI_CBIT) #define DAHDI_BITS_BD (DAHDI_BBIT | DAHDI_DBIT)
#define DAHDI_BITS_X   (DAHDI_XBIT) AND THIS!!

Then in /driver/dahdi/dahdi-base.c I changed:
static void dahdi_rbs_sethook(struct dahdi_chan *chan, int txsig, int
txstate,
int timeout)
{
static const struct {
unsigned int sig_type;
/* Index is dahdi_txsig enum */
unsigned int bits[DAHDI_TXSIG_TOTAL];
} outs[NUM_SIGS] = {
{
/*
 * We set the idle case of the DAHDI_SIG_NONE to
this pattern to make idle E1 CAS
 * channels happy. Should not matter with T1, since
on an un-configured channel,
 * who cares what the sig bits are as long as they
are stable
 */
.sig_type = DAHDI_SIG_NONE,
.bits[DAHDI_TXSIG_ONHOOK]  = DAHDI_BITS_ABCD,
}, {
.sig_type = DAHDI_SIG_EM,
.bits[DAHDI_TXSIG_OFFHOOK] = DAHDI_SIG_NONE,   /*
changed from ACD */
.bits[DAHDI_TXSIG_START]   = DAHDI_SIG_NONE,   /*
changed from ACD */
.bits[DAHDI_TXSIG_ONHOOK]  = DAHDI_BITS_ABCD, /*
added this !! */
.bits[DAHDI_RXSIG_START]= DAHDI_BITS_X,  /*
start.. xbit */
.bits[DAHDI_RXSIG_RING]= DAHDI_BITS_X,  /*
ring.. xbit */
}, {

And this:
void dahdi_rbsbits(struct dahdi_chan *chan, int cursig) {
unsigned long flags;
if (cursig == chan->rxsig)
return;

if ((chan->flags & DAHDI_FLAG_SIGFREEZE)) return;
spin_lock_irqsave(&chan->lock, flags);
switch(chan->sig) {
case DAHDI_SIG_EM: /* was FXO Groundstart */
/* B-bit only matters for FXO GS changed BBIT to
XBIT */
if (!(cursig & DAHDI_XBIT)) {
__dahdi_hooksig_pvt(chan, DAHDI_RXSIG_START);
break;
}
/* Fall through */
case DAHDI_SIG_FXOGS:  /* changed from E and M */
case DAHDI_SIG_EM_E1:
case DAHDI_SIG_FXOLS: /* FXO Loopstart */
case DAHDI_SIG_FXOKS: /* FXO Kewlstart */
if (cursig & DAHDI_ABIT)  /* off hook */
__dahdi_hooksig_pvt(chan,DAHDI_RXSIG_OFFHOOK);
else /* on hook */
__dahdi_hooksig_pvt(chan,DAHDI_RXSIG_ONHOOK);
break;

Thank you for your help Shaun!!!

-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Shaun Ruffell
Sent: Tuesday, October 02, 2012 2:17 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] DAHDI help please

On Mon, Oct 01, 2012 at 06:44:22PM -0400, Pat Collins wrote:
> Can anyone tell me if it is possible to invert the signaling bits on a
> T1 channel?
>
> I need to emulate PLAR signaling in asterisk.  E&M seems to be an 
> exact match if reversed.
>
> I need idle bits  and seized 

Perhaps you could edit dahdi_rbs_sethook() and dahdi_q_sig()?  Those
function map state to RBS states.

--
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at:
www.digium.com & www.asterisk.org

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

ast

Re: [asterisk-users] Case-sensitivity of Dialplan variables.

2012-10-02 Thread Michael L. Young 
- Original Message -
> From: "Ira" 
> To: "Asterisk Users Mailing List - Non-Commercial Discussion" 
> 
> Sent: Tuesday, October 2, 2012 8:11:32 PM
> Subject: Re: [asterisk-users] Case-sensitivity of Dialplan variables.
> 
> 
> Given that many of the users were not programmers and didn't likely
> grow up in a case sensitive world I'd also vote for case
> insensitivity. I fall into that category, I grew up with dBase,
> Clipper and VB and case issues get me all the time when I program in
> C.
> 
> Allowing case insensitivity does not stop someone from using case
> consistently and While I guess there could be a reason why you'd want
> to use the word hash in the forms hash, Hash and HASH and have them
> be 3 different items, I'm guessing that the people trying to get
> their feet wet moving from Asterisk-Now to Asterisk would be confused
> to say the least if someone did that in example code.

While true that most users are probably not programmers, most people 
administering Asterisk would be system / network admins, correct?  System 
admins and networking admins are used to working in environments such as Linux 
where variables and file names are case sensitive.

If someone is moving from a GUI interface to CLI, then they would/should know 
that case sensitivity is important and therefore the change shouldn't pose a 
problem.

Just some thoughts in regards to the concerns brought up.

Michael L. Young
(elguero)

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Questions on converting to ConfBridge

2012-10-02 Thread Joshua Colp 

Hola,

Richard Kenner wrote:


I'm looking at what would be involved in converting from MeetMe to
ConfBridge and there seems to be a lot of missing administrative things,
but I hope I'm just missing it.  We all know about the missing realtime
linkage.  That's a major nuisance, but can be worked around.


I think you are only the second or third person to really even mention 
realtime in the context of ConfBridge in the places I see.



More serious is that the CLI command to display users in a ConfBridge
don't show the caller ID information, so it becomes very hard to
have web applications that show who's in a conference.  There also doesn't
seem to be a way to lock conferences or mute or kick out users from
the dialplan.  And the CLI command needs a channel, not a user index,
making scripting via the dialplan that much harder.


Why are you wanting to use CLI commands instead of AMI? The available 
AMI actions for ConfBridge can do listing/locking/muting/kicking etc as 
you want.


As for dialplan applications to do the various things - what are you 
trying to achieve using them?


Cheers,

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Case-sensitivity of Dialplan variables.

2012-10-02 Thread Warren Selby 
On Mon, Oct 1, 2012 at 4:15 PM, Mark Michelson wrote:

> Hi!
>
> I've been confronted with an interesting issue to resolve. The
> issue is located here:
>
> 


> So respond here and let me know what you think. I got a couple of replies
> on the -dev list and they said that this would be good to put out on the
> -users list too.
>
> Mark Michelson
>

My vote is to maintain the case sensitivity as the way it is now - user
generated variables are case-insensitive, and asterisk-generated variables
are case sensitive.  I think breaking the existing behavior would be
causing more problems than it solves.

-- 
Thanks,
--Warren Selby, dCAP
http://www.SelbyTech.com 
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Case-sensitivity of Dialplan variables.

2012-10-02 Thread Michael L. Young 
- Original Message -
> From: "Vladimir Mikhelson" 
> To: "Asterisk Users Mailing List - Non-Commercial Discussion" 
> 
> Sent: Tuesday, October 2, 2012 9:02:18 PM
> Subject: Re: [asterisk-users] Case-sensitivity of Dialplan variables.
> 
> 
> On 10/1/2012 4:15 PM, Mark Michelson wrote:
> >
> > What I plan to do, no matter which way the vote goes, is to
> > document
> > on the wiki how things currently behave in Asterisk, to include the
> > example I gave above (or something similar anyway). Depending how
> > the vote goes, I will make the necessary code changes in Asterisk
> > trunk. I will document the behavior change both in UPGRADE.txt and
> > on the wiki.
> >
> > When considering which way you lean, consider that we really don't
> > have much of a precedent to go on. For instance, dialplan
> > applications
> > are case-insensitive ("answer" and "Answer" and "ANSWER" are all
> > the
> > same). Dialplan functions, on the other hand, are case sensitive
> > ("HASH" would be evaluated properly but "hash" would not). My
> > personal
> > opinion is that all variable evaluations should be case-sensitive.
> > I don't feel all that strongly about it though and could easily be
> > swayed the other way if people respond overwhelmingly in
> > opposition.
> >

 
> First you need to consider compatibility with currently supported
> packages which include auto-generated dial plans like AsteriskNow,
> PIAF,
> etc.  If you plan to break their functionality you need to at least
> coordinate your move with the maintainers.

This change would go into trunk, the development line of code.  So, I am not 
sure that a coordinated effort would need to be made here.  As with every major 
release, maintainers of external packages usually check the UPGRADE.txt.  There 
almost always will be something to change between major versions in order to 
keep in step with the new release.
 
> Then you may want to consider backwards compatibility with packages
> still widely used but not actively supported any more like Trixbox.
> Maybe not the best example as their WEB site says, "This is the
> current
> stable release based on Asterisk 1.6."

Again, I am not sure there is a need for backwards compatibility.  This change 
would go into Asterisk 12, which is not LTS.  I would think that most packages 
would be focused more on working with the LTS version of Asterisk.  I could be 
wrong though.  Given that Asterisk 11 is the current LTS that will be probably 
be released soonish out of beta, the next LTS version is a couple of years away 
giving plenty of time for people to make the necessary changes.
 
> If you really want to make it not settable (and this is big, not a
> minor
> change, if I were you I would definitely make it settable) then I
> would
> go with case-insensitive as it allows for various custom notations,
> e.g.
> Hungarian notation in naming of custom variables without a later
> painstaking investigation whether "nCallID" is equal to "nCallId" or
> not.  Consider the fact, most of the dial plan debugging happens in
> the
> logs or in the Console Screen.  Someone may want to spell "nCALLID"
> just
> to be able to see the difference between Latin "l" and "I" where the
> first one is "L" lower case and the second one is "i" upper case.

I didn't quite follow this logic.  Your example, in my mind, would actually be 
easier to debug with this change.

If you know that variables are case sensitive, you know that you have to check 
for a typo in your variable name if you are not getting what you were 
expecting. Here, in my email client, the "l" and "i" are very distinct as well 
as the console I work in.

Just my thoughts on the above concerns presented.

Michael L. Young
(elguero)

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Case-sensitivity of Dialplan variables.

2012-10-02 Thread Vladimir Mikhelson 

On 10/1/2012 4:15 PM, Mark Michelson wrote:
> Hi!
>
> I've been confronted with an interesting issue to resolve. The
> issue is located here:
>
> https://issues.asterisk.org/jira/browse/ASTERISK-20163
>
> The issue involves case-sensitivity of channel and global variables
> in the dialplan. Current behavior is as follows:
>
> 1) Variables created in the dialplan by users are case-insensitive.
> Thus if the variable MARK were set, then ${MARK} and ${mark} would
> both evaluate to the set value.
>
> 2) Variables used internally by Asterisk are case sensitive. So if
> some application set a variable called MARK, it would be different
> from a variable set by some application called mark.
>
> First off, this inconsistency is just weird. It would be much easier
> to just have things work one way or the other, not to have this mix.
>
> In addition, this can lead to some awkward situations. Consider that
> someone wants to use a specific SIP codec and so they set the
> variable SIP_CODEc to be "g722". Notice that the final 'c' is
> lowercase, presumably due to a typing error. The option would not
> take effect because chan_sip specifically checks the value of the
> case-sensitive ${SIP_CODEC}. What makes this weirder is that if
> the dialplan writer were to check ${SIP_CODEC} in the dialplan
> using a NoOp or Verbose call, then he would see the variable set
> to the value he set it to when he set ${SIP_CODEc} because the
> variable substitution is case-insensitive in the dialplan. This
> makes debugging the problem difficult.
>
> I propose that dialplan variables need to be made consistent in their
> evaluation. We need to choose either to be always case-sensitive or
> always case-insensitive. The problem is, I don't know which of these
> changes would have a larger effect on people. This is where I would
> like your feedback. Which way should it go?
>
> Some of you might be eager to propose a configuration option to
> decide which it should be. I'm sick of having hundreds of options
> in Asterisk to slightly tweak the behavior one way or another. This
> needs to go one way or the other, not be configurable.
>
> What I plan to do, no matter which way the vote goes, is to document
> on the wiki how things currently behave in Asterisk, to include the
> example I gave above (or something similar anyway). Depending how
> the vote goes, I will make the necessary code changes in Asterisk
> trunk. I will document the behavior change both in UPGRADE.txt and
> on the wiki.
>
> When considering which way you lean, consider that we really don't
> have much of a precedent to go on. For instance, dialplan applications
> are case-insensitive ("answer" and "Answer" and "ANSWER" are all the
> same). Dialplan functions, on the other hand, are case sensitive
> ("HASH" would be evaluated properly but "hash" would not). My personal
> opinion is that all variable evaluations should be case-sensitive.
> I don't feel all that strongly about it though and could easily be
> swayed the other way if people respond overwhelmingly in opposition.
>
> So respond here and let me know what you think. I got a couple of
> replies on the -dev list and they said that this would be good to put
> out on the -users list too.
>
> Mark Michelson
>
Mark,

First you need to consider compatibility with currently supported
packages which include auto-generated dial plans like AsteriskNow, PIAF,
etc.  If you plan to break their functionality you need to at least
coordinate your move with the maintainers.

Then you may want to consider backwards compatibility with packages
still widely used but not actively supported any more like Trixbox.
Maybe not the best example as their WEB site says, "This is the current
stable release based on Asterisk 1.6."

If you really want to make it not settable (and this is big, not a minor
change, if I were you I would definitely make it settable) then I would
go with case-insensitive as it allows for various custom notations, e.g.
Hungarian notation in naming of custom variables without a later
painstaking investigation whether "nCallID" is equal to "nCallId" or
not.  Consider the fact, most of the dial plan debugging happens in the
logs or in the Console Screen.  Someone may want to spell "nCALLID" just
to be able to see the difference between Latin "l" and "I" where the
first one is "L" lower case and the second one is "i" upper case.

Just my 2 cents.

-Vladimir


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Case-sensitivity of Dialplan variables.

2012-10-02 Thread Ira 

At 02:19 PM 10/1/2012, you wrote:

So respond here and let me know what you think. I got a couple of replies on
the -dev list and they said that this would be good to put out on the -users
list too.

Mark Michelson

In true Republican fashion, I'm going to vote for case-insensitivity.


Given that many of the users were not programmers and didn't likely 
grow up in a case sensitive world I'd also vote for case 
insensitivity. I fall into that category, I grew up with dBase, 
Clipper and VB and case issues get me all the time when I program in C.


Allowing case insensitivity does not stop someone from using case 
consistently and While I guess there could be a reason why you'd want 
to use the word hash in the forms hash, Hash and HASH and have them 
be 3 different items, I'm guessing that the people trying to get 
their feet wet moving from Asterisk-Now to Asterisk would be confused 
to say the least if someone did that in example code.


Ira 



--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Parameterize asterisk config files

2012-10-02 Thread Andrew Latham 
On Tue, Oct 2, 2012 at 8:04 PM, Steve Edwards  wrote:
> On Tue, 2 Oct 2012, Mitch Claborn wrote:
>
>> I'd like to be able to use the same config files in CVS and have the
>> differences resolved at run time, based on host name of the asterisk server.
>>
>> Another idea would be to write a simple perl or other program to
>> pre-process the files and put some markers in the files themselves.
>
>
> I don't use CVS, old bad habits die hard :)
>
> I use a preprocessor. Specifically:
>
> http://git.dyne.org/freej/plain/lib/javascript/config/preprocessor.pl
>
> (Not where I got it from, but it's the same file.)
>
> because it had enough features and because my production hosts already have
> Perl so I didn't have to add yet another scripting language.
>
> This preprocessor allows you to do '#if HOSTNAME==v0' where HOSTNAME is a
> shell environment variable or it can be defined on the command line.
>
> You can also define variables in an 'include' file
>
> It will do a whole lot more, but 'if' and substitution were the only
> features I needed at the time. If I could have deciphered 'm4' I might have
> used that, but the sendmail.mc files look too damn ugly to maintain.
>
> I hacked in CURDATE and CURTIME as 'pre-defined variables'.
>
> Here's a sample of one of my files:
>
> #
> #   Filename:   /source/src/${PROJECT}/manager.conf.pre
> #
> #   Version:001
> #
> #   Edit date:  2008-12-02
> #
> #   Facility:   Asterisk
> #
> #   Abstract:   Define connections to the manager interface.
> #
> #   Environment:Asterisk
> #
> #   Author: Steven L. Edwards
> #
> #   Modified by
> #
> #   000 2008-10-17  SLE Started documenting.
> #   001 2008-12-02  SLE Preprocessorize.
> #expand ; Created by makefile on __CURDATE__ at __CURTIME__
> #expand ; from __FILE__
>
> [general]
> enabled = yes
> port= 5038
> #if HOSTNAME==v0
> bindaddr= 127.0.0.1
> #else
> bindaddr= 0.0.0.0
> #endif
>
> [@AMI_USERNAME@]
> deny= 0.0.0.0/0.0.0.0
> #if HOSTNAME==v0
> permit  = 127.0.0.1/255.255.255.255
> #else
> permit  = 192.168.0.0/255.255.255.0
> #endif
> read= all
> secret  = @AMI_SECRET@
> write   = all
>
> ; (end of /etc/asterisk/manager.conf)
> # (end of /source/src/${PROJECT}/manager.conf.pre)
>
> This gets munged by my makefile so deployment consists of 'make rsync;
> make config'
>
> --
> Thanks in advance,
> -
> Steve Edwards   sedwa...@sedwards.com  Voice: +1-760-468-3867 PST
> Newline  Fax: +1-760-731-3000


While we are at it, GIT, Python Fabric and sed balance out most of my
deployment needs.  There are other moving parts but those are my own
design...


-- 
~ Andrew "lathama" Latham lath...@gmail.com http://lathama.net ~

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Parameterize asterisk config files

2012-10-02 Thread Steve Edwards 

On Tue, 2 Oct 2012, Mitch Claborn wrote:

I'd like to be able to use the same config files in CVS and have the 
differences resolved at run time, based on host name of the asterisk 
server.


Another idea would be to write a simple perl or other program to 
pre-process the files and put some markers in the files themselves.


I don't use CVS, old bad habits die hard :)

I use a preprocessor. Specifically:

http://git.dyne.org/freej/plain/lib/javascript/config/preprocessor.pl

(Not where I got it from, but it's the same file.)

because it had enough features and because my production hosts already 
have Perl so I didn't have to add yet another scripting language.


This preprocessor allows you to do '#if HOSTNAME==v0' where HOSTNAME is a 
shell environment variable or it can be defined on the command line.


You can also define variables in an 'include' file

It will do a whole lot more, but 'if' and substitution were the only
features I needed at the time. If I could have deciphered 'm4' I might 
have used that, but the sendmail.mc files look too damn ugly to maintain.


I hacked in CURDATE and CURTIME as 'pre-defined variables'.

Here's a sample of one of my files:

#
#   Filename:   /source/src/${PROJECT}/manager.conf.pre
#
#   Version:001
#
#   Edit date:  2008-12-02
#
#   Facility:   Asterisk
#
#   Abstract:   Define connections to the manager interface.
#
#   Environment:Asterisk
#
#   Author: Steven L. Edwards
#
#   Modified by
#
#   000 2008-10-17  SLE Started documenting.
#   001 2008-12-02  SLE Preprocessorize.
#expand ; Created by makefile on __CURDATE__ at __CURTIME__
#expand ; from __FILE__

[general]
enabled = yes
port= 5038
#if HOSTNAME==v0
bindaddr= 127.0.0.1
#else
bindaddr= 0.0.0.0
#endif

[@AMI_USERNAME@]
deny= 0.0.0.0/0.0.0.0
#if HOSTNAME==v0
permit  = 127.0.0.1/255.255.255.255
#else
permit  = 192.168.0.0/255.255.255.0
#endif
read= all
secret  = @AMI_SECRET@
write   = all

; (end of /etc/asterisk/manager.conf)
# (end of /source/src/${PROJECT}/manager.conf.pre)

This gets munged by my makefile so deployment consists of 'make rsync;
make config'

--
Thanks in advance,
-
Steve Edwards   sedwa...@sedwards.com  Voice: +1-760-468-3867 PST
Newline  Fax: +1-760-731-3000

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Parameterize asterisk config files

2012-10-02 Thread Paul Belanger 

On 12-10-02 06:39 PM, Mitch Claborn wrote:

Asterisk 1.8 on Ubuntu

We store the configuration files in CVS.  We have a development, QA and
production environments. 90% of the config files are the same across all
3 environments, but there are some differences in sip.conf and
extensions.conf (environment specific voip providers and/or
analog/digital lines).  I'd like to be able to use the same config files
in CVS and have the differences resolved at run time, based on host name
of the asterisk server.

Any ideas how to do this?

I looked at STS, but it appears to be Mac only.

One idea would be to use something like

#include sip-$$$hostname$$$.conf

and then use sed or similar in the startup script to replace
$$$hostname$$$ with the actual host name.  Then each host/environment
would have it's own include file as needed.

Another idea would be to write a simple perl or other program to
pre-process the files and put some markers in the files themselves.
; onlyif host=abc
; /onlyif
The pre-processor would delete lines between the tags that didn't match
the currently running host.

If you are going to astricon you'll want to show up for my talk.  This 
is basically what Leif and I will be talking about.


I use puppet to help manage our 3 environments (test, stage and 
production). Along side it I use a the following configuration setup[1] 
plus some Debian packaging scripts[2].


With this, I can quickly spin up instances which are provisioned to a 
base. Then, depending on puppet manifests[3] for each node, it defines 
how the system is then provisioned.


If more per-site settings are required, I'll roll them into Debian 
packages (we use Ubuntu 12.04) and have each site subscribe to a 
customer repo.


[1] 
https://github.com/kickstandproject/asterisk/tree/master/debian/ast_config
[2] 
https://github.com/kickstandproject/astricon-2012-presentation/tree/master/debian
[3] 
https://github.com/kickstandproject/puppet-modules/tree/master/modules/asterisk/manifests


--
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: 
https://twitter.com/pabelanger


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Call Termination Provider Madness

2012-10-02 Thread Chris Nighswonger 
On Tue, Oct 2, 2012 at 5:30 PM, Chris Bagnall
 wrote:
> On 2/10/12 6:51 pm, Carlos Alvarez wrote:
>>
>> Your traffic level, number of concurrent calls, etc would help us know
>> what
>> sort of carrier you should be talking to.
>
>
> Equally important, your geographic location, and the geographic location to
> which most of your calls are made will be useful in helping list members
> advise you.

We do ~4000+ min of outbound calling per month and just about that
inbound. Not a large volume. We have four DID's (one of which is 800).

Our calling patterns are mostly the lower 48 with a smattering
international. We are located in NC.

RTP is the problem in the FW. I just cannot see opening all RTP ports
to $universal. But I'm probably missing a key piece of information.
:-)

Kind Regards,
Chris

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] Parameterize asterisk config files

2012-10-02 Thread Mitch Claborn 

Asterisk 1.8 on Ubuntu

We store the configuration files in CVS.  We have a development, QA and 
production environments. 90% of the config files are the same across all 
3 environments, but there are some differences in sip.conf and 
extensions.conf (environment specific voip providers and/or 
analog/digital lines).  I'd like to be able to use the same config files 
in CVS and have the differences resolved at run time, based on host name 
of the asterisk server.


Any ideas how to do this?

I looked at STS, but it appears to be Mac only.

One idea would be to use something like

#include sip-$$$hostname$$$.conf

and then use sed or similar in the startup script to replace 
$$$hostname$$$ with the actual host name.  Then each host/environment 
would have it's own include file as needed.


Another idea would be to write a simple perl or other program to 
pre-process the files and put some markers in the files themselves.

; onlyif host=abc
; /onlyif
The pre-processor would delete lines between the tags that didn't match 
the currently running host.





--

Mitch


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] How to remove the call waiting tone without disabling callwaiting?

2012-10-02 Thread James Cloos 
> "NB" == Niccolò Belli  writes:

NB> If someone knows how to COMPLETELY REMOVE the fucking beep please
NB> let me know: there are already tons of phones ringing everywhere so
NB> there is no need for an annoying beep.

Edit chan_dahdi.c.

The my_callwait() and/or dahdi_callwait() functions may be enough.

You want to skip the silence and tone creation steps.

Or perhaps #defining CALLWAITING_REPEAT_SAMPLES to 0 might work.

-JimC
-- 
James Cloos  OpenPGP: 1024D/ED7DAEA6

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] Questions on converting to ConfBridge

2012-10-02 Thread Richard Kenner 
I'm looking at what would be involved in converting from MeetMe to
ConfBridge and there seems to be a lot of missing administrative things,
but I hope I'm just missing it.  We all know about the missing realtime
linkage.  That's a major nuisance, but can be worked around.

More serious is that the CLI command to display users in a ConfBridge
don't show the caller ID information, so it becomes very hard to
have web applications that show who's in a conference.  There also doesn't
seem to be a way to lock conferences or mute or kick out users from
the dialplan.  And the CLI command needs a channel, not a user index,
making scripting via the dialplan that much harder.

What am I missing?

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Call Termination Provider Madness

2012-10-02 Thread Chris Bagnall 

On 2/10/12 6:51 pm, Carlos Alvarez wrote:

Your traffic level, number of concurrent calls, etc would help us know what
sort of carrier you should be talking to.


Equally important, your geographic location, and the geographic location 
to which most of your calls are made will be useful in helping list 
members advise you.


Kind regards,

Chris
--
This email is made from 100% recycled electrons

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Too many open files: what might cause this?

2012-10-02 Thread Mikhail Lischuk 
 

Adam Moffett писал 03.10.2012 00:09: 

> manager.c: Accept
returned -1: Too many open files

It's not a problem of old Asterisk.
You should check your system limits with the "ulimit -a" 

You can
increase different limits, say "ulimit -n 4096" will increase limit for
open files to 4096 

I suggest reading ulimit manuals. 

-- 
With Best
Regards
Mikhail Lischuk

 --
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Too many open files: what might cause this?

2012-10-02 Thread Adam Moffett 
I was looking at open files.  lsof | wc -l tells me around 2000 or so.  
The total number goes up and down, but hovers around 2000 and doesn't 
seem to show any upward trend.  I haven't rebooted the system since I 
killed and restarted asterisk, so the first guess would be that asterisk 
is what had all the files open.  I wish I had checked that before I 
killed it.


cat /proc/sys/fs/file-max says 367467 so I guess whatever happened must 
have been pretty extreme.


So a few people just reported that they couldn't make any calls.  I 
logged into asterisk and at first everything on the console looked 
normal, then I got swamped with messages about too many open files.


This is from my asterisk/messages log file:
[Oct  2 16:46:00] WARNING[19429] rtp.c: Unable to allocate RTCP 
socket: Too many open files
[Oct  2 16:46:00] WARNING[19429] udptl.c: Unable to allocate socket: 
Too many open files

[Oct  2 16:46:00] WARNING[19429] acl.c: Cannot create socket
[Oct  2 16:46:00] WARNING[19429] channel.c: Channel allocation failed: 
Can't create alert pipe! Try increasing max file descriptors with 
ulimit -n


Messages like that repeat a few dozen times, and then I get this one

manager.c: Accept returned -1: Too many open files

...and that repeated tens of thousands of times.  I killed asterisk 
and restarted it.  Looks normal again.


What the heck just happened?  A bug? Was I attacked? Maybe I'm 
honestly hitting some system limit and I should bump up max file 
descriptors like the message says?  We do have a few hundred SIP peers 
and maybe we'll hit 20-30 simultaneous calls at peak times but I 
didn't think that was particularly high load.


This is Asterisk 1.4.44.  I know the 1.4 branch is old, but it had 
been trouble free for years (until now), and I'd have to rewrite some 
config syntax to upgrade so I didn't see a need to do it.




--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users




--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] How to remove the call waiting tone without disabling callwaiting?

2012-10-02 Thread Niccolò Belli 
Thank you, I already considered such an approach but the customer wanted 
to receive the new call *immediately* after the hangup (basically 
because "it was possible with the old pbx").


This is how I solved: http://www.spinics.net/lists/asterisk/msg153399.html

Such a way I hear the annoying beep every 40 seconds. If someone knows 
how to COMPLETELY REMOVE the fucking beep please let me know: there are 
already tons of phones ringing everywhere so there is no need for an 
annoying beep.


P.S.
By the way, I had a nice time with SNOM phones crashing and freezing 
everywhere thanks to a bug while handling SIP ANSWERED ELSEWHERE. I 
suggest everyone to upgrade to 8.7.3.15 beta.


Cheers,
Niccolò

Il 02/10/2012 21:16, Warren Selby ha scritto:

Niccolo,

This is what I did for one of my clients.  They had a very busy queue,
and were getting annoyed with the Call Waiting beeps.  To resolve this,
we changed the method for contacting the agents to Local Channels.  The
local channel would then do a check (using the GROUP() function) and see
if it was already in a call or not, and if it was, it would delay
sending the call to that agent.  It would then try again after a certain
amount of time had passed.

The agents are added to the queue dynamically using
AddQueueMember(${queue-name},Local/${agent-exten}@agent-callsSIP/${state-exten}).
  We would load the appropriate variables in the preceding dialplan.

Here's the snippets from extensions.conf:

[agent-calls]
;Context to dial agents when calls come into their queues

exten => _,1,Wait(1)
exten => _,n,Set(GROUP()=${EXTEN}-calls)
exten => _,n,GotoIf($[${GROUP_COUNT(${EXTEN}-calls)} > 1]?wait_longer)
exten => _,n,Dial(SIP/${EXTEN})
exten => _,n,GotoIf(${DIALSTATUS}=UNAVAILABLE?wait_longer)
exten => _,n,Goto(1)
exten => _,n(wait_longer),Wait(15)
exten => _,n,Goto(1)

--
http://www.linuxsystems.it

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] Too many open files: what might cause this?

2012-10-02 Thread Adam Moffett 
So a few people just reported that they couldn't make any calls.  I 
logged into asterisk and at first everything on the console looked 
normal, then I got swamped with messages about too many open files.


This is from my asterisk/messages log file:
[Oct  2 16:46:00] WARNING[19429] rtp.c: Unable to allocate RTCP socket: 
Too many open files
[Oct  2 16:46:00] WARNING[19429] udptl.c: Unable to allocate socket: Too 
many open files

[Oct  2 16:46:00] WARNING[19429] acl.c: Cannot create socket
[Oct  2 16:46:00] WARNING[19429] channel.c: Channel allocation failed: 
Can't create alert pipe! Try increasing max file descriptors with ulimit -n


Messages like that repeat a few dozen times, and then I get this one

manager.c: Accept returned -1: Too many open files

...and that repeated tens of thousands of times.  I killed asterisk and 
restarted it.  Looks normal again.


What the heck just happened?  A bug? Was I attacked? Maybe I'm honestly 
hitting some system limit and I should bump up max file descriptors like 
the message says?  We do have a few hundred SIP peers and maybe we'll 
hit 20-30 simultaneous calls at peak times but I didn't think that was 
particularly high load.


This is Asterisk 1.4.44.  I know the 1.4 branch is old, but it had been 
trouble free for years (until now), and I'd have to rewrite some config 
syntax to upgrade so I didn't see a need to do it.




--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] How to remove the call waiting tone without disabling

2012-10-02 Thread Niccolò Belli 

Hi,

Il 02/10/2012 21:04, Mc GRATH Ricardo ha scritto:

How about to change  tone list on indications.conf  file?


As I already said indications.conf doesn't work for dahdi channels, 
unfortunately the callwaiting tone is hardcoded in asterisk itself (not 
even in dahdi/libtonezone!). I solved patching and recompiling asterisk:

http://www.spinics.net/lists/asterisk/msg153399.html

Another good solution is to disable call waiting and using local channel 
instead, as suggested by Warren Selby:

http://www.spinics.net/lists/asterisk/msg153424.html

Niccolò
--
http://www.linuxsystems.it

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Case-sensitivity of Dialplan variables.

2012-10-02 Thread j...@millican.us 

On 10/1/2012 5:19 PM, Danny Nicholas wrote:

-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Mark Michelson
Sent: Monday, October 01, 2012 4:15 PM
To: asterisk-users@lists.digium.com
Subject: [asterisk-users] Case-sensitivity of Dialplan variables.

Hi!

I've been confronted with an interesting issue to resolve. The issue is
located here:

https://issues.asterisk.org/jira/browse/ASTERISK-20163

The issue involves case-sensitivity of channel and global variables in the
dialplan. Current behavior is as follows:

1) Variables created in the dialplan by users are case-insensitive.
Thus if the variable MARK were set, then ${MARK} and ${mark} would both
evaluate to the set value.

2) Variables used internally by Asterisk are case sensitive. So if some
application set a variable called MARK, it would be different from a
variable set by some application called mark.

First off, this inconsistency is just weird. It would be much easier to just
have things work one way or the other, not to have this mix.

In addition, this can lead to some awkward situations. Consider that someone
wants to use a specific SIP codec and so they set the variable SIP_CODEc to
be "g722". Notice that the final 'c' is lowercase, presumably due to a
typing error. The option would not take effect because chan_sip specifically
checks the value of the case-sensitive ${SIP_CODEC}. What makes this weirder
is that if the dialplan writer were to check ${SIP_CODEC} in the dialplan
using a NoOp or Verbose call, then he would see the variable set to the
value he set it to when he set ${SIP_CODEc} because the variable
substitution is case-insensitive in the dialplan. This makes debugging the
problem difficult.

I propose that dialplan variables need to be made consistent in their
evaluation. We need to choose either to be always case-sensitive or always
case-insensitive. The problem is, I don't know which of these changes would
have a larger effect on people. This is where I would like your feedback.
Which way should it go?

Some of you might be eager to propose a configuration option to decide which
it should be. I'm sick of having hundreds of options in Asterisk to slightly
tweak the behavior one way or another. This needs to go one way or the
other, not be configurable.

What I plan to do, no matter which way the vote goes, is to document on the
wiki how things currently behave in Asterisk, to include the example I gave
above (or something similar anyway). Depending how the vote goes, I will
make the necessary code changes in Asterisk trunk. I will document the
behavior change both in UPGRADE.txt and on the wiki.

When considering which way you lean, consider that we really don't have much
of a precedent to go on. For instance, dialplan applications are
case-insensitive ("answer" and "Answer" and "ANSWER" are all the same).
Dialplan functions, on the other hand, are case sensitive ("HASH" would be
evaluated properly but "hash" would not). My personal opinion is that all
variable evaluations should be case-sensitive.
I don't feel all that strongly about it though and could easily be swayed
the other way if people respond overwhelmingly in opposition.

So respond here and let me know what you think. I got a couple of replies on
the -dev list and they said that this would be good to put out on the -users
list too.

Mark Michelson

In true Republican fashion, I'm going to vote for case-insensitivity.


I will definitely cast my vote for always case-sensitive.  asterisk == 
asterisk != Asterisk != ASTERISK   In my opinion this would make 
troubleshooting much easier.  Normally I would fuss like hell if a 
change that would break existing behavior were proposed but, again just 
my opinion, this is fixing something that has always been broken and 
because of this I would also suggest making this the normal behavior for 
all aspects of Asterisk.

JohnM


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] How to remove the call waiting tone without disabling callwaiting?

2012-10-02 Thread Warren Selby 
On Mon, Oct 1, 2012 at 10:03 AM, Niccolò Belli wrote:

> Hi,
> The call waiting tone is very annoying (you hear nothing while it plays
> the beep). I need callwaiting because of the queues (the phone has to ring
> as soon as you hangup) but I want to remove the beep on my dahdi channels,
> how can I do?
>
> Thanks,
> Niccolò
> --
> http://www.linuxsystems.it



Niccolo,

This is what I did for one of my clients.  They had a very busy queue, and
were getting annoyed with the Call Waiting beeps.  To resolve this, we
changed the method for contacting the agents to Local Channels.  The local
channel would then do a check (using the GROUP() function) and see if it
was already in a call or not, and if it was, it would delay sending the
call to that agent.  It would then try again after a certain amount of time
had passed.

The agents are added to the queue dynamically using
AddQueueMember(${queue-name},Local/${agent-exten}@agent-callsSIP/${state-exten}).
 We would load the appropriate variables in the preceding dialplan.

Here's the snippets from extensions.conf:

[agent-calls]
;Context to dial agents when calls come into their queues

exten => _,1,Wait(1)
exten => _,n,Set(GROUP()=${EXTEN}-calls)
exten => _,n,GotoIf($[${GROUP_COUNT(${EXTEN}-calls)} > 1]?wait_longer)
exten => _,n,Dial(SIP/${EXTEN})
exten => _,n,GotoIf(${DIALSTATUS}=UNAVAILABLE?wait_longer)
exten => _,n,Goto(1)
exten => _,n(wait_longer),Wait(15)
exten => _,n,Goto(1)


-- 
Thanks,
--Warren Selby, dCAP
http://www.SelbyTech.com 
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] How to remove the call waiting tone without disabling

2012-10-02 Thread Mc GRATH Ricardo 
Niccol

How about to change  tone list on indications.conf  file?
Please comment call waiting line ";" according to country zone or default 
settings.
Good luck 
 
Mc GRATH Ricardo
E-Mail mcgra...@mail2web.com
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] DAHDI help please

2012-10-02 Thread Pat Collins 
Thank you for the reply!
So far, I've managed to get the on off hook to work properly!
My next problem is the incoming ring. I've changed the /include/dahdi/user.h
file:
#define DAHDI_ABIT  (1 << 3)
#define DAHDI_BBIT  (1 << 2)
#define DAHDI_CBIT  (1 << 1)
#define DAHDI_DBIT  (1 << 0)
#define DAHDI_XBIT  (3 >> 2)  ADDED THIS!!

#define DAHDI_BITS_ABCD (DAHDI_ABIT | DAHDI_BBIT | DAHDI_CBIT | DAHDI_DBIT)
#define DAHDI_BITS_ABD (DAHDI_ABIT | DAHDI_BBIT | DAHDI_DBIT)
#define DAHDI_BITS_ACD (DAHDI_ABIT | DAHDI_CBIT | DAHDI_DBIT)
#define DAHDI_BITS_BCD (DAHDI_BBIT | DAHDI_CBIT | DAHDI_DBIT)
#define DAHDI_BITS_AC (DAHDI_ABIT | DAHDI_CBIT)
#define DAHDI_BITS_BD (DAHDI_BBIT | DAHDI_DBIT)
#define DAHDI_BITS_X   (DAHDI_XBIT) AND THIS!!

Then in /driver/dahdi/dahdi-base.c I changed:
static void dahdi_rbs_sethook(struct dahdi_chan *chan, int txsig, int
txstate,
int timeout)
{
static const struct {
unsigned int sig_type;
/* Index is dahdi_txsig enum */
unsigned int bits[DAHDI_TXSIG_TOTAL];
} outs[NUM_SIGS] = {
{
/*
 * We set the idle case of the DAHDI_SIG_NONE to
this pattern to make idle E1 CAS
 * channels happy. Should not matter with T1, since
on an un-configured channel,
 * who cares what the sig bits are as long as they
are stable
 */
.sig_type = DAHDI_SIG_NONE,
.bits[DAHDI_TXSIG_ONHOOK]  = DAHDI_BITS_ABCD,
}, {
.sig_type = DAHDI_SIG_EM,
.bits[DAHDI_TXSIG_OFFHOOK] = DAHDI_SIG_NONE,   /*
changed from ACD */
.bits[DAHDI_TXSIG_START]   = DAHDI_SIG_NONE,   /*
changed from ACD */
.bits[DAHDI_TXSIG_ONHOOK]  = DAHDI_BITS_ABCD, /*
added this !! */
.bits[DAHDI_RXSIG_START]= DAHDI_BITS_X,  /*
start.. xbit */
.bits[DAHDI_RXSIG_RING]= DAHDI_BITS_X,  /*
ring.. xbit */
}, {

And this:
void dahdi_rbsbits(struct dahdi_chan *chan, int cursig)
{
unsigned long flags;
if (cursig == chan->rxsig)
return;

if ((chan->flags & DAHDI_FLAG_SIGFREEZE)) return;
spin_lock_irqsave(&chan->lock, flags);
switch(chan->sig) {
case DAHDI_SIG_EM: /* was FXO Groundstart */
/* B-bit only matters for FXO GS changed BBIT to
XBIT */
if (!(cursig & DAHDI_XBIT)) {
__dahdi_hooksig_pvt(chan, DAHDI_RXSIG_START);
break;
}
/* Fall through */
case DAHDI_SIG_FXOGS:  /* changed from E and M */
case DAHDI_SIG_EM_E1:
case DAHDI_SIG_FXOLS: /* FXO Loopstart */
case DAHDI_SIG_FXOKS: /* FXO Kewlstart */
if (cursig & DAHDI_ABIT)  /* off hook */
__dahdi_hooksig_pvt(chan,DAHDI_RXSIG_OFFHOOK);
else /* on hook */
__dahdi_hooksig_pvt(chan,DAHDI_RXSIG_ONHOOK);
break;

Thank you for your help Shaun!!!

-Original Message-
From: asterisk-users-boun...@lists.digium.com
[mailto:asterisk-users-boun...@lists.digium.com] On Behalf Of Shaun Ruffell
Sent: Tuesday, October 02, 2012 2:17 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] DAHDI help please

On Mon, Oct 01, 2012 at 06:44:22PM -0400, Pat Collins wrote:
> Can anyone tell me if it is possible to invert the signaling bits on a 
> T1 channel?
>
> I need to emulate PLAR signaling in asterisk.  E&M seems to be an 
> exact match if reversed.
>
> I need idle bits  and seized 

Perhaps you could edit dahdi_rbs_sethook() and dahdi_q_sig()?  Those
function map state to RBS states.

--
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at:
www.digium.com & www.asterisk.org

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to
Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] DAHDI help please

2012-10-02 Thread Shaun Ruffell 
On Mon, Oct 01, 2012 at 06:44:22PM -0400, Pat Collins wrote:
> Can anyone tell me if it is possible to invert the signaling bits
> on a T1 channel?
>
> I need to emulate PLAR signaling in asterisk.  E&M seems to be an
> exact match if reversed.
>
> I need idle bits  and seized 

Perhaps you could edit dahdi_rbs_sethook() and dahdi_q_sig()?  Those
function map state to RBS states.

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] Call Termination Provider Madness

2012-10-02 Thread Carlos Alvarez 
On Tue, Oct 2, 2012 at 10:44 AM, Chris Nighswonger <
cnighswon...@foundations.edu> wrote:

> If this is the wrong place to post this I'm sure someone will let me know.
> :-)
>
> I'm looking for a reliable, inexpensive call termination service
> (SIP). The one I am presently with does not seem to know what IPs they
> send inbound calls from, and it is maddening to keep up with the FW
> changes necessary, not to mention the calls which are not connected.
>

Your traffic level, number of concurrent calls, etc would help us know what
sort of carrier you should be talking to.

Also if you're constantly chasing IPs for RTP, you are the one doing it
wrong.  Is it SIP or RTP that's the problem in the firewall?

-- 
Carlos Alvarez
TelEvolve
602-889-3003
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] Call Termination Provider Madness

2012-10-02 Thread Chris Nighswonger 
If this is the wrong place to post this I'm sure someone will let me know. :-)

I'm looking for a reliable, inexpensive call termination service
(SIP). The one I am presently with does not seem to know what IPs they
send inbound calls from, and it is maddening to keep up with the FW
changes necessary, not to mention the calls which are not connected.

Kind regards,
Chris

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] One side voice one side musiconhold

2012-10-02 Thread Thorsten Göllner 
Currently I have no idea. But you wrote, that it does not happen all the 
time. Please provide us a log extract from that case where is going 
wrong. Perhaps you can do a "diff" for the good and the bad case 
yourself before?!


Am 02.10.2012 09:02, schrieb Gianluca Baù:

Hello Thorsten,

i had a trace with core set debug 10 and core set verbose 10 but i
didn't find anything usefull.
The log is very full so it could be that i missed some important information.

This is a the less verbose output of the problem:

   -- SIP/22-01b3 answered SIP/64-01b2
 -- Started music on hold, class 'default', on SIP/22-01b3
 -- Stopped music on hold on SIP/siprouter-01aa
 -- Executing [h@to-operators:1] Goto("SIP/64-01b2",
"9991") in new stack
 -- Goto (to-operators,h,9991)
 -- Executing [h@to-operators:9991] Set("SIP/64-01b2",
"~~parentcxt~~=") in new stack
 -- Executing [h@to-operators:9992]
GotoIf("SIP/64-01b2", "1?9996") in new stack
 -- Goto (to-operators,h,9996)
 -- Executing [h@to-operators:9996] NoOp("SIP/64-01b2",
"") in new stack

Where:
SIP/siprouter-01aa is A
SIP/64 is B
SIP/22 is C

I think this is the moment of the transfer.

-- Started music on hold, class 'default', on SIP/22-01b3
-- Stopped music on hold on SIP/siprouter-01aa

After the transfer of the call from B it seems to start the music to C
and to stop it on A.

I'll try to provide you a better trace. Do you have any ideas about the cause?

Thanks, regards

Gianluca

2012/10/1 Thorsten Göllner :

Did you take a look at the asterisk log? With "core set verbose 3" or more?

Am 01.10.2012 12:46, schrieb Gianluca Baù:


Hello guys,

my name is Gianluca and this is my first post in this ml.

i've a strange problem with my asterisk box. I'll try to explain you.

A (sip from ser) calls --> B (sip asterisk peer)

B put A on hold with musiconhold

B calls C

B transfer the call with A to C

A hears the C voice while C hears musiconhold

C is every peer of the asterisk.

This happens with version 1.6.22 and Asterisk 1.8.14.0 too. I tried to
update but the problem persists.
I've to say that the used phones are the same for both the versions.
They are Snom and Grandstream.

This problem is hard to debug because it doesn't happen everytime.

Did you hear something about this problem? Can you suggest me how to
understand this situation?

Thanks, regards



--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users

Re: [asterisk-users] One side voice one side musiconhold

2012-10-02 Thread Gianluca Baù 
Hello Thorsten,

i had a trace with core set debug 10 and core set verbose 10 but i
didn't find anything usefull.
The log is very full so it could be that i missed some important information.

This is a the less verbose output of the problem:

  -- SIP/22-01b3 answered SIP/64-01b2
-- Started music on hold, class 'default', on SIP/22-01b3
-- Stopped music on hold on SIP/siprouter-01aa
-- Executing [h@to-operators:1] Goto("SIP/64-01b2",
"9991") in new stack
-- Goto (to-operators,h,9991)
-- Executing [h@to-operators:9991] Set("SIP/64-01b2",
"~~parentcxt~~=") in new stack
-- Executing [h@to-operators:9992]
GotoIf("SIP/64-01b2", "1?9996") in new stack
-- Goto (to-operators,h,9996)
-- Executing [h@to-operators:9996] NoOp("SIP/64-01b2",
"") in new stack

Where:
SIP/siprouter-01aa is A
SIP/64 is B
SIP/22 is C

I think this is the moment of the transfer.

-- Started music on hold, class 'default', on SIP/22-01b3
-- Stopped music on hold on SIP/siprouter-01aa

After the transfer of the call from B it seems to start the music to C
and to stop it on A.

I'll try to provide you a better trace. Do you have any ideas about the cause?

Thanks, regards

Gianluca

2012/10/1 Thorsten Göllner :
> Did you take a look at the asterisk log? With "core set verbose 3" or more?
>
> Am 01.10.2012 12:46, schrieb Gianluca Baù:
>
>> Hello guys,
>>
>> my name is Gianluca and this is my first post in this ml.
>>
>> i've a strange problem with my asterisk box. I'll try to explain you.
>>
>> A (sip from ser) calls --> B (sip asterisk peer)
>>
>> B put A on hold with musiconhold
>>
>> B calls C
>>
>> B transfer the call with A to C
>>
>> A hears the C voice while C hears musiconhold
>>
>> C is every peer of the asterisk.
>>
>> This happens with version 1.6.22 and Asterisk 1.8.14.0 too. I tried to
>> update but the problem persists.
>> I've to say that the used phones are the same for both the versions.
>> They are Snom and Grandstream.
>>
>> This problem is hard to debug because it doesn't happen everytime.
>>
>> Did you hear something about this problem? Can you suggest me how to
>> understand this situation?
>>
>> Thanks, regards
>
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>   http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users